this post was submitted on 04 Jun 2026
84 points (80.9% liked)
Linux Gaming
26096 readers
127 users here now
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
No memes/shitposts/low-effort posts, please.
Resources
Help:
- ProtonDB
- Are We Anticheat Yet?
- r/linux_gaming FAQ
- Fork of an earlier version of the above
- PCGamingWiki
- LibreGameWiki
Launchers/Game Library Managers:
General:
Discord:
IRC:
Matrix:
Telegram:
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I love it like I loved Antergos (RIP). I've done "real" Arch and ran it for years but I don't care enough anymore to configure and install every inconsequential thing, so Cachy is perfect. I really just want the newest software and AUR but the optimisations Cachy offers are also a huge bonus
To me Cachy is too opinionated and does too much. In example I don't like they went with Alacritty, BTRFS and Fish shell by default. If I have to change the deafults anyway, then why would I need the distribution? The only thing that would be of interest to me is the custom Kernel for gaming optimized performance. I think that can be installed on Archlinux too, but I never tried it. Therefore I prefer EndeavourOS, which is basically Archlinux easy mode for initial installation and setup phase. I wanted to try out Cachy too, but there is just no reason for me to use it over Endeavour.
I just go with Arch proper. I install once, and it's like 30 mins versus years and years of use, so the installation part is pretty inconsequential.
Picking my own software is of highest value.
I second this. The only issue for me was not knowing what to install and use.
E.g. I didn’t know about the sound, and used something old (PulseAudio?) before I learned it should be PipeWire / WirePlumber (or something like that). Honestly, I still don’t understand that properly.
But the point is, I had my sound working ok. Then I had some use case, when it didn’t work. Perhaps with my Bluetooth headphones. Then I just switched to a better newer system, and the thing was resolved automatically.
Theoretically, there might be other aspects of the system when you simply not aware of them. But I think there are not too many, after all. Since I use my Arch Linux computers (PC and laptops, and even a couple of once-Windows tablets now running Arch too) all the time, I mostly settled. And now I don’t even need to reinstall, and setup things, like ever. I needed to migrate to a newer laptop, and to some other computer, I just cloned my system, and was done with it.
With any derivative distro, there’s no confidence in it being present in, say, 5 years. I’m pretty confident in Arch at this point.
Not saying them, derivative distros are bad. If they allow new people jump wagon, great. They’re comfortable with Arch, and perhaps it’s even trivial to rebase such a distro to pure Arch at some point. And I hope them (these distros) contribute to the mainline, not just parasitising off the original work, like DHH et al.
Also curious what you have against those particular things you listed.
I used Alacritty and Fish before and I'm not interested into the features and complexity of BTRFS. Alacritty is a fine editor and wouldn't mind using, but it lacks features to me and there are better alternatives. I would prefer Kitty. Right now I use Konsole and that's good. Fish on the other hand, is more problematic to me. I use the terminal a lot and I am used to Bash, even write lot of Bash scripts. They are very similar, but still different and not compatible; so for me its a struggle in the terminal to remember the differences between Fish and Bash. There is 0 reason for me to use Fish and prefer Bash.
I instantly fell in love with the design choices of fish. It does things differently and more simply than bash. The syntax is actually readable linguistically compared to bash. Very conscious choices, and there's usually just one way of doing things, and they just make sense.
I converted all my scripts from bash to fish. They are 50% less LOC, have zero comments in them, and I can actually come back a year later and instantly make an edit because I can actually read what the code does. In my bash scripts I did have comments, and I still had to bring up the manual to make an edit...
Fish's language really is very small, you basically can actually fit its entire syntax footprint in your brain's working memory. It's great to work with. Highly recommend giving it a more serious shot for anyone who is curious of a better world. 😊
I agree with you that Fish is in language design choices and the default features. There is no denying in that and is the reason why I used Fish as my main interpreter for weeks. But that would not change the fact that I read and write scripts, either for me, to share or to help others, let alone the legacy stuff. Bash is the standard.
So scripts would stay in Bash for me, and only the interactive interpreter was Fish. And that was a problem for me. Because Fish and Bash are similar, but they are different enough that I got always confused which way was to do and write scripts. Especially because Bash had some quirks (yes its bad, not denying it), and Fish didn't have them. I thought that I would get used to, but it was always confusing. I rather have a language that is completely different, not similar but different.
So, if I was using a different language that is no longer compatible with POSIX or Bash, then why would I use Fish instead any other language? Why not Xonsh (Python) or Nushell in example? Because that's the category I am looking Fish at, not to replace Bash.
I think this is a great question, and the answer is probably more nuanced and personal, even per use case.
I use fish because of its simplicity, period. And it had all the features I wanted from zsh built-in, with zero or simpler (actually understandable) configuration.
I don't help anyone with bash or write or share scripts, so I don't have that issue where I need to juggle multiple shells, which is lucky for me perhaps. 😌
But those other steps you mentioned probably are a bit more niche, let's say. I think nushell is more tailored to people using the shell to process a lot of data. Digging through logs, perhaps. Debugging systems, or systems management/maintenance. Then it's really handy to be able to process output as data tables, with proper sorting capabilities etc. Nushell is really powerful for that. I actually have it installed because it's already useful sometimes but I barely know any of its specific commands. 😅
Anyway, the choice of shell really is very personal. For me, fish and bash share the same purpose of being used both interactively and as general-purpose scripting languages. And since fish is better in my opinion I chose it. But if I had other use cases, maybe a different job with different requirements, I would make nushell my default. 😁
To be clear, I understand the appeal of Fish and its reason to exist. It's just I convinced myself that the standard shell should be POSIX compatible (had used ZSH for years too, before trying out Fish). And frankly, I am good enough in Bash for daily use and for scripting, that I can use it. Every time I look at Fish (to almost try it again), I'm jelious about some of the syntax and trap cleanups and features. Maybe one day I change my mind. I actually have plans to install Fish again and see how it goes.
Nushell is really an interesting one. This is how I imagine a modern shell should be like. But the reality is, that all the Linux tools and commandline are not based on this concept. That's why I never got into. And Xonsh, well I write Python too, and not sure how confusing that would be... I just brought up these shells to make a point about Fish being different and that I categorize it like those.
Oh yeah, you were clear about that, not to worry. 😊
Nice, I hope you do! You're welcome to join The School! 😄
Yeah, I get you. Definitely a reasonable way of looking at it, too.
Personally I find fish to be a general-purpose shell, despite the fact that it is not POSIX-compatible. So in my mind it's in the same category as bash, csh, zsh, ksh, etc. It just does things very differently. 😄 But that's just my personal mental model.
Anyway I'm here if you ever want some tips on how to do stuff idiomatically in fish, if you ever do decide to get started. 👍🤝 Hit me up in the DMs or something.
Is there any particular reason why you prefer that one specifically? Out of all the newer terminal emulators I have tried, the only one I disliked more than kitty was warp.
I used both when I was a tiling window manager user. Kitty is feature rich and has everything I would want. I would prefer over Alacritty, because I miss feature. However on my last OS installation, I kept Konsole (from KDE) as terminal emulator before I did all the basic setups and was planning on installing Kitty again. But it turned out that Konsole is excellent and there was no need to change, so kept using it.
Why did you dislike Kitty?
The protocols designed for Kitty are great, but I when I last gave Kitty itself a try, I felt it was extremely opinionated in a very off-putting way.
It was advertised as being highly extensible and scriptable, but despite that, I found it to be less flexible than my old setup which wired up tmux with Python scripts. For instance, I was able to track which pane was previously active when creating a new split, allowing me to have the newly-created pane's bashrc read the old pane's bash /proc/ entry to copy the environment variables. That wasn't possible in Kitty. And although Kitty's splits layout were functional, resizing the splits themselves was an unconfigurable pain in the ass because the sizing is based on width/height rather than bounding boxes.
I would normally chalk that up to growing pains of a new project, but reading through the GitHub issues and documentation didn't leave me with the impression that the author cared about how something could be done in Kitty, but only that it could be done in the most basic sense. If the user's workflow would benefit from having a partial overlay or popup, tough shit—they can either use a full overlay or create a layout for it.
It didn't sit well with me, and moving to Kitty full time would have been a downgrade in productivity for practically no real benefit.
I'm not the one you asked, but I use Kitty.
It's the only terminal emulator that has consistently worked without bugs for me out of all the terminal emulators I've tried. And I've tried soooo many. Probably about 20, given them all serious time and a real shot, configuring each to my liking.
One thing I don't like about Kitty is its configuration file format. 🫤
I like fish, but I don't think I'd use it as my default shell
Force of habit is very strong. I was enthusiastic about trying another shell and committed myself to breaking my habit and learning something new, and I'm oh so glad I did.
I like them both. All I have to do to switch is type bash at the fish command line and I'm instantly in bash.
Lol I was going to say the exact opposite... All I need to do is type fish and I'm instantly in fish.
Personally, I prefer to have the tried and true, if basic, shell as my default, and if I want auto complete, etc, I'll just type fish
There's really nothing about bash that I "like". Bash is just bash—it's the baseline. Then there are things that fish does better, and there are things that fish does differently. But there's absolutely nothing that I feel that bash does better than fish.
The Cachy kernel is in the AUR if you're brave enough.
I gotta say that I agree with many of Cachy's choices. I use Garuda, which makes many of the same choices and uses them effectively. For example, BTRFS is a good default choice if you also have default Snapper with pre- and post- update snapshots.
I don't remember what the shell and terminal emulator situation looked like, but I do remember that the installer specifically asks you to choose how you want to partition, so it seems unfair to me to complain about it being the "default".
I put it on my laptop, which I barely use, and just had it still running Win10 until the SSD died. It seems really nice for that purpose, to just get a quick and easy install for a secondary device, while keeping access to everything else I like about Arch.
Well, that wasn't a "complain" as a default by me. Its a valid choice (besides Fish I think), I just don't agree with that choice. What I meant is, if I don't use this default anyway, then why would I need to install the distribution of it? It's like choosing Kubuntu to install, only to remove it and then turn it into GNOME. I know this is an extreme example, but hopefully that makes it a bit more clear what I initially meant.