Hello!

On 2/28/21 5:10 PM, Mac User wrote:

After updating m68k Debian SID to the latest version in QEMU and copying the resulting
filesystem to a Centris 650, I noticed that I could telnet or ssh to the system, but the
console had the wrong keymap. This can be fixed by deleting /etc/rcS.d/S04keyboard-setup.sh,
or it can be renamed to /etc/rcS.d/s04keyboard-setup.sh, which is what I recommend for the
unsupported Debian SID installation on m68k, if possible.

The keymap should be correct for a freshly installed system as the keymap layout for 68k
Macs was switched from legacy to the new one [1].

Of course, the init scripts are only relevant for sysvinit. Please note that I'm not trying
to re-open a sysvinit vs. systemd discussion. Suffice it to say that I've found systemd to be
unusable on real m68k hardware (including a 25 MHz Centris 650 and a 40 MHz Mac IIfx). If systemd
works well enough for you, then that's great.

(...)

I do request that sysvinit continue to be available as a package in m68k Debian SID.

That's not really how it works, though. For the time being, the sysvinit package is maintained
both in Debian and upstream. But please be advised that if, at some point, the maintainers
decide to stop working on sysvinit, someone else needs to step up and take care of the
package.

I'm personally not interested in sysvinit and therefore I wouldn't be willing to maintain it. I'm
not preventing the sysvinit package to be build for any Debian Ports architecture, however. So as
long as sysvinit is being maintained in Debian, the package will be available on m68k.

On a side note, I've also noticed that "apt get update" and "apt get upgrade" are also too slow
to be usable on real hardware, implying that most people who want to use Debian SID on real
hardware must do their updates on an emulator, such as QEMU, and be comfortable copying filesystems
from QEMU to real hardware. Maybe that's to be expected with any modern operating system, but I think
it's also possible that the limitations of real hardware are not seen in faster emulators, so
developers are not as aware of, or concerned with, performance issues that are only noticeable
using real hardware.

It's pretty usable on my Amiga 4000 68060. A Centris 650 with just 25 MHz is a tad slow, of course.
But that doesn't mean that it represents all available real m68k hardware.

That said, as an experienced non-developer user, I appreciate all of the considerable effort that
everyone has put in to making modern GNU/Linux distributions work on old hardware. Thank you!

You're welcome.

Adrian

[1] https://salsa.debian.org/installer-team/console-setup/-/commit/eb883af8c9b4dbbdc3a7ecee89cc06600ac27584

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

After updating m68k Debian SID to the latest version in QEMU and copying the resulting filesystem to a Centris 650, I noticed that I could telnet or ssh to the system, but the console had the wrong keymap.  This can be fixed by deleting /etc/rcS.d/
S04keyboard-setup.sh, or it can be renamed to /etc/rcS.d/s04keyboard-setup.sh, which is what I recommend for the unsupported Debian SID installation on m68k, if possible.

Of course, the init scripts are only relevant for sysvinit.  Please note that I'm not trying to re-open a sysvinit vs. systemd discussion. Suffice it to say that I've found systemd to be unusable on real m68k hardware (including a 25 MHz Centris 650 and
a 40 MHz Mac IIfx).  If systemd works well enough for you, then that's great.  I do request that sysvinit continue to be available as a package in m68k Debian SID.

On a side note, I've also noticed that "apt get update" and "apt get upgrade" are also too slow to be usable on real hardware, implying that most people who want to use Debian SID on real hardware must do their updates on an emulator, such as QEMU, and
be comfortable copying filesystems from QEMU to real hardware.  Maybe that's to be expected with any modern operating system, but I think it's also possible that the limitations of real hardware are not seen in faster emulators, so developers are not as
aware of, or concerned with, performance issues that are only noticeable using real hardware.

That said, as an experienced non-developer user, I appreciate all of the considerable effort that everyone has put in to making modern GNU/Linux distributions work on old hardware.  Thank you!

-Stan Johnson


<html><head></head><body><div class="yahoo-style-wrap" style="font-family:courier new, courier, monaco, monospace, sans-serif;font-size:16px;"><div>Hello,<br><br>After updating m68k Debian SID to the latest version in QEMU and copying the resulting
filesystem to a Centris 650, I noticed that I could telnet or ssh to the system, but the console had the wrong keymap.&nbsp; This can be fixed by deleting /etc/rcS.d/S04keyboard-setup.sh, or it can be renamed to /etc/rcS.d/s04keyboard-setup.sh, which is
what I recommend for the unsupported Debian SID installation on m68k, if possible.<br><br>Of course, the init scripts are only relevant for sysvinit.&nbsp; Please note that I'm not trying to re-open a sysvinit vs. systemd discussion. Suffice it to say
that I've found systemd to be unusable on real m68k hardware (including a 25 MHz Centris 650 and a 40 MHz Mac IIfx).&nbsp; If systemd works well enough for you, then that's great.&nbsp; I do request that sysvinit continue to be available as a package in
m68k Debian SID.<br><br>On a side note, I've also noticed that "apt get update" and "apt get upgrade" are also too slow to be usable on real hardware, implying that most people who want to use Debian SID on real hardware must do their updates on an
emulator, such as QEMU, and be comfortable copying filesystems from QEMU to real hardware.&nbsp; Maybe that's to be expected with any modern operating system, but I think it's also possible that the limitations of real hardware are not seen in faster
emulators, so developers are not as aware of, or concerned with, performance issues that are only noticeable using real hardware.<br><br>That said, as an experienced non-developer user, I appreciate all of the considerable effort that everyone has put in
to making modern GNU/Linux distributions work on old hardware.&nbsp; Thank you!<br><br>-Stan Johnson<br><br></div></div></body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)