Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

On 24.02.2014 18:33, Mark David Dumlao wrote:
> On Mon, Feb 24, 2014 at 9:42 PM, Yuri K. Shatroff <yks-uno@××××××.ru> wrote:
>>
>>
>> 24.02.2014 16:39, Mark David Dumlao пишет:
>>
>>> On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff <yks-uno@××××××.ru>
>>> wrote:
>>>>
>>>> 24.02.2014 02:32, Alan McKinnon wrote:
>>>>>
>>>>> [1] For lack of a better term, let's just call systemd here a "system
>>>>> controller". What is this ONE thing a system controller should do and do
>>>>> it well?
>>>>
>>>>
>>>>
>>>> An init daemon generally does one thing well.
>>>
>>>
>>> it's obvious you haven't thought this through.
>>>
>>> consider, for a moment, that the "one thing well" that an init daemon
>>> is supposed to do is
>>> "run programs that do arbitrary things to get the system to an arbitrary
>>> state".
>>>
>>> do you not see a problem?
>>
>>
>> No. As you say, ``an init daemon is supposed to do is "run programs``, until
>> here you're right, but then you start talking about things the init doesn't
>> do but the programs do. In your wording, an init daemon is also a DBMS, an
>> MTA, a network startup daemon, a firewall, a getty and whatever program runs
>> on the system.
>
> Let's try to talk you through to a soft landing here.
>
> When we say init, are we just referring to pid 1, or are we referring
> to something
> else entirely?

Sorry but I think I was quite clear:
 >>>> An init daemon generally does one thing well.
Following a "Unix way" design, Everything else should be done by 
something else.

> OpenRC is often spoken of in the same breath as systemd, as if they were
> the same kind of thing. That sounds fair but think about it for a second:

Sorry but did I mention OpenRC?

> openrc - as most people talk about it - isn't even pid 1. as most people
> talk about it, openrc includes the functions.sh, the net.eth0 scripts,
> the script
> for starting your /sys, /proc, mounting local and network filesystems, setting
> the hostname and so on.

Obviously. That is why OpenRC *can* be treated as a "Unix way" thing, 
because the whole bunch are pretty interchangeable, independent and do 
their own things well, don't they?

> They may be written in a different language from pid1, but when people
> talk about
> openrc, they are talking about that whole ball of wax. From a systems
> perspective - they're parts of the same thing.
>
> Even discounting the parts that you think are ridiculous, like databases and
> loggers, there are clearly more parts in there above than can be cleanly defined
> as "one thing".
>
> Who gets to decide which is the "one thing" or not? You? Don't you rely on
> openrc to set your hostname? Load your kernel modules? Run your sysctl?
> Set any miscellaneous options in /sys? Mount your filesystems?
>
> Go ahead, define for everyone, once and for all, what this "one thing" is.
 >
> Does this one thing init include  a subsystem for reading separate
> environment files per-service? Isn't this just feature creep? Can't you just
> edit the init scripts to add those in? I mean, they are already
> scripts after all.
> And they're in /etc, they're meant to be configured.

