| 1 |
On Mon, 17 Feb 2014 11:13:39 -0600 Canek Peláez Valdés wrote: |
| 2 |
> > It simply doesn't matter if systemd boils down to one monolithic binary, or |
| 3 |
> > 600, if they are tied together in such a way that they can not |
| 4 |
> > *individually* be replaced *easily and simply* (ie, without having to |
| 5 |
> > rewrite the whole of systemd). |
| 6 |
> |
| 7 |
> You are setting a group of conditions that preemptively wants to stop |
| 8 |
> adoption of anything that is tightly integrated. That is a losing |
| 9 |
> strategy (different projects actually *want* tight integration), and |
| 10 |
> besides the burden of work should not fall on the people wanting to |
| 11 |
> use a tightly integrated stack. |
| 12 |
> |
| 13 |
> You want individual modules that are "easily and simply" replaced? |
| 14 |
> Then WROTE THEM. Don't expect the systemd authors (or any other) to do |
| 15 |
> it for you. |
| 16 |
|
| 17 |
And here we have a small problem: for modules to be replaceable the |
| 18 |
core system should be designed to support replaceable modules, but |
| 19 |
systemd is not. The whole deep integration approach and lack of |
| 20 |
inter-module boundaries doesn't allow one to write replaceable blocks |
| 21 |
without crazy hacking. |
| 22 |
|
| 23 |
Just imagine that one have PCI-E bus and this bug is being replaced |
| 24 |
with some other PC-systemd bus, where one have to interface each |
| 25 |
component differently. And if one removes e.g. audio card some other |
| 26 |
seemingly independent component e.g. network controller becomes |
| 27 |
broken. That is the nature of systemd and that is many people dislike |
| 28 |
this technology. |
| 29 |
|
| 30 |
> > That said, it seems to me that, for now at least, it isn't that big a deal |
| 31 |
> > to switch back and forth between systemd and, for example, OpenRC. |
| 32 |
> |
| 33 |
> It depends; right now you can't switch back and forth between OpenRC |
| 34 |
> and systemd without reemerging some stuff. Some of those packages |
| 35 |
> *could* be made to switch functionality at run time instead of compile |
| 36 |
> time, but SOMEONE has to write that support, and it's probably that |
| 37 |
> the upstream for the package will not accept those changes, since for |
| 38 |
> binary distributions it makes no sense to have the complexity on the |
| 39 |
> code of switching behavior at runtime when doing at compile time is |
| 40 |
> easier and the distribution generates one binary per architecture for |
| 41 |
> all its users. |
| 42 |
|
| 43 |
The most sane and fair solution was already proposed: create a |
| 44 |
systemd profile for those who need it. I personally highly dislike |
| 45 |
systemd technology, but I respect the right of other to shoot them in |
| 46 |
the leg (or head) as much as they want to. This is Gentoo: a universal |
| 47 |
constructor providing people means to build any system in any shape |
| 48 |
they need. |
| 49 |
|
| 50 |
Unfortunately chances are that in future some software may become |
| 51 |
unusable or unsupported outside of systemd profile. But patches may |
| 52 |
be created and other profiles will continue to live the same way |
| 53 |
hardened exists now and will continue to exist later. |
| 54 |
|
| 55 |
BTW it was shown at the recent LVEE Winter 2014 conference that GDM |
| 56 |
can be easily freed from systemd and OpenBSD guys have an interesting |
| 57 |
idea for faking systemd presence for applications requesting one |
| 58 |
mandatory. Though IMO any end-user application strictly dependable on |
| 59 |
any init system is broken by design: for a daemon there should be no |
| 60 |
difference by which tool it was started. |
| 61 |
|
| 62 |
> > In fact, it seems to me that, since (from what I've read) the primary reason |
| 63 |
> > that systemd was written in the first place was to provide extremely fast |
| 64 |
> > boots *in virtualized environments*, |
| 65 |
> |
| 66 |
> You are wrong; systemd was created because Upstart had the silly CLA |
| 67 |
> from Canonical[1], and because its authors wanted a novel init system |
| 68 |
> for Linux (and Linux only) that used all the cool technologies the |
| 69 |
> kernel provides, and that it could solve problems like: how to easily |
| 70 |
> and consistently start daemons with well defined semantics for its |
| 71 |
> dependencies; how to easily and consistently apply resource quotas to |
| 72 |
> them; how to deal with modern computers where hardware comes and goes |
| 73 |
> (including CPUs) all the time, etc. [2]. |
| 74 |
|
| 75 |
Excuse me please, but what you wrote above is very naive. All that |
| 76 |
reasons are just an excuse. The real reason is money: systemd is a Red |
| 77 |
Hat project (despite being formally open for everyone) and is their |
| 78 |
tool^Wweapon to fight with Canonical for a sales market. It the last |
| 79 |
years RH was pushed near even in a server market and now they are |
| 80 |
fighting back. They were lucky enough to acquire Poettiring guy and |
| 81 |
create from a simple and sound sysvinit (which is an important but |
| 82 |
not dictating peace of software) a key component where they can |
| 83 |
dictate their own line, where they can lead all Linux community in |
| 84 |
a way they need. |
| 85 |
|
| 86 |
That the real reason I despise systemd: in replaces the freedom of |
| 87 |
choice by a dictatorship of a small bunch of managers of a single |
| 88 |
corporation (yes, managers, not developers). And all this is under the |
| 89 |
veil of GPL and technical merits. This is the poison in the well of |
| 90 |
FOSS. |
| 91 |
|
| 92 |
Best regards, |
| 93 |
Andrew Savchenko |
Archives