CachyOS: Fast and Customizable Linux Distribution
cachyos.org
cachyos.org
It uses an online installer that lets you choose the desktop environment, boot manager, file system, among other things. You can follow the defaults if you're new. Once you install it, it also comes with a few helper applications that can quickly set up things you'd want to use, like a one-click button that installs all the gaming packages you want to use and their flavor of Proton which is (allegedly) faster than the default.
They also have a really good wiki which I contributed a bit to and a very active community if you need help. All around, 10/10 would recommend to anyone. I managed to convince my friend who's new to Linux to use this instead of Zorin and he's had a great time.
For me it was Debian 12 with Sway (Wayland) followed by Debian 13 with labwc and Sway.
Now I can switch from a tiling window manager (WM) to a floating WM depending on the work task.
Is there an option to stay permanently in floating mode, and allow manual placement? I'm stuck on AwesomeWM using just floating windows with easy keybindings for moving them around/resizing, etc. and am looking to jump from X11 to Wayland
And when on a laptop I maybe do a split view 2-3 times a day for a short term. 95% of the time it's full sized windows which I switch between using keyboard shortcuts.
I also just like the predictability of placing a window in a location and then the next time it spawns in the exact same place I last left it
A lot of the current defaults stem from the 90s, and often were eyeballed by the creator of said code. They're not good defaults for modern servers nor workstations nor laptops nor desktops. And all of those devices work best with different defaults.
It doesn't seem (yes, appearances can be deceiving) to be that much work, because no extra code needs to be written. For each variant, just set different default parameter values for stuff like swappiness, lazy RCUs and what not. Make it a thing to revisit the defaults every 10 years.
CachyOS and some other distros already do this, but a big chunk of distros doesn't because they think the defaults are well-thought out.
Maintaining a large distro is extremely difficult and every decision has several trade-offs.
Based on what I saw 1-2 years ago last time I looked at it, most distributions to customize and don't use the defaults straight up. From memory, so someone correct me if I'm wrong:
- RHEL/SLES - Lots of patches to kernels
- Arch - Closer to just using defaults, some config choices and downstream adjustments (so the opposite of CachyOS almost, which is why we have CachyOS in the first place)
- Ubuntu - Probably the most patched distribution compared to upstream components, also includes a lot of Canonical-specific stuff on top of that.
- Fedora - Has some bleeding edge bits and bobs
- Debian - Bit more conservative than Ubuntu, but still has patches for stability, security and backports.
In my experience, distributions changing the defaults and customizations seems to be the norm rather than the exception.
Which makes each and every one of those totally different operating systems that can run similar code to each other. We need to stop thinking of these as Linux "distros" and start thinking of these as totally separate and distinct operating systems that are based around the Linux kernel. Sort of like a business cooperative model.
I've been preaching for a long time that "distro" is the wrong term. Each "distro" is absolutely it's own, standalone operating system. There is no universal "Linux OS" outside of the kernel. Even userland can be swapped out.
Genuine question! I maintain my own Linux distro (upstream Linux + portage) for all my devices and haven’t found much reason to go beyond kernel per arch. I’m curious if there’s something I could be missing.
vm.swappiness defaults to 60, which is default from when everyone was still running spinning rust with a swap partition. Servers these days usually have very specific storage+memory configurations, whereas the usual desktop or laptop has an SSD and 16GB+ of RAM with RAM compression expanding it.
Lazy RCU loading is good on a laptop because you only lose about 10% performance and only with specific workloads, but your idle and light load energy consumption improves. Most laptops spend like 95%+ in light or idle load scenarios. Conversely, on a desktop you don't care (much) about idle and light load energy consumption, you only care about keeping max load consumption low enough so that your fans stay quiet. And on a workstation you don't care about a system being whisper quiet so you can go nuts with the energy consumption.
So far my kernel journey has been about making my hardware work + enabling features, and that’s mostly how I’ve been discovering config options. Do you have any suggestions on where one aught to read further on this sort of kernel tuning?
EDIT: doing some further research, couldn’t you just set those options via sysctl w/o needing to build a separate kernel?
You don't need to compile a specific kernel for that, this is setup via sysctl.
Do you mean RCU_LAZY? Most distros will already enable that: it doesn't do anything without rcu_nocbs, so there's no negative impact on server workloads.
[calvin@debian-trixie ~] grep RCU_LAZY /boot/config-6.12.57+deb13-amd64
CONFIG_RCU_LAZY=y
# CONFIG_RCU_LAZY_DEFAULT_OFF is not set
[calvin@debian-trixie ~] grep RCU_NOCB_CPU /boot/config-6.12.57+deb13-amd64
CONFIG_RCU_NOCB_CPU=y
# CONFIG_RCU_NOCB_CPU_DEFAULT_ALL is not set
You just have to set rcu_nocbs on the kernel cmdline.
For the first, I want the lowest latency for everything I do, together with the highest burstable speed whenever possible, for pretty much all the components.
For the servers, I basically have two types, one which does storage, they just need large disks that can be slow, and one which users actually connect to, that one needs focus on throughput, latency and performance isn't as important as "can serve all requests in a reasonable timeframe, even under load".
Finally, many of the portable devices run on batteries, so on those the focus is power-saving, even if it compromises on performance.
I'm sure others out there have more device types, like ultraweight watches, security devices, monitors, radios and much more. Each one of these have different tradeoffs, and tuning the kernel and OS for each use case makes it a lot better usually. Personally I use NixOS for everything except my desktop (CachyOS right now!), and it makes it really trivial to create profiles based on the same configuration, deployed to all devices, and today they're are tuned for exactly their purpose, as Linus intended :)
Migrating my i3 config to sway hardly took any effort. I was also able to get rid of a lot of xorg specific configurations from various x11 dotfiles and put them directly in the sway config (Such as Natural Scrolling)
[1]: https://itsfoss.com/news/kde-plasma-to-drop-x11-support/.
I’m happy with XFCE now and it is very performant.
I don't know why.
Last time I started an endeavoros install with a default i3 it borked the login manager and set no system handlers of any kind. When I went to fix the handlers the entire package that set them was gone. When I went to install that (on the advice of the accompanying forum) I had to install most of GNOME.
If you're using something that isn't KDE or GNOME you're probably going to hit rough edges.
I had tried Manjaro i3, and XFCE’s i3 variant but at the end it was actually more convenient to install the KDE version and then install i3 on top.
Anymore it's literally anything that isn't GNOME. Red Hat is basically keeping that project going.
This is actually what forced me to migrate to Wayland, seeing lots of people complaining about Wayland but not seeing people stepping up to maintain X11. And those who used to maintain X11, built Wayland instead.
Yes, Wayland isn't perfect, but for professionals who just want shit to continue working, you kind of have to move to the software that is being maintained, for better or worse.
Wayland on the other is just a insanely stupid API. Everybody advocating for Wayland should be forced to write a simple client at least once without relying on behemoths like GTK or Qt.
If by "people" you mean a fascist who doesn't know how to program, then sure. But the sensible people who don't present a security threat with their politics or with shitty code are 100% in the Wayland camp.
> Also the people that used to maintain X11 (e.g. Keith Packard) had nothing to do with building Wayland.
Those people aren't maintaining X11 today, are they? The people who are maintaining X11 today have put it in bugfix-only mode and have told you, many times, that the future is Wayland. End of discussion.
Look, you want to run a retro 90s desktop for shits and giggles, that's great. There's even an officially supported path for this use case: Ariadne Conill's Wayback. But the DEs and the toolkits are all removing X11 support within the next year or two. There is no future there. You want to keep running modern software, you will have to switch to Wayland eventually—and soon.
> Wayland on the other is just a insanely stupid API. Everybody advocating for Wayland should be forced to write a simple client at least once without relying on behemoths like GTK or Qt.
Nobody actually develops applications that way. They all use a toolkit, and the behemoths cover pretty much 90% of actual application development (modulo things like Electron). Both of those, by the way, are deprecating X11 support.
Yeah, lies and then you come in with shit like this. You can surely show several proofs then, right?
> Wayland on the other is just a insanely stupid API. Everybody advocating for Wayland should be forced to write a simple client at least once without relying on behemoths like GTK or Qt.
Why would you do it outside of toying around? Btw, I have and it's nothing out of ordinary.
was the statement I was replying to. In 10 years of using dwm I've not been aware of any bitrot that affects me. Certainly nome in the WM itself.
Always the same lies...
Edit: You really do like calling other people liars and fascists?
Not sure how much I like "hand-write your own code from snippets" as a way to configure software.
And while you have a good point, I don’t think this is what most people have in mind when they use the term “bitrot” (but I could be wrong). I say this because dwm as supplied continues to work perfectly without modification. The patches are enhancements contributed by third parties (as far as I know) and, as you’ve discovered, are not maintained.
(Also, once you have a working, patched dwm, it should continue to work forever, even if the patches that you used may no apply automatically to future versions of the base dwm.)
Last activity 2 hours ago at time of writing.
https://gitlab.freedesktop.org/groups/xorg/-/activity
Most of the people complaining are users who don't write any software. There is no practical difficulty in using an x11 wm at this point nor expected to be until major software not only doesn't support x11 by default but cannot be built with support for same.
Maybe it will be difficult to run X in 2030?
And given that Wayland has less moving pieces (it properly sits on top of kernel abstractions), your take is even less likely to be true.
Wayland despite receiving huge amounts funding has actually far more moving pieces. Even for the simplest tasks you have to deal with a dbus infested portal maze, many parallel infrastructure effects and high fragmentation. The API is atrociously stupid and cumbersome.
Besides that the modesetting driver of xorg also sits "properly on top of kernel abstractions". How is this in any ways a relevant criterion. What matters is that Wayland clearly makes the wrong abstractions for Desktop applications and the vast amount of parallel infrastructure required to do even the simplest tasks shows that.
Citation needed
> Even for the simplest tasks you have to deal with a dbus infested portal maze
The simplest task is displaying a buffer, or changing a buffer, or handling events, and absolutely none of them have anything to do with dbus whatsoever. Also, have you seen an X11 desktop environment like KDE or Gnome? I recommend looking at all the dbus messages that are in flight there at any time.
For a very strange definition of "perfect".
Dbus does suck, I'll give you that.
Ubuntu and RHEL exist, but you're right that they're outliers. This is potentially the next killer app if someone wants to take this on.
There is no "Wayland" that can stop being developed. It is a protocol and a consensus, nothing more.
Hence there is no community.
Also the whole "there is no Wayland" "it's just a protocol" spiel has been played so often that I believe Wayland apologists are mostly bots.
An absolute metric TON of code in general that is/was largely dependent on free $0 volunteer labor has been bit rotting for the past 5 years. The COVID pandemic and the ongoing tech layoffs have really opened our eyes to just how much tech got built for free by firms pushing "always be coding" down our throats in the 2010s. It's why the only truly stable Linux OSes right now are largely Ubuntu and RHEL (even more RHEL lately) - you get what you pay for if no one else is footing the bill.
IIRC, I tried to build vim from scratch, but during the menuconfig, selected different "cflags" (or whatever they call them) to add additional features. When you do this, it pulls in more packages, and eventually something failed to compile the way I had configured it. I realize there's probably N! different combinations of packages / dependencies. But still it left me thinking "why bother releasing this crap/give me the option to customize at all if you don't even do basic tests on it?".
And the more RTFM style talk I hear about getting Linux to work, the more I want to buy a bunch of Mac Minis instead. I have actual work to do.
Me too. That's why I use Linux.
If you decide to delve deeper into Linux then it pretty much becomes a high investment -> high reward thing. There's a learning curve, but you can customize everything to be exactly how you want, and there are no black boxes whatsoever.
What does this mean in practice? You set it up once, exactly the way you like it, and it runs stable forever. It has no misfeatures constantly shoved down your throat (like with e.g. Windows, with AI, ads, telemetry and bloat). Your UI doesn't go through pointless redesigns every few years (like with Windows and macOS) if you don't want to. If you don't like something you can peek under the hood and change it.
The total amount of time I've spent maintaining my Linux system (or in your parlance: "getting it to work") over the last decade is, I don't know, maybe a dozen hours? But yes, if you're a beginner this is indeed unrealistic.
No it doesn't. You still have security patches to install and stuff. And one minor patch can still introduce a breaking change that largely destroys your install.
Pretending that this can be mitigated because it's open source goes straight back to my RTFM comment. You're basically saying that someone has to learn a ton of computer science stuff to be able to use Linux. I'm saying that cannot and should not be the case.
Linux based operating systems have to be able to be used to most of their capability by someone with less than a K-12 education. Anything short of that is a non-starter.
There are all sorts of customizable. CachyOS' use of that word is rather inspecific. I guess it means the compilation flags are better customized for your CPU, plus it is easier to choose a kernel with a different scheduler enabled. So, "more customizable" in that sense.
Of course you could ask whether you could 'customize' your distribution not force you to use systemd. Most popular distributions fall flat on that one, I'm afraid...
- compiler used for building the distribution, - libc implementation, - C++ standard library implementation, - coreutils implementation, - system shell, - kernel (e.g., using Hurd), - PAM or equivalent, - util-linux, - package manager,
and so on. systemd is just one more thing in that looong, looong list.
It's good as a cutting edge OS but I don't consider it the most stable.
A properly customizable distro allows organizing and tracking patches in layers, etc.
Sure this could probably be a package in a more "traditional distro", but I'm almost sure most people don't expect their Display Manager to be replaced with Steam when they install a package.
You can add steam big picture mode as a session type which would let you pick it from the login manager (the same as if you had both GNOME & KDE installed, for example). There would be no need to replace anything.
There is unlikely to be a time that "things stop moving" enough to make all these trade-offs go away, but you can pretty much just add all this stuff to the base distro yourself anyway if you want to (I still play games on vanilla Silverblue, for example).
For this group, needing to follow wiki guides and such and spending time on basic system functionality just isn’t happening. If that’s the only option, they’re just going to reinstall Windows.
I think the group you're thinking about are console gamers, who never had to upgrade drivers, never dealt with mods and generally has a very different experience compared to PC gaming.
I’m increasingly leaning that direction. Day job is software dev, have been using and/or tinkering with some form of *nix for almost 25 years, and have been using computers for even longer and sometimes I just don’t have the patience for fiddling around with computers to coax them into doing what I want them to.
You shouldn't have to do that even on Linux. It's a big thing that holds Linux back.
> PikaOS Linux is a Linux distribution based on Debian's cutting-edge "Unstable" branch [...] [1]
Trademark and reach.
Gaming distributions don't run a stable version of Linux distributions. They're always a spin-off from one of the popular Linux distributions (rebasing every once in a while), with additional changes tailored towards gaming.
Now, you cannot just say I call my distribution Debian GNU/Linux Gaming Edition. If you would, you'd need to work under the umbrella of Debian. With a different name, you differentiate from Debian, while you can keep the advantages of their framework (hello Ubuntu).
* Manjaro is Arch.
* Cachy is a patched Arch (exactly what Arch avoids, heavy patching).
* SteamOS is Arch.
* Arch is Arch.
It doesn't take a lot of work to get any distro to become a good gaming machine, but it does take some work to make it a seamless turnkey gaming machine for the masses.
Seems like you're blinded by your own context, if CachyOS for example see patches, integrate them earlier than upstream, and let user use them today rather than "long term", how is that not useful or beneficial to the users who want/needs that?
Besides, testing patches this way sounds like it'll have wider impact in the community than just the distro that integrated the patch, as it'll have a way wider testing userbase then. Isn't that also good long term?
Which is very pointless if it's three years late for e.g. a game release
Also very few people want to tinker with every single little thing, they want a nice stable base that does what you expect and build upon it - that's why most people were fine with previous versions of windows. So if cachy fixes 95% of the issues for you, why not go for it? Saving time and headache is a reasonable thing for a focused distro.
I hope some of these work out. Honestly from a strict compatibility and ease of use standpoint nothing has been as simple or reliable for me as Ubuntu used to be. I left it due to snaps and premium nagging, but I've had the usual little "linux" quirks ever since. As much as I love cachy, my current quirk with it is that heavy disk writes tank the system aggressively. A bit of brief research suggests this might be due to using BTRFS, but I'm comfortable enough with the system that I don't want to do a total reformat right now.
I guess what I'm saying is that as much as I love linux there is still some refinement needed.
Sure, for some things you need to do base system configuration, but that is not impossible on something like microOs.
It also generally feels snappier for simple things like opening terminal, but I am pretty sure that was a kde neon issue.
I only use KDE so your experience might be different than mine.
I think both Arch and CachyOS would do fine with nvidia cards, but thanks to who I don't know.
With that said, I ran into an age-old problem: sleep.
(For reference, I have an AMD Ryzen CPU, RTX 4070 super GPU and some low-end motherboard and I am using the proprietary nvidia drivers.)
I searched the web for hours and tried a lot of things, including different kernels, but nothing helped. In the end, after I couldn't find anything new on forums, reddit, blog posts, etc, I asked chatgpt for some ideas.
It had me change BIOS settings, kernel params, nvidia module params (or something like that - I'm not well versed in this topic tbh), etc, but in some way waking up from sleep still did not work.
After it suggested some undocumented kernel param with the nvidia kernel module, I said that's it, let's try something else and reinstalled with Gnome.
To my surprise, it worked without issue. I've been using it like this for weeks now.
I have no idea if the explanation is good or not but chatgpt said it's because my hardware + proprietary nvidia driver + plasma wayland was a bad combination.
> To my surprise, it worked without issue. I've been using it like this for weeks now.
> I have no idea if the explanation is good or not but chatgpt said it's because my hardware + proprietary nvidia driver + plasma wayland was a bad combination.
GNOME has more paid devs than KDE and therefore has better quality overall. It sucks as I love KDE's UX but I had rough patches using it as well.
Though I definitely think the resources and guides Archwiki provided plus the fact that I had been distro hopping(Mint, Ubuntu, PopOS among others) the last couple years before I settled into CachyOS/Arch helped a lot.
I will say though(at least in my experience) attempting to use a tiling/dynamic WM like hyprland, sway, river, anything that depends on wlroots did not work well, which is to be expected as i dont believe any of the desktop environments I listed support Nvidia.
KDE Plasma(The default DE) and XFCE which I only used for a short while gave me the most stable and consistent environment. Generally I never promote CachyOS, but this is the first time I've seen it on the front page of HN, if you're willing to put in a little effort(i.e read through the CachyOS docs and maybe a couple pages of the Archwiki) I'm pretty sure CachyOS is the best experience "out of the box" for users with a Nvidia GPU/intel CPU/iGPU. Outside of straight up upstream Arch as long as youre willing to put in the time to configure it post install to optimize your system.
The discussion between supporters of these kind of distros and people against them are very similar to those between vegetarians.
"I don't know why the community needs a veggie chicken nuggets honestly. We have delicious vegetables."
"But veggie chicken nuggets have their place. They are quick and microwaveable, and they help bringing people in"
"We bring them in with preservatives and chemicals? Sweet potatoes are also quickly microwaveable.."
And so on.
I've used Arch Linux (always with a nvidia GPU no less!) since 2017 sometime, moved over to CachyOS just this year, and had no issues that weren't caused by myself in all this time.
I initially moved away from Ubuntu at that time, as I got so tired of dist-upgrade breaking my system every single time I tried to upgrade, so figured I'll at least understand the breakages better when they happen with Arch. But I never got Arch to break something by itself, it always end up being my fault.
I was always able to recover with some insights from random forum or Reddit posts, but I can't say this was the type hacking I wanted to do.
I'm hoping a rolling release is easier in the long run, but we'll see. Also this time I used a separate SSD for /home so that at least I could do a full reinstall and still keep my data.
Arch devs know how much friction manual intervention updates cause, so they try to keep them to a minimum.
Honestly, I've had more problems running windows than running arch.
Worst thing with Windows isn't the occasional "wtf, how do I undo this change Microsoft forced upon me?" but more "Damn, it's that time of the month where Windows force me to do X", most recently being upgrades that you cannot shutdown or restart your computer without doing. Used to be you could run some command to avoid it, but literally all the hacks stopped working.
So now I'm slightly afraid of booting Windows which I do sometimes, because I don't want to end up in the situation where I need to boot Linux for five seconds to do something quickly, but Windows is refusing to do so without first doing a 20 minute upgrade. Fucking disrespectful of people's time!
Never heard about pikaur before (Rua gang here), but judging by the screenshots, does it not allow you to review the PKGBUILD before building the package? Seems to me like the most basic feature a AUR helper has to have, since AUR is all user-contributed without reviews. Is pikaur really letting you install packages blindly like that?
Arch follows a rolling release model. It's inherently unstable, by design.
English has a specific word for that: reliable.
Pedantry aside, having a complex system filled with hundreds (thousands?) of software packages whose versions are constantly changing, and whose updates may have breaking changes and/or regressions, is a quick way of ending up with software that crashes or breaks through no fault of the user (save for the decision to use a rolling release distro).
Have you ever had to maintain a software project with many dependencies? If you have, then surely you have had the experience where picking up the project after a long period of inactivity makes updating dependencies much harder. Whereas an actively maintained or developed project, where dependencies are updated regularly, is much easier. You know what is changing and what is probably responsible if something breaks, etc. And it's much easier to revert.
Have you ever had situations where Foo has an urgent security or reliability update that you can't apply, because Bar only works with an earlier version of Foo, and updating or replacing Bar involves a significant amount of work because of breaking changes?
I won't deny that there's value in having the latest versions of software applications, especially for things like GPU drivers or compatibility layers like Proton where updates frequently have major performance or compatibility improvements.
But there's also value in having a stable base of software that you can depend on to be there when you wake up in the morning, and that has a dependable update schedule that you can plan around.
Also, you can use a tool like snapper + btrfs-assistant (both of which come pre-installed on Cachy IIRC) which lets you fully revert your filesystem (snapper rollback) or partially (snapper undochange) if something breaks. Just make sure to use a btrfs filesystem for that.
https://discuss.cachyos.org/t/qt6-upgrade-to-6-10-1-breaks-s...
Never heard about BORE scheduler. It is an additional patch to the kernel ? How stable is this ?
I've settled on sched_ext: BPF scheduler "bpfland_1.0.18_g5bff813c_dirty_x86_64_unknown_linux_gnu" -powersave for processes, and let mq-deadline handle internal storage, and bfq anything connected via USB.
What do you mean by "stable"?
As in? When I tried it, nothing crashed/segfaulted/appeared broken for the ~week I was using it, various workloads mostly programming with Rust, Python, PyTorch and Clojure.
I have an old Arctix RF headset, from back when they didn’t use Bluetooth and the quality was actually good. I’ve yet to find anything equivalent being produced today.
Under Plasma/KDE. I just followed their defaults in the installer, which at the time were BTRFS for the filesystem, whith systemd-boot, and everything wen't well. The only thing which I would have done differently in hindsight would be the boot partition at 2GB, which seems wasteful when only about 50MB are ever used. But shrug?
What else, hrrm, the stuff is mostly clocked down to 800Mhz, because of the chosen scheduler, in spite of this nothing ever lags. Though the systems have 32GB RAM, that should help with that.
It's really smooth, even on that old 'crap', even mostly clocked down.
I also had it never crash on me with anything, neither single applications, or system hangs.
After upgrading with pacman -Syu I immediately clear the package cache with pacman -Scc, because I never ever needed that.
At the moment I'm considering to remove the pacman hooks into btrfs-snapshots, because I never needed them either. Seems like cargo-cult to me :-)
I also let it bitrot for up to 150 days, meaning no updates whatsover, and then lifting it up in one accumulated rush. Effortlessly. In the past, because I've been lazy and couldn't be bothered. Lately more often :-)
I didn't reboot in these long phases without updates. Just suspend to RAM. Which works every single time. And the system stayed always responsive.
Their ZRAM setup is usable by default. No fiddling necessary.
With this stability I dared to activate https://github.com/graysky2/profile-sync-daemon / https://wiki.archlinux.org/title/Profile-sync-daemon and never had any trouble with it so far.
At the moment I'm having fun discovering a new world of audio experience with https://github.com/wwmm/easyeffects
How could I live without that?!
(Don't worry, cores stay at 800Mhz with that playing YT in FF, or watching a movie with MPV)
At least on my hardware it's the DREAM.
Oh. Did I mention I don't game at all? With the exception of maybe some Freeciv in the browser...
It's like a Arch brother that holds your hand slightly more, and have some "defaults" they nudge you towards in the docs, and some number-heavy software is slightly faster, maybe 10-15%, but overall it feels and works just like Arch Linux. To be honest, I don't notice a lot of difference and I think I'm as fine with Arch as with CachyOS, that's how little different there is between them.
But if you’re a gamer that also uses your PC for development or content creation you can’t go wrong with CachyOS.
https://github.com/Szowisz/CachyOS-kernels
Which enables you to run a Gentoo based system on the kernel modified by the CachyOS kernel team through a ebuild for the official sources on GitHub.
When emerging it deals with all necessary dependency flags and configuration for you, just a little bit tinkering with USE flags required.
Presumably because it locks your bootloader or something, such that you are unable to wipe your PC once you're finally done pulling your hair out and ready to admit defeat? ;-)
It’s basically an elegant weapon, for a more civilized age.
But also note that she eventually moved out of it > (note from 18 months later in August 2024: I’ve mostly switched back to Homebrew, nix was interesting but overall I think it’s not worth the complexity for me)
It appears to be done for the sake of hyping themselves as superior, but it's causing problems. I totally wouldn't recommend anything with such approach to new users especially.
Any views how sustainable it is for the authors to keep working on it? Is it just donation based or is there a bigger supporter behind it?
- It doesn't shut down properly most of the time, I have to cut the power ; which I do anyway to go to sleep but sometimes I forget after I use it in the morning before going to work, and it stays with a black screen and the fan running all day
- There are a lot of updates, a few Gbs per week, and I have to type my password several times a week (even when logged in), I can't find how to change that
- Sometimes after an update I'll lose an icon or two, or some settings like scroll speed, etc ; not a huge deal but forces me to google around to get the setting back
- Lots of apps are in flatpacks or snaps, I could try some other repos or maybe nix/guix/pkgsrc but I would lose the appstore anyway so I might as well look around for something else
- Some things seem painful to setup, nvidia drivers, incus/lxc, zfs on root... NVidia was the most important and I managed to make it work well now but didn't bother with the rest
I’m thinking of trying Ubuntu, but maybe T2 Linux will always be a compromise, hardly CachyOS fault I reckon.
And no, I don't bother with crap that needs a kernel level anti-cheat. Simply not for me.
- https://lists.archlinux.org/archives/list/arch-dev-public@li...
Not out of the goodness of valve's heart either, they want it for arm based steamOS devices like the frame. A win win for many though.
The Arch forums rightfully warn against this and do not want users of these distros, since all these distros are inevitably broken in their own weird ways.
There are multiple very reasonable distros. There is absolutely no need to make these forks.
FOSS is about freedom, freedom works best with options to apply to. Nobody is forcing you to do anything with these options.
By "nice" do you mean a distro which is fundamentally broken and far less supported then its parent distro?
>It’s alle achieved with these boutique distros which may display the best that’s out there.
It is displaying the worst that is out there, just with a nice interface. These niche distros are always the worst choices, because they lack in support and are all fundamentally broken.
Running someone else's patch set of Arch is the easiest way to have a terrible Linux experience. Having a nice interface to lull people into believing what they are getting is a professional product and then handing them a fundamentally broken system, where some hobbyists have patched a proper Linux distro so bad, that you are not even allowed to ask for help on the Arch forum is down right devious and presents the worst of the Linux world.
The truth is that Linux is mostly stable (even Arch), well supported and maintained. But this does not apply to these small hobby projects, which are just worse versions of their base distros with some ricing on top.
>FOSS is about freedom, freedom works best with options to apply to. Nobody is forcing you to do anything with these options.
At the same time I am free to warn people against this. These distros are a bad Idea and especially if you are new to Linux they will make you suffer far more than you should.
Except, this isn't the experience for the majority of users moving to Cachy, Bazzite, Zorin, whatever. What they're getting is a fresh, usable experience specifically in the "flavor" they care about.
Linux, and especially Arch, has an image problem, and it's the reason, despite how good these base distros might be, that people aren't coming. It takes a clever bit of branding and a marginalisation of all the gatekeeping (just like you're trying to do right now) to let users finally think "actually, maybe this is something I can use".
Yes, but it will be experience they inevitably will have once these differences will result in their OS being fundamentally broken and nobody being there to help them.
>It takes a clever bit of branding and a marginalisation of all the gatekeeping (just like you're trying to do right now) to let users finally think "actually, maybe this is something I can use".
Hilariously giving people a fundamentally broken OS, which they use based on superficial criteria is the best gatekeeper imaginable. Once the inevitable happens and their distro is totally trashed, they will never use Linux for anything again.
If you want people to have a good long term experience give them a well supported mainstream distro, instead of a fundamentally broken arch patchset.
>"actually, maybe this is something I can use".
Which is exactly the wrong thought. No, the fundamentally broken Arch derivative you are trying to use is much, much harder to use than Fedora.
Heh. I've been saying that since I was on Mandrake in the early 2000s. This is just what the Linux landscape is like.
That said, I'm generally not easily impressed, especially by random *nix distro 347, but CachyOS is surprisingly good. I've finally switched full time from Windows. I don't even need VS anymore because Rider is x-platform.
It's not a fork though. You can find out what a distribution is here: https://en.wikipedia.org/wiki/Linux_distribution
> since all these distros are inevitably broken in their own weird ways
Absolute statements should probably have some absolute and undeniable proof, what exact "weird" ways are CachyOS broken today, since you apparently think yourself to be experienced enough to know this?
Maybe it's time to stop crying, and try to see some positivity in the world rather than going into a dark hole constantly.
What? https://tracker.debian.org/pkg/hyprland https://packages.fedoraproject.org/pkgs/hyprland/hyprland/
>But couldn't for the life of me figure out how to install Arch.
I mean, come on. Sure, Arch is not for everybody, but if you are semi tech savy you could have done the internet searches I did and figured out which distros have hyprland packages. Both Fedora and Debian have them.
Arch is also not much harder to install than debian. Insert the image and go through the steps in the installer, this isn't some magic ritual. https://wiki.archlinux.org/title/Archinstall
I'll even help you. JaKool is the most popular option.
While you're at it, check how many versions the debian package is behind arch/upstream.
It blows my mind how confident people are about knowing something just because they read it somewhere without verifying it themselves.
Vanilla arch is missing so much niceties that take too long to setup.
When your line of thinking there shouldn't be any distros. Just mainline Linux kernel.
Lately, I've been going the opposite route and using RHEL more and more. I've had a couple breaking changes lately that have been caused by software under rolling release practices, which has made me begin to appreciate operating systems where their APIs and stuff get sort of frozen in time for up to a decade. In fact, this is still a big feature of Microsoft Windows.
I mean, if a server distro can be made to be "LTS" for 5-10 years, then why can't we have a decent desktop Linux OS be like that as well (besides Ubuntu)?
[1] I realise CachyOS makes some kernel modifications, but is that typical?
Yes, very common. I think not making modifications (like Arch) is the atypical case, as "unmodified from upstream" is one of the core value propositions for Arch and why we chose it in the first place.
Still, CachyOS is probably an outlier in the amount of tweaks it does, and the amount of choices it surfaces to users about those tweaks.
https://wiki.cachyos.org/features/optimized_repos/#adding-ou...
Regardless, there are people who want to avoid distributions made by Russians. Are builds reproducible? Where do these people reside? Could be important.
Well, racism / citizenship-based discrimination is a thing, yes.
> Are builds reproducible?
A valid question, but what does that have to do with the ethnic background or citizenship of the distro makers?
> Where do these people reside?
It seems their team is from all sorts of places, although it doesn't exactly say where in the world each of them is located:
> A valid question, but what does that have to do with the ethnic background or citizenship of the distro makers?
Allows security researchers to verify the binaries and/or find intentional backdoors.
> It seems their team is from all sorts of places, although it doesn't exactly say where in the world each of them is located
Lots of words for 'I don't know'. Me neither, that is why I am asking.
Bit ironic to continue posting comments here, isn't it?
None the less, I agree with your worry and caution based on where software is produced, but I enact that by checking my OS/software before installing/updating it, not spreading FUD on internet forums.
The thing with citizens of Russia and China who reside in their respective authoritarian country is they cannot be held legally accountable.
Rude
(A perspective based on 25 years of using Linux fwiw)
Not to mention that distros like catchy help to push these changes into mainline.
one reason is better sw support,e.g. Arduino, android, vivado,cuda,you name it,all are supported out of box, saves a lot of time for me
I run Arch and my 9070 xt experience was poor for several months after release. I can't imagine modern gaming on an lts release.
Cachy being Arch based and recompiling with modern cpu flags doesn't seem to be targeting the users who want unchanging boring software.
Bullship, I've used it since it came out in 2006 for everything including gaming (I'm a gamer). And that is on nvidia since then too. Not the same card, various nvidia cards over the years. All worked great. Ubuntu works great.
Ubuntu is formally supported distro, probably the most common throughout all enterprises in the US (because Red Hat and all RPM based distos suck due to RPM has repo bugs still) while deb works great.
I'm using Ubuntu 24.04 LTS with a Radeon RX 9070 XT (currently the most recent and highest-end discrete GPU that AMD makes), and it works fine, both functionally and in terms of performance.
> I run Arch and my 9070 xt experience was poor for several months after release. I can't imagine modern gaming on an lts release.
Maybe instead of imagining it, you should just try it?