I have a 64-bit machine but I'm running 32-bit Debian because there's no good upgrade path, and I really don't want to reinstall because that would take a months to get everything set up again.
I'm running Debian not Ubuntu, but the absolute minimum they owe their users is an automatic upgrade path.
> but the absolute minimum they owe their users is an automatic upgrade path.
How exactly do you purpose they perform an "automatic upgrade" on their user's hardware? You don't just patch or upgrade to go from 32 bit to 64 bit. You can't hotfix hardware like that.
Personally I would go for unpacking the 64bit userland+packages in a subdirectory, boot once into a rescue userland which just switches the directories around, then boot normally.
GRUB already has support for "boot once in this alternate configuration", so it's all there.
As I said, I'm running 64 bit hardware, and a 64 bit kernel.
But shifting the packages from 32 bit to 64 bit is not supported automatically.
And that despite the ability to install both 32 and 64 bit packages side by side.
It's like they did all the hard part for the upgrade, and just didn't finish that last little bit (find 64 bit versions of existing 32 bit packages, and install them, then remove the 32 bit).
It would still require setting everything up again, but at least once you've done that once you can put the settings in a git repository and be done with it forevermore. Reinstalling is a trivial operation.
It's a lot of work, but it is possible to "side-grade" to 64-bit.
In dpkg, add the amd64 architecture. Install and boot a 64-bit kernel. Then carefully replace 32-bit packages with 64-bit packages. You'll hit a few bumps along the way, but it's possible to do without reinstalling from scratch.
That said, it'd likely be easier to install 64-bit, diff and copy across configuration files, and port over your installed package list (dpkg --get-selections) with a bit of care for packages whose names differ between 32-bit and 64-bit. I've done something similar when setting up new systems, and it's about a half-day's work, not a month.
I actually did this with a debian sid a few years back. I guess I got attached to that trusty system which I moved from PC to PC for years and had a few too many customization.
With my latest PC I went with a clean install though.
Unless you've got some Frankenstein system with lots of random binaries dropped in by hand, it shouldn't take months.
1. dpkg --get-selections 2. Backup global data (databases and such) 3. Backup global config (/etc, /use/local/etc) 4. Backup home directories 5. Reinstall and apply all to the new system.
This is a weekend job at most if it ends up being complicated.
I don't have a new system, I would need to do it in place, on the same system.
I guess I should have clarified that I already have a 64 bit CPU, and 64 bit kernel, but my initial installation is 20 or more years old and has been updated since then, from that same initial installation. (It's even the same initial ext3 filesystem, since I used md raid to shift the installation to new hard disks over time, it used to be ext2, but that upgrade was automatic.)
Debian has the ability to have both 32 and 64 bit packages installed side-by-side.
I.e. they did the hard part. I just need some way to automatically shift each package to its 64 bit equivalent, then remove the 32 bit one, and eventually the libraries too once nothing depends on them.
> I'm running Debian not Ubuntu, but the absolute minimum they owe their users is an automatic upgrade path.
Do you have a support contract? If not, ask yourself about the complexity of what you feel entitled to — especially given that a system which will “take a month to get everything set up again” is far from a clean upgrade — and ask how much effort you've contributed to the project helping make that feature exist.
This announcement doesn't really concern Debian though. Debian still runs on rather ancient stuff like m68k, and I find it unlikely that they will drop i386 anytime soon.
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?
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.
Yes. This is why distros like Gentoo and others prefer building from source. Then you can enable as many architecture specific extensions your compiler supports.
I don't know how much of a difference this makes in practice however.
The justification for dropping 386 support was that it was a maintenance burden specifically for SMP locking primitives, IIRC. Dropping support for other 90s microarchitectures would mean not needing a workaround for the Pentium F00F bug, and having access to SIMD and prefetch instructions that can make things like a memcpy more efficient.
> SIMD and prefetch instructions that can make things like a memcpy more efficient.
Or just use REP MOVS. Modern CPUs recognize it and do optimal memory copy internally. Prefetch instructions are rarely beneficial, and often cause worse performance.
Edit: Apparently AMD Ryzen lacks REP MOVS optimization. SIMD based memcpy performs the best on it. (Intel supports REP MOVS optimization since Ivy Bridge.)
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
>There is lack of support in the upstream Linux kernel, toolchains, and web browser
Except firefox who become useless on 32 Bit after quantum I don’t have any problem with Debian on my netbooks. I am really curious about the “lack of support” in the kernel, Any idea?
Many things, none of them good if you have 2 Gb of RAM, 2 cores and no graphics acceleration.
Chromium works really well in this kind of hardware specially with javascript blocked.
My understanding is that FF Quantum works just fine even on as little as 1GB RAM. (In fact you can make it usable on as little as 512MB, but only with some swap usage.) Chrome/Chromium is a lot more RAM-hungry in my experience.
I remember the glorious days when firefox was not a memoryhog. 700MB for hundreds of tabs. Nowadays it needs 2GB because of the awful multi process model.
Talking about Firefox, I've recently heard some people getting annoyed that Firefox now depends upon Rust and Rust doesn't build on their obscure legacy platform.
I'm in turn getting annoyed at the complete lack of cost/benefit analysis that this entails.
Every software project has to deal with limited resources and the attitude that the vast majority of people running on more mainstream platforms should forsake improvements (in security or usability by Rust for example) in order to support Solaris, Illumos, HP-UX or any of those niche platforms, well that just pisses me off.
I still have a 32bit Debian installation (originally installed around 2003 and been Ship of Theseus-d over the years so it actually has 64bit hardware now) that I didn't have the time or motivation to upgrade, but if 32bit support would go away tomorrow I'd understand. What's the percentage of 32bit vs 64bit users? 0.3%?
The other way to view this is as rich software developers asking the rest of the world to pay to upgrade their hardware, or else forgo security patches. That may be hard if you're in a poor country, or are otherwise living near the poverty line.
Commercial interests have little incentive to serve this demographic, due to their lack of buying power. That leaves open source projects that were created for the public good.
I assume the same goes for the more lightweight Ubuntu-based distros Xubuntu and Lubuntu? What are som good alternatives to these that will continue to run on older 32-bit machines?
Fedora has a 32-bit LXDE version available[0], although I've never tried it. I did use regular Fedora and Lubuntu simultaneously for about a year, and didn't find it hard to switch back and forth.
> I assume the same goes for the more lightweight Ubuntu-based distros Xubuntu and Lubuntu?
From the article:
Q. What happens if I use a flavour of Ubuntu (Xubuntu / Lubuntu / Kubuntu etc)?
All the official flavours are built from the same common archive of software packages. As the Ubuntu archive drops support for i386, it would not be available to any flavours. If you absolutely need an i386 version then 18.04 LTS is still available.
> What are som good alternatives to these that will continue to run on older 32-bit machines?
As noted in the article, the LTS 18.04 release will continue getting security updates for many years to come. You should retire that hardware well before then, and not just because of security issues. Those old P4s are really power hungry compared to anything made in the past decade.
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
edit: hit submit too early leaving partial post...
'"Company vs Community", suggesting that profit goes against the user's best interest'
That depends on what users interests are: if they match with the company goals, then profit will help users as well. Killing parts of a project because they don't bring money is perfectly acceptable for a company (just look at how many project were axed by Google recently), but again, we should ask to users who invested time and money working with them.
BTW, Many small appliances, embedded systems etc. still run 32 bit cpus. Linux isn't just for servers or desktops.
I hope Debian will drop x86_32 distro too, and finally will support 32-bit multiarch properly as a forced consequence. Cross-compiling 32-bit Mesa on 64-bit Debian is a major pain, due to multiarch being incomplete, multilib not working and so on.
UPDATE: Looks like Ubuntu isn't dropping just the distro - they want to drop multiarch packages as well. That's already nasty.
Huh? Can I get a pointer about Ubuntu dropping multiarch? As for Debian's multiarch, it's a work in progress like most things. If something doesn't work, please file a bug.
> Q. Doesn’t Steam use 32 bit libraries? How can I play my games?
> Q. How can I run 32-bit Windows applications if 32-bit WINE isn’t available in the archive?
It means they are dropping 32-bit packages for good, not just the distro.
I'm using GOG, not Steam. They don't commonly rely on bundled runtime. Proposed solutions with lxc and such are quite annoying. And it's not about 32-bit Wine, it's about WoW64 Wine requiring 32-bit libraries to run 32-bit stuff. Lot's of older games are 32-bit and will never be converted to 64-bit.
If there is no 32-bit multiarch, how are we supposed to build 32-bit Mesa and dxvk / d9vk for example? And if we can't, everything will be stuck with outdated versions. It's a huge mess they are pushing for. I hope Debain won't do this horror if they can avoid it.
Arch gives you the option to use the system libraries or the built in one using steam-runtime or the steam-native binaries. But the package needs to install the 32 bit libraries to give you the option.
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.
> 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.
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.
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.
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.
Usually the only problem is 32-bit EFI which isn't a big deal to work around (you just copy an extra file to the usb drive you copy the installer to) and the computer will otherwise work fine with a 64-bit OS.
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.
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.
Void, Debian, Fedora, Gentoo, NixOS, Slackware, Guix System, Tiny Core, and Mageia are the independent distributions I know of that have 32-bit images. Also, most distributions support multilib; Ubuntu is actually the first I've heard of dropping it.
Why are they dropping i386? Surely 32 bit Ubuntu is still very much in demand in developing Countries or for people wanting to get old machines running with "okay" hardware? I can still get my IBM T22 to load a lightweight browser and navigate the internet.
The kernel still supports i386 and surely it's not that much effort to make sure Gnome and the various packages compile for it? They still plan to support 32 bit ARM systems?
I assume such distros have a CI infrastructure set up? If they are building from source, they should be able to keep i386 ticking over (sans anything that has a hard requirement on amd64, e.g. JITters).
I believe Lubuntu has the same kernel as Ubuntu [1], as far as I'm aware Lubuntu is literally just Ubuntu bundled with LXDE instead of Gnome. I imagine Ubuntu's decision to kill the i386 build will also trickle down to derivatives such as Lubuntu.
> Surely 32 bit Ubuntu is still very much in demand in developing Countries or for people wanting to get old machines running with "okay" hardware?
Every mainstream desktop CPU since late 2005 has had support for 64-bit, and mobile CPUs since 2008. If you're still running pre-2005 hardware, is the latest version of Ubuntu even really running that well at all?
Besides, they can continue to use 19.04 or 18.04 LTS. It's not like discontinuing support means existing installs are going to break.
> If you're still running pre-2005 hardware, is the latest
> version of Ubuntu even really running that well at all?
Ubuntu server and Lubuntu are still very agreeable for older hardware.
> Besides, they can continue to use 19.04 or 18.04 LTS. It's
> not like discontinuing support means existing installs are
> going to break.
After just a few versions of Ubuntu it becomes harder to find archive repositories, especially if you want to do anything like cross-compiling. It basically is a death sentence.
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.
Am I the only one who gets emotional here? I remember when I installed Linux Ubuntu 7.x on my first laptop (which it's still working in perfect condition). Truth is, I don't use this laptop anymore but I always wanted to install the latest Ubuntu just for the flash backs.
reply