I’m looking forward to the day Debian is fully reproducible and has rollbacks.
A few more thoughts about how some of the distro maintenance work carried out by companies like Red Hat and related features might be nice in the Nix world:
- ABI stability may not matter for packages in Nixpkgs, but it would be nice for using Nix to generate or otherwise supply runtimes for third-party software
- sometimes end users want stability of behavior, so they don’t want to be confronted with the latest changes to the KDE or GNOME user interface every few months or whatever. In that case, maintaining older viersions provides some value for them
- It’s true that Nixpkgs neatly elides the need for complex dependency solvers and version constraints internally, but when you are working outside Nixpkgs (i.e., on a personal or company project), often you want to pin a specific version of that package but you are essentially forced to think about versions of Nixpkgs. This has led to the creation of things like the Nix package versions search tool, and the sophisticated machinery in the mach-nix Python packaging tool that searches through past copies of Nixpkgs to find versions of Python packages satisfying given constraints. It would be nice for there to be some standardized tooling for this, even if Nixpkgs doesn’t need it, imo.
- it might also just make things a bit neater and more unified when we do occasionally need more than one version of a package in Nixpkgs. Maybe we’d end up with version constraints in the relatively low-stakes way that they appear in other source-based package management systems like Portage and Pkgsrc
- this is still different from the universal reliance on version constraints to navigate global package namespaces in binary package management systems like RPM!
1 Like
I don’t think /g/ represents the tech community so much as posters who see what operating system or other software they use as a basis for identity formation, or just making jokes. More than just NSFW, I find the kind of discussion that happens on /g/ to be extremely shallow. That’s why presentations at tech companies and the discussions surrounding such presentations are much more interesting to me.
True. But anonymity has its benefits. People are more willing to criticize things.
Very enjoying talk. You’re an entertaining presenter. I especially enjoyed the part where you got upset at how easy the filesystem configuration was. I vaguely recall feeling that way when I was looking into NixOS years ago … “they must be glossing over the details because it can’t be that easy!” 
4 Likes
Thanks, your comment also made me recall my epic struggle to run Nix on Android. My usual road to figuring out the.thing.I.wanted = myWay; isn’t a walk in the park or even a rollercoaster ride, but a single sudden abrupt freefall. Sometimes I’m not even at my PC at that moment! Wonder if it’s just me or a recurring problem with Nixers. Can the lack of the steady problem-solving progress mess up dopamine release regulation? =)
I concur, I’m curious about the most popular questions after a talk like that, coming from a background of a distro like RH.
My local community of “Linux integrators” mostly use RH/CentOS or Debian/Ubuntu and it’s very difficult to create the interest just by linking pages with blog posts and/or configuration examples…
1 Like
Very cool talk, thanks for sharing!
A small nitpick: somewhere around 50 minute you said
I think no body ever thought “Hey, I want to run NixOS inside a container inside NixOS!”
Sure we do! 
I’m running a bunch of nixos containers via containers option on my home server which has a benefit of providing namespace isolation to the services. And with containers.<name>.ephemeral option I can guarantee that the service is fully reproducible since container will always start with an empty root fs.
5 Likes
Thanks. Probably not the only hyperbole I’ve used in my talk. I’m not surprised that it’s possible, but I’d rather like to see namespace isolation happening at systemd level and NixOS magic only get involved if you up the game to NixOS’s excellent lightweight VMs.
2 Likes
I’m not sure if this is quite what you mean, but containers is already in fact just a convenient/enhanced NixOS interface for a nice little wrapper around systemd-nspawn, and NixOS also gives you more direct access to systemd-nspawn if you prefer.
I meant directly at the systemd service level.
1 Like
You mean you’d like to see NixOS services use namespace isolation by default, like to enable running multiple versions of the same service on one NixOS host, but without really having to think about/define whole NixOS containers in order to achieve that?
Sorry for still not quite getting what you mean.
I want AllowlistedDirsServiceIsAllowedToSee=/var/myservice,/etc/myservice,/run/myservice,... isolating service with user namespaces on NixOS and non-NixOS alike. And I think there already was some movement in this direction in systemd.
3 Likes
Ok yeah that make sense. For systemd itself to offer a kind of simple, lightweight policy layer based on user namespaces.
Idk much about full fat policy systems like SELinux or AppArmor, but I like the idea of Linux having something for restrictions like that which is (a) simple to configure for simple use cases, (b) common to almost all distros, and (c) can be implemented per-service by upstreams as modifications to files that many already ship.
1 Like
Alright I feel like I’m necroposting at this point, but I just stumbled upon the confinement options for NixOS services. Have you seen that module? It looks like systemd options somewhat similar to you describe already exist, and that’s what’s used in the module! Check out BindPaths, BindReadOnlyPaths, and RootDirectory in the systemd.exec manual. If you want to help push this forward in NixOS,
- there’s an open issue about confining NixOS services by default, and
- it looks like the module doesn’t yet have facilities for adding writeable
BindPaths, like into/varas you describe, but that could be fairly easily added.
I know this isn’t quite as simple or direct as what you suggested, since it’s all given in terms of an explicit chroot, but to me, it seems kinda close to what you wanted.
2 Likes
it’s only 6 days old, that is still warn to the touch fresh!
gross!
Great video! I’m a bit late to the party here.
To be fair to the FHS model, I will say that “broad CVE security patches” are something you can easily apply and are painful in Nix due to recompiling most of the dependency graph; the caveats being if at a certain point there is a fixedOutput derivation.
I know Guix and (I think technically Nix), have something akin to “grafting” but then you bring back the whole ABI compatibility problem which NixOS has amazingly avoided.
1 Like
This was one of the largest topics in the ensuing discussion, considering the audience was mostly Security team. I, personally, hope some content-addressing, hash-scraping/reintroducing and delta downloads can be used to keep the rebuild-all attitude and keep the user side experience smooth as well. As per rebuild-times, ability to rebuild a distro quickly is crucial anyway, Nix or no Nix.
1 Like
Eelco published a paper on delta binary patches but from what I can tell, it hasn’t seen wider adoption.
I’m curious to more understand how Guix will deal with grafting — there may be room to apply some of Debian’s ABI compatibility tests here to get a good middle ground.
Spack is a tool that is interesting in this space that is trying to be a middle ground as well.
2 Likes
Security people should biting at the bit for a bit of nixos.
example Libc6 security problem only effecting a few network services??? no problem… normal system, you gotta upgrade it FOR EVERYTHING on that system, as everything dynamically links it…, unless you go back to the stone age and statically link everything (the docker/go solution). Or mess around with Dynamic linker path on start up…which akin to basically nuking yourself from orbit. (it’s the only way to be sure).
Nix/OS… just upgrade those services that need the patch… bingo your done. lights out and you can go home… or if your working from home, you can move from the office to the kitchen and sudo make me a sandwich.
unfortunately, the word Spack is my language, is very very bad slang word. much worse than coq, but hey naming things in computer science is hard…especially when english is not your first language.
1 Like