Michael Scherer skrev 31.10.2011 18:07:
Le dimanche 30 octobre 2011 à 14:19 +0200, Thomas Backlund a écrit :
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)
That's the point that Lennart make, ie :
"we used to have / to mount all partition and /usr to be mounted, now,
we have initramfs to mount /, and then / to mount /usr, so it would be
simpler to merge / and /usr"
-ENOTCONVINCED
So why merge / and /usr and kill a usable feature?
Just have initramfs mount / and /usr, no need to merge.
So that's simple. For stuff needed for initial boot, we have initrd, for
the rest, that's /usr/
http://www.spinics.net/lists/fedora-devel/msg158642.html
-ESTILLNOTCONVINCED
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.
That's also what people say about manually compiling software in
solaris, and I think they are wrong, so that's not really a compeling
argument to my eyes.
Yeah, well that's your opinion.
In fact "using packages prevent me from finetuning my software" is also
a common and recuring theme from the same people ( well, slightly less
recuring nowadays as I didn't meet people telling me so since gentoo and
slackware usage slightly dropped ).
We have unix server since 1970, that doesn't mean the assumption that
lead to some design decision are not open to be revisited.
I dont mind people revisiting design decisions, but breaking working
setups sucks bigtime.
But I guess that's the development trend nowdays: "I cant be bothered to
fix things properly so I just call it "depreceated"... and go ahead
and break things just as I like"
Oh well, I guess it's time to start blacklisting some rpms to ensure
things keep working as they are intended.
--
Thomas
