Next Step...

Posted Mar 31, 2011 9:27 UTC (Thu) by ldo (guest, #40946)
Parent article: Introducing /run

Creating /share as an alternative to /usr/share. Why? So /usr/share/zoneinfo can be moved to /share/zoneinfo. Why? So that /etc/localtime can become a symlink, instead of a copy of a timezone file. Why? So that ls -l /etc/localtime will show you at a glance what your system timezone setting is.

to post comments

Next Step...

Posted Mar 31, 2011 11:06 UTC (Thu) by rleigh (guest, #14622) [Link] (13 responses)

This will naturally arise from the unification of / and /usr. I plan on having a unified / and /usr (with /usr being a symlink to / for compatibility) as an install-time option for Debian wheezy. Once done, you'll have /games, /include, /local, /share, /src etc. at the top level, but which can still be referred to as /usr/include, /usr/local etc.

Regards,
Roger

Next Step...

Posted Mar 31, 2011 23:30 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Please, please, please. Tell me that it's a joke. Please....

Next Step...

Posted Apr 1, 2011 17:44 UTC (Fri) by hmh (subscriber, #3838) [Link] (7 responses)

It is not. But expect quite a lot of resistance in the Debian side. Unlike the addition of /run, which we wanted to do years ago, killing /usr is NOT going to be well received at all.

Next Step...

Posted Apr 1, 2011 17:48 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Absolutely there's going to be resistance. And for a good reason, the / namespace is already too polluted.

Besides, "/usr on a separate disk" is still fairly common.

Next Step...

Posted Apr 2, 2011 16:32 UTC (Sat) by rleigh (guest, #14622) [Link] (5 responses)

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

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.

Next Step...

Posted Apr 2, 2011 14:51 UTC (Sat) by pr1268 (guest, #24648) [Link]

While we're at it, why not introduce "/Program Files"?

/Ducks for cover
/Realizes April Fools' was one day ago

Next Step...

Posted Apr 2, 2011 22:58 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (2 responses)

Go the other way. Make /bin, /sbin, /lib and /lib64 symlinks to their counterparts in /usr. If you do, then suddenly /usr gets its original meaning back as "Unix System Resources". Because that's what it is going to be then: in /usr you find "The OS". And in / you will then only have a few top-level directories whose meaning is clearly bound to lifecycle properties, nothing else anymore.

Think a bit about this, let it sink in. It's much nicer to symlink the root /bin, /sbin, /lib directories into /usr, then the other way round.

Next Step...

Posted Apr 3, 2011 21:51 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

This is a bit nicer. I really hate all those extra folders in the root directory.

However, here's the next question. If we get rid of separately-mounted /usr then we should as hell have something to replace it.

The current initramfs-based infrastructure just doesn't cut it (even in Dracut). It's way too complex to manage. What if I want to have a LDAP client in initramfs?

Hm. Why not treat initramfs as a small separate installation?.. It can even be managed using chroot'ed package managers. Hmmm...

Next Step...

Posted May 4, 2011 22:33 UTC (Wed) by nix (subscriber, #2304) [Link]

That seemed cracked at first sight, but the more I think about it the more sense it makes. (I think SysV did something like it, too, but I don't have a SysV system nearby to check.)

It requires only one change to early boot: the initramfs needs to find and mount /usr as well as /. Since it's already finding /, this is unlikely to be remotely problematic: it can figure out where to find it by consulting the real /etc/fstab on the / it just mounted, as well.

I think I'll rejig my system this way and see what breaks.