On Mon, Apr 06, 2015 at 09:38:06AM +0100, KatolaZ wrote:
> What really puzzles me is why if you love systemd that much you just
> continue arguing about systemd on the ML of a Debian fork specifically
> born to throw systemd away. Do you think you might be able to convince
> us that systemd is *good* and *beautiful* and *necessary*? I don't
> want to be saved, thanks ;)

All I see T.J. saying is that systemd (1) implements some good ideas
and (2) has done so in a way that is flawed in *certain* aspects,
but (3) not in *other* aspects.

And I suppose I agree with that.


An init system that can collect *all* the descendents of a service is
a nice concept.
So is having a dependency-based boot that can respond to events,
without treating "this dependency became available" as an event
in its own right.
And I suppose that knowing when service x becomes available, and
when it goes away, can be nice...as is knowing that service x will
keep running until the sysadmin stops it.

But does that entail a release schedule such that the version number
has increased by nearly 200 in 5 years, or a library to interface with
that same package?
Does it call for writing a new service to handle fdisk, another one to
handle networking, another to handle the boot splash, and so on?
Why should an init system implement an SNTP daemon, or its own
DNS server, and what excuse is there for reinventing cache poisoning?

I've heard comments about systemd being spaghetti-code.
No, it's not: it's spaghetti-architecture, but the bits and pieces looked
fairly clear. I *wish* busybox were that well-written.
It's what they require and how they're combined that's problematic.

I use musl libc on many of my installs, because I like having a libc
that's simple to read, to enhance, to fix, to build, and to install,
and that respects the bounds of its scope and keeps code and binary
size down.
systemd doesn't complement that, because it's an *boot* system that
takes half a million lines of code to cover "booting the system".
Note that I didn't call it an *init* system, because that is
obviously not the scope that they accept.
It doesn't work with musl, in small part because they decided to
require secure_getenv() which is synonymous with
if (issetugid()) getenv(var);
but also because of extensive reliance on "how glibc does it"--
which may actually be undefined or nonstandard behavior that could
change (for examples, note the flash breakage thanks to the memcpy()
rewrite, and check the history of glibc getenv()).
When people have enquired about making it work with uclibc, the
developers responded with something that sounded a lot like
"maybe, *if* it's not much different and you do the work".

It requires util-linux and its libraries, and libkmod, and its own
device manager, and libraries for crypto and compression, and it
tries to provide a boot manager that's worthless for me (I use
BIOS-based systems).
Here, I use toybox/busybox because it covers all the functionality
needed to boot and use a command-line Linux system; xz rather than
lzma is my preferred compression tool; and I use grub4dos, currently
the chenall fork, as a bootloader because I understand grub1, it can
boot from NTFS, it can easily be set up from Windows, and it can boot
FreeDOS.

So my objection to systemd mostly comes down to this question:
why should I have *any* interest in a project that averages ~3 releases
a month to add features I don't want, that depends on packages I don't
use, and would expect *me* to support *their* design?
I have things I'd rather be working on than understanding half a
million lines of boot system, and I can build one that I understand
and that meets my own needs in under a thousand.

Thanks,
Isaac Dunham