The headline makes it sound like they're dropping support for just the i386 architecture (as opposed to other x86 architectures, e.g., i686). The linked article makes it sound like they're dropping support for the 32-bit x86 platform entirely.
Are Ubuntu's 32-bit x86 packages limited to those targeting the i386 instruction set? As in, "we ship x64, or ancient i386, but nothing in between"?
Or do they use the i386 moniker used as an umbrella for all x86 architectures?
This is very confusing, but is standard naming convention for Debian/Ubuntu. Basically i386 means x86_32 and amd64 means x86_64. Why they can't use the latter is beyond me. True i386 doesn't even work with recent Linux kernel and Glibc. i386 in Debian-speak is actually i686.
It makes more sense when you look at the history: i386 has been around for going on three decades and was originally the only x86 architecture. When the world started to go 64-bit, Intel was pushing Itanium as IA-64 as the top-performance option which could go head to head with high-end 64-bit RISC processors such as Alpha, PA-RISC, PowerPC, SPARC, etc. They attempted to rebrand x86 as IA-32 as a marketing exercise to match IA-64, both to demarcate it as the lesser architecture and to continue making the competing x86 vendors look less legitimate to business customers.
AMD was the first to develop and announce a 64-bit x86 extension back in 1999 and since they shipped the first hardware, the amd64 name distinguished it from Intel's IA-64. When Intel wrote off IA-64 and adopted AMD's extensions the “amd64” name was already used in a number of places.
Random question.. they use i386 as their internal name.. but you can't actually run it on an Intel 386 right? I was under the impression that modern Linux kernels needed a Pentium Pro or newer.. meaning i586 or i686 would be more accurate?
IA-32 would imply it'd run in any IA-32 processor, the same as i386 since later versions are backwards compatible up to there, so they're functionally the same.
It won't run in i486 or i386, though, so they're both inaccurate names
I386 as an architecture, not a CPU family line (although they have a relationship). In this context, it means dropping 32 bit application support in favor of 64.
I'm a little confused by the FAQ post in the linked article. Some of the questions make it sound like 32 bit software will also stop working? Are the compatibility packages going away too?
This would have some crappy implications for Wine and games in particular.
You need the 32 bit wine binaries to support 32 bit Windows apps, so if they get removed, you'll need to install the 32 bit libraries manually, or perhaps someone will provide PPAs.
> Q. How can I run 32-bit Windows applications if 32-bit WINE isn’t available in the archive?
> Try 64-bit WINE first. Many applications will “just work”. If not use similar strategies as for 32 bit games. That is use an 18.04 LTS based Virtual Machine or LXD container that has full access to multiarch 32-bit WINE and related libraries.
Upgrading from Ubuntu to Debian solves this one among other problems. Ubuntu comes from a company, Debian from a community; the main difference being that companies must be kept profitable, so they will axe any piece of the product that won't be or appear as profitable to them, either because it doesn't sell, or because it consumes resources (developers time).
To be fair, Arch dropped i686 years ago. How many people are really stuck on 32 bit? & if companies are so quick to axe things, why is Windows still offered on 32-bit where it'll run many 16-bit programs?
Your post is really slanted "upgrading to Debian", "Company vs Community", suggesting that profit goes against the user's best interest
I'm writing this as someone who uses Arch at home & Debian at work
Say, what's the state of fanless dual (or even triple) NIC boards these days? Intel network chips please, the CPU can be whatever. It looks like I need one that does 64 bit before 18.04 runs out of support.
I've got a pc-engines apu2c4. It's a great little x86_64 PC with 3 Intel NICs. I used to use it as my primary router, and today I'm using it as a development platform for a custom router OS based on Fedora.
There's also the espressobin, which is an AArch64 board with 2 NICs, one attached to a Topaz switch. The espressobin has mainline Linux support, which is awesome.
You still have 3+ years until free security support runs out in 2023. But that said, check out this QOTOM fanless unit that has 4 Intel NICs with a Celeron J1900 64-bit processor. I can attest that it works great as a home/SMB router with Sophos XG (although you could use Ubuntu if you wanted). Just add memory and an msata SSD. There are similar models available on Amazon too with varying hardware configurations.
Thanks for the suggestion (amazon reviewers aren't so happy with it though). I want a motherboard not a NUC-like system though. Still using sata, running some servers on it etc.
A few years ago I went with a SuperMicro MBD-X11SBA-LN4F as a router motherboard. It has held up well with excellent VPN performance and a high level of stability with a few hundred megabit home internet connection. A fairly similar model would be the MBD-A1SRi-2758F. Both of these are Mini-ITX compatible so its easy to stick them in whatever chassis you want.
The CPU may be, but the bios and motherboard... possibly not so much. The system is pretty old and could use a replacement anyway before it croaks on me.
I think Valve were already forced to go 64 bit on MacOS. At a certain point I have to imagine that releasing a 64-bit client will be the path of least resistance.
For one thing, new games on Linux should no longer be targeting a platform that should have been phased out before Steam even launched on the OS.
And people will no longer need a duplicate set of libraries on their machines, all the way down to the gfx drivers. New software, and old stuff with 64-bit support, should have a lot less compatibility issues.
Readit News
Are Ubuntu's 32-bit x86 packages limited to those targeting the i386 instruction set? As in, "we ship x64, or ancient i386, but nothing in between"?
Or do they use the i386 moniker used as an umbrella for all x86 architectures?
AMD was the first to develop and announce a 64-bit x86 extension back in 1999 and since they shipped the first hardware, the amd64 name distinguished it from Intel's IA-64. When Intel wrote off IA-64 and adopted AMD's extensions the “amd64” name was already used in a number of places.
https://en.wikipedia.org/wiki/IA-32
i586 / i686 are later iterations of IA-32
It won't run in i486 or i386, though, so they're both inaccurate names
This would have some crappy implications for Wine and games in particular.
> Q. How can I run 32-bit Windows applications if 32-bit WINE isn’t available in the archive?
> Try 64-bit WINE first. Many applications will “just work”. If not use similar strategies as for 32 bit games. That is use an 18.04 LTS based Virtual Machine or LXD container that has full access to multiarch 32-bit WINE and related libraries.
Your post is really slanted "upgrading to Debian", "Company vs Community", suggesting that profit goes against the user's best interest
I'm writing this as someone who uses Arch at home & Debian at work
Say, what's the state of fanless dual (or even triple) NIC boards these days? Intel network chips please, the CPU can be whatever. It looks like I need one that does 64 bit before 18.04 runs out of support.
Edit: x86_64 CPU please, not ARM.
There's also the espressobin, which is an AArch64 board with 2 NICs, one attached to a Topaz switch. The espressobin has mainline Linux support, which is awesome.
https://www.amazon.com/gp/product/B01KX9OU58
Thanks for the suggestion (amazon reviewers aren't so happy with it though). I want a motherboard not a NUC-like system though. Still using sata, running some servers on it etc.
https://www.hardkernel.com/shop/odroid-h2/
https://askubuntu.com/questions/877703/only-32-bit-distros-a...
The CPU may be, but the bios and motherboard... possibly not so much. The system is pretty old and could use a replacement anyway before it croaks on me.
And people will no longer need a duplicate set of libraries on their machines, all the way down to the gfx drivers. New software, and old stuff with 64-bit support, should have a lot less compatibility issues.