| 1 |
On 2013-09-29 02:01, Dale wrote: |
| 2 |
|
| 3 |
> Next, we'll have to have C: even tho we never had to have one before. |
| 4 |
> ROFLMBO |
| 5 |
|
| 6 |
I would hesitate to laugh because that's where Linux is heading... And |
| 7 |
Alan and other's are right in that it's not udevs problem per se; it's |
| 8 |
all the half-desktop services[1]/applications that requires access to |
| 9 |
the libs in /usr for some unknown reason. This will (eventually) affect |
| 10 |
any operating system (even FreeBSD) that want to run things like, say, |
| 11 |
Gnome. This is feature creep on steroids. |
| 12 |
|
| 13 |
I just wish there was this simple system that would look like this: |
| 14 |
|
| 15 |
boot loader -> operating system -> applications |
| 16 |
|
| 17 |
...with a clear separation/well defined interfaces between them. Used to |
| 18 |
think Linux was a good compromise but not anymore... What you have now |
| 19 |
is something monstrous where application libs are part of the operating |
| 20 |
system. Hence the requirement of no separate /usr. At least if you run |
| 21 |
any of those things (like PAM - if some module require access to |
| 22 |
PKCS#11, Kerberos, Consolekit etc.). Personally I wouldn't touch them... |
| 23 |
|
| 24 |
In my opinion, this has gone way beyond what used to be called |
| 25 |
"spaghetti code" and into what I would like to call "spaghetti system". |
| 26 |
|
| 27 |
[1] Used to be called daemons but now people have adopted the Windows |
| 28 |
name for it. |
| 29 |
|
| 30 |
Best regards |
| 31 |
|
| 32 |
Peter K |
Archives