Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 21 Dec 2014 13:21:05 +0100
From: Piotr Meyer <>
Subject: Re: owl-startup

On Sun, Dec 21, 2014 at 07:39:10AM +0300, (GalaxyMaster) wrote:
> do my job properly I had to learn the design of that framework and it
> really looks logical and once you jump through the hoops of the learning
> curve you cannot deny that Poettering and Co did a huge amount of work
> to standardise the startup & init process.  The documentation is also
> _very_ good.

I'm not a Owl developer but as a person very interested in systemd
development history and whole integration process I strongly disagree
with your opinion. Yes, of course - at first and second look whole
concept looks promising and well considered - but digging around 
project history and corner cases reveals narrow horizons of systemd
developers, lack of experience in system administration area and
pitiful lack of vision in whole project.

To make a very long story shorter  there are some things to consider
and to use as starting points to research.

1. General rule: "Unified abstraction layer makes things what doesn't
   fit well in new rules problematic and forces developers to ignore
   them, bash them or to add large amount of exceptions and workarounds"

   - re-introducing shell scripts, "bashed" at project start
   - re-introducing them in large bunch of extra commands:
     "ExecStart", "ExecStartPre", "ExecStartPost" etc.
   - introducing large number of configuration options (at this moment 
     about 260 and still counting) due to needs to cover cases, 
     previously missed from devs radar.

2. Lack of homework: in opposite to Lennart's statements I never saw
   something like <>. I assume
   that Lennart has been made some studies about upstart/launchd and
   sysvinit but nothing more. 
   See also: <>

3. Lack of sysadmin experience:
   - "uninterpretable fsck" as typical example
   - bonding to specific, very new kernel (systemd devs doesn't grok 
     very well cases when older or custom kernel must be used - to be
     honest, kernel development, especially maintaning older version
     with systemd should be funny)
   - security problems. See: "resolver case" - reintroducing classic
     bugs (cache poisoning) into simply daemon and crashing on invalid 
     data from net:
     Yes, of course, "resolver is optional".
   - neglecting fragility of such a complicated system ("kernel is
     also complicated" or "when you delete glibc then even sysvinit
     will be dead"). 
     Symptoms already can be found in bug reports like "my systems 
     is bricked after last update".
   - socket activation as something non-profitable in server environment 
     (in opposite to dev's claims): where is declared memory profit
     in monitoring environment or how to use socket activation in slave
     mysql server instance?
   - service dependencies as something non-profitable in server
     environments: there is no possibility to create reliable
     dependencies between - for example - php interpreter, web server
     and mysql database. Especially in multi-host environment. 

4. Lack of vision: supervision system bounded to single host in era 
   "internet of things", ephemeral cloud setups and multi-node clusters? 
   Shameful and disappointed. Yes, I'm aware that creating multinode 
   dependencies system is non-trivial task, but scale of revolution that 
   comes with systemd don't justify small on non-existent benefits.

   As side note - knowledge already exists - in areas that covers 
   replication of data between multiple db hosts or supervised, 
   distributed systems like Erlang ones. I work with them a little
   and I have simple distributed message broker in my portfolio,
   so I'm not write about pure speculations here (although I'm far
   from calling myself "expert" in this area).
And - as final word - systemd is NOT a init or supervision system. It
is, according to Lennart's words: "a platform": <>
with, expected-to-be-in-future, own software management system:
(my opinion about this: see point "3").

Piotr 'aniou' Meyer

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.