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 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
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.
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.
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.
All true. But offset by the decreased performance of dealing with 64 bit pointers, it's mostly a wash. This is actually why Linus created the x32ABI https://en.wikipedia.org/wiki/X32_ABI to get the best of both worlds. Largely I think it's forgotten though.
32-bit posix dates use Jan 1, 1970 as the zero point. The maximum range is...
-2^31 seconds to
(2^31) - 1 seconds
from Jan 1, 1970, 0000 hr
Try the following short bash script
#!/bin/bash
date --date="@2147483647"
date --date="@2147483648"
date --date="@-2147483649"
date --date="@-2147483648"
On a 32-bit linux system (real or VM), you get...
Mon Jan 18 22:14:07 EST 2038
date: invalid date '@2147483648'
date: invalid date '@-2147483649'
Fri Dec 13 15:45:52 EST 1901
If you're a bank amortizing 25-year mortgages, you're already running into problems on a 32-bit linux. On a 64-bit system you'll get...
Mon Jan 18 22:14:07 EST 2038
Mon Jan 18 22:14:08 EST 2038
Fri Dec 13 15:45:51 EST 1901
Fri Dec 13 15:45:52 EST 1901
The wraparound date for 64-bit time_t is 15:30:08 on Sunday, 4 December 292,277,026,596 by which time I don't expect to be around.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
Because with 16-bit pointers, you are limited to process-sizes of 65Kb only, which is too small. 32 bit gives you enough of process virtual memory.
As I said — Moore's law gave computers, that are 4096 times more powerful today, than what we had 18 years ago. Would you say, user experience is 4096 times better today, than in 1998?
No, it is not. It is a lot better, but on that scale, however you measure it. Various things continue to suck as they did before: databases and applications still want more memory. In 1996 I would take me three days to rebuild FreeBSD "world" — today it takes 3 hours. A 24-times improvement, instead of 4000-fold.
Where did the hardware-gains go was my question and "developers ate it" is my answer. Every time somebody makes a choice of "complicated but efficient" vs. "simple but hardware-demanding" towards the latter, the users lose. Every time you choose Python/Java/Go/Scala over C, you sacrifice some hardware of all of your users for your own convenience.
Yes, of course. But you don't have to switch the OS to 64-bit to make use of those hardware capabilities. And even where you do, that may be the user's choice — developers should not be forcing it. Certainly not for the bogus reasons like "we can't find i386 hardware"...
In Soviet Washington the swamp drains you.