00:22
<ajs124>
For future reference, if anyone finds this when searching for dm-event.socket and nixos: the upstream unit has DefaultDependencies=no. If you set it Before = sockets.target, it actually starts. If I had to guess, I'd say that redhat starts this in the initrd, but since we don't have a systemd based initrd (yet), we can't do that.

02:15
<la-s>
adyatlov: the dynamic linker is really just "${pkgs.glibc}/lib/ld-linux-<arch>.so.1", so you can just do that for the 32-bit package set, which I don't remember how to access, but I do know that there is a way

02:34
<evanjs>
hrm. so until #88523 is merged, I'm trying to copy what nixos-generate does but in a nix expression. Getting to the point where I'm building images... but I'm failing on python2.7.18 for some reason

04:01
<{^_^}>
ldlework: If you're updating a package file in nixpkgs that starts with something like `{ stdenv, cmake }:`, use `nix-build -A the-package-attribute` in the nixpkgs root with the corresponding package attribute to build it. The mapping from package attributes to package files is in pkgs/top-level/all-packages.nix

04:19
<ldlework>
adisbladis: when I try to use poetry2nix to build my python library it says, Package ‘python2.7-cachetools-4.1.0’ in /nix/store/pj1i450cs7fnq12xd5nd7gypsaci9l2f-nixos-20.09pre225264.683c68232e9/nixos/pkgs/development/tools/poetry2nix/poetry2nix/mk-poetry-dep.nix:89 is marked as broken, refusing to evaluate.

05:45
<ldlework>
adisbladis: let's say i have a library and a cli project. i use what you did on the first. i specify my dependency on the library in the cli's pyproject.toml. what do I do then? poetry2nix wont be able to find my library, as it's something i've packaged with nix.

05:58
<quinn>
ultranix: i don't think you can set an environment variable for a derivation outside of the build process. if you want to set one inside the build process you should be able to just add SDL_VIDEODRIVER = "wayland" to the attribute set you're passing as an argument for .override. however if you do want to set an environment variable for the whole system, you should add it to your configuration.nix.

06:50
<cartesian-theatr>
Hello! I'm a newcomer to Nix just evaluating the stack. It looks really neat. Is ARM support for NixOS still being actively worked on? Are there any active ARM distribution channels?

06:50
<ldlework>
why is 'fab' not available when i enter into the nix shell?

06:52
<energizer>
ldlework: there were some features added in the last couple weeks for that

