Hacker News Reader

Comment by jordanbeiber | Hacker News Reader

A couple of things - if the system can handle rollbacks it will be much more reliable than using the fs, as the fs knows nothing about actual state. It knows about blocks commited to disk. Usually they look the same, but not always.

Then there’s the question of how exactly you reached this state. Having nixos generations is like having an event stream of all changes. Apply your backup to a new machine, what happens? Who knows.

In nixos/guix it’s not about only ”package tools”, it’s about treating the complete system and its state as a coherent whole.

Once I got the taste of it I see no way back to opaque packages, managed by config tools with no concept of state.

And if you’re a dev - shell.nix and declarative containers ftw.

View on HN

> if the system can handle rollbacks it will be much more reliable than using the fs, as the fs knows nothing about actual state. It knows about blocks commited to disk. Usually they look the same, but not always.

Could you elaborate on this? If I have state that works on v1 and after upgrade to v2 the state is now non backward compatible to v1, how nix (or guix) can help? As far as I can tell, in such case a fs rollback is better solution.

Depends on how the state is stored. If it's in configuration, Nix generated it and it lives immutable in the Nix store, so Nix will just point out it to the old version on rollback.

If it's something like the content of a SQL database, which lives outside the Nix store and which Nix did not generate, you need some other tool (like a filesystem snapshot, maybe) to perform the rollback. I think CoW filesystems sometimes have performance issues with DBs, though, so I'm not sure that's always the approach you'd take.

The Nix ecosystem does have a fairly mature tool for managing stateful components that live outside the Nix store, though: https://github.com/svanderburg/dysnomia

It's been around for a long time. Idk who all is using it

What state do you mean? Let’s say you have a backup of your system partition but your home folder is separate. In that case a rollback with the filesystem is the same as one through nix — the latter will place symlinks to all the previous versions and the finished result is identical.

Of course if you have in the meanwhile used the new system and your home folder contains some backwards incompatible changes, both solutions will fail. Rolling back your home folder may not be a good thing as you may have backwards compatible changes you prefer.

Also, nix can also manage installed application’s configs, so those could also be rolled back, on either a per-app basis or however you prefer.

Sure you could, like Solaris did IIRC, zfs snapshot before updates was applied.

What I mean is that a fs snapshot is ”dumb” in and of it self.

If you couple zfs with the nixos rebuild command, then… sure, I guess - but the previous generations are already more or less directly available, unless GC’d.

This is what the fine manual has to say:

Since Nix is good at being Nix, most users will want their server's data backed up, and don't mind reinstalling NixOS and then restoring data.

How does Nix work with less sophisticated package managers that run on top of it, e.g. Python's "pip"?

If you just use pip & co, nix will be unaware of it and won't care one way or another. It will basically treat your pip-installed stuff like it'd treat your sourcefiles or pdfs.

Alternatively you can create derivations instead in which case the resulting artefacts will be fully understood and manageable by nix (I think there are integrations to do that e.g. tools like carnix which can automatically create derivations from existing language-specific packages, not sure if there's one for pip/pypi).

> If you just use pip & co, nix will be unaware of it and won't care one way or another. It will basically treat your pip-installed stuff like it'd treat your sourcefiles or pdfs.

Also if you run pip as root (to install for all users at once)?

It fails, because NixOS mounts /nix/store (the Nix store, where all managed packages are stored) as read-only (with some trickery used by Nix itself to bypass this for its own builds).

And if you bypass that, `nix-store --verify --check-contents` can detect the issue.

This is very reassuring, thanks.

Guix, and I think Nix also, package the things from these other package managers so you can manage them all with the same package manager. This also means features like rollbacks can apply to your emacs packages.

You can run pip on Guix System, but I don't think you'd have to, ideally. Same for rust's cargo and so on.

Ok, makes sense. Does that mean that you don't get the latest updates that are available in pip?

Also, what happens if you incidentally run pip on a Nix system? Will it mess up your installation?

You can update packages to newer commits ahead of guix itself updating the package with a simple command[0] as long as dependencies and such haven't changed. So, if guix were behind, you should be able to easily remedy it.

[0] guix install mpv --with-commit=mpv=cc4ada655aae06218b900bb434e3521566394cde

I can't speak for pip, but cargo, rust's package manager, packages disappear on reboot. Doesn't matter for development since libraries are stored with your project, but any tools you install via cargo are gone

Reply on news.ycombinator.com