LWN.net Logo

Various notes on /usr unification

Various notes on /usr unification

Posted Feb 28, 2012 19:47 UTC (Tue) by miguelzinho (subscriber, #40535)
Parent article: Various notes on /usr unification

After reading this I was completely amazed to know how the creation of /bin, /sbin and /lib were actually an workaround to hardware limitation. The article's title must change to "Various notes on /usr RE-unification, 30 years late".


(Log in to post comments)

Various notes on /usr unification

Posted Feb 28, 2012 21:35 UTC (Tue) by khim (subscriber, #9252) [Link]

Often it does not really matter just why this or that decision was made. Other, different things start depending on it. And often even if the initial decision was done on a whim it can not be changed later because other, different things start to depend on it.

One example from my own practice: when I've developed compiler for x86-64 NaCl I've noticed that our security model makes it actually impossible to address more then 4GiB of address space and this makes 8bytes pointers (normal for x86-64) kinda pointless. We've talked a bit about it, I've tried to switch GCC to model with 4 byte pointers in memory (which was easy enough to do) and we used the result (it was faster and used less memory: what's not to like?). For about month or two our compiler had insane model where pointers were 4 bytes long and "longs" were 8 bytes long, but we've found out quite soon that such combination just triggers too many bugs in programs. Eventually we've standardized on ILP32 model. Later, when PNaCl effort was started they found out that all NaCl compilers (X86-32, X86-64 and ARM) are using ILP32 model - and this was embedded in the bitcode format!

Now, if we'll try to change x86-64 NaCl memory model we'll find out that it'll not be easy to do. Even if the initial motivation was just to save some memory by removing useless zero bytes (and to get slightly better results on benchmarks as a bonus) today there are another justification.

And this happened just in a few last years! As you can guess Linux has somewhat longer history and / vs /usr split was used for different things along these years. It looks like today they all are not really valid (Linux does not include one set of programs in /bin and another, totally different, in /usr, for example) but it's not enough to say "hey, Ken and Dennis leaked their OS into the equivalent of home because an RK05 disk pack on the PDP-11 was too small thus today it's all is not needed because we don't use RK05 disk packs". No, we should evaluate situation today and look on the use of said split today.

Why it was done in first place is not important question (unless you like UNIX folklore). Why it's used today is an important question. That's why 40 years old fairy tales are not even mentioned in the appropriate place.

Various notes on /usr unification

Posted Feb 29, 2012 9:16 UTC (Wed) by jezuch (subscriber, #52988) [Link]

> Often it does not really matter just why this or that decision was made.

It's basically how culture "happens". "We do this because, uh, well, waidaminute... We do this because our parents and out grandparents did this, go away and don't ask stupid questions!"

;)

Various notes on /usr unification

Posted Feb 28, 2012 21:41 UTC (Tue) by flewellyn (subscriber, #5047) [Link]

Very interesting link, thank you! It's funny seeing how a temporary hack got turned into a rule with lots of post-hoc justification.

I do note this amusing bit from the post:

>I'm still waiting for /opt/local to show up...

I have seen this in the wild! If you use Macports on OS X, /opt/local is where the ports tree and all packages installed through it live.

Various notes on /usr unification

Posted Feb 29, 2012 13:53 UTC (Wed) by sorpigal (subscriber, #36106) [Link]

I think the point is that it's not just some justifications after the fact, it's new requirements that happen to rely on old behaviors. Change the old behaviors, break the new requirements. Maybe the original behavior was silly but the new requirement still relies on it and if you change the original behavior users of the new thing will not be satisified with "the original reason for that behavior no longer exists."

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds