[flakes]

I think the point they’re getting at, is that there are typically a lot of delta states in between pre-upgrade and post-upgrade states when using package managers. With immutable distros, the upgrade becomes more of an atomic operation than what is offered by more incremental package manager updates.

It also means you can completely leave out the package manager from the target machines, as it’s only used to bootstrap creation of the single deployable unit. Implementing that bootstrapping step is where nix and friends are helpful in this setup.

[microtonal]

With immutable distros, the upgrade becomes more of an atomic operation than what is offered by more incremental package manager updates.

Nix offers the same guarantees. The point was that you don't need the whole system als a single unit (e.g. an image). A system can also be a tree of immutable output paths in a store (where a single output path often, but not necessarily, corresponds to a package).

In that model a system is basically an output path in the store (in reality it's a bit more complex) and has other output paths as transitive dependencies.

Upgrades/downgrades are atomic, because they just consists of selecting a different output path that represents a system. Upgrading creates a new output path that represents a system (either by downloading from a binary cache or building that output path) and booting into that output path. Rolling back consists of booting into the previous output path that represents a system.

[josephg]

This sort of atomic change should be something the filesystem provides. I think it’s crazy that databases have had mechanisms for transactions and rollbacks since the 70s and they’re still considered a weird feature on a filesystem.

There’s all sorts of ways a feature like that could provide value. Adding atomicity to system package managers would be a large, obvious win.

[pxc]

NixOS has this. Atomicity is implemented via the filesystem: the final switch between states is changing where a single symlink points from once place to another, which is an atomic operation on Linux and maybe elsewhere.

Transactional filesystems still sound cool, but Unix filesystems already have enough features to implement atomic package installation on top of them.

[josephg]

> Unix filesystems already have enough features to implement atomic package installation on top of them.

Yes, but it’s pretty awkward. You need to do the final commit via a rename or symlink. It would be far more convenient if you didn’t need to do that.

[IshKebab]

I agree. The fact that we're still doing atomic writes by renaming files is laughable. That's also pretty much the only atomic thing you can do.

I think the issue is the posix filesystem API. Nobody writes better filesystems because no software would use the new features, and no software supports fancier filesystem features because the posix API doesn't expose them.

It'll probably take someone like Apple or Google to fix this. Similar to 16kB pages.

[jodrellblank]

> Nobody writes better filesystems

People tried: https://en.wikipedia.org/wiki/Transactional_NTFS and https://learn.microsoft.com/en-gb/windows/win32/fileio/depre...

"[Transactional NTFS (TxF)] was introduced with Windows Vista as a means to introduce atomic file transactions to Windows. It allows for Windows developers to have transactional atomicity for file operations in transactions with a single file, in transactions involving multiple files, and in transactions spanning multiple sources – such as the Registry (through TxR), and databases (such as SQL). While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows"

[mkl]

And even more ambitiously, WinFS: https://en.wikipedia.org/wiki/WinFS

[marcosdumay]

Not really.

It was tried by one specific team, in one politics-guided environment. It was bounded to a ton of unrelated features because of politics, it was bounded to a specific API because of politics, it was bounded to a timeline and a team because of politics, and it was about a completely different OS.

We have no idea even how it went, because we can't trust the people reporting about it are talking about the correct thing.

[jodrellblank]

"Nobody has written a hashing/bit-rot detecting filesystem"

"ZFS is one"

"It's not really because it was written by a team, and because it was made for Solaris which is a different operating system, and there was lots of politics involved with its licensing, and because it was bound to the POSIX file API, and because it does complex volume management as well, and because it happened within a timeline before Sun went out of business, and we even have no idea how ZFS went because every documentation and article which says it's about ZFS might be talking about something else".

uh huh.

[marcosdumay]

If you used it as an example of why it always fails. And it failed because Sun was dysfunctional, then yeah, you could have a usable metaphor.

[lmm]

Iteration is a lot easier in userspace than in the base system.

[tkz1312]

nixos updates are completely atomic.