Source is the Steam hardware survey set to show Linux data only. He forgot to mention the statement is only true for Steam Gamers, not for all of Linux desktops outside of Steam.

~ https://store.steampowered.com/hwsurvey/?platform=linux

uMatrix prevents me from loading this statcounter website. :-( Can’t lookup how they measure things. In the comments people assume the stats would be counted by just looking up the user agent, which is a naive approach. I don’t think agencies dedicated to stats are doing it this simple. They have way more possibilities to track and to look what browser you are using. The stats are more accurate than you probably think. They do not need to know the exact version of browser you are using, just which type and maybe what operating system you are on.

If a script for Windows does not work on Linux and fails, then they know you are not on Windows in example.

Steam Deck is a desktop. It is exactly the same PC hardware and software you are using on your desktop PC. It runs the same games and is software compatible. Steam Deck is a desktop PC.

Android has a different hardware (not x86 compatible), is focused on phones, its eco system of software is not compatible with PC and in reverse does not run your PC software. Android based smartphones are not a PC.

Half of the Linux machines on Steam, not the entirety of Linux.

• trust: The biggest trust factor difference to me is, who manages the package and how it is installed. Both are not packaged by my distribution maintainers, therefore I have trust issues with a program that important. However both are available as Flatpak. So I would recommend to install it this way.
• updates: Another big factor is how often these are updated, especially security patches. In example for any Firefox based browser, I would not want to wait longer than 1 day before the fork is on the same version as the mainline Firefox.

I personally would prefer LibreWolf over Mullvad, because it is based off Firefox.

It’s not a big deal to anyone except you.

Wrong, this is a big deal for the developers, for the users and for any maintainer of packages.

And this wasn’t a big change or new feature so they decided to implement it. It’s pretty bold to assume this was a huge change.

It is by definition a big change. And I defined it in my first reply. As you ignore all of this and waste my time, I will not read any further and block you now.

The KDE team really should consider a 1 year bug hunting phase without bigger changes like the thing about desktop edit mode we discussed here. This is my suggestion.

Compared to what I am talking about it is a huge change. My suggestion is not to do this. How I know it? Because I said so. It is my suggestion. Can we stop arguing about semantics and definitions of words? That’s not the point of my suggestion.

My suggestion is to not do such big changes for 1 year and only focus on bug fixes and small changes for the developer and for the user. That’s the point. The desktop edit change is a HUGE change with new logic. It’s incredible complex compared to what I am suggesting.

It is not irrelevant to me and I made it multiple times clear. Its a suggestion by me, regardless of what terminology you use or the team uses. The desktop edit change is a big change which I suggest not to do for a year. Only bug fixes and small changes that enhance and improve usability. The desktop edit change is a huge change for the developers and for the end user, with lot of background changes to make it work correctly, with lot of fixes after it.

Something that complex is not a small change and is not irrelevant for the topic I brought up. I made it multiple times clear now, I don’t know why you are still act like this. It’s not a definition of a term we are trying to agree, I don’t care the term.

I don’t agree with you and explicitly listed it in my first reply as an example of what I consider a big change.

You misunderstand me. They can write new code and be ready when the bug hunting phase is over. The end user only gets bug fixes. Later they can backport any new feature after the phase.

https://wiki.archlinux.org/title/Installation_guide

I guess you meant this as a joke, but for clarification, I meant no big changes such as new desktop edit mode. I wish the team would just focus of bug fixes and enhancements without introducing new elements or changing things up in a big way like this.

deleted by creator

deleted by creator

deleted by creator

I wish the team would just spent an entire year of bug fixing and refining user experience without adding new features or making big changes such as the new desktop edit mode. Don’t get me wrong, this is super exciting too, but for the complex nature of KDE it would be good if they keep a bit of focus after a major release.

By that description, Ubuntu does the same, matching the release cycle of non LTS Ubunu versions; every 6 months with breaking changes (just like Fedora). The difference to Fedora is, that Ubuntu users do not need to upgrade to the next major version, while Fedora have to, because there is only one version.

There is no single Bash standard to follow, only a few guidelines. One way you can check for some basic errors and formatting would be using an editor with support for Bash (in best case with a builtin LSP). At the end, you have to find your style and coding standards or adapt what others do if you want work with them or edit their files.

• Otherwise there is a well known tool for checking Bash files: https://www.shellcheck.net/ You can use it online and as a downloaded program on your local machine. After using shellcheck for a bit I got used to some of its conventions and recommendations, such as always wrapping variables like in ${variable} and some other things.
• Google has a coding style guide, but not everyone likes it: https://google.github.io/styleguide/shellguide.html
• Related is the Bash Reference Manual from GNU: https://www.gnu.org/software/bash/manual/bash.html Off course this is not a guide on how to style or program, but it helps in understanding how GNU does things.

BTW the mk-blog link is 404 for me.

How are the packages more tested than on Arch? Both systems have multiple testing stages in place, doesn’t it? In Archlinux there are 2 more stages before it lands on the actual end user. Sometimes one has to wait long time, in example for me RetroArch was updated after 6 weeks after official release. That’s not bleeding edge at all. Only the system core files get updated extremely quick. But that’s only about updating new packages.

The “leading edge” term of Fedora is about a total different aspect. It’s leading, because Fedora adopts certain technologies first, before even Archlinux adopts it. In example Pipewire. Archlinux waits a bit before the technology is adopted widespread, while Fedora is leading and adopting it early. And that has nothing to do about how often the packages itself get updated. People often mixup these two things (and so I did probably).

I wouldn’t be confident in recommending Fedora to noobs, because its a distribution that is on the bleeding edge side. But it depends on what type of noob we are talking about. There are noobs in Linux, who are technically well versed in Windows and have no problem in adapting to a new system. If someone wants to have the newest software, then Fedora might be it.

Also not many people have experience with Fedora, therefore less likely to be recommended. Most people use or used Ubuntu, maybe even started with Ubuntu. You or me may not like it, but its proven that Ubuntu is generally a good choice for newcomers to get into Linux. And that also plays into how many people know and are able to help. In contrast, Fedora is too much of a niche.