On Wed, 2024-11-13 at 13:48 -0700, Stan Johnson wrote:
But we're not really suffering from bloat. On the contrary, both software
like systemd or Rust-compiled software actually use less memory, not more.
Well, systemd is completely useless on every 68030 and 68040 Mac that I
own, even ones that have enough memory to run it (e.g. SE/30, IIfx and
Centris 650). It takes most of its time just telling me about all of the
things that are timing out. It fires off too many concurrrent processes
that overwhelm slow CPUs. Whenever systemd becomes a hard requirement in
Debian, I won't be using Debian at all (there are still GNU/Linux
distributions such as Gentoo that do not require systemd).
If you really do not want to use systemd and need something small, you can
just build yourself a chroot using Buildroot or Toybox.
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?
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?
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.
Ignoring such failures provokes data loss. That's *not* a good thing.
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?
https://lwn.net/Articles/786593/
What such hardware would benefit from is low memory optimized user
space. That's hard to do with Debian, as bloat appears to have crept
into the build dependencies chain (if I understand you correctly).
The build dependencies don't end up on the installed system. For example, if
Java code is used to generate documentation, the Java runtime won't have to
be installed on the target machine. But you still need a working OpenJDK
to be able to build such packages.
While Debian was the first Linux distribution to support m68k, these days
there are other options, maybe some better suited to low memory systems
(and I'd consider even 256 MB on Amiga 'low memory' ...).
Well, I'd consider 16 MiB to be "low memory" for 68030 Macs, but you are
the Debian m68k port maintainer so you can consider whatever you want to
be low memory. Hopefully the bloat (Linux kernel and applications) will
be minimized so that old Macs, such as 68030 PowerBooks and desktops
that can have no more than 36 MiB, will be able to continue running, not
just Amigas that have 256 MiB memory. If we're headed toward Linux
distributions that can only run well enough in QEMU or Aranym, what's
the point in having old systems at all?
First of all, you can still and will always be able to build yourself a tiny
chroot using Buildroot or Toybox. And, secondly, what's the point of running
the latest and greatest kernel on a system which can't make use of any modern
kernel features anyway?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
