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 >
