Furthermore, a CLI instruction is DE-agnostic. So you don't need to cover the same topic with explanations for at least 3/4 desktop environments. GUI instructions also change a lot faster than their CLI counterparts; so by providing the commands one provides the method with the best longevity. Overall, it's just so much more efficient.
You can divide distros into two categories:
E.g. Zorin OS is a derivative of Ubuntu, which itself is a derivative of Debian. After the gargantuan effort it takes to make Debian possible, Ubuntu's maintainers 'grab' Debian, apply a set of changes and ship it as Ubuntu. After which, Zorin OS' maintainers grab Ubuntu, also apply a set of changes and ship it as Zorin OS.
Of course, not all derivatives are created equal; sometimes a single change is applied that by itself constitutes the fork. And other times, the changes are so massive that they blur the lines between independent and derivative; Ubuntu's changes to Debian is a good example of this.
Derivative distros can't simply change everything as they see fit; some things are simply essential parts. In most cases, these include:
But what other factors/aspects that are important for the average user to know about each ‘base’?
I was about to write a long ass dissertation, but it became very unwieldy. Consider asking for specific bases and perhaps I will respond for those.
On a final note, it's worth mentioning that differences between different distros have never been as blurry as they're today. With e.g. Distrobox, one can install whatever package from whichever distro they want. Thus, we aren't as tied to the packages provided by the base distro as we were used to. Furthermore, most distros have different 'variants' that allow access to different channels or release cycles. E.g. for those who want Debian packages but bleeding-edge; there's Debian Sid etc.
Sure, a lot more can be said; like how corporate interest plays into all of this. But what has been mentioned above should suffice for now.
Or, perhaps, consider another distro.
We actually already have an experimental coreboot port on the FW 13 AMD.
And, from my understanding, Framework has sent over a device to make this possible.
However, I don't know if it will ever get official support. Though, surely, I hope it will.
Support for coreboot can't come soon enough. My fingers are already tingling in excitement for that day.
For me:
and their consequences;
are the primary reasons why I absolutely adore atomic/immutable distros.
Furthermore, it minimizes all kinds of issues related to or caused by bit rot, configuration drift and hidden/unknown states. (Note that you won't reap all of these benefits on all atomic/immutable distros.)
But have been wondering why I haven’t heard of any immutable distros from arch based distros yet.
If your question is "Why doesn't Arch have its own atomic/immutable spin/flavor like Fedora and openSUSE have in their Silverblue/Kinoite and Aeon/Kalpa respectively?", then the answer simply lies in the fact that Fedora and openSUSE have a lot more incentive for venturing the unexplored waters of atomicity/immutability as their enterprise counterparts exist and will benefit majorly from it. And I haven't even mentioned how most of the new stuff first appear on Fedora (systemd, PipeWire, Wayland etc) before they're adopted on other distros.
The enterprise counterparts also allow funding that is essential for erecting this from the ground. But, even then, the shift towards atomic/immutable is a difficult one with a lot of hardships and complexity. From the ones that have developed their atomic/immutable projects retroactively (so GuixSD and NixOS don't count as they've been atomic/immutable (and declarative) from inception), only Fedora's (I'd argue) have matured sufficiently. But Fedora has been at it since at least 2017, so they've had a head start compared to the others.
In contrast to Debian (through Canonical), Fedora (through Red Hat) and openSUSE (through SuSE), Arch has literally no (in)direct ties to enterprise. Hence, it will only adopt an atomic/immutable variant if the incentive is high from the community or if it's very easy and only comes with major benefits. But, as even openSUSE is currently struggling with their atomic/immutable variants, it has a long road ahead before it becomes something that can be easily adopted by Arch. Hence, don't expect Arch's atomic/immutable variant any time soon.
However, if any derivative suffices, then at least the likes of blendOS, ChimeraOS and even SteamOS are worth mentioning here.
I’ve had Manjaro, and OpenSUSE recommended to me by a friend who likes both of them but he doesn’t game much and doesn’t need various software development tools.
If your friend is familiar around Linux, then I'd advice you to just stick to the distro they're using themselves. That's probably the best course of action.
Based on your history, I'll assume you're on Linux Mint; note that this is crucial information that influences the required instructions. Therefore, consider mentioning the distro you're using next time 😉.
From Linux Mint's release notes, we find the following:
apt install wine-installer
In case this doesn't do it, add sudo and it should work. So, instead we get:
sudo apt install wine-installer.
Tip: consider sticking to documentation and resources provided by the maintainers of your distro.
On a final note, I don't know exactly what your intentions are, but software like Bottles, Conty and/or Lutris are worth mentioning here as they're 'wrappers etc' for Wine.
Yup, as time went on, I simply felt less need to have proprietary software on my system. Steam remains as an exception; simply by virtue of having no F(L)OSS alternative (AFAIK).
Why are you even considering Manjaro?
If gaming is the priority, then I honestly don't think anything out there can beat Bazzite in terms of ease of use, 'hands-off'-ness, robustness and stability.
Honorable mentions include: Nobara and Pop!_OS.