I will introduce you the NIST configuration system. Just to clarify, how many persons of you have installed NIST? OK, so I will first describe the NIST packages and all that stuff.

I guess nobody knows about it except a few persons here. There is first the language, which is called NIST, which is a functional language, which is pure, so we don't have side effects, except for trace and debug stuff.

We have NIST packages, which is a collection of packages, like RPA and BPKGs. We have NIST, which is a distribution based on this collection of packages.

The main idea with NIST is to put at the same rank, same annotation fault, or access to a bad memory page that you don't have allocated, and no such file or directory, because if you have a reference to a file in your file system and you haven't installed it, you have no such file or directory,

and we put that at the same rank. To avoid confusing with the packager, we have a directory which is a NIST tool. In this directory, we isolate every package, so we don't have a slash bin and stuff like that.

We compute an hash for each package in the function of the sources, the libraries, the compilers, the build script, and all that stuff that are used to build the package. If you change one of these, you should get a different hash.

You can have multiple installs of OpenSSH, because you have changed the build script or the compiler. Now, with OpenSSH, we have a NIST file, which is almost this one,

where we have a function in NIST, we have a standard environment, and a function which is called net derivation, to phrase the package in the NIST tool. We have the name of the package, we have the sources, and another function to fetch the sources from a URL,

and we have the command to load it. The standard environment and the function is used to include the default compiler, the enterprise command tools, and the new make. This is the expression used to build OpenSSH, almost.

To use this expression, we have an index file, which is all packages, and we have other index words, special third packages, for example. In this index file, we say that OpenSSH is this one,

and the lib is this one, and we use the NIST language to create this derivation. When we evaluate OpenSSH, we evaluate the derivation, and we can instantiate it by creating a path in the NIST tool.

Now we have a bit of knowledge about NIST, we see that everything is awaiting, and why not use such things for other stuff?

We could use this for generating configuration files. If we suppose that a configuration file can give all its inputs,

we can generate a configuration file for all packages. So we have done that. We have for the system starters the initrd, we have for the initstreet, and all the stuff which comes with your distribution.

As long as you can express it in NIST, there is no problem. We've made a distribution which is called NIST, and this distribution, you can build all static parts. All static means that we don't support databases,

and every file which is mutable in the same sense, we cannot produce it when we build the system. So as every package or every configuration file is isolated in the NIST tool,

we don't have slash lib or slash usr. Upgrades are non-destructive, because when you install something, you install it in the store, and in the store you have different set of packages, you can have multiple and SSH version in parallel. So if you change the configuration, you can install a new version,

and when you install the version, you just change the link to the versions that you want to use. So we can roll by just using the previous version, and as we just have to change the link, upgrades are atomic.

The fact that we need source is stateless, it helps us to reproduce it, because we have all the inputs that we saw before, and we have a specific age which is determined by the inputs.

So we can reproduce the same configuration, we just have to copy the configuration to reproduce something. So here is a small example with two terms and emacs, and you see that in Lightning we only have SSH,

because the linked kernel requires it. But slash usr is empty, and slash lib is empty. No, it's not empty, it does not exist, and slash lib, slash lib does not exist too. But we have more funny stuff.

So not on my computer, because my computer is too old, but you have a compass, caddy stuff, barriers, so just usable as a desktop, you have its size.

So to show how configuration files are generated, we have SSH config, which is just a file, which is stored in the next store. So we have a function which creates a derivation, we give the name of the configuration file,

we have a statement which decides the function of the user configuration, whether we choose to enable its 11 forward or not.

It makes this a lazy language, and if we don't evaluate this configuration file, we won't serialize this information, we won't evaluate its old, its old, so we won't install it, because it is not required.

And there is one special thing, is that when you enable its own forward, then your SSH config will depend on this program.

So it depends on this hash with this package. It depends on this package. So by installing the configuration, you implicitly install its dependencies. So when you install the configuration,

you install all programs that are required to run your configuration. So you don't have to first install the program and then find out how to configure it. And the generated file is what we see at this page club,

and we have forward its 11 and the path to the program. So we will go further in the configuration. And in this source we have a main configuration

which is placing etc in its source, called configuration.next, which is the files that the person has to edit. Unfortunately we don't have a graphical interface, it's at the image or the eye.

And you put all the configurations that you need for your system, like where the bootloader should be installed, what device system you have to mount, just what device that you want to use. Devices. And in this case we set the SSHT configuration.

So here we have an attribute set with options that are defined. So as a user you just edit this configuration file, add a new option which are describing a manual or in the main page.

And you just have to run one command to build your whole system. You just run this command and you say that you want to build the system, which will build the system, or you can switch which will replace your current system by the new one.

And when you have installed this new system, we have to activate it, because the sylink is not enough to make your configuration usable. We have to change the WUD,

