Thanks OP for replying! Though, I’m a little bit confused as you had already replied to this specific comment. Perhaps you meant to reply to this comment instead?

Regardless…

It’s like owning a race car. You have to do a lot of maintenance to it and it will still bite you in the ass but when it works right it’s fast as hell and a lot of fun.

If that analogy was used to describe Arch, then yeah; I can definitely see that.

But on the other hand: if there’s no downside to built in some failsafes then why not do it?

So, if you allow me, I would like to slightly rephrase the main question to the following sub-questions (and try to discuss them as we go):

• What problem are we even trying to solve? Answer: The problem of broken/borked systems due to every-day activities. Literally none of the other systems/OSes in your life do this. Your phone doesn’t. Your console doesn’t. Your non-Linux PC doesn’t. Your car doesn’t. Your TV doesn’t. Your refrigerator doesn’t. You get the drill. So how is it even conceivable that desktop Linux is the only one that hasn’t solved this yet?
• Why is this even a hard problem to solve on desktop Linux? Answer: Because it allows far more control, agency and ownership compared to all the previously mentioned systems/OSes. Heck, you can just sudo rm -rf / your system/OS into oblivion. It is almost an oxymoron for your system to simultaneously
  • grant you all the freedom to do whatever you want
  • and take away that very same freedom in order to preserve itself
• What fail-safes even exist? Answer: Below you may find a non-exhaustive list including a short discussion.
  • Take away the freedom of the user 😅. This is literally what both Android and ChromeOS have done. And, to be absolutely fair, to great success. Your grandma wouldn’t care much for the freedom that Linux allows; she is more interested in a reliable system. This is a very effective way to make that happen. As for desktop Linux, I’m unaware of any distros that go this route. The furthest I’ve seen distros go, is that they won’t commit to support all kinds of uses. Which, to be fair, is absolutely fine in my book.
  • Actual attempts to make the system less brittle. This is where it gets a bit more interesting. Desktop Linux shits itself rather easily, honestly. It should be a lot more robust. To give you an example, IIRC, I played once a little with /etc/pam.d and my laptop didn’t boot into the OS the very next time. Like, I get it; it’s important and all, but we should be able to do better than that. While I can’t show you any examples - as I failed to find where I had seen them before - I do know that some existing systems are able to NOT piss themselves whenever an important subdirectory of /etc is absent. Arguably, NixOS provides the best example of this in practice. But I digress…
  • Keeping track of known good states and allowing the user a return to them. Basically, this refers to rollback functionality, but is not limited to them. Other examples include the factory resets made possible by bootc’s install reset and Pop_OS’ recovery partition. A LOT can be said about this and its many variations/implementations, but this suffices for the sake of brevity.
• Are there any downsides to any of the aforementioned fail-safes? Answer:
  • Taking away the user’s freedom would be like taking Linux’ soul out. This would be a categorical error. So this can’t be done UNLESS the user desires it for themselves. But, as I said earlier, I’m unaware of any distro (besides Android or ChromeOS) that has gone down this route.
  • Making the system less brittle is unfortunately not that easy, it seems. Perhaps systemd can make some changes in hopes of addressing this. Otherwise, it seems that (some) atomic distros are at least pushing changes to this effect. But aside from NixOS, I’m unaware of any that have provided a mature solution. While it definitely fares better than most, it’s not as if NixOS is unbreakable either…
  • Rollback functionality has slowly but surely become a common occurrence on desktop Linux. But, it isn’t sufficient by itself. OpenSUSE basically pioneered this when they launched Tumbleweed, but it became obvious that this wasn’t deemed enough by itself when MicroOS came along. Your experience also confirms this. Hence, this might give a false sense of security. Don’t get me wrong; there’s definitely something brilliant going on here. But, by itself, it has proven to be insufficient.
• So…, is the if-clause satisfied? Answer: Nope. Hence it should be easy to understand why they’re not doing it. A perfect solution with no downsides simply doesn’t exist.
• Is all hope lost? Can’t we do anything? Answer: I hope it’s more than clear by now that it’s a hard problem. But, while not perfect, there are some steps one might take for their benefit:
  • Limit change. A broken/borked system/OS implies that it wasn’t before. So, something happened, i.e a change occurred, after which it shat itself. So…, the solution should be rather easy: just make no changes, right? Yeah…, that’s unfortunately not how we use our systems. But, we can limit it; which is where slow-moving distros come in. Downside: They have to move slowly…
  • Compartmentalize. Why should installing a piece of software make changes to your base system? We don’t see this in NixOS. Nor do we see this on Android or ChromeOS. Downsides: Integration isn’t best yet. And, you have to trust more instances, which ain’t ideal for security/supply-chain. But, if you insist, choose your poison:
    • AppImage
    • Brew
    • Distrobox
    • Flatpak
    • Nix
    • Sysext
    • Snap
    • Toolbx
    • … (Etc. You get the drill.)
  • Ensure that every state is a known good state by excessive testing. This is kinda hard to do on your own. But…, what if your (base) system is literally the same as the one tested by your distro provider? And you know that they’re testing it (perhaps even excessively) in hopes that they may find a bug/breakage before it ships to you. This is not 100% fail safe, either. But it’s a lot easier to test than the (effectively infinitely) many permutations allowed otherwise. This is kinda the route some atomic distros have taken. Most notably, Fedora Atomic and its many derivatives. Downstream like uBlue (so, Bazzite etc.) fares even better at this. Downside: I don’t think you can achieve this without going atomic. Which, is absolutely fine for some of us, but -crucially- not for all of us (yet)…
  • Rollbacks. We shouldn’t let perfect be the enemy of good. Combined with (some of) the previous points, this amounts to a reasonably robust system. Downside: Briefly discussed earlier. Refer to that please.

