4 ms·

Honestly that’s incredible. Is there anything close to it in the Linux world? Or I guess, I’m not an expert, that’s what NixOS is trying to solve? >Just becaus

Honestly that’s incredible. Is there anything close to it in the Linux world? Or I guess, I’m not an expert, that’s what NixOS is trying to solve? >Just because they never got wide adoption doesn’t mean they were wrong This is actually something that I was thinking about recently, applies to a lot of topics not just OSes

iveqy 4y ago
See my comment about apkovl
guipsp 4y ago
> Is there anything close to it in the Linux world? Check out (as you mentioned) NixOS or Fedora Silverblue
- tmtvl 4y ago
  And Guix and OpenSUSE MicroOS. There may be others, but those are the ones that immediately come to mind.
- seized 4y ago
  Also Fedora Kinoite, the KDE flavor of Silverblue.
alxmng 4y ago
You’re right. That’s what NixOS is, a Linux distro where all software is managed by Nix, so the users environment is fully compartmentalized, declarative, and reproducible.
- MuffinFlavored 4y ago
  > so the users environment is fully compartmentalized, declarative, and reproducible. I have a question about this, please forgive my ignorance. I see this statement repeated a lot about NixOS and I've kind of had some "success" in the comments section being "critical" / "asking hard questions" about NixOS. If I have a build script that pulls + compiles + validates with hashes/checksums say, Linux kernel, some userspace tools, init system, etc. for a boring ol' distribution like Alpine or Debian, why isn't that classified as "reproducible" the same way NixOS is?
  - edgyquant 4y ago
    It would be, the problem is that you can not write such a script at the moment. As far as I know those checksums are almost always for the source code/file itself and not the compiled binary.
    - yjftsjthsd-h 4y ago
      The situation has improved, actually - you'd still have to do custom scripting to check the output checksums AFAIK but ex. https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht... tracks Debian's attempts to make it possible to reproduce packages perfectly. It's just that nixos made it pervasive and normal through the whole system.
      - mikepurvis 4y ago
        I think the main thing to understand is that Debian is reproducible as a consequence of significant unenforced contracts around what the pristine build environment will be, what the state of the package repo will be when dependencies are fetched and installed, and so on (see: https://www.debian.org/doc/debian-policy/ch-source.html#reproducibility https://www.debian.org/doc/debian-policy/ch-source.html#repr...). Your local dpkg-buildpackage invocation has pretty much a 0% chance of being a bit-for-bit reproduction of what you pulled from the archive unless you cooperate with all this ceremony. Nix, on the other hand, is reproducible by default. If you `nix build <nixpkgs/gitsha#pkgname>` you are automatically getting a local build that takes place in the same hermetic sandbox as the build you pulled from cache.nixos.org, and will be identical or very close to it. (Contrary to popular belief, not all of nixpkgs is reproducible— many packages require patching for various sources of nondeterminism, and this is an ongoing effort: https://github.com/NixOS/nixpkgs/labels/6.topic%3A%20reproducible%20builds https://github.com/NixOS/nixpkgs/labels/6.topic%3A%20reprodu...)
  - odo1242 4y ago
    many compilers aren't guaranteed to be fully deterministic tho (e.g. __DATE__ macro)
Gordonjcp 4y ago
It's kind of what snap is trying to be, but it's not there yet.
pxc 4y ago
> Honestly that’s incredible. Is there anything close to it in the Linux world? Yeah, this is similar in spirit to what Flatpak and Snap do. The latter even uses SquashFS images it mounts for every package. I have a feeling, though, that this is more similar to Distri¹, where the package manager is a bit more traditional. That is to say, packages are fine-grained (not packaging large runtimes into single chunks, like Flatpak and Snap) and there's not as much special tooling as Flatpak has for redirecting inputs and outputs, sandboxing, etc. Distri also eliminates all hooks and triggers from packages, leading to super fast installs, which is pretty cool. > Or I guess, I’m not an expert, that’s what NixOS is trying to solve? From the article, three key features highlighted are: > - Immutable system directories > - Rollback to previous states > - User-managed packages separated from system packages And, going by those criteria: yes. NixOS and GuixSD are two Linux-based operating systems which meet all three criteria today. One key difference is that Nix and Guix don't require namespacing at the filesystem, since they install everything to those wacky store prefixes with the leading hashes. Put another way: /boot/system on Haiku is a mountpoint, but /run/booted-system on NixOS is just a symlink, even though both serve the same function². But spiritually I'd say the basic idea (avoid dependency hell through lightweight package isolation) is similar and so are the results, at least in terms of capabilities. PS: If you're interested in another example, RedoxOS' package manager also has a very similar design to Haiku's and Distri's, IIRC. — 1: https://distr1.org/ https://distr1.org/ 2: Because NixOS allows you to switch to a new system without booting it (i.e., it lets you upgrade without rebooting), it actually has two symlinks here: booted-system and current-system. The current-system symlink rotates as soon as you switch configurations, but booted-system gets set only on a new boot.
outworlder 4y ago
Yeah, although Haiku seems to solve this problem more elegantly than Nix(the package manager) does(aka without a billion links). It is still great and I use it across many machines, including on OSX. Another thing BeOS did well (and it's still ahead) was the filesystem. The mail program was implemented directly in the filesystem: https://arstechnica.com/information-technology/2018/07/the-beos-filesystem/ https://arstechnica.com/information-technology/2018/07/the-b... At one point in history, there was a chance that BeOS would be adopted as the Mac OS. I wonder how that fork in the road would look like.
- pxc 4y ago
  > Haiku seems to solve this problem more elegantly than Nix(the package manager) does(aka without a billion links). It is still great and I use it across many machines, including on OSX. If Nix's solution were more elegant in this sense, you wouldn't be able to use it on macOS because macOS lacks the required sandboxing features.

iveqy 4y ago

See my comment about apkovl

guipsp 4y ago

> Is there anything close to it in the Linux world? Check out (as you mentioned) NixOS or Fedora Silverblue

tmtvl 4y ago
And Guix and OpenSUSE MicroOS. There may be others, but those are the ones that immediately come to mind.
seized 4y ago
Also Fedora Kinoite, the KDE flavor of Silverblue.

alxmng 4y ago

You’re right. That’s what NixOS is, a Linux distro where all software is managed by Nix, so the users environment is fully compartmentalized, declarative, and reproducible.

MuffinFlavored 4y ago
> so the users environment is fully compartmentalized, declarative, and reproducible. I have a question about this, please forgive my ignorance. I see this statement repeated a lot about NixOS and I've kind of had some "success" in the comments section being "critical" / "asking hard questions" about NixOS. If I have a build script that pulls + compiles + validates with hashes/checksums say, Linux kernel, some userspace tools, init system, etc. for a boring ol' distribution like Alpine or Debian, why isn't that classified as "reproducible" the same way NixOS is?
- edgyquant 4y ago
  It would be, the problem is that you can not write such a script at the moment. As far as I know those checksums are almost always for the source code/file itself and not the compiled binary.
  - yjftsjthsd-h 4y ago
    The situation has improved, actually - you'd still have to do custom scripting to check the output checksums AFAIK but ex. https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht... tracks Debian's attempts to make it possible to reproduce packages perfectly. It's just that nixos made it pervasive and normal through the whole system.
    - mikepurvis 4y ago
      I think the main thing to understand is that Debian is reproducible as a consequence of significant unenforced contracts around what the pristine build environment will be, what the state of the package repo will be when dependencies are fetched and installed, and so on (see: https://www.debian.org/doc/debian-policy/ch-source.html#reproducibility https://www.debian.org/doc/debian-policy/ch-source.html#repr...). Your local dpkg-buildpackage invocation has pretty much a 0% chance of being a bit-for-bit reproduction of what you pulled from the archive unless you cooperate with all this ceremony. Nix, on the other hand, is reproducible by default. If you `nix build <nixpkgs/gitsha#pkgname>` you are automatically getting a local build that takes place in the same hermetic sandbox as the build you pulled from cache.nixos.org, and will be identical or very close to it. (Contrary to popular belief, not all of nixpkgs is reproducible— many packages require patching for various sources of nondeterminism, and this is an ongoing effort: https://github.com/NixOS/nixpkgs/labels/6.topic%3A%20reproducible%20builds https://github.com/NixOS/nixpkgs/labels/6.topic%3A%20reprodu...)
- odo1242 4y ago
  many compilers aren't guaranteed to be fully deterministic tho (e.g. __DATE__ macro)

Gordonjcp 4y ago

It's kind of what snap is trying to be, but it's not there yet.

pxc 4y ago

> Honestly that’s incredible. Is there anything close to it in the Linux world? Yeah, this is similar in spirit to what Flatpak and Snap do. The latter even uses SquashFS images it mounts for every package. I have a feeling, though, that this is more similar to Distri¹, where the package manager is a bit more traditional. That is to say, packages are fine-grained (not packaging large runtimes into single chunks, like Flatpak and Snap) and there's not as much special tooling as Flatpak has for redirecting inputs and outputs, sandboxing, etc. Distri also eliminates all hooks and triggers from packages, leading to super fast installs, which is pretty cool. > Or I guess, I’m not an expert, that’s what NixOS is trying to solve? From the article, three key features highlighted are: > - Immutable system directories > - Rollback to previous states > - User-managed packages separated from system packages And, going by those criteria: yes. NixOS and GuixSD are two Linux-based operating systems which meet all three criteria today. One key difference is that Nix and Guix don't require namespacing at the filesystem, since they install everything to those wacky store prefixes with the leading hashes. Put another way: /boot/system on Haiku is a mountpoint, but /run/booted-system on NixOS is just a symlink, even though both serve the same function². But spiritually I'd say the basic idea (avoid dependency hell through lightweight package isolation) is similar and so are the results, at least in terms of capabilities. PS: If you're interested in another example, RedoxOS' package manager also has a very similar design to Haiku's and Distri's, IIRC. — 1: https://distr1.org/ https://distr1.org/ 2: Because NixOS allows you to switch to a new system without booting it (i.e., it lets you upgrade without rebooting), it actually has two symlinks here: booted-system and current-system. The current-system symlink rotates as soon as you switch configurations, but booted-system gets set only on a new boot.

outworlder 4y ago

Yeah, although Haiku seems to solve this problem more elegantly than Nix(the package manager) does(aka without a billion links). It is still great and I use it across many machines, including on OSX. Another thing BeOS did well (and it's still ahead) was the filesystem. The mail program was implemented directly in the filesystem: https://arstechnica.com/information-technology/2018/07/the-beos-filesystem/ https://arstechnica.com/information-technology/2018/07/the-b... At one point in history, there was a chance that BeOS would be adopted as the Mac OS. I wonder how that fork in the road would look like.

pxc 4y ago
> Haiku seems to solve this problem more elegantly than Nix(the package manager) does(aka without a billion links). It is still great and I use it across many machines, including on OSX. If Nix's solution were more elegant in this sense, you wouldn't be able to use it on macOS because macOS lacks the required sandboxing features.