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!

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 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.

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.