Ubuntu To Provide Select 32-Bit Packages For Ubuntu 19.10 & 20.04 LTS

[Grogan]

I'm not a programmer, but I see people saying to put all 32bit libraries into flatpak or snap, including the drivers? That seems crazy to me. Let's say that driver developers continue to support 32bit even if the OS doesn't. Some people now are even saying that compilers should stop supporting 32bit... That's insane! How are mesa developers going to compile the 32bit driver libraries then?! If you don't want 32bit libraries, delete everything i386 and disable the architecture, you have a choice. If you remove 32libs permanently you're taking everyone else's choice. That's tyrannical!

Oh, don't listen to those jumped up arseholes... most of the people talking like that don't actually know much beyond installing their distribution's packages and acting smug.

They aren't going to do away with multiarch compilers.

[Raka555]

About 32bit and the whole 2038 thing:

You can have int64_t on 32bit.
Just make time_t a int64_t everywhere and stop whining about it. (There is 20 years to do it)

And ofc the existing 32bit software, that can't be recompiled, are all going to launch nuclear missiles ones their timers wrap ...

So we should all immediately stop using 32bit or else your PC is going to explode in 20 years

[setbel]

Happy yet 32 bit retards? Happy that you're holding back the ONE Linux distro and really the ONLY distro that has and can bring Windows and Mac refugees into the Linux fold? You Geeks and Phreaks are Linux's BEST and WORST enemy!

What a pathetic take. Windows is the dominant desktop OS and it has backwards compatibility going back to Windows 95. Linux desktop needs to offer what Windows 10 offers, if not more, to gain users.

EVERYONE has gone 64 bit. IDE'S AND COMPILERS are dropping 32 bit support left and right. BUT OMG WINE AND MY 32 BIT VERSION OF QUAKE 2 IN UBUNTU?? TO ARMS...TO ARMS!! HUZZAH !!

And yet you can still do this: gcc -m32 -o hello hello.c.

Get OFF YOUR ASS....and learn how to package a Snap or Flatpak and/or learn LXD containers. Or pleaee SHOVE OFF as quickly as possible to your favorite "hobbyist" distro choice like Linux Mint or whatever Arch flavor of the month that hadn't been abandoned yet and let the adults continue to pave the way to a cleaner, more manageable Linux world with Ubuntu without us hearing you bitch dead tech.

ArchLinux is 2 years older than Ubuntu, still has multilib, still not abandoned. Debian, 11 years older, still has multilib, Ubuntu just has to leverage on the work done by Debian developers. Also get out of here with that Snap/Flatpak garbage.

[oiaohm]

I'm not a programmer, but I see people saying to put all 32bit libraries into flatpak or snap, including the drivers? That seems crazy to me. Let's say that driver developers continue to support 32bit even if the OS doesn't. Some people now are even saying that compilers should stop supporting 32bit... That's insane! How are mesa developers going to compile the 32bit driver libraries then?! If you don't want 32bit libraries, delete everything i386 and disable the architecture, you have a choice. If you remove 32libs permanently you're taking everyone else's choice. That's tyrannical!

Lets break this down.

Some people now are even saying that compilers should stop supporting 32bit...

This is the first mistake. Has multiarch install been able to build multiarch system from source without using chroot/container? The answer in most cases no.

Only the next release of debian will at long last be able to Multiarch build wine. Of course this still leaves a lot programs where you cannot this in fact includes mesa3d. Hang on wine project has been release 64 bit and 32 bit versions of wine. Lets go read the instructions.

https://wiki.winehq.org/Building_Wine#Containers

So the wine programs most people have been using the 32 part has been built in a container or chroot with only 32 bit parts.

Lot of ways remove the 32 bit complier make sense on the host multi-arch system because mostly it does not work dependable. Have developer wanting to build 32 bit parts use containers/chroots that do in fact work.

How are mesa developers going to compile the 32bit Interface libraries then?!

Pardon the correct will explain latter. Basically the same way they have been built now in a container/chroot with only 32 bit parts.

I'm not a programmer, but I see people saying to put all 32bit libraries into flatpak or snap, including the drivers?

First horrible point is technically there are no drivers libraries in the flatpak runtime. There is a critical problem here what you will be calling driver libraries are not in fact driver libraries.

Mesa libraries are interface libraries there is a fatal difference between a proper driver library and a interface library.

When you program load a interface library what ever libraries and part using the interface library uses playing in your application memory. This is why if your application uses 1 version of C++ and mesa libraries uses a different one your program can completely bust up and fail. While mesa has this behaviour it has to built as part of your application run-time or else trouble.

Now if mesa libraries were in fact using segregated loading of dynamic libraries covered in in the following video:

https://www.youtube.com/watch?v=Rb1wdDdOizc

They then could be called driver libraries as they are not going to mess your application up if what they are built use in libraries does not match what your application is using. This would be a totally different debate if mesa was in fact driver libraries.

