SoylentNews is people
SoylentNews
Ubuntu seems to be poising itself to letting 32-bitters alone in the dark:https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html
in 2018, the question will come if we can effectively provide security support on i386.
cross-grading between i386->amd64 is not something we can reliably ship. We must continue [to] provide the i386 port, to support multiarch and 3rd party legacy application that are only available as i386 binaries.
Building i386 images is not "for free", it comes at the cost of utilizing 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. As well as take up mirror space & bandwidth.
Thus the question is what can we and what should we do to limit i386 installations before they become unsupportable?
In essence this would mean April 2021 as the sunset for i386 as the host/base OS architecture. And April 2023 to run legacy i386applications with security support.
I do use, from time to time, a (then, in 2009) top-of-the-notch 3.4GHz P-IV, for the little gaming I do and for printing. But I did notice even it is easily overwhelmed by many javascript-laden sites. How many soylentils are going to fight tooth and nails to keep their 32 pc's up and running beyond 2018, are 32 bit platforms of any relevance today aside as for IoT or CNC processes?
(Score: 2) by bitstream on Wednesday July 06 2016, @03:36AM
This "to support multiarch and 3rd party legacy application that are only available as i386 binaries" can be solved by providing an API or binary emulation layer. Considering that modern computers are way faster than the original CPU series.
IoT and other platforms that actually need to run 32-bit on the metal may have to use another solution.
(Score: 2) by Pino P on Thursday July 07 2016, @12:24AM
My personal use case involves Xubuntu on a 1.6 GHz Atom netbook for which Wine is just barely fast enough to run free Windows-only applications (FCEUX debugging version and FamiTracker) at full speed. An Atom is roughly as fast as a P4 clock for clock but sips much less power. An actual emulator (like DOSBox) on an ARM or x86-64 wouldn't come near keeping up.
(Score: 2) by bitstream on Thursday July 07 2016, @12:28AM
Not possible to use protected mode environment where the 32-bit code is run natively on the 64-bit platform?
(Score: 2) by Pino P on Thursday July 07 2016, @01:03AM
Either way would still need some i386 libraries installed. There is a purist on another forum I use who refuses to use Wine because of all the :i386 libraries Wine brings in. He would actually prefer to debug programs in a 64-but Linux-native emulator with no debugging capability by debugging the emulator itself than to install Wine for the debug-capable emulator, even if the emulator is free software.
(Score: 2) by bitstream on Thursday July 07 2016, @02:40AM
Can't run the libraries in i386 mode then?
(Score: 2) by Pino P on Thursday July 07 2016, @03:04PM
Can't run the libraries in i386 mode then?
No.
When it was suggested that this person install the i386 libraries for 32-bit Wine, the reply [nesdev.com] was
When it was suggested that the existence of X11/Linux distributions smaller than 200 MB proved that i386 libraries weren't necessarily "several gigs", he replied [nesdev.com] that running FCEUX SDL inside GDB "took me much less time than setting up a 32-bit chroot, and wasted no space." (FCEUX, an NES emulator, has a Win32 version with a debugger and an SDL version with no debugger.) In fact, he later said [nesdev.com] he'd rather write a debugger from scratch for FCEUX SDL than install anything 32-bit on his computer's storage. I myself use FCEUX SDL most of the time, breaking out Wine when I need to single-step execution.
I initially considered dismissing such 64-bit purists as crazy or eccentric [wiktionary.org]. But the plan expressed in the featured article was to drop i386 libraries from the repository entirely as of 18.04, instead relegating them (and thus Wine) to a container of some sort, indeed "a 32-bit chroot".