On 06/17/2011 01:32 PM, Kay Sievers wrote:
On Fri, 2011-06-17 at 13:26 -0400, Robert Schweikert wrote:
On 06/17/2011 01:11 PM, Kay Sievers wrote:
On Fri, 2011-06-17 at 18:54 +0200, Dr. Werner Fink wrote:
On Fri, Jun 17, 2011 at 05:09:17PM +0200, Kay Sievers wrote:
On Fri, 2011-06-17 at 16:37 +0200, Guido Berhoerster wrote:
* Kay Sievers<kay.sievers@suse.de> [2011-06-17 12:13]: >> From the side of the enterprise people: /usr mountable ro. >> Please note that we have customers which are using exactly >> this feature. > > Sure, they will just need an initramfs that can do that, if they want it > to work in the future. > > Actually, the long-term goal is to merge the useless split of / and /usr > back to /usr and be able to mount /usr ro on every system. It's the same > model as Android is doing with /system.
On servers I always have /, /usr, (/usr)/home, /var, and /tmp on separate filesystems in order to prevent accidentally filling up /. I know others are doing the same and I think that is a perfectly legitimate use case.
Sure, you only need to be able to mount /usr from initramfs. Init will not care where it came from. But it will no longer be supported to start init with an empty /usr.
Actually, /bin, /sbin, /lib, /lib64, ... should just be symliks to /usr, which will be mounted by initramfs, and likely be read-only by default in the future.
This is a bug of systemd and a violation of the FSH standard. For server systems a nogo.
Yeah, it's a violation of the rules of the stone age. Many of them just don't make sense anymore. We need to pick the nice parts of UNIX, and leave the silly things behind us to be able to survive. And the split of / and /usr very high on the list of things we like to get rid of.
Anyway, FHS documents current behavior, it can not be violated. If the current behavior changes, FHS needs to change, and people actually working on that.
Just double checked on that. There is no awareness at the FHS level that systemd implementation is pushing for the removal of /bin, /sbin, /lib, /lib64 and having everything pushed into /usr.
Better speak up soon at fhs-discuss@lists.linux-foundation.org as the next release of FHS is in the works right now.
We submitted only /run so far.
The rest is all work-in-progress, and nothing ready for any slow-moving official FHS, or bike-shedding discussions. Stuff needs to work in reality before it can be formalized. Distros will experiment with it first. We are currently working on the initramfs code to make all that possible.
Will be a while before anything gets officially submitted. Remember, FHS documents behavior, does not set rules to follow.
Well, I'd say there will be a bunch of people that disagree with that statement. Since the "survive in the future" card has been played a couple of times in this thread, here are my $0.02. If systemd breaks the FHS there will be a lot of ticked of ISVs when they have to change their build system and/or application to accommodate whatever may break. Annoying app vendors is not the best way to achieve success or "survive in the future". Not that a transition cannot be completed, but when presented in the steamroller fashion as things are presented here the reaction on the other side is probably not very positive. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rschweikert@novell.com rschweikert@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org