If you don't want 32bit libraries, delete everything i386 and disable the architecture, you have a choice. If you remove 32libs permanently you're taking everyone else's choice. That's tyrannical!!

I am not wanting to be rid of 32 bit programs at all I am wanting that they still work. Why I want them in containers where we can use namespace to set the time EPOCH value. This still brings us back to the 2038 problem.

The way you work around the 2038 problem is change the Unix EPOCH value to something else the history standard has this as 00:00 1 of January 1970 this gives you rough 68 years before 32 bit time second counter causes errors in the year 2038.

What 32 bit micro-controllers in you car has done is kind of horrible EPOCH in them starts on the date the car was first run and counts from then forwards. Car should not be in use in 68 years right(this is a little bit of finger crossing). The CLOCK_MONOTONIC in the Linux kernel has it EPOCH starting when you boot your computer.

If you have not worked out yet both of these solutions have a problem. Lets say you want to play a game with someone who is on a different computer with a different EPOCH and program send 32 bit time across network. You now have horrible event of time travel where items have dates on one end in the future for them. So you need to be able to negotiate your EPOCH offset so that you can run the 32 bit programs on both ends with the same EPOCH offset. Remember with games a lot of the programs source code is lost for good today so we cannot rebuild them to fix. Same applies to some enterprise applications so we are deep in a hole.

Even those making fully 32 bit distributions by 2027 have to decide how they are dealing with the 2038 problem if they are providing 10 years of support. Be the distribution 32bit or 64 bit running 32 bit applications will equal placing them in containers/namespaces and having to use different time domains.

Reality is we are going into a world where we will have multi time domains and have to manage multi time domains to keep 32 bit programs working.

[oiaohm]

About 32bit and the whole 2038 thing:

You can have int64_t on 32bit.
Just make time_t a int64_t everywhere and stop whining about it. (There is 20 years to do it)

And ofc the existing 32bit software, that can't be recompiled, are all going to launch nuclear missiles ones their timers wrap ...

So we should all immediately stop using 32bit or else your PC is going to explode in 20 years

Its not 20 years in the future under 19 years now. Distributions doing 10 years of support in future straight up lose 10 years off that. That bring 8 and a bit years max. Ubuntu with there release cycles this comes down to 6-7 years.

The time we have to solve this problem before enterprise class distributions will have to start making hard choices is not that long. Make everything use time_t int64_t the simple way for Linux distributions to achieve this is remove 32 bit support completely. Most of us don't want this solution. Containerisation and use the 2038 work around of moving EPOCH is about the only way we can avoid that.

[Raka555]

Its not 20 years in the future under 19 years now. Distributions doing 10 years of support in future straight up lose 10 years off that. That bring 8 and a bit years max. Ubuntu with there release cycles this comes down to 6-7 years.

The time we have to solve this problem before enterprise class distributions will have to start making hard choices is not that long. Make everything use time_t int64_t the simple way for Linux distributions to achieve this is remove 32 bit support completely. Most of us don't want this solution. Containerisation and use the 2038 work around of moving EPOCH is about the only way we can avoid that.

OMG I am so sorry.
We have no chance to make the deadline now.

I remember something about babies and bath water ...

[oiaohm]

OMG I am so sorry.
We have no chance to make the deadline now.

Exactly we need to think the deadline is basically now in development so we start trying different solutions. So that we have time to get the solution working before enterprise distributions have to make their final choices. If enterprise distributions have made their final choice to be 64 bit only why would they do any support to keep like 32 bit mesa functional? So by 2038 if we are not ready in 6-7 years 32 bit programs might not work any more because the 32 bit libraries have not been funded for 10 years by that point.

The 2038 problem can hit us two ways.

[Raka555]

Exactly we need to think the deadline is basically now in development so we start trying different solutions. So that we have time to get the solution working before enterprise distributions have to make their final choices. If enterprise distributions have made their final choice to be 64 bit only why would they do any support to keep like 32 bit mesa functional? So by 2038 if we are not ready in 6-7 years 32 bit programs might not work any more because the 32 bit libraries have not been funded for 10 years by that point.

The 2038 problem can hit us two ways.

Many of us wont even make it to 2038 and we are getting told to stop doing things we enjoy now because of an event we will never see...

[Raka555]

I am totally on board if the distro's say they wont support anything 32bit beyond 2037... even on LTS.

[oiaohm]

I am totally on board if the distro's say they wont support anything 32bit beyond 2037... even on LTS.

You still are missing the offset. What enterprise distributions will be ending support on in 2037 is what they sold in 2026-2027. If you look at any old enterprise distributions they don't have the latest and greatest libraries any more. So by 2037 you have basically 10 year old versions of libraries that have basically been patched.

The Ubuntu suggestion of lets just make 32 bit applications stuck on 18.04 was them really do pretend of is exactly what they are going to say when we get to 26.04 if we have not solved it and this time not change their mind. Ubuntu has put a warning shot across our bow. Except we can calculate when the final shot is in fact coming and we do have time to alter things to avoid final shot.