“Building unix-like operating systems the nix way” – Христо Георгиев

In this talk, Hristo Georgiev provides an overview of the Nix ecosystem, which includes the Nix package manager, the Nix programming language, and the NixOS operating system. He explains how Nix simplifies software installation and management by treating installations as functions, emphasizing determinism and reproducibility in builds. Hristo shares personal experiences using Nix for various projects, including creating custom container runtimes and managing configurations across different operating systems. He also introduces tools like Home Manager and NixOS Anywhere, which enhance the usability of Nix in different environments. Throughout the session, he highlights its open-source nature and encourages participants to explore Nix for developing their own projects.

And now I will introduce you to our next lecturer, who is Hristo Georgiev, and he will tell us about what Nyx is and whether it is edible . Hello. Hello. Oh, yes, as Irina has already given the most important part of the lecture, yes, we will talk about Nyx. So, what are we going to talk about today? We'll talk about what Knicks is, how I got into

this thing, what's interesting, what's not interesting. I want to tell you a few personal stories about what I use this thing for, what its purpose is, why it's interesting, and why I'm even wasting your time with it. I want to give you an overview of the world of NX. And what is the state of the ecosystem, what is happening, what projects are there? And I would really

like to go into depth, into the theory of what's what, why it works that way, but there's no way we can get into that in 30 minutes. So it will be more of an overview and I hope to leave you with an idea of how to have fun with NKS. Before that, who am I? And my name is Hristo, as you probably saw in the program. And

my website is HGorgiev. You might go see blog posts of questionable age. And on GitHub you can find interesting hobby projects and not only hobby projects. Why should you listen to me? Why should you trust me? The answer is that you shouldn't believe me. This is Openfest. Lotto things I'm going to talk about today are Open Source. They are on GitHub. That's the whole point of NYX,

Trust But Verify. Everything is possible. You go, read code, watch and act. Disclaimer. And I've heard that's what people do. Disclaimer: everything I will talk about today is my personal opinion. It is in no way related to my employer. I am here absolutely free of charge. Nobody pays me for anything. I'm not affiliated with any institution that has anything to do with Nixie or anything. And why

am I here? And I really want to share with you something that I think is interesting, to ignite you and maybe the point, right, of Open Fest is to share knowledge, because together by exchanging knowledge we become better. So just as you might learn something new today, I'll learn feedback from you later, and maybe next year we'll talk again at the same time, in the same place

about who did what cool projects with NYX, and not what NYX is. So let me get to the point. Ass quiz. What is NYX? Possible answers are a programming language, a package manager, or a Linux distribution. The correct answer is yes, all three. This is the first confusing part. NYX's branding is a bit complicated. And in reality, NYX is all three things. NYX started as a package

manager that used a functional programming language, also called NYX, to configure itself. And that grew into NYXOS. Usually, when talking about NYX, the entire ecosystem is meant. In most cases, it is about the package manager. When we say when we want to talk about the operating system, we say NYXOS. The programming language, by the way, is functional. Are there any Haskell fans in the audience? Okay, fine.

I guarantee they're both here and very excited right now. They're just a bit introverted and don't show it. Well, they will be very happy with NYX. So I couldn't hold back. A small etymological fact and we move on. NYX means snow in Latin. That's why the logo you see in the background, that's the NYX logo, it's a snowflake. And if you look a little closer, you might

see that this snowflake is actually made of lambdas. Why is it made of lambda? You might ask the two Askel fans in the audience. It all started in 2006, when a young man named Elko Dostra wrote a paper. The paper is called The Purely Functional Software Deployment Model. Purely. A bit of a play on words here, as this is about functional programming. So pure functions, right? Anyone

who is familiar with these things might find it interesting. So Elko compares the basic things we know about installing software, because installing software is like that, with the accumulation and maturity of operating systems, it starts to become very complicated. However, at its core, installing software is just putting some random files in a folder and then executing them. In a sense, it shouldn't be super complicated. The complex

part is in the variety of ways you can build this software and in run it, because the environment changes and he says: "What if I imagine that everything is in a function, because those people who love functional programming, for them everything is in a function. It's very easy there. And the nice thing about functions is that if a function is either pure, it always takes the same

input, it always produces the same output, which is very useful, because it removes all the complexity about what possible scenarios there can be. And the whole mooper, by the way, it's quite approachable, we recommend you read it, is what if we look at building, installing software as just a function and describe how this thing can happen. Naturally, as a true functional fan, he says: "First step we

