The story behind this started with udev. udev was linking/depending on things outside /bin, so more and more stuff had to moved out. Eventually someone decided this was silly, and (at least on Linux with an initramfs) there's there speration of / and /usr; and /bin and /sbin is obsolete.

The pro are explained on the site. The con is people who have /usr as a separate partition and don't use and initramfs; they will now require an initramfs to boot under this proposal - and that group has been quite vocal. (The fact the proposer of this is the author and maintainer of systemd and PulseAudio is part of the reason too)

I think this configuration is something Gentoo should support (but not yet force it or make it the default - at least until we have better dracut support and intergration of dracut into genkernel)

I don't know what exactly from /usr udev needs, but I think fixing udev so that booting with /usr on a separate partition becomes possible again would be more sensible (from an administrator's point of view). I do not see a good reason to make booting with /usr on a separate partition and without an initramfs completely impossible. The initramfs just adds another point of failure here._________________Unix philosophy: "Do one thing and do it well."systemd: "Do everything and do it wrong."

Shaking up the entire FHS just because some distros are too brittle to allow flexible partitioning schemes is a flimsy excuse IMO. An easier solution would be to get rid of udev and replace it with something sane — with devtmpfs around, all udev is good for is a glorified chmod and hotplug daemon._________________*.ebuild // /etc/service/*

The con is people who have /usr as a separate partition and don't use and initramfs; they will now require an initramfs to boot under this proposal - and that group has been quite vocal.

Except... I'm yet to see a convincing argument for having / and /usr as separate partitions, so that's not really a con, it's just an inconvenience. Can you point me a situation where separating / and /usr is of any real advantage?

I'm discounting all the anti Lennart Poettering stuff per se.. I kept an open mind until I saw his performance "moderating" the Kernel Developer Panel at LinuxCon Europe... the guy may be clever but he appears to think "moderating" gave him a license to hijack, obstruct or ignore any dialogue not about him, including incredibly rudely dismissing good questions from the floor. He turned what could have been a great session into some sort of "look at me, I'm Lennart Poeterring" fest. Nevertheless it's still his ideas that should count, not his personality. But please, conference dudes: don't let him moderate anything, ever again.

The fact the proposer of this is the author and maintainer of systemd and PulseAudio is part of the reason too

I had not noticed that.
How strange ! I never wanted PulseAudio, do not want systemd as well, and the same about this initiative.
Provide tools ! Not policies ! These stuff are all about providing policies !
Provide broken tools (phonon backends, udev...) then force some particular sound server, specific partition schemes, initramfs... so that the tools might appear working !
I do not believe this is the correct way to go._________________

I don't know what exactly from /usr udev needs, but I think fixing udev so that booting with /usr on a separate partition becomes possible again would be more sensible (from an administrator's point of view). I do not see a good reason to make booting with /usr on a separate partition and without an initramfs completely impossible. The initramfs just adds another point of failure here.

Its about as good an idea as putting the entire content of /etc into a file and callining it "The Registry"
Oh, wait, that's already been done and shown not to work.

Gnome 3.x's dconf already does something similar to that with home directory files.
Instead of individual configuration files for Gnome 3.x applications, they can use dconf to store their settings in a binary database file in ${XDG_CONFIG_HOME}/dconf/ (Usually ~/.config/dconf).
Though, that doesn't sound like a good idea either.
I use both Gentoo Linux and Windows 7 and I like being able to just edit config files with a text editor or restore them from an old hard drive with Gentoo Linux.
When there is a problem with a Windows install and you reinstall it, restoring configuration stored in %USER_PROFILE%\NT_USER.DAT by restoring to a new profile doesn't work. The best you can do is open the registry hive in the registry editor and export parts of it and import them in the new installation's registry hive. Or have the foresight to backup the registry entries you need before reinstalling but you can't always to do that.
I was thinking of creating a program/script to automatically backup certain parts of the registry to restore on reinstall but I didn't get around to it.
For the most part new programs use Microsoft's .NET Framework which stores configuration in XML files most of the time (you could still use the registry if you want to) so that isn't as big of a problem though XML isn't as readable/editable as just key/value pair text files.

I don't know what exactly from /usr udev needs, but I think fixing udev so that booting with /usr on a separate partition becomes possible again would be more sensible (from an administrator's point of view). I do not see a good reason to make booting with /usr on a separate partition and without an initramfs completely impossible. The initramfs just adds another point of failure here.

It looks like that udev needs fixing or a replacement _________________"Dear Enemy: may the Lord hate you and all your kind, may you be turned orange in hue, and may your head fall off at an awkward moment."
"Linux is like a wigwam - no windows, no gates, apache inside..."

The fact the proposer of this is the author and maintainer of systemd and PulseAudio is part of the reason too

I have PulseAudio installed as I like per-application volume control and it appeared to be the only way to use Bluetooth Headphones.
I don't know much about systemd though. Something about a hal and a sysinitv replacement.
I don't really know what people would have against PulseAudio though I can see why systemd has critics.
Either way as someone said above, just being it's the same guy proposing UsrMove doesn't mean it's a bad idea (Though I don't understand enough about why they were separate in the first place to know why some may like that).

salahx wrote:

mrsteven wrote:

I don't know what exactly from /usr udev needs, but I think fixing udev so that booting with /usr on a separate partition becomes possible again would be more sensible (from an administrator's point of view). I do not see a good reason to make booting with /usr on a separate partition and without an initramfs completely impossible. The initramfs just adds another point of failure here.

If /usr is on its own partition, it can be mounted read only.
This allows backups while its in use and nfs exports to multiple thin clients, i.e. sharing it across the network.

When / (root) and /usr are merged these things are no longer possible.
Mounting / read only isn't useful, backing up / while its in use isn't useful either and nobody in their right mind would share / over several systems ... well only once._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

