 Okay, this seems to be working. Hello. As I've already been introduced and the presentation is going to be about a very beautiful operating system called NixOS or NixOS. I don't know which pronunciation is correct to be honest so I'll be using both. First of all this talk is going to be slightly different in terms of few technological tests. If you open this link you should be able to follow the slides on your device live and there's also if you look to the top left corner there's a hamburger menu which you can open and you should be able to post questions. So if you have any questions try to post them through this live show and I will do an extended QA actually because I think I hope there will be more questions than I can answer in the talk alone so feel free to put in there and if you can put a test question maybe I'll see them right here and see if it works. Anyway don't panic. NixOS really doesn't bite. This is a sort of a sales pitch for the OS so I'm not going to go into many details but I'm not a very good sales person so I'm going to give you the spoilers right in front. NixOS really doesn't bite. That's why of course. It doesn't bite more than the others. If you do try new distros you'll always get bitten by something. NixOS is no different in this but that's the point of this presentation. It can be be frustrating because it's a bit of different distribution than the others but once you start using it you learn to love it. I already see people, Jesus already here so there's living proof it up. It'll be on you really very easily. So you might be saying asking yourself why should I listen to this guy. Well my name is Jakub. I've got all the socials everything but more importantly I've been using Linux for over 20 years now 19 of which I've been using Linux full-time. I've been paid for using Linux for well over a decade and most importantly I've been using NixOS as my only desktop operating system for over four years so I hope I've got a little something to say on the topic. So what is NixOS and why should you care? Well if you want to talk about NixOS we first have to take a little detour and talk about Nix the package manager. Nix the package manager is a very specific package manager. You already know what package manager is if you're using Linux these days. Nix does the same role but it does it quite differently. It is functional, declarative, it's quite fancy and it provides immutable results which is probably the most interesting part of this piece of software. We'll talk about all these points very soon in detail. One of the more interesting things about Nix as a package manager is that it actually runs on everything. It's not bound to NixOS so you can try Nix on yes even on phones. So NixOS, what makes it unique? Well Nix gives NixOS many features like immutable package management and dependencies, fully declarative system configuration. It's if you are experienced with say things like terraform or puppet you might know what this means. If you're not following my lead and you know what it means very soon. The system state is atomic. It means that well it's atomic you know what it means right? If you have database atomicity is the inherent feature of NixOS configuration. It protects you. You really can't break NixOS easily because if you do typo or something the system just won't build and nothing will happen. Hence the atomicity here. And all the configuration for the operating system is in one place and it's written in a single language that's well rather easy to understand. NixOS is also a quite user-centric distribution because it allows you as a user to create dynamic environments for your applications environments plural. You can have multiple environments in parallel running for different workloads, different experiments, anything you want. It allows you to build different and completely independent user profiles and independent what it means. Again we'll talk about it very soon. User configuration can be done in a very similar way than the system configuration is done that is being declarative and well atomic and everything. And of course the community. The NixOS community is one of the greatest community out there. People in NixOS are aware that the destroy is different and they are very very helpful to newcomers because they understand the frustration the newcomers come with sometimes. Don't be frustrated really. It's not worth it. It's easy. So let me give you a bunch of good reasons to switch to NixOS. It's personal opinions, no warranty or management, and a bunch is just a subjective term. So would you care to guess what this is? No guesses. It is. It is. It is an NixOS configuration, but this specific configuration is actually complete and working system configuration. This is all you need, like literally all you need to have your desktop running full NixOS with Plasma 5, with Firefox and your favorite editor. Like literally all. There's nothing, you don't need to add anything to have a working system. So this is how easy it is. Well, you probably see this. Okay, I'm lying just a little bit. This is a way to split your NixOS configuration if you want, but this specific case, this specifically is this. This is a configuration for file systems and such. This is generated for you by the installers. You don't have to care about this. It just has to be there because there has to be some kind of initial state, but this you don't have to care about. This is not a complete example. I've got a much larger configuration in there, but you get the idea, right? So about the NixOS configuration, well, as I said, it's declarative. As you have seen, declarative configuration means that you basically say what you want, but you don't have to say how it's done because that's what Nix does for you. You just say, okay, I want Firefox. That's it. I want Plasma. I want X server. I want an Nix container. You just say that you want something and it'll magically happen. It is immutable. It means that once a configuration is made, it doesn't change. And if you make the configuration with the same inputs, you will always get the same outputs regardless of the current state. So the current state doesn't really matter when you create a new configuration. That means it's reproducible. You can always make the same configuration all over again and you can test it and you can be sure that if you do the configuration same and you give it the same inputs, you will always have the same outputs. And it's also atomic. It means that once the configuration is, let's say, created or built in NixOS terms, then you can switch to it. And the switch is atomic. You know, atomicity from databases probably. It means that the switch either happens at all, either happens completely or doesn't happen at all. So it's virtually impossible to end up in a half configured system because of this atomicity principle. It's not possible to break things just by, you know, rebooting system or something during the build or anything because that's the inherent property of the system. So how do you deploy this kind of config? Well, it's a simple command. This command will take all your configuration and it will... Sorry. We built a new operating system configuration and we'll switch your runtime to it, just like this. You might be asking yourself right now, well, how are new packages? I always do some Pac-Man or Apt-Apt or YAM or whatever, a DNF. I heard is the new thing in Red Hat World. So how do you do the packages? I mean, do I have to do this all the time if I want to just add new packages into the system? Well, you can, but you don't have to because we've got these profiles I've been talking about a while ago. This command will install the package Krita for you in your user profile and once it's done, you can just start it. But let's say we don't like Krita. Let's say, okay, yeah, I don't like this editor. What do I do now? Well, you can uninstall the package, of course, but then you say, okay, but let's try a different thing. Let's say I want to try Inkscape. Do I have to do the install and uninstall again? Well, again, you can, but you don't have to. Nix has this great feature of running actually a package or package output that you don't even have to install. This thing, if you run this in your Nix environment, it will start the Inkscape package for you, but it will not install it into your environment. This will create some kind of, let's say, one-off ephemeral dynamic environment just for Inkscape, which will disappear after Inkscape ends. It is great for testing new stuff. It is great if you don't want to take care of any configuration or anything. If you have your configuration completely decorated, which you can, of course, even the packages, but if you want to try things, you can do it like this and you don't mess up your profile if you don't want to. So, testing packages is great, but can I test the configuration of the system as well? Well, of course you can, because the NixOS rebuilds command doesn't only do switches, it does a bunch of other things. Let's talk about the dry-activate thing. That's one of the more interesting things. The dry-activate does something like NixOS rebuild switch, except it won't do the actual switch. It will do all the builds. It will show you what will have to be done in order to switch to the new configuration, but it won't do the switch itself. That's good for testing things. If you have some kind of inconsistent configuration that requires runtime, runtime operation, like what happens basically, this is the thing that happens at switch is something like what happens in post-hooks on packaging stores, like unit reloads, runtime configuration, these kind of things. So, NixOS will tell you that this will happen if you want to do the switch, but you won't do the switch. Another interesting thing is the NixOS rebuild boot. This will build the configuration. It will prepare your boot loader, so if you reboot your box, it will boot into this new configuration, but it won't touch your current config. This is useful if you have, let's say, a kernel upgrade, and you're not sure that your current packages will work with the new kernel for whatever reason. So, there is one more interesting thing, and that is build VM. You can actually build your whole configuration into a totally separate virtual machine which you can play with. I don't know that if any other system does this. So, now you've tested everything and you want to try to break it, right? Well, this happens with common distros. You edit something here, you add a package there, and everything breaks, right? You've been there all. Well, not with NixOS. Good luck breaking that. Because, again, in order to break things, you would first have to switch to the configuration, but you won't switch on syntax error because the build will fail. You won't switch if you have compatible settings because the build will fail. It won't even build if there are upstream bugs NixOS knows of. That happens a lot of time to me when I try to build a new kernel with ZFS, because I use ZFS and ZFS doesn't always keep adding new kernels. So, if there is a new kernel coming in which is not yet compatible with ZFS, I go to message, hey, your package ZFS is broken, you can't do this, and I won't break my system. On Arch Linux, for instance, when that happened, and I missed the little message in Pac-Bun that something didn't happen correctly, but it still built a kernel, I reboot it, and the system isn't bootable for it, because there was no drivers for ZFS. This does not happen on NixOS. But what happens if you do manage to break the thing? I mean, it's pretty hard, but it is also possible. So, let's say we broke the system. Do you know what this is? Okay, for those of you who don't, I'm sure you know what this is, right? Yeah, it makes us as its own time machine. You really can do all these things because NixOS has all these properties. Again, this naturally leads to the time machine capabilities, but since NixOS is made by humans and it's not 100% foolproof, nothing is. You always have the option to do a rollback. I mean, if this switch happens not to your liking, you can just do this single command and your NixOS will rollback to your previous configuration. Well, what if the switch breaks the system? As I said before, NixOS configuration, we call them generations, are stored in your bootloader. So, even if after the switch, your system becomes unresponsive for whatever reason, you can always reboot it and pick whichever generation you like. Usually the second to last, because that's the one that probably worked, but if you do a lot of upgrades, it might be a different generation. What happens to these generations if you don't need them? Well, there is something called garbage collection which you can trigger manually and it works pretty much like your standard programming garbage collector. You've got profiles, you've got things that configuration links to and things that no configuration links to, and those are removed by the garbage collector. So, these are, I think, the most interesting things about NixOS itself, let's talk about the Nix package manager as well. I already told you something about the, I already spoke about it, the independency. As I said, Nix allows you to manage your own profile, your own packages, your own pretty much everything independently of the system admin, as long as you stay in your user space, of course. Users are also independent from one another, that's quite implied, basically. But you are also independent on your distribution or even operating system. NixOS runs almost everywhere. I've been talking about profiles and environments. These terms, I would prefer not to define them. These are the terms I'm using mostly for you. These are not, well, sort of official, but I'm not aware that these are being used as official as I'd like. But whatever, I remember I was talking about a profile here. I was talking about the configuration of your user profile mostly, the same way as you configure the system. Like you have a Nix, let's say it's called Nix expression, some sort of, you build it, you've got your configuration, you've got your packages and everything you define in there, and that's static. And when you change your configuration, a new configuration is created in the profile, which creates a new generation of that profile or configuration. And you can go between them as much as you can with the OS itself. But there's also this concept of environments, and those environments are dynamic. FMRO, you can make them on demand like I did with the Inkscape example. You can do much more complex configurations than that. You can create a, using this Nix shell capability, you can create your own environment for, let's say, package development. You can have multiple libraries with multiple versions of these different libraries having in different environments in parallel. So you can test your configuration against different libraries at the same time without having to touch the system or do anything fancy with like VNs or something like that. You can just create the environment on demand and you can destroy it after you're done. So that's, I think, one of the great things for pro users, but it can be useful for beginners as well. And of course, Nix once everywhere, like literally everywhere where Linux currently is, there can be Nix running on it. So you can run your Nix on your Red Hat systems. You can run it on Buntus. You can run it even on Macs. That's actually wildly supported by the community. Mac is the second largest, maybe even the, no, I'm not sure, but it's one of the two largest platforms Nix builds for. So even if you use Mac OS, you can use Nix on Mac OS without any hassle. And of course, it even runs on Android. I personally don't use that, but I've seen it working and I've seen there is a good support for that. There are ports for other platforms. I think I've seen a discussion about FreeBSD. Not sure what the state is, but you may follow if you're interested in that. Good, right? Well, sometimes NixOS doesn't really fit your need. And the most, the biggest example, for instance, with beginner users and normal users like us is unfortunately games. Specifically, and that is the sad part, Linux native games. Like Unity 3D games. I was unable to start two out of three Unity games on NixOS, no matter how hard I tried. Because, and that goes for native close source applications as well. If you have any close source application that you need to run, you might find it difficult to run on NixOS. It's not impossible, but it's definitely not going to be easy. Because something called the Nix Store. This is how Nix creates everything. It creates packages, files, configuration, everything. NixOS output ultimately lands in this directory. Which is read only for users, so you shouldn't touch it otherwise. And it contains, as you can see, it contains all kinds of random things. This thing, this is a cryptographic hash of the specific build of the thing. That makes it unique. And that's what allows you to have multiple versions of the same. Of the same library, because the prefix will always be different. But this prefix will always be the same if you put the same inputs to the same configuration. That's the immutability part. But since everything is easier, it means that nothing is in the common directories like UserLab or even bin or sbin or user sbin. These directories are usually mostly empty because the execution environments for these packages are built per package. And that makes things that rely on those, that assume these sort of standard, but not really standard locations to be present. And you have to fix those, and it's not easy. I don't want to go into technical details, but be prepared. And if you have any questions, you might run into these issues. So, I hope you have questions. We can answer here because I only went through like three or four things that might be interesting. And I'm sure there are much more use cases out there. Because each user is unique and have unique needs. So, go ahead. Well, if you want to build a closed... Oh, sorry, yeah. The question was, what do I do if I want to build a closed-source application? Well, if you want to build it for NixOS, then you can build it just like any other application. The distribution in NixOS is binary, so that's not a problem. But if you want to distribute it and for it to be compatible with NixOS, then my suggestion probably would be build it statically. Let it chip all the dependencies it has. Like all the dependencies. Like go applications, essentially. We can also talk about server use cases. Okay, go ahead. I'm sorry. Can you speak a bit louder? No. No, that's the NixOS switch does. It switches your current runtime environment to the new generation. But you might have to reboot it if you rely on things that only happen at boot, like kernel upgrades. That's the same with any other... I don't have any questions. Sorry? Okay, sorry. The question was, do I always have to reboot when I do the configuration change? No, you don't. Unless the change requires reboot by design. Yeah, the question is, what is the source of the packages? Well, this is interesting. Source of the packages, by default, is something that is called NixChannel, which contains information about all the packages in source. And there is a building build system that caches the builds, basically, and it stores them under these hashes. So there is an online caching system which has all these packages built with these hashes for the official channels. So you can either build them yourself or you can just try the cache if the package already exists in there and it's downloaded from there automatically. If it exists, if it doesn't exist, it gets built. How do I know that this package is built the same way? Well, you can build it yourself and you will see that this hash will be the same if the inputs are the same. That's the immutability part. If the inputs are the same, inputs being both the configuration and the sources, like a commit, a specific commit from the sources, then if you build it from there, then you will end up with the same hash. If you don't, then there's a problem somewhere you need to solve. And it's probably a different source or maybe it is a security issue. Maybe someone tried to touch your sources. So if you don't trust the caches, you can build everything yourself. I think other sources trustworthy, essentially. Yes, I think they are. I mean, Nixsoys is a huge distribution. Everything is cryptographically signed by the package developers. You can always go through the public history of the packages on the Nixsoys packages GitHub repo. And I don't want to lie here, but if I recall correctly, you should be able to know this hash before you even build it. This hash is calculated from the sources, not from the outcome. So you should be able to check. No more questions? No server admins interested in Nixsoys? Okay, there was one. Wow, how much space does it take? Most of the space, like the bulk of everything is in Nixstore. Almost everything. It's like if you have 50 gigs, then 49.5 gigs will be in Nixstore. It really depends on how many generations of history you want to keep. If you only work with the latest generation, then the space is pretty much the same as with any other distro. Like if you have many packages, let's say 10, 20 gigs, if you want to keep generations, multiply by the number of generations, essentially. There was a question over there, I think. Okay, go ahead. Can you have Nixstore backed by external storage? Yes, you can. As long as it provides basic POSIX compatibility, then yes. And I don't think even POSIX compatibility is required. I'm not sure on that. But yeah, it actually even happens when you have, let's say, virtual machines on a v-host, and the v-host can share its own Nixstore and share it to the machines, and they can share the packages, because again, the packages are addressable. Probably, yes. If you mount an ISO image, yes, the question was, can I use an ISO image? Yes, you can. Someone, okay? Is it possible to have a POSIX because you can enjoy it? Ha, that's a nice question. Is it other packages from other distributions available? Well, let me answer slightly differently. Nix packages is the largest collection of packages of open source applications out there. It has, yesterday, it has over 80,000 packages available. The second largest was Arch Linux AUR, and it has, I think, about 60,000. So there are good chances that your package is already packaged for NixOS, but if it isn't, if you really need to use some other distributions packages, you can use, well, Flatpak is supported, so you can use Flatpaks, and you can always just write a simple wrapper around the other distributions package. You can unpackage it and just put it to Nixstore as a package. But you may have to patch the binaries, so they look for the correct libraries of dependencies because usually it doesn't exist, so you may have to do a binary patch, but NixOS has facilities for that. You can use Nix for anything. It's essentially a build system, yes. You can, the question was, can I use Nix to package other packages for other distributions? You can use Nix to package anything. I'm not sure if there are default outputs for different packages, but there are definitely outputs for Docker containers, for instance. You can build a Docker container from a NixOS expression, from a Nix expression. Go ahead. I'm not sure I heard the question completely. I heard that the question is, how do Nix language is in terms of stability? It's quite good. I mean, I use Helix editor and VIM mostly, and the support is there. I'm not sure about VS Code, but even this presentation software has support for Nix language, and it's like two years updated. I mean, the highlighter, not the password, but the highlighter, is you see the language was highlighted, and that was the internal works of this presenting software, which is outdated. So the support is pretty good, I would say. No server questions, really. Go ahead. If I have a package that needs to change the state of the system, well, you probably shouldn't use a package for that. You should use something called a module, which is a NixOS thing that defines the configuration. Right. Do I, if I have to choose a system package like for web server, do I choose between NixOS and Apache, and how the package tells the system that it is not a default web server? You don't do this in NixOS. You just say, I want, you basically, I can actually show you, maybe. I can show you how the live presentation is presented on my, sorry. This is, it's lying a bit. This is how you do that. You declare a service. Okay, I want a service that is called Nginx. I want the service to have a virtual host with this name, and I want to do something like this with it. This is how you define a virtual host in Nginx, and this is everything. This is all you need to put into configuration for a full Nginx web server with Redirect, in this case, to work. So you don't do state changes by the packages. You do them by these, this is called a module. This is called a module services with module Nginx, which has some submodules configuration, et cetera, et cetera. There's a huge, huge numbers of these modules. Everything, almost everything that you commonly use is probably a module for NixOS. This is an NixOS feature, not a Nix feature, by the way. You've got something similar for your home environment using Home Manager. So that's how you do that. You don't change the state of the system by a package. You shouldn't do that to a state of the system, because NixOS is essentially stateless. One more question, go ahead. Yes, exactly. The question is, can I replace automation tools with NixOS? Yes, NixOS is by definition its own configuration tool. So since it's purely functional and fully declarative, it's, you say, Ansible, Puppet maybe, those are not purely declarative languages, but for instance, Terraform is. So if you want to compare, I think one of the best comparisons would be Terraform. What Terraform is for, let's say cloud infrastructure, Nix language is for NixOS. Can you start over, please, a little bit more? The question is about the state of the project of NixOS. How mature it is? What part are mature? What parts are not? I don't feel I'm the one to be answering these questions, but if I would have to answer them, then I would say NixOS at its base, the Nix language, the module system, it's quite mature, it's been with us for, I would say over a decade now, not sure about, I would say there is, yeah, thanks. It's probably well over a decade now. What is new and a bit unstable is features called Flakes, which I still want to talk about a little bit in a minute. And that's a different approach to Nix packages called Flakes. It's still experimental, but it's been widespread and it's, I think, pretty stable, but officially still experimental. But NixOS at its base, I really wouldn't have a problem using it or in production on service, in math scale. All right, let's wrap it up. Okay, one last question, but make it good. Can I run NixOS on the mainframe? I don't know. On Raspberry Pi, yes, you can. I'm running a Raspberry Pi home server on NixOS. All right, so let me give you a few tips at the end. Learn Flakes, already this topic has already been touched. Flakes is a new system for package management in NixOS and Nix. If you want to start with NixOS, learn Flakes. I didn't, I don't know much about them, it's biting me in the ass. Do learn Flakes. The official installer, I mean, there is a new installer, it's just a few weeks old, I think, which is the same installer as for Ubuntu and other systems, but there are a bunch of other installers. So if you are not comfortable with installation, look out for the other installers, they might be easier. Use Home Manager for your home configuration is the same declarative config as it is for your operating system. Don't be afraid to make changes, you don't break it, and once you're comfortable enough, try to install NixOS fully manually just to see how it works under the hood. There is a couple of resources. This presentation will be available later, so you can check them out, and thank you very much.