Latest 30 Comments

Oh, sounds like a big update. I wonder if it's worth it starting the game from the beginning.

View this comment - View article - View full comments - Report this comment

x86_64 is ancient. People are already striving to move to the next, more efficient architectures (aarch64 & Risc V). We already can run x86 software without any problems in containers but generally don't need to: "Our" software is build for x86_64 by the distributions. Again, it's only crapware from crap developers which blocks this.

I really don't want to sound cynical but this makes me one. I keep reading about the wonders of Risc-v for at least 5 years, yet I am yet to see a working distro running all the legacy i386 apps and games that works seamlessly on risc-v.

I use Linux exclusively since 2009, I was reading about the heavens offered by Wayland even that early. Yet, we are witnessing its mass adoption in last couple years. Why? Because, some smart people didn't arbitrarily decide to drop x11 that would render old apps inoperable due to lack of efficient translation.

Nobody is stopping you, have fun: https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/copr/

Also, no one is stopping people to switch to other distros either. Unless its name is Debian, there is no irreplaceable distro. Have fun seeing people migrating to distros offer better and native compatibility.

View this comment - View article - View full comments - Report this comment

But that being said, you just dont f**k with legacy stuff.

Because Steam is legacy software… (but this explains a lot).

View this comment - View article - View full comments - Report this comment

This is precisely why it is so important that the volunteers step up to maintain these old technologies. You know that -- with the possible exception of companies like GOG or Valve -- the for-profit sector is not going to do it.

We're only talking about this because Valve seems too incompetent to fix their crapware. Instead you're blaming all other to fix Valve's stupidity. They're not supporting the old technologies, Steam requires an x86_64 CPU. If they want to support x86 binaries (instead they could move all games to Proton, too), they can provide their x86 runtime. No need for all others to do their job.

It is too early. We need to fully develop and deploy the containers, runtimes and technologies like WOW64 that enable 32-bit apps to run in a 64-bit environment before we abandon the libraries needed to run them right now.

x86_64 is ancient. People are already striving to move to the next, more efficient architectures (aarch64 & Risc V). We already can run x86 software without any problems in containers but generally don't need to: "Our" software is build for x86_64 by the distributions. Again, it's only crapware from crap developers which blocks this.

For now, IMO, the solution is to continue supporting 32-bit libraries.

Nobody is stopping you, have fun: https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/copr/

View this comment - View article - View full comments - Report this comment

As I pointed out earlier, Steam client is 64 bit on macOS for both x86-64 and ARM64, yet it is still not fast. The problem is CEF, as long as CEF remains as it is, changing and/or upgrading architecture won't change much.

x86_64 is not about performance, it's about compatibility. It shouldn't be slower than x86 (if it is then I again suggest Valve rewriting the whole client).

And aarch64 was only recently released as a beta. Currently it runs the x86 client via Rosetta2 which simply is slower. The aarch64 port is much faster (check the various user reports).

View this comment - View article - View full comments - Report this comment

The macOS client was recently ported to aarch64 (a completely different CPU architecture!). If an x86_64 build is harder than that then Valve should completely rewrite the Steam client.

As I pointed out earlier, Steam client is 64 bit on macOS for both x86-64 and ARM64, yet it is still not fast. The problem is CEF, as long as CEF remains as it is, changing and/or upgrading architecture won't change much.

View this comment - View article - View full comments - Report this comment

It'd be neat if the Bazzite devs would join forces with the Arkane Linux (https://arkanelinux.org/) devs to make a distro. The quality of Arch + the stability of an immutable distro with the Arkane tooling would be fantastic.

View this comment - View article - View full comments - Report this comment

Fedora tends to do this kind of thing more than other distros. It probably wasn't the best choice for a Bazzite base. That said, surely Bazzite can just build these packages or base the distro off of something else.

View this comment - View article - View full comments - Report this comment

Didn't think this would be nearly as bad as I thought yesterday. Especially some of the - sorry for saying - pretentious comments as the ones quoted by the users above, really give a bad tatse and make even myself start the idea of looking elsewhere with such attitude, that seed is planted now, Fedora.

Seriously, nothing I dislike more than people making potentially catastrophic decisions, while also being so smug about it. Like, the problem for me isn't the proposal itself, rather the attitude driving it.

For Bazzite, unrelated but this just made me truly realise and actually accept the Bazzite devs when they said 'we're not a distro', clearly, if such a change, even as significant as this, jeprodizes the whole project, because they can't handle it. This is just an observation, not an attack or anything, I was always like 'come on guys, Bazzite IS a distro'.

This brings me to another point I want to share, and I really like this about open source software, it's that because everything is out in the open, and there's really no heirachy or any official job roles, what I really like is how everyone's voice does matter, and the open source devs are put at the highest levels of scrutiny that I've seen; one small mistake (like this proposal being effortlessly reverted and pretwnd like nothing happened) and you risk your whole reputation goodbye. This is great, it (hopefully) ensures ill-intentioned individuals to burn down when they try something stupid.

View this comment - View article - View full comments - Report this comment

