Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm liking NixOS thus far. I've got it installed on my personal laptop. It's got some rough edges, but the benefits for me outweigh the downsides. I really like affordances like "nix-shell -p foo" to just run a shell with the "foo" command in it for one-off usages, instead of slowly accumulating installed apt packages that I forgot why I installed them.

Similarly, having any custom configuration inside of "configuration.nix" is way nicer to use than manually editing /etc/whatever.conf. I can have one place to store any custom hacks, with a nice comment as to why + git history.



> It's got some rough edges

I've recently been looking really hard at NixOS as a possible next-step. (I use Manjaro and am particularly interested in ways to keep my Laptop and Desktop in sync)

I've heard that the documentation can be pretty lackluster at times. Are there any other rough edges I should know about?


I'd say it's really about the documentation, including "unofficial" documentation like bug reports and SO questions. Part of why Ubuntu is so popular is because there's enough of a community that whatever issue you hit, someone's probably already hit it before and asked about it on SO, where it has a highly upvoted answer that fixes the issue and explains it. That's also why NixOS seemed like a better choice than Guix to me.

One thing I ran into was setting up a Python project using poetry2nix. Mostly works great, but then you sometimes get inscrutable error messages. I had to copy this into a shell.nix file for reasons that aren't entirely clear to me (and I had to hunt it down from https://github.com/NixOS/nixpkgs myself instead of finding docs or a bug report):

    astunparse = super.astunparse.overridePythonAttrs
            (old: { buildInputs = old.buildInputs ++ [ self.wheel ]; });
One non-documentation issue I've hit is that even when using the stable channel, you live much closer to the bleeding edge than a distro like Ubuntu. I updated my system to the latest packages, and then my wifi wouldn't work after waking up from sleep. Turned out to be a kernel regression that was fixed a few days later in a patch update. Everything was fine again, but it's not something you'd run into with a more conservative distro. Similar issue with the latest Gnome breaking extensions for a while before they got updated.


> Are there any other rough edges I should know about?

I think the easiest to encounter is that programs downloaded from the internet might not 'just work' for various reasons. (e.g. because they're linked against libraries in more typical locations, or because the code hardcodes paths like /bin/bash or /bin/rm which NixOS doesn't provide by default).

So, when programs like minikube like to provide a nice UX by downloading helper executables, it won't 'just work'.

Solutions vary from "someone already packaged this, it's not a problem" to requiring deep understanding of what you're trying to do.


It's not trivial to package/run stuff that isn't prepackaged (unusual given that NixPkgs is enormous).

But not too hard either, I authored several official packages within a few days of migrating to Nix. It's only difficult if the build process is a bit uncommon or ugly.

The hardest part about NixOS is figuring out what to learn, and in what order.


For development, not all languages have the same “support”, tooling. This is sometimes inherent in the given language’s dependency management or popularity.


I’ve ran NixOS on my last two machines. I like it more than the alternatives, but it isn’t without flaws. At this time, you must be sold on the idea of declarative configuration and willing to learn at least the basics of how Nix the language works.

It’s cool that you can Git pull and build an OS, but management of the project can be very slow. Using a ‘pull requests’ model majorly slows down progress; if you need to revise changes for a new package or package update, you will make the correction and get approval, even as a maintainer, but no one will come back around to merge it. With a patch-based model maintainers can waste less time by just making those few modification to the patch and getting updates upstreamed faster without the back-and-forth.

That said, it’s still something I’d recommend for someone with the experience and interest. There’s never been a system I was as confident with running patches and just updating the system myself for when stuff wasn’t working. But also, Guix is out there doing similar stuff and you must admire the free software goals even if it can sometimes be impractical (I just do not like the Scheme-based syntax).


I think NixOS is what the future should be. Searching and resolving packages still seems slow, and things like flakes are still evolving to address rough edges, but having completely declarative definitions of the entire OS installation is amazing.

Spinning up native development environments as an extension of production environments is nice too.

I worry that tools like pyinfra and Ansible combined with Docker containers and traditional distributions might be good enough to prevent critical mass in terms of user adoption.

Even so, it’s worth daily driving for a while just to get a sense of what the world could be like. Kind of like Erlang OTP versus Kubernetes and containerized microservices.


For anyone interested in trying it know there is one major downside: most Linux binaries won't run on it because dynamically linked libraries work strangely on NixOS


This. And it's completely reproducible. IMO this is the best bet for stability + long-term survivability.


Also you can easily remove packages without leaving now unused libraries behind.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: