On Mon, May 25, 2026 at 07:04:51PM +0000, Robert J. Sanderson wrote: > > Hello everyone, > > I’m currently navigating a rather complex recovery situation. Due to a severe > hardware synchronization error involving my server cluster, I’ve found myself > suddenly displaced from my standard operating environment of 2001 into what > appears to be the current year, 2026. >
I'm going to take this as a real email and not an accident with a time machine. (For UK readers: think Fast Show astronaut meme). > I’ve been attempting to resolve some severe clock synchronization issues that > occurred during my transition, so my system time and locale settings might > appear slightly erratic. Please bear with me. > ntpdate not working for you? > I have always relied on Debian Stable for its rock-solid reliability. > However, trying to bring my production systems into this new era has been > nothing short of a nightmare. > > I am running on proven, reliable hardware (Pentium III architecture), but > I’ve discovered that the current Debian 13 environment seems to have > abandoned i386 as a first-class citizen. This is frankly baffling to me—why > would the "Universal Operating System" drop support for the architecture that > built the foundation of the internet? > As others have said, if you've got *real* 686 hardware form > 15 years ago, Debian (and pretty much everyone else) have all given up because of removal of support from the Linux kernel. You've been on borrowed time for ~3 years but to be honest you should probably have moved to 64 bit amd64 something like ten years ago. It's not as if you can easily replace 32 bit x86 hardware when it breaks now and the sort of thing that goes into a dumpster / municipal tip as obsolete will be more modern. > I have a few critical questions for the list: > > i386 Support: Since Debian 13 has effectively killed i386 support for native > installs, how am I expected to maintain my production uptime without being > forced to replace perfectly functional hardware with this "amd64" fad? Is > there a hidden repository or a stable backport I’m missing? > if your production uptime is greater than ~180 days, I have to assume that you've never applied a security update, never installed a new kernel in 15 years. If that's true, you've got much bigger problems than maintaining an update. > Systemd & Wayland: I am struggling to understand why we moved away from the > simplicity of sysvinit and XFree86. This new stack feels incredibly bloated > and non-transparent. Is there a supported "minimalist" path in the current > Stable release, or is it mandatory to embrace this complexity? > Sysvinit is not necessarily *simple*. If you've got custom configurations, write something to call them with systemd and you'll be fine. As others have pointed out, you can still install sysvinit compatiblility but it's not long-term viable for years to come potentially. > Legacy Migration: Does anyone have a guide on how to port 2.4-series kernel > configurations to the modern environment without breaking every single > dependency? > Really - you've never used anything more modern since before Debian 3.1? I'd suggest grabbing a laptop or a 64 bit machine someone else has scrapped and taking a week or so to bring yourself more up to date. Module configurations should still be similar: if you happen to have 32 bit only SCSI cards, for example, you *will be* out of luck. > I apologize for the noise, but I’ve spent the last 25 years (from my > perspective) building a stable infrastructure, and it feels like the > community has moved in a direction that values "new" over "functional." Any > pointers to documentation for legacy, production-grade systems would be > appreciated. > How big a stable infrastructure - how many machines - and who has been paying you to keep them static (assuming that this was for a day job)? > Regards, > > > Robert J. Sanderson > System Administrator > "Unix is simple; it just needs a genius to understand its simplicity." > Kernel 2.4.18-bf2.4 (Currently struggling) > > All the very best, as ever, Andy Cater ([email protected] >