06:58
<pjt_014>
cartesian-theatr: Only two real problems: it needs its own copy of nixpkgs (and I can't figure out how to selectively update the submodule), and the way to include custom configuration is non-obvious

06:58
<energizer>
there was a series of commits about this, infinisil and adisbladis would know the details

07:01
<pjt_014>
cartesian-theatr: No, most simple packages can already be cross built fine, with something like nix build -f channel:nixos-unstable pkgsCross.raspberryPi.nq (don't worry, all that autocompletes after the 1st time)

07:05
<energizer>
ldlework: i think there are a few different options. for adding a couple packages to the nix-shell one option is to make a shell.nix with `let pkgs = import <nixpkgs> {}; app = pkgs.callPackage ./default.nix {}; in pkgs.mkShell {buildInputs = [app foo bar baz];}`

07:06
<pjt_014>
cartesian-theatr: if the target system is nixos (anything with just nix the package manager might work too), then nix-copy-closure --from ip /nix/store/path followed by nix-env -i /nix/store/path will copy over and install something

07:08
<cartesian-theatr>
pjt_014 Yes potentially. I'm interested in deploying to a small robotic fleet in the field and building out local dev workflows to ease the pain of getting builds onto machines for testing.

07:09
<pjt_014>
energizer: real quick do you know how to use the nix shell with a package from unstable? It's something like nix-shell -I nixpkgs=? -p name

07:16
<pjt_014>
cartesian-theatr: It's not so much a 'feature' as a side-affect of of how nix is structured. But it is very much better than installing things in home. It *feels* like a security problem at first, but most dangerous tools already require sudo so there's no harm in a normal user installing them

07:39
<cartesian-theatr>
pjt_014 I see, thanks. I have one question about NixOps. Have you (or anyone else) for deployments to essentially highly intermittently available machines? I'd like to push deployments all at once and have them apply as machines come Online and be able to monitor the process as it unfolds.t

11:15
<balsoft>
I've just had a crazy idea: what if instead of banning builtins.fetchTarball without sha256 in restricted mode during flake eval, we actually performed it and then saved the sha256 to flake.lock? Same with fetchGit without rev

12:52
<shreyansh_k>
infinisil: Thank you very much. It is working. With that out of the way, here is a follow up. Until this point, I understood that `override` is the way to override a package expression, is `override` not recommended anymore and is it deprecated?

13:13
<kraem>
am i misunderstanding if fetchGit is supposed to check my .gitconfig and use the https to git@git substitution defined there to use my ssh-agent when cloning private git repos? right now it's launching seahorse for me to enter username + password which doesn't work when having 2FA enabled on github

13:16
<tyrion-mx>
I am trying to compile Python from its source distribution. I am doing ./configure and make, but it is not finding zlib, even though I am using nix-shell to install it. I really don't know what I am doing wrong, and I didn't manage to find anything online. Could anybody please help?

13:30
<betaboon>
srk: gonna try your workaround on monday. i need to build a rootfs-tarball to use as nfsroot on orangepi :/

13:32
<srk>
betaboon: I can publish the patched staging branch if needed but most of the stuff is PRed or merged I think

13:32
<tyrion-mx>
balsoft: it worked \o/ thank you. The main difference I see, is that after your command if I run `env | grep zlib` I see CPPFLAGS and LDFLAGS defined, with nix-shell all the variables were prefixed with `NIX_` ... I wonder why?

13:52
<calbrecht>
i mean like there are sha256 hashes in the RECORD file, maybe that's why e.g. psutil is trying to build again even when all libs are already built and present by python.withPackages

13:54
<nixbitcoin>
How do I override an option in a module that's already specified somewhere else?

13:55
<infinisil>
nixbitcoin: Set it again with a higher priority, e.g. `the.option = lib.mkForce "the-value"`

13:57
<evanjs>
infinisil: on a related note, any recommendations for multiline searches across nixpkgs? Like, I always have issues finding things like e.g. virtualisation.virtualbox - where the attribute might be spread across multiple lines, etc

13:59
<evanjs>
*throws rnix at* :P No but I guess that makes sense. Noteverything can be done with regex :P

14:01
<infinisil>
evanjs: What this would also allow is to have inter-file searches. E.g. if you had declared `foo = import ./foo.nix` and foo.nix had `{ bar = 10; }`, you could search for `foo.bar = ?` and it would find that

14:01
<infinisil>
I guess it wouldn't be AST node search then, but rather expression search

14:07
<nixbitcoin>
infinisil: thanks, where is that kind of stuff documented?

14:07
<Henson>
Hi everyone. I'm trying to use Nixops and have deployed to a remote system and set up the remote SSH key. Then I realized I made a mistake and reverted the remote system, but nixops doesn't know that. Now I can't connect to the remote system because it's expecting ssh public key auth to work, which it doesn't. Can I disable ssh public key auth and redeploy by using ssh keyboard-interactive?

14:07
<hyper_ch>
finally I have KDE file chooser in Thunderbird instead of the GTK one :)

14:09
<hyper_ch>
Henson: I found this: https://phabricator.kde.org/T10189 so I added xdg-desktop-portal and plasma5.xdg-desktop-portal-kde to the system packages. Then I added Exec=GTK_USE_PORTAL=1 to my ~/.profile then I run once Exec=GTK_USE_PORTAL=1 /run/current-system/sw/bin/thunderbird --> that worked

14:11
<clever>
Henson: ensure the agent is running, and ssh-add a key to it

14:11
<Henson>
clever: right, but Nixops deployed to that machine, sticking its public key into the remote machine. But the remote machine has now been rolled back and doesn't have that key anymore, so nixops can no longer connect. Before the first deployment it would ask me for the password, which is all I need to do to redeploy and fix the problem.

14:12
<hyper_ch>
Henson: gimp has its own file chooser that's not affected as it seems

14:12
<clever>
Henson: you may need to edit /root/.ssh/authorized_keys first, to ensure you can get in

14:12
<puzzlewolf>
Is 19.09 still supported? The Vulnerarbility roundup contains a lot of issues for it. Do we backport security fixes?

14:15
<Henson>
hyper_ch: I use thunderbird, too, and one thing that drives me crazy is that in Nix the up and down arrows in the e-mail list scrollbar are missing, and the default behaviour (without editing the GTK3 style file) is to have the scroll bar jump to where you clicked it. So if you have 25,000 e-mails in your inbox (which I do), then it's very difficult to navigate.

14:18
<hyper_ch>
Henson: it's file choser dialog... e.g. want to save an email or attach a file... it drives me crazy that gtk file choser does not sort folders first and difference between folder and file is barely visible

14:19
<hyper_ch>
Henson: still not sure what you mean.. you mean in the file chosing dialog?

14:19
<Henson>
hyper_ch: you know at the top and bottom of a scroll bar there are up and down arrows to move the list by a little bit at a time? In my thunderbird those are gone, it's just a scroll bar.

14:36
<Henson>
clever: yes, and when I tried defining the NixOS machines in there it gets upset. I import some NixOS modules into the Nixops configuration. When I define the NixOS containers within a machine, the config that is passed into the container, is not the same config as it used to define the machine, and I am unable to access the custom modules I've imported into the nixops configuration.

14:38
<Henson>
clever: it was simply unable to find the additional NixOS modules that were overlaid onto the configuration. In the Nixops network definition that modules were present, but you define the NixOS container with a lambda that takes an attribute set as an argument, with one of those arguments being "config". That config used to define the NixOS container did not contain the modules overlaid onto...

14:38
<Henson>
clever: the config that was being used by the nixops network definition.

14:39
<clever>
Henson: it works the same way outside nixops, the containers are an isolated nixos instance, with their own module set

14:39
<Henson>
clever: so there were options I had to specify in the container that I was unable to because those options were not visible in the config that was being passed into the Nix container definition.

14:39
<clever>
Henson: you need to add the module to the imports of each container

14:42
<Henson>
clever: I'm still stuck on the Nixops password thing. I've added my id_rsa key with ssh-add, and have added it to authorized_keys on the remote system, but it's still not letting me in. It's quite possible that passwordless logins for root are disabled on the machine I'm deploying to. All I need is for nixops to ask me for a password. I'm going to edit the nixops database file to remove the...

15:15
<kraem>
when running `nix-shell -p nix-prefetch-git --run "nix-prefetch-git https://github.com/kraem/private-repo"` it prompts me for username + password for github. but when i run `./nix-prefetch-git https://github.com/kraem/private-repo` directly from a clone of nixpkgs it reads my gitconfig and ssh credentials and downloads the repo fine. why is this even though i didn't provide --pure to nix-shell?

18:02
<bqv>
emily: not sure which cli tools you mean, but i just reexport my amended pkgs from nixpkgs as self's legacyPackages, so i can always get system-matching packages from either packages or legacyPackages

18:05
<emily>
bqv: I figured out how to do it though: (getFlake "path:/nix/store/nd8w6gkh2jzrzkkkwpmzwk9v5kzzqk68-source?lastModified=1589859699&narHash=sha256-%2fI9KUnlMs+vf0Zb5ZHmfgQFSphtWguJ49wPM7cqjwqw=").inputs.nix.overlay works in pure mode

18:45
<emily>
additionally, you cannot access the configuration values with the same names you set them by (the final configuration is available as the config argument, but that's not quite the same thing)

18:53
<Henson>
in nixos configuration, if different modules depend on values from other modules, the configuration gets iterated until it reaches a fixed point, so even the ordering in which the files are imported doesn't matter, right?

19:01
<emily>
energizer: yes, import order matters. the most imperative part is the "merging" step, which is basically updating the entire config with new values "as if" it was mutable state, yes, but the actual modules themselves don't have mutation in them

19:01
<emily>
but it doesn't mean that doing { haskellPackages.blah = ...; } inside an overlay is an imperative assignment per se, it's more like you're describing overrides to be performed declaratively

19:02
<bqv>
you know the thing that does `:p` in nix repl; is that exposed as a builtin?

19:02
<energizer>
unless you do haskellPackages.blah = first mypackageList

20:11
<cransom>
using dhall to give me a list of packages to install seems like it would be analogous to having something like vault or a secret store telling me which packages to install. it's just not quite the right layer for it

20:11
<betawaffle>
An array of strings, right. The point is, you could do the same with dhall, if you needed to. You just don’t get all the functionality of nix.

20:14
<bqv>
it makes sense to think of it as dhall's output is glorified json. nix's output is ...well i don't even know, json values with side-effects? and dhall and nix can only interop using that json similarity layer

20:28
<das_j>
oof, has anyone managed to evaluate a minimal system with flakes? I dropped everything except the flake.nix and some basic configuation.nix, but fetchpypi from nixpkgs gets called with the wrong fetchurl :/

20:57
<emily>
das_j: right now I set nixpkgs.overlays = inputs.self.overlays and re-import nixpkgs to re-export its legacyPackages, but it's kind of a mess... I'm wondering whether I should make a flake for "nixpkgs with all my overlays applied" and then just depend on that to avoid the mass duplication

20:58
<emily>
but it feels like flakes probably needs to grow some mechanism to natively handle overlays if this is going to work well...

21:00
<emily>
anderson_: you could maybe get it to output into $out instead but it sounds like it probably just shouldn't be making this directory at all?

21:00
<emily>
most "ensure this directory exists because we need it at runtime" install script stuff mixes badly with cross-compilation, packaging, and so on

21:01
<emily>
das_j: input.nixpkgs doesn't take any arguments, does it?

21:01
<bqv>
emily: the way i see it, flakes have been designed without the current model of nixpkgs in mind; i feel nixpkgs should change to fit flakes rather than the other way around, and i think that's the current aim. in the mean time, the current hacks work well enough

21:01
<emily>
bqv: how would you like to see it change? afaict the only nice way to define and export packages across various systems in flakes is to define an overlay and re-export from the overlayed nixpkgs

21:02
<betawaffle>
bqv: what sort of changes do you foresee in nixpkgs?

21:04
<bqv>
emily: nixpkgs is a monolith. if chunks of package dependencies were at the flake level, you don't have to import the entirety of nixpkgs repeatedly, you could just import your forked flake of the part you want to change, and use that

21:05
<das_j>
Is it advisable to inherit nixpkgs packages into my config repo? This way `nix run etc#pkgs.hello` would evaluate even if I didn'T override it

21:06
<gchristensen>
you don't need to complain OR give a solution, just report the use case and awkwardness

21:06
<emily>
I feel like a decent step would be allowing flakes to take structured arguments so that the nixpkgs flake could be parameterised on overlays, maybe. but that's a big change and there might be a simpler thing

21:06
<emily>
bqv: packages attr requires you to enumerate every system upfront

21:06
<emily>
and the systems people enumerate in practice are much less than what nix(pkgs) can actually compile things for

21:14
<bqv>
so what you're saying is, the fact that overlays are fundamentally problematic, is the reason we should definitely keep using overlays :p

21:14
<emily>
I guess the latter is the part I haven't convinced you of, but, like, as it is overlay/overlays are the only way to export a package from a flake that isn't attached to a hardcoded system identifier.

21:18
<bqv>
makes sense. in my theoretical world, the flake you're trying to overlay would not contain hundreds of packages and wouldn't depend on every package in existence, but only a small subset. you'd have a dependency graph somewhat like nix derivations are, so you can adjust small parts of the tree. that's a change that has to be made to nixpkgs, not flakes. but i do take the point about systems being a

21:21
<emily>
I do think "forcing you to maintain a fork of nixpkgs just to bump some package that is used as a dependency" kind of sucks though, so I'm not sure I'd go for entirely removing overlays even if there were solutions to the non-monkey-patch-y usecases

21:21
<bqv>
i think you're misunderstanding my idea, but it sounds like i'm also misunderstanding you, so maybe i'll just give up and start drinking the wine i've been putting off

21:22
<emily>
I just don't quite see a concrete design that makes everything work out. you can't just remove the system from packages.<system> because it ends up tied to a nixpkgs that assumes a system (I think?)

21:23
<emily>
like the whole reason that's a thing is because nixpkgs has to evaluate itself with different system settings to even work

21:32
<das_j>
what? our flake.nix needs home-maanger for systemA, but not for systemB (as home-manager is not used there). however, systemB will also download the home-manager flake because it's an input of the shared flake.nix

21:35
<energizer>
i havent used flakes, does flakes want you to define configurations for multiple systems in a single flake?

21:43
<das_j>
the host I'm currently working on evals in pure mode, but the <> syntax was really useful. Sadly, I had to add all "channels" to the args, instead of using scopedImport (clever explained how that disables all eval caching)

21:44
<das_j>
also, as I wasn't there when he replied I forgot to clever++

22:08
<emily>
I agree but feel like there's somewhat of a bleed between "known configuration" (flake.lock) and "declarative dependency spec" (flake.nix)

22:09
<evanjs>
lassulus: right sure more wanted to clarify how it functions/what the current limitations are at the moment

22:09
<evanjs>
In our case, it’d be generating images from a VM on eg an ESXi server, etc

22:09
<emily>
explicit is good, which is why I'm not sure that flakes being able to implicitly introduce dependencies for downstreams is a good thing. but then, it depends on whether you think flakes is something to make system deployment nicer or something to turn nix+github into crates.io/npm, I guess

22:11
<emily>
tbh I think this is a fundamental rift: "nix(pkgs) is good because there's a trusted consistent monorepo and you can fix your whole environment declaratively" vs. "nix(pkgs) is awesome because you can have 500 versions of everything and install whatever without worrying"

22:22
<simpson>
emily: I'm not sure I understand this split, TBH. To me, nixpkgs is a *ports tree*, and ports trees inherently can contain all of these ideas, and it's kind of the point to be able to do many heterogenous things while relying on the homoousious nature of everything fitting together.

22:23
<emily>
I mean if you're going to have a separate overlay repo it makes sense for it to be a flake

22:36
<bqv>
adisbladis: i think that sentiment even without context is slightly problematic. I read it as "We screwed up once, let's never try and improve again, the status quo might be poor but it works"

22:37
<colemickens>
It first happened after a `git gc` months ago. Went away. Came back yesterday, no idea why. Has to do with how much stuff? is in git?

23:07
<adisbladis>
Don't hesitate to give me a ping if you're really up for maintaining a fork

23:07
<ldlework>
I have been working on a system called Blot, in Python for a few years, which is like a "programmable content pipeline" where you transform arbitrary data and then map it to templates.

23:08
<ldlework>
And it's really coming around. But I have been thinking for days "It should really be Nix"

23:09
<anderson_>
bqv: in fact it was my idea initially, but I want to test Nix overlay framework. Maintaining tde in a separated overlay allows me to be a bit more bold in experimentations and not to polluting Nixpkgs with bugs until nixpkgs-tde becomes sufficiently mature.

23:10
<abathur>
I've been daydreaming for a bit about a content-building pipeline for a edu company I'm on contract with

23:11
<anderson_>
In a foreseeable future, I want TDE as first class citizen of Nixpkgs. But I prefer baby steps and "showing something that really works" first.

23:12
<abathur>
it's hard not to think it could be nix, and I've looked a little at the recursive-nix work, but some of the assets are videos and I haven't decided whether it makes sense for them to get copied into the store

23:12
<ldlework>
adisbladis: if you make me a maintainer of a Styx fork, I'll at least merge the pull request :P

23:12
<ldlework>
adisbladis: I could also go around to any other existing forks and maybe pull in anything else anyone has done in the interim

23:19
<abathur>
energizer: mostly just logistics/confidence? Small company, fairly large in-house NAS serving video, limited ability to duplicate the entire set around for a build system, can't imagine convincing them to just delete the non-store copy

23:32
<yutyo[m]>
I came here to rant about NixOS being bad. Global installations of some packages is a thing you need, especially when updating that specific package manager and runing several stuff independent from the system.

23:32
<energizer>
yutyo[m]: if you're fighting it like this, you'll end up wasting time

23:33
<yutyo[m]>
You can't even install software from their source code like a sane person. Is that a normal thing?

23:33
<colemickens>
Those of us here are mostly familiar with this "limitation" and are okay with it. I'm not sure what you're hoping to accomplish. We could help you with the original goal, but you haven't told us what you're trying to do.

23:34
<yutyo[m]>
The documentation is bad, and its impossible to understand how to use it.

23:35
<ldlework>
yutyo[m]: it's to even describe how nix works and what it's value propositions are, even in conversation

23:35
<adisbladis>
Let's start here, why do you think you want a global install of anything? That's counter to the Nix model.

23:35
<yutyo[m]>
<ldlework "yutyo: Why do you think global i"> Because those particular package managers work that way, that you can update it with global installation of its version and having some cli software being made for global usage.

23:35
<ldlework>
i think we're still figuring out the best way to present and document the ideas behind it and how to use it best

23:35
<adisbladis>
In fact, if you think Nix is so bad why are you using it in the first place? What was the draw?

23:37
<energizer>
yutyo[m]: i agree it is difficult to use nixos simultaneously with other package managers. i decided to surrender to nix and only use its package manaegr instead of the others. that works better for me

23:37
<anderson_>
yutyo[m]: in Nix, you could do it via nix-shell. It provides a clean "sandboxed" environment.

23:40
<ldlework>
yutyo[m]: think about when you manage 5000 compute instances. you don't want engineers logging into them and manually fixing this or that. if something breaks in the future, we don't know if it's because of our main config, or what the engineer did.

23:40
<ldlework>
the better you can make the declarative configuration, the more reliably equal your compute instances will be. which means they should have the same problems, or not have the same problems, but they should all be the same

23:40
<ldlework>
you wanna fix that problem in the main config, so that all the servers benefit from the fix

23:42
<Henson>
I've come from Debian and Ubuntu to NixOS, and have switched many of my servers over to NixOS. At first I found the Nix way of doing things quite frustrating, but after sticking with it and understanding the motivations and benefits, I enjoy it. I find it much easier to make my own packages for Nix than for Debian.

23:42
<Henson>
if NixOS isn't your thing, then you can use another distribution with the Nix package manager just for installing non-system packages. I do that on my friends' computers to let them use old packages that aren't in Debian or Ubuntu repositories anymore.

23:51
<MichaelRaskin>
Reasoning about complicated setups is hard in any case, having some guarantees makes it simpler

23:51
<anderson_>
yutyo[m]: I am oldschool in that regard. I was from a time of expensive internet connection in my country. I used the servers of my high scool in order to not pay higher bills in my house :)

23:53
<multun>
yutyo[m]: nixos is currently targetted at os / system hackers. It's really nice when you have to install some software without containers on an heterogeneous set of servers. it's also super good for packaging / deploying / testing custom software end to end

23:54
<yutyo[m]>
<anderson_ "I tried to do it in Arch, but no"> Dude, Arch is literally the easiest thing if you compare it to NixOS. Even Gentoo is way easier than NixOS.

23:54
<colemickens>
I have never to configure upower twice. I've never had to configure Sway twice. I've never had to apply that weird PA patch and weird PA config for my system, every single time I reinstall. I've never had to configure anything related to any cloud, yet I can boot my exact system configuration and services in Azure/GCP/AWS in a matter of a minute or two.

23:54
<colemickens>
"Arch is easier to configure than NixOS" is something I would openly laugh at and can point at numerous examples of my nixcfg that shows that to be untrue.

23:54
<yutyo[m]>
<multun "yutyo: nixos is currently target"> I actually love hacking and tinkering, but not in a system that nothing works and there is no proper documentation.

23:55
<anderson_>
yutyo[m]: maybe my brains are wired in a different way. I think NixOS is way easier to understand than a bunch of loosely related PKGBUILD scripts.

23:55
<yutyo[m]>
<colemickens ""Arch is easier to configure tha"> Dude, I laugh to you guys for thinking a distro where you can't install from source, do global installations and need to use strict rules to be easier than Arch, Gentoo and even Linux From Scratch.

23:55
<colemickens>
I build from source all the time. You just want to be angry instead of learn. It's really that simple.

23:57
<abathur>
yutyo[m]: hope you have a better time on Arch. No reason to suffer for something you don't want/need or see the benefit in.

23:57
<samueldr>
if you prefer using a mutable system, where things are barely reproducible, feel free, you can even continue using nix on there for non-system tasks!

23:57
<yutyo[m]>
<abathur "yutyo: we can install ~everythin"> Well, several programs doesn't tho as NixOS doesn't support global installations, some programs like Electron (I know it exists, but you need a long command for it rather than "electron .", that I needed to add to all of my software), and a sane file hierarchy.

23:57
<Henson>
one thing that NixOS can do that others can't, which is the whole reason I use NixOS, is upgrade safety. You can do an upgrade and if there are problems, just reboot to go back to the previous state, or do a rollback. Super easy, super safe. No more failed distribution upgrades and manual package installations. No more bricked systems.

23:57
<multun>
yutyo[m]: nixos is also a very interesting alternative to maintaining infrastructure with ansible / salt / whatever

23:58
<yutyo[m]>
I couldn't work on any of my former projects when I was using NixOS.