[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/