we have to change some files which are required to be in slash etc and not to be sylinks for security reasons. As we saw, we integrate a neat system for rollbacks. So as you saw in my menu, I have a lot of versions for coming back to previous configuration.

So I will continue in this configuration, I will describe a bit the syntax. In the syntax you can say that it depends on other files

that you want to embed their content. So here I have created a configuration for this room, and my configuration requires that I need this room. So I want to enable the server, and I want to use a small footprint window manager,

because it's a very old computer. So the syntax is that we have imported files and option definitions. This syntax is used for slash etc configuration that needs, but you can use another syntax which works as well,

where you define imports and option declaration and option definitions. We will go on option declarations. So I created a new module,

which is an attribute set where I define the options, and I define that I want to attend the option to describe if I attend or not as a person. So the default value for this is true. I define the time, which is a mix function.

I give a useful description, which is not the case here. As types are defined in mix, we can have multiple types, and we can use mix language to define new ones.

So we have booleans, strings, and we can define how to handle variables, and how to merge multiple definitions of an option. So if one person defines that he wants a path to be sent to something, and another module defines the same path

to be sent to something else, we can decide how to merge them with a colon between them. We can use derivation or lists of another type. Now we will see how to use these options.

So here we are in the section for option definitions, and we define the SSHG enable in function of the configuration. So this argument represents the whole computer configuration.

In this argument, you have everything about your computer. We add this feature from the laziness of the language. This argument is a merge of all modules, which reproduces the same types of modules.

So this is the option that we have defined in another module, and we use this value from the whole computer configuration. In this case, we want to say that we want to disable SSHG if we add the false name.

When I say this argument merges all modules, this merges also this one. So this module is included in the whole configuration. So this introduces tricky things,

which cause the next control flow to break. So if we want to check the value of this option, if we add an access to them,

then we want to disable SSHG, otherwise we take other values. The problem here is that when you want to evaluate that you add an access for them, you have to evaluate the argument, and when we evaluate the argument,

you merge all modules, so you have to know what are the options defined in all modules, and then you can define the access to it. So to know all options defined, you have to evaluate all configured in each module. So if we want to evaluate this one,

we have to evaluate this if statement, and we have an infinite loop. There is another problem, which is that enable by the merge function, which takes by default the true value. We fall with the OR.

So if someone else has another module defined that you want to enable SSHG, we can force it with only defining false. So we need to introduce control flows for modules.

To do that, I've introduced properties. Properties annotate definitions. So here you have a definition, and I want to say this definition is only valid if I have this function, which is a property, which will annotate the enable definition

with the condition that I want to define this value only if I attend the false term. And I want to override the value with the 10 priority. So we annotate each definition,

and when we evaluate configuration, we just take properties and we move them, we delay them until we can really execute them. So we can really execute them when we are at the equal here. When we are sure that there is no retraction

unless the user made it. So we delay the if statement on the service, and when we go further on SSHG, and when we go again further on the enable definition. To express these properties,

we have four base functions which are onDelay, which define how to heighten the property when we delay it. We have onGlobalDelay, which is the same thing, but with knowing what are other properties.

We have onEval, which is used when we evaluate the value. And we have onGlobalEval, which is used when we evaluate the value, but with acknowledge of other properties. This allows us to define many properties.

So this property is used to define that we don't have a definition, which is not the same as an empty definition for example. False is not the same as not defining false.

We have the if statement, as presented here. We have override, which allows us to decide which definition takes precedence or not. And we have ordering, to order multiple definitions,

as definition can be spread around multiple modules. Now I will show you some real examples. Here is a simple example, where we handle timezone. Since only this module, we define an option with a default value.

As far as I know, there are not much users in America, so maybe we should change the default value. We define the configuration and what we should add to the shell to initialize it.

So we want to add that we export the timezone, which is defined here, this option. And we want to say where to find the timezone information. So only by adding this module,

your shell initialization will depend on the shellubc. So when you use this module, this will install the shellubc on your computer. Now we have the if small add window manager.

So I've truncated some parts, because unfortunately the file is a bit short. This is the same, except that we have some shortcuts here. We define this attribute cfg to a shortcut to use the if small add options.

We enable the configuration and how to start the window manager.

Just by defining the enable flag of if small add, this will install the if small add window manager. So at this time of the presentation, we can reproduce most of the systems that you are used to with Debian and other distributions.

But we can do more than that. What we can do is express things with more abstraction. What you see here is a generic configuration for this laptop.

So if someone else, which is unlikely, has the same laptop as me, I already suggest defining a default value, which is just a shortcut and override with a kernel which supports the SCPI.

So it won't have a problem with the battery. I've already said what are the modules which are required to put this laptop. I've already said the cable module. So you don't have to find out what is defined for this option.

The same for the touchpad and the same for the video card. Also the same for the PCMCIA with a config option, which is quite different than what you can find on the web.

So this small expression shows you that you can have a very useful abstraction compared to just installing packages and configuring Apache, configuring its work, or stuff like that. You can say that you want to have a configuration for your home network

