Colin Guthrie skrev 30.10.2011 13:26:
'Twas brillig, and Thomas Backlund at 29/10/11 21:13 did gyre and gimble:
So?
it's less impact on / than stuffing all of /usr on /
I don't understand what point you're trying to make here. You'd be
moving a whole bunch of stuff to /... And it becomes very tricky to
administer exactly what to move to / as the dependencies are non-trivial
to work out, the QA burden is very high to test all the various
combinations of setups to ensure all the required bits have been moved to /
After doing all that QA and ensuring all is well, then the whole
separate of /usr and / is totally blurred anyway. As someone campaigning
to keep /usr on a separate partition, I'd have thought this was what you
were trying to protect against in the first place... it seems totally
contradictory to suggest this as a solution.
Keep in mind that one of the key aims in highlighting this issue via
systemd is to actually ALLOW /usr to be a useful and self contained
filesystem. If /usr is properly configured without leaking half of it to
/ it could be shared across multiple machines far more easily or even
mounted as ro by default which could prove handy for security. Again,
this is about highlighting the issues with an aim to making /usr much
more useful. This is a laudable aim but you seem to be shooting it down
due to gut reactions and prejudice. I've not yet seen any technical
arguments from you about the topic.
I'm saying moving the stuff that is _really_ needed, not based on "udev
might run"...
well, thinking some more on it I guess the real design flaw (not systemd
specific) is using all of udev in init. Init should not care about more
than getting disc access (and probably network for pxe boots)
Then we wouldn't have to worry about "what udev might run" and could
keep a very clean /
Well, it _is_ idiotic if it breaks working setups / possibilities to
finetune systems.
It depends on your definition of "working". Sure if you specifically
work around the know limitations of the design then you may get a
bootable system, which you could classify as working, but I wouldn't say
this is a robust base. Just a house of cards waiting for the next
failure. I'd rather try and address the problems properly and be frank
about it in the discussions.
Well, it has worked 24/7 for servers for atleast last 15 years for
servers I maintain, so I'd say that is pretty robust.
--
Thomas
