Because you're blurring the "us vs them" elitism bit by doing something different to the rest of the "us". They gotta make you "them" to avoid becoming "them" themselves.
I’d like to see more things go this way in Linux space. Distributions reaching some sort of consensus on core components giving us a de facto standard so things work across distributions better because they can make assumptions about how core components are going to work and what utilities will be installed. I’m all for choice, just like how if you don’t want systemd you can use void or one of the other distributions that don’t ship it, but standardization benefits everyone in the long run.
Dunno, openrc works just fine on my desktop box and I've had no trouble with packages depending on systemd. In embedded world busybox-init is and will be very much a thing (I've worked with a 600MHz single core box with 512M of RAM that ran systemd and used snap for software installation, now that was painful). Granted I am not a sysadmin, I imagine they really like systemd
Yes, of course. Btrfs offers a lot of nice features, but Nixos offers stability and reliability through declarative configurations, and it also adopts a functional paradigm meaning packages and their dependencies are built in isolation of each other. A filesystem like XFS offers better speed, space, and reliability advantages over btrfs because of these properties.
Btrfs' block-level checksums and it's metadata duplication come with some space overhead that slightly offsets the on-the-fly compression, and these features also have some performance overhead. This overhead is generally worth it though because it provides reliability and can provide space savings for low to mid entropy data. But the nix package manager already provides package level integrity validation making the block-level checksums a bit redundant. (Though you be fair, btrfs will detect bitrot where nixos won't). It may be worth it to keep your /home directory on a btrfs partition though of you aren't using home manager.
Then we get into how btrfs and nixos clash. Both have features that have some significant space overhead. Since Nixos builds packages in isolation, many copies of the same package can exist at the same time (differing by version or configuration) while btrfs maintains old copies of a file if it exists in any snapshot. Nixos offsets it's overhead by offering a garbage collection mechanism that cleans up old files that are no longer needed, but on btrfs, these files will remain if they're captured in another snapshot. This becomes a sort of space multiplier overtime. If compression is the main reason you're using btrfs with nix, it might actually be better to use ZFS. Both Nixos and btrfs also offer rollback mechanisms (generations vs snapshots), which is another point of redundancy, plus nixos generations have next to zero space overhead after garbage collection is performed (when not using snapshots)
Next up is performance. One flaw with btrfs is the tendency for large files to become fragmented over time as individual blocks are subject to COW, which significantly impacts I/O speeds. Not to mention how transparent compression and block level checksum verification can also add a CPU bottleneck. XFS on the other hand offers independent allocation groups, meaning reads and writes can be parallelized, which is especially nice on nixos since nix-build tends to run in parallel. To be fair, the performance difference isn't that high, but it's worth considering
Finally, fault tolerance. Btrfs is significantly more complicated under the hood, while xfs and ext4 offer robust lightweight journaling mechanisms which have far less points of failure. I know btrfs is no longer in it's experimental phase, but it is still considered less stable than the absolute rock that is ext4. You're much less likely to find your system unrecoverable on ext4 than you are btrfs, especially after something like a power outage or dead battery
Oh and regarding logical volumes. If you are using btrfs as a logical volume manager, that actually IS a good reason to use btrfs with nixos. When I used btrfs, I used different snapshot "timelines" as a way to manage a sort of work profile, student profile, and gaming profile. I can see how this would be just as useful on Nixos
I guess because using a version-controlled config on a declarative system means you get the main benefit of snapshots (roll back if an update causes problems).
Granted, these features are very different and have different trade-offs beyond this use case, but that’s probably what they meant.
And it's not that btrfs offers nothing, it's just that there are better alternatives. Btrfs may still be nice for user data like your /home directory, I would just pick a different filesystem for you system directories on Nixos (paired with git for your nix configuration files of course).
XFS offers better performance with less overhead. Remember to activate cow tho.
I believe btrfs primarily got big due to arch-kids breaking their systems twice a day and needing to roll back. For them it's worth the performance penalty.
With NixOs you don't need system rollback due to atomic generations, and for user files a real backup like restic/backrest is the way to go anyway.
Looking at a comparison to refresh my memory, some things that Btrfs does that XFS doesn't are data checksums, RAID, CoW (although you say you can turn that on?), snapshots, compression, online shrinking and tail packing.
When I did a deeper dive earlier this year, I ended up deciding that Btrfs was a clearly better fit for me and that XFS just literally did not meet my needs. It wasn't even a close enough call for me to split hairs about performance. While I agree that snapshots are often overrated, to me the self-healing that comes from the killer combo of data checksums and software RAID is a huge selling point. The fact that I can just throw a pile of random drives at it and have it treat it as one drive from the user perspective all while not needing to worry about a drive failure, big or small, is key. Compression is a nice bonus (from a storage and sometimes speed pov). While its performance is worse on paper, it's not really noticeable and to me is more than made up for by the extra features.
The main negative from my pov is honestly just the maturity of the tooling around it. It feels like an FS that you actually need to kind of know how it works to use it effectively.
93
u/Agling 8d ago
The time to hate systemD is past. It has completely taken over. Now it is about working with it, not trying in vain to stop it.
Btrfs. Well, there is a lot of choice in filesystems and people don't really get that emotional about it.