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

[Andrew Savchenko <bircoph@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4944 bytes --]

On Mon, 17 Feb 2014 11:13:39 -0600 Canek Peláez Valdés wrote:
> > 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.

And here we have a small problem: for modules to be replaceable the
core system should be designed to support replaceable modules, but
systemd is not. The whole deep integration approach and lack of
inter-module boundaries doesn't allow one to write replaceable blocks
without crazy hacking.

Just imagine that one have PCI-E bus and this bug is being replaced
with some other PC-systemd bus, where one have to interface each
component differently. And if one removes e.g. audio card some other
seemingly independent component e.g. network controller becomes
broken. That is the nature of systemd and that is many people dislike
this technology.

> > 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.

The most sane and fair solution was already proposed: create a
systemd profile for those who need it. I personally highly dislike
systemd technology, but I respect the right of other to shoot them in
the leg (or head) as much as they want to. This is Gentoo: a universal
constructor providing people means to build any system in any shape
they need.

Unfortunately chances are that in future some software may become
unusable or unsupported outside of systemd profile. But patches may
be created and other profiles will continue to live the same way
hardened exists now and will continue to exist later.

BTW it was shown at the recent LVEE Winter 2014 conference that GDM
can be easily freed from systemd and OpenBSD guys have an interesting
idea for faking systemd presence for applications requesting one
mandatory. Though IMO any end-user application strictly dependable on
any init system is broken by design: for a daemon there should be no
difference by which tool it was started.

> > 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].

Excuse me please, but what you wrote above is very naive. All that
reasons are just an excuse. The real reason is money: systemd is a Red
Hat project (despite being formally open for everyone) and is their
tool^Wweapon to fight with Canonical for a sales market. It the last
years RH was pushed near even in a server market and now they are
fighting back. They were lucky enough to acquire Poettiring guy and
create from a simple and sound sysvinit (which is an important but
not dictating peace of software) a key component where they can
dictate their own line, where they can lead all Linux community in
a way they need.

That the real reason I despise systemd: in replaces the freedom of
choice by a dictatorship of a small bunch of managers of a single
corporation (yes, managers, not developers). And all this is under the
veil of GPL and technical merits. This is the poison in the well of
FOSS.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]