Nixcon 2019 - Lightning Talks
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Czyż, Tomasz
Jellema, Lars
Shatsky, Eugen
Mahut, Marek
Sosedkin, Alexander
Kozar, Domen
et al.
nix-cluster (xc) - Tomasz Cysz What makes a forematter? - Lars Jellema Nix Gui. Visualizing Nix store and scope - Eugen Shatsky Configuration management with Morph - Marek Mahut Nix-on-Droid: when the low-hanging fruitis also the ripest one - Alexander Sosedkin Hercules CI - Domen Kozar et al.
 Let's get rolling. We have about five of them, I think. The first one is Tomas with his next cluster. Hello again. So I deploy a lot of servers in one of the companies I'm helping with, we shareably. We have around 1,000 hosts, which is relatively fine. And I use different kind of tools. I use Nixops, I use Terraform, CloudFormation, whatever crap is on Azure, and all those Google services. And they have some issues. So the big gray box is just a tool, right? And it has fixed logic for quite a few components. One of them is fine. And for me, especially the rollout or deploy strategy, which is hardcoded into those tools, it's really, really crap. I have a lot of environments which are completely different, right? So first of all, they have hardcoded abstractions. I cannot create my own abstractions. Or maybe Nixops is a little easier, but still. The deployment strategy is fixed. Sometimes it's parametrized. You can do parallel or sequential. But can you inject your check for the database? Like you want to roll out your database, you have 40 servers of Cassandra, and you want to do one by one node. And it takes like two days. Those tools are really not good for that. And they are really buggy. Anybody use Terraform? Like, hell, right? So there is few, few more. Sometimes you want to extend your tool. And it's not always easy. The state file is like another idea. This concept should really die. And there is more books everywhere. So the idea would be to shift this tool into library. So now the gray big box is our own tool. So basically, we use the pieces from other libraries to build our own stuff. Of course, that makes it a little harder because a lot of glue and error handling is now on our side. But that's not that bad. We can minimize it. And we can try to figure out how we can minimize that and make it better. So what that gives us if we switch from the framework to the library approach, right? We can integrate new abstractions faster. We can describe whatever we want in the language we want. We can put our own rollout strategy. We can not use state file. And we can integrate other clouds or cloud resources much faster than tools. The tool is there to make the pull request proper testing. It's like at least a few weeks or months. And then you have to fork it or something, right? So if we have different kind of deployments like Cassandra or Elasticsearch, sometimes you want the restart cluster all node at once. Sometimes you want to deploy sequentially. Sometimes you want to have a health check between deploying services. Sometimes you want to just build an AMI and change the cloud formation parameter just to update the auto scaling set. And you really don't care about deploying through SSH itself. Like there are different methods and those tools are not supporting them at all. So if we have those libraries, then we have a lot of glue on our site for error hand links and logic. So how we can make it a lot more efficient. So the error site is a little simpler. So as you see in both cases, the user test coverage is the same, right? We have little less coverage for testing tool, sorry, for the tool. But the user coverage is the same, which is basically I have the input and what is the output. Is the rollout done completely well? So the error is fine. We write our test case for that. And we are, if we want to switch from that tool, it is already done. So how we minimize the glue and the logic. So I wrote those two libraries. They are really crap. But I will be developing them for another weeks. So hopefully it will be usable. So the idea is to develop bash tools really, really fast. There is few libraries like that already. So probably you can use them if you prefer. Basically I am demonstrating the concept only. So it is similar to Git, right? You have whatever CTL or admin tool. You have sub commands. This is the main application. You define just description and main and that is it, like the other scrap. And here you define the comment number one. You define four options. You define description and you run main. And then your logic for your cloud is just one line here. But I will demonstrate it in something more cool. So that was library for bash to produce CLI interfaces quickly. And now Nix cluster. So this is just a set of functions, mostly bash, like this, where you have something specific sets of requirements you want to deliver. So in this case you have Cassandra and Docker and you have NixOS on VSH. And then you have everything inside. And you can use them. You can develop your own. Those files don't have more than like ten lines of code. See reusable. So how we want to implement stuff, for example. We have our main command, which is in this example the first one. And then we have sub commands later. Okay. So we have some implementation details here. So how we do that? Okay. So this is probably the most important stuff. We write one command. We have four options, like name, node ID, Nix expression, SSH private key path. And then we source the implementation in the last line. And the implementation is really just a few lines of bash which does the job. So instead of using Terraform or whatever, let's use AWS CLI, Azure CLI, Google CLI to deliver the cloud bash on local. The tools that are working, they are mature that are delivered by integrators and don't produce much code, make it as simple as possible and use libraries instead of frameworks. Thank you. Next up is Lash Jellema with what makes a Nix format. I would like to remind lightning talk speakers to please keep track of the timer over there. Don't run over time. Is this one on? All right. So hi, I'm Lars. I'm known on GitHub as Lucas 16. I work at Seroquel. And Seroquel asked me about eight months ago to create a form for Nix as there weren't any good form letters back then. So I went out and did that. That was my task. And I had to wonder how do you build a form letter? So I started with just a parser and pretty printer. And then I had to wonder how do you determine the rules and how one stuff is pretty? So obviously you first look at the common practices, but there are still multiple styles used. Not everybody uses the same style. And there's a few choices you can make. So one is to do very specific conversions. So you just keep all the formatting that is in the original file. You fix up specific parts of ugly that you don't like. And this doesn't change too much. So you have more control. But you also need to spend more manual effort to format the file because it doesn't cover all cases. So you might still end up with mixed formats from different sources. And what this means is that the output is very consistent when you make edits to your source file. But the output is not as consistent between files from very different repositories. So the other approach is total conversion. So you throw away all the formatting that was in the original file and then you take a top bound approach. You start formatting everything from scratch, which is the approach I've taken for next formats. You might have heard about it. So this forces you to implement formatting for everything. And that also means you no longer need to think about what kind of, you no longer need to do any manual formatting. So you can just fire and forget it. And the advantage of that is that it's consistent based on the input. So if you have files from two very different developers that look similar, all the codes will look familiar. The diffs might get a little larger because of that when you edit files. But there are ways to get around that. You can ignore white space with getdiff and it won't be as large. And the reason why this is actually doable in Nix is because Nix is a pretty simple language. And so there's few enough cases that you can actually get good formatting for all of them. There's also something you have to think about, which is clarity versus prettiness. So it's very tempting to make every piece of code very pretty by aligning all the assignment operators. But that also takes a lot more work because a computer can't always guess what's ready for you. But it can understand what is clear. So when the code is, I'll give an example actually. So in our expressions, the pretty printing library I used originally, which is used mostly in Haskell, it does this. It does the one on the left, the bad part. So it really wants to fit as much as possible in a small space. And it will actually split the inner expression, which is just a call rather than doing what's on the right and splitting on logical parts of the expression. So I prefer that. And that's why I had to change the pretty printing algorithm from the standard one in Haskell. And actually, what I like the best is this because the operators and the keywords are on the left and you can more easily scan the code. Yeah, that was pretty much the entire talk. So thank you all for listening. And if you have any questions, please come and see me after the lightning talks. I'd love to talk to you. Thank you. So next up is Yuya Inchatsuki with NixGui, visualizing Nix Scope and Store. Hello, Nixers. I want to talk about my project, maybe not even a project yet, but idea for Hackaday, although there is already some amount of working code and working application. So when I started using Nix and diving deeper into the language, I thought it would be a good idea to write something which would make this task easier for others. And the more ambitious goal is to make something which could be usable as an installer. So because I'm mostly familiar with Python and QT has better multi-platform reputation and it's also not hardly bound to graphical interface and I hope it is possible to reuse models for something like N-Carses. I have chosen Python with QT. So what should it, what the GUI for Nix should look like? So I think users would expect some kind of tree visualizing the scope, the attributes and allowing to read the descriptions and set values. And here is what Nix has. So there is a flow and there are a few problems about this because, for example, there is no such thing as canonical path in the scope because one thing can be accessed via multiple paths which is used a lot in the scope and it also pollutes outputs of Nix search a lot. So you can see in search results, for example, just Nix back against VLC and something like Nix back against Leaps for QT VLC and it's the same thing and when you are new to Nix it makes quite a confusion. Then there is a result of computation, derivations and output paths in the store and this transition is, in fact, irreversible. It's a problem maybe that we cannot get the state of the scope which produced the current profile and I have started with the store browser which can currently be used to choose some profile or exact store path and see the dependency tree and different information about store paths and there is also some prototype for the scope browser which uses Nix evaluate to list attributes and parses the JSON output. I don't yet have a good solution for this but the idea is maybe we should just ignore... Okay, I will be finishing. If somebody, a few have strong experience with QT it would be nice to have a talk maybe to verify that my approach is good enough. Thank you for your attention. Next up is Marek Mahout and I believe you are going to talk about Morph. Okay, thanks. Hello everyone. My name is Marek Mahout and I am working from a company called Satoshi Labs. You probably know Satoshi Labs by the company behind the first cryptocurrency hardware wallet called Trezor and today I am going to show you how we are using Morph for our configuration management of our Nix instances. Before I jump in, can I just quickly ask how many of you are familiar with Morph? Can you raise your hands? Okay, so a lot of people, that's good. What is Morph? I really like the project description which is just a fancy wrapper around the tools we are already using daily. The features, if you compare to the system is multi-host which is probably given. It's stateless so compared to other configuration management tools such as NixOps you don't need to store the state of the infrastructure which is really nice if you are working in a team. It has built-in health checks so after each deploy you can verify your infrastructure is running as expected and it has built-in way to manage your secrets out of the Nix store of course. You can get it on this GitHub URL and it's of course in Nix packages so you can install it directly. Okay, so this is our directory structure for our Morph configuration. If you are familiar with Puppet, you might be familiar with this as well as we brought some ideas from them. The main file which is called by Morph is infra.nix and in this file we actually just import all of the files which we call profiles. So each server, each instance has its own profile. In this profile file we store information that are specific to the host itself so things such as IP address is host names but also hardware configuration and most importantly each of the profile files includes a number of roles. By roles we are defining we can have a common role where we define something for all of the hosts such as our default package set for example but each of the profiles has a role specific for its function. In this example we have the role database that is directly linked to this profile. The roles are actually built from modules so each role is using any modules in this example Nginx and we are also having a number of secrets. We are using Git Crypt to manage our secrets so it's actually encrypted on the remote Git server but we can work with it just like a plain file. The workflow is really simple. We just execute Morph build to build all our derivations for all our servers. The Morph push will just copy the closures to the remote servers and then we just deploy switches which means it just switch the configuration on all of the instances. Interesting thing here what it does after the switch is complete is also running the health checks and in case any of those fails it is executing a role back so we don't have much doubt and we know how to fix stuff. And last command we are using most often is to upload the secrets so what this does is just take all the secrets and just plainly copy them into place leaving them out of the Nix store. It restarts any services that may be dependent on those files and lastly it's around the health checks against to see if everything is all right. Okay so that's all. Actually I have something left. That's good. So that's all here are the demo files and you can catch up during the lunch if you want to talk more about Morph. I was really hoping we get like a full Morph presentation but sadly the developers did not submit the talk so maybe next year we will get that. Thank you. So next up is Alexander. I don't know how to pronounce his surname so I'm not even going to try but he's going to talk about running Nix on Android. Hello. Hello. For all of you who have found yourself staring at your Android phones and thinking okay I want to try running my familiar Linux stuff there. You don't have to go full semial. You don't have to go NixOS mobile route. There are other approaches and other distributions pioneered way earlier than us. You can also go hardcore. You can embrace Android not dish it but recompile all your disk too with Bionic that means porting everything to a different Lipsy. I think that's hardcore but Termax does that. Good luck to them. You can also get root and hammer your Android installation as hard so it will start resembling your disk through more than Android. That's also always an option for power users. And you can go an easier way and just use user space to emulation and I want to tell you that sometimes the lowest hanging through is the ripest one. I'm going to skip all the details. I will upload it somewhere and you will look it up later if you want to. I wanted to frame it as a story. This spring I wanted a lightweight travel laptop. I didn't like anything that I could buy but I found a nice Android tablet and I thought why not a tablet. I don't need much from my travel device but there was a lingering question. Could it run Nix? I did a quick Google lookup. I didn't find it definitive. Yes, I found a lot of people with a lot of problems compiling Nix under Android but I found this command and it's pretty inspirational. This would turn toys into semi-computers. I love that one. But if I'm paying for a tablet I want a tablet. I want to use Android apps. I don't want to wait until GNOME catches up with the user experience. I also love my hardware working. So I wanted Nix to coexist with Android. I also just read excellent posts but made you borrow about static linking and cross compilation and I was like wow, I know what I got to do. I should just cross compile Nix and statically link it on it and it will work in Android. So I was pretty stoked. I bought the tablet and I remember myself thinking vividly that would be super cool if I had a working prototype before Nixcon, right? Yeah. And I got it working the same evening. The biggest problem was that I had to understand first that I don't need to do anything. If I have P-root I can just rewrite access to Nix store so it looks like it is located in actual slash Nix slash store. And I also thought okay, I should now sit down and build a root of S with everything required to run Nix and it turns out we have one and it's called Nix Release Star Bowl. And I downloaded it. I P-rooted into that and it worked. Wow. So this is kind of like a testament to thank you. It just works on Android. Plain overall limitations. At first it was a very hacky bash script that did everything with an intermediate distribution called Termex but then I cut out the middleman. I forked the app so it could run Nix directly. I started cross compiling P-root the right Nix way. Then I kind of thought okay, it just works for me and I stopped working on that. And then one day I get a PR that rewrites my project. I mean, some lines survived but that was read me MD so it doesn't count. So thanks Gershly for rewriting everything. It's now properly built with Nix and all the hacks that I installed on device in his second PR he also put it under Nix control and users now have an upgrade path that is not wipe all data and reinstall it. That's wonderful. And I also just got it accepted into FDroid so it should be in their build queue now. Fingers crossed so try it from Android next week. For now you can try my APK if you want to. What gives? You can install an application. It's a terminal and a liter. There's a terminal. You can Nix run something. You are encouraged to install home manager. You don't have to compile stuff. Hydra has our AR64 binary cache. It will just get downloaded and you don't need root. You don't need username spaces. You don't need a Linux, permissive, whatever. You do need a 64-bit phone or tablet because we don't have Nix built for 32-bit arm unfortunately. It would be slow and PRoot isn't exactly helping that. And there are some restrictions like everything that uses ptrace won't work because PRoot took that. And remember that you are running stuff as an unprivileged user under another Linux distro and it's not Fedora or Debian. It's Android so everything is messed up. So don't try fancy stuff like top or maybe pink. That won't fly. But other tools work just well. I have my favorite tools there. I've type set this presentation on my tablet. I compiled it with Pandoc. It works. So semi-computer I think. And all my Android experience is still there. My Wi-Fi works. I really value that. But I think there's also a bigger question. What do we want to do with that? I think we have a quirky platform under our noses. It's quirky but it's pretty uniformly quirky. And it's already in our pockets. Maybe it's the next Nix Darwin but we just didn't explore it enough. I don't know why we didn't do that. And you're not allowed to ask questions but I am. So could we make my project that had more official? I want a fancy looking hostname for my files or something. Could I maybe recompile everything that would require a lot of builders and whatever but this could get me out of P-root and what's the actual end game? And is it worth the effort? I don't know. So please find me. Ask me or better answer those. Thank you. I've actually built my crazy e-max config on this stuff and it works just great. But next up is Domynkosa and he's going to talk about Hercules CI. Hey everyone. How are you doing? All right. You're still awake. Let's see if this works. So I'm hijacking this talk a bit. I'm sorry for three topics. Let's see if we can get. Please. All right. This might work. All right. So first of all I want to briefly mention Nixxs Weekly. It's like a weekly newsletter that's actually a monthly newsletter that goes out when I have time. But you should either subscribe for news or there's a link somewhere at the bottom of each post where you can send your blog post or whatever you have done with Nixx. So it's featured there. And I think there is about almost 1,000 people right now subscribed to it. So it's pretty wide. I mean you can get a nice audience and you can see a bunch of posts there. All right. So getting to my third topic with the second one. I wrote like a couple of a year ago, Cachex, which is a hosted binary cache, easy to use. And I don't know if you heard, but GitHub launched their CI. It's called GitHub Actions. So there is a Cachex action. If you need to start really, really easy with Nixx and a CI, basically you call it is file into your repo. You set your keys for Cachex and you're building Nixx and Cachex in like 30 seconds, which is pretty nice to start a simple toy project. And to my last topic, we're also building a complete CI replacement for Hidra. So who is running Hidra? All right. My condolences. I offer also emotional support after the Nixxcon. But besides that, you can also use our CI that we've been building for the last year. So I'm going to quickly show how it works. So you can click here. You can say Hakel CI and add a repo. So you can whitelist which repo is built. So let me just show you there's just one file in it. It's a bit cryptic, but you can build Linux and Darwin with this simple expression and it's built a hello world derivation. So nothing too fancy. So if we edit now and it loads, we can start building our project. So let's see where it is. All right. So if I push it now, we should see it. Evaluate and build. There we go. And there you go. So it displays attributes as they're being evaluated. And now it's going to dispatch this to Linux and Darwin and build them. So yeah, that's a very simple demo of it. The agents themselves need to be hosted by you on different infrastructures. So we provide serve for Nixxops, Nixxdarwin and probably other things. So we're aiming to make it as simple as possible to deploy those without scaling in the future and so on. And if you go to docs.hercules-ci.com, you will see instructions on how to deploy those agents. The service is hosted so you don't have to maintain it. Only the agents. It's free for open source. So you can, if you have some hardware or even on your laptop, the agents are completely stateless. So you can just run it on your laptop and when it's online, it will build things. And otherwise, it's a paid service for private repositories. And yeah, it's a bit busy with other things right now. We're rebuilding huge Haskell sets. So yeah, that's it. If you have some questions about Hercules-ci or Cachex or even Nixxops, talk to me later. Thanks. Thank you, Domen. Next up is Franz Plats and he's going to talk about NetworkD. So hello. This one is going to be quick. Just a few, like, what's the current state of NetworkD? Because I did a talk at last Nixxcon about switching the default networking back into NetworkD. But obviously, that hasn't happened yet. And quite a lot of people came up to me at this Nixxcon to ask about the current state. So I'm going to do a lightning talk about it to inform you what has happened and what's going to happen. So what has happened? Not that much actually because due to a lack of time on my part, but also what we already did is for 1909, we deprecated the use of networking.useDHCP and NetworkD. So it's not possible to do DHCP on all interfaces anymore if you use NetworkD because that's inherently incompatible with how NetworkD works. What we also did is we modified Nixxos generate config to not enable use DHCP by default, but only enable use DHCP on an interface basis. So only for interfaces that are available on your system when you installed NixxOS, use DHCP will be enabled. What's currently on master, what Fluctlit actually did, we also removed the 99-Schmain network unit which was causing the main part of the trouble for every like NetworkD user and like most NetworkD users out there disabled that unit actually. And so the reasons why it's not ready yet, it's actually more work and like more questions arose than anticipated when I did my talk. And there were some people who came up to me after the talk that still wanted to keep using scripted networking. And that's a problem because NetworkD supports many more features and if we want to expose them as a networking option and people still want to use scripted networking, we have to ensure feature parity or like do a lot of like assertions and that would make the networking module even more complex. So the problem is that we have decision how to move forward. And the thing is we are going to deprecate some of the options in the networking module anyway if we want to switch to NetworkD. And this is actually a chance to redesign the networking module as a whole. So what I am planning is to create an RFC for like this networking module redesign because when I was thinking about it, I got even more questions and I wasn't sure like how to move forward. And that's actually something the community has to answer because like I could implement what I'm thinking is right but that's probably not the right decision for the project. So what's my plan? I would have to have, I would like to have NetworkD turn key ready for 20.03. That means you can use NetworkD in 20.03 without any problems. That's the idea. For that we need that RFC and a little bit of that redesign of the networking module. For 20.09 I would like to have the redesign of the networking module in place which would break like everyone's network configuration probably but yeah that's just a thing we have to do at some point. So what's coming up? So we have to create that RFC at least like before Christmas. So I would like to do a NetworkD sprint this year. What I am proposing is to do it in Munich at the Mayflower office and I've already created a doodle for that. So if you have time and if you want to contribute like discussing about what are the possible solutions for like a new networking module I will create a post in the discourse later today with the doodle link and some of the questions I have for you and I hope some of some people can come and maybe even attend remotely for that sprint and we can create the RFC. Thanks a lot. So next up is Robin Gluster. He's going to talk about the Nixos RFC process but I would like to know is Matthew Bauer around? No okay thank you. So I'll just quickly talk about the Nixos RFC process. In March 2017 Zimba Thomas-Hunger and Morty started the idea and established the first version of the process. We had a few RFCs which were really uncontroversial which were accepted but otherwise everything which needed more discussion. We didn't really have any way of determining if it's going to be accepted or not. So last year at Nixcon Graham, myself, Flockley and a few others sat down and wrote up an RFC trying to improve the RFC process that was accepted in January as RFC 36 and that created one team of five people who for every RFC select team of people who are knowledgeable about that topic who in the end decide and that first team of five is the RFC steering committee whose rotation was defined in RFC 43. That was accepted in June. So we have these three teams or two teams plus the leader of the second team. The RFC steering committee is Elko, Domin, Shay, Mick92 and me. I think I didn't miss anyone. We meet once a week and go through all RFCs. When a new RFC is opened there's a period where people can nominate the so-called shepherds and the RFC steering committee then selects three or four shepherds. The shepherds team is responsible for trying to make sure that the conversation makes sense and actually focuses on the topic. The shepherd leader tries to facilitate meetings with the shepherds and the author so that they can discuss points that are controversial or need further explanation. We'd like to encourage the leaders to actually meet up with the other shepherds and the author more so that because we've had the experience that the meetings actually bring the most benefit in the discussion and move on overseas much faster than just commenting on the FCS. The general process is right on PR and RFC. Then there's this shepherd nomination period of three to four people getting accepted as shepherds. Then a discussion until it at some point hopefully reaches a general acceptance or generally everyone agrees that it probably isn't a good idea in the form that it's mentioned in the RFC. Then the shepherds call the final comment period of 10 days where they say we all unanimously agree that we'd want to accept or close this RFC and then there's a 10-day period where people can bring up new points so the discussion continues or otherwise after the 10 days the RFC is accepted or closed. Then I'm running out of time so there are a number of accepted RFCs and open RFCs for example Flakes and F-Plates is going to open one in networking and then the RFC steering committee is going to be rotated at the end of this year. We are looking for people who would like to be in it and I'm going to open a thread on discourse today. Please nominate yourself or other people and at the end of the year the steering committee will decide on the next steering committee for next year. Thank you. I believe that was our final lightning talk but I would like to quickly just ask the HDMI. Yeah I would like to ask everyone on behalf of the ORGA team to have a look off of the program and submit a review about feedback on every talk that you have some feedback on so you just go to the schedule and on the schedule you can click a talk and then there's a feedback button and just write your honest feedback so NISCON can be even more awesome next year. And yeah I know you're all hungry so we have an hour lunch break and we'll start again at one o'clock.
 Let's get rolling. We have about five of them, I think. The first one is Tomas with his  next cluster. Hello again. So I deploy a lot of servers in one of the companies I'm helping  with, we shareably. We have around 1,000 hosts, which is relatively fine. And I use different  kind of tools. I use Nixops, I use Terraform, CloudFormation, whatever crap is on Azure,  and all those Google services. And they have some issues. So the big gray box is just a  tool, right? And it has fixed logic for quite a few components. One of them is fine. And for me,  especially the rollout or deploy strategy, which is hardcoded into those tools, it's really,  really crap. I have a lot of environments which are completely different, right?  So first of all, they have hardcoded abstractions. I cannot create my own abstractions. Or maybe  Nixops is a little easier, but still. The deployment strategy is fixed. Sometimes it's  parametrized. You can do parallel or sequential. But can you inject your check for the database?  Like you want to roll out your database, you have 40 servers of Cassandra, and you want  to do one by one node. And it takes like two days. Those tools are really not good for that.  And they are really buggy. Anybody use Terraform? Like, hell, right? So there is few, few more.  Sometimes you want to extend your tool. And it's not always easy. The state file is like  another idea. This concept should really die. And there is more books everywhere. So the idea  would be to shift this tool into library. So now the gray big box is our own tool. So basically,  we use the pieces from other libraries to build our own stuff. Of course, that makes it a little  harder because a lot of glue and error handling is now on our side. But that's not that bad.  We can minimize it. And we can try to figure out how we can minimize that and make it better.  So what that gives us if we switch from the framework to the library approach, right? We  can integrate new abstractions faster. We can describe whatever we want in the language  we want. We can put our own rollout strategy. We can not use state file. And we can integrate  other clouds or cloud resources much faster than tools. The tool is there to make the  pull request proper testing. It's like at least a few weeks or months. And then you  have to fork it or something, right? So if we have different kind of deployments like  Cassandra or Elasticsearch, sometimes you want the restart cluster all node at once. Sometimes  you want to deploy sequentially. Sometimes you want to have a health check between deploying  services. Sometimes you want to just build an AMI and change the cloud formation parameter  just to update the auto scaling set. And you really don't care about deploying through  SSH itself. Like there are different methods and those tools are not supporting them at  all. So if we have those libraries, then we have a lot of glue on our site for error hand  links and logic. So how we can make it a lot more efficient. So the error site is a little  simpler. So as you see in both cases, the user test coverage is the same, right? We have  little less coverage for testing tool, sorry, for the tool. But the user coverage is the  same, which is basically I have the input and what is the output. Is the rollout done  completely well? So the error is fine. We write our test case for that. And we are, if  we want to switch from that tool, it is already done. So how we minimize the glue and the logic.  So I wrote those two libraries. They are really crap. But I will be developing them for another  weeks. So hopefully it will be usable. So the idea is to develop bash tools really, really  fast. There is few libraries like that already. So probably you can use them if you prefer.  Basically I am demonstrating the concept only. So it is similar to Git, right? You have whatever  CTL or admin tool. You have sub commands. This is the main application. You define just  description and main and that is it, like the other scrap. And here you define the comment  number one. You define four options. You define description and you run main. And then your  logic for your cloud is just one line here. But I will demonstrate it in something more  cool. So that was library for bash to produce CLI interfaces quickly. And now Nix cluster.  So this is just a set of functions, mostly bash, like this, where you have something  specific sets of requirements you want to deliver. So in this case you have Cassandra  and Docker and you have NixOS on VSH. And then you have everything inside. And you can use  them. You can develop your own. Those files don't have more than like ten lines of code.  See reusable. So how we want to implement stuff, for example. We have our main command,  which is in this example the first one. And then we have sub commands later. Okay. So we  have some implementation details here. So how we do that? Okay. So this is probably the  most important stuff. We write one command. We have four options, like name, node ID,  Nix expression, SSH private key path. And then we source the implementation in the last line.  And the implementation is really just a few lines of bash which does the job. So instead  of using Terraform or whatever, let's use AWS CLI, Azure CLI, Google CLI to deliver the  cloud bash on local. The tools that are working, they are mature that are delivered by integrators  and don't produce much code, make it as simple as possible and use libraries instead of frameworks.  Thank you. Next up is Lash Jellema with what makes a Nix  format. I would like to remind lightning talk speakers to please keep track of the timer  over there. Don't run over time. Is this one on?  All right. So hi, I'm Lars. I'm known on GitHub as  Lucas 16. I work at Seroquel. And Seroquel asked me about eight months ago to create  a form for Nix as there weren't any good form letters back then. So I went out and did that.  That was my task. And I had to wonder how do you build a form letter? So I started with  just a parser and pretty printer. And then I had to wonder how do you determine the rules  and how one stuff is pretty? So obviously you first look at the common practices, but  there are still multiple styles used. Not everybody uses the same style. And there's  a few choices you can make. So one is to do very specific conversions. So you just keep  all the formatting that is in the original file. You fix up specific parts of ugly that  you don't like. And this doesn't change too much. So you have more control. But you also  need to spend more manual effort to format the file because it doesn't cover all cases.  So you might still end up with mixed formats from different sources. And what this means  is that the output is very consistent when you make edits to your source file. But the  output is not as consistent between files from very different repositories. So the other  approach is total conversion. So you throw away all the formatting that was in the original  file and then you take a top bound approach. You start formatting everything from scratch,  which is the approach I've taken for next formats. You might have heard about it. So  this forces you to implement formatting for everything. And that also means you no longer  need to think about what kind of, you no longer need to do any manual formatting. So you can  just fire and forget it. And the advantage of that is that it's consistent based on the  input. So if you have files from two very different developers that look similar, all  the codes will look familiar. The diffs might get a little larger because of that when you  edit files. But there are ways to get around that. You can ignore white space with getdiff  and it won't be as large. And the reason why this is actually doable in Nix is because  Nix is a pretty simple language. And so there's few enough cases that you can actually get  good formatting for all of them. There's also something you have to think about, which is  clarity versus prettiness. So it's very tempting to make every piece of code very pretty by  aligning all the assignment operators. But that also takes a lot more work because a  computer can't always guess what's ready for you. But it can understand what is clear.  So when the code is, I'll give an example actually. So in our expressions, the pretty  printing library I used originally, which is used mostly in Haskell, it does this. It  does the one on the left, the bad part. So it really wants to fit as much as possible  in a small space. And it will actually split the inner expression, which is just a call  rather than doing what's on the right and splitting on logical parts of the expression.  So I prefer that. And that's why I had to change the pretty printing algorithm from  the standard one in Haskell. And actually, what I like the best is this because the operators  and the keywords are on the left and you can more easily scan the code. Yeah, that was  pretty much the entire talk. So thank you all for listening. And if you have any questions,  please come and see me after the lightning talks. I'd love to talk to you.  Thank you.  So next up is Yuya Inchatsuki with NixGui, visualizing Nix Scope and Store.  Hello, Nixers. I want to talk about my project, maybe not even a project yet, but idea for  Hackaday, although there is already some amount of working code and working application. So  when I started using Nix and diving deeper into the language, I thought it would be a  good idea to write something which would make this task easier for others. And the more ambitious  goal is to make something which could be usable as an installer. So because I'm mostly familiar  with Python and QT has better multi-platform reputation and it's also not hardly bound  to graphical interface and I hope it is possible to reuse models for something like N-Carses.  I have chosen Python with QT. So what should it, what the GUI for Nix should look like?  So I think users would expect some kind of tree visualizing the scope, the attributes  and allowing to read the descriptions and set values. And here is what Nix has. So there  is a flow and there are a few problems about this because, for example, there is no such  thing as canonical path in the scope because one thing can be accessed via multiple paths  which is used a lot in the scope and it also pollutes outputs of Nix search a lot. So you  can see in search results, for example, just Nix back against VLC and something like Nix  back against Leaps for QT VLC and it's the same thing and when you are new to Nix it  makes quite a confusion. Then there is a result of computation, derivations and output paths  in the store and this transition is, in fact, irreversible. It's a problem maybe that we  cannot get the state of the scope which produced the current profile and I have started with  the store browser which can currently be used to choose some profile or exact store path  and see the dependency tree and different information about store paths and there is  also some prototype for the scope browser which uses Nix evaluate to list attributes  and parses the JSON output. I don't yet have a good solution for this  but the idea is maybe we should just ignore... Okay, I will be finishing. If somebody, a few  have strong experience with QT it would be nice to have a talk maybe to verify that my  approach is good enough. Thank you for your attention.  Next up is Marek Mahout and I believe you are going to talk about Morph.  Okay, thanks. Hello everyone. My name is Marek Mahout and I am working from a company  called Satoshi Labs. You probably know Satoshi Labs by the company behind the first cryptocurrency  hardware wallet called Trezor and today I am going to show you how we are using Morph  for our configuration management of our Nix instances. Before I jump in, can I just quickly  ask how many of you are familiar with Morph? Can you raise your hands? Okay, so a lot of  people, that's good. What is Morph? I really like the project description which is just  a fancy wrapper around the tools we are already using daily. The features, if you compare  to the system is multi-host which is probably given. It's stateless so compared to other  configuration management tools such as NixOps you don't need to store the state of the infrastructure  which is really nice if you are working in a team. It has built-in health checks so after  each deploy you can verify your infrastructure is running as expected and it has built-in  way to manage your secrets out of the Nix store of course. You can get it on this GitHub  URL and it's of course in Nix packages so you can install it directly. Okay, so this  is our directory structure for our Morph configuration. If you are familiar with Puppet, you might  be familiar with this as well as we brought some ideas from them. The main file which  is called by Morph is infra.nix and in this file we actually just import all of the files  which we call profiles. So each server, each instance has its own profile. In this profile  file we store information that are specific to the host itself so things such as IP address  is host names but also hardware configuration and most importantly each of the profile files  includes a number of roles. By roles we are defining we can have a common role where we  define something for all of the hosts such as our default package set for example but  each of the profiles has a role specific for its function. In this example we have the  role database that is directly linked to this profile. The roles are actually built from  modules so each role is using any modules in this example Nginx and we are also having  a number of secrets. We are using Git Crypt to manage our secrets so it's actually encrypted  on the remote Git server but we can work with it just like a plain file. The workflow  is really simple. We just execute Morph build to build all our derivations for all our servers.  The Morph push will just copy the closures to the remote servers and then we just deploy  switches which means it just switch the configuration on all of the instances. Interesting thing  here what it does after the switch is complete is also running the health checks and in case  any of those fails it is executing a role back so we don't have much doubt and we know  how to fix stuff. And last command we are using most often is to upload the secrets so what  this does is just take all the secrets and just plainly copy them into place leaving  them out of the Nix store. It restarts any services that may be dependent on those files  and lastly it's around the health checks against to see if everything is all right. Okay so  that's all. Actually I have something left. That's good. So that's all here are the demo  files and you can catch up during the lunch if you want to talk more about Morph. I was  really hoping we get like a full Morph presentation but sadly the developers did not submit the  talk so maybe next year we will get that. Thank you. So next up is Alexander. I don't  know how to pronounce his surname so I'm not even going to try but he's going to talk  about running Nix on Android. Hello. Hello. For all of you who have found yourself staring  at your Android phones and thinking okay I want to try running my familiar Linux stuff  there. You don't have to go full semial. You don't have to go NixOS mobile route. There  are other approaches and other distributions pioneered way earlier than us. You can also  go hardcore. You can embrace Android not dish it but recompile all your disk too with Bionic  that means porting everything to a different Lipsy. I think that's hardcore but Termax  does that. Good luck to them. You can also get root and hammer your Android installation  as hard so it will start resembling your disk through more than Android. That's also always  an option for power users. And you can go an easier way and just use user space to emulation  and I want to tell you that sometimes the lowest hanging through is the ripest one.  I'm going to skip all the details. I will upload it somewhere and you will look it up  later if you want to. I wanted to frame it as a story. This spring I wanted a lightweight  travel laptop. I didn't like anything that I could buy but I found a nice Android tablet  and I thought why not a tablet. I don't need much from my travel device but there was a  lingering question. Could it run Nix? I did a quick Google lookup. I didn't find it definitive.  Yes, I found a lot of people with a lot of problems compiling Nix under Android but I  found this command and it's pretty inspirational. This would turn toys into semi-computers.  I love that one. But if I'm paying for a tablet I want a tablet. I want to use Android apps.  I don't want to wait until GNOME catches up with the user experience. I also love my hardware  working. So I wanted Nix to coexist with Android. I also just read excellent posts but made  you borrow about static linking and cross compilation and I was like wow, I know what  I got to do. I should just cross compile Nix and statically link it on it and it will work  in Android. So I was pretty stoked. I bought the tablet and I remember myself thinking vividly  that would be super cool if I had a working prototype before Nixcon, right? Yeah. And  I got it working the same evening. The biggest problem was that I had to understand first  that I don't need to do anything. If I have P-root I can just rewrite access to Nix store  so it looks like it is located in actual slash Nix slash store. And I also thought okay, I  should now sit down and build a root of S with everything required to run Nix and it  turns out we have one and it's called Nix Release Star Bowl. And I downloaded it. I  P-rooted into that and it worked. Wow. So this is kind of like a testament to thank  you. It just works on Android. Plain overall limitations. At first it was a very hacky  bash script that did everything with an intermediate distribution called Termex but then I cut  out the middleman. I forked the app so it could run Nix directly. I started cross compiling  P-root the right Nix way. Then I kind of thought okay, it just works for me and I stopped working  on that. And then one day I get a PR that rewrites my project. I mean, some lines survived  but that was read me MD so it doesn't count. So thanks Gershly for rewriting everything.  It's now properly built with Nix and all the hacks that I installed on device in his second  PR he also put it under Nix control and users now have an upgrade path that is not wipe  all data and reinstall it. That's wonderful. And I also just got it accepted into FDroid  so it should be in their build queue now. Fingers crossed so try it from Android next  week. For now you can try my APK if you want to. What gives? You can install an application.  It's a terminal and a liter. There's a terminal. You can Nix run something. You are encouraged  to install home manager. You don't have to compile stuff. Hydra has our AR64 binary cache.  It will just get downloaded and you don't need root. You don't need username spaces.  You don't need a Linux, permissive, whatever. You do need a 64-bit phone or tablet because  we don't have Nix built for 32-bit arm unfortunately. It would be slow and PRoot isn't exactly helping  that. And there are some restrictions like everything that uses ptrace won't work because  PRoot took that. And remember that you are running stuff as an unprivileged user under  another Linux distro and it's not Fedora or Debian. It's Android so everything is messed  up. So don't try fancy stuff like top or maybe pink. That won't fly. But other tools work  just well. I have my favorite tools there. I've type set this presentation on my tablet.  I compiled it with Pandoc. It works. So semi-computer I think. And all my Android experience is  still there. My Wi-Fi works. I really value that. But I think there's also a bigger question.  What do we want to do with that? I think we have a quirky platform under our noses. It's  quirky but it's pretty uniformly quirky. And it's already in our pockets. Maybe it's the  next Nix Darwin but we just didn't explore it enough. I don't know why we didn't do that.  And you're not allowed to ask questions but I am. So could we make my project that had  more official? I want a fancy looking hostname for my files or something. Could I maybe recompile  everything that would require a lot of builders and whatever but this could get me out of  P-root and what's the actual end game? And is it worth the effort? I don't know. So please  find me. Ask me or better answer those. Thank you.  I've actually built my crazy e-max config on this stuff and it works just great. But next  up is Domynkosa and he's going to talk about Hercules CI. Hey everyone. How are you doing?  All right. You're still awake. Let's see if this works. So I'm hijacking this talk a bit.  I'm sorry for three topics. Let's see if we can get. Please. All right. This might work.  All right. So first of all I want to briefly mention Nixxs Weekly. It's like a weekly newsletter  that's actually a monthly newsletter that goes out when I have time. But you should  either subscribe for news or there's a link somewhere at the bottom of each post where  you can send your blog post or whatever you have done with Nixx. So it's featured there.  And I think there is about almost 1,000 people right now subscribed to it. So it's pretty  wide. I mean you can get a nice audience and you can see a bunch of posts there. All right.  So getting to my third topic with the second one. I wrote like a couple of a year ago,  Cachex, which is a hosted binary cache, easy to use. And I don't know if you heard, but  GitHub launched their CI. It's called GitHub Actions. So there is a Cachex action. If  you need to start really, really easy with Nixx and a CI, basically you call it is file  into your repo. You set your keys for Cachex and you're building Nixx and Cachex in like  30 seconds, which is pretty nice to start a simple toy project. And to my last topic,  we're also building a complete CI replacement for Hidra. So who is running Hidra? All right.  My condolences. I offer also emotional support after the Nixxcon. But besides that, you can  also use our CI that we've been building for the last year. So I'm going to quickly show  how it works. So you can click here. You can say Hakel CI and add a repo. So you can whitelist  which repo is built. So let me just show you there's just one file in it. It's a bit cryptic,  but you can build Linux and Darwin with this simple expression and it's built a hello world  derivation. So nothing too fancy. So if we edit now and it loads, we can start building our project. So let's see where it is. All  right. So if I push it now, we should see it. Evaluate and build. There we go. And there you go. So it  displays attributes as they're being evaluated. And now it's going to dispatch this to Linux and  Darwin and build them. So yeah, that's a very simple demo of it. The agents themselves need to be  hosted by you on different infrastructures. So we provide serve for Nixxops, Nixxdarwin and probably  other things. So we're aiming to make it as simple as possible to deploy those without  scaling in the future and so on. And if you go to docs.hercules-ci.com, you will see instructions on  how to deploy those agents. The service is hosted so you don't have to maintain it. Only the agents. It's  free for open source. So you can, if you have some hardware or even on your laptop, the agents are  completely stateless. So you can just run it on your laptop and when it's online, it will build things.  And otherwise, it's a paid service for private repositories. And yeah, it's a bit busy with other  things right now. We're rebuilding huge Haskell sets. So yeah, that's it. If you have some questions  about Hercules-ci or Cachex or even Nixxops, talk to me later. Thanks. Thank you, Domen. Next up is  Franz Plats and he's going to talk about NetworkD. So hello. This one is going to be quick. Just a  few, like, what's the current state of NetworkD? Because I did a talk at last Nixxcon about  switching the default networking back into NetworkD. But obviously, that hasn't happened yet. And  quite a lot of people came up to me at this Nixxcon to ask about the current state. So I'm going to  do a lightning talk about it to inform you what has happened and what's going to happen. So what  has happened? Not that much actually because due to a lack of time on my part, but also what we  already did is for 1909, we deprecated the use of networking.useDHCP and NetworkD. So it's not  possible to do DHCP on all interfaces anymore if you use NetworkD because that's inherently  incompatible with how NetworkD works. What we also did is we modified Nixxos generate config  to not enable use DHCP by default, but only enable use DHCP on an interface basis. So only for  interfaces that are available on your system when you installed NixxOS, use DHCP will be enabled.  What's currently on master, what Fluctlit actually did, we also removed the 99-Schmain  network unit which was causing the main part of the trouble for every like NetworkD user and like  most NetworkD users out there disabled that unit actually. And so the reasons why it's not ready  yet, it's actually more work and like more questions arose than anticipated when I did my talk. And  there were some people who came up to me after the talk that still wanted to keep using scripted  networking. And that's a problem because NetworkD supports many more features and if we want to  expose them as a networking option and people still want to use scripted networking, we have to  ensure feature parity or like do a lot of like assertions and that would make the networking  module even more complex. So the problem is that we have decision how to move forward. And the  thing is we are going to deprecate some of the options in the networking module anyway if we want  to switch to NetworkD. And this is actually a chance to redesign the networking module as a whole.  So what I am planning is to create an RFC for like this networking module redesign because when I  was thinking about it, I got even more questions and I wasn't sure like how to move forward. And  that's actually something the community has to answer because like I could implement what I'm  thinking is right but that's probably not the right decision for the project. So what's my plan?  I would have to have, I would like to have NetworkD turn key ready for 20.03. That means you can  use NetworkD in 20.03 without any problems. That's the idea. For that we need that RFC and a  little bit of that redesign of the networking module. For 20.09 I would like to have the redesign  of the networking module in place which would break like everyone's network configuration probably  but yeah that's just a thing we have to do at some point. So what's coming up? So we have to  create that RFC at least like before Christmas. So I would like to do a NetworkD sprint this year.  What I am proposing is to do it in Munich at the Mayflower office and I've already created a doodle  for that. So if you have time and if you want to contribute like discussing about what are the  possible solutions for like a new networking module I will create a post in the discourse later  today with the doodle link and some of the questions I have for you and I hope some of some  people can come and maybe even attend remotely for that sprint and we can create the RFC.  Thanks a lot. So next up is Robin Gluster. He's going to talk about the Nixos RFC process but I  would like to know is Matthew Bauer around? No okay thank you.  So I'll just quickly talk about the Nixos RFC process. In March 2017 Zimba Thomas-Hunger and  Morty started the idea and established the first version of the process. We had a few RFCs which  were really uncontroversial which were accepted but otherwise everything which needed more discussion.  We didn't really have any way of determining if it's going to be accepted or not. So last year  at Nixcon Graham, myself, Flockley and a few others sat down and wrote up an RFC trying to improve  the RFC process that was accepted in January as RFC 36 and that created one team of five people who  for every RFC select team of people who are knowledgeable about that topic who in the end decide  and that first team of five is the RFC steering committee whose rotation was defined in RFC 43.  That was accepted in June. So we have these three teams or two teams plus the leader of the second  team. The RFC steering committee is Elko, Domin, Shay, Mick92 and me. I think I didn't miss anyone.  We meet once a week and go through all RFCs. When a new RFC is opened  there's a period where people can nominate the so-called shepherds and the RFC steering  committee then selects three or four shepherds. The shepherds team is responsible for trying to  make sure that the conversation makes sense and actually focuses on the topic. The shepherd leader  tries to facilitate meetings with the shepherds and the author so that they can discuss points  that are controversial or need further explanation. We'd like to encourage the leaders to actually  meet up with the other shepherds and the author more so that because we've had the experience that  the meetings actually bring the most benefit in the discussion and move on overseas much faster  than just commenting on the FCS. The general process is right on PR and RFC. Then there's this  shepherd nomination period of three to four people getting accepted as shepherds. Then a discussion  until it at some point hopefully reaches a general acceptance or generally everyone agrees that it  probably isn't a good idea in the form that it's mentioned in the RFC. Then the shepherds call  the final comment period of 10 days where they say we all unanimously agree that we'd want to accept  or close this RFC and then there's a 10-day period where people can bring up new points  so the discussion continues or otherwise after the 10 days the RFC is accepted or closed. Then  I'm running out of time so there are a number of accepted RFCs and open RFCs for example Flakes  and F-Plates is going to open one in networking and then the RFC steering committee is going to  be rotated at the end of this year. We are looking for people who would like to be in it and I'm  going to open a thread on discourse today. Please nominate yourself or other people and at the end  of the year the steering committee will decide on the next steering committee for next year.  Thank you. I believe that was our final lightning talk but I would like to quickly just ask  the HDMI.  Yeah I would like to ask everyone on behalf of the ORGA team to have a look off of the  program and submit a review about feedback on every talk that you have some feedback on  so you just go to the schedule and on the schedule you can click a talk and then there's a feedback  button and just write your honest feedback so NISCON can be even more awesome next year.  And yeah I know you're all hungry so we have an hour lunch break and we'll start again at one o'clock.
