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".
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
I don't happen to know, maybe someone has figures. But I would have thought that the 32-bit x86 embedded linux market was quite large.
Nullius in verba
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.
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.
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!
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.
First, addresses/pointers aren't normally the largest chunk of code or data memory usage, so the include in RAM usage is far less than double.
Also, in the specific case of the Intel x86 architecture (which is what this is about, not general 32 bits vs. 64 bits), there is a significant reason to move from i386 to x86_64. The i386 architecture has a very small CPU register set, compared to most modern CPU architectures (and some instructions can only use certain registers). That means lots more things require memory loads/stores, which is bad for performance. When AMD created x86_64, they added a bunch of registers (and got rid of most of the usage restrictions), so 64 bit code performance is better.
What the hell? 32 bit cpus are everywhere. The article is talking about PC builds, x86 clones in other words, only a Wintel person actually thinks that is the only arcthitecture out there. Meanwhile if you look at the Linux kernel it has 29 different architectures it supports.
I assume the computer name is Theseus.
RETURN without GOSUB in line 1050