Le lundi 31 octobre 2011 à 19:06 +0200, Thomas Backlund a écrit : > 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.
What is the usable feature ? To be able to put some kind of quota on /usr ? To be able to use a different fs for / and /usr ? > > >> 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. That's also yours, or you would be using solaris or slackware instead of doing packages. > > 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. So basically, you want fix that just change nothing ? > 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" Well, what do you propose to fix this properly ? -- Michael Scherer
