[Arm-netbook] A suggestion why Systemd may be bad

[John Luke Gibson]

I appreciate the explanation. My premise was based on the linux sucks
video sequel which argued that many people thought systemd was messy
because it wasn't minimalist enough.

If the code of the init system is not getting expanded by interweaving
component files, that leaves me curious what it is getting expanded
by. I presume that might be extra firmware for more support of more
hardware, but idk.

Anyways, I can see this topic is tiring so readers hereof need not
respond to this thread :P

On 2/15/17, Philip Hands <phil at hands.com> wrote:
> John Luke Gibson <eaterjolly at gmail.com> writes:
>
>> Perhaps it is the idea that a linux machine should be wholly modular
>> and attaching a library to a critical component of the system,
>> shouldn't be a viable strategy for popularizing one's work.
>>
>> When a distro is forced to carry a package due to a dependency of a
>> dependency, or any magnitude there of, it breaks a core separation of
>> power there. The users depend on distro's to provide reliable
>> packages, however if a package is intentionally interweaving files to
>> make these dependencies simply a part of the file and therefore
>> robbing the distro's the ability to choose a different dependency
>> should another developer or team thereof prove more reliable or more
>> suited for their distro.
>>
>> Systemd in this sense would be like microsoft robbing those wishing to
>> distinguish themselves of the ability by increasing the magnitude of
>> difficulty in doing so.
>>
>> Now, keep in mind, I am not fluent in any programming language and
>> have not audited Systemd, nor do I know anyone who has. This is based
>> on a compiled understanding of observations expressed in arguments
>> both infavor and against Systemd.
>
> Which is why it does not actually add anything, sadly.
>
> In Debian we've made sure that one can run without systemd (the init
> replacement) as init.  We actually have support for non-linux kernels,
> which therefore do not support systemd, which is not portable, so
> chances are that Debian will continue to support systems that do not
> have systemd as init.
>
> Under the umbrella of systemd (the project) one finds other separate
> components such as journald and loggind.  These are separate components
> that one could individually replace if there were viable alternatives.
> They are separate in the traditional unix-like, do one thing well style
> that people complain about systemd not following.
>
> One set of alternatives to these components used to be mostly provided
> by the various Kits, like ConsoleKit which does pretty much the same
> thing as loggind.
>
> These alternatives have mostly rotted on the vine since the systemd
> efforts turned up.  Blaming systemd for providing software that is
> better, to the extent that people switch away from the previously
> available components, does not strike me as overly reasonable.
>
> People that care about the lack of alternatives probably ought to start
> doing something about that, instead of complaining about it.
>
> It is not worthwhile to expect people that work on (or who prefer)
> systemd to also work on those alternatives that they do not use.
>
> As it happens, the Debian systemd folk went beyond the call of duty by
> coming up with the systemd-shim package, which makes it more easily
> possible to avoid systemd as init.  Understanably they are not
> particularly motivated to carry maintenance for that forever, and sadly
> nobody else seems moved to step forward.  So that package is currently
> orphaned, waiting for a maintainer to pick it up.
>
> Of course, once the likes of ConsoleKit have rotted, the modern desktops
> are left with little alternative but relying on logind to provide this
> functionality, at which point the popular distros end up with an
> implicit dependency on at least some components provided by the systemd
> project.
>
> That still is not a hard dependency on systemd-the-init-running-as-PID-1
>
> It is also not something that was forced on anyone.
>
> Most distros have decided that maintaining the option to run other inits
> is really not worth the effort, since there's not much benefit, and
> certainly it introduces bugs one didn't need to experience.
>
> I hope I've got that at least broadly right, since I'm neither a systemd
> enthusiast, nor a systemd hater.
>
> My own systems are generally set up to need me to run sudo mount rather
> than having ConsoleKit/logind determine that I'm logged in, and so can
> do that by clicking something, so I'm not really the target audience of
> GUI users that need all these extra components (which are part of
> systemd the project, but sod all to do with what I might run as init)
>
> Having people confuse systemd the project with systemd the init, and the
> running of the init as a normal user process with running it as PID1,
> and then insisting that getting rid of libsystemd0 is important for some
> reason, makes the water so muddy that anyone that's been paying attention
> to this subject for any time at all is _very_ bored by it by now.
>
> Can we stop please?
>
> Cheers, Phil.
> --
> |)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
> |-|  http://www.hands.com/    http://ftp.uk.debian.org/
> |(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY
>