Let me put it like this: it’s about learning curve. Arch is relatively easy to begin with, but NixOS gets much easier the more nix you learn.
What do I mean about that? Imagine having to patch something, which can be the thing. On arch you’d have to replace a package, which could lead to issues and conflicts, whereas NixOS gives you the option to keep two or even more versions of the same library, because it does not rely on your traditional UNIX path.
But with this super power comes a catch. You have to learn a programming language and learn how the nix store operates, which is a pretty high learning curve. Also, NixOS suffers from a governance issue and going by the documentation is like shooting in the dark.
That being said, the best manual for NixOS is GitHub, searching for anything and filtering by the nix language. You’ll see a ton of varying systems, be they workstations or servers.
And no matter what all the warnings say, no, flakes aren’t EXPERIMENTAL or UNSTABLE, but rather CONTENTIOUS internally. Again: I love NixOS, but they gotta fix their governance issues.
I haven’t used it yet personally, but I would bet as soon as Debian/Ubuntu LTS/CentOS/openSuse/other stable Linux distros get kernels new enough to it will be not just a btrfs killer, but a ZFS killer too.
The tiered write and read layers and SMR support put ZFS caching to shame.
Nobody uses SMR for live data anyway unless it’s in very particular circumstances.
Bcachefs is still at least a couple of years away from serious use. But sure, if it’s available and you have a good backup strategy you can use it today.
As for “years away” I agree. As my first post said people should wait till you can use bcachefs in the stable distros. Debian isn’t getting kernel 6.7 any time soon 😆. So years away is right in any case.
I think bcachefs addresses the reason why people don’t use SMR HDDs. (Aka changes resulting in cascading writes)
You could have a data pool with the following tiers.
Tier 1: SSDs
Tier 2: HDDs
Tier 3: SMR HDDs
With bcachefs you would only ever write to your tier 1 storage. In the background, as able, bcachefs would offload the data from the faster lower tiers to the slower higher tiers based on frequency of data access.
You would only ever read from the SMR HDDs and would never write to them. They act as a sort of async backing to your data.
Personally I would love a data pool with a few SSDs, backed by a few HDDs, backed by many SMR HDDs. You would save so much money just with good architecting.
Bcachefs should be a ZFS killer. All the features of ZFS with storage tiers being a superior version of ZFS’s L2arc with none of the DKIM kernel license incompatibility nonsense.
Damn, I didn’t think to include SMR drives when it comes to bcachefs. Your whole comment made me appreciate the whole concept under a whole new light actually, thanks!
My only issue is software availability and management. I use the Packman repository to manage codecs and I avoid using the change vendor option; i used to change the vendor every time and ended up with a broken system, so I reinstalled and also resized my partition because I dual boot. I haven’t had problems at all.
You only need to pay attention for your needs, I recently installed systemd networking packages because they don’t come preinstalled, and YaST is very helpful in some situations like installing patterns (multiple related packages at once), mostly desktop environments. I gotta say that the openSUSE Wiki may not be enough to understand, but there is an official forum and you can also look at the Arch wiki.
Btw, GNOME is the official DE used by the developers, but KDE Plasma works very well, and all of them update constantly, you’ll have available updates every week.
seems like a bug in one of rhe programs you’re using.
modt software automatically manages it’s cache…
are you using build caching tools such as Mozilla sccache? These tend to create 20gb+ cache directories, especially if used with debug builds
I just map both the user cache and the /tmp directory to a RAM drive. I allocated 4 GB but in practice it never gets even close to that much, and Linux seems to not be reserving the entire 4 GB at boot so I would assume how much RAM is used depends on how much is actually in your cache.
It also defers cache and tempfile related problems to turning it off and on again.
No issues to report here. Audio sucked when I had an old shitty laptop with a BT4.0 chip but after I upgraded to a Thinkpad X280 Bluetooth just worked out of the box. Been using pipewire but before that I used pulseaudio with bluetooth audio extensions that you can find on the AUR. Pulseaudio was far less stable, pipewire just werks.
You can setup your Arch with grub menu btrfs snapshots just like NixOS for convenient rollbacks. NixOS has too steep a learning curve, coming from someone who recently tried it and ended up being somewhat disappointed by it. NixOS sounds good on paper but in reality it is a long way from a mature product for desktop or general use.
As you mentioned Arch has AUR which packages just about anything and everything you could ever want in the future. And the Arch Wiki will never be “not relevant” so long as you are using Linux anywhere, the Arch Wiki is a handy reference.
For everyday tasks, I think a Fedora distrobox works fine, but you would have to upgrade it eventually and I admit I’m not sure how you do that under distrobox. Still, I initially used it and still have a Fedora distrobox I use for doing stuff for my job, as well as one I use for running a game modding program that requires Java, and they both work fine.
I’ve also had success with a Debian distrobox, which I used to compile Render96ex. Debian is pretty universal, so it’s much easier to follow compile instructions using it than a Fedora distrobox ^^’
Python is easy on NixOS, you just need to use python venvs and you can use pip like normal
(python -m venv .venv) to create the venv (only need to do once per project)
.venv/bin/activate to enable the venv (Vscode should do this automatically if you create the venv through the python extension)
Then just pip install to your heart’s content
(Probably a good idea to pip freeze > requirements.txt every time you install a new library too to make it reproducible
Also you should probably add the venv directory to gitignore if you’re using git as it’ll add a lot of crap to source control that can be easily regenerated from the requirements.txt
I used to like the idea of nixos because it felt “tidy” to configure everything centrally. However that tidyness is achieved by adding an extra layer which just replicates the configuration options of every program. If there is a bug in that layer or something is just not implemented, either you have to learn the whole inernals of nixos and nixpkgs, for which there is no real documentation, or you have to resort to doing things imperatively again, which is hard because of the opacity of the generated system and also defeats the whole purpose. So basically, you are completely dependent on nixos developers for things you could have easily done yourself on arch.
I have to disagree with this, with home-manager you can pretty much put just put your normal config files inside your NixOS config and map them into wherever they’re meant to go, except now they’re managed by nix
The built in config options are really nice but you don’t have to use them in the slightest as long as the package itsself is in nixpkgs
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.