I’m not really sure where you’re trying to go with that metaphorical language. But on any of the BSDs, Nix is certainly a ‘yolk’ in the sense or being almost unrecognizably far from its potential. Same for Nix on Windows and same for Guix on, say, macOS.
There’s not yet enough practical functionality (installable Nix packages) on those platforms for Nix to attract much of a userbase on those platforms. But with hardly any users, the only potential contributors are those who are interested in doing a lot of packaging work and don’t need many working packages today. That’s hardly anyone.
Contrast to Nixpkgs on Linux or Mac, where things are ‘good enough’ to attract lots of users who mostly want to just use Nix but may also make drive-by contributions at the margin. Nixpkgs on those platforms is already over some initial hurdles that it just isn’t on other platforms.
And it does seem to be a bootstrapping/critical mass issue to me; it would be easier to find contributors to a more mature version of any of those Nixpkgs platforms than what is currently in Nixpkgs. That’s why, imo, milestones like the one in the OP can be so exciting: it raises Nix’s visibility in those small communities and also shows some momentum, increasing the hope that Nixpkgs might reach critical mass on those platforms.
I just wish Nix won’t become a wall like Docker on the BSDs, with upstream project installation instructions being “just use docker” or “just run nix build”.
The best thing folks can do right now is help with cross compilations to new platforms (purer and easier to keep working in CI today than native stuff! And the best way to help with that is poke ones head in https://matrix.to/#/#exotic:nixos.org.
I suspect this is naive since I avoid the module system as much as I can and my knowledge is a little superficial+user-oriented, but whenever I’m doing something like setting up a development shell for a database or web server that has a module, I end up wondering if it would make sense to ~pull more config-generation logic towards the packages in the form of passthru functions and slim down the existing module implementations in nixos/nix-darwin/home-manager (and maybe devenv or others?)
I guess it might make the external module systems too sensitive to the nixpkgs rev, but I could also imagine it making it easier to:
deduplicate work
get more people invested in refining the config abstractions
create more leverage for setting up dev environments
make it easier to iterate on the groundwork needed for good BSD/etc. modules by exercising them in dev environments
minimize the module work needed to jump from there to the first palatable BSD-based NixOS (and maybe also each Nth? not knowledgeable enough about BSDs to know how much overlap there’d be at this level)
Yeah we should try to share stuff between NixOS and the other module system things. I have yet to fully dive into that so I don’t have many specific suggestions, but Initware in being a systemd fork is supposed to help avoid / shrink down that problem by allowing us to use the same unit files.
Yeah, because what I truly want are functions and direct overrides, and a) people want type checking b) we don’t have a systematic type checking solution except the module system that I avoid as far as possible, there is a way to at least suppress the worst things about the module system, but I haven’t figured out a complete integration solution for that. (I haven’t got around to spend much time on it, either; if someone is already good at using the module system and makes a PoC PR, I will happily update the RFC to document the proposed solution in the currently-missing part, and get the things moving again)
nix-build --arg crossSystem '{ system = "x86_64-openbsd"; isStatic = true; }' -A hello
Chat room:#nix-openbsd:tapenet.org which already existed, thanks to @qbit who previous took a stab at at this, and more recently answered many questions. Let’s revive it!
