appiah4 wrote on 2026-08-11, 19:57:

I am genuinely not sure what you think I meant as well as what you want me to explain, but I will bite.

I put it like that because your words read as if the situation I perceive as a major problem with every-year-less-gnu/linux seems to be of little significance to you. If I read you correctly, I must be missing something and therefore would appreciate your perspective, so thank you for responding.

From my perspective, the problem field is not static. I watched this systemd cancer grow for more than a decade and every next year the situation is worse, not better. I know I can gentoo it, but before I stoop there I would rather give openbsd a try and see for myself what I have been missing out on all these years.

Even slackware 15 is not totally systemd-free any more…

I use i3 wm straight from xinit - don’t care what gnome and kde do with regards to systemd. I am simply mulling on a strategy to be systemd free in a sustainable way that does not have a near-future expiry date. Again.

At present I can still cobble up a “functional” box - my major concern is that the direction we are going in, is from bad to worse. This is not sustainable. I do not want to reserve mental bandwidth for nonsense like this all the time.

The water is getting too hot to be comfortable and I am not a frog.

That’s my position at least.

cyclone3d wrote on Yesterday, 03:39:

That and it is dumb to try and keep supporting stuff that old on newer OSes. I am surprised it wasn't dropped long ago.

And that's not really a pressing issue, because Kernel 6.12 in some shape will be supported until 2034-2035, supposedly: https://cip-project.org/blog/2025/01/13/kerne … problems-solved
I think putting at that point 35-40 years old hardware finally out of support is more than reasonable.

What can anyone realistically run on a 486 with a modern kernel?

myne wrote on Today, 04:13:

What can anyone realistically run on a 486 with a modern kernel?

ssh with modern NetBSD still works, with transfer rates in the tens of kilobytes range (maybe a little faster on DX4 and Am5x86) with modern cryptography, on a 32MB 486 machine.
The same should be possible on Linux, but unlike NetBSD where you can get away with just a custom kernel, it's going to require either running a niche distro that is compiled for i486, or rolling your own. So I think the limited energy toward supporting i486 would be better to have concentrated in one place and that's NetBSD (or arguably FreeDOS).

So, realistically: nothing useful.

I have argued 2 points elsewhere.

1) I expect a line in the sand to be drawn at some point, and either the kernel splits out old junk into a separate OPTIONAL HAL-like complimentary branch, or it just drops it. I expect the line to probably be (in x86 space) something like: X64 only, UEFI only, PCIE only. Given that BIOS and ISA (via LPC) clung on to around around Broadwell era, that puts that line around Skylake. Not to say there aren't exceptions in both directions. Dumping or splitting all that off will reduce the x86 support list massively. There have been only 2 chipsets and their mildly tweaked derivatives since then. There's only HDA sound. There's only 3 GPUs albeit if you look at the instructions/compatibility it's probably closer to 10 but they're bundled in the same 3 drivers anyway. There's only what.. maybe 10 ethernet chipsets. 1 ESPI driver. ~2 superios. All in all, probably under 100 drivers.

2) People are focusing on the loss of support for literally ancient x86s while ignoring the billions of relatively new, and certainly functional ARM Androids that cannot upgrade because Linux's kernel doesn't have an MS style versioned driver model interface like WDM/NDIS AND manufacturers don't care to recompile proprietary blobs for shit that doesn't make them money. I fully expect a massive botnet of not-that-old phones to force this issue to be a priority at some point. You can't force the manufacturers to fix it, but you can give Linux a stable versioned HAL interface that allows old blobs to work with new kernels.

myne wrote on Today, 05:00:

