I would love to see NixOS-style declarative management brought to one (or more) of the BSDs.
I'm currently building out a NixOS-based router to replace an old and dying Ubiquiti Edgerouter Lite. BSD would be perfect for the job but the ability of NixOS to have the entire system configured declaratively is enough of a killer feature to get me to use it over something BSD-based.
if anyone is interested in pursuing something similar, I'm using [0] as my hardware base and [1, 2] as example configurations.
Back in the day I had some dealings with Joyent, and I pitched them on Nix for SmartOS. I couldn't get them to take me seriously, because they were old-school Unix heads, but damn that would have been a great system.
Define a zone with a Nix derivation, the Nix Daemon installs all its dependencies into a shared Nix store, which then gets mounted read-only into all the zones. It would have eliminated all the copying things around they were doing with pkgsrc, speculatively installing a bunch of stuff in case you need it, Manta etc. Alas!
I'll be setting up this 2.5GbE fanless box [1] as a router soon and this looks cool, maybe I'll test it out. NixOS' killer feature for routers/firewalls is probably how easy it is to revert to the previous configuration if something breaks during an upgrade. Some people even run their firewall in a VM so they can try out different configurations without worrying about bricking their main one, but that whole concern is nixed (pun intended) with the way NixOS works.
Do any of these mini PCs have rack mount options/kits available? It seems like all the affordable+low power opn/pfsense boxes don't have options for rack mount other than plopping them on a shelf. Even the official ones from Netgate, their rack mountable routers start at a much higher price and performance point than I need but I really want everything tidy in my existing rack.
Search “firewall + 1U” on Aliexpress/Alibaba. Or, hear me out, get a NanoPI R4S and just mount it to the side of the enclosure, get rid of the shelf altogether. No shelf no problem. Next level aesthetics ;)
>I would love to see NixOS-style declarative management brought to one (or more) of the BSDs.
In theory, an OpenBSD NSH configuration would have a large overlap of features and functionality with the Nix-based router configuration you've been working on. Btw, NSH allows one to configure OpenBSD in a similar CLI shell as that of a Cisco, ProCurve, or similar device. The shell commands make up a configuration file that can be exported / imported. NixOS & BSD is something I thought of but hadn't mentioned when someone recently submitted[0] a link to NSH. Coincidentally, another user brought up NixOS as a potential solution, only for the comment to trigger some friction[1].
I've been dreaming about more integration between Nix and BSD for a while now, but unfortunately, my skills and knowledge to actually implement something like this are nowhere close to where they need to be to actually create anything in this vein. That being said, there are others who have done more, and so Nix is available on FreeBSD[2]. Nix on FreeBSD has a long way to go before it's as useful as it is on Linux/macOS - the latest discussion on it is in the NixOS Discourse forum[3].
Appreciate you linking to the blog post and GitHub repo for nixos-router. FYI, one other option available for Linux is the Debian-based VyOS[4] which provides a familiar command-line interface like OpenBSD NSH.
If I may ask, how is vyos in terms of functionality? I'm more than comfortable with cli (have worked with cisco/hp/arista routers and firewalls before).
You can write Chef targeting OpenBSD and run it in local mode. Get to use plain Ruby instead of a hodgepodge functional programming language. NixOS modules tend to be more "batteries included" than your average Chef cookbook, but if you stick to using native Chef resources you get something (pseudo-)declarative and powerful.
Disclaimer: I use NixOS every day and I love functional programming. But boy do I wish Nix had picked Haskell, OCaml, or Lisp instead of inventing a programming language.
Chef isn't an alternative to NixOS. Chef is imperative and stateful as it could possibly get. The whole thing is piles upon piles of unrestricted Ruby code that gets evaluated during deployment. NixOS has the exact opposite design.
Compared to NixOS, Chef's design allows for flexible deploy time decisions, but it comes at a price. With Chef, it's hard to ever predict everything that's going happen during deployment. Chef code takes a bunch of external inputs in the form of Chef attributes and also has full visibility into server state. All of this happens during deployment. So to make sense of what would happen during deployment, you'd have to run your Chef code in the exact same environment as your target server. To make things even more challenging, Chef code can easily mutate server state irreversibly unless you go to extreme lengths to prevent it.
NixOS, on the other hand, prioritizes predictability and reproducibility. It builds the files required for deployment beforehand in a sandboxed environment before the deployment phase, with all the necessary inputs fed upfront. During deployment, it mostly copies those files into an isolated location under /nix/store and creates symlinks to them in /etc and elsewhere to activate the system. Figuring out what would happen during deployment beforehand is a matter of inspecting the built files.
Furthermore, unlike Chef configuration, NixOS configuration doesn't concern itself with deploy time actions. Its focus is on expressing static configuration. The Nix language is used for this purpose, so comparing it the against unrestricted general purpose programming languages is a mistake. A better comparison would be languages like JSON, YAML, Jsonnet, and Dhall.
I like the design of Guix more than NixOS, but I haven't gotten around to actually trying it. The tricky thing about GNU distros is they often make it very difficult to install nonfree packages like Discord. I don't use proprietary software very often, but when I do I prefer to have it available in my distro's package manager.
Besides that, I look forward to giving it a chance.
Heavy Nix user here.
Since month two I've been using flakes for everything: In projects to holds packages and devshells together with inputs locked via lock files, for holding system configuration, raspberry pi images, nixpkgs overlays etc..
Does GUIX have some similiar thing which can provide a standard formal structure and lock resouces? Thx.
Not that I know of, but ideas continue to trickle down, so I look forward to a reimplemention for Guix in the future. Something like nix-index would be great too, but all in due time, as the project admittedly doesn't have quite as many resources.
edit: to be clear, I'm taking about flakes, Guix does have plenty of mechanisms and utilities regarding direnv-esque project manifests, lockfiles, and even "inferiors" which let you install outdated packages that the distribution has otherwise moved on from by actually building and using the version of guix that the package would have been built with at the time
I also use a qotom box for my main router. It runs arch and is 100% automated via Ansible. I have recently taken the deep dive into Nix and installed nixos on my main laptop. I have much to learn but am considering things like replacing the router with Nixos now too.
As someone who's only recently made the switch from OpenBSD to NixOS due to work needing Linux, I have some thoughts on this. OpenBSD is very easy to reason about -- not too many things going on, and every little thing is documented. The system fits in your head and doesn't overwhelm you; it is predictable and sensible.
NixOS on the other hand: while I really like the idea of declaratively managing your entire system, the whole functional programming schtick isn't for me. I cannot for the life of me understand half the stuff I read (the Nix language, that is). I still don't see why all this couldn't have been written in say, Lua for example. Nix (and NixOS), is overwhelming.
That said, it's the least-shit of all Linux distros because it brings about the cohesion that others lack. I will continue to use it, at least for now.
> the whole functional programming schtick isn't for me. I cannot for the life of me understand half the stuff I read (the Nix language, that is). I still don't see why all this couldn't have been written in say, Lua for example. Nix (and NixOS), is overwhelming.
It's because you're still thinking about this imperatively, when you should be thinking declaratively. I was in the same boat as you, but everything has recently begun to gel and it's much easier to read Nix configs.
The language is definitely intimidating but once I wrote a few small derivations for my own use, everything became clear almost immediately, much to my surprise. Try to do everything as declarative as possible (use flakes) and you'll have a considerably more consistent experience.
Would you mind giving me an example of something that’s declarative vs imperative? I see this distinction made all the time and for the life of me I still don’t understand it.
Or rather, I’ve never seen “declarative” code that I’ve liked. I watched a YouTube video once wherein two bits of code achieved the same thing, but one was imperative and the other declarative. I preferred the “imperative” code every time because I could actually read it, see what was going on. The “declarative” code seemed like it was obfuscating something or engaging in a bit too much magic for my tastes.
All the cool kids prefer declarative though, so I’m wondering what I’m missing.
it is about telling what you want instead of how to do ("computer thinking"). so let's say you want all numbers from 10 to 14 excluding 13, 15, 19 and 23. In haskell you do `[x | x <- [10..24], x /= 13, x /= 15, x /= 19, x /= 23]`, which is declarative. In imperative programming you generally would need to do control flow like a for loop. So declarative programming is way more expressive, as in functional programming like haskell it borrows many mathematical notations.
I find declarative programming like functional better for higher level programming, while Torvalds for example likes C for Linux development because it is closer to how computers work (while providing the needed abstraction than programming in assembly for example).
but i don't think the argument for it really makes any sense for OP's comment. As an user or even packager you hardly use actual functional concepts. You're mostly dealing with a JSON with some functions for declaring the system, not some crazy Haskell shit. It is just that it takes time to learn new stuff, and stuff that have concepts you're unfamiliar with takes a bit longer. And it is true that the curly braces, function arguments, and some other stuff can look kind hard to decipher, but in general it's a familiarity thing.
They both do. I use Guix on Ubuntu right now as it means I can get the benefits of Ubuntu for running things like Steam and Nvidia drivers easily but also the benefits of Guix for programming stuff. It's not perfect though.
I'm currently building out a NixOS-based router to replace an old and dying Ubiquiti Edgerouter Lite. BSD would be perfect for the job but the ability of NixOS to have the entire system configured declaratively is enough of a killer feature to get me to use it over something BSD-based.
if anyone is interested in pursuing something similar, I'm using [0] as my hardware base and [1, 2] as example configurations.
0: https://amazon.com/QOTOM-celeron-Processor-Fanless-pfSense/d...
1: https://francis.begyn.be/blog/nixos-home-router
2: https://github.com/stanipintjuk/nixos-router