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
openSUSE dropped IA-32 builds from their brand new releases, and the Ubuntu community is talking about it (nevermind that 16.04 will support their IA-32 build for another five years). It's still supported by CentOS and Debian and lots of other distros. In short, saying you're shit-outta-luck is totally not accurate.
Why not just drop the boot 32bit part and only have the compact 32bit libs. Like how windows server 2008 and newer is on the windows side.
Why cut off apps that can run today on a 64bit system with out needing any vm bs.
If you had read TFA, you might have found out that's exactly what most Linux distros are doing. 32-bit library support isn't going anywhere, just .ISO builds for the i686 and older.
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."
Gary Johnson? Jill Stein? Why pretend there are only 2 candidates?
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
They can still test the software on "better" hardware. They can also run it in a VM. That's what they expect everyone else to do.
It may not be "optimal" but it's certainly possible.
That's not even getting into the fact that they aren't really trying very hard to find 32bit x86 hardware.
A Pirate and a Puritan look the same on a balance sheet.
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.
My poor old Acer Netbook, 7 years old and going strong, isn't 64 bit, and runs Linux Mint very well. Oh no, what shall I do?
Really, there will be 32-bit compatibility for a minimum of 5 more years (Mint 18 support cycle) and by then ... maybe the Acer will deserve retirement.
Specifically IA-32 hardware, not anything 32-bit.
I don't disagree with a decision to drop support for old hardware, but what about some other level of support using emulated hardware to at least give some degree of support?
I think you're missing what the point of "support" is. A company can release a binary and say they support it, without testing it and not fixing any bugs for it, but that makes them look like assholes.
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.
At least for intel Archs, you can install a 32 Bit OS on a computer with a 64 bit capable cpu.
Which doesn't mean squat. We're talking Q.A. here.
The goal is to determine whether the code will work on a real 32-bit architecture, not a 64-bit architecture running in 32-bit emulation mode. The two have differences. If you run the tests on something other than the real target you have no clue whether it will work on the real thing.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Second, it's funny how the democrats complain about money in politics yet they are the biggest recipients from unions, businesses, and now international entities.
Funny how much Republican money is sitting on the sidelines because Trump is the nominee.
If they expect "every one else" to run 32 bit software in VMs, they actually should test their 32 bit builds in VMs.
"The devil is a squirrel" as we say in german ...
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."
No reason to stop. If it does what you need, go ahead. I'm sure source-based distros like Gentoo will still be fine. Distros that focus on long term support like CentOS and Debian will probably still provide a 32-bit distro as well.
I would also like to point out that your 10-year-old laptop is having trouble now. Add another 7 years to that and you will be compounding those problems dramatically. I don't see any (desktop or laptop) computers around from 1999 that are terribly useful today. Some parts from a 15+ year old PC are hard to find nowadays (unless you have a huge stash or like risking your money on feebay.) Think IDE hard drives and DDR1 or SDRAM.
"Frequently wrong, never in doubt."
Embedded, IoT and robotics are awash with 32 bit x86 stuff.
How many of those run Ubuntu or OpenSUSE?
Is that when you started or when it finished? I'm asking because it might have been Gentoo.
I started in 1997 with Debian in a book distro. Ran SUSE for many years. Used Ubuntu, Fedora or Mint at work, depending on whatever was popular with the engineers. When I worked at Google, I used Goobuntu (Ubuntu variation). These days I'm banging on Red Hat Linux to see if I want to go for the certification.
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!
A [Washington, ..., Lincoln, ..., Obama] Presidency will be the end of the republic.
FTFY
Yes, you can run 64-bit software on it, but should you?
Yes you should, without a doubt, unless you know for sure the main bottleneck for your application will be memory.
The 64-bit modes offer more registers, and instructions that can do more operations per cycle as well as other optimized instructions. In most cases the performance will be much better!
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
"doubles our testing burden (actually, more so, do you know how hard it is to find 32-bit hardware these days?)" I can find 32-bit hardware easily. Obviously, someone who didn't try and claims it not possible.
Agreed. There is a lot of hardware - even new hardware - that is 32-bit; while especially the case in non-x86 systems, there is even x86 systems that are still being shipped in 32-bit mode (e.g 32-bit OS) by default or are 32-bit only, especially in the embedded world - and yes, many of those embedded devices may still operate a GUI interface.
Example: A previous employer was converting from DOS to Linux. We had a GUI interface and the developer just loaded up X-Windows (GNOME I think) and then made a full screen GUI app on top of that. The basic use case was an embedded system (VMIC 7805 Board, Pentium M, - which still sells new) and we were using Ubuntu 8.04 as a base at the time (8.04 was newly released). (FYI VMIC 7805 runs a number of difference OS systems from Windows, Linux, VxWorks, and even DOS.)
So yes, this guy is extremely short sighted - probably looking at MicroCenter or Best Buy and saying "well, no 32-bit systems here, guess we can't buy any". There is plenty of manufacturers you can find to build a 32-bit only system that are desktop oriented.
Now, where it may get harder is finding a 32-bit system that is server oriented since most server builders are looking towards packing in the memory beyond the capabilities of a 32-bit system. Even so, Canonical should have no issue there since they are also doing some system building and could just build their own for their dev farm or just build images in 32-bit only mode to be tested in servers in a datacenter running VMWare, KVM, Xen, etc - a 32-bit guest OS is no issue in a 64-bit host environment.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Well yes and no, there are some surprises from time to time. Like you might expect passing arch=i486 to gcc would give you code that would run on a 486, not always unless you pass other options as well. The problem is testing on the latest x64 chip means you are going to have a super set of the the i686 ISA in most cases, and with the wrong compiler flags or kernel build options, you might discover it really does not work on older hardware.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Now, where it may get harder is finding a 32-bit system that is server oriented since most server builders are looking towards packing in the memory beyond the capabilities of a 32-bit system.
The whole argument is nothing more than a straw man. All you have to do is have a multi-boot system where one of the images is 32 bit. Sure, you won't be able to take advantage of all of the RAM, but it will run, just fine. And, you can have one using a PAE kernel so that you can test programs in that environment as well. (Yes, people do use PAE. It's for when you have more than 4 GB RAM but either don't want to nuke, pave and reinstall a 64 bit system or can't because you can't afford the downtime. All you need to do for that is install a PAE kernel and support packages, reboot into it and later, remove the non-PAE packages. And yes, I'm writing from personal experience.)
Good, inexpensive web hosting
and:
DES hasn't changed, but the amount of computational power attackers can bring to bear has.
... but they'll do nothing but die when a bomber drops its weaponry inside the walls.
Or to put it a different way: archers manning a castle's walls were a decent defense against melee soldiers
I felt a great disturbance in the Force, as if millions of Intel Atom netbooks suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.
AKA, my netbook :(
Old Intel Atom processors won't run 64-bit code. My firewall/gateway machine is running an nice but old nano-ITX motherboard with such a processor. I had to download debian's 386 build to get it to work. So, I hope debian at least keeps the 386 build for a while.
—G
Hillary has sold uranium to the Russians and military communications secrets to the Chinese. The risk of a Hillary presidency is the military defeat of the U.S. and the accompanying millions of dead Americans.
Contribute to civilization: ari.aynrand.org/donate
Donald Trump only has something like 20% odds, yet he'll probably get more than 1/3 of the popular vote. I say if you don't like Hillary, "throw your vote away" on a third party and not someone who has a 9-year-old's solution to immigration and runs a campaign targeting Archie Bunker.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
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
So? Reagan sold a lot of stuff to Iran and even Hezbolla.
"Treason doth never prosper, what's the reason? For if it prosper, none dare call it Treason."
The headline is click-bait, but they are referring to intel 32 bit CPUs. I see no plans to drop arm 32 bit support, since arm64 is still in its early days.
I remember when a kernel build was an all-night job (on a machine with four megs of RAM).
-- Ed Avis ed@membled.com