On 11/13/24 12:55 PM, John Paul Adrian Glaubitz wrote:
On Thu, 2024-11-14 at 07:36 +1300, Michael Schmitz wrote:
I didn't say that - just supporting Arnd's point that much of the RAM
constrained old m68k software won't benefit from today's user space.
We're talking about an open source stack here. No one is going to run an
old binary from the 80s on a current system. And if you want to run old
software, you're certainly also not running the latest kernel.
Development isn't driven by memory pressure anymore, so code bloat is a
natural consequence.
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).
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. 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. Systemd even complains if I manually edit
/etc/fstab. 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 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.
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?
Again, the problem is not Debian-specific. Heck, it's not even Linux-specific.
Much as I appreciate Adrian's efforts to keep up with user space
development, I won't be in a position to help with an ABI change.
Thanks, I will then just do it myself with brute force or drop the port.
Sure, you do pretty much all the work on Debian/68k, so you get to decide.
If this involves changes at kernel level (syscall parameter alignment?)
however, my recommendation would be to rather drop the port than end up
with new kernels no longer backwards compatible with old user space.
Otherwise, I'd not even be in a position to do any kernel testing and
bugfixing (which often requires hardware, not emulators).
I don't buy this argument. Why would your world fall apart if we switch
alignment to 4 bytes. I seriously don't get it.
Adrian