1) I expect a line in the sand to be drawn at some point, and either the kernel splits out old junk into a separate OPTIONAL HAL-like complimentary branch, or it just drops it. I expect the line to probably be (in x86 space) something like: X64 only, UEFI only, PCIE only. Given that BIOS and ISA (via LPC) clung on to around around Broadwell era, that puts that line around Skylake. Not to say there aren't exceptions in both directions. Dumping or splitting all that off will reduce the x86 support list massively. There have been only 2 chipsets and their mildly tweaked derivatives since then. There's only HDA sound. There's only 3 GPUs albeit if you look at the instructions/compatibility it's probably closer to 10 but they're bundled in the same 3 drivers anyway. There's only what.. maybe 10 ethernet chipsets. 1 ESPI driver. ~2 superios. All in all, probably under 100 drivers.

But it's ridiculous for m68k to stay in the code base even if obscure and Socket AM3+ (some of those lack UEFI) to get rm -rf. I think a lot of this problem is that the entire "x86" architecture (32- and 64-bit) is a single port from the kernel's perspective, so i586 support for example bothers the maintainers in a way that m68k doesn't, because it's cordoned off in a separate directory where they don't have to deal with the #ifdefs, errata workarounds, etc.

myne wrote on Today, 05:00:

2) People are focusing on the loss of support for literally ancient x86s while ignoring the billions of relatively new, and certainly functional ARM Androids that cannot upgrade because Linux's kernel doesn't have an MS style versioned driver model interface like WDM/NDIS AND manufacturers don't care to recompile proprietary blobs for shit that doesn't make them money. I fully expect a massive botnet of not-that-old phones to force this issue to be a priority at some point. You can't force the manufacturers to fix it, but you can give Linux a stable versioned HAL interface that allows old blobs to work with new kernels.

I was going to make this point earlier and you have made it better. Traditionally the answer to those unhappy with there not being a stable driver ABI was to open source your driver and upstream it to be in-tree in the kernel. That way, when the kernel maintainers broke the ABI, they would fix the driver for you. This model is broken if they are going to keep purging things that "nobody uses."

jakethompson1 wrote on Today, 05:27:

But it's ridiculous for m68k to stay in the code base even if obscure and Socket AM3+ (some of those lack UEFI) to get rm -rf. I think a lot of this problem is that the entire "x86" architecture (32- and 64-bit) is a single port from the kernel's perspective, so i586 support for example bothers the maintainers in a way that m68k doesn't, because it's cordoned off in a separate directory where they don't have to deal with the #ifdefs, errata workarounds, etc.

I don't make the rules. I just try to predict the most logical future.
BIOS support leaves a lot of potential attack surface.
ISA support in any way shape or form including LPC leaves huge piles of hardware technically possible to plug in (Via DISAppointment), and people will probably bitch about it not working.
PCI is far less of an issue since it is software identical to PCIE, but dropping it does automatically exclude all AGP and PCI cards, chipsets, and clunky bridges and pulls the entire mainline tree into "modern x64".

jakethompson1 wrote on Today, 05:27:

I was going to make this point earlier and you have made it better. Traditionally the answer to those unhappy with there not being a stable driver ABI was to open source your driver and upstream it to be in-tree in the kernel. That way, when the kernel maintainers broke the ABI, they would fix the driver for you. This model is broken if they are going to keep purging things that "nobody uses."

It's a serious issue. I get that Linus is philosophically opposed to microkernels, but the cold hard reality is they have flexibility that monolithic doesn't.
I wouldn't expect a full "HALification", but more like the Windows NDIS model where for example it's theoretically possible for MS to recompile win11 with NDIS 5 support and 98/2k network card drivers would work. I would expect it to have a series of enableable/disableable "HALs" set at various Kernel version milestones. This would be huge for the "old android" community.
Weirdly people care less about $300-1000 linux devices they literally carried everywhere for years on end than the PC they most likely never used Linux on in the first place from 30 years ago.

BIOS drop off is very unlikely in any foreseeable future. And It doesn't make much difference compared to some early unpatched UEFI full of security holes anyway.
Not sure why would Linux suddenly drop the whole industry standard interface as a whole, even ISA. AGP specifically? Sure, it would still work as a glorified PCI slot. Although still unlikely, because it's not as obscure as VLB.

If a line is going to be drawn, and I think it's likely, it will come down to making a good argument to keep it.