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.
" 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."