I think NixOS would benefit from easily accessible collection of opinionated modules/profiles/configurations with minimal set of options. Something like gnome-desktop / sway-desktop / etc. Gnome actually does pretty good job here.
The point is: currently my NixOS and Home Manager configurations have over 2k LOC total. When you search for configurations on GitHub/Google you are likely to find complex ones. For example, quick search for "nixos gnome" (Google) gives me link to NixOS Wiki (which describes only Gnome part) and blog post (https://gvolpe.com/blog/gnome3-on-nixos/) which is useful but links to really huge configuration (https://github.com/gvolpe/nix-config) that is overwhelming to any beginner.
Yes, that's how I learned nixos -- moderately on the sparse documentation, highly on other people's code. I was shy on the #nixos channel.
Now I have a working setup which spans all of my computers and servers (I also have autodeployment scripts for aws and netboot). I use the devos flake as a template, check this out: https://github.com/divnix/devos
It's for the user packages. This way you can keep the system profile lean for fast updates of the kernel and such, and then update firefox and other things separately. With Guix they have had manifests for a while, which are integrated into Guix proper and are like the package half of Home Manager (not the config stuff). I only keep a handful of things installed as system packages, and then I have probably 100 or more things in my manifest.scm file. As my user I apply this manifest and it will install or remove things as needed. No root privileges needed.
> This way you can keep the system profile lean for fast updates of the kernel and such, and then update firefox and other things separately
That makes a lot of sense. Right now a nixos-rebuild is really slow for me as I have a big configuration.nix file. I guess Home Manager could help in this case, will dig into it.
My primary use-case for Home Manager is dotfiles management. This way I can keep them consistent across all machines and development containers (managed with NixOS declarative containers, so Home Manager configuration is applied on container startup).
A lot of odd Nix hate in here, or at least extreme dislike.
NixOS is so very usable. There are a lot of foot-guns but that's true of Linux systems.
It takes some time to get comfortable with all the different ways to configure stuff. There's a new language, a new build system, a new Linux distribution.
I've spent very little time relative to say, figuring out dpkg or systemd, or learning Bash or C or Perl, or learning the Linux FHS.
NixOS makes running deterministic systems driven from a single configuration incredibly easy.
Nix the language and tools allow you to build software deterministically and create environments where that software is available (e.g. on $PATH).
Nix Flakes is an experimental feature aimed at bringing reproducible and hermetic configurations of dependencies into the fold (i.e. lock files, ala Gem or Cargo or Go Modules).
Nix-the-tool's interactive "package manager" should be deprecated, as it's a huge pitfall for most developers. But it works and is frankly a good first step for folks coming from Apt or Homebrew.
Learning to write modules is probably the steepest learning curve, but compared to learning how to build RPMs or Dpkg or Brew recipes, it's really not bad at all. I actually find it easier and I've been at this for less than a year. Sure, if you're trying to get something working no one has figured out yet you may be in for a pickle, but that feels like it's always been true. The difference is a lot of software breaks and bends the rules and boundaries constructed to keep things and people sane. Nix does not allow that, generally, which is a very good thing. Fixing other people's garbage is the bane of any package system maintainer, it's no different here.
Crazy thing about NixOS is that it's so good, all the bad parts can be excused. I like to go on forums and complain about how the Nix configuration language is horrible, and there's not much documentation on how to get general things done.
But that said, I'm still running NixOS on my servers. And no way that I'd ever go back to old fashioned provisioning scripts like Ansible.
Just yesterday I had a problem upgrading a machine that's been running for 3 years without updates, and it wouldn't upgrade to the latest version of NixOS because of some certificate issue I couldn't figure out. Tried a couple things, nothing worked, gave up and destroyed the box. Installed the latest version of NixOS on it, pulled my configuration from git and it's back online exactly how I want it.
It runs 5 websites in docker containers with a reverse proxy that automatically gets its SSL certificates from Let's Encrypt, some other services, and a tmux session with irssi. Everything neatly managed by systemd through unit files, everything set up from one simple nixos configuration.
If I'm complaining about NixOS, it's because the best server operating system in existence right now has flaws. Not because I'd ever go back to a traditional linux distribution.
> Crazy thing about NixOS is that it's so good, all the bad parts can be excused. I like to go on forums and complain about how the Nix configuration language is horrible, and there's not much documentation on how to get general things done.
I don't think it is fair to say that Nix as a programming language is horrible, IMO, as a DSL it is pretty good and fits the domain well.
It is a strange language at first and it takes some time to learn all its quirks. Also, it lacks better tooling, things like LSP for example (there is one but it is slow and limited last time I tried). But just claiming the language is "horrible" is really unfair.
I think it's fair. It is, by far, the biggest hurdle to adoption and contributions.
I'm a SWE and I don't grok it yet.
Granted, I haven't spent a ton of time on it. But if you have to spend a ton of time on it, it has in some sense failed.
It's harder to learn than literally any other language I can think of that isn't designed specifically to be esoteric. Most languages, after you have picked up a few, you can just glance at and you've got the basics. Nix is its own beast entirely.
Edit: I do acknowledge that there is some difficult to manage inherent complexity. And, like many others, I love what Nix is trying to be. But I do think improving the language would be a big step.
I mean, I am very used to pure functional programming and I still find Nix quite challenging. For a lot of reasons. The abstractions are all weird, there are so many pieces that are confusingly put together, etc. Lots of stuff.
Even the PL itself is really weird and unfamiliar. And not super well documented. I remember spending a while not too long ago trying to figure out how to interpolate a string. And then you have goofy stuff like with, etc.
Exactly. Before learning Nix I used Elixir and Clojure, so I was pretty much at home using a functional language (even if Clojure/Elixir are not exactly pure functional, but they come close with their immutable data structures).
The other thing that trips some people is that Nix has lazy evaluation. Even Elixir or Clojure uses eager evaluation, so this concept is even more uncommon the functional programming. However, this concept bite me just a few times, so it is not like you have frequent issues with it.
In my experience, the biggest problems for learning Nix (the language) are the lack of type annotations and the tendency to separate function calls from function arguments. The first time you look in `my-package.nix` you find... a dict of function arguments? I think? What the heck? What function takes these arguments? What function arguments are valid?
So you end up grepping the whole source tree for `"./my-package.nix"` just to see what functions are using it, and you find this construct:
someFunction ./my-package.nix
Which in other languages would be the slightly bizarre
So you're pretty sure these are arguments to someFunction, but it's weird that the call to `someFunction` wasn't in the same file, because it makes it hard to know what's going on.
All of this this wouldn't be so unclear if the syntax wasn't visually similar yet semantically different from most languages. The map syntax in particular looks exactly like a block in curly brace imperative languages:
{
foo = "blah";
bar = foo + "blahblah";
}
----
Fortunately, there's work to separate Nix (the tool) from Nix (the language), so that any configuration language can be used to produce derivations. Nickel has been one of the drivers of this push:
This is exactly what I meant with "there is one but it is slow and limited last time I tried", but it does seem that they made good progress (the last time I tried it was some months ago).
Yeah, I'm just waiting for Jeff Geerling to get onboard with Nix. Then things will get interesting (he's a big Ansible buff and probably the biggest RasPi Youtuber).
I disagree. I don't use Nix, but I've been in situations before where an upgrade either couldn't complete, or catastrophically broke something. Those situations are horrible and can take hours or days to resolve.
Having the option to say "fuck it" and just reinstall everything, without worrying about manually installing exact software versions and reconfiguring everything sounds amazing.
I think the important thing that did not come across very well is that "wipe and reinstall" with nix is so incredibly painless that doing it is even an option. The same would be very very painful with other distributions. A clean reinstall of your whole system with nixos takes maybe 30 minutes. Compare with the average "my Ubuntu upgrade failed" debugging session...
Yes, and speaking of… the fact that “generations” are a central feature which allows seamless rollbacks to previous system states means that if your upgrade fails you’re hardly ever more than a few minutes away from a functional system again.
Wait, isn't a point of NixOS is that your updates are guaranteed to be smooth? I haven't used it, but your story now worries me. I don't want to be back at "just reinstall the OS" days, even if configuration is portable.
> And it wouldn't upgrade to the latest version of NixOS because of some certificate issue
This sounds like Lets Encrypt changing it's protocol. Nix itself doesn't give a shit about such things, but maybe some sort of script was supposed to double-check the cert on boot (just speculating). While NixOS can be reproduciable, whatever software Let's Encrypt runs is obviously outside the host's control, so perhaps "leap-frogging" to the latest NixOS somehow helped.
This is incidentally a good example at why I am pretty against microservices (not saying Let's Encrypt is a bad or a microservice, but it is the analogue of one in this parable).
I couldn't figure out what it was, but it was definitely a problem with NixOS itself, possibly with expired root certificates or something like that. The upgrade command couldn't connect to the nixos servers. I know there was at least one root certificate that expired in the past 3 years, so maybe I just caught a bad interval for not upgrading.
On NixOS installing any package is the same as reinstalling the operating system. Reinstalling the operating system just took a minute longer because it had to do more downloading. (edit: in theory, I actually bet that the certificates sneakily leak mutable state into the system with the expiry process, i.e. I bet that if I reinstalled the same version of NixOS with the same configuration, I'd get an install that would actually be able to talk to the nixos package servers)
But you're right to be worried a little bit, and this is exactly why many people criticize NixOS. In theory it's the most perfect operating system, but in practice it's so complicated that when something's bugged it's really hard to figure out how to recover, and the documentation is not up to the task of educating you on what to do when things are wrong.
Also this situation was a bit special because it couldn't talk to the NixOS servers for upgrading (I presume due to an expired root certificate, but I couldn't figure it out), if it was any other problem, I could simply roll back the upgrade process (which would be instantaneous because it doesn't actually remove the old packages when you upgrade).
With a cloud server it's obviously less of an issue, but even with a desktop for Nix its less of an issue than any other distro.
Each time you update your configuration it's essentially reinstalling. When you boot you have the option to boot the previous version (which includes previous app versions and etc).
Reinstalling NixOS and updating it are extremely similar actions except for full reinstalls having data loss (formatting) and taking longer (cache is empty).
When you use Docker you probably don’t configure your websites using Nix so there is no deterministic build happening here? In Ansible it’s just a few lines of code to start a Docker container. I’m not sure how Nix really helps here.
In Nix it's also just a few lines to start a Docker container. I might be considered a heretic by the Nix community, but I don't believe in the advantages of Nix for software development / application configuration. Docker is the end all solution to that problem in my opinion.
I haven’t used full-on NixOS yet, but I’ve used the Nix package manager quite a lot, and literally all of my forays have been miserable for a variety of different reasons.
To be clear, I love what Nix aspires to be, but it doesn’t deliver on its promises IMO.
As a package author, the Nix language has lots of rough edges, it’s absurdly tedious to figure out how to call various functions (what type of argument does it expect?) because it’s untyped and nixpkgs is poorly documented. There are too many other issues here to unpack.
As a consumer of packages, it’s often unclear what I need to do to install anything but the simplest packages. E.g., installing vs code with some plugins (note that this differs between NixOS and other systems). Further, the CLI interfaces are confusing from a UX perspective IMO, and it’s often unclear what I actually need to use Nix well (homemanager? flakes?) the guidance is confusing and contradictory.
So I don’t hate Nix, but I do have a lot of constructive criticism.
>So I don’t hate Nix, but I do have a lot of constructive criticism.
Why not write a blog post? Probably some of those issues are known but no one works on them, so a reminder isn't bad. And for those that aren't, maybe someone picks it up and tries to fix it.
Also considering posting your ideas to the Nix forums or possibly github issues, lots of activity there and you’ll probably get some good feedback before publishing.
The UI for Nix has been under significant rework over the last ~3 years, but the new UI isn't ready for primetime yet, so none of it is made prominent now. It's getting there though.
There’s no official support for non-free but the GUIX community has created a number of channels for non-free packages. I believe this is the main one:
Yes, but you won't likely find help for NonGNU software in the offical GNU Guix channels, IIRC they have a banner on their libera.chat that says you shouldnt be asking for help with non-free software here.
I have no opinion about NixOS but every time I read someone touting its merits I feel like I live in a parallel universe. NixOS seems to solve problems I never had at extreme costs to its general usability.
I don’t care that I can rebuilt a computer identical to mine in minutes. I don’t change computer often enough for it to matter and the tweaking I do is minimal because frankly tweaking configuration is not fun and feel like a gigantic waste of time. Same things for reproducible builds, I like them as a developer for the things I work on because they make things easier to manage and debug. I couldn’t care less as a user. I just want things to work.
I guess it could make sense for servers as an alternative to provisioning tools but then it seems to me like it’s competing with docker and kubernetes and I have never seen a convincing argument about why it would be better.
I think that’s why you see a lot of things you view as dislike. Plainly speaking I think most people don’t see the point.
The "market" for Nix is honestly OCD people that care about the software production process --- "god willing" our fastidiousness will eventually pay off as everyone else slowly boils in "accidental complexity", and our decisions finally make sense to others. In the meantime, it's hard to convey the benefits.
For now, I argue there is surprisingly little business case to care about developer efficiency --- VCs want you to blow cash, and increased developer outsourcing with remote work is covering the stupid complexity costs the cloud imposed. Mainly, businesses are demand constrained. That there is tons of embarrassing supply chain issues rights now is to me in accordance with this. America has gotten really good at advertising and customer acquisition, but we've lost skills at actually doing the basics, as it is really easy to service whatever demand you can scrounge up.
So far now, you either really want a clean workbench, even at the cost of dealing with the complexity that cleanup exposes, or you don't. That says whether Nix is or isn't for you.
> it seems to me like it’s competing with docker and kubernetes and I have never seen a convincing argument about why it would be better.
This seems to indicate a huge mismatch between what you think Nix/OS is compared to what it actually is. NixOS is for creating/maintaining systems, Docker is for running applications and Kubernetes is for running applications but across multiple servers, neither of those tools are like the other really.
I would argue Docker and Kubernetes are a bunch of crap popularized by people lulled into blowing all their money to cloud providers and compelled out of envy to imitate big tech -style deployments, even though it means taking on extra problems you absolutely don't need to deal with.
Also, Docker and Kubernetes are...just more layers. There is no cleaning up what came before. The Nix ecosystem is about drilling all the way down and cleaning up the prior tech debt. It's a fundamentally different approach.
Again, misunderstandings seems to run rampant in this thread...
No, Docker doesn't maintain systems, it handles applications. No one runs systems inside of Docker. People run applications with Docker, and Docker itself runs on systems.
And no, Nix doesn't "do this differently and better", as what Docker does and Nix does is wildly different. Nix is for machines, not applications. Sure, a subset of features from Nix can be used like Docker, but that doesn't mean Nix and Docker is the same, no matter what you think of markets or whatever.
I think what the parent is alluding to is: What is the practical point of using Nix when similar outcomes can be reached with more mainstream solutions? In other words, suppose I want to deploy a web app that depends on Nginx, PHP, and PostgreSQL.
I could:
(a) Run all as docker-compose type solution
(b) Run all as scripted Nix solution
(c) Install packages manually on general purpose OS
Lets ignore "c" for the moment as the goal is to avoid that exact scenario. Given the prevalence and widespread support for "a" why should sysadmins choose "b"?
I don't understand how you can use docker-compose, docker, Kubernetes or anything else to achieve the same thing as NixOS. NixOS gives you a fully reproducible personal computing system, from boot config, window manager, partitioning to applications, home directories and everything in between.
What mainstream options are available for doing this? Guix could be one option, but it's not mainstream so I'm not sure what tools you are referring to.
Guess I'm missing the whole subject of this thread then. The submission is about NixOS, which is for full systems (like in personal computers), something you cannot build with either Docker nor Kubernetes, the technologies that WastingMyTime89 said seems to compete with NixOS.
Eh you can do the same thing (or close enough) with a bash install script on a "stock" linux system and then a docker set up with the applications that that you want. Or with ansible. it really depends on the end goal. Not everyone needs every single bit to be the same. Or you can just image a drive. It depends on the end goal and often multiple solutions will get you there.
These are the nasty solutions I have to deal with at work all the time and my entire job consists of handling things when the "quick" bash cloud init script that someone wrote and various people have made additions to over the years goes wrong.
Bash scripts fail at this task because they are generally not convergent. Ansible makes a basic effort at being convergent, but most of the scripts I've seen are extremely naive about the ways in which a configuration can diverge.
And why would someone want that? Sure it sounds theoretically nice, especially if I was still working in IT. But learning another system with a poor ui has a large cost for a theoretical benefit.
Nix is (a) and (c), depending on how you want to use it. What differentiates it from docker-compose or `dnf install` isn't just the fact that you can ship something in containers or install some packages but also the various properties those containers or packages inherit from the build system.
Yes but no. Docker is mainly used for its ability to build and reuse standardised containers. It’s very much a distribution mechanism (I mean that’s why it’s called docker). From other comments I get the feeling that NixOS could be used to build reproducible containers in a way that remind me of building tools like Bazel but it’s not entirely clear to me why you would chose to do that nor if it’s actually a goal of the product.
> I guess it could make sense for servers as an alternative to provisioning tools but then it seems to me like it’s competing with docker and kubernetes
It’s not competing, it’s complementing. Think of it as a fully deterministic “docker build”.
Yes but « docker build » already exists and can already be made deterministic so it’s indeed somewhat competing. Would anything be easier by using Nix?
Right now it seems to me like a large ordeal with little to no benefits and my interaction with the Nix community hasn’t been very convincing. A lot of Nix users seem to believe determinism and reproducibility of everything to be enough of a justification in itself. I don’t think it’s worth the pain.
The biggest limitation of using Docker for building images is that it does not allow for composition. You can't simply say you want to combine a Python and Rust image for example.
With dockerTools from nix (https://nix.dev/tutorials/building-and-running-docker-images), this kind of composition is easy. You also end up with significantly smaller image sizes - containing only exactly the dependencies needed for the image to work, which is also good from a security perspective - since it decreases the attack surface.
> « docker build » already exists and can already be made deterministic
Truly deterministic Dockerfiles are a rare thing to find among the ecosystem.
And we haven't even got into docker's poor support for unprivileged container building which leads to weird solutions using dind when you need to build an image from inside a container..
Two examples to get a taste of the tradeoffs and utility it provides would be postgrest and IHL.
I think it’s sexy. But like you I haven’t had the time to really dive into it and understand it. The promise is simplification, both operational and in terms of the runtime.
> A lot of odd Nix hate in here, or at least extreme dislike.
I hate this expression. I'm a nix user. But if you can't understand why people dislike it... you're the one that's odd and out of touch.
If you want people to adopt nix the worst way to convince them is to call their behavior odd when it isn't.
The reason why adoption of nix is so low is trivial. High initial learning curve and it's so different from everything else that's out there. The only reason why I got over that learning curve is because my company uses it. If it wasn't for my job I would not have have the will power to climb over that learning curve.
Like seriously can you not see that someone is not willing to spend months learning nixos when they can get a pretty much from point A to point B using a turn key solution like ubuntu?
Nix is great. But you need to climb over the initial hump. That is all.
What we dislike is everything talking about the costs, and not the benefits. Fine if it's not for you --- I personally care more about institution and upstream adoption than getting more random end users at this point --- but people passing off these one-sided cost-and-no-consideration-of-benefits analyses as engineering decisions is a bit grating.
To me Nix is hard, but Nix is worth it. I acknowledge these people's pain, now would they acknowledge my pleasure (ideally without writing it off as that of a cult inductee! :)).
> What we dislike is everything talking about the costs, and not the benefits.
Exactly. I tried to push really hard our company to use Nix/NixOS (and maybe in our case nix-darwin too, since the majority of engineering uses macOS), but it never went anywhere (I did convert a few of my colleagues to use NixOS though).
But why? Well, onboarding is a pain in my company. We have some Ansible scripts that always break in some innovative ways, so it takes a whole day to setup a new machine for a bunch of engineers. Sure, partly of the fault is the fact that our Ansible scripts are really hacky (in some steps they still call some Bash scripts instead of using Ansible DSL for example), but Ansible is simply lacking in some places to have a really pleasant experience.
If we could use NixOS though, this would be a very different matter. I use NixOS in the same company, had the same configuration for pretty much 1 year, and also survived a broken laptop and setup my whole setup in like 30 minutes (most of time spend downloading packages actually). I even separated part of my NixOS configuration in another repository so other engineers using NixOS can also make use of it.
Yeah, it took a long time to get where I am currently, but nowadays I just stopped worrying about managing system, system update breakages, and anything like this. I can just use my system, fully up-to-date, and I know if something breaks, I can revert. It is beautiful.
Yeah I ended up working at a place that was already using NixOS -- as in developer laptops come with NixOS, and that was definitely a huge plus. Much nicer when the war is already won, and there is no class of macOS or Windows-using devs to appease!
> But if you can't understand why people dislike it... you're the one that's odd and out of touch.
Oh I know by now why people dislike it. I've worked for years with it with engineers of all stripes. It's always big heads and bad attitudes and never Nix itself.
And Ubuntu isn't a turnkey solution to what people use Nix for lol.
> A lot of odd Nix hate in here, or at least extreme dislike.
I don't have any doubts about the likes of Nix or even other attempts at improving the reproducibility of building and installing packages being technically superior to what we have now in some ways.
But at the same time, you can't forget about people and in some ways the industry taking the path of least resistance whenever possible.
You want to introduce a good but somewhat complicated way to manage packages? People will simply use "apt" while its UI/UX/DX is easy to get a hang of.
People get sick of differences between environments and how hard it is to deal with everything from resource constraints, port binding, configuration management, persistent data handling etc. in *nix? Many of them will turn to shipping VMs, tools like Vagrant or more recently - Docker.
Thus, it stands to reason that for any tool to become popular amongst the "common folk", not just brave early adopters or very technically able people, the tool needs to be easy to use.
I guess that's also why i'd say that more people use Linux distros (GNU or otherwise) as opposed to something like the *BSD OSes, even if those also have some notable benefits in regards to stability, networking performance, in-tree development etc.
Nix is common among consultancies because the more switching between projects you do, the more it pays off. If you like every 6 months (or merely every job change!) fuck with APT, your bashrc, etc. with a little stack overflowing during onboarding, whatever. It's too rare to be worth optimizing; I get it. If you switch projects every 2 weeks, the calculus changes greatly.
I do work at one of them now, but I got into Nix as a student hobbyist, when I was also rotating through homework assignments and personal projects quickly.
> Nix is common among consultancies because the more switching between projects you do, the more it pays off.
I feel like this is perhaps situational? I am yet to see Nix be used once in about 5 years of development in many projects in Eastern Europe, both governmental in private sector.
Though maybe the industry here is lagging behind trends - only in the past 3 years or so Docker has started gaining a foothold and even large corporations are just figuring out how to run their own Kubernetes clusters and Docker Swarm is still in use in some places, or even just Docker Compose.
Then again, some of these projects don't even have systemd services in place to ensure that they can be controlled easily, so who knows... Manually launching Tomcat or GlassFish instances never inspires confidence.
> I feel like this is perhaps situational? I am yet to see Nix be used once in about 5 years of development in many projects in Eastern Europe, both governmental in private sector.
Hah!
Nix is super European, and from my American vantage point the more west you go, the fewer Nix users there are! I first learned of the whole Eastern Europe consulting phenomenon via the Nix community too.
Yeah, good points. Nix has been as-yet very pointedly a developer-centric ecosystem. And not just that, but developer-centric for people who favor functional programming in general.
There's some work especially in the last few years to make it all more approachable, but that's the background. Wait a couple more years and you will see more projects like Nix GUI here start to mature and then it will get very interesting beyond people who have backgrounds in, e.g. distributed computing and Haskell.
Nix(OS) purely with Flakes i.e. without channels is so f good that I'm not using it just as my daily driver on a PC and to package software and create development environments...
I also replaced Buildroot with it for building embedded images for SBCs. Lifechanging experience.
I have went pretty deep in nix recently and imo the "Fixing other people's garbage is the bane of any package system maintainer, it's no different here" + high learning curve + lack of xattrs and permissions support in nix store makes it a bad OS. The amount of custom code to fix "issues" and "issues" that are only fixed because the maintainer thinks he knows better than the dev is too big to be maintainable. Still a good package manager for eg macOS if you dont need that.
> Fixing other people's garbage is the bane of any package system maintainer, it's no different here.
I honestly think it's hard for "Nix to Nix" simply because by trying to make everything reproducible, it is dealing with more of upstream's garbage, and "reifying" the hoops that people jump through doing sysadmin things in code looks scary.
I really want more upstream developers to use Nix, so they might loose their myopia, and start thinking of the the FOSS ecosystem as a whole, and not just their own packages within it. Nix is the best way to get the bird's eye view, I am sure. Just try not to gag at what you see!
[1] Though I still maintain that contributing to Nixpkgs is much easier than contributing to e.g. Debian or Fedora.
Yeah, exactly. Nixpkgs is basically the largest and most up to date repo in the Linux world now. Most of that’s coming just from the small existing core community. That has to say something for the efficiency of it.
Reproducibility is not the only issue they're facing. I think the mentality extends to more than just fixing linker issues, e.g. this https://github.com/NixOS/nixpkgs/issues/9656
At the end of the day, I much prefer trusting upstream than having to trust packagers to do everything right.
Having your screen locker which is written in C be setuid root is a really bad, really insecure idea. That it's supposedly being done for security reasons is replacing a minor, difficult to exploit security issue with something that's essentially guaranteed to be vulnerable.
Upstream is clearly wrong here - whether that means slock should be patched to be sane, or that slock should just not be packaged at all, I couldn't say.
The thread raises some valid points on both sides, but the slock issue is secondary to the real issue. Adding misc patches:
- Makes different systems behave differently - this makes bugs harder to track and confuses users
- Moves the trust from the software developer to both the software developer and packagers (who may not have the same expertise that the developer has)
For ex. #1: When you use software like slock, you presumably trust slock to do its job well. If you don't trust him enough in his choice to add setuid, then why would you trust him enough to use the screen locker?
I understand adding patches that are strictly packaging related if upstream is uncooperative (mostly I guess because nix is small), but changing behavior is another ballgame.
There's always been the tacit assumption that using a package manager implies trust in the way that packaging is handled by that manager. Often people who handle packaging dozens or hundreds of packages over years actually ARE much more aware of the security implications of decisions made by developers of individual pieces of software.
Fair, but at the same time, "setuid" is a war where everyone looses, IMO :).
Since the issue was first closed, there are some solutions for NixOS that I hope for discoverable. For Nixpkgs alone, I really don't think see any solution that is both secure and ergonomic -- setuid is bad.
Setuid has been replaced by capabilities, but nix faces the same struggles it has for setuid (only supports it through a wrapper, and that was after a "wontfix" according to the bug tracker).
More than that though, the mentality that you can just patch away critical features (like setuid) without telling the user is imo unhealthy for an OS.
Just because it doesn't have an obvious minimal modern UI doesn't mean it doesn't do its job. Gotta read I guess .. but then again Nix also in general has a prerequisite of "calm down and read." But then again, so does Linux!
The only thing you need to do to be Nix-competent is not flip the table and blame the tool when you get an error you don't understand. (Same goes for Haskell.) That said, my years of industry experience has shown that that is a rare attribute - doubly so amongst those with experience and therefore egos.
People in this thread act like Nix users are out of touch. Maybe, but I'd rather be out of touch and learning than grumpy that I had to read.
> Make NixOS usable for non-technical users through a settings / package management GUI.
^ emphasis mine. What exactly does a non-techical user have to read to understand whatever's on the screenshot? Forget non-techincal, explain this to a technical person.
Apparently this has something to do with sound? Have you or any nix-person ever seen a sound configuration screen for non-technical users? I mean this one is by no means perfect, but do compare: https://www.techrepublic.com/a/hub/i/r/2016/10/05/a7dba7dd-3...
What? They're nothing alike. One has normal, logical options like selecting sound effects and output devices. The other has useless things like how much the media keys adjust the volume by and whether to entirely disable sound on the system, and is littered with technical jargon like 'undefined' and 'boolean'.
You don't select your output device with your configuration.nix. You use it to configure the underlying OS. So doing this stuff with a GUI? Unheard of in the mainstream. Unnecessary maybe too, but still. Not the same.
You can be "grumpy you had to read" or "grumpy about other being complaining they have to read". You chose that latter and I think it's a good choice :).
> I'm guessing that you actually need to know Nix to be able to use it, which kinda defeats the "usable for non-technical users" goal.
I don't think that's true. Excel is usable by non-technical users. Part of it is due to the GUI, part of it is due to the easy packaging. But you still need to know spreadsheets to use it. This project does the same for Nix.
Unfortunately Nix-Gui hasn't yet achieved it's tagline. Hopefully https://github.com/nix-gui/nix-gui/issues/77 letting users configure a predefined list of options relevant to completing a task will bring us closer to that goal.
This is a work in progress and definitely isn't at the point where, for example, a Ubuntu user with little technical background could switch over easily.
As many commenters have pointed out, users will still be questioning which options they should change to accomplish a goal and will need to use a search engine.
To alleviate these problems, our next major step is "Guided Configuration"[0]. This will allow users to select a task (e.g. add a user, add a group, configure your desktop environment, configure sound, configure bluetooth, etc) and be provided a list of options relevant to the task.
Additionally "Recommended Options"[1] will inform users of options relevant to their current configuration which they have yet to define.
There are a few other smaller changes in the works to help with usability, and I'm open to suggestions for how we might continue to improve UX and make configuring NixOS intuitive.
What a coincidence. I was just asking about NixOS on Mastodon. Reposting (I'm on a mobile, little time to type):
" a question on dev environment isolation. Is either #NixOS or #GUIX usable as an OS for day-to-day use (coding, browsing, occasional gaming)? Or is it better to just use their respective package managers on top of regular Linux? Also, anyone here doing desktop #virtualization? Is there a sense of running a #VM per project? Is that a viable alternative to dual-booing Windows when I want to do some Windows dev or play a game?
I'm planning to overhaul my desktop and am exploring options."
Guix System is very usable as a main OS if your hardware is compatible. Linux-libre gives some people trouble with their GPU or WiFi. I use a ThinkPad T440p with the WLAN card removed, and everything that remains works fine. If you need blobs for an AMD GPU or WLAN, you likely need to swap out linux-libre for linux in your config. I haven't done this myself, but I know a few people who have done so. Also consider that discussion of non-free bits like this are not allowed in the official IRC and mailing lists, so you'll have to either be on your own or find the semi-secret places where guix users use non-free things.
All that aside, I've spent time with NixOS and Guix System both, and much prefer the latter. Nix has more packages, but some of them (which I actually use in everyday life) are broken in odd ways where they work fine in Guix. I also like to use a distro without systemd when possible, and find the guix community feels more alive/active. Getting more Guix users (and packagers) will help narrow the gap as well. There are enough packages that I don't miss too much in daily use, and you can comfortably get all your emacs packages through guix, I just often can't try some new program when I first learn about it.
Kind of orthogonal to your questions, but perhaps it helps:
NixOS solves OS-level issues. If you don't appreciate that you're having them, or you're solving them by other means, you might not see the appeal.
I tried NixOS on three separate occasions before it stuck. My existing setup is based on Debian and templating config files across machines (small heterogeneous network). This system can rebuild any machine from a blank slate, and so the first two times I tried NixOS I didn't see what it could give me - my configuration was already quite declarative and centralized.
The third time trying NixOS, I was aiming to make an image for a Raspberry Pi (after a Raspbian apt-get upgrade had borked a system once again). Seeing that I could make a full build from source, cross compiled or emulation compiled, with a few lines in a config file made it all click. It felt reminiscent of the Lisp curse where such a thing isn't well documented, because it's just second nature once you understand the system. I've only felt that level of paradigm changing expressive power a few times, and NixOS was one of them.
What is keeping me heading in the NixOS direction is the greater source accessibility. I've run Debian for 20+ years, and I still don't routinely modify existing packages. Whereas with Nix it's second nature because it's essentially a source distribution.
I've used it as my daily driver for the last 7 years.
I don't really play games that much but you can install Steam, and at that point the distro doesn't matter as much. (Though for a bunch of reasons I think NixOS would be the ideal distro to base SteamOS off of, and Valve & co. are only now closing the gap years later with some still-beta flatpak-esque stuff.)
I would say, if you can get excited with messing around with Nix instead of playing video games, you're going to have a better time. Not because you need to (though you might if this is your first time doing Linux), but because the joy lies in being able to understand "what the fuck is actually going on!" for the first time, and getting to that level of understanding will take some time.
You may already realize this, but you don't need to run a VM per project if you're using Nix; Nix lets you have as many self-contained development environments as you like, all on one machine without VMs or containers.
Over the years, I tested multiple options, and currently, I'm using NixOS declarative containers. It requires more work to create a new environment than with nix-shell, but in my experience, this is not a bottleneck. With some setup, you can even run graphical applications inside containers. I've written more about this and other approaches on my blog: https://msucharski.eu/posts/application-isolation-nixos-cont... if you are interested. It is pretty specific to my needs, so it may not work for you.
Regarding the Windows: after playing with GPU-passthrough, I came back to dual-boot. It is more reliable because you are less likely to run into some hardware quirk.
I've recently switched (from Arch) to Guix for my new desktop. Works great, though does require some work (I enjoy the tinkering). Depends on what you want of course, and needs you have especially in the non-free or things like JS (Guix does not package, but you can use Nix package manager or other tools I think). Here is the HN post for the article I wrote to see the article (about the hardware) and discussion https://news.ycombinator.com/item?id=28628344 I'll have some followups soon on what I like about Guix for this usage and how I set things up, with some tips.
I have a Windows VM on a NixOS host for gaming, was really quite convenient to set it up, I set it up on a separate drive to be able to boot native too but I ended up never really doing it, so I will reconfigure my 2 drives as a Zraid and have windows on a Zvol instead.
NVIDIA works great, but if I were to buy new hardware I'd go AMD (maybe Intel when the time comes)
> I have a Windows VM on a NixOS host for gaming, was really quite convenient to set it up, I set it up on a separate drive to be able to boot native too
I've been planning on doing exactly this, but haven't had the time to figure out the best way of going about it.
Is there a good guide/write up you'd recommend? (I already have a Windows 10 install on a separate SSD, but I rarely boot it because I can't stand the OS)
Can theoretically game on Linux and windows at same time with just a single gpu (2080 ti), mainly use it cause I only have single gpu and I don't want to loose hardware acceleration on Linux, the nixos module both applies a the vgpu unlocker for consumer graphic cards (so u can split a gpu in multiple virtual gpus) https://github.com/DualCoder/vgpu_unlock
And merges it with the GeForce drivers so the host gpu does not stop having display output
And I just passthrough the vgpu and Xbox controllers to the vm with qemu and my main windows nvme disk (windows naturally just works inside and outside a vm for me, dual boot)
Overwatch is also highly optimized via Wine, if you're looking to play. I'm on 6-year-old hardware (i5 4460, GTX 1050ti) and I have no problem hitting 120+ FPS in-game.
This video is a pretty good demonstration of how neck-and-neck the performance is these days. Frankly, I feel like it stutters less in Linux, but I might just be imagining things.
Don't know about Guix System but I've used NixOS as main OS for third year now just fine. Of course for coding you'll need to learn how to create (basically learn Nix, the language) an environment that has the libraries used in the specific project. The last question applies to any distro. Gaming is viable if you've GPU passthrough.
Two years user of NixOS here, moved after using Arch for about 3 years. Overall I'm really happy with it.
I also evaluated Guix when migrating from Arch. My raw and honest opinion about it is that it's just an attempt at open source fragmentation with zero innovation(I'm not impressed by Scheme or Lisps) that uses GNU marketing/branding/philosophy to gain adoption. I decided not to waste any time with it.
> My raw and honest opinion about [Guix/GuixSD] is that it's just an attempt at open source fragmentation with zero innovation(I'm not impressed by Scheme or Lisps) that uses GNU marketing/branding/philosophy to gain adoption.
This is an extremely uncharitable take on Guix. I hope it doesn't take root in the Nix community, not least of all because it overlooks areas where Nix could stand to learn from Guix.
Guix is ahead of Nix with:
• grafts
• its excellent subcommand interface
• documentation
• explicit organization/structure for contributors
• the bootstrap story
• trusting/signing channels
and it also has some interesting differences in choice of abstractions at various levels, like its service system vs. NixOS' modules.
Guix's existence doesn't harm Nix users or developers in any way, and there's no need for this kind of hostility or dismissiveness. As a Nix user, I hope Guix flourishes.
> Is either #NixOS or #GUIX usable as an OS for day-to-day use (coding, browsing, occasional gaming)?
Yeah, definitively. I use only NixOS on all my machines for about 3 years already. My machines are working so well nowadays that I rarely have to change anything [1], even during major upgrades (between stable versions).
I don't fear anymore if a machine could break tomorrow. I know that it will be very easy to restore it to a working state. Last time my working notebook broke I didn't even bother making a backup (except from some data on my Home), just installed my config and it worked exactly it was working before. Also, I don't fear changing my system: if something brokes after the changes, I can just rollback.
I use for all those three purposes, mainly coding and browsing, but some light gaming. Steam actually works better on NixOS than any other distro I tested before thanks to the isolation that Nix provides.
> a question on dev environment isolation. [...] Or is it better to just use their respective package managers on top of regular Linux?
I imagine those are part of the same question. Generally what I recommend for newbies is to start small: yeah, it is fine to continue using your respective package manager, specially if you don't need "native compilation" [2].
After you get more experience with Nix though, I would recommend you to start isolating your development environments. Nix has its own `nix-shell`, that it is kinda bare-bones but works well, and can be very practical once you use something like `nix-direnv` (https://github.com/nix-community/nix-direnv/). There is also this `devshell` (https://numtide.github.io/devshell/intro.html) project that is interesting.
> Also, anyone here doing desktop #virtualization? Is there a sense of running a #VM per project? Is that a viable alternative to dual-booing Windows when I want to do some Windows dev or play a game?
I put those two questions together because yes, I ran desktop virtualization on NixOS, and yes, I ran Windows on a VM to play games thanks to PCI-e passthrough (my dedicated GPU is connected directly to the Windows VM so the performance is near native) [3].
Again, I will not recommend you do to this right after starting NixOS since it is one more thing to possible frustrate you, but just so you know that it works and works well, specially because my VM configuration on NixOS is also on my `/etc/configuration.nix` and it is fully reproducible. Coincidentally I was messing with my VM settings yesterday and "broke" my VM multiple times, however I just run one command and restored it to the previous state.
However I never bothered to dual-boot NixOS/Windows, because I barely use Windows nowadays so I find rebooting my system just to use Windows bothersome. Probably not your case, so maybe dual-boot makes more sense. This article should help and seems very easy to do (again, disclaimer, not tested because I never needed it): https://nixos.wiki/wiki/Dual_Booting_NixOS_and_Windows.
About the VM per project, unless you want to do this for some other reason (security maybe?), you don't need to. As I said before, you can use things like `nix-shell` and this will already give isolation enough for development purposes.
---
Some closing words: remember, start small! Nix/NixOS is a journey. You will learn eventually what you need. However, if you try too many things at the same time you will feel frustrated. The official documentation is good, however it kinda assumes that you know what we are talking about already, and it is also very big and not well separated in steps, so it feels overwhelming for newbies. To supplant this there are many blog posts, however some of them are out-of-date (it shouldn't be too much of an issue though, since Nix tries really hard to backwards compatible).
You will eventually need to learn the minimum of the language to read the source code. It is less difficult than it seems, because while Nix as a language is strange at the first glance, it is a very well designed DSL for the domain. After sometime editing your own configuration you will naturally learn the Nix language, and can start to understand what is happening.
For where to start, I recommend trying to replicate your current system in a NixOS install. If you already use another Linux distro try to get the same desktop environment and packages that you already use. If you're coming from Windows/macOS try Gnome or KDE. Just tweak the system until you're happy with the result. Eventually try Home-Manager to manage your Home configuration in the same way as in NixOS (fully declarative), and once you feel happy, you can try Flakes (making you configuration fully reproducible). This process can takes months or even years, but don't bother or rush, just continue your journey. It really pays off in the long run.
[1]: well, I am on a "coding spree" right now so I am doing many changes, most to refactor some things that I wasn't happy before; but before this coding spree my configuration didn't change significantly for almost a year.
[2]: what I call having to compile C/C++ libraries in an another language like Python (giving it an example here, almost any language has a similar mechanism since C/C++ ecosystem is huge), that generally needs to dynamically link with whatever you have in your system installed. This is possible on Nix/NixOS, and easy once you know what you're doing, but it is different from anything else so it does trip newbies.
Thanks for the detailed writeup, and all the pointers in it!
> About the VM per project, unless you want to do this for some other reason (security maybe?), you don't need to. As I said before, you can use things like `nix-shell` and this will already give isolation enough for development purposes.
That's great to know. I don't have security requirements there - I'm just looking for a way to isolate projects along with their dependencies and supporting software (e.g. if I need a one-off installation of some program to create project-specific assets).
The problem I'm trying to solve is the system getting messy over time - accruing multiple versions of runtimes for programming languages, system configuration changes, pinned library versions etc., all because every other project needs some OS tuning or system-wide dependency. Eventually, I always end up hitting a roadblock where something I need now is incompatible with something I changed 2 years earlier no longer remember why. So I'd like to keep various projects and activities isolated, and to be able to just get rid of them when they're no longer needed.
The reason I'm asking about VMs is because I recall reading a blogpost or a HN comment where someone described how they're achieving what I'm after by running a hypervisor on their main machine, and doing everything in one-off VMs. I can't find that post/comment now, and I'm left wondering if this is something people do, and what the tradeoffs are.
Old versions of software are super easy to deal with with Nix, because it gives you a baseline level of isolation for all packages that obviates these problems. On some of my systems running the latest NixOS release from 2021, I've installed a package from 2015, and I didn't have to do anything to isolate it or its whole toolchain.
> The problem I'm trying to solve is the system getting messy over time - accruing multiple versions of runtimes for programming languages, system configuration changes, pinned library versions etc., all because every other project needs some OS tuning or system-wide dependency. Eventually, I always end up hitting a roadblock where something I need now is incompatible with something I changed 2 years earlier no longer remember why. So I'd like to keep various projects and activities isolated, and to be able to just get rid of them when they're no longer needed.
Don't worry, this issue is solved with Nix/NixOS itself.
If you use `nix-shell` to setup an dev environment for which project, you will generally have a `shell.nix` or `default.nix` file in the same directory as the project. For example:
with import <nixpkgs> {};
mkShell {
name = "myProject";
buildInputs = with pkgs; [
gcc
python39
lua
];
}
And once you use `nix-shell` inside the directory that contains this file above, it will download GCC, Python 3.9 and Lua, and put them on PATH. If you do a Ctrl+D, it will exit this shell and you won't have those 3 programs in your PATH anymore (assuming of course that you don't have them installed in your system).
BTW, this is where `nix-direnv` enters: it will do the `nix-shell` part and Ctrl+D management automatically for you. So once you enter in the project directory, it will automatically activate the `nix-shell`, once you exit, it will automatically exit `nix-shell`.
The Python case is specially interesting because if you have Python 3.7 in your system PATH, this shell will override the system Python, so only in this project you will have Python 3.9.
To avoid re-downloading them every time, Nix will actually cache those dependencies. So to really remove them from your system you will need to run the garbage collector (`nix-collect-garbage -d`), but since they're not in your PATH they will not conflict with other packages in your system.
It is something similar to NixOS (however in this case this is system-wide):
In this case, GCC, Python 3.9 and Lua will be available on your system PATH after you do a `nixos-rebuild swtich`. If you remove them they will be deleted from the system PATH after running `nixos-rebuild switch` again, creating a new generation.
The generation part is important: in case things break, you can go back to the previous version using `nixos-rebuild switch --rollback`. So let's say you changed Python 3.9 to 3.10 on your system but it actually broke something important (let's say it is a script that is important for your desktop, so now you don't have a desktop anymore): you can just call `nixos-rebuild switch --rollback` and everything will go back to working again, and afterwards you can commit your changes and run `nixos-rebuild switch` to commit them.
I don't mean isolating just the project, but also its development environment, tools for making assets, their dependencies, etc. Possibly persisting runtime state when switching over to a different project. Basically, as if each project had its own dedicated laptop.
IIRC, Vagrant was geared for just project isolation, and didn't offer the optimum VM management experience.
Having worked in a large Nix dev environment, the difficulty in understanding what was going on meant devops were needed for the simplest changes. Ended up being a blocker for every project I was on. Love the idea but really really dislike it in practice. NixOS is cool though.
With the naivety of someone who's never worked in _any_ large dev environment: I would guess for that to work (at this point, at least) every team would need either someone who knows Nix on the team, or at least on-demand access to someone floating?
I feel like ~proficiency with Nix has is a bit of a superpower as a developer. It's an incredible lever. But I have no delusions about how hard some "easy" things are, especially around language ecosystems with their own package managers. And learning it is a good bit of work.
Yeah the env I worked in was managed by some of the core Nix devs so they went in 100% and used all of the cutting edge features. It ended up being utter magic to me and most others I know. Tens of thousands of lines of Nix code so trying to add a library to the build was practically impossible, some of the code was hidden in private repos because it was confidential etc but other repos imported it… gah!
I think one of the reasons it feels like this is with Nix, the guts of what people are setting up are all exposed, right there in robust code. You see what's going in to the sausage.
In comparison, I've worked in projects which distribute their components as .deb packages, and the difference is night and day, the latter being a nightmare of laborious manual steps and funny tools. To a user of a .deb file this is all opaque, but let me assure you the complexity is most certainly there in spades.
Shopify is a shop with about 1000 developers who use Nix on MacBooks. Here’s a video on one of their internal tools which is basically just a bit of chrome on top of Nix to run anything without installing it: https://youtu.be/VUM3Km_4gUg
This is the type of costs-and-benefits "it's not for me" I can get behind.
(I left another comment about as a Nix user I don't mind it not being popular, but I do mind people complaining about the costs and ignoring whatever benefits might lie on the other side, as if all technology is reducible to its learning curves.)
Also having worked in a large Nix dev environment, I find it quite intuitive to use and the reproducibility is a great way to ensure your bugs aren't caused by an incorrectly set environment variable or something random like that. It does get a bit annoying when you need a package not available in nixpgs but thats true of any build system
I keep going to the NixOS website to understand what NixOS is.
it says it's an "OS". I've been in the computer thing for a long time and in my experience, an "OS" is the thing that runs when your machine first boots up. From this it follows that you can't run an "OS" without rebooting a machine (or running it in a VM, or whatever).
Yet I go to nixos.org, click "Learn" (let's assume I'm the supposed "non technical user") click "install nix".
And what we see is two lines of shell that seems to be starting some kind of daemon. I just ran that locally, and it even states, it's going to move things around and start a daemon:
- set up the "default profile" by creating some Nix-related files in
/root
- back up /etc/bashrc to /etc/bashrc.backup-before-nix
- update /etc/bashrc to include some Nix configuration
- back up /etc/zshrc to /etc/zshrc.backup-before-nix
- update /etc/zshrc to include some Nix configuration
- load and start a service (at /etc/systemd/system/nix-daemon.service
and /etc/systemd/system/nix-daemon.socket) for nix-daemon
is nixos an "OS"? Can I install it on a machine with no pre-existing OS booting from a USB stick? would be great if their docs could explain if nixos is an "OS" or some kind of runtime modification of linux / OSX. (Edit: wikipediaing / googling, it looks like you can in fact install it from an ISO, and that Nix is basically a linux distribution. I guess it has some kind of installer that can "morph" an existing distro into nix? their site should be less cagey about basic details like this).
I think if the NixOS site / docs could do a better job, or any job at all, of answering this question it would make it more clear what exactly it is because I only have a vague idea that it's a package manager that rides on top of existing OSes, which is great, but the site doesn't make it look like that.
The website has decided the best rhetorical approach is to describe what the "ecosystem does for you", and thus not talk that much about Nix vs NixOS vs Nixpkgs up front. But I think that might be mistake. I would lead with:
Nix - package manager / build systems for end-to-end reproducibility at scale.
Nixpkgs - Extremely comprehensive package repository built using Nix.
NixOS - Linux distribution built around Nixpkgs
Home-Manager - doftfile manager built around Nixpkgs
There are other tools, but they are much more niche, so I would start with that. I think that clears up with what you and many others have asked, and doesn't "distract from the sales pitch" too much.
“The NixOS Wiki is a community-run project to document the Nix Ecosystem. NixOS is a Linux distribution which is created with the Nix package manager as its foundation. NixOS relies upon the extensive Nixpkgs package repository, which is one of the largest and most up-to-date package sources in the Linux world. The Nix ecosystem also includes tools like Hydra, for continuous integration testing, and NixOps, for deploying NixOS machines to networks and clouds (e.g. EC2, GCE, and Azure).”
There is some somewhat confusing naming here, and I believe it is the cause of your confusion.
There is a operating system named Nixos. It uses a package manager called Nix. The package manager can be installed in other operating systems. The package manager is configured using a functional language also called Nix.
What you installed was either the package manager, or a interpreter for the language.
in my experience (writing SQLAlchemy) it's good to give all of the "<Brandname>" titles a suffix. That is, instead of having "Nix" and "Nix OS", you would have, "Nix Package Manager" and "Nix OS".
I had *exactly* the same experience with SQLAlchemy. for years and years, it was, "SQLAlchemy" and "SQLAlchemy ORM". The online discussion was always the same: "ORMs, I like ORMs, I dont like ORMs, blah blah blah" and constantly trying to say, "SQLAlchemy has a whole non-ORM part too!" and this was only vaguely received.
Problem was 90% solved by *changing the name*, introducing the new term "SQLAlchemy Core":
SQLAlchemy Core
SQLAlchemy ORM
now when people talk about SQLAlchemy, you will regularly see discussions with "I only use Core, not ORM" or "did you try that with Core?" There are still people who think SQLAlchemy is in its entirety an ORM but it's a vastly thinner slice of less engaged users -the path to understanding the different components is helped enormously by qualifying them all.
It's a bit confusing (and the old site did a better job explaining this), but basically, you have two separate projects: Nix (a package manager/build system) and NixOS (a standalone Linux distribution that uses the Nix package manager).
can i use the nix package manager without using nixos? is that what the "install" link I referred towards is setting up ? my original impression of nix years ago was that oh it's a package manager, maybe like the old BSD packagesource thing, great. but then "NixOS" came in and seemed to confuse things.
all good stuff but wow that website needs to be reorganized.
Yes, I agree it needs to be fixed. I noted this source of confusion earlier and appreciate the confirmation. Will be working on getting a disambiguation header on the main download page soon.
You’re on the right track. Nix is a package manager you can use on just about any Linux distribution, and also MacOS. NixOS is a Linux distro built with and including Nix (and using Nixpkgs as its package repo).
Nix is also the name of the functional programming language created to describe packages in Nix the package manager.
Nix is also a pun on the word meaning “nothing”, which is a nod to how it’s all purely functional.
> can i use the nix package manager without using nixos? is that what the "install" link I referred towards is setting up ? my original impression of nix years ago was that oh it's a package manager, maybe like the old BSD packagesource thing, great. but then "NixOS" came in and seemed to confuse things.
Yes. On the download page[0] you have two sections: Nix (the one you were looking at), and NixOS (which is packaged as a traditional disk image).
I should try to look at the documentation again. But apart from the using the package manager, the rest of the documentation submerged you in a deep theoretical understanding of nix, going deeper and deeper, until the only thing that made sense anymore was the respect you gained from the technies who went further and somehow managed to use nix.
It should be said it is for technical but non-programmer users, "power users".
I don't think it is more scary than dconf-editor or regedit :D.
After this foundation is laid, there's no reason we can't add more "tutorial/wizard" flows, just as Microsoft kept revamping the Windows "control panel" but kept the old version.
What we can't do is simply drop config options like Apple. The Nix ecosystem aspires to be all mechanism minimal policy. If upstream exposes the knob, we ought to somehow expose it, at least via a free-form textual "extraConfig".
>After this foundation is laid, there's no reason we can't add more "tutorial/wizard" flows, just as Microsoft kept revamping the Windows "control panel" but kept the old version.
As usual, those who have learned Nix have completely forgotten what was difficult about it in the first place. And those who haven't are so confused that are unable to ask good questions.
Sounds like a concise description. All Nix people I met say „bro it’s so simple“ while the docs throw around 20 different concepts, multiple of which seem to be the same thing, but not really, but really you may want X in case you want to do Y but sometimes not except usually you do but well actually it’ll be replaced in a few months (...)
Hey, just go through this 20-page tutorial series and by the end you may be able to transfer that experience to that one ruby package with a particular native dependency you just want to build right now.
Another aspect is that the Nix experience varies widely between languages, in part because of different levels of support for different languages but also because different languages’ build and runtime systems vary with respect to how easily they map to Nix. So your friend who heartily recommends Nix might have had a decent experience with his Haskell projects, but you and I working in the trenches with Python or Ruby are having a miserable time and everyone who told us Nix was great just kind of shrugs and chuckles as they tell us they don’t know how to solve our problems with Nix.
nix is awesome and would make a great addition to windows and mac as well, if we all standardize on something like this, we could have more reproducible computing environments across dev, prod, and fun. also improves security a lot due to software supply chain management w/ immutable builds, and could make rebuilds + updates far easier and faster
it's a bit esoteric though, the syntax and docs can both improve a lot.
my dream machine is qubes host running nixos guests but that's a lot to set up and learn!
This will sound rude, but I'm more and more convinced that people immersed in nix have never seen a real person in real life.
defined boolean expression reference true.
wat.
I'm a technical person, and I have no idea what this is. And for technical people? Literally everyone says that "nix is really hard to get started with".
nix and nix-related developers, please, please find some real people and talk to them.
I'm a nix fan and have been using nixos for years now, packaging stuff and writing my own nix-based libraries, but I still find the language to be painful.
The problem is, documentation is sparse to non-existant, error messages are poor and often far from the actual problem, and it makes use of concept that lots of people are not familiar with (like lazy evaluation) without ever explaining them, resulting in surprising semantics.
But as far as I can tell, the nix devs are fully aware of these issues - they are affected by it too! The problem is, solving each of those issues is hard, and requires a lot of focused efforts.
> The problem is, documentation is sparse to non-existant, error messages are poor and often far from the actual problem, and it makes use of concept that lots of people are not familiar with (like lazy evaluation) without ever explaining them, resulting in surprising semantics.
Absolutely, that is the major roadblock for Nix/OS in my opinion, with the new `nix` command, the documentation is way better but the language and OS documentation is still bad, if you search for something on a search engine, the top result will probably be the NixOS Wiki which is not even official! Manuals can come up but the title for the nix manual (not NixOS) is "NixOS - Nix 2.3.15 Manual" which is confusing by itself but even more so when you're trying to solve a specific problem and not just get the manual. Having the "NixOS" part at the end for example would already help. Having titles for different parts of the manuals would be best. However, manuals are single pages except for the new nix command manual.
That is a truly horrible user experience in my opinion...
NixOS is however very good in other areas so the experience is positive in general but if resolution of issues could be faster, it would help significantly. My guess is that they will push towards the new manual format, so this will get resolved eventually but it will probably take a long time.
They are also probably not aware of certain issues like the fact that having no roadmap is not great for end users or contributors and doesn't create this focused effort that is required to solve the issues mentioned. Nix devs seem to be a bit too technical which is becoming a problem. If you guix to nix, they are much more organized, if you go to their homepage and want to contribute, it is very clear where you can contribute and how.
Another example would be flakes. They created quite a hard split in the community between people that are using them and people that are not. They have some problems sure, but I think they should become standard and then be iterated upon.
To summarize, the Nix/OS project feels to me like it is still treated like a research project with no users and few contributors which is not the case.
> The problem is, documentation is sparse to non-existant, error messages are poor and often far from the actual problem, and it makes use of concept that lots of people are not familiar with (like lazy evaluation) without ever explaining them, resulting in surprising semantics.
I used NixOS and Home-Manager to run my entire system and home directory for a couple weeks earlier this year. The lack of clear documentation made me leave. Most of the time to find relevant information I'd have to go in some chat room since often the "official" documentation would be outdated. If the documentation was better I'd probably still be on it.
Autogenerated documentation !== up-to-date and/or good documentation.
Autogenerated means "we take these particular strings and texts and dump them in a different format". It says nothing about whether they are even remotely up to date.
Sure, but in my experience the documentation from the source has always been correct. There is tons of stuff on other websites that is outdated, but the source documentation has not suffered the same atrophy.
More importantly, much of the documentation is auto generated not from arbitrary doc strings, but from the nix expressions themselves. IE: https://search.nixos.org/options?
So I believe there was another source of the misinformation then the official docs.
Most probably NixOS Wiki, it's not official but always comes up as the top result because the manual's titles are irrelevent when you're trying to solve a specific issue. The NixOS Wiki is very helpful in a lot of ways (there is more info than in the manuals and you don't have to troubleshoot for hours because you missed activating some options), butit is true that it is sometimes outdated :/
Too that I say look at react hooks. Somehow the React devs managed to introduce functional concepts into a framework without anyone knowing why or how this black magic trick works. At the time of introduction I was heavily interested in functional approaches, mainly the solutions from Haskell. And now nobody gives a a damn how hooks works in JS only that they make the coding somewhat easier and nicer. (I‘m no JS developer and how no real world view at the current stage anymore).
Regarding nix. I love the idea and the project. Tried it 3 times with various issues which stopped me from using it (last time I was not able to compile a rust program because of some weird c runtime library which was pulled with the wrong version from wherever by whoever). My second bigger issue with nix is the fact that you have to go all the way or it makes no real sense. Mixing nix with Ubuntu or base arch is of course possible. But the developing python or whatever whichever means to install and manage the whole toolchain and project dependencies also with nix. I still check the project every now and then.
nix has been around for 18 years. If the documentation is still sparse after all these years, it's not a problem that will be fixed, ever. Same for explaining concepts.
Proper errors are a huge and poorly understood problem, so I'm inclined not to judge those too harshly.
I don't think it is fair to judge a project for the number of years its been around, specially for something that is really novel and innovative. Nix/NixOS is not a new web framework that most of concepts are really clear for everyone working with Web. It is a brand new concept for Operating Systems, however most people don't have a clue about system immutability and reproducibility and why this is so hard.
Of course, this doesn't excuse the state of the documentation that should be better. It is just that nobody ever documented this kinda of things before, so it is difficult to do it better.
Nix and NixOS just started to get more known and become popular from the last ~5 years or so, and I think this made the whole community aware that documentation is an issue and it is getting better and better (but maybe not at the pace most people wanted).
You probably don't have a problem that this solves.
I.e., some people still download random zipfiles from the internet and install each individual app from a wizard dialog onto their Windows 10 machine. They find software repositories and package managers confusing and overengineered. I guess that's okay.
I don't find package managers confusing but I do, in fact, find them overengineered. They solve at most 75% of application management problems with the fallback for the other 25% being "compile it from source yourself" and it takes an army of unpaid third party maintainers to pull that off.
In my current estimation, Nix just solves an additional 5% at the cost of exponentially more overengineering.
If you think the words software repository and package manager are esoteric technical jargon then you don't need nix, which is completely fine. But it allows developers to identically reproduce builds of a software which depends on other software packages. Other package managers may depend on some global variables of your system, which nix avoids.
That's like asking "what problem does apt-get solve, exactly, with its technical jargon, when I can always download the software I want using Google Chrome?"
Honestly, that's so patronising I wonder if you are trolling?
I use Debian and Redhat happily, also do plenty of Docker. I really want to love Nix and have tried a few times (even submitting some package updates), but just kept bouncing off it and giving up.
Good for you. That means you haven't encountered a problem that Nix is designed to solve.
(Nix is very much a "worse is better" tool in the tradition of hacking something together out of existing tools until you a minimal working product. It's designed to solve a particular class of problems quickly and painlessly, even if the end result isn't "clean" or "elegant". The "clean" and "elegant" solutions to these problems are vastly more complex and overengineered.)
I believe I have a problem Nix is designed to solve (reproducible builds) all the time. However, one can work around it with enough pain and suffering on Ubuntu (I can write a shell script to download and build the specific GCC, GHC, rustc and other packages I need and build from source where required), and still find that much easier to distribute to my colleagues, rather than having to teach them to use Nix.
What else is Nix good for? I'd be interested to know.
Nix allows you to abstract over your shell scripts. Like pack those fuckers in a derivation and now people can install them with Nix in a uniform way (and compose them with their own packages) instead of manually shell scripting.
You can even use a single overlay to add a namespace to your company's nixpkgs, which will then allow your colleagues to discover all the versions of all those tools with nix repl
> pkgs.CJefferson.ghc<TAB>
and boom! All the GHC versions you've worked hard to package across branches and repos etc will be at their fingertips.
As is always the case with FP, composition and abstraction is the big longterm win with Nix. No other comparable tool comes close on those axes.
>They find software repositories and package managers confusing and overengineered.
And that's why big distros have created GUIs (e.g. Ubuntu's software center) that truly hide any technicalities. Nix-GUI, as it's now, will instead be more like Synaptic, it kinda makes life easier but you still require technical knowledge to use it.
I'm using it for some internal systems at work and I feel there's nothing like it.
NixOS gives a level of reproducability that other tools like Ansible won't ever be able to give you.
This reproducability means it makes debugging problems very easy: E.g. uncomment a line in the config and see if something starts working again. You can nearly undo everything cleanly in NixOS by just doing that.
On the other hand the learning curve really is pretty steep. Took me about half a year to get to a point where I understood it enough to be able to debug most errors.
Yeah. We've used it on servers. It's good in a small setting where a handful of Nix experts can run the infrastructure show.
Getting it to scale to an organisation of hundreds wasn't feasible. As soon as we needed to start expanding "infrastructure" beyond just one team, and rapidly hiring new engineers in the context of rapid growth. Training and learning curve was intractable. And we cannot just easily hire NixOS experts like traditional Ubuntu OS.
Nix made complicated things possible but simple things complicated. Pretty much every new feature request could only be processed by a handful of Nix experts, and it was obvious that wouldn't scale with the growth of the company.
Frankly, Nix solves problems that the industry has already solved or knows how to live. Its lack of adoption from software vendors makes the economical cost/benefit unatractive.
> Frankly, Nix solves problems that the industry has already solved or knows how to live
Agreed. Nix solves really important problems, but the problems it introduces tend to be worse. My instinct is that Nix is on the right path, but there doesn’t seem to be much awareness or concern for tackling these problems. Of course, this is the contributors’ prerogative—if they’re really just interested in making Nix work for the existing Nix community (rather than broadening it into the world of mainstream software development and operations), then that’s all well and good. But if they want to appeal broadly they need to make some significant changes.
Yes. I know Shopify does (or at least did), I believe Target was a relatively early adopter. I think Tailscale dabbled with the idea.
Everything feels quite stable from a server admin perspective, though there are still various competing methods to actually administer fleets of machines. Nix Ops is a bit opinionated but works okay. I just build locally or in CI and push to hosts remotely.
FWIW Shopify used nix-shell for the developer environment. If all they need to do is import standard packages - it's actually quiet a good solution for multi-platform dev environments.
I would say it's more convenient and useful for servers, but it could also be used for desktop. In theory it's the perfect server operating system, but in practice many sysadmins balk at having to learn the configuration language which has some design flaws that make it awkward and they stick with old fashioned stuff like Ansible.
The point is: currently my NixOS and Home Manager configurations have over 2k LOC total. When you search for configurations on GitHub/Google you are likely to find complex ones. For example, quick search for "nixos gnome" (Google) gives me link to NixOS Wiki (which describes only Gnome part) and blog post (https://gvolpe.com/blog/gnome3-on-nixos/) which is useful but links to really huge configuration (https://github.com/gvolpe/nix-config) that is overwhelming to any beginner.
Great example of such approach is nixos-hardware (https://github.com/NixOS/nixos-hardware) which provides one-line configuration covering hardware quirks.