Before my switch, i used Ubuntu exclusively for 13 years in row. I always heard of problems (and not at least because of the PPA repositories) when upgrading from one major version to the next, be it a LTS or not. I never did that and always installed fresh because of these stories. Mostly 4 years in between, or sometimes 2.

Its entirely possible that most problems happened because of packages from PPA that the user did not change for the new upgrade. Because PPA repositories were often designed for a specific version of Ubuntu. So its not entirely the fault of the apt package manager in that case.

Read the manual intervention notes from Arch that could be important. And do the update. That’s normal and nothing to worrry about, if you know what you are doing.

I don’t think this is true. The package manager is there for a reason to prevent that. If you have more updates to install at a time, then the chances are the same as if you would have installed the problematic update one at a time. Just read the manual intervention information from Arch and see if there is something to do, then it won’t bork. If people don’t know what they are doing and do not read the additional information (that is required to do so on Arch), well yes, then you could end up borking your machine. But not because so many updates are installed at a time. The package manager and operating system and their maintainer designed it in a way that you can install ton of updates at a time without borking. This is fine.

Sure, and that’s exactly what you want if you are on a rolling release, isn’t it? If you neglect the rolling release for a month, what did you expect would happen? Also if you have more apps and packages, the more updates will come out. Rolling releases are for people who maintain the system and care about the updates.

So you neglected the operating systems maintained regularly, despite it being a rolling release? I assume you didn’t read the manual intervention instructions that are posted regularly too. I don’t understand people using a rolling release and then not caring about the maintenance. Off course it won’t end very well.

Because you get updates and have an up to date system?

This has nothing to do with immutable desktops.

Would you eat something where you don’t know whats inside? For me its like going into a Restaurant and they promise you it will taste wonderful, without telling you whats inside, only showing how it looks from outside. Would you eat it? That’s kind of what a proprietary emulator is for me. And I don’t have much to choose from, unlike vegetarian food (you can even make your own food out of the parts you buy). Sometimes I straight up have no other choice than use proprietary software (like Steam for Steam games, even the games are proprietary…).

I understand the nature of your comparison. We are making a compromise and accept that we have less to choose from, for our greater good and goal.

Not if its not absolutely needed to. In example Steam is a pass, or back then when I was using Nvidia cards the proprietary drivers was a must have too. I even have proprietary drivers installed for the gamepad… (and hate myself for it) BigPEmu is “just” another emulator and I can play the Jaguar games on RetroArch already. So yes, I avoid proprietary software by principle, but do make exceptions. I’m not a purist. I’m still curious to how it compares to my current solution.

You mean YouTube? I’m not aware of that.

This means the stars lost their original meaning of just expressing what you like, as it is tied to monetization. Imagine how wild it would be if YouTube did this with likes of videos…

Unironically, to me it was besides RetroArch (I know what it is, its not an emulator in itself, I could discuss this all day long) it was actually Yuzu. That’s because I played BotW and TotK this year on Yuzu. Otherwise its RPCS3, Xemu and Cemu off course. I’m surprised he didn’t mention Xemu at all.

As for BigPEmu, its unfortunately proprietary software. So I’m not going to test it, but wonder how it compares to Virtual Jaguar core in RetroArch.

In that case, its all Google I agree.

But that is a decision the user takes, not Google. If people don’t want to install alternative stores because its too much work, then its not Googles fault. The problem is that phone manufactures do not have the alternative stores installed (besides Samsung). Its entirely in the hands of phone manufacturers and they should be sued over, not Google.

I just want to play games.

Edit: On a more serious note, I am actually a bit on Googles side here. Because everyone can actually install an alternative store. It’s like asking Steam to add an installer for GOG and Epic Games Store in the Steam store. There is no technical limitation on the smartphones why anyone could not install alternative stores or software. The lack of installed alternative stores right from the start is not a fault of Google, but the phone manufactures who did not put these by default.

Overall, am I wrong with my observation? I really think Google is not at fault for this particular thing.

It only shows up when you use the dropdown menu to filter for Linux only. Then you also will see Freedesktop SDK (Flatpak). For whatever reason Flatpak and SteamOS Holo are ignored if you look at all operating systems instead Linux only. If you compare the numbers, they are not added to Archlinux or anything else.

Where is this stated?? If that was the case, the difference to other distros would be much higher. SteamOS is usually listed separately as HoloISO: https://store.steampowered.com/hwsurvey/?platform=linux

The survey is just accepting to send some auto collected data. There is no “real survey” involved.

Does Archlinux include SteamOS? Why isn’t SteamOS not listed, but several versions of Ubuntu is listed separately? Wasn’t SteamOS making up about half the Steam users using Linux? I would like to see multiple ways and options to enable and disable for Linux grouping, and longer lists. It may be enough for MacOS or Windows, but not for Linux.

I am curious too. You tested two different versions, one beta and the other current nightly (different content). It’s okay for a quick test, but you can actually have a much closer test. Both nightly and only one day difference:

• bz2: https://archive.mozilla.org/pub/firefox/nightly/2024/11/2024-11-26-20-51-18-mozilla-central/firefox-135.0a1.en-US.linux-x86_64.tar.bz2
• xz: https://archive.mozilla.org/pub/firefox/nightly/2024/11/2024-11-27-09-56-17-mozilla-central/firefox-135.0a1.en-US.linux-x86_64.tar.xz

I run this quick test multiple times and on average these are typical results (don’t forget to delete the unpacked folder between each runs):

$ time tar xjf firefox-135.0a1.en-US.linux-x86_64.tar.bz2

real    0m5,784s
user    0m5,700s
sys     0m0,371s

$ time tar xJf firefox-135.0a1.en-US.linux-x86_64.tar.xz

real    0m1,699s
user    0m1,621s
sys     0m0,315s