>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
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-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.
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.
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?
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%20reprodu...)
Other previously nondeterministic build issues have some similar opt-in workarounds. Have a look around the Reproducable Builds project website for more info/examples.
https://reproducible-builds.org/docs/source-date-epoch/
https://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.htm...
Older package managers use a "name-version" scheme to try and avoid package conflicts, but in practice there can be different binaries which have the same "name-version" identifier and they're not always compatible.
The way Nix solves the issue is to store everything in a content-addressible store `/nix/store`, where multiple concurrent versions can be installed without naming conflicts (the directories are named with the content hash). When an app is compiled, it is linked to specific shared libraries in the nix store which will always be present on the system. The `/usr` directory then, is just a collection of symlinks to the actual content in the nix store (most recent versions), for compatibility.
Because derived packages are reproducible, they will always have the same content hash on every system on which they are deployed. As a developer then, you can target very specific shared libraries when building your software, and you know that when you deploy them, users are going to have the exact same dependencies you had when you built it.
It might be! Nix uses that very same strategy for enforcing reproducible outcomes when dealing with non-reproducible operations, like fetching things from the great mutating mass of the internet.
I would say that Nix differs from that approach mainly in the way it divides up the problem. So-called binary package managers like you use on Alpine and Debian perform runtime dependency resolution against a mutating global namespace that usually lives on the internet— the binary repos themselves. Generally, those repos include only one copy of each package. So to halt the forward march of all those versions, you have to mirror each repo of binary artifacts you're interested in using.
With Nix, outcomes also depend on the state of the repo, but the repo is just a collection of build recipes which are the mapped onto their outputs in a single, huge binary cache. Every new build gets added to the same binary cache, for every Nixpkgs/NixOS release. It just grows and grows. And of course, Nix builds work even without enabling the binary cache at all.
So to get the same kind of reproducibility out of many other package managers, you generally have to set up additional infrastructure.
But if you do everything right, you can certainly have a fully reproducible OS image based on Alpine or whatever else.
1. Implicit dependencies that are needed to build the software but not managed by the package manager or build system itself. For example, if your language package manager depends on a C library that it can't build itself. Or Linux distribution package managers that implicitly assume the presence of a "base system".
2. SAT solvers for version selection. Using one of these usually introduces an implicit dependency on the clock time, because your dependencies will resolve to different versions at different times.
The reason your script wouldn't classify as reproducible is simply that you would probably fail to fully specify your dependencies. It's harder than you'd expect once you start moving up the software stack to complicated high-level applications.
Check out (as you mentioned) NixOS or Fedora Silverblue
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
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.
—
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.