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://firstname.lastname@example.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.