[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Four people decided the fate of debian with systemd. Bad faith likely



On 2 March 2014 10:53:51 WET, Jack <jack@jackpot.uk.net> wrote:
>Systemd scares me. As far as I can see it does a lot of things right
>(in
>some cases these are things that no other contender does right); I'm
>not
>going to try to enumerate those things, that's been one elsewhere. But
>the way systemd has been designed, in particular the way it has borged
>dbus and syslog, is a real problem for me.
>
>I try to build systems that only run those daemons the system really
>needs. This is partly for security, and partly because I have several
>systems that are resource-challenged. Many of those systems have no
>GUI,
>and until now needed no dbus. I try to run nothing that depends on
>polkit or consolekit (it's a coincidence that those components are also
>Lennart's work).
>
>But the systemd approach is to use dbus for all IPC; and dbus is now
>part of systemd. Dbus is complicated; I don't begin to understand it.
>SystemD places dbus at the heart of PID1, and that IMO was a
>questionable technical decision.
>
>SystemD isn't just an init system; it also uses the CGROUPs kernel
>feature to manage user sessions. I don't understand why that
>functionality was incorporated into the init program. An init system,
>IMO, should restrict itself to bringing up services.
>
>I *really* don't want binary logs. I realise that I can make the new
>journald pass all log output to a text-based syslog daemon; but then
>I'm
>running a journald that I don't need.
>
>Similarly I have no need for a logind: even those of my systems that
>have a GUI are not multi-seat.
>
>If only systemd had been designed as a smorgasbord - a set of
>components
>designed to work in concert, but each being susceptible to being
>omitted
>in favour of its predecessor, then I would have been much less
>uncomfortable about it.
>
>I think it's great that Debian provides the only mainstream platform
>that supports The Hurd an kFreeBSD kernels, although I don't use them.
>The choice of systemd as a default init system will inevitably
>marginalise those kernels in Debian, which I think is sad.
>
>I do hope that those working on writing standalone components that
>implement the various systemd interfaces are successful (and soon). I
>will probably be sticking with Wheezy/SysV as long as possible, or
>until
>the prospects of those efforts becomes clear. I wish I had the chops to
>contribute to those projects - I believe they have the potential to
>match the strengths of systemd, while avoiding the birds-nest of
>dependencies that makes systemd seem such a heavy, take-it-or-leave-it
>deal.
>
>Of course, the CTTE's decision concerned the *default* init system for
>Jessie. Other init systems will continue to be packaged. So it's not an
>apocalypse.
>
>But systemd does *so much*, and so many other distros have decided to
>adopt it, that I fear that applications will come to rely on its
>features; the other init systems will be marginalised, and eventually
>wither. We will then all become dependent on Red Hat for a large part
>of
>our critical infrastructure. Red Hat is a billion-dollar commercial
>operation, with goals that are very different from Debian's. So I fear
>the CTTE's decision may in time come to harm the Debian project.
I am also only a Debian user and I don't know much about the matter, but if I understand correctly systemd is a drop in replacement for sysV, which has a lot more functionalities but works fine with sysV initscrits.

Wouldn't it be possible, in the future, to write a replacement to systemd which works fine with the systemd configuration, but that doesn't have most of those problems that systemd has?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Reply to: