On 24.02.2014 18:33, Mark David Dumlao wrote:
On Mon, Feb 24, 2014 at 9:42 PM, Yuri K. Shatroff <yks-...@yandex.ru> wrote:
24.02.2014 16:39, Mark David Dumlao пишет:
On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff <yks-...@yandex.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
