I've had a similar experience with systemd itself. While you could go and read through the systemd docs to understand all of its nooks and crannies, you can actually learn the important bits by reading through the source for NixOS's modules (which are linked directly from https://search.nixos.org/options). You start to see patterns of which options they set in the units, and pretty quickly build up the knowledge you need to write your own. This is also aided by the fact that the repository is one giant git repo hosted on GitHub that you can search, clone, tweak, atomically deploy from a local branch. It buys you so much flexibility when experimenting.

This is something that is coming to traditional Linux as well though, with zfs snapshots. I've had it for a long time on FreeBSD. I just snapshot before I do something big.

I see the benefit of declarative configuration as an admin at work where we need to set up many systems the same way. For home desktop use I don't really see the point, I don't think it's a tech that fits perfectly in every scenario. Like most technologies there's usecases where its benefits shine and the drawbacks are irrelevant, and others where it's the opposite.

For example I often come across software that isn't packaged for my OS and I like to just compile them and try them out without having to do the whole packaging routine.

As to "home use", personally I'm successfully keeping my dotfiles & $HOME/bin/ scripts managed with Nix + home-manager. Becomes useful when changing jobs, and also makes it easier to share new config tricks between work & home machine. Regardless if Linux or Mac.

edit: in particular, going just Nix (not NixOS) on work machine(s) allows me to fall back to apt-get/brew quickly when a particular tool is not (yet) on Nixpkgs.

> For home desktop use I don't really see the point

Lucky that you don't need to run NixOS as your OS to get a lot of the advantages from it then. I use debian for my boring desktop applications but have Nix available to me for when I need any e.g. development tools.

This is what I used to think, but after twenty years of running Linux, and at least twice that many reinstalls, I very much appreciate an OS that doesn't eventually bitrot underneath me.

"Just install this one package to get CUDA working"... no. If I do that, then in two months when I want to do something else I'll find my OS is no longer capable of being used that way. And in four, when I want this specific version of CUDA working again, I don't remember how. The instructions probably wouldn't work anymore anyway.

NixOS allows me to put in down in terms of code, and the code practically never stops working. It's also immortal -- I've never needed to reinstall it. If I did, it'd be painless, but that's only ever happened in case of hardware failure.

It's the best part of Nix.

> This is something that is coming to traditional Linux as well though, with zfs snapshots.

Has there been a change in ZFS licensing? I thought it was always going to remain poorly integrated into the Linux ecosystem.

> I thought it was always going to remain poorly integrated into the Linux ecosystem.

Interestingly, NixOS excels at ZFS integration.

Because NixOS builds everything from source with transparent binary caching, always upgrades your system as an integral while, and performs upgrades atomically, you'll probably not even notice that ZFS isn't in the mainline kernel as you use it. NixOS will never upgrade your kernel to one that's incompatible with whatever version of ZFS is in the repos, and it'll never leave you in a partially upgraded state where your new kernel is installed, but your new ZFS modules are not— even if you pull the power during an upgrade.

ZFS feels very native on NixOS. It's great

To my knowledge, the integration with the kernel is still not very good. As someone else mentioned in a reply, there are large swathes of the Solaris kernel with duplicate functionality included in the Linux kernel solely to support ZFS, because native integration is too difficult in face of the licensing and maintenance issues.

It remains a kludge rather than something that can really be thought of as an integrated Linux solution. Even if it works okay in some situations.

Is the Solaris Porting Layer really due to a licensing issue or just a ZFS portability issue? FreeBSD's ZFS implementation reportedly has a similar portability shim.¹ The new OpenZFS implementations for Windows and macOS each have their own Solaris Porting Layer, too.

If what you want is just snapshotting and you want something that's in the mainline kernel, I guess there's BTRFS. Bcachefs seems to be coming along nicely, but who knows when it'll really be ready.

——

1: https://papers.freebsd.org/2019/BSDCan/jude-The_Future_of_Op...

I can ignore the licensing for my personal stuff (and some work might be able to, too) but from a technical perspective I find the SPL translation layer and fs caching overhead much greater pill to swallow. It’s basically bolting on Solaris as a 2nd memory system just for zfs. I really hope this hack is recognized for what it is sooner rather then later…

No. It's poorly integrated but well maintained in the Linux ecosystem. Certainly usable.

With the exception of NixOS, with which it's well integrated. The integration is a bit of an oddball, though.

Kinda typical... nice to have though!

You can do the same with btrfs too. I think SuSE already integrates this, and I used to do that with Arch Linux before I started using NixOS.

SUSE uses btrfs as the default fs for years. A snapshot is taken before each upgrade automatically.

> This is something that is coming to traditional Linux as well though, with zfs snapshots. I've had it for a long time on FreeBSD. I just snapshot before I do something big.

This has been available on traditional Linux for quite some time with btrfs snapshots.