NixOS 22.11 “Raccoon”(nixos.org)
nixos.org
NixOS 22.11 “Raccoon”
https://nixos.org/blog/announcements
200 comments
Agreed. When I'm selling Nix to other Linux users, instead of getting lost in an explanation of deterministic package versions, I tell them system upgrades are atomic: you either enter the new environment or you don't. Either way you're in a consistent state. If for some reason there's difficulty booting, you can always go back to the previous system state from the boot menu. Mostly Debian and Gentoo users have nibbled on this bait. Arch users less so. YMMV
It's even better than reverting the whole system because you can still run an executable from the old system in the new system. Once, I found out that video had stopped working for me in Zoom but because I hadn't used it in a while there had been multiple system updates since then. I was able to bisect through the previous system profiles and find the most recent version that still had working video. I used this for a month or so until the bug was fixed in the current version.
I always forget to explain that. Atomic updates are one of the best if not the best feature of nixos.
How about isolation, how do you manage that? Are services ran under different containers, VMs or namespaces?
No.
A main reason people use containerisation is to work around the problem that different versions of libraries and binaries cannot coexist in classical Linux distributions. This problem does not exist in NixOS.
The services are declared as NixOS modules, which manifest as plain systemd services on the server.
Systemd has its own set of options for resource/security isolation, and some NixOS modules use them where possible, for example: https://github.com/NixOS/nixpkgs/blob/8d559672bedd54034b711d...
A main reason people use containerisation is to work around the problem that different versions of libraries and binaries cannot coexist in classical Linux distributions. This problem does not exist in NixOS.
The services are declared as NixOS modules, which manifest as plain systemd services on the server.
Systemd has its own set of options for resource/security isolation, and some NixOS modules use them where possible, for example: https://github.com/NixOS/nixpkgs/blob/8d559672bedd54034b711d...
My router (a VM with passed through network card) is currently running on NixOS, I’m really happy so far, it makes kernel patching (which in my case is required for the nic to work properly at 2500BASE-T) much easier than manually patching and building the kernel every time. It also gives me the guarantee that I will be able to rebuild the exact same host almost bit by bit in the future, in case of necessity, which is important for something like a router (I also take vm snapshots but upgrades are crucial for something potentially facing the internet and handling firewall). Looking forward to move away from proxmox to a fully NixOS virtualisation host too.
Yeah I used to use pfSense but hated having a load of config and firewall rules created manually, it all felt quite brittle.
Moved to NixOS almost 5 years ago now and haven’t looked back, my router config is in Git and I’m able to make changes with confidence.
Best part is making a change/installing an update and being able to rollback if I mess something up. I also use Nixus to push new configs which has a nifty feature where it will autorollback if you e.g make a config change that locks you out of SSH.
I also moved from ESXI to NixOS for a virtualisation host more recently and that has been great as these machines are inherently long lived so you can’t apply the “cattle not pets” mindset here, but I feel like I can make changes and install updates with confidence. It also helped when I migrated to a Threadripper build where there were some strange quirks which needed Linux kernel patches, it’s nice being able to do this declaratively and to store everything in a versioned Git repo.
Moved to NixOS almost 5 years ago now and haven’t looked back, my router config is in Git and I’m able to make changes with confidence.
Best part is making a change/installing an update and being able to rollback if I mess something up. I also use Nixus to push new configs which has a nifty feature where it will autorollback if you e.g make a config change that locks you out of SSH.
I also moved from ESXI to NixOS for a virtualisation host more recently and that has been great as these machines are inherently long lived so you can’t apply the “cattle not pets” mindset here, but I feel like I can make changes and install updates with confidence. It also helped when I migrated to a Threadripper build where there were some strange quirks which needed Linux kernel patches, it’s nice being able to do this declaratively and to store everything in a versioned Git repo.
How are you managing the VM’s on NixOS?
A couple years ago I was searching for a good way to declaratively manage them, and the best I came up with was libvirt + terraform + nixos-generators for images. It feels like you should just be able to set them up as systemd units, but I couldn’t figure it out.
microvm has caught my eye recently but I haven’t played with it yet: https://github.com/astro/microvm.nix
A couple years ago I was searching for a good way to declaratively manage them, and the best I came up with was libvirt + terraform + nixos-generators for images. It feels like you should just be able to set them up as systemd units, but I couldn’t figure it out.
microvm has caught my eye recently but I haven’t played with it yet: https://github.com/astro/microvm.nix
Not OP (and I suspect they don’t have what you’re looking for since they have stated they treat the VMs as pets, not cattle). I currently use libvirt, but I eschew persistent VMs and instead build the libvirt domain XML with Nix, and then start VMs with `virsh create /path/to/myvm.xml`. Using an absolute path means that libvirt will not persist the domain, and makes it easier to declaratively manage the config with Nix.
However, none of my VMs are always-on, so I don’t have to deal with restarts on config change. That said, when libvirt isn’t managing the lifecycle of the VMs as much, writing a systemd unit should be quite a bit easier.
However, none of my VMs are always-on, so I don’t have to deal with restarts on config change. That said, when libvirt isn’t managing the lifecycle of the VMs as much, writing a systemd unit should be quite a bit easier.
The VMs themselves are a mix of some manually created ones (the VM configs are still NixOS though), and some IaC VMs which I just use Terraform and the libvirt provider. It's a bit clunky but I wouldn't want to embed the VM config in the hypervisor configuration as the VMs can be live migrated to other hypervisors.
MicroVM looks awesome though, thanks for the pointer!
MicroVM looks awesome though, thanks for the pointer!
Did you manage to get live migration working with the terraform provider? As of a while ago it wasn’t implemented but idk if that’s changed:
https://github.com/dmacvicar/terraform-provider-libvirt/issu...
I appreciate your comment here, and the parent comment.
I've been using OPNSense[0] as my router for the past several months. So far, I am quite happy with it, but I've also thought that NixOS would be the next step.
My OPNSense router has 30+ VLANs and many layered firewall rules (my take on "zEr0 tRuSt") and so the task of converting it all to NixOS seems a little daunting.
I appreciate the utility of OPNSense's web GUI when configuring and troubleshooting my router config. It would be awesome if something like that could be integrated with NixOS. Additionally, something like nsh[1] to provide a traditional router/switch style CLI would be a dream come true.
[0] https://opnsense.org/
[1] https://www.nmedia.net/nsh/
I've been using OPNSense[0] as my router for the past several months. So far, I am quite happy with it, but I've also thought that NixOS would be the next step.
My OPNSense router has 30+ VLANs and many layered firewall rules (my take on "zEr0 tRuSt") and so the task of converting it all to NixOS seems a little daunting.
I appreciate the utility of OPNSense's web GUI when configuring and troubleshooting my router config. It would be awesome if something like that could be integrated with NixOS. Additionally, something like nsh[1] to provide a traditional router/switch style CLI would be a dream come true.
[0] https://opnsense.org/
[1] https://www.nmedia.net/nsh/
NixOS is great for a basic home router (I use it for my home router) but it’s networking config is still pretty rudimentary, and some things I would expect to work just don’t - i.e. port forwarding only works from outside your network, not inside.
I haven’t done much with vlans yet so I can’t comment on that.
I haven’t done much with vlans yet so I can’t comment on that.
This has more to do with iptables/nftables I think. I solved this by adding my port forwarding rules to the prerouting chain and the output chain. You can use a jump to consolidate the rules, like so - https://gist.github.com/madjam002/d30f6000adf0761e92623f7de2...
As other commentators have said, switching to systemd networkd has allowed for more advanced network configurations than I ever managed with pfSense. IPv6 works pretty much out of the box with my ISP which uses DHCP prefix delegation, I can assign /64's to different VLAN networks, and more recently I set up network prefix translation (I think that's what it's called) for my lab kubernetes cluster so each pod gets a unique IPv6 address in the RFC 4193 range which maps to my actual ISP provided IPv6 prefix, so if I change ISP the IPs in the cluster would remain the same. Being able to expose Kubernetes services directly to the internet with unique IPv6 addresses is pretty nice :)
As other commentators have said, switching to systemd networkd has allowed for more advanced network configurations than I ever managed with pfSense. IPv6 works pretty much out of the box with my ISP which uses DHCP prefix delegation, I can assign /64's to different VLAN networks, and more recently I set up network prefix translation (I think that's what it's called) for my lab kubernetes cluster so each pod gets a unique IPv6 address in the RFC 4193 range which maps to my actual ISP provided IPv6 prefix, so if I change ISP the IPs in the cluster would remain the same. Being able to expose Kubernetes services directly to the internet with unique IPv6 addresses is pretty nice :)
I would highly recommend to use systemd-networkd based networking which should be able to do almost everything if configured correct.
Is there a nix config wrapper for systemd-networkd?
NixOS still does everything I need it too, but the parent comment sounded like they had a bit more complex of a setup.
NixOS still does everything I need it too, but the parent comment sounded like they had a bit more complex of a setup.
Not sure what you mean by config wrapper, but yes, systems-networkd is quite nice. Here's my home router setup with vlan1 for uplink to ISP, a bunch of other vlans for internal networks, and IPv6 prefix delegation to internal networks, and of course fireguard. All configured using systemd-networkd:
{ pkgs, lib, ... }:{
{ pkgs, lib, ... }:{
networking = {
useNetworkd = true;
useDHCP = false;
enableIPv6 = true;
};
networking.wireguard.interfaces = {
wireguard = {
ips = [ "172.20.60.1/24" ];
listenPort = 61891;
privateKeyFile = "/etc/nixos/secrets/wireguard-privateKey";
peers = [
{
publicKey = "897mRPejuv9yVnmTvcUL7ckQkIiM0wnSgHmgR15Evyw=";
allowedIPs = [ "172.20.60.10/32" ];
presharedKeyFile = "/etc/nixos/secrets/wireguard-presharedkey";
} systemd.network.networks = {
"10-eno1" = {
matchConfig.Name = "eno1";
networkConfig.LinkLocalAddressing = "no";
networkConfig.DHCP = "no";
extraConfig = ''
VLAN=wan
VLAN=vlan99
VLAN=vlan30
VLAN=vlan20
VLAN=vlan1
VLAN=podnet
LLDP=no
EmitLLDP=no
IPv6AcceptRA=no
IPv6SendRA=no
'';
};
"11-vlan1" = {
matchConfig.Name = "vlan1";
linkConfig.RequiredForOnline = false;
networkConfig.DHCP = "no";
networkConfig.Address = "192.168.1.1/24";
networkConfig.Domains = "tanso.net";
networkConfig.ConfigureWithoutCarrier = "yes";
};
"11-podnet" = {
matchConfig.Name = "podnet";
linkConfig.RequiredForOnline = false;
networkConfig.DHCP = "no";
networkConfig.Address = "172.20.2.1/24";
networkConfig.Domains = "tanso.net";
networkConfig.ConfigureWithoutCarrier = "yes";
};
"11-vlan20" = {
matchConfig.Name = "vlan20";
networkConfig.DHCP = "no";
networkConfig.Address = "172.20.20.1/24";
networkConfig.Domains = "tanso.net";
networkConfig.ConfigureWithoutCarrier = "yes";
extraConfig = ''
IPv6SendRA=yes
DHCPv6PrefixDelegation=yes
'';
};
systemd.network.netdevs = {
"11-vlan1" = {
netdevConfig = { Name = "vlan1"; Kind = "vlan"; };
vlanConfig.Id = 1;
};
"11-podnet" = {
netdevConfig = { Name = "podnet"; Kind = "vlan"; };
vlanConfig.Id = 2;
};
"11-vlan20" = {
netdevConfig = { Name = "vlan20"; Kind = "vlan"; };
vlanConfig.Id = 20;
};
"11-vlan30" = {
netdevConfig = { Name = "vlan30"; Kind = "vlan"; };
vlanConfig.Id = 30;
};> Is there a nix config wrapper for systemd-networkd?
The options under systemd.network almost map 1:1 to systemd-networkd ones.
The options under systemd.network almost map 1:1 to systemd-networkd ones.
Port forwarding not working from inside the gateway sounds like it’s not doing hairpin NAT by default. I’m running a NixOS home router pair, not currently doing any port forwarding but now I’ll have to check that tonight, if nothing else people might appreciate an option for it.
Wow, didn’t know about Nixus, thanks!
Can you share your router configs? I'd love to have a NixOS based router.
One drawback I realized about NixOS as a router for home use is that if you need to share administration of the network, then it has to be easy for non-experts. In that case something like OpenWRT might be a better choice.
Well, at least the config file options are relatively straightforward, but you're right in that a GUI makes more sense for genpop
Did you base your router config on some existing template or did you just built it up from scratch?
I based much of the configuration on [1] but I took the nftables rules from the official nftables wiki.
[1] https://francis.begyn.be/blog/nixos-home-router
[1] https://francis.begyn.be/blog/nixos-home-router
My experience with NixOS: Package installation is usually just from the official channel, system options can usually be done with `/etc/nixos/configuration.nix` and home-manager.
Major problems: installing niche proprietary software that you may have to package yourself, and fighting Nix for languages with package manager, e.g. Python, which frequently uses packages not in nixpkgs.
Major problems: installing niche proprietary software that you may have to package yourself, and fighting Nix for languages with package manager, e.g. Python, which frequently uses packages not in nixpkgs.
I wouldn't call them major problems. There are workarounds for running things without much effort if you want, e.g. FHS or steam run or distro box. For Python, you can create a virtual env and use it like any other machine.
And if you do put in the effort to make a package, you'll never have problems figuring out how to install it in the future, and can share that gain with others.
Making packages for nix is way easier than making debs or rpms in my experience.
And if you do put in the effort to make a package, you'll never have problems figuring out how to install it in the future, and can share that gain with others.
Making packages for nix is way easier than making debs or rpms in my experience.
Some packages won't work when installed via pip though, psycopg2 for instance.
Occasionally you can get packages with native dependencies to work by creating a nix shell that includes the dependent libraries. Sometimes that can mean using an FHS shell, which is indeed annoying.
It’s not elegant, but you can also usually find popular Python libraries in nixpkgs so they’re available in your shell’s “global” Python environment.
It’s not elegant, but you can also usually find popular Python libraries in nixpkgs so they’re available in your shell’s “global” Python environment.
nixpkgs is already one of the largest package collections. There is a good chance your software is already included.
The nix language itself is pretty straightforward and if you know haskell your should feel straight at home.
You shouldn't use nixpkgs python packages as a replacement for your python development. That would also not work that great on other distros.
The nix language itself is pretty straightforward and if you know haskell your should feel straight at home.
You shouldn't use nixpkgs python packages as a replacement for your python development. That would also not work that great on other distros.
I think there are a few problems here:
1. Packaging requires knowing more than just the language, you should also know how files are being linked, what to look for when you got an error. If you only know haskell, you may not know this.
2. If you wrote the correct script, it just works. But if you wrote something wrong but syntactically correct, finding the issue may not be that trivial, in my experience the trace is not very useful.
3. Not sure where the documentation for helper functions is. I think there are unofficial documentation out there but iirc it is not in the nix reference manual?
4. Some python packages with system dependencies will not work when installed through virtual environment. I haven't done serious python development for a long time so I forgot what I usually do to fix it, but I think I just packaged everything in Nix.
5. Some build tools without wrapper (iirc mold, ldd) will cause loader error.
But yeah, I do agree that packaging is not that hard, just require a bit more thoughts than just using typical build instructions and `make install`, and perhaps look at the binaries with ldd.
1. Packaging requires knowing more than just the language, you should also know how files are being linked, what to look for when you got an error. If you only know haskell, you may not know this.
2. If you wrote the correct script, it just works. But if you wrote something wrong but syntactically correct, finding the issue may not be that trivial, in my experience the trace is not very useful.
3. Not sure where the documentation for helper functions is. I think there are unofficial documentation out there but iirc it is not in the nix reference manual?
4. Some python packages with system dependencies will not work when installed through virtual environment. I haven't done serious python development for a long time so I forgot what I usually do to fix it, but I think I just packaged everything in Nix.
5. Some build tools without wrapper (iirc mold, ldd) will cause loader error.
But yeah, I do agree that packaging is not that hard, just require a bit more thoughts than just using typical build instructions and `make install`, and perhaps look at the binaries with ldd.
1. Yes, you need to know some more things but in particular not linking. I have no idea about linking or what to do when it fails with weird symbol errors. If you have a standard autotools, cmake or meson setup it might be as easy as just adding the packages to nativeBuildInputs and it works. The more custom stuff the project does the more you need to hold it hands.
3. For example here https://nixos.org/manual/nixpkgs/unstable/#chap-hooks
5. It is quite the opposite. If the typical build instructions are ./configure; make; make install then you might only need to specify the install directory to $out and you are done. Looking at ldd is also not usually required when compiling from source.
3. For example here https://nixos.org/manual/nixpkgs/unstable/#chap-hooks
5. It is quite the opposite. If the typical build instructions are ./configure; make; make install then you might only need to specify the install directory to $out and you are done. Looking at ldd is also not usually required when compiling from source.
FYI this comment ended up making something work that I couldn't get working (as a side project) for at least 2 months; I did not realize that providing certain things as nativeBuildInputs might make package sub-dependencies build correctly (so for example, I have an Elixir project which depends on a NIF which is a compiled C++ or Rust project which is automatically built when I build the main Elixir project). Moving those to that suddenly made it work!
So thank you for that! There's not a lot of docs I found out there (yet?) about getting sub- or sub-sub-dependencies to build correctly in multi-layered projects that depend on different language technologies and build toolchains (where a traditional linux distro makes A LOT of assumptions that "just so happen" to work!), but at least now that I got this working, I can lock it down with a flake and in theory be good to go for a while! (or at least have a rollback strategy if something borks!)
So thank you for that! There's not a lot of docs I found out there (yet?) about getting sub- or sub-sub-dependencies to build correctly in multi-layered projects that depend on different language technologies and build toolchains (where a traditional linux distro makes A LOT of assumptions that "just so happen" to work!), but at least now that I got this working, I can lock it down with a flake and in theory be good to go for a while! (or at least have a rollback strategy if something borks!)
It would be nice if you could just install python packages with pip in a venv and ignore nixpkgs python packages, but then some things like e.g. pyqt5 actually have some extra dependencies on system libraries, so you pretty much need the nixpkgs version to get it to run https://nixos.wiki/wiki/Packaging/Quirks_and_Caveats#ImportE... and if you want to keep using the venv for the other packages (e.g. because they aren't in nixpkgs) you might try initializing with "python3 -m venv --system-site-packages" to make the nixpkgs pyqt5 visible in the venv, but for some reason venv/bin/python3 ends up pointing to the wrong python, so I currently resort to "ln -s $(readlink -e $(which python3)) venv/bin/python3" ...
If there's some easier way, I'm eager to hear about it.
If there's some easier way, I'm eager to hear about it.
> nixpkgs is already one of the largest package collections. There is a good chance your software is already included.
Yes, but that still doesn't solve this:
> Major problems: installing niche proprietary software that you may have to package yourself
If some software _isn't_ packaged, it's a pain in the butt to get it running on NixOS. Either you have to create Nix derivations, which have a pretty steep learning curve, or you have to do some hackery patchelf business, which also isn't easy.
At least, as of 2018, when I last tried. Things could be better now.
Yes, but that still doesn't solve this:
> Major problems: installing niche proprietary software that you may have to package yourself
If some software _isn't_ packaged, it's a pain in the butt to get it running on NixOS. Either you have to create Nix derivations, which have a pretty steep learning curve, or you have to do some hackery patchelf business, which also isn't easy.
At least, as of 2018, when I last tried. Things could be better now.
I run NixOS, but I'm relatively new to Nix. A couple weeks ago I was trying to get an old vanity key generator to build because it wasn't on nixpkgs (vanitygen++) and on a lark I decided to write my own derivation using some examples of similar C++ packages I found and figuring out what nix packages it needed to build. So I did, and the maintainer accepted the PR: https://github.com/10gic/vanitygen-plusplus/commit/7bcee06f3... Note that I am not a C++ developer and only know the basics about how to get C/C++ things to build.
So what does this get us? In theory, this is now trivially-buildable on any distro that has nix installed, or on nixos. I haven't converted it to a flake yet (still learning that) but if I (or someone else) did, it would be deterministically reproducible anywhere on nix.
I agree that there's a learning curve on figuring out the "recipe" for a thing, but once someone does that work, it's basically done forever. Which is a promise that no other system can even approach.
And once you figure out a certain amount of it, this moment will come where you realize you want every system you deal with to be Nixified. Like the guy elsewhere in this thread who rebuilt his own router using NixOS and loves it.
Getting new developers up to speed in your shop's dev environment? Completely trivial to do with Nix. Getting a machine back up after a failure? Reinstall NixOS and reapply the config you were using (which is in source control). Upgraded Gnome and some things you need broke? Or updated your GPU driver and now your screen just shows black? Simple... Roll back in the bootloader to a previously-working config, then undo your changes to the config definition.
Have 10 different projects all with different dependencies and version requirements that would normally collide with each other? Trivial, each project has its own default.nix file and Nix can drop you right into that environment while you're working on those projects.
NixOS (and very honorable mention to Guix) are in fact the only ways to run Linux while keeping your sanity intact!
So what does this get us? In theory, this is now trivially-buildable on any distro that has nix installed, or on nixos. I haven't converted it to a flake yet (still learning that) but if I (or someone else) did, it would be deterministically reproducible anywhere on nix.
I agree that there's a learning curve on figuring out the "recipe" for a thing, but once someone does that work, it's basically done forever. Which is a promise that no other system can even approach.
And once you figure out a certain amount of it, this moment will come where you realize you want every system you deal with to be Nixified. Like the guy elsewhere in this thread who rebuilt his own router using NixOS and loves it.
Getting new developers up to speed in your shop's dev environment? Completely trivial to do with Nix. Getting a machine back up after a failure? Reinstall NixOS and reapply the config you were using (which is in source control). Upgraded Gnome and some things you need broke? Or updated your GPU driver and now your screen just shows black? Simple... Roll back in the bootloader to a previously-working config, then undo your changes to the config definition.
Have 10 different projects all with different dependencies and version requirements that would normally collide with each other? Trivial, each project has its own default.nix file and Nix can drop you right into that environment while you're working on those projects.
NixOS (and very honorable mention to Guix) are in fact the only ways to run Linux while keeping your sanity intact!
Would be cool to get new packages like this on nixpkgs.
It's more a story of, you have to do some hackery patchelf business, but creating a Nix derivation helps you do just that.
The unfortunate part is that creating a Nix derivation is no more approachable than the patchelf hackery was in the first place.
The unfortunate part is that creating a Nix derivation is no more approachable than the patchelf hackery was in the first place.
Most of the time you can just use autoPatchElfHook and add the missing libraries to buildInputs. I can't remember when I last looked at patchelf itself.
...and learning that is the hard part.
Creating a basic nix derivation is easy and if you don't want to upstream it you can take all kinds of dirty and impure shortcuts.
You almost never want to invoke patchelf by itself but use some wrapper like autoPatchelfHook, FHS, nix-ld, nix-autobahn, etc.
Since 2018 a lot quite a lot happened. Give it another chance.
You almost never want to invoke patchelf by itself but use some wrapper like autoPatchelfHook, FHS, nix-ld, nix-autobahn, etc.
Since 2018 a lot quite a lot happened. Give it another chance.
It's only way when you know how. It's quite difficult to learn.
> .. if you know haskell ..
And if you don't have any FP background you're just.. out of luck. /s
And if you don't have any FP background you're just.. out of luck. /s
I must admit I got a long way with contributing without knowing much about functional programming. Most things done in mkDerivation especially the basic ones almost abstract the functional and lazy part away.
For niche software, I found steam-run, or distrobox
As for last problem.. Yeah. It is a problem. x.x
As for last problem.. Yeah. It is a problem. x.x
steam-run is just a fat wrapper around bubblewrap fhs. If you want to optimize your system you can easily build a smaller one yourself.
> Major problems
I don't think I agree here. There are plenty of examples of how to package/update/fix anything custom you desire. The learning curve is there, definitely, but this is not major - I do this several times for my own OS and software that utilizes Nix.
I don't think I agree here. There are plenty of examples of how to package/update/fix anything custom you desire. The learning curve is there, definitely, but this is not major - I do this several times for my own OS and software that utilizes Nix.
How long are we going to sit on our hands and pretend flakes aren't the only way forward?
Am I just missing something?
Am I just missing something?
Well they are - but there are a couple of things blocking it from becoming the default. I think the main thing is this PR: https://github.com/NixOS/nix/pull/6530 - Eelco Dolstra gave a talk on this recently as well if you wanna know more: https://www.youtube.com/watch?v=JE-vLFMTXxM
Another thing that comes to mind is the ability to parametrize flakes so that they can be configured from the CLI: https://github.com/NixOS/nix/pull/6583
Another thing that comes to mind is the ability to parametrize flakes so that they can be configured from the CLI: https://github.com/NixOS/nix/pull/6583
I check on that lazy trees PR like twice a week, lol. It's my most anticipated Nix PR for some time now. I imagine I'm not the only one!
I've not bothered with flakes (yet?); mostly because I don't quite understand/appreciate what they're for/add.
They're apparently better than using channels, and env vars like NIX_PATH; but I don't bother with those either.
I just use `fetchgit`/`fetchFromGitHub` with specific commit IDs, and that seems mostly reproducible. I've got Nix repos dating back about 8 years, and the only reason some commits can't be reproduced is due to link rot (mostly GitHub repos being deleted in protest at Microsoft purchasing it). I don't think flakes solve that? (Seems more suitable for something like IPFS)
They're apparently better than using channels, and env vars like NIX_PATH; but I don't bother with those either.
I just use `fetchgit`/`fetchFromGitHub` with specific commit IDs, and that seems mostly reproducible. I've got Nix repos dating back about 8 years, and the only reason some commits can't be reproduced is due to link rot (mostly GitHub repos being deleted in protest at Microsoft purchasing it). I don't think flakes solve that? (Seems more suitable for something like IPFS)
One thing flakes enable is "easily run some other source".
e.g. to run the latest build of Nix from the GitHub repository NixOS/nix on the master branch, it's:
A less contrived example of where this is useful is with Home Manager. Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). -- Whereas with flakes, you can declare Home Manager as an input, so that applying the Home Manager configuration can be done with less effort.
Flakes are like "nix's nix". With nix, you benefit from putting in effort to declare the inputs of some package, and how its outputs are constructed. With nix flakes, you declare where the Nix code you're using comes from.
e.g. to run the latest build of Nix from the GitHub repository NixOS/nix on the master branch, it's:
nix run github:NixOS/nix/master
A less contrived example of where this is useful is with Home Manager. Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). -- Whereas with flakes, you can declare Home Manager as an input, so that applying the Home Manager configuration can be done with less effort.
Flakes are like "nix's nix". With nix, you benefit from putting in effort to declare the inputs of some package, and how its outputs are constructed. With nix flakes, you declare where the Nix code you're using comes from.
> Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS).
From the home manager documentation ( https://nix-community.github.io/home-manager/index.html#sec-... ):
> If instead of using channels you want to run Home Manager from a Git checkout of the repository then you can use the programs.home-manager.path option to specify the absolute path to the repository.
From the home manager documentation ( https://nix-community.github.io/home-manager/index.html#sec-... ):
> If instead of using channels you want to run Home Manager from a Git checkout of the repository then you can use the programs.home-manager.path option to specify the absolute path to the repository.
Neat, though I hope I helped your curiosity regarding why people find flakes useful.
With home-manager, you can declare a flake configuration where home-manager is an input; and then applying the configuration is pretty hands-off since Nix will fetch the appropriate revisions of the inputs.
I think that using flakes is more convenient than the alternatives. (Having to add a channel; or, as you point out, cloning the repository in a consistent path on each system you use & then running that).
With home-manager, you can declare a flake configuration where home-manager is an input; and then applying the configuration is pretty hands-off since Nix will fetch the appropriate revisions of the inputs.
I think that using flakes is more convenient than the alternatives. (Having to add a channel; or, as you point out, cloning the repository in a consistent path on each system you use & then running that).
I'd say the real alternatives are probably the json-based, pre-flakes pinning tools like Niv, nix-wrangle, and nix-thunk.
They're still less convenient for me than flakes because they don't have great integration with Nix's profile managers (nix-env, nixos-rebuild, home-manager). But they do have fewer quirks in some ways, since they don't try to enforce pure evaluation like the flakes implementation does. They don't worry about whether the pinning happens inside a git repo or whatever.
(I think some orgs that use Nix in production are still using Niv, and haven't touched flakes. Niv is certainly still maintained.)
They're still less convenient for me than flakes because they don't have great integration with Nix's profile managers (nix-env, nixos-rebuild, home-manager). But they do have fewer quirks in some ways, since they don't try to enforce pure evaluation like the flakes implementation does. They don't worry about whether the pinning happens inside a git repo or whatever.
(I think some orgs that use Nix in production are still using Niv, and haven't touched flakes. Niv is certainly still maintained.)
I used to use Niv, but these days I find it more convenient to just call `builtins.fetchGit` where it's needed, rather than faffing with external files/tools (although https://hackage.haskell.org/package/update-nix-fetchgit can be useful). It's certainly much nicer than the "olden days" of `nixpkgs.fetchgit`, which required an "impure" copy of Nixpkgs (like <nixpkgs>) in order to fetch a pinned copy!
I tend to have a single git repo with my system config, which uses import-from-derivation to grab a bunch of other stuff; and defines a single "package" that's a big `buildEnv` of all the programs I want. That seems to work fine across NixOS (on an old i686 Thinkpad), an old Ubuntu desktop, macOS (a couple of work laptops; old one used nix-darwin, new one just uses nix-env), and I'm currently trying it on nixos-mobile (on my Pinephone).
I tend to have a single git repo with my system config, which uses import-from-derivation to grab a bunch of other stuff; and defines a single "package" that's a big `buildEnv` of all the programs I want. That seems to work fine across NixOS (on an old i686 Thinkpad), an old Ubuntu desktop, macOS (a couple of work laptops; old one used nix-darwin, new one just uses nix-env), and I'm currently trying it on nixos-mobile (on my Pinephone).
Flakes are basically a framework for centrally managing dependencies. Instead of using fetchgit, you’d just make the git repo a flake input and use that input wherever you need to.
The other nice thing they do (that I use) is provide a nice way to define entry points (either ones accessed by a specific nix flake command, or just Nix flake run). Nix flake check and nix flake fmt are the ones I use.
But mostly it’s not anything new, just a (eventually, right now needing to be manually turned on is annoying) nicer UX on top of things that were already possible.
The other nice thing they do (that I use) is provide a nice way to define entry points (either ones accessed by a specific nix flake command, or just Nix flake run). Nix flake check and nix flake fmt are the ones I use.
But mostly it’s not anything new, just a (eventually, right now needing to be manually turned on is annoying) nicer UX on top of things that were already possible.
I have not used flakes at all for my NixOS server. To put it one way, why should I care?
(speaking as someone who hasn't actually fully converted over to flakes yet)
Because it actually fulfills the original promise of Nix: Forever-reproducible builds.
Anyone who's ever dealt with a lockfile across any stack that supports that idea in dependency definition, knows how this works and what it's good for.
Because it actually fulfills the original promise of Nix: Forever-reproducible builds.
Anyone who's ever dealt with a lockfile across any stack that supports that idea in dependency definition, knows how this works and what it's good for.
Couldn't agree more. I love Nix (well, i have nits with the lang/UX), but Flakes is essential imo.
Using Nix without Flakes is going through 99% of the trouble for concrete, reproducible builds but then dropping the last 1%.
I had my non-Flake builds break like it was a mutable operating system. I just don't get why Flakes aren't the standard.
Using Nix without Flakes is going through 99% of the trouble for concrete, reproducible builds but then dropping the last 1%.
I had my non-Flake builds break like it was a mutable operating system. I just don't get why Flakes aren't the standard.
The UX is much nicer with flakes.
Flakes provide a consistent entry-point to a set of Nix files (rather than just a hoping that Nix files conform to some convention).
Nix flakes also let you get by with even less worry about the system state: e.g. you don't need to add channels or put your code in your user's overlays directory. You can just use the path/URI to a flake, and nix will take care of downloading all the inputs appropriately.
Flakes provide a consistent entry-point to a set of Nix files (rather than just a hoping that Nix files conform to some convention).
Nix flakes also let you get by with even less worry about the system state: e.g. you don't need to add channels or put your code in your user's overlays directory. You can just use the path/URI to a flake, and nix will take care of downloading all the inputs appropriately.
I haven't used NixOS directly yet myself, but I use nixpkgs regularly. It really does make my life easier, so I'm thankful for that. I've built some nixos vms with nix however, that's also pretty nifty.
I might want to try some new Linux distribution so I wonder: what doesn't work in nix? What are its weaknesses? What about devices with non-free firmware?
- You will have to learn both the nix language and working with nixpkgs. Learning nix is pretty trivial IMO (great resources are nix-1p[0] and Nix Pills[1]) but the documentation, while vast, is pretty shallow at the moment. You will likely have to resort to reading random blog posts, nix configs published by others and the source code of nixpkgs itself.
- As mentioned by another commenter you will not be able to run random binaries by default. You can use nix-alien[2] which will automatically fetch the required libraries and build an FHS environment for the binary.
- It is significantly more bandwidth- / rebuild-heavy. If an input for a derivation changes it will trigger a rebuild, which means either a redownload from the binary cache or a recompilation.
[0] https://github.com/tazjin/nix-1p
[1] https://nixos.org/guides/nix-pills
[2] https://github.com/thiagokokada/nix-alien
- As mentioned by another commenter you will not be able to run random binaries by default. You can use nix-alien[2] which will automatically fetch the required libraries and build an FHS environment for the binary.
- It is significantly more bandwidth- / rebuild-heavy. If an input for a derivation changes it will trigger a rebuild, which means either a redownload from the binary cache or a recompilation.
[0] https://github.com/tazjin/nix-1p
[1] https://nixos.org/guides/nix-pills
[2] https://github.com/thiagokokada/nix-alien
> learn both the nix language
That seems weird to me. I don't have to learn package configuration language in other distributions. I thought that one could just install packages with a package manager.
> You can use nix-alien[2] which will automatically fetch the required libraries and build an FHS shell for the binary.
That's actually fine. I want to put closed source software into a chroot anyway.
That seems weird to me. I don't have to learn package configuration language in other distributions. I thought that one could just install packages with a package manager.
> You can use nix-alien[2] which will automatically fetch the required libraries and build an FHS shell for the binary.
That's actually fine. I want to put closed source software into a chroot anyway.
If you want to run nixos (i.e. the linux distro) then the configuration file is written in the nix language. Given that you’ll have to configure your installation, you’ll have to learn the nix language
If you just want to use nix for packages, you can run any distro and install nix the package manager into it. This is a good way to dip your toes in the water. And in that case you can just use the cli commands for installing packages.
If you just want to use nix for packages, you can run any distro and install nix the package manager into it. This is a good way to dip your toes in the water. And in that case you can just use the cli commands for installing packages.
I remember reading that nix unlike all other distros can install multiple version of the same package and I want this feature, but I guess programming a package config might be too much for me. Maybe I'll try nix package manager then.
The Nix idioms that are used in configuring NixOS are super simple, mostly just turning things on and off.
You can browse some here: https://search.nixos.org/options
For example, to install an OpenSSH server and run it, you'd write:
(For NixOS, the Nix you write only starts looking like real code when you want to add new features or some packages to NixOS.)
You can browse some here: https://search.nixos.org/options
For example, to install an OpenSSH server and run it, you'd write:
services.openssh.enable = true;
services.openssh.ports = [
22
2222
];
environment.systemPackages = [
pkgs.firefox
pkgs.jq
];
(For NixOS, the Nix you write only starts looking like real code when you want to add new features or some packages to NixOS.)
> nix unlike all other distros can install multiple version of the same package
The above is sometimes true and sometimes not. For the most part, Nix can install multiple versions of a program but only one can be in use at any given time.
Nix is for the most part shell based workflow (as in bash, zsh, etc.). The `nix-shell` command lets you switch out the packages (and versions of packages) that are used in any given shell, but it works off of a configuration file written in the Nix language that you write. The programs that are available are controlled by environment variables such as PATH and MANPATH.
Nix is a big shift from the usual way of dealing with packages, programs, etc. It isn't really useful until you really make the effort to understand what is going on, learn the Nix language, etc. If you are not interested in "programming" your system, then it probably isn't for you.
The above is sometimes true and sometimes not. For the most part, Nix can install multiple versions of a program but only one can be in use at any given time.
Nix is for the most part shell based workflow (as in bash, zsh, etc.). The `nix-shell` command lets you switch out the packages (and versions of packages) that are used in any given shell, but it works off of a configuration file written in the Nix language that you write. The programs that are available are controlled by environment variables such as PATH and MANPATH.
Nix is a big shift from the usual way of dealing with packages, programs, etc. It isn't really useful until you really make the effort to understand what is going on, learn the Nix language, etc. If you are not interested in "programming" your system, then it probably isn't for you.
> Nix can install multiple versions of a program but only one can be in use at any given time.
That’s not really true and is only a limitation of how PATH works on UNIXes (the first match is used). But you can for example add an aliased name for multiple versions of the same package, or for another meaning of use you can have different executables in the same environment different versions of the same lib (e.g. one bash script references python3, the other python3-at-specific-patch/minor-version/whatever)
That’s not really true and is only a limitation of how PATH works on UNIXes (the first match is used). But you can for example add an aliased name for multiple versions of the same package, or for another meaning of use you can have different executables in the same environment different versions of the same lib (e.g. one bash script references python3, the other python3-at-specific-patch/minor-version/whatever)
> or the most part, Nix can install multiple versions of a program but only one can be in use at any given time.
That's a bit hand-wavey. More precisely: when you run a command, like `python3`, you can only associate that with one file. If you want multiple Python 3 interpreters, you'll have to use different names (e.g. making symlinks).
Alternatively, you don't need to bother "installing" anything; e.g. I use Nix for projects which use Scala, Maven, Python, NodeJS, etc. yet I don't have any of those installed. Instead, each project includes a `shell.nix` file which specifies the tools it wants. Running `nix-shell` in different folders gives me access to different tools.
Also, with Nix we only need to care about the end result: we can "install" a bunch of different programs, even if they have incompatible dependencies, since we're not "installing" those dependencies. ("Install" just means putting a symlink in some bin/ folder, like /run/current-system/sw/bin on NixOS or $HOME/.nix-profile/bin on non-NixOS)
That's a bit hand-wavey. More precisely: when you run a command, like `python3`, you can only associate that with one file. If you want multiple Python 3 interpreters, you'll have to use different names (e.g. making symlinks).
Alternatively, you don't need to bother "installing" anything; e.g. I use Nix for projects which use Scala, Maven, Python, NodeJS, etc. yet I don't have any of those installed. Instead, each project includes a `shell.nix` file which specifies the tools it wants. Running `nix-shell` in different folders gives me access to different tools.
Also, with Nix we only need to care about the end result: we can "install" a bunch of different programs, even if they have incompatible dependencies, since we're not "installing" those dependencies. ("Install" just means putting a symlink in some bin/ folder, like /run/current-system/sw/bin on NixOS or $HOME/.nix-profile/bin on non-NixOS)
This is only true if you want multiple versions in the same global environment. If you really want them in global environment, you can create meta package that aliases with symlinks. Otherwise you can use nix-shell to get any environment you want.
While maybe not impossible, it is quite hard to cox Nix to "install" multiple different versions of the packages. They all cannot be in your path at the same time.
I still encourage you to give it a try. You can build different versions of same package and not "install" them. Instead just execute the binary from the built version (I do this where I have a built-but-not-installed version of openssh-8.6 laying around because I have an old service that modern SSH no longer supports).
You can also run `nix-shell -p <custom-package-version>` to get a shell with a specific package available in the path, overtop of whatever might be globally installed.
Who knows, you might even be tempted to dip your toes into the Nix language by writing a custom `shell.nix` to build a shell with some more complex development environment, or to simply automate a complex `nix-shell -p` command.
I still encourage you to give it a try. You can build different versions of same package and not "install" them. Instead just execute the binary from the built version (I do this where I have a built-but-not-installed version of openssh-8.6 laying around because I have an old service that modern SSH no longer supports).
You can also run `nix-shell -p <custom-package-version>` to get a shell with a specific package available in the path, overtop of whatever might be globally installed.
Who knows, you might even be tempted to dip your toes into the Nix language by writing a custom `shell.nix` to build a shell with some more complex development environment, or to simply automate a complex `nix-shell -p` command.
> That seems weird to me. I don't have to learn package configuration language in other distributions. I thought that one could just install packages with a package manager.
NixOS is more like a distro bundled with Ansible, so you can describe your entire system as code.
NixOS is more like a distro bundled with Ansible, so you can describe your entire system as code.
but in contrast to ansible it uses a real programming language and not turing complete yaml
And it's reproducible since the entire system is built with it. Ansible is brittle as hell.
On both NixOS and Guix System you can get by pretty well without learning the config langs or all the more advanced features. Only really becomes a problem if you need something new packaged. You can enjoy declarative package management with easy rollbacks without really learning more than any other distro.
> I thought that one could just install packages with a package manager.
You could use the command
But... the interesting part of Nix is that it lets you install packages declaratively, by editing a config (like vim and emacs packages). Besides installing packages, all configuration is done through this config file (or bunch of config files): nix generates all files in /etc for you, again, like vim or emacs, but for the whole OS
That way, you easily transfer your setup to another computer or even keep two machines in sync. And you can add it to version control. And you get a grub menu with all your previous setups (until you uninstall them)
If this doesn't appeal you, you probably won't like to use NixOS
You could use the command
nix-env -iA mypackage
But... the interesting part of Nix is that it lets you install packages declaratively, by editing a config (like vim and emacs packages). Besides installing packages, all configuration is done through this config file (or bunch of config files): nix generates all files in /etc for you, again, like vim or emacs, but for the whole OS
That way, you easily transfer your setup to another computer or even keep two machines in sync. And you can add it to version control. And you get a grub menu with all your previous setups (until you uninstall them)
If this doesn't appeal you, you probably won't like to use NixOS
> It is significantly more bandwidth- / rebuild-heavy. If an input for a derivation changes it will trigger a rebuild, which means either a redownload from the binary cache or a recompilation.
For general usage I didn’t notice it much, like, as an alternative to apt/pacman/etc. Ok, maybe don’t use it from a limited data plan (but isn’t true of every desktop OS?).
But sure, if you patch some lib n layers deep you will have to recompile many things, which is a godsend (in that you can actually do that), but will take a bit of time. But you can usually decrement its impact by really changing what has to be changed and using a “standard” channel for all the rest. With flakes it is especially easy to mix and match multiple nixpkgs repos at different versions.
For general usage I didn’t notice it much, like, as an alternative to apt/pacman/etc. Ok, maybe don’t use it from a limited data plan (but isn’t true of every desktop OS?).
But sure, if you patch some lib n layers deep you will have to recompile many things, which is a godsend (in that you can actually do that), but will take a bit of time. But you can usually decrement its impact by really changing what has to be changed and using a “standard” channel for all the rest. With flakes it is especially easy to mix and match multiple nixpkgs repos at different versions.
you can also use https://github.com/Mic92/nix-ld or build a fhs.
If you just want someone to shoot you straight:
Documentation and naming conventions for Nix are absolute shit across the board. This will get downvotes, and people will say I'm wrong, but I'm 100% right. Go see yourself, it's bad. Language is called Nix, OS is actually called Nix, package manager is called Nix, just the whole thing seems like it was written in 1 week by a squirrel with 12 hands and a sack of ritalin.
That being said a lot of smart people here and in my peer group swear it's the truth, despite none being able to elevator pitch it.
Documentation and naming conventions for Nix are absolute shit across the board. This will get downvotes, and people will say I'm wrong, but I'm 100% right. Go see yourself, it's bad. Language is called Nix, OS is actually called Nix, package manager is called Nix, just the whole thing seems like it was written in 1 week by a squirrel with 12 hands and a sack of ritalin.
That being said a lot of smart people here and in my peer group swear it's the truth, despite none being able to elevator pitch it.
> Language is called Nix
Yep; that's a bummer. The manual calls it the "Nix expression language", and some people refer to it as "nixlang" (similar to Gophers saying "golang")
> OS is actually called Nix
Nope, it's always NixOS; 100% of the time. In fact, the naming confusion goes the other way in this case, since the whole project (Nix, NixOS, etc.) lives on the domain nixos.org, and the GitHub account NixOS!
> package manager is called Nix
The commands are called Nix; but I personally find the idea of "package manager" just complicates things. Nix is more of a build tool, like Make; internally, it uses "derivation" to refer to anything from a text file to an entire OS. An application, like a music player, may involve many derivations (e.g. a derivation for its source code, a couple of derivations containing patches, a derivation for an interpreter with the required libraries, etc.); indeed the "actual program" in our $PATH is often just a script which invokes some other binary defined via a different derivation ;)
Yep; that's a bummer. The manual calls it the "Nix expression language", and some people refer to it as "nixlang" (similar to Gophers saying "golang")
> OS is actually called Nix
Nope, it's always NixOS; 100% of the time. In fact, the naming confusion goes the other way in this case, since the whole project (Nix, NixOS, etc.) lives on the domain nixos.org, and the GitHub account NixOS!
> package manager is called Nix
The commands are called Nix; but I personally find the idea of "package manager" just complicates things. Nix is more of a build tool, like Make; internally, it uses "derivation" to refer to anything from a text file to an entire OS. An application, like a music player, may involve many derivations (e.g. a derivation for its source code, a couple of derivations containing patches, a derivation for an interpreter with the required libraries, etc.); indeed the "actual program" in our $PATH is often just a script which invokes some other binary defined via a different derivation ;)
I always refer to nix on mac as "nix package manager" to disambiguate. It seems to be the common way to do so.
> some people refer to it as "nixlang"
more commonly just nix language or you know it out of context
more commonly just nix language or you know it out of context
Sounds like they aren't very smart if they can't elevator pitch it.
Perfectly reproducible OS with easy rollbacks. OS never gets crufty, no need to reinstall every release version or two. Single configuration language for all apps and system components. Composable and shareble config modules at any level of abstraction, e.g. you can piece together many git repos to custom roll your OS. Isolated dependencies for every package, meaning no dependency hell (similar to docker). You can have multiple versions of everything running live. Ability to run temporary environments using the same config language.
Current OSes are like VAX or TRS-80 in comparison. Nix-likes are the future.
Perfectly reproducible OS with easy rollbacks. OS never gets crufty, no need to reinstall every release version or two. Single configuration language for all apps and system components. Composable and shareble config modules at any level of abstraction, e.g. you can piece together many git repos to custom roll your OS. Isolated dependencies for every package, meaning no dependency hell (similar to docker). You can have multiple versions of everything running live. Ability to run temporary environments using the same config language.
Current OSes are like VAX or TRS-80 in comparison. Nix-likes are the future.
My Litmus test for package managers is the ability to install gnome, switch it out for kde and back. (Or starting with kde). One should be able to do that without accumulating garbage (packages that are no longer used, config files, etc), but so far only NixOS passes it (and I didn’t try but assume Guix).
That last sentence is so true. I'm all in on Nix and I couldn't elevator pitch it if my life depended on it.
Here's one:
Nix solves what Docker merely works around.
The secret of Nix is the application of the common wisdom of memory management discipline in modern programming language design to the process of building and distributing software.
The payoff is, as with garbage collection in the original case, and immense leap in safety, productivity, and maintainability for software build and deployment systems.
Concretely, Nix and the ecosystem of tools built upon it and each other mean:
Nix solves what Docker merely works around.
The secret of Nix is the application of the common wisdom of memory management discipline in modern programming language design to the process of building and distributing software.
The payoff is, as with garbage collection in the original case, and immense leap in safety, productivity, and maintainability for software build and deployment systems.
Concretely, Nix and the ecosystem of tools built upon it and each other mean:
- configuration management that never drifts
- upgrades that can always be rolled back in seconds
- servers that don't accrue cruft
- software whose bill of materials comes for free
- an end to version conflicts
- packages which can always be bundled into a minimal container image in seconds
- build artifacts which turn out the same no matter where or when you build them
- software running as-needed, even locally, without having to be installed or manually cleaned up
- a single, simple language capable of defining your entire stack, from building individual assets to managing cloud infrastructure to deploying service-oriented systems
- an end to 'works on my machine' bullshit in their development environments *without* the inefficiencies of virtualization— even on macOS
- user-mode package management for supercomputers and mainframes
- the ability to boot into yesterday's workstation with two keystrokes at boot time
- a time machine for running obsolete software which can't build on modern systems
- a time capsule for software research being conducted today
- the largest, most up-to-date package collection in the world
"A completely repeatable setup all the way down."
- Nixpkgs: Content-addressed reproducible package manager. No collisions because of the content-addressed part.
- NixOS: Full OS that says "what if we did the same for the whole OS"
- NixOS: Full OS that says "what if we did the same for the whole OS"
Uber- I mean Haskell for operating systems.
Like Ansible but more bdsm.
Linux not making you feel superior anymore? Try Nix!
Like Ansible but more bdsm.
Linux not making you feel superior anymore? Try Nix!
NixOS is a reproducible, customizable, programmable and adaptable Linux distribution.
Completely repeatable setup.
Like Docker, but works.
Like Docker, but works.
Docker is not repeatable. If I try to build the same Dockerfile in 12 months then I likely do not get the same output and it wouldn't be surprising if it does not build at all.
Correct and agreed, hence my "but works" portion of the comment!
The notion of portability is Docker's bread and butter. With proper version pinning you _might_ get lucky with repeatability too. Most people anticipate repeatability to be part of portability, but it really is a distinct notion.
The notion of portability is Docker's bread and butter. With proper version pinning you _might_ get lucky with repeatability too. Most people anticipate repeatability to be part of portability, but it really is a distinct notion.
This fits with the usual definition of repeatable. Repeatable means that you can run the same steps, but if the steps are non-deterministic, repeating them doesn't guarantee the same result.
> it wouldn't be surprising if it does not build at all.
This part is a stronger point, and it's true. When you repeat something and what you get is not just a different version or variation but something with totally different or broken behavior, that seems bigger than an ordinary failure of reproducibility.
> it wouldn't be surprising if it does not build at all.
This part is a stronger point, and it's true. When you repeat something and what you get is not just a different version or variation but something with totally different or broken behavior, that seems bigger than an ordinary failure of reproducibility.
> OS is actually called Nix
Not true. The distro is called `NixOS`. The package manager and it's language is called `Nix`.
I do agree that the learning curve is extremely steep.
Not true. The distro is called `NixOS`. The package manager and it's language is called `Nix`.
I do agree that the learning curve is extremely steep.
"Derivation": A per-package lockfile (that is, a merkle tree of dependencies with the hash of their binaries plus the hashes of any deeper dependencies... think git with its commit hashes) that is computed at runtime when that particular binary is installed or updated. This ensures that it will always run with the exact versions of the things it depends on, and upgrades to sub-dependencies (like glibc, or openssl, etc. etc.) won't suddenly break things, because multiple versions of those can now exist in parallel, since its "name" (with regards to the nix store) is not just the canonical name but the canonical name concatenated with its "commit hash" (as it were, using git language)
so basically, when you install something with nix, it's specified all the way down to the bare metal (except for perhaps the kernel)
so basically, when you install something with nix, it's specified all the way down to the bare metal (except for perhaps the kernel)
This is mean, but it's not so blatantly false that it's worthy of downvoting.
Nix and Nixpkgs are messy, evolved things with a lot of history and quirks. They're also very powerful tools that can change the way you even approach computers. If you stick with them long enough, they may inspire you to extend and leverage them in creative ways... continuing the process of messy evolution. :)
Nix and Nixpkgs are messy, evolved things with a lot of history and quirks. They're also very powerful tools that can change the way you even approach computers. If you stick with them long enough, they may inspire you to extend and leverage them in creative ways... continuing the process of messy evolution. :)
Nix the language enables you to write explicit build recipes that can be reproducibly built with good integrity guarantees and granular and distinct knowledge of the build-time dependencies and the run-time dependencies (so you only ever transmit closures that have what they need to execute).
Nix the set of tools gives you convenient command line tools that can: evaluate Nix language expressions, build recipes, analyze build-time or run-time dependency graphs of a recipe, give you ephemeral shells with the packages you want in scope but not installed "globally", package management tools to install packages globally, and recipe diffing tools so you can see how recipes changed.
Nix the package manager is a convenient, gigantic, community effort to explicitly describe how to (reproducibly) build almost all of the OSS software that users need and it comes with a substitution cache so that most recipe build products are easily substituted when installing, so you don't have to build. Even if you don't use Nix, nixpkgs is still impressive because you have the most explicit documentation for how to build a piece of software from source and all of its dependencies than anywhere else on the internet, it usually rivals project author's in its specificity, explicitness, and clarity.
NixOS the Linux distribution combines all of this together with a convenient configuration module system and generally good defaults to give you an operating system that is declaratively specified from your etc hosts file all the way down to the recipe for building the kernel, a rich and granular dependency graph, reproducible OS configuration builds, and diffs between closures.
My biggest gripe with Nix is the lack of static types. This was the originator's biggest mistake that Nix will be living with for a very long time to come. Static types would have helped bring the learning curve down IMHO and made it easier to document and less frustrating to debug.
That being said, the overall properties of Nix, nixpkgs, and NixOS far outweigh the pain points in my six years of production experience with it and for what we care about: auditability, reproducibility, explicitness, efficiency, and integrity.
Nix the set of tools gives you convenient command line tools that can: evaluate Nix language expressions, build recipes, analyze build-time or run-time dependency graphs of a recipe, give you ephemeral shells with the packages you want in scope but not installed "globally", package management tools to install packages globally, and recipe diffing tools so you can see how recipes changed.
Nix the package manager is a convenient, gigantic, community effort to explicitly describe how to (reproducibly) build almost all of the OSS software that users need and it comes with a substitution cache so that most recipe build products are easily substituted when installing, so you don't have to build. Even if you don't use Nix, nixpkgs is still impressive because you have the most explicit documentation for how to build a piece of software from source and all of its dependencies than anywhere else on the internet, it usually rivals project author's in its specificity, explicitness, and clarity.
NixOS the Linux distribution combines all of this together with a convenient configuration module system and generally good defaults to give you an operating system that is declaratively specified from your etc hosts file all the way down to the recipe for building the kernel, a rich and granular dependency graph, reproducible OS configuration builds, and diffs between closures.
My biggest gripe with Nix is the lack of static types. This was the originator's biggest mistake that Nix will be living with for a very long time to come. Static types would have helped bring the learning curve down IMHO and made it easier to document and less frustrating to debug.
That being said, the overall properties of Nix, nixpkgs, and NixOS far outweigh the pain points in my six years of production experience with it and for what we care about: auditability, reproducibility, explicitness, efficiency, and integrity.
> That being said a lot of smart people here and in my peer group swear it's the truth, despite none being able to elevator pitch it.
OK, I’ll bite.
Nix is a build system. NixOS is a Linux source distro built on top of it (cf Gentoo, gittup, BSDs). Except you won’t need to build anything.
Nix builds (should) execute in an isolated environment, thus the build artifacts are (ideally) bit-for-bit identical no matter where they were built. This means you can have a shared artifact cache (cf Bazel). Now for the clever part: in a distro, such an artifact cache is the same thing as a binary repo. Thus you are in fact using a (somewhat disk-space-hungry) binary distro until you want to patch something, at which point it transparently reverts to a source one (up to and including rebootstrapping the system compiler if you wish).
That’s the gist, but there are some more goodies on top of that.
First, none of this really requires a NixOS-only world. Thus, as an intermediate step, there’s Nixpkgs: a ports-like collection of packages that runs on conventional Linux and macOS systems (*BSD support is possible but has bitrotted). To maintain isolation in such an environment, all binaries it builds refer to dynamic libraries by build hash rather than load whatever’s present, and are usually wrapped to ensure other parts of the ambient environment don’t leak through. But once you’ve done that, more or less the only thing remaining to have a “gimme a shell with P, Q, and R in it” command is to point PATH to the right build directories. Hermetic build environments (cf virtualenv) for any supported language, user-scoped rootless package installs, good stuff.
Second, what NixOS adds on top of that (apart from a kernel) is a system for building system configurations out of Nix-language descriptions. It’s a bit clunky, like all config generators, but once you commit to maintaining all of your /etc that way a full rollback of (the NixOS-managed part of) the system is a single GRUB selection away. There are also things like “run a QEMU with this system config inside”, “build a Docker-compatible image with this system config inside”, etc.
Finally, as to how this works, Nix the build language is really simple, it’s JSON + (pure) functions + laziness + a build recipe type. Usually you just generate some shell or Perl or whatever scripts and stuff them into the recipe, so for Nixpkgs it’s honestly a bit overkill, but NixOS uses it to define a rather clever system with options that (if defined) set values of other options that ... all the way to the options that define the raw content of each file in /etc, with rules for merging option values if you wish (cf CUE, Dhall). If your mental model of your system is more abstract than the configuration of each individual service, it’s not hard to write it down as Nix code that defines some new NixOS options, then define your system—or several—in terms of those options.
Bad parts:
Apart from the build system as such, the CLI includes support for a lot of the idioms I mentioned above, so the separation may not look that clean. (This is not helped by the fact that a complete CLI overhaul is in progress, with old commands like nix-build and nix-env being superceded by a single new one, nix. The nixos-* ones are separate for now.)
The language is perhaps a bit too minimal and lacks a standard library, so Nixpkgs ends up containing that as well, without much in the way of documentation. You will have to refer to the source there. The library is mostly simple list and mapping utilities, so it’s not difficult, but figuring out whether the thing you want is in it or not can be frustrating, and the API won’t win any beauty contests.
It can be slow.
OK, I’ll bite.
Nix is a build system. NixOS is a Linux source distro built on top of it (cf Gentoo, gittup, BSDs). Except you won’t need to build anything.
Nix builds (should) execute in an isolated environment, thus the build artifacts are (ideally) bit-for-bit identical no matter where they were built. This means you can have a shared artifact cache (cf Bazel). Now for the clever part: in a distro, such an artifact cache is the same thing as a binary repo. Thus you are in fact using a (somewhat disk-space-hungry) binary distro until you want to patch something, at which point it transparently reverts to a source one (up to and including rebootstrapping the system compiler if you wish).
That’s the gist, but there are some more goodies on top of that.
First, none of this really requires a NixOS-only world. Thus, as an intermediate step, there’s Nixpkgs: a ports-like collection of packages that runs on conventional Linux and macOS systems (*BSD support is possible but has bitrotted). To maintain isolation in such an environment, all binaries it builds refer to dynamic libraries by build hash rather than load whatever’s present, and are usually wrapped to ensure other parts of the ambient environment don’t leak through. But once you’ve done that, more or less the only thing remaining to have a “gimme a shell with P, Q, and R in it” command is to point PATH to the right build directories. Hermetic build environments (cf virtualenv) for any supported language, user-scoped rootless package installs, good stuff.
Second, what NixOS adds on top of that (apart from a kernel) is a system for building system configurations out of Nix-language descriptions. It’s a bit clunky, like all config generators, but once you commit to maintaining all of your /etc that way a full rollback of (the NixOS-managed part of) the system is a single GRUB selection away. There are also things like “run a QEMU with this system config inside”, “build a Docker-compatible image with this system config inside”, etc.
Finally, as to how this works, Nix the build language is really simple, it’s JSON + (pure) functions + laziness + a build recipe type. Usually you just generate some shell or Perl or whatever scripts and stuff them into the recipe, so for Nixpkgs it’s honestly a bit overkill, but NixOS uses it to define a rather clever system with options that (if defined) set values of other options that ... all the way to the options that define the raw content of each file in /etc, with rules for merging option values if you wish (cf CUE, Dhall). If your mental model of your system is more abstract than the configuration of each individual service, it’s not hard to write it down as Nix code that defines some new NixOS options, then define your system—or several—in terms of those options.
Bad parts:
Apart from the build system as such, the CLI includes support for a lot of the idioms I mentioned above, so the separation may not look that clean. (This is not helped by the fact that a complete CLI overhaul is in progress, with old commands like nix-build and nix-env being superceded by a single new one, nix. The nixos-* ones are separate for now.)
The language is perhaps a bit too minimal and lacks a standard library, so Nixpkgs ends up containing that as well, without much in the way of documentation. You will have to refer to the source there. The library is mostly simple list and mapping utilities, so it’s not difficult, but figuring out whether the thing you want is in it or not can be frustrating, and the API won’t win any beauty contests.
It can be slow.
Thats quite a lengthy elevator ride : )
Right? :) I intended only the first two paragraphs to be the pitch and the rest to be an extended explanation, but I have to admit they aren’t really a summary of the rest.
Now that I’ve written this, I see I can’t really phrase the benefits such that the result is neither a shallow-sounding platitude nor a laundry list of features, when the reality is a laundry list of features that mostly fall out of a couple of overarching ideas. And it’s not like each of those features haven’t been done before, but this particular implementation comes out remarkably simple and sane given the length of the list.
Now that I’ve written this, I see I can’t really phrase the benefits such that the result is neither a shallow-sounding platitude nor a laundry list of features, when the reality is a laundry list of features that mostly fall out of a couple of overarching ideas. And it’s not like each of those features haven’t been done before, but this particular implementation comes out remarkably simple and sane given the length of the list.
> naming conventions for Nix are absolute shit across the board
No, not really. They are not consistent for every part and not every package is up to date with everything but if you get the gist you can easily guess things. If things are really weird we can always rename them.
No, not really. They are not consistent for every part and not every package is up to date with everything but if you get the gist you can easily guess things. If things are really weird we can always rename them.
Nix feels to me like a cool but somewhat hacky v1 of a really great idea. I'm hoping someone creates a much more elegant successor.
If Nix is CVS or even Subversion, I'm hoping for Git.
If Nix is CVS or even Subversion, I'm hoping for Git.
What? Have you used the old nix cli? It absolutely dominates Git in the frequency of "how do I do that again?" /s
Maybe take a look at Guix? (I don't use it, but it sounds like what you describe)
The neat thing about the functional design of Nix is that you don't have to reinvent the wheel: just make better steering.
Everything about Nix can be trivially refactored. Every part is neatly isolated from the rest.
Everything about Nix can be trivially refactored. Every part is neatly isolated from the rest.
> Everything about Nix can be trivially refactored. Every part is neatly isolated from the rest.
Tweaking a few NixOS modules it replacing a package is easy, but neither the Nix codebase nor Nixpkgs is characterized by perfect modularity or uniform layering.
Tweaking a few NixOS modules it replacing a package is easy, but neither the Nix codebase nor Nixpkgs is characterized by perfect modularity or uniform layering.
I'm just going to link to the best HN comment I've seen on this topic
https://news.ycombinator.com/item?id=33679621
https://news.ycombinator.com/item?id=33679621
No mention of the fucky /nix/store paths for everything? I haven't used a lot of other distros, especially recent ones (my list: Slackware, Redhat, Ubuntu, Debian), but Nix is a drastic departure from the standard FHS and Linux conventions.
Don't get me wrong - I love NixOS! I'm gradually switching my infrastructure to NixOS. There are very necessary reasons for Nix's departures. But it is jarring, and if we want converts we have to manage expectations properly!
Don't get me wrong - I love NixOS! I'm gradually switching my infrastructure to NixOS. There are very necessary reasons for Nix's departures. But it is jarring, and if we want converts we have to manage expectations properly!
That's true! Whenever I demo Nix for someone in person, the first trick I do is
> Look ma, no /usr/lib
and right after that it's a chat about the Nix store, and then a tour of what all those ugly hashes let you achieve.
I guess when I wrote that comment I was mostly thinking about what it's like to administer NixOS on a personal system over the moderate term, not the initial shock and wonder of hiking through the glorious Nix symlink forest under /nix/var/nix/profiles for the first time. :)
> Look ma, no /usr/lib
and right after that it's a chat about the Nix store, and then a tour of what all those ugly hashes let you achieve.
I guess when I wrote that comment I was mostly thinking about what it's like to administer NixOS on a personal system over the moderate term, not the initial shock and wonder of hiking through the glorious Nix symlink forest under /nix/var/nix/profiles for the first time. :)
My personal administration involved a lot of digging through installed software's FHS to figure out how things worked. Especially coming up through Slackware. It's probably a learning style thing.
Mutable distros you directly edit stuff in /etc, then build your knowledge on top of that foundation. Whatever better practices you end up adopting, you're still ultimately modifying files in /etc (and probably elsewhere). A NixOS beginner shouldn't be touching config files, and can't even do things like replace a binary with a shell script wrapper to understand when and how a program is run by a different program.
So I see that departure as a pretty huge one, that will affect someone learning Linux on NixOS for many years, as they need to dig through NixOS specific docs to understand how they're supposed to configure something, rather than falling back to the regular packaging docs. Whereas with Debian you only need Debian documentation to know how to install a package, but after that the upstream package documentation tells you everything else.
As an aside, I feel like NixOS asks a fundamentally different question - "how can we mitigate Linux/Unix's complexity" rather than the traditional mutable distro question of "how can we best interact with Linux/Unix's complexity".
(Also, that sounds like a great approach to explaining NixOS!)
Mutable distros you directly edit stuff in /etc, then build your knowledge on top of that foundation. Whatever better practices you end up adopting, you're still ultimately modifying files in /etc (and probably elsewhere). A NixOS beginner shouldn't be touching config files, and can't even do things like replace a binary with a shell script wrapper to understand when and how a program is run by a different program.
So I see that departure as a pretty huge one, that will affect someone learning Linux on NixOS for many years, as they need to dig through NixOS specific docs to understand how they're supposed to configure something, rather than falling back to the regular packaging docs. Whereas with Debian you only need Debian documentation to know how to install a package, but after that the upstream package documentation tells you everything else.
As an aside, I feel like NixOS asks a fundamentally different question - "how can we mitigate Linux/Unix's complexity" rather than the traditional mutable distro question of "how can we best interact with Linux/Unix's complexity".
(Also, that sounds like a great approach to explaining NixOS!)
Another thing is that the nixos option searcher[1] links to the nix source code that implements the option, so you can go digging through how things work. It's definitely an extra layer of abstraction vs editing /etc/foorc but I have copied what those things do into my configuration.nix and made changes to poke at stuff.
1: https://search.nixos.org/options
1: https://search.nixos.org/options
A few times, I have privately used NixOS modules' source code to answer questions about how to configure software that I do not use, in response to questions posed by users of other distros. It's an awesome resource! :D
> My personal administration [prior to NixOS] involved a lot of digging through installed software's FHS to figure out how things worked. [...] Mutable distros you directly edit stuff in /etc, then build your knowledge on top of that foundation.
That's true. Once you have found your footing with the Nix language and figured out some basics of how to navigate the NixOS modules in Nixpkgs, the latter becomes a rich source of examples on how to configure everything on a modern Unix-like system, from mounting a btrfs subvolume in your initrd via systemd/dracut integrations to setting up PipeWire to emulate PulseAudio. But while NixOS can still teach you a lot about how a working Unix-like system is put together and how its stack is configured, the most useful point of entry for such exploration is very different from what you might be used to on other distros.
You can also learn by exploring the Nix profiles and the Nix store of a working system, much like you would walk through the FHS on a ‘normal’ Linux system— after all, all of your system-wide config files can eventually be hunted down in the Nix store. If you run `ps` on a NixOS system, you'll see explicit references to RC files for lots of programs that are wrapped to point to specific config files, and for running persistent services. But it's probably not as useful as going directly to the Nixpkgs source, once you've learned to read a little Nix.
> A NixOS beginner shouldn't be touching config files, and can't even do things like replace a binary with a shell script wrapper to understand when and how a program is run by a different program.
That's an interesting thought. I didn't come to NixOS as a beginner in the Linux world; NixOS was not my first distro. (I think that's true for most of us in the community.) With NixOS, neither the paradigm nor the community really encourages the kind of monkey patching, that kind of learning by brute intervention on a running system. Even so, I think it would be possible (if perhaps a bit perverse) to write a textbook or a course like ‘Learning Unix with NixOS’. I think using a read-write store as a teaching tool before showing the reader how to use Nix itself to wrap programs that live in the Nix store would be fine.
> [NixOS users] need to dig through NixOS specific docs to understand how they're supposed to configure something, rather than falling back to the regular packaging docs.
Right, NixOS definitely changes the sort of ‘order of recourse’ users will want to make when configuring a piece of software. I'd say it looks something like this:
A NixOS fanatic might frame this
> Whereas with Debian you only need Debian documentation to know how to install a package, but after that the upstream package documentation tells you everything else.
in an alternative way:
> Whereas Debian only helps you to install the package, NixOS will also help you perform common configuration tasks. It's only when you need to perform peculiar configuration tasks for your specific needs that you really have to dive into the upstream documentation.
At the same time, knowledge of some upstream component (e.g., Xorg, connman, OpenSSH, etc.) always remains applicable with NixOS, if you want it to be. Everything that's configurable under /etc/something/or/other on Debian remains configurable on NixOS in a straightforward way, either by specifying key-value type config in the Nix language or (in the worst case) by embedding a config file snippet in your NixOS configuration.
> As an aside, I feel like NixOS asks a fundamentally different question - "how can we mitigate Linux/Unix's complexity" rather than the traditional mutable distro question of "how can we best interact with Linux/Unix's complexity".
I think this is well put, and it's what I was getting at above with the idea that thinking about the particular structure of some program's RC file is a last resort in NixOS. But it's not entirely one-sided! The NixOS module system serves not just to shield users from that complexity when they don't need to confront it, but also to teach them about it when they do. For me, that's one of the reasons that learning the Nix language and exploring the Nixpkgs codebase is so worth it.
That's true. Once you have found your footing with the Nix language and figured out some basics of how to navigate the NixOS modules in Nixpkgs, the latter becomes a rich source of examples on how to configure everything on a modern Unix-like system, from mounting a btrfs subvolume in your initrd via systemd/dracut integrations to setting up PipeWire to emulate PulseAudio. But while NixOS can still teach you a lot about how a working Unix-like system is put together and how its stack is configured, the most useful point of entry for such exploration is very different from what you might be used to on other distros.
You can also learn by exploring the Nix profiles and the Nix store of a working system, much like you would walk through the FHS on a ‘normal’ Linux system— after all, all of your system-wide config files can eventually be hunted down in the Nix store. If you run `ps` on a NixOS system, you'll see explicit references to RC files for lots of programs that are wrapped to point to specific config files, and for running persistent services. But it's probably not as useful as going directly to the Nixpkgs source, once you've learned to read a little Nix.
> A NixOS beginner shouldn't be touching config files, and can't even do things like replace a binary with a shell script wrapper to understand when and how a program is run by a different program.
That's an interesting thought. I didn't come to NixOS as a beginner in the Linux world; NixOS was not my first distro. (I think that's true for most of us in the community.) With NixOS, neither the paradigm nor the community really encourages the kind of monkey patching, that kind of learning by brute intervention on a running system. Even so, I think it would be possible (if perhaps a bit perverse) to write a textbook or a course like ‘Learning Unix with NixOS’. I think using a read-write store as a teaching tool before showing the reader how to use Nix itself to wrap programs that live in the Nix store would be fine.
> [NixOS users] need to dig through NixOS specific docs to understand how they're supposed to configure something, rather than falling back to the regular packaging docs.
Right, NixOS definitely changes the sort of ‘order of recourse’ users will want to make when configuring a piece of software. I'd say it looks something like this:
1. Is there an existing NixOS module for configuring the software I want to use?
2. If so, does the module have any high-level options that look so convenient that I should try them right away?
3. Is there any additional, special configuration that I need to do?
A NixOS fanatic might frame this
> Whereas with Debian you only need Debian documentation to know how to install a package, but after that the upstream package documentation tells you everything else.
in an alternative way:
> Whereas Debian only helps you to install the package, NixOS will also help you perform common configuration tasks. It's only when you need to perform peculiar configuration tasks for your specific needs that you really have to dive into the upstream documentation.
At the same time, knowledge of some upstream component (e.g., Xorg, connman, OpenSSH, etc.) always remains applicable with NixOS, if you want it to be. Everything that's configurable under /etc/something/or/other on Debian remains configurable on NixOS in a straightforward way, either by specifying key-value type config in the Nix language or (in the worst case) by embedding a config file snippet in your NixOS configuration.
> As an aside, I feel like NixOS asks a fundamentally different question - "how can we mitigate Linux/Unix's complexity" rather than the traditional mutable distro question of "how can we best interact with Linux/Unix's complexity".
I think this is well put, and it's what I was getting at above with the idea that thinking about the particular structure of some program's RC file is a last resort in NixOS. But it's not entirely one-sided! The NixOS module system serves not just to shield users from that complexity when they don't need to confront it, but also to teach them about it when they do. For me, that's one of the reasons that learning the Nix language and exploring the Nixpkgs codebase is so worth it.
I guess I kind of think of that as like "Lisp has a lot of brackets!" true, but something someone looking into potentially using it knows already.
NixOS has a steep learning curve but if you start to climb it, it is probably the strongest distro right now especially if you want to customize things and have it reproducible.
From my experience, any binary is going to need patching before it runs, because shared libraries are in weird paths. I especially had issues running Steam, but this was about 8 years ago — maybe the situation has improved now.
Steam still needs to be configured
https://nixos.wiki/wiki/Steam
but it's just a few lines in your config and then it works
https://nixos.wiki/wiki/Steam
but it's just a few lines in your config and then it works
That page is missing the opengl drivers which you also most likely want in the 32 bit variant.
Setting programs.steam.enable also enables 32-bit opengl, last I checked.
Yes, that's correct and then you need to tell it which driver you need for your hardware. For example like:
hardware.opengl = { extraPackages = with pkgs; [ intel-compute-runtime # OpenCL library intel-media-driver # video encoding/decoding hardware accerlation ]; extraPackages32 = with pkgs.pkgsi686Linux; [ intel-media-driver # video encoding/decoding hardware accerlation ]; };
hardware.opengl = { extraPackages = with pkgs; [ intel-compute-runtime # OpenCL library intel-media-driver # video encoding/decoding hardware accerlation ]; extraPackages32 = with pkgs.pkgsi686Linux; [ intel-media-driver # video encoding/decoding hardware accerlation ]; };
Yes, you cannot just download any random binary from the internet unless you use a FHS because those libraries are compiled for Distros using a default file system layout.
you can't run binaries built for other distributions, without patching them
Not true: there are many tools that allows directly running any binary, like nix-autobahn [1].
[1]: https://github.com/Lassulus/nix-autobahn
[1]: https://github.com/Lassulus/nix-autobahn
or https://github.com/Mic92/nix-ld or a FHS. There are many projects to help with this.
Haha, sometimes it goes the other way round.
The vpn client at work wasn't available for the latest ubuntu and the old version did not work due to changes in some libs. Wrapping it with nix providing the right libs was way easier and much more replicable than manually building the required stuff. Did in on my machine and than 3 mins to do the same for a colleague.
The vpn client at work wasn't available for the latest ubuntu and the old version did not work due to changes in some libs. Wrapping it with nix providing the right libs was way easier and much more replicable than manually building the required stuff. Did in on my machine and than 3 mins to do the same for a colleague.
Sort of true, you can but it require a fhs environment setup
I wonder why Nix doesn't give every package a FHS env by default. In 2022 chroot and overlayfs should be available everywhere. Wouldn't that solve a ton of problems?
Nix has no concept of "package". Applications are defined as derivations, but so is everything else (I wouldn't want an entire FHS directory structure for, e.g., a single text file).
If you want an FHS, you can get one using a function like buildFHSUserEnv (that's defined in the Nixpkgs project; Nix itself doesn't know or care what FHS is; indeed, Nix will happily run on non-Linux platforms)
If you want an FHS, you can get one using a function like buildFHSUserEnv (that's defined in the Nixpkgs project; Nix itself doesn't know or care what FHS is; indeed, Nix will happily run on non-Linux platforms)
A FHS adds slight overhead to a package and to launch times. It also shadows part of the file system. For example /lib would probably be different for every other program which would be even more confusing.
steam-run usually. That gives you a Ubuntu-like environment.
If Nix is too much but you still want an immutable distro, look into Fedora Silverblue (or Kinoite). It offers some of the advantages of Nix in a more approachable fashion.
Seconding this. I ran Silverblue until recently due to some bugs in Kinoite but switched as soon as possible because GNOME sucks.
Its the first distro I've used in 20 years that doesn't feel like a stiff wind could cause the whole thing to collapse and catch fire in an unrecoverable way, while still allowing me to run any software I want instead of just what is in some limited curated repo. And unlike Nix, I didn't need to learn a new language to use it.
Its the first distro I've used in 20 years that doesn't feel like a stiff wind could cause the whole thing to collapse and catch fire in an unrecoverable way, while still allowing me to run any software I want instead of just what is in some limited curated repo. And unlike Nix, I didn't need to learn a new language to use it.
Does Silverblue still support traditional package managers? An immutable OS seems nice and I like Bubblewrap's isolation, but I would never switch full-time to an all-Flatpak distro...
Yes, you use 'rpm-ostree' to install and manage regular dnf packages, or local .RPM files.
The limitations are:
1) Each invocation of the package manager (install/upgrade/uninstall, the usual stuff) results in a new OS 'commit' and requires a reboot to switch to it.
This is the entire point of the distro (random .rpm broke your system? just rollback), and is why Silverblue users generally only use DNF packages for low-level tools and run regular applications as flatpaks, appimages, or podmans.
2) Occasionally you'll run into a package that wants to write to a folder that Silverblue made read-only and version-controlled, and breaks. In that case your only options are to run the package inside a toolbox (a special Podman container that comes with Silverblue for these scenarios), or patching the package.
The limitations are:
1) Each invocation of the package manager (install/upgrade/uninstall, the usual stuff) results in a new OS 'commit' and requires a reboot to switch to it.
This is the entire point of the distro (random .rpm broke your system? just rollback), and is why Silverblue users generally only use DNF packages for low-level tools and run regular applications as flatpaks, appimages, or podmans.
2) Occasionally you'll run into a package that wants to write to a folder that Silverblue made read-only and version-controlled, and breaks. In that case your only options are to run the package inside a toolbox (a special Podman container that comes with Silverblue for these scenarios), or patching the package.
In addition to the sibling comment about layering, this is largely what toolbox is for. Essentially you create containerized environments with a lot of integration (you can run GUI apps from them) and install whatever you want in those.
I have my issues with both Flatpak and Toolbox as far as how they're put together and work, but overall I find it to be a vast improvement on the status-quo way of doing things. YMMV, of course.
toolbox create new_dev_env_or_whatever
toolbox enter new_dev_env_or_whatever
dnf install all_the_things
I have my issues with both Flatpak and Toolbox as far as how they're put together and work, but overall I find it to be a vast improvement on the status-quo way of doing things. YMMV, of course.
I found distrobox to be useful even on Fedora. For some reason running CLion under a plain toolbox resulted in very frequent system-wide pauses lasting several seconds.
I had the same issue on Kinoite 35 specifically, but only with GTK applications. That forced me to Silverblue at the time, but 37 seems to have ironed out whatever it was.
Interesting, that's much better than what I assumed. NixOS' composition tools are fairly similar, at least in scope.
Never mind traditional package managers... you plug it in right, you can run Nix on Silverblue!
https://gitlab.com/ahayzen/silverblue-nix
NixOS people will prefer NixOS, but Silverblue seems like a nice complement to Nix if you need an FHS base system and want to retain some Nix-ish features like rollbacks and atomic upgrades.
https://gitlab.com/ahayzen/silverblue-nix
NixOS people will prefer NixOS, but Silverblue seems like a nice complement to Nix if you need an FHS base system and want to retain some Nix-ish features like rollbacks and atomic upgrades.
You can install all the usual software from the Fedora repos, but you need to do a reboot before you can use it. See the Package Layering section here: https://docs.fedoraproject.org/en-US/fedora-silverblue/getti...
(for other readers) This is only required for packages that require low-level integration - services, virtualization, drivers. The Silverblue big idea is that you should make maximum use of flatpaks and "toolbox" containerized environments, all which "float" over the base OS. Once everything's been "layered" to your liking, you rarely touch the base OS anymore except for updates.
I would expect something like Steam gaming on my dual-GPU laptop might be one deep mineshaft of "nope" on NixOS.
If it's an Intel iGPU + an Nvidia dGPU setup beware there's a bug with the implementation of the Nvidia driver currently which breaks connecting external displays on X11 depending on your hardware. See https://github.com/NixOS/nixpkgs/issues/199024 and the comments of https://github.com/NixOS/nixpkgs/pull/165188.
Also setting Coolbits doesn't seem to work either on my end, which means no overclocking support for the Nvidia GPU (if that's something you care about).
Also setting Coolbits doesn't seem to work either on my end, which means no overclocking support for the Nvidia GPU (if that's something you care about).
NixOS actually handles NVIDIA hybrid graphics more easily than most distros. When I got a laptop with NVIDIA/Intel hybrid graphics a few years ago, it took less time to configure on NixOS than it had on openSUSE, which I was dual-booting at the time.
I don't have a laptop like that anymore, but check the NixOS manual and NixOS.wiki, and ask around if you get stuck!
(When I last used it, Bumblebee was the best option and worked well, but these days, native PRIME offloading should also work fine and it's what I would prefer.)
As for Steam, just add
(If you're accustomed to Flatpak Steam, you can alternatively enable Flatpak and just install Steam that way, like you would on your existing distro.)
I don't have a laptop like that anymore, but check the NixOS manual and NixOS.wiki, and ask around if you get stuck!
(When I last used it, Bumblebee was the best option and worked well, but these days, native PRIME offloading should also work fine and it's what I would prefer.)
As for Steam, just add
programs.steam.enable = true;
(If you're accustomed to Flatpak Steam, you can alternatively enable Flatpak and just install Steam that way, like you would on your existing distro.)
I can't speak to that specific use case, but in a more general sense...
NixOS, just like any other OS, can have you walking down the familiar caverns of, "getting the thing to work that this system isn't designed to accommodate well."
But this time is different: you can start over fresh at any time.
This is really the situation where NixOS shines the most. No more, "wondering what you installed where when you were trying to get that over program working the other day." No more, "did I just do the steps in the wrong order?"
It's unbreakable. Your OS is guaranteed to feel like a fresh install. Forever. Because it can't be anything else.
NixOS, just like any other OS, can have you walking down the familiar caverns of, "getting the thing to work that this system isn't designed to accommodate well."
But this time is different: you can start over fresh at any time.
This is really the situation where NixOS shines the most. No more, "wondering what you installed where when you were trying to get that over program working the other day." No more, "did I just do the steps in the wrong order?"
It's unbreakable. Your OS is guaranteed to feel like a fresh install. Forever. Because it can't be anything else.
No, that works fine. As well as it ever does.
Really? I'm curious to read more.
It works very well for me under Ubuntu these days, but if I can get it working equivalently well on NixOS I may legitimately consider switching.
It works very well for me under Ubuntu these days, but if I can get it working equivalently well on NixOS I may legitimately consider switching.
I use steam on nix and it was a breeze.
Plugging my own thing here, but I have been experimenting with a Nix configuration for gaming only. My configuration is here (for Nvidia, which does not work without tinkering as AMD does) : https://github.com/jhvst/nix-config/blob/main/nvidia.nix
First, this is a whole system specification. This means that executing this on Nix will build you a whole OS image. You can build the image if you have Nix by running the first line on file. You can also use Docker with the instruction on my README: https://github.com/jhvst/nix-config (however, kexec will not likely work, read more how to run it later)
Back to elaborating on the Nix file from the gaming perspective. First, we have the overlays. These are like patches to the packages, and really useful for gaming because it allows building important packages like mesa from the source tip. This is particularly useful when new games or GPUs are released. Same thing for wayland: Nvidia and its proprietary drivers need some patching, but it's possible to get wayland (and sway) to work this way.
Then, I have taken the reproducibility of Nix to a next step in my opinion, and made the system stateless. This means that it runs from the RAM. It is easy to create installation media like kernel, initrd, and rootfs because you have all the steps to create the distribution. This means that here, Nix works as a meta-distro like Gentoo, on top of which you develop your own. Running from the RAM means that theoretically, if you have a working config, and two people with different hardware runs it, then they should have the same experience. If you look at ProtonDB, you often find that some people claim that game X works on their machine with drivers and mesa of Y and Z, but there is no way to copy their configurations because it's certain that the user has made some stateful changes which they have forgotten hence left undocumented, which is the reason it works for them. If everyone would be using Nix, you could reproduce their system and possibly fix your own, but this is not tractable with most OSs.
If you like to test my changes, you can read more about my approach here: https://github.com/NixOS/nixpkgs/pull/203750
For testing I distribute Nvidia as documented here: https://github.com/jhvst/jhvst.github.io/blob/main/ramdisk.m...
However, I have developed it bit further: if you manage to get into an iPXE shell, you can write `boot -a http://boot.ponkila.com/menu.ipxe`, then select the second option which is Nvidia (proprietary drivers), and with some waiting you will get into a shell prompt to which you can write `sway --unsupported-gpu`, which will launch sway. Cmd+Enter opens a prompt to which you can write `steam`, which will open Steam. Then, you have to mount some drive on another shell with `mount`, and add this as a Steam library via Steam's UI. Then you can play games. I use this on AMD and I have been very happy.
To get iPXE, the easy option is to go along with https://netboot.xyz. You will find the `iPXE shell` option here to which to write the boot option from the previous paragraph.
I also added AMD to the iPXE menu for whomever decides to test it. Sway is launched by writing `sway`. Steam should be started with `AMD_VULKAN_ICD="RADV" VK_ICD_FILENAMES="/run/opengl/driver/share/vulkan/icd.d/radeon_icd.x86_64.json" steam` to use the faster RADV driver.
First, this is a whole system specification. This means that executing this on Nix will build you a whole OS image. You can build the image if you have Nix by running the first line on file. You can also use Docker with the instruction on my README: https://github.com/jhvst/nix-config (however, kexec will not likely work, read more how to run it later)
Back to elaborating on the Nix file from the gaming perspective. First, we have the overlays. These are like patches to the packages, and really useful for gaming because it allows building important packages like mesa from the source tip. This is particularly useful when new games or GPUs are released. Same thing for wayland: Nvidia and its proprietary drivers need some patching, but it's possible to get wayland (and sway) to work this way.
Then, I have taken the reproducibility of Nix to a next step in my opinion, and made the system stateless. This means that it runs from the RAM. It is easy to create installation media like kernel, initrd, and rootfs because you have all the steps to create the distribution. This means that here, Nix works as a meta-distro like Gentoo, on top of which you develop your own. Running from the RAM means that theoretically, if you have a working config, and two people with different hardware runs it, then they should have the same experience. If you look at ProtonDB, you often find that some people claim that game X works on their machine with drivers and mesa of Y and Z, but there is no way to copy their configurations because it's certain that the user has made some stateful changes which they have forgotten hence left undocumented, which is the reason it works for them. If everyone would be using Nix, you could reproduce their system and possibly fix your own, but this is not tractable with most OSs.
If you like to test my changes, you can read more about my approach here: https://github.com/NixOS/nixpkgs/pull/203750
For testing I distribute Nvidia as documented here: https://github.com/jhvst/jhvst.github.io/blob/main/ramdisk.m...
However, I have developed it bit further: if you manage to get into an iPXE shell, you can write `boot -a http://boot.ponkila.com/menu.ipxe`, then select the second option which is Nvidia (proprietary drivers), and with some waiting you will get into a shell prompt to which you can write `sway --unsupported-gpu`, which will launch sway. Cmd+Enter opens a prompt to which you can write `steam`, which will open Steam. Then, you have to mount some drive on another shell with `mount`, and add this as a Steam library via Steam's UI. Then you can play games. I use this on AMD and I have been very happy.
To get iPXE, the easy option is to go along with https://netboot.xyz. You will find the `iPXE shell` option here to which to write the boot option from the previous paragraph.
I also added AMD to the iPXE menu for whomever decides to test it. Sway is launched by writing `sway`. Steam should be started with `AMD_VULKAN_ICD="RADV" VK_ICD_FILENAMES="/run/opengl/driver/share/vulkan/icd.d/radeon_icd.x86_64.json" steam` to use the faster RADV driver.
> What are its weaknesses?
I think is easier to see this with what is their main strength: A declarative/reproducible OS setup. Is AMAZING for server deployment (like what you put in a docker file but that not mutate after it).
But I don't think will be so nice for day to day use. That is where a mutation OS is easier.
I think is easier to see this with what is their main strength: A declarative/reproducible OS setup. Is AMAZING for server deployment (like what you put in a docker file but that not mutate after it).
But I don't think will be so nice for day to day use. That is where a mutation OS is easier.
I don't agree. NixOS has many weaknesses, but a server/desktop divide is not one of them.
Fwiw the best summary of "should I use NixOS" is https://news.ycombinator.com/item?id=33679621
Fwiw the best summary of "should I use NixOS" is https://news.ycombinator.com/item?id=33679621
As soon as you have multiple machines with shared configs it gets really attractive again.
My desktop development workstation is running on NixOS. I am always updating it as soon as possible because I know I can revert everything. That is damn nice.
The biggest weakness is the built-in expectations it has on how packages install/operate. There are some patterns that will not fit into the box easily (e.g. native-compiled gems/node packages).
Also since things are declarative, that means things like e.g. updating bash aliases has additional friction vs the traditional way of editing the file directly.
Also since things are declarative, that means things like e.g. updating bash aliases has additional friction vs the traditional way of editing the file directly.
> updating bash aliases has additional friction vs the traditional way of editing the file directly
Additional friction (not much imo), but you will actually be able to move that bash plugin that does that thing you didn’t even realize were not available in a vanilla shell.
Additional friction (not much imo), but you will actually be able to move that bash plugin that does that thing you didn’t even realize were not available in a vanilla shell.
I ran NixOS on my living room emulation/gaming computer for years, until I stopped having one. It wasn't particularly high friction or server-y.
> Graphical installer
I've recently installed NixOS on an old Thinkpad I got from work, and I was pleasantly surprised by the graphical installer. Even though NixOS is far from a beginner distro, removing friction in the initial installation process is a good thing.
I've recently installed NixOS on an old Thinkpad I got from work, and I was pleasantly surprised by the graphical installer. Even though NixOS is far from a beginner distro, removing friction in the initial installation process is a good thing.
I was also pleasantly surprised, especially by how easy it was to setup disk encryption. I probably wouldn't have done so otherwise.
I set up LUKS with NixOs like 5 years ago without any prior experience and it was straightforward (just followed the docs). I wish that dealing with nix/nixos was always that easy...
Last week I switched from my Arch VM to a NixOS 22.05 VM full-time and it has been an excellent experience so far.
Looking forward to seeing and reporting back on what my first NixOS upgrade experience is like.
Looking forward to seeing and reporting back on what my first NixOS upgrade experience is like.
Having absolutely no fear going into an OS upgrade is one of the best parts of nix. If anything breaks, you can go back to your old config and be sure it’ll still work.
Going back to an OS that doesn’t have this property feels like programming without version control.
Going back to an OS that doesn’t have this property feels like programming without version control.
Definitely up there for the top Nix benefits - truly atomic OS upgrades.
It's a shame this isn't explicitly highlighted on nixos.org, it's only implied in the "Is the previous version better? Roll back anytime."[0] section, when it's true for both packages and your entire system's config.
[0] https://nixos.org/explore.html
It's a shame this isn't explicitly highlighted on nixos.org, it's only implied in the "Is the previous version better? Roll back anytime."[0] section, when it's true for both packages and your entire system's config.
[0] https://nixos.org/explore.html
Touching on that version control and Nix are the same thing. Would be cool if they merged in some system.
You may be interested in Flakes[0], which locks your nixpkgs (and other "inputs") to a specific known version.
Obligatory disclaimer, they're still in beta, but everyone's using them anyway. There's some ongoing work[1] before they're officially released.
[0] https://nixos.wiki/wiki/Flakes [1] https://www.youtube.com/watch?v=JE-vLFMTXxM
Obligatory disclaimer, they're still in beta, but everyone's using them anyway. There's some ongoing work[1] before they're officially released.
[0] https://nixos.wiki/wiki/Flakes [1] https://www.youtube.com/watch?v=JE-vLFMTXxM
Update: I'm on the nixos-unstable "rolling distro" so I don't actually need to do anything.
Also if anyone is wondering, nixos-unstable feels very stable as an end-user.
Also if anyone is wondering, nixos-unstable feels very stable as an end-user.
Seems like a good time to flatten my Dell windows 11 laptop and install Nix on it. I've really loved using NixOS in various VMs but the experience is so good I want to use it full time.
Any recommendations on how to best set up pre boot encryption and opt in state these days?
Any recommendations on how to best set up pre boot encryption and opt in state these days?
Though I've liked NixOS in the past, the documentation is an absolute mess. I've switched to GNU Guix.
As someone just getting started with Nix & NixOS, I couldn't agree more.
In terms of documentation: the lines between nix-the-language, nix-the-tool, and nixos-the-system are often too blurry. Familiarity with one of the three is often assumed or implied.
Everyone seems to be using Flakes and/or home-manager; the official docs and tools all try to scare you away by labeling it unstable/experimental (if ever mentioning them at all), yet it seems difficult to find third-party resources that don't refer you to Flakes at some point.
The "getting started" manual is very good at getting you to a basic and very usable desktop system, but once you want to go anywhere beyond that, the difficulty (and complexity) immediately ramps up to crazy levels.
The references usually feel like they're complete, but I found it extremely difficult to find a simple answer to quite basic questions of the "how to do X" kind; e.g. I want to supply the same list of packages to python310.withPackages and python311.withPackages, to have both Python versions available system-wide (so I can trivially fire up an IPython shell and hack away at a simple problem). I solved this on other systems e.g. by using stupid text substitutions in a shell script, or calling "python3.xx -m pip -r requirements.txt", but it's still unclear to me how to do it with Nix - do I need to learn more of the language, or more about nixpkgs, do I stick with copy-pasting the package list, etc.
I wish the documentation was even 10% as good as OpenBSD's, but many commands don't even have basic man pages. It's definitely the most intriguing OS I've tried in many years, with a lot of promise for a return on the investment, it's just that it feels incredibly steep to get anywhere when you're just getting started.
In terms of documentation: the lines between nix-the-language, nix-the-tool, and nixos-the-system are often too blurry. Familiarity with one of the three is often assumed or implied.
Everyone seems to be using Flakes and/or home-manager; the official docs and tools all try to scare you away by labeling it unstable/experimental (if ever mentioning them at all), yet it seems difficult to find third-party resources that don't refer you to Flakes at some point.
The "getting started" manual is very good at getting you to a basic and very usable desktop system, but once you want to go anywhere beyond that, the difficulty (and complexity) immediately ramps up to crazy levels.
The references usually feel like they're complete, but I found it extremely difficult to find a simple answer to quite basic questions of the "how to do X" kind; e.g. I want to supply the same list of packages to python310.withPackages and python311.withPackages, to have both Python versions available system-wide (so I can trivially fire up an IPython shell and hack away at a simple problem). I solved this on other systems e.g. by using stupid text substitutions in a shell script, or calling "python3.xx -m pip -r requirements.txt", but it's still unclear to me how to do it with Nix - do I need to learn more of the language, or more about nixpkgs, do I stick with copy-pasting the package list, etc.
I wish the documentation was even 10% as good as OpenBSD's, but many commands don't even have basic man pages. It's definitely the most intriguing OS I've tried in many years, with a lot of promise for a return on the investment, it's just that it feels incredibly steep to get anywhere when you're just getting started.
The lines are often blurry because they are quite interlacing and all where purpose build for each other.
> python310.withPackages and python311.withPackages
I think that should be solvable by supplying them the same function.
env = ps: with ps; [ numpy toolz ] python39.withPackages(env) python310.withPackages(env)
> python310.withPackages and python311.withPackages
I think that should be solvable by supplying them the same function.
env = ps: with ps; [ numpy toolz ] python39.withPackages(env) python310.withPackages(env)
I want to use the expensive hardware I own and from the few examples I have seen guix is incredible verbose often requiring two to three times the code to express the same thing as nixpkgs.
What's the best way to use nix (pkg manager) to set up dev environments these days (i.e. as an alternative to, say, asdf)? devenv.sh?
Creating a vanilla flake.nix for each project to use with nix shell and direnv doesn't seem like a practical approach considering each language has very different requirements and there doesn't seem to be a go to repository of flake templates available anywhere.
Creating a vanilla flake.nix for each project to use with nix shell and direnv doesn't seem like a practical approach considering each language has very different requirements and there doesn't seem to be a go to repository of flake templates available anywhere.
If you are looking for a simple interface that is an alternative to asdf, but uses Nix under the hood, you could check out Devbox (https://github.com/jetpack-io/devbox). Our goal is to make spinning up per-project dev environments easy and approachable, without having to write a full nix.flake.
So far no one mentioned that you can:
- easily cross compile packages: pkgsCross.aarch64-multiplatform.hello
- NixOS has modules to get complete services like Nextcloud, Mastodon or Matrix Synapse up and running within minutes including nginx configs
- it is possible to switch Desktops and clean up all packages
You easily can, but its a pretty miserable user experience compared to non cross-compilation (e.g. build times are incredibly long since happy-path nix is mostly backed by binary cache).
Yeah I’m ready to finally stick with it now I think, having it on my server means no/low effort admin
Recently installed nixos and was trying to get docker installed with little success - I tried googling for a while and came up short. Maybe it’s obvious to veteran nixos users. Does anyone know of a comprehensive nixos guide or YouTube series? I’d love you forever.
Add this to configuration.nix:
virtualisation.docker.enable = true;
The best comprehensive guide is the manual:
https://nixos.org/manual/nixos/stable/
virtualisation.docker.enable = true;
The best comprehensive guide is the manual:
https://nixos.org/manual/nixos/stable/
[deleted]
tmountain's reply has the best direct response to the issue you ran into. Check it out, it's a one-liner. :)
I think video resources are maybe under-emphasized in talk about Nix on HN, and they're important for people who prefer that modality, so I've compiled a list of videos on Nix that I have watched and feel might be helpful for learning it.
There is no comprehensive YouTube series that I can recommend, but you can find really good introductory and overview videos in the form of past conference lectures in the NixCon and NixOS channels on YouTube.
NixCon: https://youtube.com/@NixCon
NixOS: https://youtube.com/@NixOS-Foundation
Here are some playlists and direct references to educational material on Nix and NixOS that I've actually watched. Taken together, they will at least outline all of the normal stuff you might want to do on NixOS, from configuring your system to writing packages to (if you want) leveraging flakes to running your own binary cache.
Reading Nix Expressions (Zimbatm, NixCon 2019) — https://youtu.be/61MuMY9XFNo
Nix: Why and How It Works (Graham Christensen, NixCon 2019) — https://youtu.be/lxtHH838yko
Fearless Tinkering: How NixOS Works (Graham Christensen, NixCon 2019) — https://youtu.be/DK_iLg2Ekwk
Learning the Nix Store Layer (John Ericson, NixCon 2022) — https://youtu.be/utQf4VH7QMw
Overrides: In and Out (Graham Christensen, NixCon 2019) — https://youtu.be/6VepnulTfu8
Nix Flakes in Production: What, Why, and How (Alexander Bantyev, NixCon 2020) — https://www.youtube.com/watch?v=o1Y7rWrPEO8
Nixpkgs Overlays: A place for all excluded packages (Nicolas B. Pierron, NixCon 2017) — https://www.youtube.com/watch?v=W85mF1zWA2o
The Architecture and History of Nixpkgs (Jon Ringer, Summer of Nix 2022) — https://www.youtube.com/watch?v=TKgHazs3AMw
Hydra, Nix's CI (Thomas Bereknyei a.k.a. tomberek, Summer of Nix 2022) — https://www.youtube.com/watch?v=AvOqaeK_NaE
There's also some really good content outside of the official NixOS YouTube channels! See below.
Informal intro to the Nix language, derivations, and Nixpkgs (Silvan Mosberger, from a Nix onboarding for another Tweag employee, recorded 2022): https://www.youtube.com/watch?v=9DJtHIpdp0Y
Burke Libby's Nixology series — https://youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgM...
NixOS 101: Introduction to a Different Type of Linux Distro (Tweag onboarding document, 2022) — https://www.youtube.com/watch?v=pfY9Hc_zChs
Introduction to NixOS (Charles Strahan, NYLUG Presents 2017) — https://www.youtube.com/watch?v=VivXSoovUFI
Nix Flakes 101 (Jörg Thalheim a.k.a. Mic92, rC3 2020) — https://www.youtube.com/watch?v=QXUlhnhuRX4
Why NixOS: An Introduction (Ingolf Wagner, rC3 2020) — https://www.youtube.com/watch?v=0eTgQaNiRF0
Sane System Management with NixOS (Tim Steinbach, LambdaConf 2020) — https://www.youtube.com/watch?v=_LDzO5_d1a0
Nix for Functional Systems (Brian McKenna, YOW! LambdaJam 2017) — https://www.youtube.com/watch?v=mIxtBVKo7JE
There are others out there which I didn't list because I've never watched them, and there are probably some older ones I did enjoy which I was unable to dig up. It's probably really only worth watching one or two of the generic, overview, intro-type videos. But there are plenty of them, so feel free to decide within a few seconds whether one clicks with you, and choose it based on that. FWIW, I think Charles Strahan's NixOS intro video is my favorite of that type.
If you really want a comprehensive lecture playlist, the curriculum I recommend is:
NixCon videos not listed here can be useful for pointing you to interesting, new or important ancillary and third-party projects in the ecosystem. :)
I think video resources are maybe under-emphasized in talk about Nix on HN, and they're important for people who prefer that modality, so I've compiled a list of videos on Nix that I have watched and feel might be helpful for learning it.
There is no comprehensive YouTube series that I can recommend, but you can find really good introductory and overview videos in the form of past conference lectures in the NixCon and NixOS channels on YouTube.
NixCon: https://youtube.com/@NixCon
NixOS: https://youtube.com/@NixOS-Foundation
Here are some playlists and direct references to educational material on Nix and NixOS that I've actually watched. Taken together, they will at least outline all of the normal stuff you might want to do on NixOS, from configuring your system to writing packages to (if you want) leveraging flakes to running your own binary cache.
Reading Nix Expressions (Zimbatm, NixCon 2019) — https://youtu.be/61MuMY9XFNo
Nix: Why and How It Works (Graham Christensen, NixCon 2019) — https://youtu.be/lxtHH838yko
Fearless Tinkering: How NixOS Works (Graham Christensen, NixCon 2019) — https://youtu.be/DK_iLg2Ekwk
Learning the Nix Store Layer (John Ericson, NixCon 2022) — https://youtu.be/utQf4VH7QMw
Overrides: In and Out (Graham Christensen, NixCon 2019) — https://youtu.be/6VepnulTfu8
Nix Flakes in Production: What, Why, and How (Alexander Bantyev, NixCon 2020) — https://www.youtube.com/watch?v=o1Y7rWrPEO8
Nixpkgs Overlays: A place for all excluded packages (Nicolas B. Pierron, NixCon 2017) — https://www.youtube.com/watch?v=W85mF1zWA2o
The Architecture and History of Nixpkgs (Jon Ringer, Summer of Nix 2022) — https://www.youtube.com/watch?v=TKgHazs3AMw
Hydra, Nix's CI (Thomas Bereknyei a.k.a. tomberek, Summer of Nix 2022) — https://www.youtube.com/watch?v=AvOqaeK_NaE
There's also some really good content outside of the official NixOS YouTube channels! See below.
Informal intro to the Nix language, derivations, and Nixpkgs (Silvan Mosberger, from a Nix onboarding for another Tweag employee, recorded 2022): https://www.youtube.com/watch?v=9DJtHIpdp0Y
Burke Libby's Nixology series — https://youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgM...
NixOS 101: Introduction to a Different Type of Linux Distro (Tweag onboarding document, 2022) — https://www.youtube.com/watch?v=pfY9Hc_zChs
Introduction to NixOS (Charles Strahan, NYLUG Presents 2017) — https://www.youtube.com/watch?v=VivXSoovUFI
Nix Flakes 101 (Jörg Thalheim a.k.a. Mic92, rC3 2020) — https://www.youtube.com/watch?v=QXUlhnhuRX4
Why NixOS: An Introduction (Ingolf Wagner, rC3 2020) — https://www.youtube.com/watch?v=0eTgQaNiRF0
Sane System Management with NixOS (Tim Steinbach, LambdaConf 2020) — https://www.youtube.com/watch?v=_LDzO5_d1a0
Nix for Functional Systems (Brian McKenna, YOW! LambdaJam 2017) — https://www.youtube.com/watch?v=mIxtBVKo7JE
There are others out there which I didn't list because I've never watched them, and there are probably some older ones I did enjoy which I was unable to dig up. It's probably really only worth watching one or two of the generic, overview, intro-type videos. But there are plenty of them, so feel free to decide within a few seconds whether one clicks with you, and choose it based on that. FWIW, I think Charles Strahan's NixOS intro video is my favorite of that type.
If you really want a comprehensive lecture playlist, the curriculum I recommend is:
1. Charles Strahan's intro to NixOS
2. Burke Libbey's Nixology series (because his videos are relatively short)
3. The listed NixCon and Summer of Nix videos
4. Mic92's Flakes 101
NixCon videos not listed here can be useful for pointing you to interesting, new or important ancillary and third-party projects in the ecosystem. :)
NixOS' infamous learning curve has an undersung sweet spot. I recently discovered a bit of a ‘vlog’ (the video part is just a static image) describing NixOS from the perspective of a self-described, impatient, fickle hacker, which I think testifies to this very well. It begins:
> I am not a smart man. The difference between success and failure to me, is razor thin. I am impatient. I am hubristic. I am easily bored. I have it in my to be tenacious, but it has to be drawn out by reward at the end. And NixOS ticks all these boxes for me, in a way that other systems really don't.
https://www.youtube.com/watch?v=17-TRCpDizA
I think it's worth listening to as it is, but below, I've tried to condense and summarize the parts of that 30-minute video most relevant to that point, for folks to whom the pacing of a relaxed, rambly, personal monologue does not appeal.
> I'll give you an example. All my systems have the same set of installed programs now. Now that seems real simple. Y'know, they all say, let's say, `screen`, or `tmux, or they all have Ardour, or they all have the same Emacs configuration. I know that sounds basic, but that has never happened to me before [laughs]! I'm just too easily bored [smiles] to invent such a thing that would make it possible for me to do that. [...] System configuration, instead of being this laundry list of chores to be done, becomes a programming exercise. I'm comfortable with programming exercises. I do not like chores.
> [...]
> The integration between Nix the language, Nix the package manager, and NixOS the operating system means that I'm not required to invent very much. [...] Everything I just described to you, I could have done 15 years ago, with systems like Puppet [or] Ansible[.] [...] However, while using those systems, I am required to make choices about how things are done. And those choices really have some stop[ping] energy to them. Some of the choices are so low-level that they're uninteresting, and it becomes rather boring rather quickly to do [something like] Puppet or Ansible. ‘Where is this `authorized_keys` file supposed to go?’ I don't really care! [laughs] I just want [...] to be able to log into that system.
> On top of all that, where [with NixOS, it feels like] I'm just motoring along [unimpeded]— I'm creating a configuration very quickly that rewards [rather than drains] me— at the end of it, I can share that configuration with someone else in a meaningful, even executable, way. And the way to execute it is well-understood. There's no trickery [hidden in the deployment environment]. This is also [supposedly] the same with Puppet and Ansible, but somehow, no one seems to do it! You don't see people sharing Ansible configurations. This culture of sharing configuration, of sharing declarative statements about builds, is something that is [...] in quantity and quality, unique to NixOS.
> I recently heard from a friend [...] who somehow saw my videos [on NixOS]. [...] We never spoke about NixOS before I heard from him [about this]. But he took the configuration that I'd put up on GitHub, [...] made a couple of changes to it, and he got one system up and running. And he said ‘Wow, that was easy!’. This guy has been doing [Unix and Linux systems administration] for 25 years, and I can't imagine that he's ever done such a thing before. [I can't imagine that he has ever] just walked up to some repository, and [simultaneously] had [...] the inclination, the confidence, and the ability to repeat a build [of it] on his own system. [...] He actually said to me at some point, ‘What have you done to me?’ [laughs]. Of course, I didn't do anything. He's well on his way to converting all of his other systems to NixOS.
> [...]
> I think [Nix's features] sort of feed into each other, as a [...] virtuous cycle. Like I said: I am not a smart man, I am not a patient man. I can be tenacious, but it really takes me feeling like I'm gonna get something at the end. [...] [W]ith Nix, I don't feel like I'm wasting my time, I find myself— surprisingly!— getting to the bottom of issues that I could have gotten to the bottom of on Ubuntu, or Manjaro, or Fedora, or whatever else I was using, [but never did]. I could have fixed them there, but man, the reward for doing so was just minimal.
> [...]
> [That's because] first of all, if you're not running a configuration management system, and you have to do it manually on every system... that is really boring to have to do. So the answer is to run a configuration management system. But the configuration management tools that are available for these systems are [...] just me typing, except automated. [...] There are sort of [declarations], but they definitely have an order. And you have to know the order, you have to control the order. In the NixOS stuff, I'm not concerned about order. [...] Nix uses `bash`, under the hood, so of course I'm [actually] running bash— yeah, sure. But I'm not [thinking about it] very often.
> People have anticipated the kinds of things I wanna do in [the] Nix [world;] I just reuse whatever they did. It is [admittedly] a game of inches here. I often found myself in a place, with my other systems, where all of them were configured completely differently. I just didn't bother with configuration management stuff. It's not like I haven't used configuration management tools. I use them all the time. [I use them] at work and stuff, but for my own systems, it just seemed like ‘ugh’. It was like going to work! [...] ‘Ok, now I'm back at work, and I have to name these steps.’ It's dull. It's boring.
> [But] now that I have Nix[OS], I'm getting to the bottoms of these stupid issues, like [...] fixing my computer's sleep. Even though I would have had to do exactly the same thing on Ubuntu or Manjaro or Fedora, or any of that stuff— it's the same system— but I actually do it now. Because I'm like ‘Okay, fine. I can write this down once [and for all].’ NixOS has nudged me over the edge of feeling like I'm not wasting my time [...] and that makes me tend to get to the bottoms of issues. Success [now] more often seems possible than impossible. Before, it just seemed impossible, like
> > I am never gonna get this under control. I am just gonna live with chaos.
> [laughs] Everyone has chaos. But in this game of inches, NixOS has just pushed me over the edge that little bit, to where I have things working that I've never had working before. Some concrete examples:
> - I can bring up a new system with the vast majority of configuration that I actually use in 20 minutes. [...] (20 minutes would be a long time, actually. I would have to make a couple mistakes.)
> - [Due to random differences in sleep behavior, mDNS configuration, and God knows what, before] it was always a crapshoot when I'd type `ssh some-host-name` whether I'd actually get in. [...] Now that all of these systems share the same configuration, that hasn't happened to me.
> - I can print from any system. I know it sound stupid. But yes! I don't print often, but when I wanna print, I just wanna print. That was never possible in my old configurations. I'd always have to [fuck] around with printing.
> - I can shut the lid on any of my laptops that are connected to external monitors... and the won't go to sleep. I know, I know— it seems stupid, but it's true! I figured it out. [Thanks to NixOS], I put enough time into that to fix it.
> - I can shut the lid on laptops not connected to external monitors, and they do go to sleep. They go to sleep! They don't just sit there [...] [shining] the monitor light on the keyboard for two hours, running down my battery. [...] It's because I was rewarded [along the way] when I put the time in.
> - I can carry around [...] an external ZFS-formatted drive, and I can plug it into any of these systems and mount it. It can even be encrypted!
> - Once I log in, I can send and receive Keybase messages on any of these [5] systems.
> - I can use my stupid Roland looper on any of these systems. [NixOS encouraged me to] put the time in to add the kernel patch that it requires.
> - I can use an old build of a package— built years ago— to solve dependency bitrot. The current version of a package I use will not build. But I can transport myself back in time, just for that one.
> Another thing I noticed while I was asking questions in various support channels for NixOS is that it somehow also happens to have a really excellent community. I haven't seen this kind of community in many other places. I saw it (way back in the day) with Python. And before then, [laughs] I think the only other place I've seen it was on bulletin board systems. There's unreal politeness, and humility, and thoughtfulness, and thoroughness on all of the support channels I can think of— Discourse, Matrix, IRC, GitHub. [...] There's no ‘RTFM’, there's nobody flexing there. [...] It is the default [on the Internet] to see people flexing and being assholes in support [...] but there's none of that in the NixOS community. [...] It is astounding to me. How did it happen? [In the NixOS community], everybody is smarter than I am. Everyone. I love that!
> [...]
> Once you give [NixOS] a fair shake, you will not go back to something else. [...] The idea that you would look at NixOS, use it for a month, and then be like ‘eh, idk, I'll go back to Fedora’... I don't see that happening to many people. My mind would be blown by that happening.
> I am not a smart man. The difference between success and failure to me, is razor thin. I am impatient. I am hubristic. I am easily bored. I have it in my to be tenacious, but it has to be drawn out by reward at the end. And NixOS ticks all these boxes for me, in a way that other systems really don't.
https://www.youtube.com/watch?v=17-TRCpDizA
I think it's worth listening to as it is, but below, I've tried to condense and summarize the parts of that 30-minute video most relevant to that point, for folks to whom the pacing of a relaxed, rambly, personal monologue does not appeal.
> I'll give you an example. All my systems have the same set of installed programs now. Now that seems real simple. Y'know, they all say, let's say, `screen`, or `tmux, or they all have Ardour, or they all have the same Emacs configuration. I know that sounds basic, but that has never happened to me before [laughs]! I'm just too easily bored [smiles] to invent such a thing that would make it possible for me to do that. [...] System configuration, instead of being this laundry list of chores to be done, becomes a programming exercise. I'm comfortable with programming exercises. I do not like chores.
> [...]
> The integration between Nix the language, Nix the package manager, and NixOS the operating system means that I'm not required to invent very much. [...] Everything I just described to you, I could have done 15 years ago, with systems like Puppet [or] Ansible[.] [...] However, while using those systems, I am required to make choices about how things are done. And those choices really have some stop[ping] energy to them. Some of the choices are so low-level that they're uninteresting, and it becomes rather boring rather quickly to do [something like] Puppet or Ansible. ‘Where is this `authorized_keys` file supposed to go?’ I don't really care! [laughs] I just want [...] to be able to log into that system.
> On top of all that, where [with NixOS, it feels like] I'm just motoring along [unimpeded]— I'm creating a configuration very quickly that rewards [rather than drains] me— at the end of it, I can share that configuration with someone else in a meaningful, even executable, way. And the way to execute it is well-understood. There's no trickery [hidden in the deployment environment]. This is also [supposedly] the same with Puppet and Ansible, but somehow, no one seems to do it! You don't see people sharing Ansible configurations. This culture of sharing configuration, of sharing declarative statements about builds, is something that is [...] in quantity and quality, unique to NixOS.
> I recently heard from a friend [...] who somehow saw my videos [on NixOS]. [...] We never spoke about NixOS before I heard from him [about this]. But he took the configuration that I'd put up on GitHub, [...] made a couple of changes to it, and he got one system up and running. And he said ‘Wow, that was easy!’. This guy has been doing [Unix and Linux systems administration] for 25 years, and I can't imagine that he's ever done such a thing before. [I can't imagine that he has ever] just walked up to some repository, and [simultaneously] had [...] the inclination, the confidence, and the ability to repeat a build [of it] on his own system. [...] He actually said to me at some point, ‘What have you done to me?’ [laughs]. Of course, I didn't do anything. He's well on his way to converting all of his other systems to NixOS.
> [...]
> I think [Nix's features] sort of feed into each other, as a [...] virtuous cycle. Like I said: I am not a smart man, I am not a patient man. I can be tenacious, but it really takes me feeling like I'm gonna get something at the end. [...] [W]ith Nix, I don't feel like I'm wasting my time, I find myself— surprisingly!— getting to the bottom of issues that I could have gotten to the bottom of on Ubuntu, or Manjaro, or Fedora, or whatever else I was using, [but never did]. I could have fixed them there, but man, the reward for doing so was just minimal.
> [...]
> [That's because] first of all, if you're not running a configuration management system, and you have to do it manually on every system... that is really boring to have to do. So the answer is to run a configuration management system. But the configuration management tools that are available for these systems are [...] just me typing, except automated. [...] There are sort of [declarations], but they definitely have an order. And you have to know the order, you have to control the order. In the NixOS stuff, I'm not concerned about order. [...] Nix uses `bash`, under the hood, so of course I'm [actually] running bash— yeah, sure. But I'm not [thinking about it] very often.
> People have anticipated the kinds of things I wanna do in [the] Nix [world;] I just reuse whatever they did. It is [admittedly] a game of inches here. I often found myself in a place, with my other systems, where all of them were configured completely differently. I just didn't bother with configuration management stuff. It's not like I haven't used configuration management tools. I use them all the time. [I use them] at work and stuff, but for my own systems, it just seemed like ‘ugh’. It was like going to work! [...] ‘Ok, now I'm back at work, and I have to name these steps.’ It's dull. It's boring.
> [But] now that I have Nix[OS], I'm getting to the bottoms of these stupid issues, like [...] fixing my computer's sleep. Even though I would have had to do exactly the same thing on Ubuntu or Manjaro or Fedora, or any of that stuff— it's the same system— but I actually do it now. Because I'm like ‘Okay, fine. I can write this down once [and for all].’ NixOS has nudged me over the edge of feeling like I'm not wasting my time [...] and that makes me tend to get to the bottoms of issues. Success [now] more often seems possible than impossible. Before, it just seemed impossible, like
> > I am never gonna get this under control. I am just gonna live with chaos.
> [laughs] Everyone has chaos. But in this game of inches, NixOS has just pushed me over the edge that little bit, to where I have things working that I've never had working before. Some concrete examples:
> - I can bring up a new system with the vast majority of configuration that I actually use in 20 minutes. [...] (20 minutes would be a long time, actually. I would have to make a couple mistakes.)
> - [Due to random differences in sleep behavior, mDNS configuration, and God knows what, before] it was always a crapshoot when I'd type `ssh some-host-name` whether I'd actually get in. [...] Now that all of these systems share the same configuration, that hasn't happened to me.
> - I can print from any system. I know it sound stupid. But yes! I don't print often, but when I wanna print, I just wanna print. That was never possible in my old configurations. I'd always have to [fuck] around with printing.
> - I can shut the lid on any of my laptops that are connected to external monitors... and the won't go to sleep. I know, I know— it seems stupid, but it's true! I figured it out. [Thanks to NixOS], I put enough time into that to fix it.
> - I can shut the lid on laptops not connected to external monitors, and they do go to sleep. They go to sleep! They don't just sit there [...] [shining] the monitor light on the keyboard for two hours, running down my battery. [...] It's because I was rewarded [along the way] when I put the time in.
> - I can carry around [...] an external ZFS-formatted drive, and I can plug it into any of these systems and mount it. It can even be encrypted!
> - Once I log in, I can send and receive Keybase messages on any of these [5] systems.
> - I can use my stupid Roland looper on any of these systems. [NixOS encouraged me to] put the time in to add the kernel patch that it requires.
> - I can use an old build of a package— built years ago— to solve dependency bitrot. The current version of a package I use will not build. But I can transport myself back in time, just for that one.
> Another thing I noticed while I was asking questions in various support channels for NixOS is that it somehow also happens to have a really excellent community. I haven't seen this kind of community in many other places. I saw it (way back in the day) with Python. And before then, [laughs] I think the only other place I've seen it was on bulletin board systems. There's unreal politeness, and humility, and thoughtfulness, and thoroughness on all of the support channels I can think of— Discourse, Matrix, IRC, GitHub. [...] There's no ‘RTFM’, there's nobody flexing there. [...] It is the default [on the Internet] to see people flexing and being assholes in support [...] but there's none of that in the NixOS community. [...] It is astounding to me. How did it happen? [In the NixOS community], everybody is smarter than I am. Everyone. I love that!
> [...]
> Once you give [NixOS] a fair shake, you will not go back to something else. [...] The idea that you would look at NixOS, use it for a month, and then be like ‘eh, idk, I'll go back to Fedora’... I don't see that happening to many people. My mind would be blown by that happening.
Is it like docker?
Anyway trying my hand on Kivy. Work for once for iOS and android undder macOS. Then never so far. Trying Gm even of macOS. No.
May be start again with this and try to install Kivy again
Anyway trying my hand on Kivy. Work for once for iOS and android undder macOS. Then never so far. Trying Gm even of macOS. No.
May be start again with this and try to install Kivy again
Nix is a package manager and NixOS is a distro. It's (very) kinda like a docker and gentoo combination done by haskell people
> Is it like docker?
No. Docker is a way to execute processes (e.g. servers).
Nix is a way to define the contents of files (e.g. an OS filesystem).
No. Docker is a way to execute processes (e.g. servers).
Nix is a way to define the contents of files (e.g. an OS filesystem).
I maintain multiple pet servers. When I used Ubuntu, doing release upgrades cost me ~6 hours per server per upgrade every 2 years. Most of that time went into merging updated upstream configuration files with my changed configuration files, often for silly stuff like upstream changing tabs to spaces in the config file syntax. With the Debian-style upgrader, you also have to wait 5 minutes until you're prompted for the next config file to merge, while other packages are "configuring" with `dpkg`. So you cannot do them all in a batch, but have to stare at the screen throughout the procedure, attending every 5 minutes.
So with multiple servers that was multiple days of upgrades per year.
With NixOS, these days are is reduced to minutes.
For example, on one of my servers I upgraded just now:
This server currently runs:
This is possible because with NixOS, you do not mutate text files in `/etc` for configuration. Instead, you write a structured config similar to a JSON object (but in the Nix language, so you can use stuff like `map` and `filter` to solve repeated tasks over e.g. all the domains in your web server). This config only contains the differences from the default config. So concepts like "does the upstream Apache config file indent with tabs or spaces" no longer play any role.
For the server above, the config file is 800 lines long, of which 200 are comments.
So NixOS is saving me multiple days per year in sysadmin tasks, which is pretty good!