You asked how it works, the post states how it works. You also asked if it’s slow, which is clearly answered in the post (though you didn’t quote that part). You also asked if there’s some “secret sauce” allowing it to be fast, which is also a weird question since everything used is listed in the post.

If something wasn’t clear to you, why not specifically ask about it? Even in this comment, you still don’t specify what you don’t understand. What kind of answer are you expecting to get?

Why not click the link and find out? It’s literally a Mastodon post, you don’t even have to read much.

(Note that the immutable distros will only be represented by Fedora, GuixSD and NixOS. The others are either too niche or immature)

This was my issue with your original comment - I’m aware most of the work on features like these is based on immutable distros, but just being immutable doesn’t mean it will have those features.

When it comes to reproducibility and declarative system management, I think you’re right that they’re only available in immutable distros.

The security benefit of a read-only filesystem isn’t very significant IMO, and for some immutable distros, interesting parts (to attackers, like /etc for example) are mutable anyway.

And I don’t use any snapshot solution currently, but don’t most of them only store the parts that change between snapshots? According to the Arch Wiki, Snapper’s “default settings will keep 10 hourly, 10 daily, 10 monthly and 10 yearly snapshots”. This doesn’t seem like much of an advantage for immutable distros, really.

There’s no need to go over the “consequences” as they’re (as the name implies) consequences of what has mentioned earlier. Hence, as their causes are better than the one found on traditional distros, so are the consequences better than how they’re found on traditional distros.

I disagree with this though. “Better” is very subjective - I for one consider being able to have an up to date system that can have parts of it updated without rebooting to be much nicer than using something like rpm-ostree, even if it is safer to use in theory (I can’t remember the last time I had an issue when installing a package; rebooting to apply an install atomically will likely make no difference to me other than wasting my time). I know I can use containers to get around this, but once again, this just adds to the hassle.

I guess I’d define it as a distro where the base system is read-only and changes or updates to it are done by replacing it atomically.

Fact of the matter is that the immutable variants of these features are far and wide superior over their counterparts found on traditional distros.

How exactly? Just saying it doesn’t make it true. Except for atomic updates (which are basically the main point of these distros, and why they’re also called “atomic”), what can they do that you can’t on a normal distro?

(Note that you won’t reap all of these benefits on all atomic/immutable distros.)

That’s because most of these benefits are not a result of a distro being immutable.

IMO crunch has no excuse; it is a decision that benefits the business while hurting the workers.

“A few weeks” of crunch translates to hundreds of extra working hours.

Using niche browser forks is often not a good idea. These are extremely fast moving projects that need to constantly be updated to stay secure.

This is especially true for Firefox forks, as Firefox allows you to customize it to the point that it is almost the same as many of these forks.

There are exceptions to this - for example, LibreWolf has a fairly good track record and Mullvad Browser needs to fork Firefox to (try) ensure all users have the same fingerprint.

I figured it out.

I added the Ubisoft Connect installer as a non Steam game, installed it with GE-Proton9-4, and then switched the shortcut to the location of “UbisoftConnect.exe”.

Then, in the launch options, I put:

PROTON_BATTLEYE_RUNTIME="$HOME/.steam/steam/steamapps/common/Proton BattlEye Runtime" %command% uplay://launch/15657

And make sure the Proton BattlEye runtime is installed through Steam.

I played multiple full matches in a row like this without any issues.

Edit: Oh I almost forgot, you also need to get a copy of pdh.dll and put it in the game’s directory.

but we did have to do a bit of crunch. And I think, to be honest, you will always have a little bit when you’re trying to finish something, especially when there’s so much complexity that needs to be brought together.

What does doing “a bit of crunch” even mean? Crunch means you’re (practically) forced to work overtime, there is no excuse for this IMO. The game was on early access for a while, surely they could’ve delayed its full release by a bit to prevent this.

Doesn’t seem to.

There’s also 4get (metasearch engine; https://4get.ca is the developer’s instance).

I was trying to say GOG isn’t comparable to Itch…

Edit: Btw I buy games from all 3, if I didn’t do business with every company I don’t trust I’d probably starve by now

Ok? I didn’t claim anything about Steam

Knowing Valve, even if it was in development for years it might never come out anyway, so this doesn’t surprise me.

GOG is a subsidiary of CD Projekt (which I personally don’t trust after the disastrous release of Cyberpunk 2077, and the empty promises of bringing GOG Galaxy to Linux; they also stretch the definition of DRM-free in some cases).

Ultramarine Linux was created out of frustration with the legal limits of Fedora. As Fedora (and Red Hat) is an American entity, there are legal restrictions on what software can be packaged in the distribution due to the US patent system.

The Ultramarine team aims to make Fedora a little more user-friendly by allowing users to install or package any software they want as long as someone maintains it in Flathub, RPMFusion, or Terra.

In addition to this, we provide various UX improvements around the system, and in the future, custom apps.

In case anyone else was wondering what this is

There’s a 5th type - those of us who understand that the technology itself isn’t a scam and has valid uses (even if many “AI” startups actually are scams), but think there isn’t that much potential left with current methods due to the extreme amount of data and energy required (which seems to be supported by some research lately, but only time will tell).

You know that if someone skims your card and makes a fraudulent purchase, you will likely be able to get your money back, right?

What do you think will happen if someone exploits a 0-day in GPay to do this? How could your bank know the purchase was fraudulent? At least with a card it is obvious that this can happen.

If you care about “secure” payments that much, why not use cash?

Unless you have a very bad PSU, this doesn’t actually matter.

Less “responsibility” on the servers would mean better capacity to scale and serve more clients on the same hardware and (if the identity is not dependent on the server and can be easily portable) it would mean less attached value to the server itself

To me, this makes it sound much more attractive to run a server, as it will be easier to do. Though I guess this is subjective.