Re: Plan needed for switching m68k to 32-bit alignment

[Stan Johnson <userm57@yahoo.com>]

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.