write a programming language called NYX. It is lazy evaluated, which is important for reasons. Then I can explain, but briefly, in general terms, you have a function that tells how I build software, for example Firefox, and hypothetically Firefox has a depend on the FFM pack. Hypothetically, I don't know why there would be , but let's say there is. When you go to disable Firefox, he says: "Okay,

Firefox needs input from FFM. It's lazy to install it, but until someone asks for something, it won't resolve it down the tree. And this actually turns out to be a very cool idea. We won't get into a dry theory about why this is cool and why not, but in order for this thing to work, he says we put everything in a NYX Store. However, the NYX Store

clashes with another idea, which is a very fundamental Linux idea for FHS. FHS stands for File system hierarchy standard and it's a standard in Linux that says what each folder is for. And for example, if you read the standard, it says where software is installed. It's put in the bin or in the user beam folder or in the user local beam folder or sometimes in the OPT

folder. And in general, it's a bit like this, this standard has evolved, some things have been moved, it's a bit of a matter of interpretation. When every piece of software is some kind of output and every change the way you build this software, it produces a different result, you can't follow this standard for many reasons, but the most basic of them would be that if you have

a banner called FFMP, for example, you can't put both banners called FFMP in the same folder, because they will interfere with each other. And he says very simply we will hash the uniqueness of each of each binary and we will put it in NX and that's it . We forget about the FHS, it's not that important. This is also one of the main differences between NYX and

any other Linux operating system, that it doesn't care about this standard at all, which has its own peculiarities when we want to dynamically link some libraries and things like that. This gives us a lot of things, as for starters it sounds like a very cool process, that if everything is the same input, it always gets the same output, that means we can deterministically say that this comes

from this. That is, for example we remove all the suly chain tax, because I can say that this source cd produced this binary, which not many other systems can prove. And actually the interesting part for us is not so much suly chain tax, because for us as people who just use Linux, not all of us have this problem. The more interesting part is the other interesting side

effects of this and more specifically that first of all everything is the same, that is, the same input always produces the same output. Second, everything is mutable. Once I build it, it is forever like that and in fact it has no reason to be mutable, because if I change something in it, then this thing will produce a different hash and it will be a different artifact. So

there is no point in changing anything. This gives us very cool effects, because for example let's say you have some binary, we started with FFMpack, let's say, we are talking about FFMpack. I want to update a new version of FFMP in the classic distributions. You run the package manager, it goes, downloads, the compiler maybe or just downloads some biny from somewhere and replays this thing in the

user bein folder. Now then, however, in order for it to actually work, it has to be reloaded into memory, if it's already there. Maybe you have to restart, maybe you have to do some things like that. In NYX, it won't play FFM pack. It will put the very old FFMpack, a new FFMpack and will build again, compile these things and at some point it will crash. That

is, it is practically impossible to have half-broken upgrades. You can't have your operating system upgrade break in the middle of the upgrade and you stay in a broken state, because it will first build everything and then crash it. If something broke along the way, there's no way you can have the upgraded operating system broken. The same goes for rollbacks. Then we'll talk about what NYXOS Generations are,

but generally speaking, every single thing, that I have installed, produces a generation. This generation can be run in exactly the same way as it was installed. Accordingly, this has another cool side effect. We have a collection at the package level in the operating system. Because everything is code, everything is input and output. By extracting the entire tree, I can see which package I upgraded and absolutely no

one uses it anymore . Accordingly, I can clean it up, I can have a number of packages and use them, a number of versions of the same software, use them in parallel, or if I don't want to use the principle, I want to use only the last one, I can run a garbage collection and have it clean them up for me . The other extremely interesting side

effect of NYX in my opinion is that most operating systems that I have seen, most package managers are either source driven or Binary package driven. NYX is initially source driven, that is, NYX accepts instructions on how to build this software, but in reality in the real world you almost never build software, unless you did something custom, because usually you pull the binary cache, because everything is reproducible

and I can prove that this source code produced this binary. When I give you this binary, you don't need to trust me. Nick guarantees that what I gave you is not in any way contaminated. I didn't put some root kit, I didn't put some little things inside it. That is, NYX considers Binary distribution as a cache optimization of source code on the source CD build, which I