or for your cluster of computers with small differences between them. This gives you the abstraction that you want. You just have to write a module which is a really simple syntax. And define what are the options that you want to define.

And if you need it, you can keep the options that are used by other modules. So with NIST we have package management with isolation,

so we don't depend on other programs. We have atomic upgrades, so we inherit that for NIST source. We have road bytes that we inherit too. We have multi-users, which I haven't presented in this presentation, which allow you to build your system as a normal user.

So you can, as a normal user, need to have a single build. You can also build in a VM to test your configuration in a VM. As a producer you can just set it to boot or to switch it.

We can reproduce it because if you just take the configuration file, you send your configuration file to somebody else. We are able to reproduce the same thing as you.

Because we generate the configuration file and we use a package manager which has explicit dependencies. So there is a link to nixless.org if you want to visit.

Or you must visit it. And if you have questions, I can answer them.

The idea is that you know from the sources, from the build script, and from other stuff is that you can predict what hash you pull out.

So the hash is computed from the sources and you don't have to build it to determine the hash that you pull out. So you know the hash before the build? Exactly.

I met so many people in one presentation.

So let's continue with a small demo. Sorry, it's only easy. Which is a symlink to the nix store.

It's working as is 80. Oh, that's a normal.

Still working.

Yes, we have slash etc and slash links which are the bases and slash link for sh. And in slash etc we have a lot of symlinks. Which are shared?

The contents of the root directory should contain my own configuration object too. Yes, root directory. Yes, you have root, mnt, add-drive-fresh.

And other stuff which comes from my previous systems. And the sources of nix which I store in this directory.

So let's see. So you can see that slash etc is most of the symlinks. Which are, these are static ones for example. Some things that are enabled by the activation script.

And the static directory is just a symlink to something else. Slash etc needs to work on itself. We have a configuration.txt.

We have an old version which unites. And we have some sources where I store my computer configuration. It needs the sources and the list of packages. If we go into the sources, we should have a module directory.

And this is an old version because I'm no longer using this computer. So we separate all modules inside a list of directories.

And we have a lot of modules. So we have modules for kernel and stage one. For the 8 server, for it's model, for the window manager that I'm using. And for this video projector.

So we have a lot of modules for display manager. We have the screen display manager and KDM. So we have a lot of modules and they are all merged to generate the whole computer configuration.

And inside each module you have access to the whole computer configuration. I was curious, what are your future intentions for Nexus? There are some projects about license calculation.

To check that the system is respect licensed. Currently that's only a project. And I'd be involved in some jobs to manually check that you have the right license in your derivation.

By checking all packages from which it depends. So there are some words like that. There are others I think. I'd say that the main research direction is distributed deployment.

So you can have specifications of networks of machines. And you can automatically deploy them to real machines. The machines from them are deployed into the cloud. And it will help medically from a verification of what all those machines are supposed to do. So let me introduce Elko. There are ports also to other platforms.

Cross-platform configuration? Yes. At least we have a port to the SIVA block for this. For the ARM platform.

And MixOS manages U-Boot and those things. And we have all those properties also in the SIVA block. And Mix packages also has some kind of cross-compilation to build this.

To build an exhaust system on these packages for another platform. Can you introduce the Mix package version on a regular issue system? Even on the SIVA version?

Let's take the case of when a hacker would break into a MixOS system. And modify some installed application files. Is there some kind of built-in safeguards for detecting corruption of files?

Yes. First, there is one thing. Which is that all path in the MixOS are read-only. So this is for data, of course.

But there is a command to verify that the contents of the program hasn't changed. But just like RPM, this is a command to check that this stuff hasn't changed. So, first, yes. All package are read-only.

So you can have a user which is modifying this stuff. And normally this will be a root. There is one incident where the root is that the upload has failed. Because there is no slash lift. So normally the alpha executable works.

There is no slash lift on the mix as well. So that's an unplanned advantage. Yes. Couldn't this type of fix start in the build? Which one? This external fix?

Yes. You have a list of profiles which is incremented. Each time you install a new package.

Tool generation. So the last one is my current generation. The two previous generations are coming from modification. For example, I either install or uninstall something.

So you have generation. I don't have much. Yeah, I can reinstall it. You can go back to previous profile. Yes. Could you...

Oh. Yes. You can check out the repository to show.

This is the name of this file. As you can see, I just include the computer generic configuration.

So you just have to use the same to use the configuration for PCMCU. This is the action scheme.

This is derived from all the inputs. Since we are using the purely functional model to write such hashes. It doesn't matter which machine you have built a component. So if I decide to transfer a particular component to somebody else, I can transfer that component with a hash node.

We even have a dependency mechanism that takes all the dependencies. So when we want to transfer a particular component to all its dependencies, we just have to scan what dependencies are there and then just transfer the missing parts.