Next Step...

Posted Apr 2, 2011 16:41 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
In reply to: Next Step... by rleigh
Parent article: Introducing /run

I gain at least a measure of order from /usr.

First, why do I need "/include"??? A language-specific directory on the top level? "/games" is equally stupid.

Oh, and how about /amd64-mingw32msvc, /arm-linux-gnueabi or /i586-mingw32msvc? Won't it be lovely to have them on the top level?

What we really need is consolidation of everything under ONE directory. I'd better move /bin, /sbin, /lib TO /usr if I had my way. Unfortunately, it's too deeply ingrained by now in all sorts of applications.

Think about it for a second. Imagine that you'd have a Linux with /etc, /home, /var, /usr in the top directory. Maybe also /system for sysfs, procfs and runtime directories. Won't it be easier to manage and use?

to post comments

Next Step...

Posted Apr 2, 2011 17:51 UTC (Sat) by rleigh (guest, #14622) [Link] (2 responses)

The individual extra paths are purely cosmetic. That's really missing the point of why a separate /usr is bad and/or unnecessary. And by separate, I mean separately mountable.

There's a significant cost to having a separate /usr. That cost is having some parts of the system unavailable before it is mounted, which makes the system have to go through complex contortions to actually start up.

Consider the NSS modules under /lib/libnss*.so used by the eglibc resolver. They may have dependencies on other libraries. Some of the LDAP modules have depend on libraries in /usr e.g. cryto libraries. If that module is needed to bring up the system, all those libraries must be moved to /lib, and any other data they need from /usr must be brought into the root.

Also consider eglibc itself; the locale data and other parts are found under /usr. If you use any of these facilities before /usr is mounted, it can break in "interesting" ways.

Those are just two examples. There's plenty more. The point is that it's complex, fragile, and makes some things incredibly hairy, and other things not possible at all.

These issues go away when you don't have a separate /usr. If you no longer have a separate / and /usr (i.e. mounting the roofs gets you both), then you have to question why you have /usr at all. Seriously, why? What advantages does it give you? It the cost/benefit worth it? I've spent some time thinking about the issue--you can see a link to my thoughts on the matter elsewhere on this page. Unifying / and /usr is a logical consequence of this.

An important concept to grasp is that on a modern package-managed distribution, / and /usr are not separable, and in fact have never been separable. They exist as a managed whole, and it is not possible to use or upgrade/maintain one without the other.

Regards, Roger

Next Step...

Posted Apr 2, 2011 18:12 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Then one can unify /var and /. What if one needs Postfix running in order to use SMTP to get a one-time password for the system to boot? Or maybe /var/spool is necessary for CUPS to print out boot logs on a remote printer?

Your argument is incredibly weak. If you need LDAP for your system to mount /usr then you definitely doing something wrong and you just should make sure that /usr is available before LDAP is needed. And uniting / and /usr won't give you ANYTHING, since in this case you won't even have the final / if LDAP is not available.

Besides, namespace pollution is a reason in itself to avoid throwing some extra stuff to /.

Next Step...

Posted Apr 4, 2011 2:38 UTC (Mon) by hmh (subscriber, #3838) [Link]

1. /usr inside /: we have been through that recently enough in debian-devel. There were many objections, and it was rejected for the time being.

It is very unlikely to fly until RO / becomes a reality. And unlike /run,
since it has been recently rejected, any attempts to get this deployed without getting most of the issues addressed are likely to backfire very nastly.

And you cannot have "no /usr" if you don't solve this one first, as all reasons for rejecting it are also valid for "no /usr".

2. no /usr: an EXTREMELY HARD sell. It causes a major mess on / and to my knowledge it will give us no strong technical advantages at all. It needs to wait for (1) above to be resolved, anyway.