On 11/13/24 2:01 PM, John Paul Adrian Glaubitz wrote:
SysVInit uses a huge set of bash scripts where every action involves
spawning
a new shell while systemd does all of that in C. Compiled C code is definitely
faster on an m68k machine than hundreds of shell scripts.
Yes, compiled C code is faster than an equivalent script, but scripts
are much easier (for some of us) to edit and turn on and off than
systemd components.
systemctl disable foo.service is too hard?
Yes, it's too hard. And if I want to change something in foo.service
instead of disabling it, I'm sure there's a way to do that in systemd as
well, but using vi (or nano) to edit the equivalent sysvinit script is
easier for some of us. Also, if fubar.service is completely messed up,
then I might not be able to boot into the operating system that is
running systemd in order to use systemctl (especially on a slow system).
But if I'm using sysvinit scripts, I can boot a rescue CD, or Gentoo, or
whatever else I might have installed, mount the relevant root
filesystem, then disable the sysvinit script (delete it or change the
leading "S" to "s") or use a text editor to fix it.
Plus systemd has lots of components and does lots of things that arguably
an init system shouldn't even be doing, things that aren't needed at all
on old systems, such as managing logins, setting the time and managing DNS.
Old systems don't need user management or networking?
Yes, of course they do, but some users don't expect or want their init
system to perform those functions.
FWIW, these components can be turned off if you insist using a separate package
for each and every standard service that's part of the standard Linux userland.
You are not forced to use systemd components.
Systemd even complains if I manually edit /etc/fstab.
Which is a good thing. SysVInit systems would just silently fail when you added
an entry to /etc/fstab which didn't work properly so that you could end up with
something not being mounted where it should be or vice versa.
I'd probably see an error message in the log files or at boot time if I
added an incorrect entry to /etc/fstab. Some users don't want their init
system to be a nanny, especially on a slow system.
Ignoring such failures provokes data loss. That's *not* a good thing.
True enough. No one is suggesting ignoring misconfigurations; I'm just
suggesting that systemd isn't the right place to provide nanny services.
Perhaps there are ways to tune systemd for small systems,
but I haven't seen any distribution that does that. On small, static
systems that don't have USB, Firewire, PC-Cards, etc., udevd and
sometimes dbus aren't even needed, and systemd is certainly overkill for
such systems.
I'm using systemd on my Amiga and any other embedded system I have and it works.
I'm not trying to rehash old systemd/sysvinit discussions; I realize
that Debian has chosen systemd as its default init system. That's fine;
Debian can do whatever they want, but no one can tell me that systemd,
at least in the configuration as it is distributed by Debian, is better
than sysvinit for small, mostly static systems. That's why there are
entire distributions that are dedicated specifically to not forcing
their users to use systemd.
You mean "professional" distributions like Devuan?
Devuan is great, even if it's not as "professional" as Debian. If I
required a professional distribution, then I would pay for professional
support. As it is, Debian is probably converting more users to Devuan
than anyone else. I had to install Devuan on several Apple x86_64
systems because Debian keeps breaking X11 support by making systemd a
dependency (even if it's a temporary mistake, and I know you aren't
involved with x86_64). This is a hobby for many of us, and we don't need
the drama. Besides Devuan, Gentoo is also very good. So is Void, though
they recently removed support for everything except i386 and x86_64. And
of course there's always NetBSD, though it has some issues booting on
powerpc.
