4 ms·

I must admit, I'm curious about the idea but I don't yet "get" it. Reproducible builds sound like a great idea at first, but this has the same problem as Docke

I must admit, I'm curious about the idea but I don't yet "get" it. Reproducible builds sound like a great idea at first, but this has the same problem as Docker containers: you inadvertently become a package/distro maintainer. How does one update the system regularly with security updates? Are we locking by semver somehow (like node, etc.)? And who decides which version ranges to lock to, etc. etc.? Honestly, I'd probably much rather just take an existing Debian/Redhat/etc. LTS distro and do a custom install script, which isn't that hard in the first place. And, in case of cloud server environments, you can just take a snapshot of your VM with a simple click of a button. You can't get much more reproducible than an actual snapshot of your entire system.

kaba0 5y ago
Usually you have a declarative package/system config file that is seldom changes and you point it to a nixpkgs repository, which has definitions for other packages. So an update is as easy as changing that repo to a newer/modified branch. Of course you can even depend on multiple such repos, or override them in any way so you can use a specific lib with an older shared library while use everything else with the latest. As for versioning, it is hash-based. Packages specify a source (eg github repo and a specific commit) and the hash of the downloaded source files, and build instructions inside the nixpkgs repo. The resulting program will depend on each listed property. And since they are referenced by hash, a program can use any possible version of another program. Hope it answers your questions!
Mic92 5y ago
Within a release there are no version bumps, only if you live on unstable or switch to a new release you would get them. The problem of an actual snapshot of your entire system is that you don't really now what should be in there and it collects a lot of cruft/state. With NixOS you can write little modules for services and move those between VM/Machines, whatever floats your boat. IMHO this type of config management sucks less than ansible/chef etc because you are not fighting against the package manager. The configuration holds the ground truth on what is installed on the system.
takeda 5y ago
It's like an OS that has builtin salt/ansible/chef/puppet. Because Nix language describe the OS instead of what to change/configure it's superior to these tools, and solves the problem that supposedly same machines are drifting apart. For example if in the CM you tell it to install a package, then change your mind and remove the entry that does it. The package will remain installed. With NixOS if you remove the package from configuration, it's gone. I personally really like Nix's building capability. For example I can use it to generate a minimal docker container. It requires some knowledge, but I can also modify compilation options in dependencies (like remove unneeded functionality). It looks like there's also an option to similarly build lightweight OS images[1]. I haven't tried it yet but looks cool. [1] https://github.com/cleverca22/not-os https://github.com/cleverca22/not-os
squiggleblaz 5y ago
> but this has the same problem as Docker containers: you inadvertently become a package/distro maintainer. How does one update the system regularly with security updates? Are we locking by semver somehow (like node, etc.)? And who decides which version ranges to lock to, etc. etc.? That is not true in the case of NixOS. NixOS is an ordinary distribution: it has a release (which seems to be maintained for a year, receiving security patches) and an unstable branch. So if you want to maintain your whole system in Nix, my recommendation is something like: (1) use nix flakes. Flakes basically means you expressly specify the versions of your inputs, following the well known pattern of a human-edited but loosely specify source specification and a lockfile. (2) One of your inputs will be github:NixOS/nixpkgs/release-21.05, which means the release-21.05 branch of github.com/NixOS/nixpkgs. The lockfile will ensure this follows the latest version (3) In your flake, include your system configuration: it should build the whole system (systemd jobs, your reverse proxy, whatever it is you want each machine/class of machines in your network to do), not merely your application. (4) In your flake, include your system tests. They can run on a virtual machine (or a network of virtual machines) whose configurations are derived from the configurations you created in (3). If you've done that, you can now be reasonable confident that you can automatically receive security updates, run your tests against them, and deploy them.
- danieldk 5y ago
  (which seems to be maintained for a year, receiving security patches) Releases are maintained until one month after the next release. So, 21.05 will be maintained until a month after 21.11 is released.

kaba0 5y ago

Usually you have a declarative package/system config file that is seldom changes and you point it to a nixpkgs repository, which has definitions for other packages. So an update is as easy as changing that repo to a newer/modified branch. Of course you can even depend on multiple such repos, or override them in any way so you can use a specific lib with an older shared library while use everything else with the latest. As for versioning, it is hash-based. Packages specify a source (eg github repo and a specific commit) and the hash of the downloaded source files, and build instructions inside the nixpkgs repo. The resulting program will depend on each listed property. And since they are referenced by hash, a program can use any possible version of another program. Hope it answers your questions!

Mic92 5y ago

Within a release there are no version bumps, only if you live on unstable or switch to a new release you would get them. The problem of an actual snapshot of your entire system is that you don't really now what should be in there and it collects a lot of cruft/state. With NixOS you can write little modules for services and move those between VM/Machines, whatever floats your boat. IMHO this type of config management sucks less than ansible/chef etc because you are not fighting against the package manager. The configuration holds the ground truth on what is installed on the system.

takeda 5y ago

It's like an OS that has builtin salt/ansible/chef/puppet. Because Nix language describe the OS instead of what to change/configure it's superior to these tools, and solves the problem that supposedly same machines are drifting apart. For example if in the CM you tell it to install a package, then change your mind and remove the entry that does it. The package will remain installed. With NixOS if you remove the package from configuration, it's gone. I personally really like Nix's building capability. For example I can use it to generate a minimal docker container. It requires some knowledge, but I can also modify compilation options in dependencies (like remove unneeded functionality). It looks like there's also an option to similarly build lightweight OS images[1]. I haven't tried it yet but looks cool. [1] https://github.com/cleverca22/not-os https://github.com/cleverca22/not-os

squiggleblaz 5y ago

> but this has the same problem as Docker containers: you inadvertently become a package/distro maintainer. How does one update the system regularly with security updates? Are we locking by semver somehow (like node, etc.)? And who decides which version ranges to lock to, etc. etc.? That is not true in the case of NixOS. NixOS is an ordinary distribution: it has a release (which seems to be maintained for a year, receiving security patches) and an unstable branch. So if you want to maintain your whole system in Nix, my recommendation is something like: (1) use nix flakes. Flakes basically means you expressly specify the versions of your inputs, following the well known pattern of a human-edited but loosely specify source specification and a lockfile. (2) One of your inputs will be github:NixOS/nixpkgs/release-21.05, which means the release-21.05 branch of github.com/NixOS/nixpkgs. The lockfile will ensure this follows the latest version (3) In your flake, include your system configuration: it should build the whole system (systemd jobs, your reverse proxy, whatever it is you want each machine/class of machines in your network to do), not merely your application. (4) In your flake, include your system tests. They can run on a virtual machine (or a network of virtual machines) whose configurations are derived from the configurations you created in (3). If you've done that, you can now be reasonable confident that you can automatically receive security updates, run your tests against them, and deploy them.

danieldk 5y ago
(which seems to be maintained for a year, receiving security patches) Releases are maintained until one month after the next release. So, 21.05 will be maintained until a month after 21.11 is released.