think is quite unique. For example, Freebsd is one such operating system that has ports. The ports are source based. There is also PKG, where you can install binaries, but these two systems, the two package mandra, they don't know about each other. With NYX, this is the same thing. So. enough with the theory. I promise we won't talk about atomic things like that anymore. Now we'll talk about

fun things, how I had fun with Nix. All that I told you at the moment, I didn't know who Elkodostra was. I didn't know all this stuff about Nix and a few years ago I was just a bored young man who was approaching Christmas holidays. And yes, by the way, I forgot to warn, I have a very small AI slop in my presentation. I hope you can

bear with it. Well, Christmas is coming. I have prepared a book to read. The book is called Building Orchestrator in Go from Scratch. And I'm thinking how cool it is. Now I'm going to have a few free days here and I'm going to write a container orchestrator, I'm going to make something like Moses Kubernetes and start doing this thing. And I also realize that the whole book.

I don't want to say anything bad about the author, who by the way is called Boring. I don't know if it's a coincidence, but the book is basically about how to download the Docker API to GO, which is not particularly complicated. How to start containers, how to stop them and how to schedule them if we have a lot of nodes running them these containers, how to distribute

who goes where, which is very cool, but it sounds like it will fill me up by the end of the day, and that means that if I finish here, I have to go talk to my family in the other room, which no one wants. And I decided to complicate the task a little and said that I would make my own container Runtime, not just an orchestrator. And

so BICR was born, which I am not very proud of now, but it is also an abbreviation of Bit Container Runtime. I wrote this thing and it turned out that it is actually not super complicated. By the way, these are links that are in the presentation. Then you can see them, look at them with the code of all these things and it turned out that it is

okay, but my runtime does not build, it cannot run docker images and I have to build the containers myself to run these things. And I tried again, I tried dead boots and other cool tools, but they are not enough so interesting. And of course what do we do? We take Linux from Scratch. And so BI in S was born, which is another project that you can also

see on my GitHub. And I sit down and read Linux from Scratch. I've always wanted to build my own Linux distribution and I hadn't read it. By the way, I recommend reading the book twice. The first time just copy-paste things, because the second time you should try to understand what's really going on. And I realize that half of the book is how to build the toolchain so

that we can start building the operating system, which is quite complicated and I wonder, well, does it have to be so complicated, can we do it better? And then I discover NYX for the first time and I wrote this great code, I'm not proud of it at all, but it's historically important, because because when I build Linux from Scratch, I needed certain compilers, certain versions, so that

I could be sure that I was producing something that really worked and I wrote this a NYX code that installs a bunch of things: Corals, GCC, WG and other things like that. And I wrote this down in my notes, because when you run it with NXL das Pure LFS, this thing starts, which first installs these things in it. That is, you guarantee that you have the entire

set of things available to compile whatever needs to be compiled. And secondly, it is a pure shell. For me, this is very important, because pure shell means that if something is not mentioned in this, then even if it is installed on the operating system, I do not want it to exist for you. This is important for me, because if I give it to a friend this same

shell, if he uses I don't know Alpine, some Linux, I use Ubuntu, I do not want something not to work with him, because I forgot to put something in the shell, which my operating system has by default, his does not. So this in itself is useful, but not that much, right. At that time I did not know more details, but now, if I started to I do

this thing, it would probably look something like this. Now it looks a little more complicated, but it 's basically the same. We create one. This is just a def environment in which we install some tools. What's different here from the previous version is that first of all here we already have input and output, that is, we follow the principles that everything is a function that has an

input and output. This output I said will work on these two operating systems X and on X86 and on an RM processor. And this will have these things. Now why is this better? Because first I specified the architectures, but that's not that interesting. What's more interesting is that I gave it input. That is, I said this thing will be built from a specific version of NYXOS. If

you have, for example, Debian and you install some packages, these packages are then patched. If you upgrade twice at different times, you get different things. When it comes to NYX, if you have one flake and tell it this flake works with this version, it will always process exactly the same thing. That's the whole point. And actually the secret to this whole thing, because here when they write

NYXPG unstable, it sounds a little strange how unstable, but actually Super Power is that we have a lock file. If for example you write no JS, as you have package jon you have a package log, in exactly the same way you have flake NX and flake lock. And in this LK it is described exactly what is happening, exactly what each package was like at the time of