I don't know what exactly from /usr udev needs, but I think fixing udev so that booting with /usr on a separate partition becomes possible again would be more sensible (from an administrator's point of view). I do not see a good reason to make booting with /usr on a separate partition and without an initramfs completely impossible. The initramfs just adds another point of failure here.

Okay, but as far as I understand these "extras" are not strictly needed to boot the system. So then, why not run these parts in an additional step, after all local filesystems (or at least /usr) is mounted? Like this:

Well, we even have two stages already, see /etc/init.d/udev-postmount (just for some stuff that can't be done when some directories and files are not yet writeable). So maybe the udev rules file format has to be changed (to distinguish between stage 1 and 2), but I guess it would be a cleaner solution._________________Unix philosophy: "Do one thing and do it well."systemd: "Do everything and do it wrong."

If /usr is on its own partition, it can be mounted read only.
This allows backups while its in use and nfs exports to multiple thin clients, i.e. sharing it across the network.

When / (root) and /usr are merged these things are no longer possible.
Mounting / read only isn't useful, backing up / while its in use isn't useful either and nobody in their right mind would share / over several systems ... well only once.

Its about as good an idea as putting the entire content of /etc into a file and callining it "The Registry"
Oh, wait, that's already been done and shown not to work.

Which is where we get to where we are today...

Sometimes I think we're seeing the effects of Windows types who have moved to Linux, and brought their Windows Ways with them. I occasionally participate in Wayland discussions over on Phoronix, and see some similar attitudes over there. They see some Unix feature, don't understand why it's there, and thereby consider it to be ancient crap - like network transparency. That was my hot-button over on Phoronix, and being called a Unix-tard - they somehow feel that network transparency is something only a few old grey-hairs do, and anyone modern would use vnc or some such. Meanwhile I run use network transparency regularly on my home LAN, especially for servers that have no running X server or desktop, but I just prefer GUI client applications sometimes. I also use network transparency regularly at work.

I came to Linux as an OS/2 refugee, but I've been willing to learn the Linux way, and am pretty happy here, though I do miss the WPS. I'm not happy to see Windows refugees changing the Linux desktop into Windows._________________.sigs waste space and bandwidth

Its about as good an idea as putting the entire content of /etc into a file and callining it "The Registry"
Oh, wait, that's already been done and shown not to work.

Which is where we get to where we are today...

Sometimes I think we're seeing the effects of Windows types who have moved to Linux, and brought their Windows Ways with them. I occasionally participate in Wayland discussions over on Phoronix, and see some similar attitudes over there. They see some Unix feature, don't understand why it's there, and thereby consider it to be ancient crap - like network transparency. That was my hot-button over on Phoronix, and being called a Unix-tard - they somehow feel that network transparency is something only a few old grey-hairs do, and anyone modern would use vnc or some such. Meanwhile I run use network transparency regularly on my home LAN, especially for servers that have no running X server or desktop, but I just prefer GUI client applications sometimes. I also use network transparency regularly at work.

I came to Linux as an OS/2 refugee, but I've been willing to learn the Linux way, and am pretty happy here, though I do miss the WPS. I'm not happy to see Windows refugees changing the Linux desktop into Windows.

Yep, that is my beef with modern desktop development as well. It is so focused on on single user experience that is leaving at the side the network transparency (try to launch a browser from a remote location if the local copy is already running) - the feature in which Unix was light years ahead.

The irony is, in many modern settings standard X-windows networking/local rendering is actually become faster than vnc-style remote rendering/screen copying

If nobody is willing to write code to retain the support of separate /usr without initramfs and see it through the commit process, it's not a feature worth keeping.
Then I will gladly welcome this layer of extra complexity from packaging process removed; no need to care about cross / and /usr dependencies within a package, linking level, etc.

If nobody is willing to write code to retain the support of separate /usr without initramfs and see it through the commit process, it's not a feature worth keeping.
Then I will gladly welcome this layer of extra complexity from packaging process removed; no need to care about cross / and /usr dependencies within a package, linking level, etc.

Yes, and then if even developers do not care, at some stage we may observe gentoo becoming a distribution not worth keeping ...

If nobody is willing to write code to retain the support of separate /usr without initramfs and see it through the commit process, it's not a feature worth keeping.
Then I will gladly welcome this layer of extra complexity from packaging process removed; no need to care about cross / and /usr dependencies within a package, linking level, etc.

Yes, and then if even developers do not care, at some stage we may observe gentoo becoming a distribution not worth keeping ...

Full stop. You are confusing distribution maintainers with upstream udev developers.

I have not seen a need to put /usr on a separate partition so I have not done so.
Can someone explain why you would need /usr to be a separate partition?

I need (like) /usr to be a separate partition because I mount my SSD drive there, while I keep everything else on the HDD. I bind /usr/src and /usr/portage onto the HDD because they write lots of small files, and /opt back into /usr/opt on the SSD because it's mostly more apps. All my applications and shared data then reside on the SSD drive, and they load right now. The only time the SSD is written to is when portage is updating an application, which helps prevent write wear on the SSD drive. All verified with atop.

Because /bin, /lib, /var, and /etc remained on the HDD, there were few boot issues.Just a few minor things like alsactl, and udev-postmount handled them.

With udev-postmount going away, and the /bin, /lib directories migrating back to /usr, I don't see any choice but to migrate to the initramfs way if I want to keep my read-only SSD /usr/filesystem. It actually may not be a terrible thing if it prevents udev from becoming the cross-directory spaghetti code it was beginning to look like. Like it or not, with the increasing complexity of the boot process these days--encrypted disks, multi-terabyte drives and the like--I suspect initramfs is the future, udev or no.