Remember the days when everyone and their pet iguana was raving about Arch Linux? You couldn't escape the ever-so-subtle "I use Arch BTW" remarks in every Linux forum. Well, move over, Arch, because NixOS is here to steal your thunder! Nowadays, it seems that you can't browse YouTube or read a blog without stumbling upon someone extolling the virtues of NixOS and how it is the epitome of computing perfection. But hey, who needs critical analysis when we can jump on the hype train and declare NixOS as the new Arch? Because that's exactly what's going on. NixOS has now become the self-proclaimed prodigy that's poised to dethrone Arch Linux as the holy grail of Linux distributions. The time is calling, my friends! It's time for you – the seasoned Linux enthusiast – to dust off your keyboard warrior capes and embark on a new crusade. So, grab your Tux plushie (or, your pitchforks if you belong to the world of devils) and let's embark on an adventure through the enigmatic world of NixOS (and let the memes commence)!
The Nix package manager got ported to OpenBSD, so that part of NixOS must be excellent.
I’m surprised, and really pleased; I was under the impression that Nix required Systemd, and was thus a Linux exclusive. Good to see
Nix (the package manager) does not depend on systemd in any capacity; just like apt, apk or Pacman do not depend on systemd.
NixOS currently uses systemd and cannot be ported without major restructuring. So far the enthusiasm to do that has been very limited. InitWare may be the path forward but that project seems to have stalled.
Note that NixOS also does not support any kernel other than Linux either.
It is also available on macos
Nixpkgs is, but not NixOS.
Note that, while the Nix package manager can technically run on OpenBSD to some capacity, that doesn’t mean packages in Nixpkgs are compatible with OpenBSD.
I can’t comment on the current situation from first-hand experience but I can say that there is no support guarantee as there is for Linux and macOS and that there is no binary cache either. You have to build everything yourself and I’m not even sure we can build even basic packages such as
helloon BSDs yet.OpenBSD has no intention of trying to use Nix packages, my point was that the Nix package manager has useful enough features and functonality that it was ported to OpenBSD to use for managing OpenBSD software and packages.
That’s what porting does, it’s making a program fully functional on a different operating system or different hardware architecture. Compatibility serves a different purpose from porting.
My point was that support for BSDs in Nixpkgs (which is the de-facto “standard library”) is still in its infancy. Nix without Nixpkgs is like C without a libc.
Terminology on this is a bit loosely defined. What I meant was that the packages in Nixpkgs largely haven’t been “ported” to BSDs yet.
Many of the packages might already be “ported” and would work if other packages lower down in the tree worked. In Nixpkgs we don’t really differentiate between fixing packages so that the package works as upstream intends or making something work that was never intended to work.
There is zero interest in Nix pkgs, that’s all Linux stuff. Every and all Linux packages is incompatable with BSD, and there is no way to make Linux packages ever compatable with BSD.
To port Nix package manager to BSD they change the source code to run on BSD libraries, look for BSD compiled programs, and how run on BSD dependancies, interacting with a BSD kernel.
Installing Nixpkgs on BSD is the same as talking about making Mac OS programs run on Linux, that’s physically impossible.
OpenBSD is not trying to run the whole Nix distribution, they only tool the Nix package manager and changed the source code of the Nix package manager but removing all referances to Nix and Linux, changed the code to run on BSD libraries and changed the Nix package manager source code to look for BSD format files.
Nix package manager on OpenBSD has no knowledge and no understanding of Linux or NixOS files.
I may not have been precise enough here with the wording.
To clarify: Nixpkgs is a source distribution. You can see all of it here: https://github.com/NixOS/nixpkgs
From Nixpkgs, Hydra builds binary artifacts which then get distributed through the binary cache (cache.nixos.org). Users usually use binaries substituted by the cache but these binary artifacts are a direct result of the source, a small set of parameters (mainly platform), some time and some energy, so we usually rarely talk about them. They’re not interesting to us; we could reproduce them at any time by just building again.
What I’m talking about all happens at the “source” level, not the binary level. You obviously can’t take a Linux binary to a BSD and expect it to run but you can take a package definition initially made for Linux, try to build it on a BSD and run the result of that.
From experience with Darwin, this works in the majority of cases and usually only requires very few adjustments to the build recipe. With Nix, we have a full expression language at our hands, so we are able to to things like optionally adding some dependencies depending on the platform. We usually do not maintain separate build recipes for separate platforms; they usually use the same build definitions with different parameters.
What do you mean by this? OpenBSD “forking” Nix (a la Guix) would be news to me. Do you have some links for me?
The Nix package manager has no knowledge or understanding of “Linux or NixOS files” on any platform, including Linux/NixOS.
Its purpose is to know how to evaluate and realise Nix expressions.
I can evaluate a Nix expression for OpenBSD on my macOS machine. Nix doesn’t care.
(Obviously I can’t build it but I could theoretically cross-compile it, if support for that was to be wired up in Nixpkgs.)
I think you’re misunderstanding a bit how Nix and Nixpkgs work with different platforms.
In the OpenBSD ports and packages tree for user installation here
Not sure what I’m supposed to see there, that’s just their packaging for the Nix package manager binaries. It’s largely unmodified from upstream, just some tiny platform compat patches.
What is this a response to?