the build. That is, if I write some software, package it, release it, NYXON Stable may have moved on, it may have received new patches, it may have received new software, Nixon Stable may already be something else, but the hashes are the same and they will always be reproduced in this way. You can look at this as if you have MPM and NVM, that is, here you have

the compiler and the packages and the Runtime - everything is described in one thing. Aon stable sounds a little vlekki, but it 's not really that different from Deban testing. Debian testing in my experience, at least it's called testing, but it actually works most of the time . So NXON stable is something like that. If you want, you can pin to the stable versions of NYX. Right

now, I think the latest one is 2510. Ah, it's related to the years, months of release and things like that. So I actually found that I can in every project that I need, so what I started with was Linux from Scratch, but it could be anything else, I can just put a single M file, a single flake file, put def, which is a very cool one, which

automatically detects that you enter a directory that has a flake, automatically activates it, installs all the available software and it sets up everything necessary. The nice thing about this thing is that this applies to all programming languages. If I write JavaScript, MVM volta are such tools. If I write Python, VM. If I write Java SDK. Every language for programming, which I have ever worked with until now,

there is some such software. And I am already tired of learning how they all work one by one. I want a lol that will solve this problem for me forever. First we can install a compiler, runtime, other things like that, but then we can also install various dependencies. For example, you have a project, it depends on postgres for example. Absolutely nothing stops you from putting postgres as

a dependency in a flake and starting it like that. There is no need for def containers, no need for various virtual machines, no need for any such things. Now you will say well what is wrong with Docker Comp? Doer compl is no problem. It is great, it works. If you work on Linux, your containers come Natively, there is no very big overhead. If you work on MacOS

for example, however, the containers work in a virtual machine. This is an overhead that you can save. You can install, for example, Native Postgreay for MacOS for RM. The alternatives, by the way There are a lot of interesting ones on the flakes. There are three very popular ones. Here are called Flx, Defbox and Devf. The interesting thing is that all three are based on NYX and all

three are trying to solve a problem and that is that flakes, if you remember two slides back, look a little bit intimate at the beginning. you see a wall of code and you don't know where to start with this thing. These three tools are trying to make it much more user-friendly. They are trying to make it easy to go and see a little bit of a higher-level

declarative language that they will translate for you down to NYX, which is great if you want to try something like that. And a piece of advice I advise you to try one of these tools, but my experience shows that even if you start with Flx, which is very easy and useful, at some point you will want to see what is happening underneath. Maybe it's just me, but

at some point you may have to learn how the NK thing works. Like The first lesson I learned from my encounter with NX is that I can build death environments and in these def environments I can put compilers, put dependencies, put run dependencies. I can even build environment variables and all sorts of things like that, so that I can run my entire project. Right now, when I

start a new project, no matter what, no matter what language, the first thing I do is put a flake in there, because I don't want to try to figure out which compiler this was compiled with last time. I just want to run it. So this comes to my second topic, for which I decided to use NYX, and that is Does anyone know what Racing is? Have you

heard of this term? Okay, we see a couple of hands and that's great. Racing, for people who don't know, is the practice of tuning your operating system. It comes from racing, like we have car tuning. In the same way, some people they tune the operating system. It has a bit of a negative connotation, because not always tuning is particularly useful. Sometimes it's more of a visual tuning.

We put stickers on and everything looks really cool. But it doesn't have to have a negative connotation. So at some point it hit me. Okay, wait, I can make death environments. My whole computer is an environment. Can't I manage a def environment and my computer with NYX? And it turns out I can. And actually, this is nothing new. People have been managing Dot Fils for a long

time. Dot fguration. You can put whatever you want on it. So do you really need any software for that? No, you don't. You can just copy and paste files between different machines and it will work. Until recently, I used a software called gnust. Stl actually takes some files and symlinks them to the right places so that the software that uses them can load them. For NYX, there's

something called Home Manager. Home Manager is, as the name suggests, manages your home folder. That is, you can put different configuration files there. Both problems that it solved for me are first that when you make the dot files once, it is very cool to be able to use them on more than one machine. And in my case, these machines are sometimes not the same operating system. For

example, my TMU is the same TMUX on OSX and Linux, but underneath the operating system is different. Accordingly, some differences in the configuration begin to appear. And I have two options. Should I start managing TOS configuration for Linux and Tinux theme for OSX or can I just write some minimal code that will switch for me, recognize which operating system I am on and apply this or that

