This is somewhat interesting to me; in that there are a couple of 32bit proprietary GNU/Linux games of yesteryear I adore. Hell I finally got ahold of the official Sim City 2000 port Loki games did in the late 90s, this past year.
Starting with Ubuntu 19.10 it will officially be easier to run those games on NetBSD through it’s linux binary compatability layer than it would be with straight Ubuntu.
Strange times.
From a FLOSS gaming perspective this transition would be easy, as source would be available. I think its interesting that Ubuntu is trying to do it; percisely because they have done a lot to court proprietary devs in the past.
Overall, I’m happy with the move from 32-bit, but I think that’s because I fall in this demographic of not having to care about it unless it’s breaking my software config; I can easily see folks using 32-bit apps on a daily basis and this feeling like left behind.
So… can we emulate 32-bit? I haven’t thought about this stuff since like, first discovering Wine, or I should say WINE, and at the time it made more sense, but now I see everything being ported to everywhere, and I don’t know what gets lost, practically, in dropping 32-bit support.
You can to a point. Things get kinda tricky though the closer to hardware the apps need to access though. Specifically in my limited experience video acceleration and opengl get tricky there because at some point those 32bit calls gotta talk to 64bit drivers.
You could of course drop everything into a virtual machine, or a kind of linux-in-a-bottle 32bit environment. Though most variations of both require running an unpatched old linux distribution with security concerns OR building what amounts to 32bit Ubuntu to put in the bottle.
To be fair to Ubuntu they seemed like they wanna pitch something of one of these last options for those who need it; but its unclear who they expect to put in the work. As it’s comparable to the amount of work their savings from dropping 32bit support.
Kinda. In so far as there is a BSD gaming scene, yes.
The BSDs have a history of supporting binaries and the full ABIs from multiple posix/unixish systems. [NetBSD documentation here] Including GNU/Linux. BSDs users have and do use this for gaming with games that have native GNU/Linux ports.
I actually exploited this to get an old port of Hyperspace Delivery Boy running on NetBSD a little while back when it was my primary OS.
Many BSDs not just NetBSD will be supporting the 32bit GNU/Linux ABI and carrying more 32bit linux libraries in their ports trees than Ubuntu soon will be.
It’s interesting to me Canonical is still saying things like this:
We will also work with the WINE, Ubuntu Studio and gaming communities to use container technology to address the ultimate end of life of 32-bit libraries; it should stay possible to run old applications on newer versions of Ubuntu. Snaps and LXD enable us both to have complete 32-bit environments, and bundled libraries, to solve these issues in the long term.
At the end of the day, their saying shipping all the neccesary libraries for 32bit support is to big of a headache for them, but building them and putting them in snaps or other containers won’t be too much of a headache for various other smaller projects and devs.
Like at the end of the day their just moving the work out of their distro. Not reducing work. Im not sure why they expect developers or users to be all pleased with that.
There is real risk to anybody who is running a body of software that gets little testing. The facts are that most 32-bit x86 packages are hardly used at all. That means fewer eyeballs, and more bugs
… and again doesn’t splitting the eyeballs looking at that code into smaller more fragmented silos compound the problem?
I get their desire to drop 32bit. But I think it would be best to be blunt about it. This whole, “One day all of our 32bit devs will need to build their entire library chain from libc up and that ought to be seen as normal because containers!.” - isn’t doing anyone (Canonical included) any favors.
Im having trouble wrapping my head around freezing the 32bit libs/packages. Seems like it could cause lots of problems if your 3d acceleration library versions dont match your drivers. Especially the proprietary ones which often require specific versions of opengl. I wonder too how much of their chatter about the long term legacy support for 32bit needing to be snaps, ties into their shiny new snap store their building.
Why not atleast ship the debian packages for i386 with minimum tweaks if this is about saving labor? Debian is showing no signs of dropping i386 libs.
That being said their whole timeline for this seems to have been pushed back a year into the next LTS release, so everyone has time to gnash their teeth about it.
I dont run Ubuntu but how this tussle settles is going to be interesting a few years from now.
I just wanna add even if their isnt compatability issues with freezing the libraries, I dont get why they would deny their own users upstream bugfixes and sexurity fixes to these packages.
Something else Ive been mulling on. I WAS an Ubuntu user at one point. Ubuntu stopped “supporting” 32bit PowerPC in 2007 but didn’t stop shipping community supported binaries until 2016. I had a clear memory of that first bit because I was running it on a tangerine ibook at the time. When that was announced I switched to Debian for about eight to ten years or so.
Not sure why i386 can’t get a nine year phase out like that.
I am also half wondering if their trying to focus shift away from desktops; without panicking their user base. I remember chatter from them that their cloud business was actually kind of profitable around the time they decided to scrap dev time and money on Ubuntu Phone and Unity.
