Nix-GUI: Make NixOS usable for non-technical users through settings / GUI
github.com
github.com
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.
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
https://nixos.wiki/wiki/Comparison_of_NixOS_setups
This is the other big one (most stars): https://github.com/hlissner/dotfiles
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.
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.
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.
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.
You can have a peek here: https://nixos.org/manual/nix/unstable/command-ref/experiment...
Using scheme for everything is great, for showcase and recent developments check this video on guix home https://www.youtube.com/watch?v=R5cdtSfTpE0
https://gitlab.com/nonguix/nonguix
More if you google “GUIX nonfree”.
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.
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.
Time to try it again.
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 think the biggest difficulty most people have is that it's a pure functional language, and that is quite foreign to a lot of people, even many SWEs.
It's something that's not going to change though because it's a fundamental part of why Nix works so well.
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.
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.
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
some_function( eval_file( "./my-package.foolang" ) )
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:
https://discourse.nixos.org/t/nickel-the-nix-language-spin-o...
Better than so many I use professionally
Having the option to say "fuck it" and just reinstall everything, without worrying about manually installing exact software versions and reconfiguring everything sounds amazing.
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).
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).
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).
I've only ever noticed one difference: installing the bootloader only happens on nixos-install, not always on nixos-rebuild
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.
It’s not competing, it’s complementing. Think of it as a fully deterministic “docker build”.
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.
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.
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..
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.
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.
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.
You absolutely can build docker images using Nix via dockerTools.buildImage [0].
[0]: https://nix.dev/tutorials/building-and-running-docker-images
Docker's features usually include "its easier to create and maintain a system".
That Nix does this different and better doesn't matter when a user is just looking to solve that one problem.
At that moment, for that user, Nix is just a fancy config manager with one click deploy features and competing with docker.
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.
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 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"?
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.
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.
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.
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.
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.
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.
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.
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.
I also replaced Buildroot with it for building embedded images for SBCs. Lifechanging experience.
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.
At the end of the day, I much prefer trusting upstream than having to trust packagers to do everything right.
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.
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.
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.
- 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.
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.
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! :)).
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.
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.
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 can see the value of it, if I ever learn Nix, and want a quick way to make modifications without having to google every possibilities.
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.
^ 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...
This config is for a different layer - one a non-technical user probably wouldn't ever modify in most OSes. Hence, the value.
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.
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.
Also, if you've used Nix-Gui, please consider filling out the UX Survey: https://github.com/nix-gui/nix-gui/issues/129
[0] https://github.com/nix-gui/nix-gui/issues/77 [1] https://github.com/nix-gui/nix-gui/issues/21
" 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."
NVIDIA works great, but if I were to buy new hardware I'd go AMD (maybe Intel when the time comes)
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)
When I moved to NixOS I just did a normal NixOS install and applied the same parameters to kernel boot as before and passed the GPU through.
I was using looking-glass at first, but my computer is too slow and crappy (memory bandwidth seems to choke) to run 144fps in overwatch.
You just pass the entire block device into the VM if you wanna keep your setup, or pass it through with as PCIE if it's an NVMe device.
I thought it'd be hard, but you'll be up and running in a day
https://www.youtube.com/watch?v=voXc1nCD4IA
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.
IIRC, Vagrant was geared for just project isolation, and didn't offer the optimum VM management experience.
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.
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.
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.
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.
[3]: if you're interested on this approach, I used this guide when started: https://forum.level1techs.com/t/nixos-vfio-pcie-passthrough/.... To get it fully reproducible it though, there is no way on NixOS itself yet, however there is a good guide here: https://nixos.wiki/wiki/NixOps/Virtualization#Setting_Up_the...
> 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.
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
];
}
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):
{ pkgs, ... }:
{
environment.systemPackages = with pkgs; [
gcc
python39
lua
];
}
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 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.
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.
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.
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.
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.
(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.)
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.
all good stuff but wow that website needs to be reorganized.
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).
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.
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.
They could've named these things better IMO
I wonder if adoption of these otherwise awesome projects would improve if they did a better job with communication?
What is confusing however, is that the configuration language and the package manager have the same name, Nix.
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.
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).”Nix-GUI: Make NixOS usable for technical users through settings / GUI
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".
Well put, this is exactly the goal. https://github.com/nix-gui/nix-gui/issues/77
Dev has made a great implementation for people who fear the terminal. Thanks to this now i can bring more of my friends to try tools like these.
I dont think the creator is delusional at all, The non-technical in this market is just different.
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!
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.
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.
Proper errors are a huge and poorly understood problem, so I'm inclined not to judge those too harshly.
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).
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 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.
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.
[1]: https://nixos.org/guides/nix-pills/enter-environment.html
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.
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.
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.
> They find software repositories and package managers confusing and overengineered.
The screenshot is literally a mishmash of technical jargon with little to no relation to each other.
sound.enable defined boolean asset resource enabled.
What problem does it solve, exactly?
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.
In my current estimation, Nix just solves an additional 5% at the cost of exponentially more overengineering.
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.
(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.)
What else is Nix good for? I'd be interested to know.
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>
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.
“Defined” means the configuration is set, as opposed to unset or undefined
“Boolean” is a type, so the setting can be either true or false
“Expression” is the value of the setting, in this case true
“Reference” is a button that opens up the documentation for this particular setting
If you keep telling yourself nix is hard then it will be hard
I get the impression it's more used on desktop, but I'm curious if anyone has used it on servers?
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.
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.
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.
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.