Slashdot Mirror
Linux Letting Go: 32-bit Builds On the Way Out (theregister.co.uk)
An anonymous shares a report on The Register:Major Linux distributions are in agreement: it's time to stop developing new versions for 32-bit processors. Simply: it's a waste of time, both to create the 32-bit port, and to keep 32-bit hardware around to test it on. At the end of June, Ubuntu developer Dimitri Ledkov chipped into the debate with this mailing list post, saying bluntly that 32-bit ports are a waste of resources. "Building i386 images is not 'for free', it comes at the cost of utilising our build farm, QA and validation time. Whilst we have scalable build-farms, i386 still requires all packages, autopackage tests, and ISOs to be revalidated across our infrastructure." His proposal is that Ubuntu version 18.10 would be 64-bit-only, and if users desperately need to run 32-bit legacy applications, the'll have to do so in containers or virtual machines. [...] In a forum thread, the OpenSUSE Chairman account says 32-bit support "doubles our testing burden (actually, more so, do you know how hard it is to find 32-bit hardware these days?). It also doubles our build load on OBS".
I think that the trouble finding testing hardware is quite telling.
Can end users even buy a new, off-the-shelf 32-bit system these days, except for specialized devices like embedded systems?
Is there anything more than a relatively tiny fraction of the user base that is stuck on 32-bit hardware, that can't use virtual machines to run that software on something that's not a potato?
And I mean, it's not like the old 32-bit versions of OS's are gone. Windows 95 is still around. It didn't go away. I'm willing to bet there are still Windows 95 machines running somewhere in mission critical systems in places around the world.
Yes, there's no security updates, but just unplug it from the internet and you're safe from the vast majority of attacks, and if you're worried about local access to your Windows 95 machine... install a thicker door?
At some point technology has to move on.
Check out my sci-fi book "Lacuna" at http://goo.gl/MVxX8
Well, I mean, if you're running Windows 10 right now... uhh.
Lemme rephrase. If Ubuntu 18.10 is 64-bit only, is that a problem? What show-stopping problem for a 2006 MacBook is present in 18.04 but fixed in 18.10?
What's wrong with running 18.04 until the hardware dies?
Check out my sci-fi book "Lacuna" at http://goo.gl/MVxX8
Uh... as more time goes on, more exploits are found in all software, making all systems gradually more insecure. It's almost like there were a universal law governing such things *cough*.
Ubuntu's going to support IA-32 images for at least another five years (EOL for 16.04), probably seven (18.04 EOL). If your IA-32 system is still chugging by then, there'll still likely be Debian and CentOS to switch to.
Well, in 2018, the 2006 MacBook will be 12 years old. 18.04 is an LTS release and will have 5 years of support and security updates. By the time there are no more security patches, the machine will be 17 years old and software exploits will be the least of the user's concerns if it is still his/her main machine.
"Frequently wrong, never in doubt."
The problem is not newly-bought consumer electronics or legacy software. The problem is legacy hardware. I'm still using the Thinkpad I bought in 2006 (4:3 aspect ratio display). Luckily it's a 64-bit processor, but others have older 32-bit machines.
It's also not about the kernel -- Linux itself will support 32-bit architecture for a long while more, and most software will compile correctly on both 32-bit and 64-bit, though it will be less and less true as distributions stop their QA and you are left with only the upstream development team.
Of course, these old machines are pretty few, so it probably does make sense for Ubuntu to drop 32-bit packages. Other more enthusiast-targeted distributions will probably keep 32-bit support. In particular Gentoo compiles everything locally.
Posts like this always confuse me. The terms i386 and 32-bit are not interchangeable. AFAIK, they were only talking about getting rid of i386 architecture (i.e. 20+ year old 32-bit hardware), but would maintain i686 (more recent 32-bit hardware) support.
Then use Debian. While discouraging i386 as default download is long overdue, judging from other old architectures, it'll be a long long time until i386 is retired from the first class arch set, and even then it'll be welcome in second class (AKA debian-ports), among stuff like m68k, alpha or sh4.
Or, use Debian-hurd. It's available for i386 only!
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
So much for Linux being "great for old hardware". This is really just an dubious move by distros and really just ignores a huge area where Linux can see use: Old hardware where Windows wont run. You also have another aspect of this which is your basically trashing 32 bit app support if you do not include 32 bit libraries, or, providing a thunk between 32 bit apps and 64 bit libraries.
Even if 32 bit libraries are not built, you should be able to run a 32 bit app by compiling the libraries yourself, so distros could at least allow people to build 32 bit libraries easily from source packages, (with the benefit of automatically building all dependancies).
Another area this will create problems is with VMs on even recent hardware, Intel chips up to just a year or two ago didnt include VT-x or a Ring 2, which means that virtualization of 64 bit OSs will not work.
I don't even know what all of those are.
That is easy to explain, phantomfive:
All this are little bugs, usually black, with lots of golden legs sitting on the motherboard.
Some of them even have arms as you can see, some are sparcling and the others are of greek origin, like the pentium but I wonder where the monon, and duon etc. are. I guess the alpha is also a greek and the i686 has an extraordinary high IQ, or had ... I believe he is out of service now.
Regarding the 'motherboard' ... I'm not sure if you are old enough to get explained that yet. Considering that there are sometimes daughterboards sitting in strange positions on top of the motherboard ...
Hope that helped!
P.S. the Athlon is a long forgotten Spartan athlete. He always wanted to participate in Pankration at the Olympic games. But alas, Spartians were prohibited to participate in that discipline. (Something with killer instinct or something) So he finally decided to dress like a girl. Seems he did not know that women folk is not allowed at Olympic games either. Sad fate. Really sad.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
We at least need enough 32-bit packages available in the 64-bit distro (whether by dpkg --add-architecture i386, or by installing "lib32" packages like we used to do) to install and run Wine.
You see, to run Win32 programs, your Wine emulator binary needs to be a 32-bit Linux/ELF application. I suppose it could emulate cross-architecture, but wine prides itself on *not* emulating native code generation (for performance). Otherwise it would be as slow as a software virtualization solution like Bochs or (non-KVM) qemu.
Wine, in turn, depends on a number of system libraries for core services. It then implements common Windows APIs "in terms of" available platform libraries. Direct3D in terms of OpenGL; DirectSound in terms of libasound2 or libpulse; etc. These libraries, linked into a 32-bit binary, must also be 32-bit.
I agree that there's no point in testing 32-bit *hardware* any longer, but I hope they continue to ship 32-bit *builds* (even if they stop making 32-bit installation CDs). There's just too much software on the Win32 platform that needs to run on Linux (desktop OR server; see game servers) to abandon this segment of the market.
I bet he's a systemd fan too, the bastard.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
This is certainly a place where *nix excels. I've started mucking around with an old Powerbook G4 because it's easier to carry around than my main workhorse. Debian, Gentoo, and FreeBSD all run on it happily even though it's hard to find new hardware to test on. Gentoo and FreeBSD treat ppc32 as a "second tier" platform - they'll still auto-generate the installers and configure package dependencies, but they won't check for errors during the build, and bugs in ppc32 won't delay a new release. It's up to users to submit bug reports/patches or fix issues as they come up. Transitioning i386 to this level of support is far from the end of the world.
What's there to "find"? You can kick-off a 32-bit VM under any hypervisor — both on the cloud or on your own desktop. You can automate the VM-creation and tear-down on your build-farm quite easily.
I too strongly prefer to have a system, where size_t is equal to off_t (so you could mmap an entire file and not worry about it), but that is not "free". 64-bit pointers are, obviously, twice-wider than 32-bit ones, so "hairy" structures — with lots of pointers in them — nearly double in size. If none of your processes require more than 4Gb of virtual memory, there is no reason — other than the developers' laziness — to go 64-bit.
Whether it is an OS embedded inside a router or a point-of-sale machine, or even a single-user web-and-email desktop, 32-bit is perfectly sufficient and the overhead of 64-bit not justified.
And that laziness is what is keeping us back... Over the last 18 years, according to Moore's law, our computers have become at least 2^12 times more powerful. Now ask yourself, is the user-experience — however you choose to measure it — 4096 times better than it was in 1998? And, if it is not, where did the gains in hardware go?
By refusing to setup/use tens or even hundreds of 32-bit test-systems, developers force thousands and millions of users to upgrade. That is not a fair trade-off.
In Soviet Washington the swamp drains you.
There are a bunch of desktop distributions that will no longer do 32 bit builds. Makes sense.
No effect on kernel or disties for 32 bit systems/embedded/etc.
Is that when you started or when it finished? I'm asking because it might have been Gentoo.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
RPM non-binary package:
noarch
Used for packages that aren't arch-specific, documentation, configuration, etc.
Sun/Oracle:
sparcv9 sparcv9v sparc sparc64 sparc64v sparcv8
sparc is sparc32 v7 abi (or should be... systems: ipx ss2, etc)
sparcv8 is v8+ abi (32 bit with some new instructions, ss4/5/10/20)
sparcv9/sparc64 is sun ultra+ systems (ultra 1 and above with 64 bit processors.)
sparcv9v is (I assume) Niagra chips and above, containing virtualization/containerization tech.
Hitachi SuperH:
sh4 sh4a sh sh3
Not sure what arch 'sh' is (sh2?3?)
sh3/4 were used in some routers and I think the Sega Saturn/Dreamcast/Naomi 1/2 consoles/arcade boards. Have never actually seen one outside a console in real life, although in japan at least there were apparently some routers using them as embedded processors running linux.
ARM:
aarch64 armv5tel armv6hl armv3l armv6l armv4b armv7hl armv4l armv7l armv5tejl
aarch64 is the 64 bit arm extensions. The rest are arm versions from 3 to 7 with different option flags. I think wikipedia has a comprehensive article on what they all mean. Lots of possible binary incompatibilities with arm binaries if you don't build to a specific instruction subset, which almost nobody ever did. v5->7 should I believe be forwards compatible. v6 and 7 definitely are.
Alpha:
alphapca56 alpha alphaev5 alphaev56 alphaev6 alphaev67
DEC's legacy shat all over by Compaq+HP. Better chip than IA64 if they had only produced them on newer processes and provided PC-prices entry level systems to keep developers engaged. China is supposedly producing homegrown knockoffs of these chips for fpu calculations in one of their supercomputers.
x86/x86_64:
geode amd64 i386 i486 pentium3 x86_64 i586 pentium4 i686 athlon ia32e
geode is amd's embedded x86, used in the original released OLPCs and various other embedded systems and devices. Not sure the exact x86 arch it is equivalent to (486->586, and maybe newer arch features)
ia32e I think is the x32 or x86_64 using 32 bit pointer ABI which allows the register file of x86_64 but only using 32 bit pointer references to keep memory usage low for applications that don't require more than 4 gigs of ram.
amd64 == x86_64
And the rest of those are Intel/AMD designations up to to SSE2 (P4) Not sure why they have that many different versions.
Itanic:
ia64 - Nuff said
IBM/Others PowerPC:
ppc64 ppciseries ppc64iseries ppcpseries ppc64p7 ppc64pseries ppc ppc8260 ppc32dy4 ppc8560
32 and 64 bit variants of PowerPC, dating from 90s era Macs to today.
IBM S390:
s390 s390x
Some sort of mainframe/large workstation systems I think. Not sure if the supported models are all PPC derived or not. I believe they run a different microcode layer on top of the cpus intended for mainframe use. Also run a hypervisor(or equivalent) above linux (and predating hypervisor capabilities in x86 by many years.)
Hope that helps! Check wikipedia for further info. They have rather comprehensive articles on all of these!
It's becoming more clear every day how the major Linux distributions have all been drinking the same cool-aid.
Seems so, but as of now 32 bit Linux has 22 years left (year 2038). I heard that may be fixed but AFAIK nothing yet. In any case for 32 bit I would use NetBSD or OpenBSD since the 2038 issue does not exist for them. I would like to know what "major dist" officially includes :) One distro I consider major just released a 32 bit version.
No they didn't. RHEL did, and since CentOS is more or less just a rebuild of the RHEL sources the base CentOS 7 distribution is also 64 bit only.
But CentOS has also has an AltArch distribution for i386. It's right there on the download page if you want it.
I assume the computer name is Theseus.
RETURN without GOSUB in line 1050
Many of the Atom based notebooks are 64 bit compatible with a minor performance loss.