Next Step...

Posted Apr 2, 2011 16:32 UTC (Sat) by rleigh (guest, #14622)
In reply to: Next Step... by Cyberax
Parent article: Introducing /run

Separate /usr is extremely common, and this isn't going to go away anytime soon. It will also never be possible to make the transition automatic: it could well require repartitioning in order to get a big enough root partition, or LV resizing etc. So having a unified / and /usr will only be possible to do on a fresh install. Initially, it will just be an option, and it won't be the default. But it will be /possible/.

Having a unified / and /usr isn't a new concept. Debian GNU/Hurd was doing this for years, with a /usr -> / symlink. It won't take much work to get this working on GNU/Linux. The main thing is finding and eliminating duplicate paths which would be overwritten; most of the duplicates are workarounds due to the split in the first place.

It's very common for people to have a knee-jerk negative reaction to this: after all, it's a radical departure from what we've been used to for decades. However, please do take the time to consider what you have gained from a separate /usr. For the vast majority of cases, nothing is gained other than needless complexity.

Most of the historical reasons for having the split are long gone. Sharing /usr between machines makes zero sense when you are using a modern package manager. Having a separate /usr for booting no longer matters now we have a capable initramfs which sets up the system sufficiently to allow any filesystem to be mounted: we can just mount / containing /usr directly; previously it was not always possible to do this if you needed to e.g. start up RAID arrays, discover LVM volume groups, bring up networking etc. Previously, you needed to do this using programs on the root filesystem as part of the startup sequence. Today, the initramfs does all of this. Now we have /run [I implemented this for Debian over the last two days in base-files and initscripts; should be available very soon] we are looking much nearer having a read-only / by default. It's common to have a read-only /usr; now you'll be able to have a read-only / *including* /usr.

Regarding top-level namespace pollution, most of the directories are duplicates, and those that are not still logically fit.

Regards,
Roger

to post comments

Next Step...

Posted Apr 2, 2011 16:41 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

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?

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.

Next Step...

Posted Apr 13, 2011 11:53 UTC (Wed) by robbe (guest, #16131) [Link]

> Regarding top-level namespace pollution, most of the directories are
> duplicates, and those that are not still logically fit.

Maybe get rid of cruft like /usr/{games,src} first? They have no reason to live.