48
Linux kernel will soon drop ~~i386~~ (32-bit) support
(web.archive.org)
You're using a 386? Dont make me laugh
This isn't talking about the microprocessor model from 1985, if that's what you're thinking.
Rather, that microprocessor was the first to introduce the x86 32-bit architecture, which is getting discontinued here.
So, that includes some hardware still manufactured in the early 2000s...
Yea I have a 32 bit machine from 2007.
That’s quite interesting because the spy chips¹ began in 2008ish. So people who avoid the spy chips are losing options. ~~There may not be many 64bit machines that pre-date the spy chips~~ (edit: there might be a 5-year span of 64-bit AMD spy-free chips). I’m lucky to have a machine from 2008 just before the anti-consumer chips came out. IIUC there is only one modern architecture that avoids the spy chips: the IBM Power11.
1: spy chips → Intel’s Management Engine/ARM trustzone/AMD’s Platform Security Processor; tech that is anti-non-corporate consumer
Um.... Are you referring to the most ubiquitous OS worldwide nowadays... Minix?
Referring to Minix was not my intent. A short overview of the issue is here. As you apparently know Intel chips after 2008 use Minix for the management engine but I’m not sure to what extent Minix itself is a factor the vulns. The problem is the mere existence of an attack surface hard-wired into processors that can be externally exploited when the purpose of the ME is useless to non-corporate users. Bugs have been discovered that enable attackers to install malicious firmware¹. AMD’s PSP is also a problem and I don’t know if the PSP OS has been revealed. PSP is composed of an ARM processor with Trustzone, but I don’t know what OS Trustzone uses.
I just realized I forgot AMD PSP did not hit until 2013, so I guess there must be a lot of 64bit spychip-free boards out there made from 2008—2013.
1: ⚠ that link is enshitified with autoplay so I suggest using Lynx to access it.
No, that is not what it means. i386 is specifically the set of instructions that the 386 introduced. Later processors from intel added additional instructions, those were rolled into i686 as a set. i686 contains i386 so it can still run programs that target that, but a 386 can't run a i686 program.
i386 and i686 are both x86 32 bit instruction sets.
What is happening is that the kernel will no longer support i386 as a target. So any processor that does not support at least i686 will stop working. This is basically anything before around a pentium 3 (iirc might be wrong about exact CPU.) Vista era computers should not be effected.
The confusing part is that some distros have already dropped all 32bit for other reasons, but it would mean it would be hard for distros going forward to support 386 era processors.
The Linux kernel dropped i386 support back in 2012: https://www.phoronix.com/news/MTI0OTg
I think any reference to i386 nowadays really refers to i686. Debian, for example, officially dropped support even for i586 with Stretch back in 2017: https://web.archive.org/web/20170701011018/https://www.debian.org/releases/stretch/i386/release-notes/ch-information.en.html
So I think the linked article really does mean that they are dropping all 32-bit x86 support.
It pairs well with my RTX4090 :D
I think your GPU might be bottlenecking you.
Your windows boots up in what, a day and a half?
The CADT model at it's finest. It's funny because Linux is considered the de facto choice for legacy hardware because it runs so well on it, or at least used to. The fact is the development model used by distros (and apparently also the Linux kernel as well) is absolutely awful, and it inevitably hurts movements that depend on it such as Permacomputing.
So it's interesting reading all the folks talking about permacomputing and the like.
And I think there's merit to keeping those architectures around.
But let's turn this on its head, shall we? Where do we get the people who still have that hardware who are willing to actively take part in Linux kernel development?
Like, to become facile enough with the process, tools and codebase to be able to bear the load of writing new security patches as vulnerabilities are found?
It's a hard problem. The number of people actively contributing to Linux is large in aggregate but VANISHINGLY small when it comes to any particular area of interest.
bad news for permacomputing folks
it can still be custom compiled in, right?
I don’t have a deep knowledge of the kernel to know if it’s as easy as simply adding in a separate module.
this post was submitted on 27 Dec 2023
48 points (91.4% liked)
Permacomputing
248 readers
1 users here now
"In a time where computing epitomizes industrial waste, permacomputing encourages the maximizing of hardware lifespans, minimizing energy use and focussing on the use of already available computational resources." (from the permacomputing wiki)
See also: !permacomputing@slrpnk.net
founded 1 year ago
MODERATORS