 Before we start, we will actually just connect the two bits. Then from Bridgewater will tell us a bit in short about what they do with Nix at their company. As you probably know, they're also Gold Sponsor, and then he will continue to talk about a thing called Nix Code Build. Hello, can people, okay, I can hear myself so I think you can hear me. Okay, so I have not prepared anything about Bridgewater, but I will give you a very brief overview about it, so that maybe you know why we sponsored this place. So that's my name. I don't have any slides about this. Bridgewater is, there's a few different ways of putting it. I think the way we'd like to describe ourselves is a company trying to understand how world economic markets work. It is technically a hedge fund if you want to put it in those terms, but we basically invest money for large pension funds, sovereign wealth funds, institutional investors in general, and do so based on our understanding of world economic markets. So you could think of it as an expert system, trying to learn about how things relate to each other. Where Nix starts to come in is we, first of all, we very heavily value our intellectual property. They're clever trading algorithms and things like that, that you don't want people to steal, you don't want your own employees to steal, you're very paranoid about this stuff because it's worth a lot of money. We see Nix as a potentially, basically almost a game changer in how we can deal with security. There's obviously things like the GR security thing which is great, but we're seeing security in terms of reproducibility, determinism, auditability of these things, which haven't historically been focuses in Nix. I mean, you get some of those things for free, some of them not for free. Things like the reproducible valuations are partly inspired by our desire for this. And so I see Nix as an excellent foundation to build these things upon. And of course, there is just, it's a huge productivity gain for me. And so we see that as having great potential there. I don't want to lie about it. We definitely aren't using it in a very widespread manner yet. It's pretty much just me. And I've deployed a couple of services to dev production in the sense that a large chunk of our developers use them without knowing that they're on NixOS. But if NixOS were to go down, that would cause a lot of productivity issues and things like that. We are not currently deploying any kind of economic analysis stuff on NixOS. But I think the key aspect of it is that I have a lot of buy-in from the company. As in people are CNICs, they don't use it yet, but they're excited by it. And so within the company, I have a lot of leeway to start spreading it more widely, to get other colleagues involved in it, and to do work on Nix packages and things like that, where it serves our needs. And so things like that, the EC2 instance metadata configuration from metadata, which nobody has heard of because I did not document it, but when you boot up an instance in AWS, you can configure it from metadata. And that was partially inspired by our needs at work. And so that's pretty much Bridgewater's relationship to Nix. I hope that we will expand our usage of it and keep supporting the community in far better ways than a logo down there. But yeah, so that's it. I don't know, is this a question and answers type thing? I don't think they're... Okay, that's a pitch. Okay, it's fine. I think that's a pitch. Great. Okay. Okay. Thank you. And then what I actually came up here for. Initially, Aaron inspired me, so I tweeted about it. Yes, and so this control tab, or in my case command shift things, lets me move through my slides. And so I'm going to talk about... Let's see. Nix code build. So I generally characterize it as the most obscene abuse of Nix you'll see in a while. And I hope you will agree with me after seeing this. So who here has looked at all the Darwin work that's been happening recently? Has anyone? Yeah, so a few of you have. I was one of the main people behind it. And as part of that, that's a whole different topic of conversation. But as part of that, there are some annoying things which I had to do. Apple releases a lot of source code on its open source.apple.com, but they don't really put much effort into making it actually compile for anyone. And if we would like a nice pure Darwin standard M, we need to compile it ourselves. And a lot of these things don't work from the Linux world. For example, Proc PS, we don't have Proc on Mac OS. And so Proc PS just doesn't work. And so we need our own PS. How do we get our own PS? We go to Apple's source code releases, this thing. And you'll see a nice PS in there, and it's the Apple flavored PS. And so we need to compile that. Unfortunately, you'll see up at the top here is adcommands.xcodeproj. And we really don't want to bring an Xcode for this. Xcode is a monolithic several gig download. It's a pain in the ass. It isn't scriptable. And it's closed source and doesn't really feel like the Nix philosophy of compiling everything and caching it and all that. And so we really don't want to be doing that. So what I do instead of in the current Nix packages tree is, this is the context here, what I do instead is this, which is really not very nice, right? I don't even bother writing a make file. I call CC a bunch of times, not GCC because we don't have GCC. It's just CC. Please, everyone stop writing GCC all over the place because it doesn't work with Clang. But yes, this compiles PS from macOS and gives us basically a very basic PS expression. Of course, if it's a more involved project, that's a pain in the ass to write out all these things because sometimes they call code generators and all these other things. And so what I've wanted for a while is an Xcode, open source Xcode replacement or Xcode build replacement. Xcode build is the command line version of Xcode and only comes with Xcode and furthermore is not open source. And so I can't build that from source. And so what actually, well, a lot of people use Xcode here. Okay, that's not a lot of people, but Xcode comes with these PBX prod files, which most people have never actually seen the contents of. It turns out macOS's heritage from Next Step is there are macOS P list files, property list files, and they come from Next Step way back in the day. There are several different formats for these, including this obsolete format, which Apple doesn't support anymore except inside Xcode. And that is the format of this thing, this Xcode build project. And so if I want to build Xcode projects myself, I need to understand this format. Now by an amazing luck and why this is turning into a huge hack, do you notice anything strange about this file? This is an ancient Next Step format. What I'm getting at is that it is very similar to Nix. Nix syntax. And so very similar, not quite exactly similar, but similar enough that I can run some obscene set over it and make it into Nix. And so what I did was that. And so this is the Nix version of that. And so this is the build file for building that PS project and everything else with it. Nixified, I put a few quotes around things and stuff like that. That might not be strictly necessary and it might make things neater later. But let's just pretend this is the right way to do it. You'll see I stuck globals made of the function because they have some incorporates. They bring in state from somewhere else and things like that. But otherwise the format is identical. It's a very large file. You'll notice some annoying things about it is that the actual, like once you get over the syntax of the thing, you actually still have the semantics of how to interpret it. That isn't documented anywhere, but with a little bit of tinkering, I figured out how to interpret it. And I have about a screen full of Nix code that I'll show you in a second to do that, which is maybe it's more than a screen full. Maybe it's three screen fools or so. This is a code that can compile PS from that thing. And it's written in Nix and all it does is input add commands dot Nix, which is the translation of the other thing. And now I have a Nix object, which I can treat in Nixie ways. So there's a lot of things I could talk about here. I want to talk about a couple of neat little tricks. Let me just take this out of order a little bit. You'll see if you look back at this Nix file, this is actually, there's this randomly generated identifier or semi-randomly generated identifier by Xcode. And it's actually defining a horrible, horrible graph. And so you have the keys at the top level here, and then they get referred to further down here. And I believe Peter Simons or various other people have given us a technique for dealing with this in a very clean way. Does anyone know what I'm talking about? Okay, well, it is, it's a lazily, and the way I handle this, or I handled this when I wrote it, is lazily expanded giant map. And so that way I don't actually have to ever deal with those identifiers mostly. I can, I basically recurse over the entire structure. And whenever I see one of those things, I say, do I already have it? In which case replace it with this definition. And so it's a fixed point of a big dict. Or attrasset, sorry. And so that's how that part works, and then I just need to process it. And processing it involves this cute little pattern, which I haven't seen used elsewhere. I really wanted switch statements in Nix. So I made another attrasset and treated it as a switch statement, as in the keys are the cases, and the values are the behavior that I want to happen. And so, and then I just do cases.switch over that thing. I use that all over the place in this file, because if I have a C file, I need to compile it with C, and if I have a Lux file, I need to compile it in another way. And so the rest of it is just sort of boilerplate tying it all together, but those are the essence, that's the essence of Nix code build. And any questions? We have time for two questions. Will it source code dot C, dot C evaluate to an attribute that has source code and then dot C and then dot C in it? Three levels, or will it be one identifier? Source code dot C, and this is a construct inside the Xcode build file. In Nix, will it evaluate... It creates a derivation for every single C file, and creates an O file for that. But the name of the attribute, will it be source code, and then it will be an attribute in it, dot C, or is it the name of the attribute, is it source code dot C dot C? I'm not sure, I understand. That's literally something that Apple... Okay, yes, sorry. How did you test that this all worked? I called Nix build and got PS out of it. So how many of these Apple packages does this work for? Did you try to order Xcode? This was me being bored one evening. You can see literally in the Nix code build, I hard-code add commands. So I've tried it on add commands and nothing else. If I were feeling motivated to work on more Darwin stuff, I would probably expand this and make it work for more things. But it leads, like many of these Nix-based make files, it leads into questions about what recursive Nix is and how that, like if I were to actually use it in derivations inside Nix packages, I would need to be able to build something using Nix inside of Nix, and that's something which is a little iffy right now. So it was more of a, let's see if I can actually do this more than a useful tool. If someone else wants to take it, I can remove this secret thing on the just thing. Or I could just publish it anyway, it's fine. I was ashamed of it for a while. Okay, thank you. Johan Schultz? Yes, so this will be a talk about Nix as user environments. And please, Matej, prepare. You're next. Oh yeah, okay, I need the same resolution basically. Actually, while we wait for, I need to create a quick poll. I was asked actually three times to ask everybody who in the crowd is actually using NixOS? Okay, so those three who asked me, I have an answer. And another question is, so what are you guys doing tomorrow and after tomorrow? As you know, we have sprint for two days from 10 until eight in the evening at road code office. It's, let's say, on the other side of the thing that sticks in the middle of Berlin. How it's called? Burlinto? Ferencer, that's the thing. So it's basically few stations away from here with U-Bahn. So road coding is also sponsoring the snacks during the day. So it would be nice to know how many of you will come tomorrow. Let me just have a, keep the hands up. And on Tuesday? Okay, very close. So I'll just, I have the overlay. Okay. How we're doing? No? Can we? Okay. Somebody knows the joke. And only one, and it's actually German joke, but everybody will get it and everybody knows it, I think. When a boss comes to ask you, right, what do you do? Well, most of the hero of us will say, nicks. Right. Oh, on Monday or whenever you're back, use it. If somebody has successfully connected this notebook to the projector, can you share the, because he's the next one. Okay. We'll just continue. Can you, yeah, can you try? Okay. This will work. Okay. Can we get the mic out? HDMI out. Reboot always works. Okay. So we're back with a talk about, from Arseniy, from about nicks packages in nicks build. Wait a second. Okay. Do you hear me? Yeah, nice. So hello. I'm too nervous. My name is Arseniy Siroka, maybe mostly, you know, me by my nickname Jagga Jagga. You can find me at GitHub and RC and in Twitter, my name is T-00 and the guy who likes to merge. So I'm going to talk about two, not topics, questions exactly. And the first one is about nicks build. You know the nicks build too. You can build exactly every project that has a default nicks, which works in it. You can just type nicks build and works and you'll get the result. That fucks. And why it's cool? Because you don't need to know any other building tools like Cable, Make, whatever. You just type nicks build and get the result. We already have some transformers from those configuration files to our nicks files. That's why nowadays it's easy to transfer your project to nicks. And also we have nicks shell, which is more powerful than such things as Cable sandbox, which sometimes do the same thing. But so that's a demo. We have a simple Haskell project where we have nicks files. For example, I'm a person who don't know how to use Cable. I just type nicks build, get the result and having my add effects. But what's the problem? If we do any changes to our project, even if we add files that our project doesn't need, nicks build will build our project from scratch. And that's pretty, sorry for my English. And that's sad because if you have big project, we will waste our time just waiting while it will finish to compile. So in our company, we try to solve this problem exactly we started just a week ago. But we want to solve this problem and what do we want to see in the result? We work with Haskell, so now we are going to solve this problem just for this language. We want to make build, make derivation more granularly. And if we succeed in this work, we would like to make this solution for every language to forget this language-specific tools just to use nicks build. Well, we have several approaches now how to solve this. The problem, for example, we want to create in the result directory, nicks build provides result directory in your project. We would like to add a directory called artifacts and some flag to nicks build like minus, minus, double to use your source codes and to use those artifacts. Indeed, that's not so pure solution because sometimes we can have problems with this. But a global pure solution is, we haven't been discussing this. But I think that we can think about monads because they can handle such things. Because indeed, if we produce the result, even if there are artifacts and no final result, that's some kind of state. And the next nicks build will get the previous state and generate new one. So that's everything I wanted to say about nicks build. So all your suggestions about how we can make it are welcome. Next thing I want to say probably that was discussed in conference about nicks packages. As I said, I like to participate in nicks packages repository life. And nowadays we have more than 70,000 commits. We have more than 800 forks, lots of clones. And this year I saw in GitHub statistics, we have lots of views and the most significant part, we have lots of unique visitors. But what's the sad part? We have lots of unclosed pull requests and lots of unclosed issues. And lots of that issues are, they are not related to the real life. So lots of them are solved already, but they are opened in GitHub. So that I think I want to say that our next packages repository is really friendly to contributors. We have, we already have guides how to write packages. We have contributing guide for GitHub, for Git users, how we would like to see your commit names, et cetera. And the most significant part for a new contributor that we have lots of examples in our package repository. And beginner can, I think, can start easily to create wrappers for packages to make sauce. And I wanted to say just two things. First of all, I think that we need to follow the rules that we've created. And the other thing that I want to ask Nixos community to go through pull requests and issues and take a look at them and close those that are no longer relevant. That's all. Yeah, questions? Yeah, there is no time. Okay. Just one question. One question and then we go on. All right. So I have one remark and then a proposal. So for the next packages pull request, we had like an open session about that. And I'll post notes to the mailing list. But the core, you know, the main thing that we kind of figured out is when we have sprint at least once a year, we should, you know, dedicate, you know, like an hour of that for everyone to review their pull requests. And they will get assigned to attend other pull requests. So if we have like 20 people at the sprint, that's 200 pull requests that will get traction. So for those who don't come to the sprint tomorrow, if you can spend a little bit of time now that you have all the excitement about Nix and review some, you know, at least your pull requests and a few others, that's going to help because we don't really want that to grow. And if you think that they automatically close, they don't. And we really have to, we really need more eyes on them. And for your, you know, question of how do you kind of use the temporary folder, I think by just being able to tell Nix to use the temporary folder that it produced before that would help a lot in terms of for the Haskell. So that would be a quick solution to have a flag saying, you know, use the, you know, first you would build it with minus K and then it would have a flag to say that it can reuse it. Yeah, it saves the results and start. That's all. Thank you. This is the thing I'm working on. I'm a taste of man. Well, this, okay, I'll just start as I prepared. For those who don't know, this is my little project. It started as like with elastic search loopback and polymer monstrosity. Since then, it lost some weight. It now uses just Node WebKit and Polymer. Well, if somebody has been watching this project, it might seem as if it would be dead. Sorry, I'm nervous. And no, it's, well, it's not yet dead, no. I have been quite busy for the past six months. Therefore, I was slowly working on it on a stable branch, which is a mess right now. But I plan to do more things at this print. Well, okay, the progress. I'm rewriting the code to be more structured as part of upgrading Polymer to version 1.0, which before it wasn't very good. Okay, it is about 90% done. So this is, I'm finishing it right now. And the usability of this program, actually, this is a Nix UI, if I didn't say that already. The Nix front end, actually. At least I wish to be. Okay, it can be useful for Nix as a graphical ISO image. For users to quickly discover the packages, configuration options, and stuff like that. And to install something real fast. And actually, it can be useful also for development tool, as you can see the changes in the Nix OS modules. This one, configuration options. I'll show them after I finish here. And actually, there comes only the one point here. Plans for the sprint. I will finish the rewrite. If somebody wants to join me, just poke me. Okay, then the next line would be to merge on stable branch to master and make a release. Right now, just met me. So other way around. Okay, the first thing here, I mean, this one was experimental. I don't see it as really to be in the release. Okay, let's see this one. My default profile. This is it. So these are all the packages. Well, not all because this would be much larger. Actually, this is just truncated. The search works like that. Do you have all the... Well, let's see. That's one. It's all the Nix can give me for this. It's got all the data that probably you need even for development. So you can poke if someone... The maintainers, if this program is not... If it has a debug or something. Then, okay, then we can go back. Configuration options. Actually, this UI just read only for now. It doesn't give any... It cannot install it. Although I have the function, so right in the code, but I have to just bind them inside somewhere and make a smart button. Okay, this is the configuration with Nicholas. He told me one trick. So I reuse some old code and use hit strict and it works. I mean about the values can read. This can read the values from the configuration.nix. And we can show them. These are... Those two are set, actually. It says their example default value and stuff like that. Well, you can see all the... Like that and that. Okay, I missed somewhere. Okay, no matter. No, not that. Okay, then this is almost over. The planet, it's... Well, the planet. It's... Let's see this one. It works like that. And nothing special, but... Let's see some... Okay, this one has some code in it, like that. It might be useful for... Because the first time I used the... I didn't actually know for the NixOS planet. It was Garbus told me someday. But it's not... It was not, I don't know how to say... Known to... Known to... Well known. So I'm just thought back. And maybe I can do that too. That's actually it. We have time for one question. And Johan, please prepare meanwhile. Oh, just make me. Hello. No. I was just sniffing a little bit into the code base. And was surprised to see quite a lot of pearl code, in fact. And I wonder if there is any idea of translating that maybe into Python. Just as an idea. Well, pearl is kind of more dead than some other stuff. Okay, I'll just answer it. Because you're talking about Nix. Yeah, okay. The answer is there is a ticket already open. It's going to be rewritten into C++. And it's just a matter of time. So all code of Nix is going to be C++. One day. There is even a bounty. 100 euros is already there. 100 dollars. 100 dollars, yes. So one day it will happen. Just while we wait, those of you who haven't know, we have a planet which is a collection of blog posts. Which you can send us your RSS from your blog. It's on planet.nix.org. To actually get to it, I would actually have to show how to send. You have to open a pull request. Or just ping somebody on RSC. And they will add your RSS feed. And everybody will be notified about your blog posts. Yes, we are ready? Okay. Your name? Jochen Schulz. Jochen Schulz, okay. Your name disappeared. We will talk about Nix as a user environment. Okay, sorry for the problems. I was the only laptop here. And this conference doesn't work. Okay. So basically, I'm Jochen Schulz. I'm a scientific staffer on the Institute for American Applied Mathematics of the University of Coating. So, the administrator for the Institute, and we are doing several stuff using the moment, the DBN-based system here, with a little quick analysis on computer servers. So we are calculating stuff. There are some over 400 client computers which are configured through Puppet at the moment. So, I have the RIN servers and several file systems there. And some virtual machines. And so, this is basically the setup at the moment that runs with DBN. And I started using NixOS so, actually, one year ago. And already using it at home totally. And the idea was, okay, let's switch the whole Institute to NixOS. Okay. This is the task. And, okay, one thing which is important here is that the lowest thing is many client computers can and will be disconnected because they are laptops. So, when we figure laptops, when we put them out of the network, we can put in the network and so on. So, first of all, a little bit about what the management at the moment has had. We use Puppet. But we want to get rid of this NixOS, okay? So, at the moment, Puppet does something like host group. So, there's a host group which is a laptop which has a specific configuration. There's a VM which has a specific another configuration and so on. Okay, we want to use NixOS. It has rolling releases. So, one of the things is in the setup, like we have, okay, every two years, we upgrade the system. Well, something like this. So, but with NixOS, because of the rollback possibilities, we could use, yeah, more or less every time I want. Yeah. Okay, and also one of the main things from the scientific viewpoint is it's easier to use, we produce with numerous calculations. So, we can really have some NixChile. So, this is what is the dependency. This is how to run and we can run it later in the same way. Okay, because of this kind of laptop stuff, we can't use NixOS really because NixOS is central and deploys it on the computer which is there and prepared. We can't do this. So, this was the main problem there and then the general idea we come up with was to, okay, let's make a channel where all the configuration for all the hosts is in. So, this is mainly the Nix package fork, of course, and the main idea is to have additional modules which play the role of host groups. So, there are laptops, they have a specific set of modules, a specific set of options and, yeah, okay, so this is the basic idea. A high drive will build all the packages and all the specific packages and all the channels. This is what we already have, really, but we are only in the beginning and then, in the end, we want to use the X-ray and reboot, apparently on the clients to get updates to the channel and get all the configuration we changed on the server somehow, so on the channel. So, the basic idea there in this setup is that we have some central module. It's called non-default Nix which serves as an entry point for all the modules. So, here we have num.hostID which the idea is the client has some hostID which is defined in its Nix or its configuration file and then I can switch in my channel which configuration it gets. We call it here profile, so we have some set of modules which is like, okay, this is a laptop with whatever settings. And he gets it because its name of the computer or its hostID is whatever, client52, something like this. So, this is basically this mapping from hostID to a list of modules which I will reply to the computer. One problem there is that we want to have, because there are laptops that can go around versus in the world, because we have our own channel, the computer has to be accessed to this channel, but of course we have passwords, there are credentials in it, there are private keys, whatever. So, we come up with some, okay, we have some we need to encrypt them. Okay. So, we thought about it, we simply used gtb to encryption and when I set up the computer, I will create this key pair and then can have a private key on the computer and the public key is uploaded to the server which then can decrypt the credentials with the channel update. Okay, basically. Okay. So, this is the installation which is also said to do, it doesn't have done it yet. So, we need to have some provisioning for the client which as I said before, I can't work with Nixops because there are some laptops somewhere and I have to switch it on, I have to do something and at the moment we are doing it with PEC boot. So, we want to do the Nixops so we have to do a simple bootstrap of Nixops, for example, Nixops install, then have this key, basic configuration where I put the host ID in it so then the computer is set up then you can have the configuration since, of course, created with Nixops install in the beginning and then I must channel update and he gets all the information from the server how he has to be configured. So, this is the idea. The user site here is because, okay, we have all users which then have these Nixops configure laptops so they have to to work with us, basically. So, one of the nice things, of course, is they need some development environments because they are also coding stuff, numerical calculations. So, one of the things, of course, is Nixops we also come up with some idea of user profiles, have some defined set of a profile and then they can easily switch between different environments. This is, of course, standard Nixops stuff. One of the things which is a little bit more interesting here is okay, not every user should have the ability to write its own Nixops expressions. We can't expect that from everyone. They are not the basic users but we can't expect to write Nixops expression from them. So, one of the idea was to have some, in an interface script which writes in the mix expressions. So, okay, I have a package I want to add to the Python environment or the GHD environment and then I want to call something like Nix and this package to EXE or whatever. And this writes the derivation and puts it in the config and then it gets to the user and then the user can use it. Okay, here's a question in the how to upgrade. The user profile is not usually upgraded. He has to do it. The user has to do it. There are other questions here. We at the moment don't know how to do it really. There are other questions. There's one of the main things here in the talk is we are in the Bing engine. We want to know if this setup make any sense and have some discussion about this. Yeah, okay, no time I think. Yeah, I mean, we're more or less finished in the last slide anyway. And also was do I put the configuration we have more lots of configuration. Do I put them into the global configuration etc or part of the packages that have different constant pros. User convenience I also talked about in the slide before. It's a little bit interesting thing about. We don't know how to handle this. Yeah, dashboard we have at the moment Puppet and Forman which gives us kind of interesting dashboard for managing all of our clients which we are not with NixOS at the moment. Okay, so we have to do all the work really. So we have to do all the packages and create these NixOS packages to reflect our system at the moment. So this is really okay, thank you. Thank you. Okay, we have time for one, two question if there's any or So our users, it wasn't clear, but our people is part of this already implemented? So are there actual users who have NixOS on their machines? No, we have at the moment a Debian system which uses the Nix package manager. So we have somehow just curious about the experience of people who aren't familiar with Nix, but now they have this thing on their machine that they didn't decide to put there. Maybe using Nix package management at the moment. We have Debian systems with Nix. So do you plan to migrate to NixOS and as a part of this question, are there sources somewhere? What? Is there source code of your things? Yeah, there is a little bit of source code, but of course we think of planning this to release at least parts of the stuff, of course. Anyway, in the end it's open with one of the things with the secrets in the end it's open anyway. You can get it from anywhere. No, we may migrate to NixOS but this is not planned how to do it. At some point, at least, I think we simply reinstall the computers. So, yes. Yeah, we can use this. Okay, thank you. Okay. So, next presentation is going to be from Nikolas about NixDemon. Okay. So, as you can see with the title of this presentation, I like trolling. So, this was a presentation that I made a few months ago. I won't make all the presentation but I will go through the big parts of it. And okay, so that's it, you all know about it. What I wanted to talk about is not this part, it's this one. There is one thing which gives me to the Nix Package Manager and NixOS and others and this is I can summarize it at the beginning at this table. So, let's do an exercise with me. We have a short period of time so let's be quick. In one side you have basically a package manager or what it might be and on the other side you have a program. So, what is the file system? What is the file system for a package manager? I mean for a program. A name space. A name space? State. Memory. Okay. What is a path? A pointer? That fits with the memory. What is a package? A module? So, if you have a memory and a pointer and on the file system you have a path. A path points to what? A structure? Yeah, a folder on the file system. So, what's a pointer points to in memory? A structure sounds like a nice one. So, what is a package manager? If you have pointers which are pointing to structures in memory, what is managing these pointers? I got a garbage collector there. Somebody mentioned. What did you say? Memory manager computer. So, we've got a garbage collector and memory manager. So, what is an installation? If you have a structure in memory, what is installing a structure in memory? Writing. Writing. Allocation. OK. Removing? Dialocation. OK. It's not simple. What is no such file or directory? Use after three? Use after three? Thankful? Yeah. That's about it. So, what does NICS mean in this world? NICS is a package manager which is kind of different from the others. If we try to isolate NICS the properties that we have for programs, we realize that, oh, package are immutable. We have a package manager which is a garbage collector. And installing means that you are basically routing the package that you have. A route is basically from where the garbage collector starts to see what is installed. And removing means that you lose a reference, that you have no longer any route to your package. And, of course, no such file or directory is a safe vault, which is one of the best analogies. So, if we continue with society, OK, we have a package manager which is a garbage collector. What are the properties of garbage collectors? So, we have two properties which are like conservative, which is like basically saying I will be safe with memory and I will scan everything and say, oh, if there is something which looks like a pointer, I will consider it as a valid pointer. And that's a property that we have with NICS package manager, which is like, OK, if there is something which looks like a path, I will consider it as a valid path into the NICS store and consider it as still alive. And another property that we have with garbage collector is being independent of the language. That's why this talk is about the NICS demon and not the NICS language. The NICS demon works with a protocol and basically as soon as you are able to talk to this protocol, whether it's in NICS with the NICS language or maybe in Python or in Scheme, somebody made it, then you got a new language on top of a garbage collector and that's what we've got with the NICS demon. And somebody mentioned this presentation a few days ago on IRC and I think it was worth presenting it here because it might not be clear to everybody. So I kind of clarified these ideas and give you another review of NICS in a way that I also like. Thank you. Two questions and then we move. Meanwhile, Thomas, please prepare for... So the one thing I didn't catch is the connection with the NICS demon. For instance, the garbage collection is not a property of the NICS demon, but NICS in general. You can run it without a demon and it works fine. So the NICS demon is independent of the language that you fit it with. But also independent of the store, etc. You can disable the NICS demon and run as root and it all works exactly the same. So those are properties of NICS, not the NICS demon. That's just what I wanted to say. Yeah, but I meant the NICS demon as all this property of the garbage collector and not being tied to a language. Yes. Details. Any other or we go forward? Okay. Thank you. Do you see the same thing on the screen? I think it's on one of the sides. This one? Maybe. Move your cursor to the right. Oh, okay. So how do I move this? So how do I get this screen to the other side? Okay. Try something else. I have no idea how to look at it. I can see it. But I don't see it here anymore. Yeah. Okay. So Thomas will be talking about cross compiling. Cross compilation. Yes. Well, I'm Tomas Lovati and I discovered NICSOS about half a year ago when I was looking for a way to automate as much as possible at work and I wrote for pretty much everything we developed. I wrote NICS expressions, NICS packages so we can now build everything very easily and configured Hydra so that we have everything that we change. We have immediately or immediately, reasonably immediately feedback about what we broke or what still works and this helps us a lot because we need to test against many different configurations for example different versions of Postgres with Oracle with different versions of LibreOffice for example and it's very easy to achieve with NICS but once you write all the expressions that's the hard bit so at the moment I would like to follow the I think Rob had the plan how to achieve success with NICS so find a good company so I think I succeeded in that and now I'm trying to NICSify everything so what remains now is to find out how to deploy stuff so it's a bit tricky for us because I don't have a control over the machines where it runs so some customers somebody has Ubuntu machine, somebody has SUSE, somebody has Windows some machines can be even offline so we don't have any access there so there's the existing solutions that don't seem to fit any of the range we need so that's something I need to think about still I think even containers don't work for example on Ubuntu sorry yes, this maybe that's the solution or maybe something even simpler there were some discussions about creating the module system simplifying and one of the big remaining issues I have is I have everything which runs on Linux automated now so I make a change and I see what works and what doesn't but I don't have this on Windows and I would really have this ability on Windows too and actually the big thing with Windows is that I have to babysit the machines, they have release machines test machines and they always keep asking for activations for some reason I don't know I need to always go to the machine and do something and telephone to Microsoft and so and I think there is a way to do it completely on Linux with Vine and maybe cross compiling using Mingwei that already kind of works so here is a simple expression where I can define that I will be cross compiling with Mingwei for 32 bit Windows applications or 64 bit so I can simply write one line and have next packages which will be compiled for the particular target and it works very well for example hello I can for example I can build a Windows executable and I can see that it's a 32 bit Windows executable I can do the same thing for 62 bit 64 bit and I can see that I have 64 bit Windows executable and I can even I haven't tried the 64 bit but so it works it's world so all the infrastructure is already there in next packages now the problem is that this was a really trivial example so once I start doing something more complicated which we would need for automating all these things to Hydra many things break and ideally somebody loves Knicks and loves Windows and would be interested in fixing lots of stuff make it work on Mingwei then please let me know thank you we have time question or two there won't be any bounty for 100 dollars but it might be a little bit project so my question is what does make building Knicks on Windows natively difficult is it a tool chain or is it Knicks depends the source code depends on specific implementations specific libraries I don't know I think the next packages don't simply needs to be adapted to understand that the compilation under Mingwei needs something else than compilation under Linux for example there are assertions if I install some package and tries to compile a lip icon and there is assertion which says that it shouldn't be on Linux but the target is Linux so the assertion shouldn't fail so I think there are some things that just don't work plus there are things that the Windows targets needs special maybe I don't know I haven't had the time to investigate but there is I think there is a work there that I would like to be done but I don't have any time to do it myself so what do you mean you did not make upstream bugs how can I know what the problem is no I haven't made upstream bugs because I don't understand what the problem really is yet okay but I mean the hello world works so it's just a question of it's really making it more advanced until it doesn't work out so I know that there are many problems but I think many open source projects are not really used commonly on Windows because Windows has a different packaging system so I think many things like icon V are not really natively buildable on Windows usually they would build on a Sikwin probably because Sikwin has patched them and has their own system you know so I think I identified some packages that I'm sure work under Mingwei that is possible to compile them on Mingwei I succeeded once doing that under Ubuntu but I don't have any way of compiling that on Nix easily I would have to really dig into it and find out how to do it so I know for example SBCL which would be interesting for us here there's a package for it in Nix packages I know that it works under Wine and it compiles under Mingwei but it doesn't compile if I just do this simple thing so is that clear I guess there is the chance tomorrow morning I won't be here thank you for potential people who are interested I won't be here next week I'm on holiday so please contact me on this email I will read it when I come back okay thank you okay so we reached the end of the talk the first two days of the conference tomorrow it starts sprinting what I would like to thank is actually the whole crew that helped and please Paulos come up because you did a big job Peter please come Jonas Jon Jon Elina come on you know that you helped right and I'm calling but I'm really low on voice come on we are on camera so this is the team who helped make the first Nix IS conference possible and they executed it and it was all lazy no worries and I'm just happy that this became true and I guess see tomorrow and if not tomorrow I don't know where next year but I think we should meet next year as well right okay so let's talk on IRC where and how the details but thank you and for this evening there is nothing planned I guess we can talk outside how and where to go maybe for drinks but yes tomorrow we will start with sprints 10.30 we're gonna start with the initial presentation so be there at 10 you know the usual half an hour buffer but yeah guys thank you