There’s perhaps more that can be written on this topic. But, I’ve already become tired and this text has already become quite lengthy. If you managed to come this far, thank you! Much appreciated!

but i do wish there was a bigger culture of “no regressions for users”

Isn’t that basically Cinnamon, Mate, Xfce (and most other DEs not named COSMIC, GNOME or KDE Plasma)?

Thanks for the response!

But not having a picture does not help lol. Perhaps using a live USB might fix it. But then again, that probably involves messing with kernel settings or whatever. Seems quite involved for a simple update…

I 100% agree with you. But we shouldn’t ignore that CachyOS -at the end of the day- is still just Arch. And, within its excellent Wiki, we find the following “Warning” in the section concerning upgrading packages:

“Users are expected to follow the guidance in the System maintenance#Upgrading the system section to upgrade their systems regularly and not blindly run the following command.”

If we follow the link, we find within the second paragraph the following important reminder:

“Make sure to have the Arch install media or another Linux ‘live’ CD/USB available so you can easily rescue your system if there is a problem after updating.”

Kinda on the nose, don’t you think 😅? So, to be clear:

• I agree that reaching out to a live USB after a simple update is kinda bonkers.
• Yet, I acknowledge that that’s basically within expectations for Arch.
• Hence, I don’t use Arch^[1]. And perhaps you shouldn’t either…

My Xbox controller was difficult to connect at times.

Thanks for clarifying! But, is this still related to issues with Bluetooth chips?

I’ve had installs with audio issues

Sorry, I simply can’t relate; simply, because I thankfully can’t recall being bothered with any such occurrence.

difficulties playing games because Lutris or Bottles wouldn’t work…

This, however, I can relate to. I’ve noticed that installing through one of the storefronts -be it GOG^[2], Steam, Epic^[3] (etc)- is a much better experience. And even if you don’t own it through any of the aforementioned platforms. Chances are that both the Steam client AND Heroic Games Launcher will do a splendid job at running the game. To be clear, I’ve use both Lutris and Bottles in the past; the latter quite extensively even*.

Why sometimes Linux is hard to switch to

Switching is easy. Sticking to it is harder and involves relearning most of your activities in a new context.

So now I face another reinstall…

I’d honestly think that CachyOS was more ‘sturdy’. Though, I suppose it’s curious that you don’t mention anything about your troubleshooting attempts. Beyond your rollbacks in hopes of resolving the issue*. If you don’t like/want to (learn to) troubleshoot, then reconsider if CachyOS is your home.

FWIW, over (almost) 4 years of Fedora Atomic, I was only once ‘forced’ to reinstall; which happened in the first week (or so). And that was 100% a user error.

This and having to dive into the deep end of terminal commands to get drivers, programs or games working can be quite frustrating.

This isn’t recognizable to me. Would you be so kind to clarify/elaborate? Perhaps with an example even?

I understand why people are turned off and go back to Windows…

The only time I felt this, was when I just cold-turkey switched to Fedora Silverblue and bashed my head to the wall when trying to implement Madaidan’s hardening 😅. But, again, that was just very naive.

Onto NixOS for me.

NixOS is definitely based. So go for it.

What would your ultimate distro be like?

Stateless, and hardened AF. So, probably an amalgamation between your favorite security-focused Linux (be it secureblue or Qubes OS) and NixOS for its impermanence module.

I feel like you’d love tldr.

OP, I urge you to clarify and/or elaborate in case you desire better engagement. Like is your goal to make a long list of Wine-related software? Or, instead, understand which one is preferred?

Furthermore, a more meta suggestion: a quick glance at your profile shows that you have almost three times as many posts compared to your comments. You’re free to engage however you wish. But please, consider engaging more with the community output. Thanks in advance!

Ah, okay. I was looking at niri’s .gitignore 😅. But yeah, I can see it now. Thanks again!

Thank you for the intro, that helped.

Glad to hear it was helpful.

Sounds like Mint not having it is relevant

Yup. FWIW, there’s also the security argument; I.e. X11 makes keylogging trivial, while Wayland provides protection against it by default. Having said that, there is experimental support for Wayland in Linux Mint. But, ideally, it needs more time to cook.

Thank you for bringing this up! But, while you’ve clearly pointed out where to look at, it wasn’t quite enough for me to understand what exact content gave it away. Was it

• short/brief .gitignore?
• /target?
• /result?
• Any combination of the above?

