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

["Canek Peláez Valdés" <caneko@gmail.com>]

On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
[snip]
> Maybe it is 'full of errors', but is the primary point true?

False implies whatever you want it to imply. You can't prove anything
if your assumptions are incorrect.

>> There is actually little code inside PID 1;
>
>
> The quoted text said nothing about this, so please stay on point.

I was answering to someone else.

> As to the point raised:
>
>
>>> Can you surgically remove systemd in the future without reverse
>>> engineering
>>> half of what the LSB would look at the time, or will its developers
>>> ensure
>>> that this is a one time choice only?
>
>
>> You guys talk about software like if it was a big bad black magical
>> box with inexplicable powers.
>>
>> If someone is willing and able, *everything* can be "surgically
>> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank
>> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo,
>> and ESD. KDE got rid of aRts (and who knows what more).
>
>
> I think you are being a little disingenuous here.

I am not.

> The obvious unspoken meaning behind the 'can you surgically remove' was:
>
> Can you do it *easily*? I'm sure you would not suggest that getting rid of
> the above were 'easy'?

I've never said it was easy. I said it could be done by someone
willing and able. I repeated that like five times I think. I said it
was done before; I never said it was easy.

But it can be done, and that's a indisputable fact.

> It simply doesn't matter if systemd boils down to one monolithic binary, or
> 600, if they are tied together in such a way that they can not
> *individually* be replaced *easily and simply* (ie, without having to
> rewrite the whole of systemd).

You are setting a group of conditions that preemptively wants to stop
adoption of anything that is tightly integrated. That is a losing
strategy (different projects actually *want* tight integration), and
besides the burden of work should not fall on the people wanting to
use a tightly integrated stack.

You want individual modules that are "easily and simply" replaced?
Then WROTE THEM. Don't expect the systemd authors (or any other) to do
it for you.

> That said, it seems to me that, for now at least, it isn't that big a deal
> to switch back and forth between systemd and, for example, OpenRC.

It depends; right now you can't switch back and forth between OpenRC
and systemd without reemerging some stuff. Some of those packages
*could* be made to switch functionality at run time instead of compile
time, but SOMEONE has to write that support, and it's probably that
the upstream for the package will not accept those changes, since for
binary distributions it makes no sense to have the complexity on the
code of switching behavior at runtime when doing at compile time is
easier and the distribution generates one binary per architecture for
all its users.

> So my main concern is - will it still be possible - *and* easy - in a year?
> Three years? Five? If the answer to *any* of those is no, then I think the
> best solution - for gentoo at least - is to make whether or not systemd is
> to be used more like a *profile* choice - a decision that you can make at
> install time, similar to choosing between hardened or not (not easy/simple
> to switch to/from after a system is up and running).

That's how it works right now, because Gentoo developers *did* the
work. And the whole point of my "willing and able" mantra is to see if
someone here steps up into the plate.

It's *really* easy to say "oh, systemd should be provided by a profile
so the user is free to CHOICE if she wants to use it or not", but
*someone* has to write the necessary support so that the profile
actually exists. You want to be sure your choice is not "taken away"
from you? Join Gentoo and help to make that choice possible.

Don't expect that someone will do it for you.

There is a lengthy discussion in gentoo-dev about the problem with
understaffed arch teams. It's worth a reading, but the general
consensus is that the minor archs cannot be kept in stable if there
are not enough developers for said arch to do the testing.

It sucks? Of course it sucks; but there is no magical fairy that
automatically will keep working all the ebuilds for all the archs in
Gentoo. SOMEONE has to do the testing, someone has to triage bugs,
someone has to *fix* them.

If there is no one, then the arch cannot be kept in stable. And that's
a hard cold fact.

If *all* the Gentoo developers switched to systemd (highly unlikely),
then how could they support a separated profile for systemd? They
won't, and your "choice" will then be "taken away".

If the Gentoo developers decide that having systemd in a separated
profile is too much work (likely, even now), then what? More whining
from users because they "took away" their "choice"?

They could whine all they want, but if nobody steps up to the plate to
do the actual work, nobody (necessarily) will do it for them.

> In fact, it seems to me that, since (from what I've read) the primary reason
> that systemd was written in the first place was to provide extremely fast
> boots *in virtualized environments*,

You are wrong; systemd was created because Upstart had the silly CLA
from Canonical[1], and because its authors wanted a novel init system
for Linux (and Linux only) that used all the cool technologies the
kernel provides, and that it could solve problems like: how to easily
and consistently start daemons with well defined semantics for its
dependencies; how to easily and consistently apply resource quotas to
them; how to deal with modern computers where hardware comes and goes
(including CPUs) all the time, etc. [2].

> having it be a choice made by selecting
> a corresponding *profile* is the *ideal* solution - at least for gentoo. At
> least this way everything could be documented, and switching between a
> systemd and non-systemd profile can be supported for as long as possible,
> understanding that at some point in time it may have to become an install
> time choice - kind of like choosing between hardened or not is mostly an
> install time choice now.

That profile idea sounds even reasonable. But I don't think the devs
will implement it, since simple dependencies seems to work up until
now, and *someone* would need to write the profile, and *someone*
would need to test it, and *someone* would need to triage bugs for it,
and *someone* would need to fix them.

If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE
it would happen.

But don't complain if no one does, and it doesn't.

Regards.

[1] https://plus.google.com/u/0/+KaySievers/posts/C3chC26khpq
[2] http://0pointer.de/blog/projects/systemd.html
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México