and reuse the common things. And my other problem was that when I build mainly for Linux with different desktop environments, I very often forget to install some tools. For example, one such lol is W. is a very small tool that shows when I increase and decrease the volume or brightness on my laptop, it shows me a progress bar to what extent it has been increased or decreased,

which is the configuration there. I go and buy a new computer, I start increasing the volume and nothing happens. I hear what is happening and I forget every time. Home Manager allows you to collect your installation and configuration in one place and you can practically manage your entire operating system with this thing. Of course, only in the home folder. Here we do not move anything outside of

it. So. Now I will show you some very quick examples. And these are my dot files at this address. Steal. The best thing you can do if you want to start with your own DOTFs and steal from someone else. They do not have to be mine. Dot files are like a poem. And they say that a poem is never finished. It is just abandoned. So my DOT

files are always work in progress. If you can benefit from them. I'd be happy. If not, then so be it. So let's say you have TUux, which I already gave as an example. You have a standard configuration. For example, I use control space as a prefix for Tux. The absolutely most minimalist way you can use a home manager is to tell it "I want you to install

the package and TUX I want you to load this configuration into it . That's it. There's nothing more you need to know about NYX. This will work and there is no way the configuration can be applied without the banner being there or vice versa. This doesn't seem particularly helpful. It becomes more useful when you use the built-in home manager modules. And for example, this is my Git

configuration. For example, here, I can't forget to install Git very often , because I use it daily, but I very often forget to install Git LFS. And that will guarantee me that this will always be there. It will ensure that my configuration is always the same. The key with which we sign the same mei branch. Everything is the same everywhere. And this is reproducible on all my

operating systems. If you want them to use something in between, for example, I use alacriti on most of the operating systems I use and I don't want to use the entire module. I can make an intermediate version that I made a custom module for Lakriti and I said I want the font to be different. Everything is exactly the same. Use the tomal file for all my operating

systems. However, I want different configurations to be able to use this thing. That's right. We can cram all these home configurations into one big flake. And here's an example of how I say this is my source NYX from take me from NYX Unstable. Use Home Manager. You can see that this actually downloads it from GitHub. That is, there is no complicated hidden way to distribute this and

that software for NYX. And I start loading some configuration. I say include me to home git and TUux. This can be planned on any operating system that supports the NYX package manager. You don't have to use NYX in any way. It works on Mac, it works on Linux, it works on most interesting operating systems. Speaking of Max, there is a very nice software for Mac called NYX

Darwin. NYX Darwin enables people who want to manage their OSX operating system to do so through NX. Basically, the people who manage Dot Fil for OSX, so with every upgrade, Apple changes some things , which means that we break things and with every upgrade we have to go find where they moved this configuration for me with this upgrade. NYX Darwin abstracts this thing, gives another level of

abstraction on top and says now I'll apply these things to you. You don't need to know where it is. You can see here that I'm using Home Brew, because there's not much for OSX and there's not much graphics software in NYX packaged, you can use Home Brew, install some things like Spotify, Chrome or whatever else you need there. Generally speaking, the situation is that I have one

package manager, with which I manage the other package manager, and at some point, okay, I build the configuration for the operating system, I build all the configurations for the applications inside, I install software, and I start thinking, okay, are n't I practically building different distributions? What exactly is distribution? A distribution is a specific set of software with the configuration for it, and it actually turned out that

it gives you something very close to having a framework for building Linux distributions that are absolutely customizable. And we come to the third thing I need to do . I often have to work with some servers, and once you get used to all these NX niceties, when you start talking about servers, working with them, you start to miss all the things that are there. And I'm like,

okay, can't I start orchestrating some servers with NYX? Why not? In the specific case that I needed, I had to lift a Kubernetes and I started lifting several machines. When I install virtual machines on my computer or have real hardware on my computer, I just plug in the flash drive with the installer and install. Everything works. But what happens when we go to the hyenas, to Amazon,

to Asure, to Google and say give me NxOS and they say you're some kind of junk money, I don't know what that is, right? The only thing I found was that there was some tutorial on how to build this on NYXOS, which didn't look very cool to me. What you can do is install NYX, the package manager for any operating system, and just use your proximity. However,

this doesn't give you many things that NC would give you. For example, it doesn't allow you to manage system services, it doesn't allow you to use NYX modules, a bunch of things like that. It allows you to activate your chosen software, but to use it as a user, not as a whole system. And here's a really cool one called SystemNiger. Basically, a company of young people came

