Please see the following article for an up to date statement regarding 32-bit packages on Ubuntu 19.04 and 20.04 LTS.
https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
Please see the following article for an up to date statement regarding 32-bit packages on Ubuntu 19.04 and 20.04 LTS.
https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
This is encouraging, though I still think there’s a lack of communication clarity between “i386” and “32-bit”, e.g.:
which seems to be conflating i386 packages with 32-bit libraries used by 64-bit installations…
None of the announcements so far have made clear whether 32-bit libraries will continue to be available to the 64-bit OS. Even:
is still vague (kernel config flags don’t mean much without the supporting userland).
I don’t think anyone is really against dropping i386 as an architecture, but the real concern is how to support 32-bit applications on a 64-bit installation.
Snaps etc. for 32-bit applications are (IMO) over-engineered solutions to a solved problem:
If there’s any concern that 32-bit libraries won’t build with newer software versions then keep in mind that rolling-release distros are already using this approach and they haven’t broken yet.
that is a good statement which clarified quite a lot of things to me but realy we should all remember that canonical cant support 32bit/i386 forever because of monetary reasons security reasons and practicality reasons. While i do support you in your move to remove 32bit software(i am trying to do that myself anyway) i also understand those who need such software. but at the same time i would like to point out that one of big blockers of move away from 32bit is valve with its steam client which is exclusivly 32bit and they should think to endevour to move to 64bit architecture
You’re still conflating two different things.
Supporting 32-bit software is not the same thing as supporting the OS running on the i386 architecture.
in the world of debian linux i386 is a designation for 32bit same designation can be found on packeges
it is equivalent to amd64 which in general in debian world means 64bit
i used both terms for those who are not aware of this fact
No one is creating 32 bit processors, computers, laptops these days, even though there (still) are some 32 bit OSs running on 64bit laptops. (I have one, but it’d be a museum piece in few years.) There wont be hardware for which to create 32 bit software. So, it’d be a waste of time and resources to keep on supporting a dying system. It would be more businesslike to use the resources Ubuntu have to get on with 64bit. That way, Ubuntu would be ready, when all other OSs completely drop support for 32 bit. Dropping support for 32bit is a sure thing.
It’s not that simple. For example, https://packages.debian.org/sid/lib32gcc1 is a 32-bit library in an amd64-architecture package.
I understand how people confuse the two things, but they are not the same.
We’re not talking about 32-bit CPUs (i.e. the i386 architecture).
Retaining 32-bit libraries is important for a number of years yet. There are still people running WIN16 software under WINE; there is still plenty of software with 32-bit components; Ubuntu needs to retain 32-bit software compatibility - and that means retaining 32-bit libraries.
They must be running Linux software…under Wine
i understand this but most of the time this terms are conflated in linux/debian worlds so i used the terms in a way so everyone would understand what im talking about
Before I once again drop into a sleep state I have to say that ubuntu as a distro and community project should devote some time think of a way to steer the project. I saw numbers thrown around how miniscule the 32 lib uses are; yeah, if I run 20 servers with a few of them being virtualization hosts with another 10-30 virtual machines on them, I’m not going to use 32 libs anywhere else but on my desktop and laptop. So out of 50 machines I use 32 libs on two, but all the same they’re more important for me than snaps will ever be. If I can’t run wine on my desktop ubuntu, I won’t be recommending ubuntu server either to keep things simple.
What if during an install process user was asked permission to participate some simple polls, which would be opt in and pushed to notification centre on desktop? Asking these things on dev mailing list is going to polarize answers due to demographic.
Reading all the toxic comments and hateful replies on the Internet in last couple of days, I just wanted to put this out:
Thank you, Ubuntu Developers, for your effort! You are doing an amazing job! (with and without 32bit support, btw).
And to cheer up the mood, take a minute for Ricky Gervais: https://www.youtube.com/watch?v=L3dxMGzt5mU
This is not the correct attitude.
Whether, wine can or cannot be run on Ubuntu doesn’t make Ubuntu less better. That’s a wine problem, not an Ubuntu problem.
I’d recommend Ubuntu to anyone, who care to listen and try. Most would dual boot. I won’t ask them to stop playing Windows games in Windows or hate Windows. All, I’d want would be these new users to try Ubuntu and get attached to it, and without any demands. Let them start liking/loving Linux and Ubuntu without any restrictions. Some would stay, and some would still play Windows games in Windows.
I personally have i386 arch removed both from my work and home machines (even “apt update” works faster). Of course, games and Wine are super important and should work. But it will be cool to see some fresh polls/stats on how many users rely on 32bit apps and how many just want to play games.
Year 2038 problem, progressively increasing difficulty of supporting 32bit, security issues, etc. will not disappear. So, this should be addressed. I like Snap, and it should be a good solution for this.
And when it comes to taking that last step and run a couple of old windows programs they’d have found out that those things used to be possible on Ubuntu, that it is possible on other distros but Ubuntu doesn’t consider their need worthy of the effort
What sort of message does that send to new users, and even to existing users that get their perfectly functional setups wiped out from under them?
I’m glad the decision has been reversed, and that Ubuntu has committed to working with other projects like WINE to find a longer term solution
But that should have been done in the first place. That it wasn’t, that they thought they could just dictate their will onto others gives me severe reasons to doubt whether I can in good conscious recommend this distro to others anymore
Ppl should come to Linux, and Ubuntu with an open mind, not just to run away from some other distro. Those who run away from one OS, would run away again from the next OS in time. Ubuntu is an established high quality distro.
Wine, on the other hand, advertises Windows apps, so of no interest to me. And, should be of no interest to those who really wants to use Linux.
I’d like to address a few points from the announcement:
community process to determine which 32-bit packages are needed […] add to that list post-release if we miss something
Sounds like a lot of work, TBH, even if it’s mostly the community (= unpaid volunteers) doing it, lots of hassle. Definitely more than just leaving the i386 buildds running.
use container technology to address the ultimate end of life of 32-bit libraries […] Snaps and LXD enable us both to have complete 32-bit environments, and bundled libraries
Again, why? Why drop something that took years to design & implement, but most importantly already exists and works well – only to replace it with an as yet vague idea of a solution that’s at best over-engineered and at worst does less, less well?
By all means, isolate legacy software as much as is feasible, but I’m not keen on bundling everything and the kitchen sink with applications. I much prefer the traditional way.
There is real risk to anybody who is running a body of software that gets little testing.
How is this a problem for the 32-bit repository but not, say, for 64-bit universe or random PPAs?
The facts are that most 32-bit x86 packages are hardly used at all. That means fewer eyeballs, and more bugs.
One would hope that any bugs don’t hide in the automatically generated packages but in the source code of the software contained therein, source code that is largely shared between other architectures. In my experience, targeting a multitude of architectures makes for better code, as cut corners don’t tend to be very portable.
Software continues to grow in size at the high end, making it very difficult to even build new applications in 32-bit environments.
(New) software that can’t be built in 32-bit isn’t going to require it or be a required dependency, is it? Besides, nobody is asking you to build something that cannot be built. For now, Debian manage just fine, despite having ~10 release architectures, a much larger fully supported repository, and being non-profit.
Don’t get me wrong, it’s your OS, you should be free to take it in any direction you see fit and you shouldn’t even have to explain yourselves. But you did – and as it stands your arguments aren’t very convincing.
What I don’t understand is why netboot image is being dropped. Netboot only contains basic libraries and is required for compiling/fixing patch from community. Can anyone throw some light on it ?
Further, Valve have posted an update.
https://steamcommunity.com/app/221410/discussions/0/1640915206447625383/