Debian 'Bullseye' enters final phase before release as team debates whether it will be last to work on i386 architecture Debian 11, codenamed "Bullseye", has entered the first freeze stage, meaning no large or disruptive changes, or new package transitions (merging, splitting, renaming or removing) are allowed. The 32-bit i386 architecture is part of the release but may not be in Debian 12, codenamed "Bookworm". The Debian project comes up with …
The release team also suggested a change in approach. Up until now, Debian has assessed support for the various architectures fairly late on in the cycle. This is possibly too late: the suggestion now is to assess this just as a major release happens in the planning for the next release. So if Debian Bullseye - which will be Debian 11 - has just started the process of slowing changes, to soft/hard/ freeze, to release - it's a little late to suddenly drop an architecture.
Any support will need to be for five years or so - three years in full support, two in LTS - and discussions round the issue showed that's hard, though it did produce interesting information about who had what hardware still running / who would care if it ceased at this point. It threw up people willing to test i386 at the moment but not necessarily anyone extra willing to commit to long term maintenance.
Assume something of the order of four months for the freeze etc. and release of Bullseye. Planning for Debian 12 ("Bookworm") release goals begins more significantly then. Bearing in mind that the release process will take a couple of years for a further five year lifespan, I anticipate that i386 will be dropped at that point, early on in planning for Bullseye release goals. It is a decision for the developers/porters and release managers at that point.
Most Intel/AMD 32 bit only hardware is ten or eleven years old in 2021. There's another interesting conversation going on over at LWN about obsolete ARM chipsets and removal of architectures from the Linux kernel - nobody is actively preventing you running old code but you have to take everything else into consideration including being prepared to actively contribute to keeping it running appropriately.
Most Intel/AMD 32 bit only hardware is ten or eleven years old in 2021
Why is that an issue? I've run servers much older than that. You want some 32-bit systems? I'll ship you a pallet of PCs... (more likely I would find someone on eBay selling the same, closer to you to reduce shipping cost).
32-bit systems can address 4GB or RAM and PAE allows multiples of that, so we're not talking low-end systems that are only used for retro-computing. I still occasionally use an EeePC netbook that's got a 32-bit x86 CPU.
I see 32-bit mostly on the likes of VMs with low amounts of RAM. Being 32-bit reduces the memory usage significantly.
But when the time comes to retire Bullseye, they'll be 15-16 years old.
Would you really choose to do something as major as installing a new OS on a system that old, or would you use it as an incentive to replace it with something newer? I'd certainly go for the latter.
Of course there's nothing stopping you from running old, unsupported, operating systems on your old, unsupported, hardware.
> Would you really choose to do something as major as installing a new OS on a system that old, or would you use it as an incentive to replace it with something newer? I'd certainly go for the latter.
In a corporate IT environment, where the company operations rest on it, I will agree with you.
But, in most other environments, I'd consider the environment before throwing away a perfectly usable machine. My car is 10 years old, it has rust, but it will run for the next 10 years without much going wrong.
People still use Victorian, or even much older houses. Crazy.
I get new shoes when the old ones start actually falling apart.
I have books published before 1920, one is a science book that has an article on the possibility of the existence of Unicorns and the discovery of the Gulf Stream.
Computers should last for decades.
> Running really old machines is actively bad for the planet, beyond a certain point.
No, it's the opposite. Dumping functional old machines is way worse.
Think about it. I have a Ryzen system as my main machine. It does way more per watt than my 586 laptop. But I use the laptop to run stuff that does not need performance, like word processing, coding (depending on language and compilation time), reading etc. So, is it better for the planet if I send that machine to landfill and use the Ryzen instead? Or I have the Ryzen off while I play with regular expressions?
You're basically saying, use the efficient Ryzen to do barely anything while bury the 586 to leach out it's poisons into the water table. Yep, so good for the planet.
"Being 32-bit reduces the memory usage significantly."
???????
If the memory requirement fits in 32bit, then 32bit is equal to 64bit.
If the memory requirement exceeds 32bit, then 32bit comes at the cost of more cycle time.
Regardless, newer 64bit architectures can utilize newer, faster instructions that save time and energy.
You may be forced to stick with 32bit, but if you're not then the only "win" is if you already have the hardware, then you don't have to spend the $$$$.
I think I typed the above nearly verbatim 25 years ago, except replace 32 with 16 and 64 with 32. People flipped out when Intel announced "the future" with the Pentium and of course everyone thought 16bit was dead... but it dragged on even into the early 2000's.
As for the article, Debian just can't jettison 32bit compatibility, but they can at any time drop testing as the article implies. If you _REALLY_ care about security, this would be a good move, however it would be very $$$$. If you don't care about security, well, don't freak out because your copy of MACH3 will keep on running in that VM for ever... and ever... and ever (even on your Atom 8W SoC).
I think what has been lost here is that we're not discussing just any 64bit architecture, we're discussing x64 in particular. Do you want to run that x86 32bit compiled code on a AMD x64 CPU, then go ahead. Remember we're discussing AMD's x64 in particular, which gives certain liberties other (all?) 64bit architectures do not have (memory consumption in particular).
If you want to keep that old machine around just to compile against 32bit (which will probably be ran on a x64 anyways), then go ahead, but I can only imagine how difficult that must be for entire OS distribution so I can completely understand at least bringing up the idea of dropping i386.
> I think I typed the above nearly verbatim 25 years ago,
And you learned nothing.
You do know that these new 64 bit instructions you speak of tend to operate on larger operands? I.e ADDing two 64 bit numbers together on a 64 bit machine requires less cycles because the OPERANDS are bigger. On a 32bit machine you will need to load words from 4 separate memory locations and then perform 64 bit math using 32 bit registers. Thus much 32bit code will keep to 32 bit math, for speed.
So when that code is compiled for 64bit, it will be loading the same values in 64 bit operands, into 64 bit registers. This practically halves the time taken to perform the calculation, thus is faster.
But now all your math is using 64bit operands, see the problem? Unless you specifically use 32bit math instructions you will be loading TWICE as much data from ram and saving TWICE as much data to ram. This does not affect all instructions, and 32 bit systems were doing 128bit math too but when your basic operations now use 64bits of data:
IT MEANS YOUR SYSTEM USES MORE RAM FOR THE SAME JOB AS USED BY A 32BIT SYSTEM.
Sorry for shouting but, my god, when adults don't get basic math over 25 years it just, I'm lost for words.
Consider a 35+ million installed base and a number of currently produced boards that are 32-bit only. Raspberry Pi OS still needs a 32-bit version, and the 64-bit version is still in beta. Until there is an upgrade path for the Pi0/Pi0W, that will remain to be true.
I don't think it's 32-bit ARM that's at 'RISC' here (bad PUN-ishment) but 32-bit i386 specifically.
Raspbian/RPi OS is still 32-bit last I checked, though FreeBSD had 64-bit ARM for RPi 3 a couple of years ago.
embedded systems are still widely using 32-bit Linux for ARM (or in some cases MIPS I guess). It's smaller and runs slightly faster due to address width.
Not sure how many embedded systems [other than legacy] are using 32-bit i386 though. And maybe that's why they are considering dropping it. [although I've got some old Pentium III computers and motherboards that could be used for testing if they want 'em]
> "There are an order of magnitude more people with i386 kernels (and thus presumably i386 hardware) than there are for every other non-amd64 release architecture combined. Further, there are more people with old i386 hardware than there are for any other arch," said another developer.
I've no doubt that there are still people who will keep running their ancient x86 hardware until it's pried out of their cold, dead hands. And not just hobbyists - there's no shortage of companies and institutions running ancient hardware to keep a specific bit of software operational, as we frequently see in The Reg's own On Call posts.
"A few years back, I worked at a company which was still using a Commodore 64 to drive a CNC machine. When a power surge caused this to reboot, I had to drill through three brick walls and don a full hazmat suit to descend into the bowels of the old engine room, through the old steam boiler and down to a small room where the C64 was beeping to itself, tucked away in a steel filing cabinet under a sign marked 'Beware of the leopard'".
But there's a big difference between running an i386 kernel on newer hardware, and running an i386 kernel on original i386 hardware. And even then, what would an i386 do with anything to be found in a modern kernel[*]?
I mean, the i386 topped out at 40mhz. And while it could theoretically have up to 4GB of RAM (or more with PAE), I suspect you can count on one hand the number of physical motherboards which supported more than 64mb of ram.
So, yeah. I suspect most people are running i386 kernels on newer hardware (e.g. pentium and up), simply because it was simplier and easier to guarantee compatibilty and stability.
Which in turn makes me wonder how many CPU cycles - and electricity - are wasted annually by people running these i386 kernels which don't take advantage of newer architectural features...
[*] And what would come first? The results, or the heat death of the universe?
I've got a couple of Atom based things still running. Use less power than any 'modern' 64 bit machines. Or rather at about £5 a year for being permanently on there is little financial incentive to upgrade them.
Well it would be £5 a year but I have PV so I'm probably getting paid to run them!
Fair :)
Though at a glance, even these support more than just the base i386 architecture. E.g. looking on Wikipedia, the original Silverthorne models support MMX, SSE3 - and even hyperthreading in some cases, while all the subsequent models at least nominally support Intel-64.
And I'm guessing that if they're sitting there and Just Working, you're not spending much time upgrading them to the latest version of the kernel :)
I've got a couple of Atom based things ...
My Asus 1000HE (Atom N280/2Gb RAM/250Gb HDD) runs perfectly well and when I'm not travelling with it, I use it to run my coffee roasting software which, to my chagrin, stopped being published in 32bit at v1.1.
It's over 10 years old, runs Devuan Beowulf 32bit / Openbox with no issues and don't see me getting anything else for the tasks it covers.
Cheers,
O.
My RPi4 should come in at about the same cost. It's only running PiHole/DNS, and sits at 3.7W according to my plug-in energy meter. So that's about £5.50/yr at 17p/kWh, I reckon. For a quad core 64-bit capable machine (albeit running a 32-bit OS for now).
And if it lasts 15 years it still wont be financially beneficial to me. I have no need for any more oomph than they've got. They does backup, file sharing, some web serving, network monitoring and occasionally run some video capture and motion detect and get_iplayer. The only time they sweat is when there's a power cut (we get quite a few). A Pi-Zero would be more than I need but the ssds seem to be a bit annoyed with power cuts!
But does i386 actually support i386 any more? I don't follow Linux particularly closely but I'm sure I remember it actually needed at least a Pentium nowadays. I know even NetBSD now requires at least an FPU in default trim, can't remember if there was anything else bumping it up to at least a 486 off the top of my head.
And it doesn't have to be particularly old to be 32 bit only, just think away from commodity hardware. How long is it since Atom was 64 bit across the board? Or consider the VIA C3/C7 cores, popular in embedded and thin clients?
I think Intel's last Atom that could not run 64-bit code was around 2010 or so. Such machines are almost certainly still running and usefully employed, but probably not owned by people capable of contributing to the code maintenance. Also, how easy (and cheap) would it be to replace the hardware? Quite easy for an atom based "normal" PC and much harder for an embedded system, though the latter may not be something you want to slap Debian 12 onto!
But does i386 actually support i386 any more? I don't follow Linux particularly closely but I'm sure I remember it actually needed at least a Pentium nowadays.
This... i386 support and x86 (i686?) are subtly different. There was chatter recently on the FreeBSD lists from someone trying to get FreeBSD 12.1 running on a 386. (Or maybe some 486 derivitive), only to discover that some pentium specific instructions had crept in to the pre built binaries.
The response was basically.... you'll have to compile it yourself if you want support for hardware that old... it should work.... good luck.
Mind you, the 386 was produced until 2007, but I suppose if you're sitll using one by then you'll have the skillset to make things work yourself.
For Debian specifically, 686 is the lowest that's supported - there were discussions on the debian-cd list about this.
[Removal of 486 was apparently accidental due to compiler options - by the time it was noticed, a couple of releases had gone by so it wasn't reverted.]
Read it again mate, it's not about dropping support for the 386 processor but for x86 entirely!
Targeting 386 is the lowest common denominator for any 32bit system. They are talking about dropping support for ALL 32bit CPU's (for booting, 32bit code execution can still be supported).
Btw mate. I still run old and brand spanking new 8-bit systems ;)
But I do need the i386 libraries in order to be able to run the Basic PAYE Tools from HMRC. Maybe there will be a port of those to ia64 before bullseye is obsolete, otherwise I'll have to figure out how to run it on Windows and be able to keep the records safe and secure for the 5 years required by HMRC.
The 2038 year bug is a mere 17 years away true, but dropping support for 32 bits in the middle of a pandemic were many people lost their jobs and so on?
Oh that's what I call a way to piss people off.
I no longer use 32 bit computers myself since my last one, a former Media center XP laptop, died for real last year.
But a lot other people do. Is amazing but even in 2021 there are people running machines that don't even have 2 GB of ram.
Why don't you see that people more active online? Because they are running very outdated hardware. Even on Seamonkey 32 bits things are going to slow to a crawl if the machine hardware is not powerful enough.
Were do you can find those people? Were else? IRC. The #puppylinux channel gets questions on "how d to run X" on 20 something machines at least one a day.
True the hard disk/s that came with the original machine are probably long dead but a hard disk is one of the easiest things to replace and if the rest works, why not revive an old machine and give it a ride?
I no longer use 32 bit computers myself since my last one, a former Media center XP laptop, died for real last year.
I still run various architectures down to 8-bit. Granted many of them don't run Linux nor are x86, but the stance that anything below 64-bit is "dead" is quite far from the truth.
There are options to run a 64-bit OS on top of those even so - I made Debian installation work on Bay Trail machines for exactly this setup. Grab a multi-arch netinst image and you're good. It just needs a 32-bit version of Grub, then everything above that is 64-bit.
No, no no. Just don't do that if you want to see what Linux is all about. The experience of running Linux on an old machine with doggy hard disks and sod-all RAM will give you the worst 'first impression' you could possibly imagine.
I cannot recall how many people have done that around me, and in every case they would say it is so much worse than Windows ... running on their bleeding edge desktop.
For the best experience, treat yourself to a new SSD for your daily machine, swap it out for the one already in there (presumably Win10) then install a modern distribution and be amazed at how good Linux really is on a modern machine. When you've finished playing, you can just swap disks back and nothing has been messed about with on your old OS.
Of course you can multi boot if/when you know what you're doing, but for a zero risk strategy it's the only way to go. You probably need a new SSD anyway ...
Many have been dropping i386 support recently. For newer kit, this makes sense as there is not that much i386 gear that is online. Most of the still running kit is for the CNC machine (and the like) that probably never was online on even on a network. So it can safely run whatever OS and software they currently have installed. If the OS was updated, I suspect there is good chance the software installed would not run. So from Debian's perspective (or anyone else's) is with the effort to continue to continue to support i386, etc. in the future.
> For newer kit, this makes sense as there is not that much i386 gear that is online. Most of the still running kit is for the CNC machine (and the like) that probably never was online on even on a network.
Everything you just said contradicts the article. Tell me, if these non-networked CNC machines are the only 32 bit systems, why do Debian see them as a huge number of systems that run recent Debian versions? Did you read the article? Debian said themselves that there is a massive number of 32 bit installs but they want to drop 32 bit because they hare finding it hard to test the builds.
What you say about a non networked machine continuing to run any OS it needs is correct, basically common sense (in the IT form at least). If a German car garage can still run a C64 to help test and tune Ferrari engines I'm sure there are plenty of Windows 3.1 and OS/2 machines doing stuff.
I know of an American county who were using an Acorn machine to run the counties school heating systems over wireless link. The UK rail network also used similar machines to display the live train information on the screens on the platforms. I think they finally migrated when they got to the point they found it hard to find reliable sources of error free floppies.
No. The problem with floppies was brake dust. It gets in everywhere through the tiniest gaps.
The interim work round was to leave a sacrificial disk in the drive. Install, and run from a hard drive, then eject the floppy before doing software/timetable updates from a fresh one. At that time there was virtually no network availability, modems were quite unreliable in that environment, and they'd just started doing remote customer information via... pager messages!
Yep, I still have 2 32-bit systems. But, as others have said, I am not in some mad rush to have them have to run the newest software on them. These distros over the years have dropped 386, then 486, then pentium support (most went straight from 486 to 686 back then), most now need PAE too, they have slowly dropped support for older CPUs over time.
One is running Ubuntu 18.04 (20.04 has a few 32-bit packages to support wine etc., but not enough for a working system), and it's just serving up files and junk anyway, no newer packages needed.
The other is Ubuntu 11.04 with mythtv, running a much newer Ubuntu kernel to support newer TV tuner stick; had to turn off apparmor, since the Ubuntu 11-era apparmor setup has like 1/4 the settings an Ubuntu 18-era kernel needs, but other than that no drama at all, it booted right up to a graphical desktop, all tuners detected, etc. Obviously no newer packages needed here.
What's in the latest and greatest that would improve my 32-bit systems? Server-side, virtualization and cloud-related stuff, which is not really gonna happen on a 32-bit system; on desktop, better video drivers and mesa support, especially for newer cards (not needed, a 32-bit system is not getting a new video card dropped in); and x265 (... I don't think any 32-bit system is fast enough to do any x265 encoding or decoding in a reasonable length of time.)
They are talking about support in terms of maintaining security patches and such; this is true, but the other big issue is build time. I was very surprised when I went recently to build a kernel on my quad-core I5, and it took quite a long time; I mean, it took longer to build a kernel now than it did back when I was running a 486! You'd think modern fast systems would mean fast builds, it doesn't, the compiler does a lot more optimizing now than it did 10 or 20 years ago, which more than cancels out the speedup from having a much faster CPU; building like 20,000-30,000 packages (really, Ubuntu, Debian, etc. have a huuuuge number of available packages) surely takes a looong time and dropping i386 will save a huge amount of time on whatever build servers they have.
If it's just security, if they get any maintainers they could move i386 to an unofficial port, if there's demand for that. But it could be a matter of build time too.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