up with an idea and said: "Okay, what if, just like we have a home manager for the home directory, what if we write a system manager and we can install it on any Linux." Great, this gives us a system, it gives us modules, it gives us the ability to manage the configuration, it gives us everything. However, this underneat does not change the operating system. For example, if

you install a Ubuntu and add a system manager to it, what's underneath is still Ubuntu. That is, it cannot manage absolutely everything. It gives you some more polished tools, but not everything. And here comes one of my favorite tools ever. It's called NYXOS Anywhere. NYXOS Anyware is the closest thing to what some people would describe as a NYX virus. NYXOS Anywhere finds an SSH machine that you

hopefully have control over and permission to use. It goes through it, uses exec, loads NYX into memory, runs the installer, uses another tool called NXO, which is called disco, to package all these things and installs NYXOS. This is a true full feature NYXOS. It's not just a packaged thing put on top of your operating system, which is great, but it still requires some NYXOS stuff, it requires

some kind of Linux to be pre-installed so I can put NYXOS stuff on top of it. And here's one of my other favorite NYXOS Generators. It turns out that I'm not the only one who has this problem, it turns out that others have had it too and have written one. They are actually helpers on top of the base NYX, which can package the configuration that you made

for NYXOS onto whatever you tell them, onto AWS, for example AMIMGes for EC2, Aure, GCP, Linux containers, Docer, Virtual Box, whatever else you can think of. For example, when I want to do some slightly more complex configuration, I say, generate a QC image for me and push it into QMO to test some things. This practically you can deploy the same configuration in EC2, you can test it

in QMO, and you can burn it to an ISO flash drive and boot a Life CD from it, all with the same configuration. And this gives me the opportunity to have NYXOS Generations on my servers , which is one of the coolest things, because I told you we have atomic upgrades. Each installation generates a generation and here you can see, these are actually my generations and you

can see that the 38th generation is current, but at any moment, with any upgrade, if I've broken something, I can roll back, which is great. So we're back to my problem. I want to raise a bernetis cluster, what do I do? I'm picking up this super minimal flake, which in this case I'm depositing on digital. Digital ocean uses Qo underneath. The only thing I have to do

is turn on the cloud. Cloudit allows my virtual machine to take its settings. I put in an SSH key and start working with this machine. In this case, I have only installed four packages: Curl, WG, Git, and Vim, because that's the most important thing. Wim. This is the case for me because I chose the approach where I want to set up very minimal machines and float some

configuration on them, but nothing stops you from doing absolutely the entire setup, the entire virtual machine, including your software being packaged and deployed with everything as one image. This is one way I have chosen to install minimal flake and make a custom configuration on it. To make a custom configuration I use another very nice tool called deployer s. Deployer can take the configuration and describe different hosts

that it can deploy to on an existing NYXOS. And here the most interesting part for me is that you can see the Remote build parameter. Because NYX reduces the entire software installation problem to a simple copy, we can choose the software we want to install. Which machine should we build it on, which machine should we install it on. That is, if you have a very powerful machine

that you are building on, your desktop for example is very powerful, you can build it on it, you can also build it on a repair machine, if it is more powerful. This is actually a file copy. And for example, in my case, my digital droplet had 1 GB of memory and I launch a build by inertia and it dies because it doesn't have enough memory. And as

it is, I put a slop and it worked. However, for example, right now, this conference, those people in the back are recording with a machine that is configured with Mix OOSOS. MixOSOS is naturally a play on words from Mmixer and NYXOS. So we did all this configuration with NYXOS. When the machine starts up, everything is installed in it, all these things start. This configuration we hope at

some point may need to be able to run on a Raspberry Pie. If you have to build all the software with Raspberry Pie, it can take a very long time on the Raspberry Pie itself. You don't want this. You want to have a powerful machine that builds things and you want to have a machine that just runs them, which sounds to me like a super cool case

for any embedded deployment or if you have any type of deployment on any machines. Because we can push files from the machine and put them on the machine that will run them, but we can also do the opposite. We can build the software and put it on some server and let customers run it. One such tool is Cashks. Cashk is a commercial service where you can go

to pay some money and they give you the opportunity to use it outright. But actually, with this configuration that I have given here, you can make your local Nni Cash publicly accessible and people can simply configure it and start using it. That's right. And now I want to tell you about a few interesting Note Wor projects that you can play with . And NYX runs on all

