On 2022-10-25 15:15:43 +0200, Marco Moock wrote:
Am 25.10.2022 um 12:33:56 Uhr schrieb Retrograde:
Ancient hardware deserves ancient kernels, but cannot justify
consuming developers' valuable time
Linux boss Linus Torvalds has contemplated ending support for
the i486 processor architecture in the Linux kernel.
Most Linux distributions provide only support for i686, that was
the Pentium Pro.
For instance, Debian Jessie was the last version to support
i586. Given that I have several working (though not actually
used ATM) i586 boxes (Intel Pentium MMX- and AMD K6-based),
it prompted me to look into alternative systems to run there
if necessary. I've ended up choosing NetBSD, which both
supports 486DX and later hardware-wise, /and/ has a working
Linux devmapper implementation (I tend to rely heavily on
Linux LVM in my setups.)
So far, I've only used NetBSD on i686+, though, but I have
no reason to doubt that it would work on i586 just as well.
(Disappointingly enough, I've ran into an issue trying to
boot NetBSD HEAD kernel via Syslinux multiboot support,
http://gnats.netbsd.org/56935 . Worked fine with NetBSD 9.)
My concern isn't i486, however, but rather the ever diminishing
control that the user has over their own personal computing.
The first issue is the ever-increasing complexity of the
software. I can imagine an amateur contributor to the NetBSD
kernel. Feel free to provide counter-examples, but my
impression is that someone who contributes to Linux in near
every case does it as part of their full-time job (in essence
even if not in the name.)
The same could be said about either of modern Web browsers
(or perhaps 'engines' would be more accurate) out there.
Aside of the effort involved, there's the issue of education.
How many of computer users can afford, in both time and money
involved, the training necessary to read, and possibly tweak,
the source of the software they use on the day-to-day basis?
Leaving aside the technical issues, such as when the source
isn't available, or is obfuscated, or when even the binary
is not readily recoverable (such as in a 'Trusted Computing'
setup), there's software which the user isn't permitted to
modify /legally./ The one where you're /forbidden/ from
learning what went wrong, and making it right, whether on
your own, through the community effort, or by hiring an
(independent) professional programmer.
With those concerns in mind, I've ended up becoming somewhat
of a retrocomputing enthusiast, as such hardware is less
complex and /typically/ (though by no means universally) has
better support from free software.
Naturally, 'retro' setups favor simpler software; something
I can get involved with without becoming a full-time
programmer. Say, I use Lynx as my primary Web user agent for
over two decades now; about the only uses I have for Chromium
are online payments, and Javascript and CSS development.
I use a TWM variant or Openbox, depending on how featureful an
install I have at hand; I've toyed with Gnome and KDE c. 2000,
but saw absolutely no reason to use either for anything.
I write my HTML documents with Vim, and ensure well-formedness
with xml_pp(1). Turns out they could be opened with a
wordprocessor just as well, so when I'm asked for 'anything
Word,' I send HTML (+ CSS) instead, and it 'just works.'
When I need a PDF, I spawn Chromium, though. (Still, my HTML
documents tend to be regular enough that I can convert them
to Mom, as in $ groff -mom, and get a PDF that way instead.
I'm too invested into CSS to use that routinely, however.)
Incoming PDFs IME are readable with $ pdftotext | less more
often than not. (Otherwise, there's Zathura, though it has
heavier footprint than most of the X programs I use.)
Similarly, stripping XML tags off, say, a .docx document
tends to produce readable prose.
I rely on such tools as play(1) and mpg123(1) for music
(including HTTP radio), and I very rarely watch videos.
Aside of the aforementioned Chromium (and perhaps Zathura),
about the only 'heavyweight' programs I use are Darktable,
Kicad and command-line portions of Hugin et al. (I don't
have GLX in my setups, so Hugin proper isn't usable.) Pretty
much everything else should work on an i586 well enough.
... Granted, I use perhaps somewhat low a threshold and define
'retrocomputing' as the use of (general purpose) computers
produced ten years ago or more. The most recent x86-64 CPU
and mainboard I have (and use) I've bought back in 2012.
Those, as of this year, satisfy the condition.
The most recent non-x86 system I have is newer, however: it's
an Olinuxino SBC based on Allwinner A64 marked with '4617',
which I presume is the production date (i. e., ISO week and
year.) Though I hardly use it ATM, as I've ran into a couple
of issues with the Debian arm64 port.
(The oldest of my boxes is based on a 40 MHz Am386 CPU, which
I use mostly for running older software, such as DOS games,
though it has a number of FreeDOS packages installed as well,
such as versions of mTCP, Vim and Lynx.)
I cannot even imagine how it is possible to run a 486 with enough
RAM (256 MB) to boot the current kernel.
Thanks to Computer Nerd Kev for providing some data on
this, BTW.
--
FSF associate member #7257 np. 8086 by Master Boot Record
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)