Lightning_Talks__NixCon_2019__0_839.png Lightning_Talks__NixCon_2019__840_2243.png Lightning_Talks__NixCon_2019__2244_3575.png Lightning_Talks__NixCon_2019__3576_3623.png Lightning_Talks__NixCon_2019__3624_4067.png Lightning_Talks__NixCon_2019__4068_6095.png Lightning_Talks__NixCon_2019__6096_8399.png Lightning_Talks__NixCon_2019__8400_9179.png Lightning_Talks__NixCon_2019__9180_9443.png Lightning_Talks__NixCon_2019__9444_10043.png Lightning_Talks__NixCon_2019__10044_10187.png Lightning_Talks__NixCon_2019__10188_10859.png Lightning_Talks__NixCon_2019__10860_12755.png Lightning_Talks__NixCon_2019__12756_13751.png Lightning_Talks__NixCon_2019__13752_14087.png Lightning_Talks__NixCon_2019__14088_18539.png Lightning_Talks__NixCon_2019__18540_21359.png Lightning_Talks__NixCon_2019__21360_21815.png Lightning_Talks__NixCon_2019__21816_21959.png Lightning_Talks__NixCon_2019__21960_22055.png Lightning_Talks__NixCon_2019__22056_27491.png Lightning_Talks__NixCon_2019__27492_30059.png Lightning_Talks__NixCon_2019__30060_30839.png Lightning_Talks__NixCon_2019__30840_32807.png Lightning_Talks__NixCon_2019__32808_37943.png Lightning_Talks__NixCon_2019__37944_38807.png Lightning_Talks__NixCon_2019__38808_39083.png Lightning_Talks__NixCon_2019__39084_39191.png Lightning_Talks__NixCon_2019__39192_39275.png Lightning_Talks__NixCon_2019__39276_47771.png Lightning_Talks__NixCon_2019__47772_48143.png Lightning_Talks__NixCon_2019__48144_48215.png Lightning_Talks__NixCon_2019__48216_49079.png Lightning_Talks__NixCon_2019__49080_49247.png Lightning_Talks__NixCon_2019__49248_49595.png Lightning_Talks__NixCon_2019__49596_49643.png Lightning_Talks__NixCon_2019__49644_51971.png Lightning_Talks__NixCon_2019__51972_52019.png Lightning_Talks__NixCon_2019__52020_52175.png Lightning_Talks__NixCon_2019__52176_52451.png Lightning_Talks__NixCon_2019__52452_52931.png Lightning_Talks__NixCon_2019__52932_53039.png Lightning_Talks__NixCon_2019__53040_53483.png Lightning_Talks__NixCon_2019__53484_53651.png Lightning_Talks__NixCon_2019__53652_55571.png Lightning_Talks__NixCon_2019__55572_55787.png Lightning_Talks__NixCon_2019__55788_56099.png Lightning_Talks__NixCon_2019__56100_56171.png Lightning_Talks__NixCon_2019__56172_63443.png Lightning_Talks__NixCon_2019__63444_63515.png Lightning_Talks__NixCon_2019__63516_64547.png Lightning_Talks__NixCon_2019__64548_66947.png Lightning_Talks__NixCon_2019__66948_69779.png Lightning_Talks__NixCon_2019__69780_71471.png Lightning_Talks__NixCon_2019__71472_71783.png Lightning_Talks__NixCon_2019__71784_73235.png Lightning_Talks__NixCon_2019__73236_73343.png Lightning_Talks__NixCon_2019__73344_74494.png