Live data from Hacker News

NixOS 22.11 “Raccoon”

nixos.org

171–180 of 201 posts

Re: NixOS 22.11 “Raccoon”

#171

Earlier quoted context omitted.

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 we…

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.

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 :)

Re: NixOS 22.11 “Raccoon”

#172
post #139

Earlier quoted context omitted.

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 glo…

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).…

> 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:

  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?
If the answer to (1) is no, or the answer to (3) is yes, then it's definitely necessary to consult the upstream documentation on the software you want to use. In the case that a module exists but you need special config, there will always be a way for you to pass configuration options defined upstream directly to the application through your NixOS configuration.

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.

Re: NixOS 22.11 “Raccoon”

#173

Earlier quoted context omitted.

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).…

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

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

Re: NixOS 22.11 “Raccoon”

#174

Earlier quoted context omitted.

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

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.

Re: NixOS 22.11 “Raccoon”

#175

Earlier quoted context omitted.

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

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. toolbox create new_dev_env_or_whatever toolbox enter new_dev_env_or_whatever dnf install all_the_things And now you've got a container with whatever installed. To use it you do have t…

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.

Re: NixOS 22.11 “Raccoon”

#176

Earlier quoted context omitted.

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.

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.

Re: NixOS 22.11 “Raccoon”

#177
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.

Re: NixOS 22.11 “Raccoon”

#178
post #144

Something that isn't stated in this thread yet is how easy NixOS makes version upgrades. 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. Wit…

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

Re: NixOS 22.11 “Raccoon”

#179

Earlier quoted context omitted.

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 we…

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.

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.

Re: NixOS 22.11 “Raccoon”

#180

Earlier quoted context omitted.

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

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!

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...
Post reply on HN