linux-m68k.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: Stan Johnson <userm57@yahoo.com>
Cc: Michael Schmitz <schmitzmic@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	 linux-m68k <linux-m68k@vger.kernel.org>,
	debian-68k <debian-68k@lists.debian.org>,
	James Le Cuirot	 <chewi@aura-online.co.uk>,
	Sam James <sam@gentoo.org>,
	Geert Uytterhoeven	 <geert@linux-m68k.org>,
	Andreas Schwab <schwab@linux-m68k.org>,
	Thorsten Glaser	 <tg@mirbsd.de>,
	Finn Thain <fthain@linux-m68k.org>
Subject: Re: Plan needed for switching m68k to 32-bit alignment
Date: Wed, 13 Nov 2024 22:01:02 +0100	[thread overview]
Message-ID: <f5dd33186498e9ade40b5ffca45d8fabf04a3ec9.camel@physik.fu-berlin.de> (raw)
In-Reply-To: <a8611762-5539-d6c7-8d99-2fdaa6a1caef@yahoo.com>

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

  reply	other threads:[~2024-11-13 21:01 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25  6:48 Plan needed for switching m68k to 32-bit alignment John Paul Adrian Glaubitz
2024-10-25  9:06 ` Finn Thain
2024-10-25  9:18   ` John Paul Adrian Glaubitz
2024-10-26  7:31     ` Finn Thain
2024-10-26 22:04       ` Thorsten Glaser
2024-10-27  2:49         ` Finn Thain
2024-10-27  3:08           ` Thorsten Glaser
2024-10-27  3:47             ` Finn Thain
2024-10-27  4:23               ` Thorsten Glaser
2024-10-27  6:16                 ` Finn Thain
2024-10-27 13:15                   ` Arnd Bergmann
2024-10-28  3:07                     ` Thorsten Glaser
2024-10-28  4:51                       ` Finn Thain
2024-10-28  8:09                         ` John Paul Adrian Glaubitz
2024-10-28  8:49                           ` Finn Thain
2024-11-13 12:53                             ` John Paul Adrian Glaubitz
2024-10-28  8:03                       ` John Paul Adrian Glaubitz
2024-10-28  8:44                         ` Finn Thain
2024-11-13 12:51                           ` John Paul Adrian Glaubitz
2024-10-28  7:58                     ` John Paul Adrian Glaubitz
2024-10-28  7:55                   ` John Paul Adrian Glaubitz
2024-11-14 16:29                   ` Geert Uytterhoeven
2024-11-15  0:24                     ` Finn Thain
2024-11-15  1:24                       ` Thorsten Glaser
2024-11-15  1:31                         ` Thorsten Glaser
2024-10-28  7:53               ` John Paul Adrian Glaubitz
2024-10-28  7:49             ` John Paul Adrian Glaubitz
2024-10-28  7:47           ` John Paul Adrian Glaubitz
2024-10-28  8:40             ` Finn Thain
2024-11-13 12:50               ` John Paul Adrian Glaubitz
2024-11-13 22:01                 ` Finn Thain
2024-10-28  7:43         ` John Paul Adrian Glaubitz
2024-10-28  7:40       ` John Paul Adrian Glaubitz
2024-10-28  8:29         ` Finn Thain
2024-11-13 12:47           ` John Paul Adrian Glaubitz
2024-11-13 22:52             ` Finn Thain
2024-10-25  9:55 ` Arnd Bergmann
2024-10-25 10:10   ` John Paul Adrian Glaubitz
2024-10-25 10:50     ` Arnd Bergmann
2024-10-25 15:07       ` Andreas Schwab
2024-10-28  7:24         ` John Paul Adrian Glaubitz
2024-10-25 21:38     ` Thorsten Glaser
2024-10-25 22:24       ` Andreas Schwab
2024-10-25 23:42         ` Thorsten Glaser
2024-10-27 13:03           ` Greg Ungerer
2024-10-27 12:58         ` Arnd Bergmann
2024-10-28  3:19           ` Thorsten Glaser
2024-10-28  3:54             ` Greg Ungerer
2024-10-28  7:57           ` John Paul Adrian Glaubitz
2024-10-28  7:30         ` John Paul Adrian Glaubitz
2024-10-26 10:46       ` Geert Uytterhoeven
2024-10-28  7:41         ` John Paul Adrian Glaubitz
2024-10-28  7:26       ` John Paul Adrian Glaubitz
2024-11-14 19:46       ` Geert Uytterhoeven
2024-11-14 22:13         ` Thorsten Glaser
2024-11-14 22:37           ` James Le Cuirot
2024-10-28 18:57   ` Michael Schmitz
2024-10-29  3:39     ` Finn Thain
2024-11-13 12:58       ` John Paul Adrian Glaubitz
2024-11-13 23:12         ` Finn Thain
2024-11-13 12:54     ` John Paul Adrian Glaubitz
2024-11-13 18:36       ` Michael Schmitz
2024-11-13 19:55         ` John Paul Adrian Glaubitz
2024-11-13 20:48           ` Stan Johnson
2024-11-13 21:01             ` John Paul Adrian Glaubitz [this message]
2024-11-14 18:07               ` Stan Johnson
2024-11-14 19:28                 ` Geert Uytterhoeven
2024-11-13 20:49           ` John Paul Adrian Glaubitz
2024-11-13 21:33           ` Thorsten Glaser
2024-11-13 23:34             ` Finn Thain
2024-11-14 19:32           ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f5dd33186498e9ade40b5ffca45d8fabf04a3ec9.camel@physik.fu-berlin.de \
    --to=glaubitz@physik.fu-berlin.de \
    --cc=arnd@arndb.de \
    --cc=chewi@aura-online.co.uk \
    --cc=debian-68k@lists.debian.org \
    --cc=fthain@linux-m68k.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=sam@gentoo.org \
    --cc=schmitzmic@gmail.com \
    --cc=schwab@linux-m68k.org \
    --cc=tg@mirbsd.de \
    --cc=userm57@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).