[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 21 Dec 2014 13:21:05 +0100
From: Piotr Meyer <aniou@...tek.pl>
To: owl-users@...ts.openwall.com
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"
Symptoms:
- 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 <http://skarnet.org/software/s6/why.html>. I assume
that Lennart has been made some studies about upstart/launchd and
sysvinit but nothing more.
See also: <http://0pointer.de/blog/projects/why.html>
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:
<https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg25287.html>
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": <http://0pointer.de/public/gnomeasia2014.pdf>
with, expected-to-be-in-future, own software management system:
<http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html>
(my opinion about this: see point "3").
Regards,
--
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.
