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".
Gary Johnson? Jill Stein? Why pretend there are only 2 candidates?
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
The majourity of ARMs sold are still 32 bit, and there is no reason for an embedded system to go 64 bit, usually.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Read TFA. Nobody's killing 32-bit libraries. Only .ISOs for 32-bit CPUs.
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.
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!
At some point we are going to want drop x86_32 kernel support and just have 32-bit compatibility libraries, but I don't know when that makes sense.
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.
Define "normally"... On a busy web-server, for example, the number of simultaneous connections is limited by the maximum number of sockets and files, that can be opened and processes or threads, that can run. All of those structures have lots of pointers... And even where they don't, the alignment optimizations often pad them, leading to (much) bigger sizes. For example, right now on my two FreeBSD-boxes:
sizeof(FILE) i386: 236, amd64: 312 sizeof(struct socket) i386: 424, amd64: 696 sizeof(struct proc) i386: 776, amd64: 1272So, if you use Apache, which uses a process (or even a thread) per active connection, you need about 50% as much memory for the same number of simultaneous connections.
Something similar can be said for Firefox and any other user application.
Those registers are largely available to 32-bit processes — just specify the right -march to your compiler. Yes, 64-bit mode does give your something — no question about it. Point is, it is not free...
In Soviet Washington the swamp drains you.
Read TFA. Nobody's killing 32-bit libraries. Only .ISOs for 32-bit CPUs.
The fine article says
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.
This suggests it's not just the ISOs that they plan to get rid of but also support for 32-bit applications, which includes Wine (for running 32-bit Windows applications). So yes, that's pretty worrying for Wine as a lot of Windows applications are either still 32-bit only, or depend on a 32-bit installer. Furthermore, one of the great advantages of Wine is that you do away with all the annoyance that are VMs. So using "containers or virtual machines" is really not much of a solution.
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.
Many of the Atom based notebooks are 64 bit compatible with a minor performance loss.
I think you're wrongly painting the entire embedded space with the same brush. I work in said space. Sure there are toaster controllers or whatever that would happily run on an 8 bit pic, but honestly there is a lot more heavy duty stuff going on than that in the majority of the embedded world.
At least everything I've worked on in the last 20+ years would have benefited from 64 bit/moar powa!!!.
How the hell did this nonsense get +4 Informative?
> So, if you use Apache, which uses a process (or even a thread) per active connection, you need about 50% as much memory for the same number of simultaneous connections.
Um, no. You need an extra 1272-776=496 bytes per connection. The size of a "struct proc" is negligible compared to the total amount of memory each process will use. More generally, memory used for kernel structures is negligible compared to user-space memory consumption.
The difference between 32-bit and 64-bit pointers is going to vary between substantial (but still nowhere near double) for code which uses pointers extensively (e.g. high-level languages such as Python, PHP, Java, JS, which use pointer-to-object everywhere), and negligible for programs whose memory consumption is dominated by large arrays of primitive types (char, int, float).