Sorry, do you mean *everything* in /etc/ is to be configured? That's a 
convention to put the init stuff in /etc/. You could as well put it in 
/usr, /boot, wherever. In FreeBSD, the local init stuff resides in 
/usr/local/etc. In Solaris, elsewhere. In AIX, elsewhere. Why do you 
look at everything from a single linux's angle? Please note, I never say 
the 'linux way' but the "Unix way".
And you might also notice, an init system does not really much depend on 
the init daemon. It's pretty possible to run a SysV init daemon on a BSD 
system, or the opposite, because all the init daemon does is start some 
init scripts. Maybe /etc/rc, maybe /etc/init.d/* ...

> Does this one thing include service dependencies?

This depends on what one thing you want the init daemon to do. In e.g. 
FreeBSD, the dependencies are handled by /etc/rc.

 > Why sysv has gone for
> a LONG time without them, just a sequencing, and that works fine for almost
> all cases anyways. Isn't this just feature creep? Can't you just edit the init
> scripts to start any dependent services?
 >
> Point is - go look at any arbitrary feature that's part of your "init
> system" and
> you could cry to hell and high water that it's violating the "one
> thing", whatever
> that "one thing" is that doesn't seem to be defined.
>
> At least with systemd the parts are cleanly split off into separate executables.
> Yes, it's technically not needed for pid 1 to create tempfiles for
> other programs.
> That's why systemd-tmpfiles is its own tiny program, that does one "one thing"
> (create tempfiles for other programs) and nothing else. Yes, it's technically
> not needed for pid 1 to check your filesystems. That's why systemd-fsck is
> once again, a separate utility, that does "one thing" (run fsck) well. Yes,
> it's technically not needed for pid 1 to remount your filesystems readwrite.
> Again there's a separate utilty for that, that does nothing but just that.

Okay, but can I take them out and substitute mine own easily? How? Is 
there a well-defined standard? Is there a well-defined objective, a 
target at which the systemd software set will be considered stable 
'version 1.0'? I am asking again, if a bug is found in the systemd 
infrastructure, is it possible (i.e. how much effort it would take) to 
fix it temporarily on a running system?

> It's clear to me that there's an analogue between the different parts of a
> full openrc system - that just happen to be implemented in scripts - and
> the different parts of a systemd system - that just happen to be implemented
> in small binaries.
>
> Every time people complain about systemd having too many features,

I don't. Quite the opposite, I say, OpenRC has marginally less (if ever) 
features than systemd. Mentioned cgroups? The Wikipedia article about 
OpenRC states that it supports cgroups. Mentioned parallel startup? 
OpenRC supports it. Talked about `tail'ing last N log lines? I am quite 
sure that it would be a matter of minutes to get OpenRC to support this 
(assuming logs properly set up). And so on.

> they just _casually_ forget to mention that, for instance, their init actually
> asks them if they want to run interactive (why do that when you can specify
> from the boot loader?) or checks the configuration files of their daemons
> to see if they're valid and prompts the user to config if not. They just
> _casually_ fail to mention that their init has plugins for NetworkManager
> and ifplugd, that it comes with scripts for setting the consolefont.
> Meanwhile systemd does those same things, and it's bloated, theirs
> isn't.

I heard about 'the bloated stuff', too. I don't generally agree with it. 
But from what I see I conclude that systemd is bloating. It devours the 
environment, leaving the system with a set of tightly interconnected, 
hardly logical (IMO) but ultimately ambitious tools which are developing 
with priority of their number to their stability. The target feature set 
is not well-defined, and never will, as seen from the past issues - a 
permanent blatant feature creep.

> Oh you're going to say that that's not fair, it's external optional stuff,
> it's not _really_ part of openrc, but that's not intellectually honest is it?
> Heck, I could do that same. I could control my bootup process so that
> I run my own stuff instead of systemd-fsck, systemd-tmpfiles,
> systemd-mount and all that jazz and run plain old init scripts in their
> place.

No, really. What does systemd *add* what is missing and impossible to do 
with OpenRC?

> Why bother?

That's what I say. Why bother, if OpenRC already has almost everything 
you need. And what it doesn't, probably could be added with much less 
mess of writing a whole init system from the ground up and with much 
less transition cost and with much less hype about how cool the 
developers are to reinvent a Brand New Wheel. Could you advertise 
yourself more if you were just amending a SysV init system?
(Hell, and who did say that we are ranting here instead of writing code; 
what could have been SysV init like if those guys had written code for 
it? -- Ah no, it's probably even better that they didn't.)

> The reality is that - init scripts don't do just one thing, and don't even
> do it well.

The init scripts altogether don't do one thing, and I never said this. A 
single init script usually does. Why not always quite well? Because it 
depends not only on the script, but on the software itself. Do you claim 
a systemd unit file does the thing better than a shell script? No it 
just can't, I see many (if not most) of the unit files just issue commands.
The problem of the current SysV init system is that during its history 
there was a great number of different people writing different scripts 
in different styles as per their understanding of 'well'. But these 
could easily be conducted to a standard, actually e.g. FreeBSD has no 
problem with init scripts. Neither do I think OpenRC does.

In fact, by chance I'm here a 'sacrifice' because many things you (and 
other posters) attributed to me I either didn't say at all or said quite 
differently. ('Bloated systemd' is one example; comparing the whole 
systemd infrastructure to a single init daemon is another, etc.)

I didn't want to throw off systemd as a choice of a solution. (Yet I 
don't consider it *the* solution.) I was talking more about its 
unjustified hype and ambitions and indeterminate goals. While I do have 
some technical expertise, I surely don't have it enough to judge the 
design impartially. (Please respond anyone who claims he has.) And to be 
fair, I mostly didn't criticize the technical aspects of systemd about 
which I really care far less than about the `policy to conquer the world`.

I do respect the PoV of systemd's supporters as long as it solves their 
problems, but I personally don't have problems that only systemd could 
solve. My personal experience with it (though back in OpenSUSE 12.2-3), 
the opinions of my mates and the stuff I'm reading have already formed 
my point of view which says, systemd's claims are much of a soap bubble.

Well, at this point I'd rather really get back to my coding. Thanks 
everyone who bothered reading and answering.

-- 
Best wishes,
Yuri K. Shatroff