5 ms·

Another opinion: immutability is required to guarantee software integrity, but there is no need to make whole system or "apps" immutable units. NixOS also consi

Another opinion: immutability is required to guarantee software integrity, but there is no need to make whole system or "apps" immutable units. NixOS also consists of "immutable units", but its "granularity" is similar to packages of traditional Linux distros, each unit (Nix store item) representing single program, library or config file. This provides a better tradeoff, allowing to change system relatively easily (much easier than in immutable distros described here, and in many cases as easy as in traditional Linux distros) while having advantages of immutability.

UltraSane 2y ago
Immutable distros are a good fit for very mature Infrastructure as Code setups. They make drift from the original config impossible.
- packetlost 2y ago
  IME you don't need a mature IaC setup to have it work well, especially if you've bought into containerization
- shatsky 2y ago
  >make drift from the original config impossible NixOS makes that too, its whole "system output path closure" is as immutable as every single store unit within it. But NixOS "reuses" units which are unaffected by NixOS config changes when applying new config, making its "system rebuild" super fast and light on resources when something like a single config file is changed in NixOS config. And possible to be done "in place", unlike with "conventional immutable distro"
toprerules 2y ago
You don’t understand what immutable distros are for. Imagine you need to upgrade 500k machines and your options are either run an agent that has to make the same changes 500k times and hopefully converges onto the same working state no matter the previous state of the machines its running on, or you pull a well tested image that can be immediately rolled back to the previous image if something goes wrong. Saying it’s just about integrity is like saying docker images are just about integrity… they absolutely are not. They give you atomic units of deployment, the ability to run the same thing in prod as you do in dev. Many other benifits.
- IshKebab 2y ago
  > and hopefully converges onto the same working state no matter the previous state of the machines its running on Isn't that exactly the point of NixOS?
  - flakes 2y ago
    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.
    - josephg 2y ago
      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.
      - IshKebab 2y ago
        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 2y ago
        > Nobody writes better filesystems People tried: https://en.wikipedia.org/wiki/Transactional_NTFS https://en.wikipedia.org/wiki/Transactional_NTFS and https://learn.microsoft.com/en-gb/windows/win32/fileio/deprecation-of-txf?redirectedfrom=MSDN 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"

UltraSane 2y ago

Immutable distros are a good fit for very mature Infrastructure as Code setups. They make drift from the original config impossible.

packetlost 2y ago
IME you don't need a mature IaC setup to have it work well, especially if you've bought into containerization
shatsky 2y ago
>make drift from the original config impossible NixOS makes that too, its whole "system output path closure" is as immutable as every single store unit within it. But NixOS "reuses" units which are unaffected by NixOS config changes when applying new config, making its "system rebuild" super fast and light on resources when something like a single config file is changed in NixOS config. And possible to be done "in place", unlike with "conventional immutable distro"

toprerules 2y ago

You don’t understand what immutable distros are for. Imagine you need to upgrade 500k machines and your options are either run an agent that has to make the same changes 500k times and hopefully converges onto the same working state no matter the previous state of the machines its running on, or you pull a well tested image that can be immediately rolled back to the previous image if something goes wrong. Saying it’s just about integrity is like saying docker images are just about integrity… they absolutely are not. They give you atomic units of deployment, the ability to run the same thing in prod as you do in dev. Many other benifits.

IshKebab 2y ago
> and hopefully converges onto the same working state no matter the previous state of the machines its running on Isn't that exactly the point of NixOS?
- flakes 2y ago
  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.
  - josephg 2y ago
    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.
    - IshKebab 2y ago
      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 2y ago
        > Nobody writes better filesystems People tried: https://en.wikipedia.org/wiki/Transactional_NTFS https://en.wikipedia.org/wiki/Transactional_NTFS and https://learn.microsoft.com/en-gb/windows/win32/fileio/deprecation-of-txf?redirectedfrom=MSDN 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"