 Okay, so I have taken it upon myself to introduce the first speaker for the first speaker is probably The one person who doesn't need any introduction, but we'll do it anyway. It's a good also the guy who started it all I think may have been around ten years ago that you wrote your PhD thesis purely functional software management and And I think it is the dream of pretty much every PhD student that ten years after submitting the thesis There's a big conference with lots of attendees Who want to dying to talk about the work So without much further ado, please welcome Ilko Dostoe and his keynote address All right, okay, that sounds like it's working. I can hear myself. So yeah So let me first start with the important thing so welcome everybody and thank you all for coming and We missed a very important. Thank you. Namely to the organizers. So rock palace and Peter So let's give them a big thanks for taking care of the organization and So, yeah, this is really impressive what you did here We already had thank you for the sponsors, so especially since I work for one of these I won't ask for another applause Okay, so in this talk I'm going to do think two things I'm going to talk a bit a little bit about the state of the project and what we've been doing in the last 12 months and Then I'm going to talk about the road map But I'm not good at the visionary stuff so I'll just talk about some things that I think are Important in the future and then I'll open the floor to you guys to Share your ideas on what's important. So I would like to have a sort of interactive thing All right. So what has been going on? Well, we actually have a very nice. You could say almost exponential growth So this is a graph of the The committers to the next packages repository So as you can see the first few years there was not much happening So I was writing my thesis and basically Nick's was a vehicle for writing papers as these things go and then so after 2010 or so things really started To grow so we're now at something like 160 Individual committers per month. So it's quite a Large and growing community. So let's see if we can keep the exponential growth going Actually it's already tapering off a little bit at the end so maybe you should ignore the last bit So this is the number of commits per day. So it's also quite large There was actually a peak last year. I guess that was around the 1412 Release time frame. So I guess lots of people started stressing out and doing commits So, yeah, also quite a nice growth Or perhaps here's a graph that actually the title is a Misnomer. This isn't really the next package of size. It's the Size of the next packages trunk job set on Hydra. So this this is really how stressed our build farm is So the Hydra the next packages job set currently consists of 45,000 jobs. So if you're wondering why Hydra is always having a disc fool This is why So it has been having ups and downs the downs are mostly every time our single Mech OS X build machine broke and we disabled Darwin builds You get a big drop so But this is this is not a very scientific number because there's a lot of double counting and so on but So perhaps more interesting is Yeah Growth in users rather than developers So I don't really have any measures of that because we don't have something like what's called the Debian installation Count or they have this thing where users can sort of register themselves We don't have that but we have the the binary cache, which is I guess reasonable Or as correlated to User growth so this is since 2013 when we had the binary cache so every time Nick's user install something it it comes from cache.niksOS.org So we're now at some almost 100 gigabytes of traffic a day So that has also been growing rather large although Rob claims that this is mostly him downloading stuff from from all his machines Or the number of unique IPs per day so we're now at something like 1600s per day, and I think we had a few hundred thousand unique IPs over the lifetime of the binary cache so yeah, I guess You could conclude from this that there are at least 1600s people a day Hitting the cache so doing nicks or nicksOS operations. So All right, so that's some numbers on our progress. Oh a few more though, so we recently hit our 10,000 PR slash issue on github so And most of them are actually closed. So that's that's I guess a good sign Only about oh, they're only a thousand open. So that's Should probably do something about it, but I guess that's not too bad Alright, so what what has been happening in the in the last 12 months? So I'm so we've had two nicksOS releases I cannot possibly summarize what was in them thousands of new packages services We have a whole new Haskell framework Big improvements to GNOME KDE and so on One thing that I really should give a shout out is Vladimir here This this is so awesome. This is something we've wanted for years and now we finally have it I Had to mention this because these slides are made with latech using a nicks expression So this is the nicks expression that builds these slides. It used to be that so I always stubbornly kept using tatech because It's a small only 200 megabyte package or so and not Tech live, which is this two or three gigabyte monstrosity, which you can't really use because if you want to Build your slides, you would have to first download three gigabytes of crap Which is bad if you're in a hotel with a really bad internet connection But now we have this really nice minimal thing. So you only have to download The stuff that you need so I think this is really nice because it's it's just an example of how nicks can sort of Infiltrate other domains because we now really have a better tech life than tech life. So All right, I just wanted to give a shout out to that So what has been happening in nicks we have had three releases Lots of new features a few that stand out So we have signed binary cash support is important for security. So for instance, this allows us to Serve cash.niksOS.org or mirror it and You don't have to trust the mirror. You only have to have the appropriate public key of cash.niksOS.org and this allows other people to set up caches and as long as you Have the right public keys in your installation. It all works fine Automatic downloading of nicks expressions. I'll come back to that but this basically is I think going to make nicks channel obsolete so here you can now just say nicks nf-f and then the URL to a terrible containing nicks expressions And install packages from there and you can also put something like that in the nicks path environment variable So for instance, I use this on nicksOS machines in order not to have to Run nicks channel on those machines. You just set the nicks path environment to point to a terrible like the 1509 current release And and and then nicks nf just does the right thing And a really big thing that has been happening is Well the Mac OSX support in general so in nicks we have had sandbox support But more importantly in nicks packages we've had major improvements to the packaging in particular. We now have a pure Standard environment or almost pure so it doesn't depend on stuff outside of nicks packages apart from the C library I guess and a few other things So I think you no longer need to have X codes installed to To bootstrap or to build things So this is another great thing. So had there a few of course still a few kinks, but Once this works, I think really nicks and nicks packages has the potential of being better than homebrew for developers and Mac OSX want To to set up their environment. So have another step to a world domination Yeah, so hide this I've been doing some work myself on on hydra. So hydra is really a big bottleneck to the project because Well nicks packages is really big nicks OS is big So yeah, we had those 45 packages in the nicks packages job set And then multiplied by all the branches we have like the staging branch and the various release branches feature branches So Basically hydra can't really keep up and it has also various software problems So these are being addressed. So part of it is already there. So we have a new hydra Q runner that schedules builds much more efficiently So it used to be the case that hydra was really kind of stupid So it had a queue of builds and then it would read sort of randomly select some builds and basically run a nicks build on each of them But that meant that if all these builds depended on the same derivation like rebuilding GCC That the whole build farm would be doing only one thing namely rebuilding GCC So you'd have all those machines except one being idle. So that was really a bad utilization And now we have a much smarter Q runner that just looks at the entire queue at the entire Dependency graph of all the builds in the queues and if there's any build steps that can run it will run them. So That's a lot better Another thing is a hyra provisioner so we can now dynamically scale the build farm up and down So we can start easy to spot instances to do build So for instance if there are 10,000 Linux builds in the queue then it will fire up a dozen spot instances To sort of quickly burn through the queue Now the only sad thing about this is that we can't do this for Darwin Because right now we have one Mac mini doing all the Darwin builds so Yeah, we need to do something about that and There are some more improvements on the way, but I think I have another slide about that later on All right, so another thing that has been happening is that we have a Nick's was foundation now Which is a nonprofit organization? I think the official description in the founding document was to support a purely functional deployment model blah blah blah So yeah, so this was really intended as a vehicle to be able to handle donation So for years people have been asking well Hydra is so slow. Can I donate some money or some hardware? and we didn't really have a infrastructure to to to deal with that so now we have a foundation and more importantly with a bank account and a PayPal account so And and a legal identity so yeah, so we can handle donations and we can Use that in the future to for instance buy Hatshner hardware and to pay Amazon costs and to pay for conferences So yeah, that's that's very good. So maybe at some point in the future the foundation could also do other things like Handle copyright assignments, but I always get very bored thinking about that sort of thing so Alright, so that was the past now the future the roadmap So I should say that roadmaps are fiction So in my PhD thesis there is actually a future work section Which is what academics do when they write a paper there is the obligatory future work section which describes all the things that you're actually not going to do but You want to show the reviewers how clever you are and that you thought about these things and you sort of claim them in case somebody else decides to do them But number one on that list is For the future work is a fully Nixified system a pure Nix based Linux system tentatively called NixOS so that one actually happened That's very good. I actually went through the others on the list and This was really the only one that happened So it's still some work to do actually some of these things. I've totally forgotten what they are feature selection automatic instantiation no ID oh This one was lies a language for builders So there was something in there about how bash is a horrible programming language and we need something better So weeks has that just just need to give a shout out to them The intentional model I'll get back to that but all the other stuff type system and so on Don't see that happening anytime soon But who knows Maybe maybe somebody wants to do a PhD on that and All right, so here are just a few things that I think are interesting for Nix and That I'm interested in working on so this is by no means a definitive list. So this is why I'm interested in now Have what you all have to say So a new command line interface Distributed or peer-to-peer binary caches and content address Nix store, which is a nicer name for the intentional model and So this is 3.0 so at the current rate our versions are going. This is probably in 2030 or so but All right, so this this is actually this is something that I think we should be able to do in in the near future So a new command line interface So the current one is pretty crafty with all these separate commands and a lot of them have names that don't make sense Like Nix instantiate nobody understands what that means. So what does instantiate and why should you care? and It's unclear why some things are commands and other operations in command So for instance, there's Nix collect garbage, but there's also Nix stored dash dash GC and they do sort of the same thing but not quite and Yeah, so there are a lot of Suboptimal design choices like Nix and Uses package names which is slow So if you say Nix and dash I Firefox it has to evaluate basically all of Nix packages To figure out which one of those packages is Firefox So this is why most people will say Nix and dash I a capital letter Firefox So then it will only look at the Firefox attribute. So it will Only evaluate the thing that is necessary another issue which is kind of in the Interaction between Nix and Nix packages is that Nix packages Well, so a lot of packages have options and there are also a bunch of global options, but they have absolutely no discoverability unlike say the Nix or as module system where Options are automatically show up in the manual so you can find out about them But all these Nix packages configurability is You have to know that you can pass a particular option or do an override or whatever so So we have a system a purely functional system with with functions that you can pass arguments, but Yeah, if users don't know how you can pass an argument or that these arguments exist It's not very useful. So And Nix and only does imperative package management. So Nix and factions are things like install upgrades but So this is in contrast to the Nix OS style of upgrading where you have a declarative specification I want a system with these packages taken from the most recent or Version of Nix packages and then when you do an upgrade everything gets rebuilt So so clearly the Nix and style also has advantages. So for instance, I don't want all of open office to be redownloaded everything every time I install some package but Yeah, clearly there's also a value in having the declarative style so the solution is to replace it by a single git style command so a Command called Nix With lots of sub commands like Nix install Nix you see Nick shell etc So this would presumably be based on attribute names by default So you could say Nix install X org dot X message or a python packages dot whatever and So it would be fast And presumably it would also remember Those attribute names and so then later where you do an upgrade that you use the attribute name to do the upgrade But the semantics here are not entirely clear yet. I mean if you ever if for instance if you installed Firefox unstable doesn't actually exist, but imagine we had something like that It's unclear whether doing Nix upgrade should Upgrade to the latest firefox unstable or to the latest firefox and what happens if the firefox unstable gets removed So so there are some issues to figure out there Another thing that lots of people have Demanded over the years is caching of searches. So Nix dash Q a Nix and dash Q a is Pretty slow If you're not on an SSD drive, it is also the rate reason why I say maybe I've never really been a favor of implementing caching because What's the saying had there two hard problems in computing? naming and cache coherence so Yeah Sorry Yeah, yeah So Yeah, making sure especially given that you can pass options To Nix packages that might influence the result of the evaluation that makes the caching kind of tricky to do So really my advice would be to get an SSD drive, which is always good advice, but especially for Nix So maybe also support a declarative style have we would have a Nix rebuild command that basically Works analogously to Nix or is rebuilt and maybe deprecate Channels or more precise the Nix channel command because We don't really need it anymore now that you have you could say a Nix path is Nix packages is And then the URL of the channel you want to track Because if you do this Nix and full automatically download the latest version of the channel So you don't need to run Nix channel dash update anymore Well, so there are lots of other things that can be fixed here So I think there is an issue somewhere where people are throwing around IDs for for this So, yeah, we just need to come up with with something nice Yeah, so the next packages discoverability Yeah, that's that's a tricky problem. So we need some sort of new package formalism then what we Something better than what we currently have. So the style where a package is a function Where we mix both the dependencies and sort of the feature arguments like enable pulse audio So Nix and fest no idea to see that some of these things are Options that you might want to show to the user and others are just dependencies that are Generally not interesting to show. So maybe we need something a function like make package that separates the dependencies from the sort of the option Sort of the user visible options something like that. So I've I don't really have an idea how to do that But I think we do need something like that in Ah, yeah, so the distributed binary cache or the peer-to-peer cache. So this would be this is also something that people have wanted for a long time so Maybe this would even allow us to get rid of having a big hydra build farm and so basically people could just build stuff upload it somewhere and maybe even publish it via IPFS and then If enough people have built a certain package and it had the same build results, then you can trust it So obviously this is risky. What do you do if there are sufficiently number of bad people who are publishing Trojans so This is really something of a research issue But yeah, the idea would be that you would only download a binary if from from a binary cache If a specific binary has at least n signatures something like that So this does require Greater build determinism than we have currently so Nick's has always been about reproducibility of builds but not about bitwise exact reproducibility So for instance things like timestamps do end up in builds and that breaks this whole thing because If different people are building a package and the end of a slightly different binaries Had then also put different signatures on that So you'll never reach the required number of signatures So that's why we want Exact reproducibility, which is a hot topic at the moment. So for instance, I think Debian got a few hundred thousand dollars from the Linux Foundation to work on improving built determinism so Hopefully Things will come out of that that we can use as well So another thing is The content to dress Nick store also known as the intentional model. So that's Really the only way the only reason you need to care about is that it allows any user to install packages From any binary cache without having to be rude. So right now Had With nicks with the nicks demon users can install packages from source Or they can install binaries as long as That binary cache is trusted by By route so you you cannot just point at an arbitrary binary cache and pull binaries from there and the reason is that I Knicks has to trust that a particular Output corresponds to a particular derivation. So if I type Nick's n-5 firefox It has to trust that a particular binary in the cache is actually the result of building firefox and not the result of building firefox and inserting a trojan horse in there so Or just replacing it with a script that Formats your hard drive so So if you add a content address Nick store then Basically you You don't need that kind of trust anymore any user can do anything. So that would be very nice Alright, so that was for Nick. So how about Nick's OS? Well a few things As so there are the standard things like system D updates which has been Languishing for a while, but finally we have system D 227 About to hit master There are other things we should do like GCC 5 But the main thing that I think is very important is closure size reduction It's kind of a strategic goal. I think Because right now Nick's OS is kind of fat. So for instance the configuration the system closure of my laptop is something like three gigabytes now I Don't really care about that because My laptop has plenty of disk space and it has generally a fast internet connection But for things like containers and cloud deployments you really want The closure to be as small as possible because for instance if we use nixops to deploy a gazillion EC2 instances We have to upload or at least part of the the system closure to each of those machines So the smaller the closure is the better Now the reason why Nick's OS is rather big is that Unlike other distributions our packages are generally not split into Sub packages like well had the binaries The headers the static library stuff like that So nix has a feature for that called multiple outputs. So there you can have a derivation With multiple that produces multiple store paths and then for instance you can put the documentation which And nobody cares about because you just Google it into a separate output And had or seen a separate outputs has so So that they don't end up in the in the system closure Now actually this has been going on for a long time. So already something like three years ago I had a Basic prototype for that that have reduced closures a lot. So things like What was it the pan news reader? We had closure reduction from 400 megabytes to 100 megabytes or so or so it was really a lot But it never made it into into master. So Vladimir has been working a lot on this. So hopefully We can get some of this soon should probably stop doing these things in separate branches because that tends to Diverge a lot and especially so it would probably be better to to do These things in in small steps And and quickly merge them into master But this is always a hard problem how to how to handle these kinds of branches Yeah, so some hydra improvements that we really need so right now so yeah, like I said, we really have a Bottleneck because we have a central hydra machine which has something like three terabytes of disk space Which run on the verge of definitively running out of so this week we had some disc fool and I couldn't figure out how to clear up some disk space so it was deleting some old job sets, but And it's also really slow so this machine so so everything that hydra does so Every package that it builds so it builds them on separate machines, but it all has to go through this central machine So which has a really slow rate something disk So very often the load on this machine goes to something like 100 because you have 100 processors blocked on doing IO So so that's that's terrible So the So the next thing I want to do about the Hydra Q runner is to have builds directly Uploaded to the binary cache so they don't have to be stored on the local Nick store of this central machine So this would also be nice for users directly because you don't have to wait until The contents of this machine gets mirrored into cash.niksOS.org So things would end up in cash.niksOS.org directly so as soon as Hydra is build something your your builds get faster And and of course we have unlimited disk space on EC2 so And the other thing that we really need is more Mac OS X machines and since those are not so easily proficient That's We'll have to figure something out. I mean there is we use some company logic blocks We use some company in Atlanta. I think that provides Mac OS X cloud machines sort of So we should plug some in That's actually my last slide so that was all I had to say so Yeah, I would like to open the floor to Whatever crazy ideas or demands you have So if you think we should do this we should not do this Then please say so So we have 15 to 20 minutes for questions. So go wild It's probably a very bad idea, but for build determinism Why not have an external signature an internal signature? What does that mean though versus? You you change some some Yeah, you have some some file which has a timestamp. We know it doesn't influence the external behavior of your program Right, but how do you know it doesn't influence it? I mean that's always so for instance take something like a timestamp. So so generally it doesn't influence it But Nick's doesn't know anything about well, for instance, you might have an output like a dot a file Which has a timestamp or timestamps embedded in it Nick's doesn't know anything about dot a file. So it doesn't know that those timestamps don't matter. It all it sees is a A lot of bytes And it cannot distinguish between good differences and bad differences Except if he was supported and being declared as such have you ever thought about that? Oh So you would declare in the derivation like these kinds of changes don't matter something like that Yeah, if you had some But it would have to be a pretty powerful way. I mean for instance specifying that Time stamps in a dot a don't matter Yeah, how would you specify that? So what kind of formalism would you have something to declare a certain? patterns in binaries don't matter or so In that that kind of situation it's better to just fix the package so that it generates Deterministic dot a files Right if you can yeah, yeah, well, so some of these things are easy like the dot a files So it turns out that I think nowadays there is an option to make them deterministic. I think we're even using that But then there are things like For instance the GCC profile to build so it when you compile GCC it does a profile run and So the result of that is very timing sensitive. So the GCC you get depends might be influenced very slightly by timings at build time and yeah, there's there's no way you can specify that This binary is equivalent to that binary. Yeah, that's just too hard This is just a kind of idea or suggestion We use Nick's a lot in production right now the company I'm at which is the Allen Institute of Artificial Intelligence in Seattle and One thing we've run into in introducing next to new people we've got a lot of Nick's expressions We use them to manage data sets all sorts of stuff But when new people come the error messages a lot of times that we get from the parser Or the expressions can be very cryptic. I think as far as the ability That's one of the core issues we run into and like when we have new team members We're teaching it to is small little errors, you know in you forget a semicolon somewhere or you don't You know close a string can result in just the absolutely, you know very disconnected error messages So that would just be one thing I think from an optimality perspective We need to improve is just error messages. Yes as simple as that is. Yeah, absolutely Yeah, it's kind of a hard problem So actually what you mentioned so syntax errors in my experience are not too bad because they're kind of localized It will tell you there's a parser at that point the really hard problem is if you have say in an x-rays configuration You have some some well type error basically and you get a giant stacked race and you have no idea Where this comes from and what causes it? And Yeah, and it's also not even clear Whether for instance a giant stack trace is actually helpful because it's just All that garbage vomited over your screen generally just scares people away Yeah, yeah, I think yeah, whenever you have a weird case like that, yeah make a buck Hi Two things first on you needing more macOS and builders Have you considered or maybe this isn't possible with just virtualization like starting some Linux and starting macOS virtualized and building inside That they didn't need hardware then I think I think we sort of thought about it, but Yeah, there's always kind of the legal issue that you're not allowed to virtualize Mac OS X or I Didn't know that So people you can do it, but it's it's not really legal cannot confirm nor deny Right, right, right, right. So then we okay, just second thing on on Previous slide. He said he had the idea of caching the names for search What came up in my mind there is just that you really need a different representation of the data structures like a reverse index to do faster search To find these things caching didn't really make sense to me there I think the cash is just well, it's just a cash. So it stores the list of packages attribute versions descriptions or the metadata To make nicks and or nicks queries faster So if you then do nicks Nicks install or actually if you do nicks search Firefox or something like that it would Be able to very quickly search the metadata But but of course this whole caching stuff becomes a lot less important if we're installing by Attribute name by default So it might actually be that nobody cares anymore about caching once we do that Hello, a quick practical question. You said we should define multiple outputs for the package to make the closure smaller if I for example New TLS has the default out and a man outputs defined and when I look into the in nicks rappel I see New TLS dot all dot standard n dot system dot type Dot man and dot out somewhere in between all those so discoverability with that can we improve that? Right, so there should also be a dot outputs Okay Which is the list of outputs so it's it's one it's in so the so the actual outputs so if you define an attribute outputs is deaf man dog whatever that causes Outputs with those names to be added so you get attributes with those names, but there's also the dot outputs attributes so But but there's still a lot of issues To be figured out there. So for instance nicks and or nicks So what output should it install by default? Yeah, that's not at the moment, right? I'm actually not sure whether it's in the list. Yeah, I think it does the first. Yeah, so you don't get the man pages Which you probably do want Oh It does. Oh, okay. Oh, okay. So that's right All right, so for the camera it is source all outputs and the general question Do you think it's still possible to put a type system over nicks expressions? What's what's your take on that? That would be really hard Because it's not even clear what the types would be so they're actually once was a Andres Lloyd wrote a Grant proposal for a research project and I don't remember the exact details, but so I assume he had some thoughts about what the type system would look like but I Assumed that just doing basic Hindley Milner or something like that would not work because yeah, it's basically attribute sets are records so and there are type systems for for for for record types, but It's also Sort of slapping a type system onto a language that didn't have a static type system I mean, we do lots of sort of dirty things that are Probably not typable so Yeah, but it would be really nice One thing I'd be curious about is just the relationship of nicks to containers and and where What the future looks like for that? Not that it necessarily needs to be formalized or not that we need to have one but from a marketing to new users perspective Where Nick sits into relation of that or features that or ways that we can improve that ecosystem You said containers, right? Yeah. Yeah. Yeah, so I actually kind of skipped over that So I had something there about improved container supports because my thoughts are not very concrete Sort of skip that Yeah, so I think So certainly we can do a lot better at For instance a lot using nicks was to build containers like a docker images because yeah and nicks or nicks OS are very suited for it doesn't necessarily have to be nicks OS, but Since you have all that stuff anyway, you might as well like the module system you may as well use it But I'm also been thinking about so for is a system D provides a lot of sort of container like features So that you can run a service inside a A change route or inside an environment where it only has access to a few bind mounts And that's actually quite convenient so rather than having sort of full containers You just define subsets of the file system. So for instance, you could say the postgres service only needs access to slash data slash postgres and to Well only the subset of the nicks store namely the closure of postgres in a nicks store. So those are in the only paths it needs So that's basically a sort of container and And then you could have things like Using a tool like nicks ops to migrate Had the contents of a container to a different machine because you know that the only things that postgres can access are the things in those directories so and then you really have sort of a handle on on Yeah, what makes up a service slash container So, yeah, they're all sorts of really cool things that could be done there That that's I don't know how to do yet Yeah, so I'm actually curious about the portability of nicks to other platforms besides Linux and Mac OS X so for me for example, I also do windows development sometimes for me It would be great that we can also use nicks properly on sikwin, but the problem is Yeah, of course, we need manpower to maintain the portability to of nicks for sikwin And also we need to make some changes to nicks packages. So for example, that the standard environment works properly I Think there are some improvements possible there. So for me Touching the standard environment, I know how to bootstrap a Linux system, but still I find it a bit scary And I think Yeah, there are some things we can do to improve that Do you also have some ideas on that or not me specifically but Road code or is rock where is he? So do you have something about how the sikwin or windows stuff is going along? Yeah, so it works if you sweat a lot and look long enough it's Kind of works a lot of impurity, but once you have this base image of Sikwin at least from the last time it's when was the last time what would taken the branch Probably like in June July. So from June July nicks packages. They work, but then depends Which package you want? I don't know Python works open LDAP works Like quite a lot, but they are just like some you just need to spend a bit of time It's it's not about manpower because nobody wants to work on Sikwin. It's more about It's true But it's more about Companies wanting it that if they have the deployment and you want to deploy on Windows. It's possible It just costs a bit more Which is the equals manpower And of course it will bit rot Quite a lot. I mean it used to work at some point in the past and Then it for a long time it didn't and then you did stuff and so now it should be in a workable state again, but Yeah, unless we have a Sikwin machine in the build farm it will probably Sort of oscillate between working and not working We have five more minutes for questions. So I've seen your email recently about Hydra that is not officially supported I would like to ask if it will be possible at least Document somewhere what commit works and Yeah, how to achieve some working configuration, right because it's one of the parts of the Next OS stuff that really brings people in I think And it's very hard to find a commit and configuration so that It actually works So the most recent one should work the problem is if you're upgrading because I mean it might break your existing installation because they have a schema changes and Sometimes the default locations change and Or yeah, or it might require some other configuration changes. So that that's really the problem, but I mean the sort of currents Revision is what hydra.nixxs.org runs. So That should work Yeah, so it's but so the deeper question here is that we should really do hydra stable releases, I guess that's Yeah Yeah, that that would be obviously The best thing to do, but it's kind of a manpower issue It takes time to do releases and write release notes and Yeah, and I Don't really have that at the moment Yeah, my take on this is if you if you get someone to be like the release manager to spend some time helping, you know Go through the commits and and form a change log and all that Shouldn't be too much investment and and if we get someone to take care of that I'm sure that will get momentum and and you know more people interested So I think it's yeah, just if somebody volunteers basically to do to manage releases that will Push this forward Hello couple notes When you're talking about upgrading the Nix CLI I'm over it You might want to take an example from like the free BSD PKG. It's almost doing the same thing like a case I did again Well, like the free BSD PKG. Oh, okay, which is you have a PKG search PKG upgrade PKG audit PKG install It's almost like Nix search Nix For with kind of the helping with Sigwin stuff I think you can run Sigwin at a wine so it you could probably put that into a test for Hydra Speaking of Hydra Hydra is incredibly useful, but it is kind of it takes a bit getting used to so if you have questions about this Yeah, I think the IRC channels a good place to ask I have done the Hydra setup before and I try to help people but I can understand the lack and manpower and creating official releases for something that's kind of a development tool type thing so and One last thing for containers some of the people I work with released something called clear the next containers that use hardware support and new support in the Linux kernels and they can deploy Containers in about 150 milliseconds For spawning off a new system. So there's some really neat technology going on in there It's coming out of the open source technology group at Intel Yeah, somebody was also talking about unique kernels Okay, so we've run out of time. Thank you very much echo for your talk