I desire to learn this in the hopes of improving my vibe-code radar.

Regarding its architecture, the table says about Wayland the following

Single unified Compositor handles everything

While this has been true in practice, this isn’t dictated. For example, very recently, we’re finally seeing the decouplement of the compositor from the window manager. Granted, this is still a very recent development and we don’t know if others will follow suit. But I’m excited to see where this will lead us.

I suppose it depends mostly on what you intend to do.

FWIW, Wine makes you potentially vulnerable to malware that targets M$ otherwise. As such, I prefer sandboxed solutions. This used to be Bottles for me. However, currently, I don’t have any need for it; I play my games through the Heroic flatpak and don’t need Wine outside of that.

what is wayland

Basically, whenever an app has a GUI it wants to display, it communicates that to ‘the system’ with all the necessary details. After which ‘the system’ does the rendering and whatnot. Wayland is a protocol that defines a set of rules on how this interaction should take place. Hence, technically, it is only (the defining) part of the modern solution.

how important is it?

Very. Basically, either it or its ‘predecessor’^[1] X11 is involved whenever you want to display/render anything^[2] on desktop Linux. As X11 has been abandoned in favor of Wayland, some modern features like HDR or VRR are only found on the latter. On the other hand, I believe Wayland was never meant to offer full feature-parity with X11. Hence, some unsupported edge cases may continue to exist indefinitely. Thankfully, it has come a long way. What remains are some concerns related to accessibility AND the adjustment^[3] of the surrounding ecosystem.

Shortlist of traditional distros, ordered roughly in descending order:

• Linux Mint^[1]
• Zorin OS^[2]
• CachyOS^[3]
• Fedora^[4]

Shortlist of Only^[5] recommendation for atomic distros:

• Bazzite^[6]

As for deciding between a traditional or atomic distro, I’d personally suggest to try out Bazzite first. And refer to their documentation whenever something comes up during initial setup. If at any point, you’re not able to get it to work even with the help of its community —^[7] be it through their Discord, Discourse or subreddit — then simply pivot to the traditional distros.

Necessary pre-empt: I’m literally u/pheusie. But I got no clue how I can convince you of that beyond “Trust me bro.” as I’ve changed the password of u/pheusie in hopes of never returning to it; kind of my way of dealing with this unhealthy habit of mine 😅.

Anyhow, without further ado…

Microsoft Surface

Hehe 😅, I hope you’ll not be met with any problems. But, if you’re concerned, consider checking this link out. Perhaps some distros take this into account and install the kernel for you (or at least provide a streamlined way of doing so), but I’m simply unaware of any.

I do prefer free software but I only hate giving corporations more money than I have to. I don’t mind paying extra to shop local, I donate to the fedi instances I use, gog’s preservation fund, Wikipedia, and a few other similar things. If the money is primarily going to the people who are actually doing the work or to the cost of equipment and maintenance then I feel a lot better about paying for something so I’m willing to consider paid software if it’s better and will probably make some kind of donation to any FOSS projects I get software from if it’s free.

That’s great to hear. Unfortunately, I can’t vouch on the effectiveness and reliability of any commercial product used for securing desktop Linux devices.

I’m not worried about keeping up with feature updates or always having the absolute newest version. I want it to be stable and functional so once I have it set up security updates will be the thing I’m most concerned about. I’m fine just setting an alarm and checking for updates every Friday or something like that. Background updates are nice but it’s not a big deal to keep up with it manually if it’s centralized into a repository.

I suppose this should have sealed the deal; i.e. we should have been able to logically arrive at a (set of) distro(s). But…, I’m clearly hesitant because the options aren’t as great as I’d wish. To give you some insight:

• Logical choice would be: Debian (LTS) or Ubuntu (LTS), because they seem to offer (at least) decent~ish support for the linux-surface kernel AND both are slow-moving distros. But…,
  • Debian is only an excellent choice as long as you don’t do a major release upgrade. Like, that page is SO MUCH MORE involved that it has any right to be. By contrast, the distro I’m on does automatic major release upgrades in the background. It doesn’t even notify me 🤣🤣🤣. Like, that’s how smooth it can (and perhaps should) be. Without receiving a major release upgrade, Debian is at best usable for three years. Which, ain’t bad, I suppose. But it’s definitely not great.
  • Debian LTS grants Debian some much needed longevity; 5 years instead of 3 years. But, they don’t receive direct security updates and support by Debian’s Security team. Hence, if you’re concerned about security, then this is definitely concerning.
    • Note: There’s also a Debian ELTS, that extends this further to 10 years. But it’s commercial. Unsure if that’s a desired solution.
  • Ubuntu’s documentation suggests that upgrades are handled a lot more gracefully compared to Debian. But, the discourse will inform you that Ubuntu is plagued by Snaps. As that’s a can of worms I’m not willing to open, I’ll leave it at that 😅.
  • Unfortunately, Ubuntu LTS doesn’t fare better in that regard.

So…, you might ask: “What about downstream?” The response would be that I’m unaware of any that are both popular AND known to have a dedicated security team.