Now first i will say that we should have been dropping 32bit support at least decade ago already if not even earlier. But that being said, you just dont f**k with legacy stuff. If you want to remove things then you provide a compatibility packages or whatnot for old software that cannot be recompiled etc. Thats just my 2 cents. Same goes to wayland and stuff. You provide a layer to support legacy things.

Now about the bazzite shutting down potentially when that happens... well that's really what you can expect from a small distros developed by few people and maybe several random contributors that use some other distro as a base.
We have had loads of distros that have gone extinct.

View this comment - View article - View full comments - Report this comment

@syylk

can we please stop blabbering about corporate greed and for-profit progressism? These are guys helping for free in their free time. It's not IBM, it's not RedHat, it's a different thing.

Since only two people commented about this, I'm going to assume you're talking about me.

Please slow down and read what I wrote more carefully. I did not say that corporations were directly involved or that the volunteers were corporate flunkies. I said that there is no need for open source volunteers to employ a philosophy developed by a corporate for-profit mentality. A completely different thing.

Besides, how do you know that this issue is not being influenced by IBM or RedHat in some way? If we maintain old things, we do not buy new things.

Resources are scarce.

This is precisely why it is so important that the volunteers step up to maintain these old technologies. You know that -- with the possible exception of companies like GOG or Valve -- the for-profit sector is not going to do it. Our society has been devaluing the idea of maintenance against the "convenience" of a throwaway habit that only benefits the for-profit sector -- at the expense of our society, culture and environment. In fact, it is the lack of maintenance that is causing this resource scarcity.

It's too early now? Most likely yes.

It is too early. We need to fully develop and deploy the containers, runtimes and technologies like WOW64 that enable 32-bit apps to run in a 64-bit environment before we abandon the libraries needed to run them right now. Honestly, even in the corporate world, there are businesses that still utilize Windows XP or Windows 98 because of a critical application that absolutely will not run in modern operating systems.

Do I have a solution?

For now, IMO, the solution is to continue supporting 32-bit libraries. Which, of course, means that we will see more reviews such as this one popping up periodically in the future.

View this comment - View article - View full comments - Report this comment

@The_Real_Bitterman

That's what the Steam Runntimes and org.freedesktop.Sdk.Compat.i386 are for. 32bit support on 64bit systems.

You do not need a single 32bit library to run 32bit software on 64bit systems with flatpak.

Erm... What is inside of the Steam Runtime and org.freedesktop.Sdk.Compat.i386?

View this comment - View article - View full comments - Report this comment

Not my mind of game but I am impressed by the underlying thought and technologies they've put into this product.

View this comment - View article - View full comments - Report this comment

The game that keeps giving! The kids and wife are really excited about this too. Family coop time!

View this comment - View article - View full comments - Report this comment

So does this mean I can finally start the game? For the past months I've been downloading the latest builds on GOG but never actually playing it.

On the other hand I appreciate the devs' continued support of the game, if anything it means this wasn't just a cash grab on the game's good name.

View this comment - View article - View full comments - Report this comment

The macOS client was recently ported to aarch64 (a completely different CPU architecture!). If an x86_64 build is harder than that then Valve should completely rewrite the Steam client.

View this comment - View article - View full comments - Report this comment

I don't really understand the logic of some on the issue tracker saying that Steam shouldn't be a blocker for removing 32 bit applications. We kept Python 2 around long after it was deprecated to make sure GIMP continued working until GIMP 3 was finally released.

Valve really needs to put more work into the Steam client, absolutely. It should be 64-bit and should have Wayland support on desktop by now. That said, it should still serve as a significant blocker for dropping 32-bit libraries.

View this comment - View article - View full comments - Report this comment

Ahem. Library person here. Sure, books disappear, but just disappearing because "nobody ever read them" is not "normal". So for instance, in my region all the academic libraries have a kind of catalogue-sharing thing called "last copy" to make sure that when we weed books that aren't used, we don't all accidentally dump the same one. Somebody will have one last copy of that weird old book.

View this comment - View article - View full comments - Report this comment

Once again demonstrating that you're better off waiting a year. You'll get a better game for less money.

View this comment - View article - View full comments - Report this comment

Debian says Hello there!

View this comment - View article - View full comments - Report this comment

i recomend this presentation for anyone thinking legacy dont matter, but i dont think its your case:
https://www.youtube.com/watch?v=65crLKNQR0E

It's not that legacy doesn't matter.
It's that we do no longer really need legacy itself to keep other legacy alive.

Some things will no longer work, no doubt.
But I'd argue that those things were no longer important to people or someone would've made an effort to modernize or preseve them - just as people did with Flash, which can still be enjoyed without having to have Flash installed (with a bit of effort).

Who knows how many books we lost because nobody ever read them. It happens, it's normal.

View this comment - View article - View full comments - Report this comment

I would love to play this game, but it's unplayable to me due to the developers being hilariously incompetent, and I just checked: they still haven't fixed the issue. LOL.

