[Mageia-dev] Please test: initscripts+systemd in updates_testing

Sun Oct 30 12:26:26 CET 2011

'Twas brillig, and Thomas Backlund at 29/10/11 21:13 did gyre and gimble:
+> 30.10.2011 01:16, Colin Guthrie skrev:
+>> 'Twas brillig, and Thomas Backlund at 27/10/11 15:12 did gyre and gimble:
+>>>
+>>> Then we need to move those libs to /lib(64)
+>>
+>> There is quite serious talk about deprecating /lib, /bin and /sbin and
+>> basically anything that is not in /usr (with exceptions for /home /root,
+>> /etc and a few others). Of course there are various flames about this
+>> idea (earth will collapse into sun etc.) but it's actually surprisingly
+>> well received thus far IMO.
+>>
+>> Also, keep in mind that you're talking about moving a *lot* to / here...
+>> all the PCI/USB databases, all the udev setup, any application that udev
+>> might run in it's rules.... I won't reiterate what is written in the
+> 
+> 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.
+
+>> link Olav already provided, but suffice to say the problem is neither
+>> new, not specific to systemd. It's just being highlighted by systemd.
+>> Please keep this in mind when commenting on this topic.
+>>
+> 
+> Interesting on how people think "systemd is the solution to everything",
+> and cant accept complaints when is screws up working systems....
+> 
+> It's pretty much like Apple fans and their love for iCrap
+
+And the statement above is as equally pointless as fanboiism. You're not
+giving ANY technical arguments here, just spouting FUD and pointless
+rhetoric which is not something I would expect to see from yourself :(
+
+>>>>> That's just plain idiotic.
+>>>> I somewhat agree. But even Fedora is suggesting not to have separate
+>>>> /usr :(
+>>>>
+>>>
+>>> That does not make it less idiotic. IIRC they employ the systemd creator
+>>> so...
+>>
+>> But that doesn't make the idea any more or less idiotic.
+>>
+>> The reasons stated (and this discussion happened many months ago) are
+>> all well understood and documented in the link provided by Olav.
+>>
+>> It is NOT a systemd problem. It's a problem we have RIGHT NOW too, it's
+>> just that most setups are easy enough to work around by waiting and
+>> doing this sequentially which slows down the whole boot process. We've
+>> solved similar problems in the past by moving things to /lib but it's
+>> just a sticking plaster, not a real fix.
+>>
+> 
+> What's the difference of moving stuff to /lib as compared moving all of
+> /usr into / besides bloating /
+
+It dilutes the whole point in keeping /usr separate in the first place!!
+This is what you are arguing for but yet you are contradicting it at the
+same time.
+
+> And by chasing seconds in bootup you screw those who want to finetune
+> their systems. Thats a regression.
+
+No it's not. By this argument if you were to build a house upon sand, it
+would be the fault of the brick manufacturer for building too heavy
+bricks, not the planners who thought that sand was an appropriate
+foundation. Papering over the cracks is not good for anyone. I want a
+robust system by design, not by careful manipulation of the fundamental
+problems to avoid the known broken bits.
+
+> For those  people that are so concerned about bootup times, why dont
+> they buy new hw, use fast ssd and learn how to suspend to ram/resume ...
+
+I really don't understand why people keep harping back to "startup
+times" as the sole argument for a systemd-based system. It seems to show
+a lack of understanding of the project as a whole if this is the only
+justification used.
+
+Sure better h/w will help boot times and I certainly want them myself,
+but it doesn't mean I don't want systemd. I want proper process
+supervision, I want logging all the way from early boot, I want
+information about why a service failed and I want to be able to track
+when binaries are launched from webservices and run away (either
+malicious due to a breach or just bad programming), and I want to
+properly unmount / and deactivate LVM on shutdown and reboot. I cannot
+do any of this with sysvinit but systemd means I can do all of that and
+more.
+
+>> If you have constructive criticism as to the reasons why this is now
+>> warned about specifically in systemd, then this is perfectly valid but
+>> should be done in context rather than simply calling it "idiotic"
+>> without any further clarification.
+>>
+> 
+> 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.
+
+>> And systemd is not saying that /usr cannot be on a separate partition.
+>> It's just saying that it cannot realistically be the job of the init
+>> system to mount it, it has to be handled at early boot in the initramfs,
+>> not by init. The reasons why this is the case are documented very
+>> clearly.
+> 
+> So by this reasoning we should stuff everything we can into initramfs,
+> and not care of partitioning / mount points at all.
+
+No, it means we have to stuff what is needed to mount /usr into initramfs.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited http://www.tribalogic.net/
+Open Source:
+  Mageia Contributor http://www.mageia.org/
+  PulseAudio Hacker http://www.pulseaudio.org/
+  Trac Hacker http://trac.edgewall.org/
+