sorts of exotic operating systems. Some of them are even DOS based. Nixel SWSL is a very nice tool. I personally tolerate it. If you have to work on Windows, you can put it on and use all the pampering that NYX offers. NYXOS BSD is an unofficial fork of NYX, but it actually shows that NYX is just a tool for building and installing software. There is absolutely no

reason why it shouldn't work on BSD. If free BSD is your thing, try NYXOS BSD. I think you'll like it. GUX is an extremely interesting is trying to fix the original sin of NX, specifically they don't like the fact that NX is written in NX and they say the obvious choice is SK. Obviously you should have written it to SK. Our friends at the Free Soft Foundation

have rewritten it to SK. There's a leak that says well, it's really cool what you've done, but it's slow. I'm going to rewrite it in growth and we're going to rewrite it slowly, module by module, which I don't want you to confuse with the other Twix project, which is also rewriting it in growth. I'm not sure that's the difference. I know they are both tall. There is

one important project that is on Determined NYX. This is the company where Elcdost works. They're trying to do NYX for the Enterprise. For example, if you use the fully open source NYX and install it on your OS, every operating system upgrade breaks NX and you have to reinstall it. They have the absolute killer feature of not breaking your computer when upgrading the operating So now the question

is how would you like to get started with NYX, if you want to enter this world, you want to see how you can start. I recommend you first try an NX flake with some def environment if you want something to test. This is the most non-invasive way to try NYX. He works in one folder, nothing outside that folder is affected. You install, test, configure software. The second

step would be to install home and try tuning your entire operating system environment. I say again, steal the best from someone's dot files . Then, if you want to be a little more cautious, bring up a virtual machine with NYX, test some things, see what might break, rollback, everything is great. Finally, I recommend you check out NYX Pills, where you can find checkpoints that can introduce you

to NYX. If you like this, you might want to get really deeply involved in the project. The easiest way to access NYXPG is on GitHub. You could go package software, see how people do some stuff with NYX. The NYXOS Foundation is a non-profit organization that tries to move NYX forward and they, along with other organizations such as the Free Soft Foundation Europe, take funding from many places,

but one of them is NJI Zero. NJI Zero is a product of a European Union project that attempts to achieve software autonomy in Europe. They want to give money away to open source projects. NGI Zero donates money to the NYXOS Foundation. If you are applying for a project, you want to do something, not just NYX based, of course, you can apply and receive funding to do it

open source, which I think is a good idea. This is the point I wanted to tell you. This is a link to the presentation, all the links for people who don't mind typing that long address, you can scan the QR code. Thank you. Okay, let's thank our speaker again and we have a few minutes for questions, in case any of you have any. You can command the

microphone in the middle of the hall. Questions first time, second time. Thanks for a very interesting story. A lot of putts for the Knicks, but so much detail for the first. Otherwise, I have the following question. And there was also talk about combating problems with chain attacks. However, your examples here explicitly state that you are using the master branch for some sources. This is not very certain

from this point of view . It may sound counterintuitive that I'm using some kind of unstable branch, but realistically, once I've installed it and tested it and verified that it works, I say this is something and lock it. So if this master branch changes, those hashes will be changed and I won't have a build fail after that , I'll say someone changed something. This is not the

same thing you tested. Well, I'm not talking about this unstable version, I'm talking about those modules that are used as source for the same job. Yes. But even when using Unstable, each unstable installation is pinned with specific packages and the hashes of those packages. Hmm. So we know that this is the thing we tested. No one can change it. And another small note, that when you use

a fixed version of Debian, it stays the These changes are either not the case or you are using a fixed alias. Okay, I don't really understand them, it seems to me that they're patching things up anyway, but I could be wrong. okay. Well, we don't have time for any more questions, so if anyone else has anything they'd like to discuss with Hristo, maybe he can find him

at least some of the time behind the video team table, as he mentioned, and with a few other people who have used Nix for streaming in the streaming setup that we use in this room. And now it's lunch break. And I remind you that there is a grill outside, which also has things for people who don't eat meat. And I want to remind you about the light-hearted

talks that will be held in Hall B. Today they are from 4:00, not 5:00, but if anyone wants to tell something to the Open Fеest audience for 5 minutes, they can sign up at the reception.