The problem is that I play with a numpad (I have a southpaw keyboard) for every single game ever. This is the ONLY game I've ever played that has an an entire shitload of hardcoded keys that CANNOT be rebound, or even worse, aren't even listed in the settings, so you CAN rebind other stuff to them, and then you do multiple things in-game when you press a button. Like, open a container, but also turn the flashlight on, or some other dumb shit like that.

All this time later, still no word on this, the most basic game development 101 issue of all time. How hard is it for a studio to allow people to rebind their keys? For these devs, impossible.

This also makes the game entirely unplayable for left handed people, since a lot of them have normal keyboards with the numpads on the right.

View this comment - View article - View full comments - Report this comment

@pleasereadthemanual, random user comments don't line up with the history of Bazzite.

As Kyle Gospodnetich said in reply:

There’s some revisionist history going on here. While we did experiment early on with containerizing Steam, this was only done on Desktop images. We dropped it completely because it has numerous unfixable problems that make it a bad experience. At no point did this power the gamemode session images of Bazzite because it can’t, for the same reasons the Flatpak can’t, and the gamemode session images are 2/3rd of our users.

View this comment - View article - View full comments - Report this comment

Regarding mouse movement, I had a similar issue in Splitgate 2 & Satisfactory 1.1, but fixed it by using Proton 10, as hinted on protondb. That may not be the issue you are facing, but it does sound similar.

Edit: these three games are built using UE5, so no wonder they have similar issues.

View this comment - View article - View full comments - Report this comment

I think this isolated comment in a very big thread misses a lot of the bigger picture.

A long-time Fedora packager points out:

It’s really weird for an entire computer operating system to shut down because you don’t want to build your own packages? That’s strange. But you still have other options: ship the final Fedora builds of the i686 packages that you need

Followed by a user (not developer) of Bazzite saying:

Bazzite cant use Flatpak, as there are a lot of kernel and other patches made that won’t work in the flatpak due to the sandboxing nature of Flatpak. If it was an AppImage, different story. Nobara would suffer a similar issue. So many of the benefits of Bazzite would be pulled out.

At the same time, i find @kylegospo 's comment disingenuous, because while not great, they can revert to how they used to run Steam, as an exported app from a Distrobox container. It wasn’t perfect, but it worked for a long time. Also, making a copr repo of these packages wouldnt be so bad, there is already a copr repo for many custom packages in the project.

I feel compelled to add Neal Gompa, contributor extraordinaire to Fedora, openSUSE, CentOS, currently on the X.org board, big proponent for dropping Wayland for Fedora on KDE/GNOME among many other things, offered another solution far earlier in the thread: https://discussion.fedoraproject.org/t/f44-change-proposal-drop-i686-support-system-wide/156324/27

We have the infrastructure for this with the ELN stuff, a selection of packages could be autorebuilt for i686 in a secondary tag and then the result is merged into composes.

Essentially pairing down the 32-bit packages into just what's needed for Steam and a few other choice pieces of software. There was some discussion about the feasibility of this, but it doesn't seem impossible, and is the solution Fedora is most likely to go with.

P.S. Not a Fedora user.

View this comment - View article - View full comments - Report this comment

I've been using Bazzite comfortably for almost a year and I'd really rather not have to find a replacement distribution for my desktop. I could go back to Kubuntu, but then I'd have to deal with Snaps again...no thanks.

View this comment - View article - View full comments - Report this comment

This is very sad, but I can't help but wonder why Bazzite (which launched on late 2023) trusted using Fedora as a base in the first place, since earlier in that year we have seen a major Red Hat / RHEL controversy regards source code restriction (and probably many more before I joined Linux back in 2021). That being said, perhaps changing the distro base could salvage the project? What about using openSUSE, which also relies on RPM packages? It's most likely easier said than done (I'm not a programmer myself), but that got me thinking if this is really the end for Bazzite.

View this comment - View article - View full comments - Report this comment

It seems to me there is a lot of bad faith reaction to a statement of intend aiming to find solution for when critical upstream package will stop suporting 32 bits.

That's how I interpret

And it’s better to start planning for the removal of i686 packages now than when (insert foundational package here - for example, CPython) stops supporting 32-bit architectures and we need to scramble to adapt.

View this comment - View article - View full comments - Report this comment

I've settled comfortably into Fedora for about a decade now but I might start eyeing something, probably Arch again, if this even starts going forward. While I hope the day can come soon, it is much too early to drop the entirety of 32 bit support and the apathetic responses to people showing actual (not even just Steam) use cases are disheartening.

View this comment - View article - View full comments - Report this comment

This is just moving the problem from outside the Flatpak to inside the Flatpak: If we want to run all those old 32 butt games, they need 32 bit libraries somewhere.

That's what the Steam Runntimes and org.freedesktop.Sdk.Compat.i386 are for. 32bit support on 64bit systems.

You do not need a single 32bit library to run 32bit software on 64bit systems with flatpak. Also there is WOW64 for Wine / Proton which is to run 32bit Windows game on 64bit. Even Windows uses 32bit abstractions on 64bit to run legacy software.

Removing 32bit support is not an issue at all.

View this comment - View article - View full comments - Report this comment