Originally posted by oiaohm
View Post
Announcement
Collapse
No announcement yet.
Ubuntu To Provide Select 32-Bit Packages For Ubuntu 19.10 & 20.04 LTS
Collapse
X
-
- Likes 4
-
Originally posted by Raka555 View PostOMG I am so sorry.
We have no chance to make the deadline now.
The 2038 problem can hit us two ways.
Leave a comment:
-
Originally posted by oiaohm View Post
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.
We have no chance to make the deadline now.
I remember something about babies and bath water ...Last edited by Raka555; 25 June 2019, 04:31 AM.
- Likes 2
Leave a comment:
-
Originally posted by Raka555 View PostAbout 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
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.
- Likes 1
Leave a comment:
-
Originally posted by BOYSSSSS View PostI'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!
Originally posted by BOYSSSSS View PostSome people now are even saying that compilers should stop supporting 32bit...
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.
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.
Originally posted by BOYSSSSS View PostHow are mesa developers going to compile the 32bit Interface libraries then?!
Originally posted by BOYSSSSS View PostI'm not a programmer, but I see people saying to put all 32bit libraries into flatpak or snap, including the drivers?
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://media.ccc.de/v/ASG2018-173-libcapsulesegregated loading of dynamic librarieslibcapsule is a project that allows segregated dynamic linking: Access to...
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.
Originally posted by BOYSSSSS View PostIf 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!!
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.
Leave a comment:
-
Originally posted by Jumbotron View PostHappy 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!
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 !!
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.
- Likes 3
Leave a comment:
-
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 yearsLast edited by Raka555; 25 June 2019, 04:00 AM.
- Likes 1
Leave a comment:
-
Originally posted by BOYSSSSS View PostI'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!
They aren't going to do away with multiarch compilers.
- Likes 3
Leave a comment:
-
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!
- Likes 6
Leave a comment:
-
Originally posted by ThoreauHD View PostAs long as they get this done within the next 13 years(18-5 support cycle), it will be fine. But it will need to be 64bit within that time frame, no matter how many games or print drivers we lose.
Ubuntu does not have 13 years. Long term LTS distributions by what Ubuntu is doing 10 years of support. The 32 bit time failure year is 2038. You subtract support time frame that comes 2028. The last year a distribution should release with non containerised 32 bit 2027. Ubuntu LTS are only done on a even year that make the wall for a Ubuntu LTS 2026. This is not 13 years to solve the problem its 6-7 years.
Please note containerising all the 32 bit applications is only the first step. The step is agreeing in things like EPOCH offsets to time.
Originally posted by board View PostSnap is not mature, its sandboxing is too rough or too restrictive. We need something that covers most real world scenarios and that is customizable enough to satisfy the security needs of most users.
6-7 years to make snap/flatpak mature with time offset support or something else equal with the option if we fail lose all 32 bit support out any distribution that will sell companies/end users 10 year support contracts after 2027 like it or not.
Leave a comment:
Leave a comment: