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.
1 Like
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.
5 Likes
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.
3 Likes
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
8 Likes
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.
1 Like
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.
2 Likes
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
4 Likes
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.
1 Like
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.
2 Likes
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 ?
1 Like
Further, Valve have posted an update.
https://steamcommunity.com/app/221410/discussions/0/1640915206447625383/
6 Likes
You’re just ignoring the arguments on one side. Saying that the argument is “not worthºy” doesn’t really represent correctly the arguments that were made, and saying it’s not possible to run it on Ubuntu is simply to ignore the path that was presented to actually enable users to continue to use them. It’s not fair to put things that way and doesn’t represent the reality.
By the way other distros have been walking the same path, and some have also done the same (minor distros in popularity like OpenMandriva), but the fact that the others haven’t looked more into doing something like this says more about the other distros disregard for security and stability risks, than says whatever about Ubuntu. When you lag maintenance at the upstream projects and QA is almost null because nobody does it, then those risks increase a lot.
1 Like
It doesn’t work well and it’s not maintained correctly often on upstream projects, and there’s lack of QA
Would you mind elaborating? I.e., in what way does it not work well? Your upstream in this case is Debian, they still maintain i386 (dpkg arch, not “would run on an actual i386”) as a first class arch, and you don’t hear “Debian” and “not maintained correctly” in the same sentence very often. As long as the i386 packages are built from the same source as the amd64 ones, they stay current, most fixes trickle down to them as well. The exposure is limited to issues that only manifest in the i386 version of a package. That’s much better odds than amd64 universe and PPA packages, that may not receive any updates at all and be of questionable quality to begin with.
The fact is, current amd64 systems can run 32-bit code natively, removing support on the OS level is a regression in hardware support. I’d be against it in principle even if there weren’t any major use-cases – and there are plenty. (One could even make the case for re-introducing i386 as an installable architecture, if not for 32-bit/hybrid Atom boards and netbooks then for lighter [= more] VMs, but I digress.) The point is, 32-bit code is not legacy, hardware that cannot run 64-bit code is – that’s a big difference. Even if it were legacy, it looks like many people still want or even need to run 32-bit software, and why shouldn’t they? When choosing an OS, they ask “Does it run my stuff, and does it run it well?”, not “Is it pure 64-bit?” – and for once, they got it right.
IMHO, running both 32-bit and 64-bit code on amd64 at the same time should be fully supported and as seamlessly as possible – Windows does that very well – for the foreseeable future, and multiarch is, as of now, the best way to do that. Compiling the 32-bit packages to target amd64 CPUs is an option, as is selectively dropping non-essential packages that won’t compile and would be too much effort to fix.
Bundles (Flatpack/Snap/Appimage) currently negate all advantages of centralised package management, containers/VMs aren’t there yet, either. Too much overhead, too much complexity to manage, too fragile for the desktop, not at all well integrated, let alone seamless.
It’s highly likely that a better solution than multiarch will emerge, maybe in conjunction with a paradigm shift to containerise everything transparently (cf. Qubes), who knows, but it isn’t even on the horizon yet, so why the rush?
2 Likes
I for 1 am glad to see support for running 32bit on amd64.
While I do like the thought of moving towards a pure 64bit environment, I don’t think the time is right.
I wish 32 programs could just use the 64bit library, but I guess that just isn’t going to happen.
Frankly I’m annoyed by all this “it’s not ubuntus problem if a given application doesn’t work/run”. This is not kosher in my view to the community guidelines. Regardless of a person’s view toward a particular program , these comments are not helpful. Some users need these programs, your personal bias against Windows and games is just detrimental to the conversation.
As was pointed out in the legitimate concerns category there are some 64bit apps that have 32bit dependency issues. Wine being just 1 example. Luckily the apt system can enumerate such dependencies and a solution can be found that covers most use cases.
1 Like
If it’s so little maintenance to take Debian’s i386 packages and run them in Ubuntu, perhaps you could make a respin of Ubuntu 19.10 which has full i386 support? Or is it not as easy as you’re making it out to be and it is actually time-consuming to do?
You could call it Ubuntu i386 Remix 19.10 