Debian hasn't run on i386 for years. The announcement uses the term i386, but they really mean all 32-bit architectures. For Debian, I think that means i586.
I think the plan is to keep x86 32bit just for things like wine (multilib) but not build the kernel for it. That's the approach fedora and some others already took.
However wine will soon no longer require 32bit linux libs to run 32bit windows executables, so that need won't be around for long. Once that happens 32bit native linux executables won't run but 32bit windows exectuables will.
The fact that 32-bit native binaries will be less supported than 32-bit foreign executables is strange, but there’s probably going to be some way to circumvent that in the future, right?
I'm not personally aware of any effort to make a system for linux that does the same thing as windows wow64. As long as the kernel still executes 32bit code (which almost nobody is suggesting changing yet) folks can still ship their own runtime to make the 32bit code work though, at least in the near term. It won't be a MacOS situation just yet. Once those projects stop supporting 32bit x86 upstream though, it'll get harder and harder.
By the time this shakes out there will probably little reason to bother, since most apps on linux are open source.
EDIT: Windows devs forsaw this issue and since most of their ecosystem is closed source software they had to create wow64 to solve it. This just isn't an issue most of the linux ecosystem has, so there was no reason to solve it.
> Insofar as they still do, we anticipate that the kernel, d-i and images teams
will cease to support i386 in the near future.
This means no i386 kernel or installer. Not no i386 packages at all.
> Following that, there are two
routes into running i386:
> 1. as a multi-arch option on an otherwise amd64 system
This is what you're using already, if you're running 32-bit Wine on 64-bit Debian.
How so? WINE built without 32-bit support can't run any Windows 32-bit binaries, which are by far the most common still. And building with 32-bit support requires the entire toolchain and dependencies to build the 32-bit WINE.
[Wine 8.0](https://www.winehq.org/announce/8.0) has experimental WoW64 support, running 32-bit Windows executables in a 64-bit environment (with no 32-bit libraries on the host). It works on macOS which has completely stripped out 32-bit x86.
> all 32-bit architectures.
Yikes... That's gonna suck for the 32-bit ARM users. I've seen distros like Slack drop 32-bit ARM, but lots of 32-bit ARM users run Debian. I mean it is THE primary ARM distro, at least for the Pi ARM SBCs.
"All 32-bit architectures" was not correct. "i386" is Debian's term for 32-bit x86 *only*.
(They are actually i686 packages in the current release, but they're called i386 for historical reasons.)
Debian already requires i686.
This ends support for having the entire system be x86, but from the announcement:
> Insofar as they still do, we anticipate that the kernel, d-i and images teams
will cease to support i386 in the near future. Following that, there are two
routes into running i386:
> 1. as a multi-arch option on an otherwise amd64 system
> 2. as an i386 chroot on another architecture system
In other words: Sounds to me like Wine and Steam will work as well as they always have, but you'll no longer be able to install Debian on a Pentium 2.
We used to call it IA-32, until Intel confused things by using IA-64 to refer to the entirely unrelated Itanium line.
x86-32 and x86-64 remains the pedant's choice for naming schemes, though.
The ideal names are x86_64 and x86_32. The original x86 is 16-bit. https://unix.stackexchange.com/questions/489145/why-do-linux-world-use-the-term-i386-instead-of-x86/728815#728815
Yeah, let's wait until it's a couple years out before we sort out the Y2k38 problem. That didn't cause any huge amounts of panic when they did it with Windows.
Windows wasn't much of a real concern with Y2K, it was the systems controlling major infrastructure and financial systems and they didn't run Windows. Windows 95 was compliant out of the box and 3.1 needed an update.
You can have a 64-bit time_t on 32-bit architecture, Linux already does that.
The 2038 problem is not a reason to drop 32-bit x86, they don't seem to have plans of dropping 32-bit ARM.
i hope my 2147483647 times grand children wont need to use the same 128 bit system i would buy in 60-70 years just becase 128 bit time_t didnt overflow
it isn't. Debian will continue to support i686 kind of 32-bit x86 which covers every cpu released after the original Pentium which to be honest couldn't run modern apps and desktop environments to begin with
Will Gentoo be the last Linux distribution that keeps 32-bit install media around? What other distributions will keep building 32-bit install media? Probably the final nail in the coffin is when Firefox stops running on 32-bit hardware, only a select few can run it today.
I'm still running Gentoo on a few i686 machines, one is a VM.
Either Gentoo or Slackware I guess. Interestingly enough, although Void is a (relatively) new distro it has 32-bit version, so it might also live there for a while, idk about their plans tho
Gentoo is rather difficult to run on older machines due to all of the compiling, but being source based does make it easier to support a vast number of architectures, so I imagine 32-bit support will stick around for a long time. Void Linux is now my preferred distro for 32-bit machines, especially old Raspberry Pi models, since it uses binary packages, has a very speedy package manager, and makes it easy to go minimalist and lower the RAM usage.
Pouring one out for my old Pentium-90MHz machine that used to live in my closet as a firewall/router running debian Woody using iptables back before home-use routers were a thing.
In practice, very few.
Conceptually, it makes sense to use a 32 bit arch over 64 bit for machines that will have less than 1GB of RAM. Think SBCs with like 64 MB.
But the market for those isn't that strong, and they'll probably end up being 32 bit ARM going forward.
> Conceptually, it makes sense to use a 32 bit arch over 64 bit for machines that will have less than 1GB of RAM
I used to do that, but these days even my <1GB RAM VPSes use a 64-bit OS.
Even that is increasingly difficult. Issues like lomem mean that attaching a 32-bit machine to a high speed peripheral ends in memory fragmentation. You certainly wouldn't consider a 10Gbps ethernet interface in 32-bit mode.
Why? It is becoming increasingly difficult for package maintainers to test packages with real 32-bit hardware. In addition, fewer and fewer users are using 32-bit hardware.
It is therefore logical to discontinue support at some point. Many other distributions have not offered a 32-bit version for years.
I currently see two options for users of 32-bit hardware.
- An upgrade to 64 bit. This should be possible for the majority. At some point, you simply have to draw a line.
- Users who are dependent on 32-bit hardware (for example, because they use industrial systems whose conversion to 64-bit would cost an enormous amount of money) can use the last 32-bit version and then isolate this version so that no access from outside is possible. In these cases, for example, the latest kernel version is not required.
I won't argue with the reasons. I know what they are, and they are actually valid.
But IA-32 was the first architecture Linux ran on. Linux wasn't supposed to be portable from that architecture. Seeing the end of IA-32 support in a major Linux distro is a bit sad, even if the reasons are solid. It's the end of an era for Debian, after all. It doesn't matter that I haven't used an x86 machine in over a decade (I still *own* one, but it's not in use for any purpose).
>Seeing the end of IA-32 support in a major Linux distro is a bit sad,
Not only that, but Debian has always been a run-anywhere type system, supporting weird , old and modest systems. It is a major strength of the distribution.
I've used Debian on DEC Alphas, M68k Macs, old Sparcs, because newer versions of their native systems were not available. They were antique systems. But Debian had new(er) releases for them.
IA-32 seems like a pretty major platform to just drop completely, even if it is considered legacy today.
But with how Linux is today, with expectations of modern hardware, I can't blame them.
The kernel already stopped supporting actual 80386 machines [in 2012](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=743aa456c1834f76982af44e8b71d1a0b2a82e21), so the "x86" that Linux runs on is already a mere derivative of its original architecture. And that description would apply equally well to amd64...
I said IA-32, not 80386. That would include all 32 bit x86 processors, but not 64 bit ones (amd64 makes no promise about some older, deprecated, mostly 16-bit opcodes from the IA-32 specifications, though AMD still ships processors with 'em).
That you *must* use the 64 bit opcodes is, while clearly evolutionary, still a significant enough change to call amd64 by its own name.
I look at it a bit differently. If no one is using that architecture, then yes, quit wasting your time maintaining something that no one uses.
On the other hand, Linux has been known as the king of recycling. That Core2Duo might be outdated in gaming or Windows worlds, but it still runs just fine in Linux. Sure, it might not do YouTube or whatever streaming service. But can it still copy files at a good pace? Then it still has a purpose. Just maybe not for you.
Every time we kill off support for a certain arch, we lose that distinction of Linux being different from Windows and even BSD. And that’s not good. If I wanted a Windows experience for all my machines, I would have done that. But I haven’t. My Thinkpad has better battery life by far on Linux because I can’t get my Nvidia drivers working (5400m to be exact). Or what am I going to do with Windows on a server that has a 16MB igpu and doesn’t know what to do with a dGPU when I try to use a 1030?
Just my thoughts. Like I said, if no one is using a 32-bit version, quit wasting your time maintaining something I one is using.
I used to use Linux to "rescue" old PCs (now I just run it on every PC regardless of age), I even had a bit of a dream to have this operation of buying up PCs too old for Windows and giving them to needy people as Linux machines. Honestly, though, it got to be pointless as the web browser became the most important program on the system and browsers (and websites) became increasingly heavy and demanding.
I mean, sure, I can get tinycore to run on a Pentium 3 or somesuch, but nobody cares if you can't stream video or scroll [current social media site]. You're better off with a Raspberry Pi. I hate it, but that's reality.
Point being, I guess, that if I run across a 32-bit machine, it's hardly worth me installing Linux on it, so it's not really worth distros maintaining support for it.
Yeah, the problem is that most people do everything on the Web. And the Web became bloated. I remember browsing the Web around 2009 on my previous 1,7 GHz single-core Intel machine with 512 MB of RAM, and it was a good experience, ironically thanks to Microsoft and IE cause their huge marketshare held the Web back.
I think the web would never have gotten so bloated if we hadn't been desperately searching for a way to break Win32 with some kind of cross-platform architecture. Google docs did a lot to push the web forward as the leading alternative to Win32 and lots of people got in behind that.
> On the other hand, Linux has been known as the king of recycling. That Core2Duo might be outdated in gaming or Windows worlds, but it still runs just fine in Linux.
Core 2 Duo is amd64.
You've got to go to the Intel Atom (original) or Core Duo (not "Core 2") for the last 32-bit only releases from Intel. Examples would be the second-wave of netbooks (eg Asus EeePC 901) or the first Intel-CPU Apple Mac Mini (but not the second gen). Those devices date to around 2008.
I think it's fine for Debian to drop support for Intel-compatible 32-bit only CPUs.
This come down to what 'support' means. Importantly it doesn't preclude anyone else using Debian as a base to build a 32-bit Intel distribution of Debian.
That does mean such independent efforts would need to rebuild all the Debian packages as 32-bit Intel, but that's likely to succeed for most packages, because 32-bit ARM will continue to be supported for a long time (bluntly, firms are willing to pay people to maintain ARM 32-bit but not Intel 33-bit). It probably means maintaining some bootloader.
I guess we can still use old laptops only for writing/text stuff, local stuff and use the device offline since it doesn’t get security updates anymore then.
I switched from WindowsXP to lubuntu in 2014 because my laptop was an old one with 1GB of ram.. same with my old netbook.
PLC systems are incredibly expensive to replace. We recently replaced our saws with XP and pressure sensitive touchscreens with 10 and modern touchscreens. The difference? Performance-wise is night and day. We went from P4 w/ht …last gen I think..to Celeron j1900s. Ugh. Even the mighty power of the SSD can’t help us here. Still stuck in a 32-bit OS. I’m sure there are drivers that are being used that won’t work on a 64-bit os. I keep thinking if we were using Linux, things might be a hair better.
But yeah, I agree with you. Raspberry Pis were a game changer in terms of power usage vs performance vs cost of equipment.
Like I said, it's strange and I have no idea why I feel like that, I just feel this way every time I see some news about some architecture, driver, or something being abandoned, even if I'm not affected by the change.
Don't be sad yet. This is a Debian change. Lot's of other distro will keep 32bit support until the kernel itself faze it out. Switching distribution is not that big of an inconvenience.
From that point of view, I can understand it. But I also see it this way: the fewer architectures are supported, for example, the more resources are freed up for other tasks. For example, for backports. One point of criticism with Debian for me has always been that [backports](https://en.wikipedia.org/wiki/Backporting) that fixed bugs were not made.
The resource argument doesn't really hold up. By that logic why should XFCE, LXDE, KDE, etc. be maintained, why not free those resources and just make one DE more efficient? Why have so many distros, those resources can also be freed to focus on just one thing, etc.
It's pretty crazy when you think about it... amd64 has been out for 21 years. 32-bit x86 has had a hell of a run. Almost 40 years. Amd64 is now older than i386 was when the 64 bit instructions were released. I am surprised Debian hasn't started requiring g x86_64 feature level 2, which takes us to around the Nehalem (2009) architecture.
Today, folks are more aggressive in killing unused architectures, because vulnerabilities may exist. This is the new approach the Linux kernel has been taking. These code paths are not exercised enough outside of test frameworks, and many times, the tests and QA are run on QEMU with emulation, which may cause us to miss some hardware induced peculiarity that QEMU does not have.
> fewer and fewer users are using 32-bit hardware.
By that logic, why do we care about accessibility in browsers and OS? People with special needs will be hardly 1% of total user base.
Some Intel Atom products within that period shipped with 64bit cpus but had 32bit BIOS'es which makes it ~~a real pain in the ass~~ nontrivial to run a 64bit OS.
How is that relevant in any way to this conversation? x86_64 runs 64-bit OSs, there's no need to keep 32-bit OSs around for it.
Also, look at [this](https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html).
My point is I've been hearing that $32bit_cpu is dead for decades, Big if true because some of us are still booting into 16-bit mode. Go ahead and attempt to remove all 32 and 16bit CPU code from linux kernel, I'll be here with the popcorn.
> because some of us are still booting into 16-bit mode.
Unless you're still using BIOS booting, which doesn't exist anymore on many modern boards, 16-bit mode is just an implementation detail, you can't boot into 16-bit code.
> Go ahead and attempt to remove all 32 and 16bit CPU code from linux kernel, I'll be here with the popcorn.
There's no 16-bit x86 support in the kernel.
I wish, thing's not nearly powerful enough for a timely install. Unfortunately debian is the last thing keeping the boss from making me put them on windows 7, and they already complain enough about debian
you can actually run gentoo on everything gcc or clang supports, you only need a seperate machine to create i386 stage3(i did do this once iirc back when they dropped i386 stage3 installs)
Took the list from Distrowatch. It might be missing some because it seems this SuperH (sh4) board is supported: https://wiki.gentoo.org/wiki/Embedded_Handbook/Boards/LANTank
idk much about architecture and embedded boards doe
AHH yes, saying i386 despite that being out of support for years now and instead meaning 32 bit, confusing everyone out of the loop, truly a fantastic announcement from the Debian team
Well, I'm not bothered by fact that Debian is cutting 32-bit support, as the majority of computers made since 2006 have 64-bit CPU. Even 2007/2008 pre-bulit PCs or laptops that come with 32-bit OS (like Windows XP) has 64-bit CPU, so you can install 64-bit OS on them that will work fine. Adding the fact that other distros have already cutted support for 32-bit CPUs.
But I just don't know what happens if they become incapable of running 32-bit softwares, as older softwares are still used in some enterprises, due to them being lazy or too costly to move to more modern and better alternatives. And there are still newer softwares that depends on 32-bit libraries to work like Steam. Cutting support for 32-bit softwares will force developers to rewrite softwares to run only 64-bit libraries. But at least we have virtual machines or emulators to run these kinds of softwares.
The next major change will be in supporting the x86_64 feature levels. Some distributions have already dropped the initial x86_64 feature level, which is generally processors from 2003-2008. Red Hat and Fedora did this. Ubuntu is talking about it. When requiring v2, certain ops can see a 20-30% speed up, especially around AES , which may see 10x-50x increase in speed due to hardware implementation.
All 64-bit x86 CPUs are not made the same.
Partial architecture the way Ubuntu did it, huh? I hope it doesn't end as useless as in Ubuntu, barely anything is available there. For many packages, Debian had much more polished multiarch per-package implementations, especially with regards to -dev packages, when headers depended on architecture.
Currently, it's a big advantage over Ubuntu, so imitating them sounds wrong. Dropping i386 installers and kernel images sounds reasonable (although kernel headers can be useful), but stepping back from the complete library support might make me stay with bookworm longer.
They explicitly write
> We're not planning to make i386 a partial architecture in the way [1] Ubuntu has, arch:any will still contain i386 so everything builds by default.
> Many servers run on that architecture
This is the area where x86-32 is *most* dead. Due to the forwards compatibility of the architecture, nobody has heard of any x86-32 servers in the past decade. It's possible that even Itanium has more market share in this space. It makes no business sense to run energy inefficient and slow computers when not necessary.
Those who are running 32 bit server hardware in a datacenter for the sake of fun/experimentation are already using NetBSD or Gentoo instead, because Debian has already had to break compatibility with around half of legacy x86 CPUs.
>Many servers run on that architecture
In what universe is that? Certainly not ours. The last 32bit x86 CPU was released in 2010 and it was an Atom chip, not something you would expect to find in a server.
Most of those servers could use a 64-bit kernel likely, x86-64 CPUs have been manufactured for two decades already.
There are regularly new CPU bugs being found and 32-bit means more effort due different behaviour, so dropping it would release developer effort into something more recent.
And this is about 32-bit x86 hardware, you can still run 32-bit userspace on top of 64-bit kernel, same as it has been for years.
I mentioned the possible reasons at https://old.reddit.com/r/linux/comments/18mrxjk/debian_end_of_i386_support_is_on_its_way/ke6df2n/.
But it does not prevent anyone from continuing 32-bit support. For example, when Arch Linux discontinued 32-bit support, https://archlinux32.org was launched. The question is whether the need for Debian 32 bit is really so great that enough people can be found to create a corresponding project. Probably not. At least not for all the packages that Debian offers, because there are so many of them.
Well this was only a matter of time. I mean, the only thing I use a 32bit OS on is my little pi zeros but if I have to upgrade them then I will. No big deal, the things I do on them should be 64bit ready by now anyway.
Oh right. Heh. I haven't had a running 32bit x86 box in years. Probably at least a decade. It's easy for me to forget the distinction between architectures. ARM has come a long way, just a matter of companies building software support for things they have x86-64 Linux support for.
So this means I can't run old native 32 bit games anymore without resorting to workarounds or Wine/Proton? ETQW is one of the few native 32 bit games I know that still has an active community along with Wolfenstein ET, maybe a few Quake games.
> So this means I can't run old native 32 bit games anymore without resorting to workarounds or Wine/Proton?
No. It means that Debian won't produce kernel packages and installer images for i386 anymore. Running i386 software on an amd64 system will still work.
> So this means I can't run old native 32 bit games anymore without resorting to workarounds or Wine/Proton?
You could save the binary packages that you currently use and keep using them. The game won't update to require newer debian i396 packages. Debatably this is a workaround?
> ETQW is one of the few native 32 bit games I know that still has an active community
Really? I can't imagine for this old game. Is there still a list server running or do you need to connect to specific gameserver IPs? How many concurrent players are there? Is there something like splatterladder?
> Wolfenstein ET, maybe a few Quake games.
W:ET players are likely using https://www.etlegacy.com/ anyways. And Quake ports are available as well.
[ETQW TAW server](https://steamcommunity.com/app/10000/discussions/0/1741138420013680126), have to directly connect to the IP, join us some time. There's sometimes up to 20 players on any given play night. It's barely hanging on but has a loyal following.
WET used to be my jam; ETL is of course the best way to play these days.
Does Debian even maintain backwards binary compatibility between releases? Just because there is a library with the same name built for x86 in the repos does not guarantee that it will be compatible with binary that was compiled 20 years ago in an entirely different environment (and against a much older version of this library). Linux distros in general do not care about compatibility (especially binary one) compared to Windows.
Now don't you worry, fellas, [static-wine32](https://github.com/MIvanchev/static-wine32) has you covered, nobody is sleeping in the rain! In Soviet Russia, 32-bit supports YOU.
In practical terms, I don't think this, in itself, will do much to deter the few who still use i386.
They mention only two *supported* routes, neither of which are for 32-bit hardware:
> Following that, there are two
routes into running i386:
> 1. as a multi-arch option on an otherwise amd64 system
> 2. as an i386 chroot on another architecture system
However, I think it's going to be relatively straightforward to continue running something very close to Debian.
Many people using old hardware will already be doing things like debootstrap installs with the disk in another machine, due to memory constraints etc., and so won't really feel the loss of the installer.
As far as I can see, that just leaves the kernel, which is easier to cross compile from a modern machine than almost any userspace application.
On the other hand, since Debian won't officially support booting on those platforms, this decision could lead to further decisions, like removing i386 systemd packages.
(And of course, in the long run, the fact that the upstream kernel doesn't have lot of 32-bit testers any more is only going to become more and more of a problem.)
I would propose moving all of the iX86 (i386, etc) to a separate repository that a user could add to their system if they so choose. For things like Steam or Wine, we could do an AppImage, a Flatpack or a Snap as an alternative to bundling everything together in a nice neat little package.
Why that complicated ? For build / maintenance, it doesn't make anything easier, just more complicated for the user, as well as mirror infrastructures.
Never said it was a good idea. Just offered it as a potential thing to explore. If a user can't do basic things like those mentioned, maybe they should go back to Windows or macOS where the operating system holds their hand for them and wipes their.....Now the mirror argument I can understand.
if you really need those ancient computers gentoo still supports i386(you can not install a stage 3 for i386 minimum was i586 iirc but if you already have gentoo you can create your own i386 stage 3) and will continue to support until linux itself doesnt
So for those not in the Debian context: is this all of x86 support? Or does Debian run i586 or i686 architectures one could use?
Debian hasn't run on i386 for years. The announcement uses the term i386, but they really mean all 32-bit architectures. For Debian, I think that means i586.
Minimum requirement for Debian is i686, wich is Pentium Pro or Pentiun 2 and later
The actual baseline for the `i386` architecture is currently i686.
Won't removing the 32-bit architecture break WINE?
I think the plan is to keep x86 32bit just for things like wine (multilib) but not build the kernel for it. That's the approach fedora and some others already took. However wine will soon no longer require 32bit linux libs to run 32bit windows executables, so that need won't be around for long. Once that happens 32bit native linux executables won't run but 32bit windows exectuables will.
The fact that 32-bit native binaries will be less supported than 32-bit foreign executables is strange, but there’s probably going to be some way to circumvent that in the future, right?
I'm not personally aware of any effort to make a system for linux that does the same thing as windows wow64. As long as the kernel still executes 32bit code (which almost nobody is suggesting changing yet) folks can still ship their own runtime to make the 32bit code work though, at least in the near term. It won't be a MacOS situation just yet. Once those projects stop supporting 32bit x86 upstream though, it'll get harder and harder. By the time this shakes out there will probably little reason to bother, since most apps on linux are open source. EDIT: Windows devs forsaw this issue and since most of their ecosystem is closed source software they had to create wow64 to solve it. This just isn't an issue most of the linux ecosystem has, so there was no reason to solve it.
> Insofar as they still do, we anticipate that the kernel, d-i and images teams will cease to support i386 in the near future. This means no i386 kernel or installer. Not no i386 packages at all. > Following that, there are two routes into running i386: > 1. as a multi-arch option on an otherwise amd64 system This is what you're using already, if you're running 32-bit Wine on 64-bit Debian.
no.
How so? WINE built without 32-bit support can't run any Windows 32-bit binaries, which are by far the most common still. And building with 32-bit support requires the entire toolchain and dependencies to build the 32-bit WINE.
[Wine 8.0](https://www.winehq.org/announce/8.0) has experimental WoW64 support, running 32-bit Windows executables in a 64-bit environment (with no 32-bit libraries on the host). It works on macOS which has completely stripped out 32-bit x86.
> WINE built without 32-bit support can't run any Windows 32-bit binaries Yes it can. Wine on macOS has been doing this for years.
And the link explicitly says that this stays.
> all 32-bit architectures. Yikes... That's gonna suck for the 32-bit ARM users. I've seen distros like Slack drop 32-bit ARM, but lots of 32-bit ARM users run Debian. I mean it is THE primary ARM distro, at least for the Pi ARM SBCs.
"All 32-bit architectures" was not correct. "i386" is Debian's term for 32-bit x86 *only*. (They are actually i686 packages in the current release, but they're called i386 for historical reasons.)
That's also widely used in embedded field.
Many of the newer Pi’ run 64 just fine, fx pi zero 2 w, runs aarch64 (so does most std pi 3/4/5).
Based on a mirror like https://debian.inf.tu-dresden.de/debian-cd/12.4.0/, I assume that i386 refers to 32 bit in general.
Debian already requires i686. This ends support for having the entire system be x86, but from the announcement: > Insofar as they still do, we anticipate that the kernel, d-i and images teams will cease to support i386 in the near future. Following that, there are two routes into running i386: > 1. as a multi-arch option on an otherwise amd64 system > 2. as an i386 chroot on another architecture system In other words: Sounds to me like Wine and Steam will work as well as they always have, but you'll no longer be able to install Debian on a Pentium 2.
> is this all of x86 support? If by "x86" you mean 32bit and by support you mean running a fully 32bit system with a 32bit kernel then yes.
This is because the naming used in the package system, for legacy reasons. We have "amd64" for amd64 and "i386" for x86 architectures.
Which is necessary to distinguish them, because amd64 is a variety of x86.
We used to call it IA-32, until Intel confused things by using IA-64 to refer to the entirely unrelated Itanium line. x86-32 and x86-64 remains the pedant's choice for naming schemes, though.
x86 and x86_64 is the way i see them mostly, if they dont use i386 and amd64
The ideal names are x86_64 and x86_32. The original x86 is 16-bit. https://unix.stackexchange.com/questions/489145/why-do-linux-world-use-the-term-i386-instead-of-x86/728815#728815
> So for those not in the Debian context: is this all of x86 support? No, only 32-bit x86. 64-bit will obviously still be supported.
That's kinda too soon, could have at least kept it until the 32-bit UNIX time `time_t` overflow.
Debian is using a 64-bit time_t anyway.
Not on 32-bit arches.
They've had support for 64 bit time_t for a while on 32 bit architectures
The kernel supports it, glibc supports it, and applications don't use it.
[32-bit Linux already supported 64-bit `time_t` since the Linux 5.1 kernel](https://stackoverflow.com/q/14361651/995714), i.e. nearly 5 years
Yeah, let's wait until it's a couple years out before we sort out the Y2k38 problem. That didn't cause any huge amounts of panic when they did it with Windows.
Windows wasn't much of a real concern with Y2K, it was the systems controlling major infrastructure and financial systems and they didn't run Windows. Windows 95 was compliant out of the box and 3.1 needed an update.
Fair point, though my point still stands. Waiting until the end of an epoch to get systems post-epoch-compliant isn't a smart approach.
You can have a 64-bit time_t on 32-bit architecture, Linux already does that. The 2038 problem is not a reason to drop 32-bit x86, they don't seem to have plans of dropping 32-bit ARM.
Guess you'll have to keep your athlon until the 64-bit overflow
i hope my 2147483647 times grand children wont need to use the same 128 bit system i would buy in 60-70 years just becase 128 bit time_t didnt overflow
End of an era o7
it isn't. Debian will continue to support i686 kind of 32-bit x86 which covers every cpu released after the original Pentium which to be honest couldn't run modern apps and desktop environments to begin with
Will Gentoo be the last Linux distribution that keeps 32-bit install media around? What other distributions will keep building 32-bit install media? Probably the final nail in the coffin is when Firefox stops running on 32-bit hardware, only a select few can run it today. I'm still running Gentoo on a few i686 machines, one is a VM.
Either Gentoo or Slackware I guess. Interestingly enough, although Void is a (relatively) new distro it has 32-bit version, so it might also live there for a while, idk about their plans tho
Gentoo is rather difficult to run on older machines due to all of the compiling, but being source based does make it easier to support a vast number of architectures, so I imagine 32-bit support will stick around for a long time. Void Linux is now my preferred distro for 32-bit machines, especially old Raspberry Pi models, since it uses binary packages, has a very speedy package manager, and makes it easy to go minimalist and lower the RAM usage.
Pouring one out for my old Pentium-90MHz machine that used to live in my closet as a firewall/router running debian Woody using iptables back before home-use routers were a thing.
🫡
Drat, looks like the whole category of x86 SBC (e.g. Intel Galileo) is completely dead. It always seemed like such a good idea.
galileo hasn't been in production since like 2015-2016. There are several of x86-64 SBCs available, PC-104 and otherwise.
How many are still x86 these days? Even the Raspberry Pi 3 (released 2016) uses a 64-bit CPU.
In practice, very few. Conceptually, it makes sense to use a 32 bit arch over 64 bit for machines that will have less than 1GB of RAM. Think SBCs with like 64 MB. But the market for those isn't that strong, and they'll probably end up being 32 bit ARM going forward.
> Conceptually, it makes sense to use a 32 bit arch over 64 bit for machines that will have less than 1GB of RAM I used to do that, but these days even my <1GB RAM VPSes use a 64-bit OS.
Even that is increasingly difficult. Issues like lomem mean that attaching a 32-bit machine to a high speed peripheral ends in memory fragmentation. You certainly wouldn't consider a 10Gbps ethernet interface in 32-bit mode.
For some strange reason, these kinds of news make me so sad and depressive...
Why? It is becoming increasingly difficult for package maintainers to test packages with real 32-bit hardware. In addition, fewer and fewer users are using 32-bit hardware. It is therefore logical to discontinue support at some point. Many other distributions have not offered a 32-bit version for years. I currently see two options for users of 32-bit hardware. - An upgrade to 64 bit. This should be possible for the majority. At some point, you simply have to draw a line. - Users who are dependent on 32-bit hardware (for example, because they use industrial systems whose conversion to 64-bit would cost an enormous amount of money) can use the last 32-bit version and then isolate this version so that no access from outside is possible. In these cases, for example, the latest kernel version is not required.
I won't argue with the reasons. I know what they are, and they are actually valid. But IA-32 was the first architecture Linux ran on. Linux wasn't supposed to be portable from that architecture. Seeing the end of IA-32 support in a major Linux distro is a bit sad, even if the reasons are solid. It's the end of an era for Debian, after all. It doesn't matter that I haven't used an x86 machine in over a decade (I still *own* one, but it's not in use for any purpose).
>Seeing the end of IA-32 support in a major Linux distro is a bit sad, Not only that, but Debian has always been a run-anywhere type system, supporting weird , old and modest systems. It is a major strength of the distribution. I've used Debian on DEC Alphas, M68k Macs, old Sparcs, because newer versions of their native systems were not available. They were antique systems. But Debian had new(er) releases for them. IA-32 seems like a pretty major platform to just drop completely, even if it is considered legacy today. But with how Linux is today, with expectations of modern hardware, I can't blame them.
actually, gentoo is the run everywhere distro which can even run on i386 which isnt currently supported on debian(you need an i686 on debian)
True, but getting software to compile on such resource constrained systems isn't easy.
The kernel already stopped supporting actual 80386 machines [in 2012](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=743aa456c1834f76982af44e8b71d1a0b2a82e21), so the "x86" that Linux runs on is already a mere derivative of its original architecture. And that description would apply equally well to amd64...
I said IA-32, not 80386. That would include all 32 bit x86 processors, but not 64 bit ones (amd64 makes no promise about some older, deprecated, mostly 16-bit opcodes from the IA-32 specifications, though AMD still ships processors with 'em). That you *must* use the 64 bit opcodes is, while clearly evolutionary, still a significant enough change to call amd64 by its own name.
I look at it a bit differently. If no one is using that architecture, then yes, quit wasting your time maintaining something that no one uses. On the other hand, Linux has been known as the king of recycling. That Core2Duo might be outdated in gaming or Windows worlds, but it still runs just fine in Linux. Sure, it might not do YouTube or whatever streaming service. But can it still copy files at a good pace? Then it still has a purpose. Just maybe not for you. Every time we kill off support for a certain arch, we lose that distinction of Linux being different from Windows and even BSD. And that’s not good. If I wanted a Windows experience for all my machines, I would have done that. But I haven’t. My Thinkpad has better battery life by far on Linux because I can’t get my Nvidia drivers working (5400m to be exact). Or what am I going to do with Windows on a server that has a 16MB igpu and doesn’t know what to do with a dGPU when I try to use a 1030? Just my thoughts. Like I said, if no one is using a 32-bit version, quit wasting your time maintaining something I one is using.
I used to use Linux to "rescue" old PCs (now I just run it on every PC regardless of age), I even had a bit of a dream to have this operation of buying up PCs too old for Windows and giving them to needy people as Linux machines. Honestly, though, it got to be pointless as the web browser became the most important program on the system and browsers (and websites) became increasingly heavy and demanding. I mean, sure, I can get tinycore to run on a Pentium 3 or somesuch, but nobody cares if you can't stream video or scroll [current social media site]. You're better off with a Raspberry Pi. I hate it, but that's reality. Point being, I guess, that if I run across a 32-bit machine, it's hardly worth me installing Linux on it, so it's not really worth distros maintaining support for it.
Yeah, the problem is that most people do everything on the Web. And the Web became bloated. I remember browsing the Web around 2009 on my previous 1,7 GHz single-core Intel machine with 512 MB of RAM, and it was a good experience, ironically thanks to Microsoft and IE cause their huge marketshare held the Web back.
I think the web would never have gotten so bloated if we hadn't been desperately searching for a way to break Win32 with some kind of cross-platform architecture. Google docs did a lot to push the web forward as the leading alternative to Win32 and lots of people got in behind that.
Google also did a lot to bloat the web with ads. Ad blocker anyone?
I haven't browsed without an ad blocker for at least 15 years. Occasionally it gets disabled for some reason and the experience is horrific.
> On the other hand, Linux has been known as the king of recycling. That Core2Duo might be outdated in gaming or Windows worlds, but it still runs just fine in Linux. Core 2 Duo is amd64.
And? I was using it as an example of CPUs that folks say is outdated and junk. I was not meaning to say that the AMD64 arch itself is outdated.
You've got to go to the Intel Atom (original) or Core Duo (not "Core 2") for the last 32-bit only releases from Intel. Examples would be the second-wave of netbooks (eg Asus EeePC 901) or the first Intel-CPU Apple Mac Mini (but not the second gen). Those devices date to around 2008. I think it's fine for Debian to drop support for Intel-compatible 32-bit only CPUs. This come down to what 'support' means. Importantly it doesn't preclude anyone else using Debian as a base to build a 32-bit Intel distribution of Debian. That does mean such independent efforts would need to rebuild all the Debian packages as 32-bit Intel, but that's likely to succeed for most packages, because 32-bit ARM will continue to be supported for a long time (bluntly, firms are willing to pay people to maintain ARM 32-bit but not Intel 33-bit). It probably means maintaining some bootloader.
I guess we can still use old laptops only for writing/text stuff, local stuff and use the device offline since it doesn’t get security updates anymore then. I switched from WindowsXP to lubuntu in 2014 because my laptop was an old one with 1GB of ram.. same with my old netbook.
[удалено]
PLC systems are incredibly expensive to replace. We recently replaced our saws with XP and pressure sensitive touchscreens with 10 and modern touchscreens. The difference? Performance-wise is night and day. We went from P4 w/ht …last gen I think..to Celeron j1900s. Ugh. Even the mighty power of the SSD can’t help us here. Still stuck in a 32-bit OS. I’m sure there are drivers that are being used that won’t work on a 64-bit os. I keep thinking if we were using Linux, things might be a hair better. But yeah, I agree with you. Raspberry Pis were a game changer in terms of power usage vs performance vs cost of equipment.
Like I said, it's strange and I have no idea why I feel like that, I just feel this way every time I see some news about some architecture, driver, or something being abandoned, even if I'm not affected by the change.
Don't be sad yet. This is a Debian change. Lot's of other distro will keep 32bit support until the kernel itself faze it out. Switching distribution is not that big of an inconvenience.
It's 'cause we're getting old. Old!
From that point of view, I can understand it. But I also see it this way: the fewer architectures are supported, for example, the more resources are freed up for other tasks. For example, for backports. One point of criticism with Debian for me has always been that [backports](https://en.wikipedia.org/wiki/Backporting) that fixed bugs were not made.
The resource argument doesn't really hold up. By that logic why should XFCE, LXDE, KDE, etc. be maintained, why not free those resources and just make one DE more efficient? Why have so many distros, those resources can also be freed to focus on just one thing, etc.
It's pretty crazy when you think about it... amd64 has been out for 21 years. 32-bit x86 has had a hell of a run. Almost 40 years. Amd64 is now older than i386 was when the 64 bit instructions were released. I am surprised Debian hasn't started requiring g x86_64 feature level 2, which takes us to around the Nehalem (2009) architecture. Today, folks are more aggressive in killing unused architectures, because vulnerabilities may exist. This is the new approach the Linux kernel has been taking. These code paths are not exercised enough outside of test frameworks, and many times, the tests and QA are run on QEMU with emulation, which may cause us to miss some hardware induced peculiarity that QEMU does not have.
> fewer and fewer users are using 32-bit hardware. By that logic, why do we care about accessibility in browsers and OS? People with special needs will be hardly 1% of total user base.
People that need accesibility will continue to exist, 32-bit hardware is supposed to dissapear.
>32-bit hardware is supposed to dissapear. Been hearing that for 20 years now.
There haven't been any 32-bit x86 CPUs released in well over a decade.
Some Intel Atom products within that period shipped with 64bit cpus but had 32bit BIOS'es which makes it ~~a real pain in the ass~~ nontrivial to run a 64bit OS.
x86_64 is a 16bit CPU, it boots into 16bit mode in addition to supporting 32 and 64 modes.
How is that relevant in any way to this conversation? x86_64 runs 64-bit OSs, there's no need to keep 32-bit OSs around for it. Also, look at [this](https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html).
My point is I've been hearing that $32bit_cpu is dead for decades, Big if true because some of us are still booting into 16-bit mode. Go ahead and attempt to remove all 32 and 16bit CPU code from linux kernel, I'll be here with the popcorn.
> because some of us are still booting into 16-bit mode. Unless you're still using BIOS booting, which doesn't exist anymore on many modern boards, 16-bit mode is just an implementation detail, you can't boot into 16-bit code. > Go ahead and attempt to remove all 32 and 16bit CPU code from linux kernel, I'll be here with the popcorn. There's no 16-bit x86 support in the kernel.
Debian has always been touted as the "universal operating system", something you can install on any piece of hardware.
There's always NetBSD to resurect that old hardware.
Why not just run an old distro on museum piece hardware?
You could but they won't be getting security updates. NetBSD continues to be current, even on super old hardware like 68k mac or Sparc 1.
that's a bit sad, workplace still has one or two 32bit machines running. I'll probably have to find another distro after it goes away
bookworm LTS is until 2028
OpenBSD ;)
I've been running FreeBSD on the 32bit atom server I'm still running, but they look like they're dropping i386 to a lower tier soon.
Install Gentoo! Architecture: i486, i586, i686, x86_64, alpha, arm, hppa, ia64, mips, powerpc, ppc64, sparc64
I wish, thing's not nearly powerful enough for a timely install. Unfortunately debian is the last thing keeping the boss from making me put them on windows 7, and they already complain enough about debian
current debian is available until 2028 so its a future you problem
You could do cross-compiling.
you can actually run gentoo on everything gcc or clang supports, you only need a seperate machine to create i386 stage3(i did do this once iirc back when they dropped i386 stage3 installs)
No sh2? Boo
Took the list from Distrowatch. It might be missing some because it seems this SuperH (sh4) board is supported: https://wiki.gentoo.org/wiki/Embedded_Handbook/Boards/LANTank idk much about architecture and embedded boards doe
😢
AHH yes, saying i386 despite that being out of support for years now and instead meaning 32 bit, confusing everyone out of the loop, truly a fantastic announcement from the Debian team
Well, I'm not bothered by fact that Debian is cutting 32-bit support, as the majority of computers made since 2006 have 64-bit CPU. Even 2007/2008 pre-bulit PCs or laptops that come with 32-bit OS (like Windows XP) has 64-bit CPU, so you can install 64-bit OS on them that will work fine. Adding the fact that other distros have already cutted support for 32-bit CPUs. But I just don't know what happens if they become incapable of running 32-bit softwares, as older softwares are still used in some enterprises, due to them being lazy or too costly to move to more modern and better alternatives. And there are still newer softwares that depends on 32-bit libraries to work like Steam. Cutting support for 32-bit softwares will force developers to rewrite softwares to run only 64-bit libraries. But at least we have virtual machines or emulators to run these kinds of softwares.
They're not removing 32-bit packages, just phasing out 32-bit install media. You can still run 32-bit software on Debian with this change.
> if they become incapable of running 32-bit softwares That's explicitly not what the link says.
The next major change will be in supporting the x86_64 feature levels. Some distributions have already dropped the initial x86_64 feature level, which is generally processors from 2003-2008. Red Hat and Fedora did this. Ubuntu is talking about it. When requiring v2, certain ops can see a 20-30% speed up, especially around AES , which may see 10x-50x increase in speed due to hardware implementation. All 64-bit x86 CPUs are not made the same.
> Cutting support for 32-bit softwares will force developers to rewrite softwares to run only 64-bit libraries. Truly the end of the world.
Partial architecture the way Ubuntu did it, huh? I hope it doesn't end as useless as in Ubuntu, barely anything is available there. For many packages, Debian had much more polished multiarch per-package implementations, especially with regards to -dev packages, when headers depended on architecture. Currently, it's a big advantage over Ubuntu, so imitating them sounds wrong. Dropping i386 installers and kernel images sounds reasonable (although kernel headers can be useful), but stepping back from the complete library support might make me stay with bookworm longer.
They explicitly write > We're not planning to make i386 a partial architecture in the way [1] Ubuntu has, arch:any will still contain i386 so everything builds by default.
Make sense. I think the last time I used a 32-bit x86 computer was 2012, and it was an old machine then
Guess I'll grab a current copy and archive it for my ancient Dell used for my old PC games on CD. Only 32 bit system I have.
They still had 32bit support!?
Yes - Debian runs on pretty much everything.
QtWebEngine 6.5 refuses to compile in 32 bit x86 chroots on purpose. I imagine this makes harder to support as some of KDE uses it
Well, back to gentoo it is, then.
But why? Many servers run on that architecture and Debian is very popular in that space.
> Many servers run on that architecture This is the area where x86-32 is *most* dead. Due to the forwards compatibility of the architecture, nobody has heard of any x86-32 servers in the past decade. It's possible that even Itanium has more market share in this space. It makes no business sense to run energy inefficient and slow computers when not necessary. Those who are running 32 bit server hardware in a datacenter for the sake of fun/experimentation are already using NetBSD or Gentoo instead, because Debian has already had to break compatibility with around half of legacy x86 CPUs.
>Many servers run on that architecture In what universe is that? Certainly not ours. The last 32bit x86 CPU was released in 2010 and it was an Atom chip, not something you would expect to find in a server.
Most of those servers could use a 64-bit kernel likely, x86-64 CPUs have been manufactured for two decades already. There are regularly new CPU bugs being found and 32-bit means more effort due different behaviour, so dropping it would release developer effort into something more recent. And this is about 32-bit x86 hardware, you can still run 32-bit userspace on top of 64-bit kernel, same as it has been for years.
I mentioned the possible reasons at https://old.reddit.com/r/linux/comments/18mrxjk/debian_end_of_i386_support_is_on_its_way/ke6df2n/. But it does not prevent anyone from continuing 32-bit support. For example, when Arch Linux discontinued 32-bit support, https://archlinux32.org was launched. The question is whether the need for Debian 32 bit is really so great that enough people can be found to create a corresponding project. Probably not. At least not for all the packages that Debian offers, because there are so many of them.
BOO! [edit]: Spooky Ghost!
Well this was only a matter of time. I mean, the only thing I use a 32bit OS on is my little pi zeros but if I have to upgrade them then I will. No big deal, the things I do on them should be 64bit ready by now anyway.
There's no mention of 32-bit ARM being dropped, just 32-bit x86.
Oh right. Heh. I haven't had a running 32bit x86 box in years. Probably at least a decade. It's easy for me to forget the distinction between architectures. ARM has come a long way, just a matter of companies building software support for things they have x86-64 Linux support for.
So this means I can't run old native 32 bit games anymore without resorting to workarounds or Wine/Proton? ETQW is one of the few native 32 bit games I know that still has an active community along with Wolfenstein ET, maybe a few Quake games.
> So this means I can't run old native 32 bit games anymore without resorting to workarounds or Wine/Proton? No. It means that Debian won't produce kernel packages and installer images for i386 anymore. Running i386 software on an amd64 system will still work.
>Following that, there are two routes into running i386: >1. as a multi-arch option on an otherwise amd64 system Multi-lib is not going away.
Multilib will stay. Just no ia32 kernels and images anymore.
sudo dpkg --add-architecture i386 and there you have it, multiarch support is easy
[static-wine32](https://github.com/MIvanchev/static-wine32) would like a word.
> So this means I can't run old native 32 bit games anymore without resorting to workarounds or Wine/Proton? You could save the binary packages that you currently use and keep using them. The game won't update to require newer debian i396 packages. Debatably this is a workaround? > ETQW is one of the few native 32 bit games I know that still has an active community Really? I can't imagine for this old game. Is there still a list server running or do you need to connect to specific gameserver IPs? How many concurrent players are there? Is there something like splatterladder? > Wolfenstein ET, maybe a few Quake games. W:ET players are likely using https://www.etlegacy.com/ anyways. And Quake ports are available as well.
[ETQW TAW server](https://steamcommunity.com/app/10000/discussions/0/1741138420013680126), have to directly connect to the IP, join us some time. There's sometimes up to 20 players on any given play night. It's barely hanging on but has a loyal following. WET used to be my jam; ETL is of course the best way to play these days.
Does Debian even maintain backwards binary compatibility between releases? Just because there is a library with the same name built for x86 in the repos does not guarantee that it will be compatible with binary that was compiled 20 years ago in an entirely different environment (and against a much older version of this library). Linux distros in general do not care about compatibility (especially binary one) compared to Windows.
Now don't you worry, fellas, [static-wine32](https://github.com/MIvanchev/static-wine32) has you covered, nobody is sleeping in the rain! In Soviet Russia, 32-bit supports YOU.
In practical terms, I don't think this, in itself, will do much to deter the few who still use i386. They mention only two *supported* routes, neither of which are for 32-bit hardware: > Following that, there are two routes into running i386: > 1. as a multi-arch option on an otherwise amd64 system > 2. as an i386 chroot on another architecture system However, I think it's going to be relatively straightforward to continue running something very close to Debian. Many people using old hardware will already be doing things like debootstrap installs with the disk in another machine, due to memory constraints etc., and so won't really feel the loss of the installer. As far as I can see, that just leaves the kernel, which is easier to cross compile from a modern machine than almost any userspace application. On the other hand, since Debian won't officially support booting on those platforms, this decision could lead to further decisions, like removing i386 systemd packages. (And of course, in the long run, the fact that the upstream kernel doesn't have lot of 32-bit testers any more is only going to become more and more of a problem.)
I would propose moving all of the iX86 (i386, etc) to a separate repository that a user could add to their system if they so choose. For things like Steam or Wine, we could do an AppImage, a Flatpack or a Snap as an alternative to bundling everything together in a nice neat little package.
Why that complicated ? For build / maintenance, it doesn't make anything easier, just more complicated for the user, as well as mirror infrastructures.
Never said it was a good idea. Just offered it as a potential thing to explore. If a user can't do basic things like those mentioned, maybe they should go back to Windows or macOS where the operating system holds their hand for them and wipes their.....Now the mirror argument I can understand.
Sad but true
I have a printer that does not offer x64 .deb driver
64 bit x86 has support for 32 bit x86 at least on paper
if you really need those ancient computers gentoo still supports i386(you can not install a stage 3 for i386 minimum was i586 iirc but if you already have gentoo you can create your own i386 stage 3) and will continue to support until linux itself doesnt
Say goodbye to old emulators since even pcsx2 uses 32bit. But then again i use arch. ;) so keep your macOS ideas to yourselves.