It seems Canonical have done a bit of a U-turn on dropping 32bit support for Ubuntu, as many expected they would do. Their official statement is now out for those interested.
The most important part to be aware of is their new plan:
Thanks to the huge amount of feedback this weekend from gamers, Ubuntu Studio, and the WINE community, we will change our plan and build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS.
We will put in place a community process to determine which 32-bit packages are needed to support legacy software, and can add to that list post-release if we miss something that is needed.
That's not the end of it though of course, eventually 32bit will be dropped which is inevitable really. Just not fully this time. Touching on this, they said in the post about using "container technology" to address "the ultimate end of life of 32-bit libraries" so hopefully by that time everything they need will be in place to make it super easy for users.
I'm glad Canonical have seen some sense on this, they clearly didn't communicate it well enough to begin with but they at least understand when they've made a big mistake like this and owning up to failures is part of what builds trust, so I'm happier now. Next time this happens, I just hope they give a very clear roadmap giving everyone proper time to prepare, which they didn't this time.
Their full statement is here. It will be interesting to see how Valve react, after announcing an end of Ubuntu support for Steam for Ubuntu 19.10 onwards.
Quoting: GryxxQuoting: F.UltraQuoting: GryxxQuoting: F.UltraQuoting: eldakingQuoting: F.UltraNo I didn't say that others did such stuff all the time. What I said was that in the real world companies announce their plans, then they await comments from users and partners to see how said plans will be received after which the plans are either amended or put into production.
The problem here is that the Linux fanbase decided to see the announcement of plans as a foregone conclusion and then run around screaming.
When they "announced" this years ago, did they set a date? Was it fully decided and plotted out? How much did they broadcast their intentions so that people could prepare their transition?
Or was their announcement now still just a "plan" to be discussed, despite the fact the changes takes effect in a few months?
Everyone was surprised by this because information was not communicated clearly enough and in advance enough. Yeah, we are probably overstating the impact... but this a panic Canonical created.
Here is the initial announcement from last year: https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html so it was just one year ago and not years as I first claimed (shame on me there).
edit: further research shows that they also made an announcement back in 2016: https://lists.ubuntu.com/archives/ubuntu-devel/2016-June/039420.html
Basically, they said in 2016: "What do you think is appropriate?"
In 2018 as i understand they talk about dropping i386 images- not whole legacy 32 bit support, at least in your linked post
In 2019 we get: BANG!, you have 4 months to prepare your software/game/library for 64-bit only Ubuntu. You need 32 bit? Stay on older system until it runs out of support.
There was never a plan to migrate software. There was discussion about dropping, but until recently we had no timelines or guides how to prepare. That's not fair.
Here is a quote from the 2016 post:
Quote18.10+:
* Stop providing i386 port
* Run legacy i386 only application in snaps / containers / virtual machines
And that is exactly what they proposed to do in the now famous 19.10 announcement. And while I agree that 4 months is a very small time frame, it's quite obvious that they consider non LTS versions to be mere testbeds and that people would remain on 18.04 for quite some time:
QuoteQ. I have 32bit 16.04 LTS / 18.04 LTS installed, what are my upgrade options?
18.04 LTS has Standard Security support until 2023. Extended Security Maintenance runs for a further 5 years until 2028. You can stick with your current installed version until then and still be safe and secure.
This should give plenty of time to migrate away from 32-bit legacy applications before the next LTS which will be available in April 2020, or the following LTS in 2022. Alternatively place the legacy application inside an 18.04 LTS i386 container, on top of a newer 64-bit installation of Ubuntu.
I think a major problem here is that many people never read that far or just thought that, well let's worry about that in 2018 and then forgot about it. This whole rally that happened now should have happened back in 2016, perhaps then we could have avoided all the name calling.
QuoteOr some other variation of above things and/or adjusted timelines.That's not announcment. That's question. And,, beeng quite rude- Why the fuck i need to stay with old distro, that does not support recent hardware? What can i do if i want to play Steam on my Ryzen 7 3500x an RX 5000?
What do you think is appropriate? Can we survey and/or somehow
validate if above would be appropriate or needs to be extended or can
be shortened?
It was a clear indication that they where thinking in those terms and incidentally that is exactly what they then announced would happen for 19.10, a problem here is that users, Valve and WINE didn't pick this up in 2016 while the Ubuntu devs apparently thought that they did so when no one complained they went ahead with the plans.
Ubuntu have what they call HWE which basically is when they will release a new kernel in order to support the newest hardware on older LTS systems. So your RX5000 will be supported on 18.04LTS.
Anyway we are all beating a very dead horse right now since Ubuntu have decided to continue with 32-bit support for selected packages. So if we continue this too long we will end up just like the People's Front of Judea.
https://www.youtube.com/watch?v=WboggjN_G-4
Regarding Ubuntu Studio, it's probably to do with all the 32bit binary only vst plugins that are out there.
Quoting: GuestI care very little. I have read the full statement and it is clear to me that damage control continues.
They still tell me to my face i shouldn't use the 32 bit software i am currently using. Either i am a miscreant or simply an insignificant edge case. And long live to snaps. They are right, we are wrong. They did not fuck up, they are being magnanimous with us. Whether one finds this satisfying or not, it is not a U-turn.
So, i have one year and half to work out a solution with another distro which is plenty enough.
Me too, i am curious about what valve will say. Whether Canonical's compromise will work out well enough or not for steam games, i doubt Valve will accept to depend on Canonical whims.
I would be surprised we get a final answer soon after having read one of their comments about the lack of real desktop distro. My guess is they have already been looking for a while.
indeed this is not a u-turn, but only a postponing of the same "intentions," as Patola rightly pointed out earlier, that were never clearly stated as a public announcement (rather what sounded to nearly everyone like an announcement that i386 install images would be axed, which isn't even close to the same thing).
i also don't think the form this postponing is planned to take is going to go off without many hitches either. users will likely best be served to avoid ubuntu entirely if they don't want to hit any snags.
Quoting: GuestMaybe I'm paranoid but I think this is actually about Canonical trying to force everyone to use Snaps, and they probably think they have the weight to do it, but if that's the case they're delusional.
not paranoia, the evidence is there and being filtered through your experiences to afford you the intuition of a likely answer. it's just your brain functioning, and i'm wondering the same about their angles ;3 it's not like canonical has a history of trying to get people invested in their own separate project ecosystems /s mhmhhaha
the discussions linked by f.ultra also make this rollout of news, etc, and this light-backpedaling look that much more amateur, frankly. the whole thing smacks of carelessness, and not about all topics entirely, but about some very important consequences. are valve and codeweavers not interested? surely if ubuntu desktop adoption and growth are part of canonical's vision, they would be considered fairly important factors. Owo
if canonical wanted valve to support 32-bit-support monetarily, was this the best decided approach? maybe i'm stupid, but i can't tell what parts of any of this make coherent sense.
Quoting: GuestJust how many 32 bit apps do you run on your machine? I run one, steam.
The app used to send declarations on Polish taxes electronically is an Adobe Air application which works on GNU/Linux via its old 32-bit runtime.
(OTOH, containerizing it will probably be the easier and safer way to support it, so...)
Quoting: riusmaQuoting: TobiSGDQuoting: GuestI can see why they want to remove 32 bit libs because it's a ton of work.But a ton of work for whom? They still get the majority of their packages directly from Debian, throwing a patch on one or the other package and just compile. If Debian still supports newer versions of 32 bit libraries, how much work is there really to be done for canonical?
I think that this discussion on Twitter is interesting (imho) on that subject (Neal Gompa is from Fedora). :)
Very interesting discussion, indeed, explaining in detail why maintaing 32bit libs is not easy for those distributions which really care that everything works.
He mentions Mageia a few times, e.g. here: https://mobile.twitter.com/Det_Conan_Kudo/status/1142766407047925760
"Just for note, of all the major distributions today, the only one I know of that still makes 32-bit x86 equal priority as 64-bit x86 for releases, update QA, etc. is
@mageia_org
because its user base of 32-bit users is *much* higher than most of the other distributions."
I cite this to emphasize how important the normal desktop user is for Mageia. Let's explain why this is so: Because Mageia is purely made by "normal" desktop users AND have also absolutely no company interests or dependencies lurking in the background: not financially nor technically. And they are luckily big enough to provide good quality assessment. Yes there are lots of Linux distributions from independent people but only a few are not derivates and have enough manpower to do enough QA.
The desktop user is not the real "customer" for the big Linux distributions. I guess this is the core of the problem.
Last edited by Micromegas on 25 June 2019 at 5:22 am UTC
We're mostly talking about Steam and Wine here, both could be packaged with what they need. Sure, that means some minimal bloat, but disk space is really damn cheap (I just bought a 2 TB SSD (!!) for under 400$, so... yeah).
Or, as Canonical said in the announcement, use container technology to keep a "fresh" 32bit environment around for those applications that need it.
I just don't really see the need to keep them around in PPAs, which I think is Canonical's main point here.
Last edited by TheSHEEEP on 25 June 2019 at 5:15 am UTC
Quoting: TheSHEEEPWhy not just use a kind of Snap or flatpak to keep those 32bit libraries around that are needed?I got 4 drives ~3 TB total around 98% full, while having installed 149/320 games. Every containerization would make thing more difficult for new users. And we barley reached a point when Linux gaming is not considered hard. And for the price- remember it is dependent on individual peoples income. For example, in my country you could expect to get paid around 460$ monthly, making such SSD too expensive (Even if relatively cheap per gigabyte). And that is not worst case scenario like Brazil either.
We're mostly talking about Steam and Wine here, both could be packaged with what they need. Sure, that means some minimal bloat, but disk space is really damn cheap (I just bought a 2 TB SSD (!!) for under 400$, so... yeah).
Or, as Canonical said in the announcement, use container technology to keep a "fresh" 32bit environment around for those applications that need it.
I just don't really see the need to keep them around in PPAs, which I think is Canonical's main point here.
See more from me