 So, I'm here with all my fancy presentation gear, and I guess I kind of feel like I'm some motivational speaker or something who's come out and been stuck in kind of the small room, but he's still going to try to convert everybody in the audience anyway. So, what I'm going to talk about is kind of some thoughts that I've been mulling over for the past year or so, and there's nothing that, you know, is earth-shattering or final or anything, but I thought it was interesting enough to present a talk about. And I've been looking at this Nix thing, which is a Linux distribution, basically, but also a package manager that you can throw onto a SX or whatever or Debian. And there were some interesting ideas in there, and I'm going to go through some of them, but I thought I'd start here with this Haskell DAV, which is a library that Clint wrote. So, I knew Clint would be here. He had the talk right before mine. If you look at the source code of it, here's the source code, 444 lines of Haskell, the Atlanta Web Day interface that's quite convenient to use. And here's the control file, which is, you know, more than a quarter the size of the entire source. Down here is all the metadata that gets distributed as part of the Haskell package. And I wanted to just make you sit through this, because when you're maintaining something like this and everything is repeated three times and has bounds on it that have to be updated when Clint changes things, of course, Clint is normally doing all this work, but I was stuck working with it earlier too, and I was like, gosh, it just keeps on going forever. And then, of course, there's more, because let's repeat everything a few more times, just because, you know, why not? Oh, and then there's this. So let's just repeat this part, as is completely unchanged three times with different package names, because, you know, why not? And we've got this fantastic new technology that lets us not duplicate the entire description three times and cut and paste it every time you edit it. So this seems pretty crap. I mean, it really does. And there's a lot of them. I don't know if these numbers are really accurate, but I got somewhere around 844 for the Haskell group. Of course, the plural group has like the entire universe. And then there's the Python group and the whatever, Java, blah, blah, blah. So it's like what, 50% of the archive or something is just fairly redundant stuff, I think. I mean, it's insane. So we're doing a lot of make work. And of course, Enrico has already talked all about this in his talk. So he kind of stole some of my thunder. But this is, I find this really annoying and it really reduces my motivation to work on something when I have to go edit everything three times and everything. So here is the equivalent from the new religion that I wanted to talk about. It's still not really great actually. It's repeating everything at least twice. But you'll notice the first odd thing about it is that it does look kind of like some piece of Java script or something. It's actually some little language. And it's got a hash in there, some other weirdness about jailbreaking, which I have no idea what that's about. But this is a package management system that runs on all kinds of OS. So it's twice the complications. But it's definitely shorter. I don't think it looks horrendous. It's obviously not suitable for Debian, but it's kind of an interesting point of, wow, they actually made this package shorter. So that's nice. And then, so I was thinking about this and I'm like, well, what is the actual entropy in that package that I showed you? And here is every line that couldn't be inferred pretty easily. And I think the standard surgeon could also be inferred pretty easily and probably some other things. And I just threw in a couple of little kind of, this is some kind of made-up template language where you could just say, oh, just go, shouldn't expand to all the other lines, please. If you remove the little template language bits, I think this is a Dena Colton Rico's DevDry. So I'm glad we both came up with that. So that's okay. I don't like little template languages. Maybe Enrico's thing is a very brilliant simplification. But here's another attempt at it. This is valid Haskell code. I haven't bothered to write the actual back end, which would be like a few functions. So in here, we have a source package and it just says it's in the web and it has the standards version. And then the packages section, well, I should first say that both of these are functions from some kind of representation of the source package to some kind of representation of the data that we actually want. So it may look like it's just saying, oh, the source is this, but it's actually saying, go pull the source out of this reader and add and then do whatever you want to get out the value that you'd like. That's what I'm assuming I haven't written the code yet, or ever. So then this next thing, the idea here is there's gonna be some kind of a Haskell libraries function that just goes and figures out all the metadata that makes Haskell library. And then there's this also back tick thing, which is a standard syntax that says, oh, there's also a package hdav, which is then gonna be defined by these following lines. This is all made up, but it would actually work just fine. It's probably, I don't think it's that scary looking. I'm using pretty similar syntax to this in my propeller project. I just kind of stole it. But I think what it shows you is that once you get a language and preferably something that's referentially transparent and functionally and functional, you can kind of start refactoring and end up with something that looks clear to read, clearish to read. And I think extensible and a lot better than what we have now. I'm not gonna claim that this is any better than Ricoh's Deborah at all. But it's an interesting alternative, I think. So, hello, okay. So I wanted to look at some types just because why not? We're talking about Haskell-y stuff. This is the current type and it's basically just a control file, duh. You can see my little bullet points. I wouldn't take these with a grain of salt because everybody can have an opinion about things, but it definitely has a nice simplicity to it. As far as it's really easy to learn this, you can just look at it and learn a few RFC 822 format things. You know all you need to know, really. Here's what people, if I believe, tried, haven't they? When there's some yotter or some such thing long ago that went in and said, we'll just have some executable program that you have to run before you can build your package and that was thoroughly laughed out at that being. And I think the FP Masters would now just reject it out of hand. But it has some benefits, too. You can make a control file or other files in the package and make them as simple as you want and have all the code off there doing its own thing, be refactored out and use whatever languages you liked. But it's probably completely insane and wouldn't fly because you really don't want unpacking a source package to grep for all your passwords and email them off someplace and whatever. So, let's see, pre-generated control files. I think this is basically how I would characterize Dev Dry. It basically goes off and runs some, it does some IO and makes a control file, a lot of control phi. And there we go, and of course Dev Dry also generates other things. And you could even say that it's not really pre-generating them. I don't know, Enrico, how would you characterize it? Do you think it's fair to say that every time you're doing IO and generating the file, when you're using Dev Dry, every time you build, you would run the program and it would go off and do whatever and make the file? Yeah. Okay, so yeah, you make a modification and you have to run it again. But otherwise you don't have to run it again. So this isn't completely accurate. And I think it's awesome, actually. I think people will probably be switching to it soon. Can you talk about it in depth? Yes. Please repeat the question. Yes. Or use the mic. Okay, well, I think I was clear there, but I forget exactly what I asked Enrico. But I believe it was something along the lines of, am I accurate in this? And make clarified that, yeah, you don't have to run it every time. But I also think that if people speak up a little bit, the people in the street might be able to hear you. And this is kind of what I'm worried about with this is the whole issue of, you have a thing that you're generating just like automake, auto-conf, all that stuff. You end up with an auto-generated file. What happens if somebody forgets it's auto-generated and then it goes and edits it? What happens if the tools break and then you have an auto-generated file that can't be reproduced from source and get a valid package or a package that you want to upload or whatever? So I think these are issues. They're obviously issues that can be dealt with. But they are downsides to this. And Enrico, if you want to say something or anybody else, please, you know, I think it's valid concerns, right? What's your name, Lost? Okay, I'm sorry. You were apparently doing something else when I was talking to you. I missed that you were talking to me. Yeah, so what I'm saying is that I think that having these auto-generated files can have the same problems as auto-make, auto-comp, and so on. You know, all the problems that we're familiar with, probably the worst of them would be if you had a package that had generated the dummy directory that worked and then some change broke it. And now you're, what are you going to do? I like to think that DevDry is a transition tool rather than a final tool. And so I would like DevDry to be an excuse to have auto-generated version tools end up being doing all the work based on minimal input that could be like configuration of the auto-definition tool. And at that point, there's no need of DevDry. You just run a script that generates Debian using upstream metadata and some extra local bits. Okay, right. But that still leaves you in the position of not really having a solution to that problem, right? I mean, if the script that you're running, whatever it is for the particular language or package is not part of the package and changes and things can break. So you have to have interfaces, you have to worry about, you know. Yeah, I would hope that that fits into the domain of sanity of the auto-definition tool for that language, which if it's well written, it will hopefully not just be a hack of thingies, but some have some clear interface that says this is a Python package that has the extra dependency that cannot be represented there. And by the way, the Debian maintainer is not the same as upstream. And that's it, yeah. So you have to have interfaces and, you know, yeah, that makes sense. Let me move on. So this is what I proposed up above, which is where you have some kind of an upstream source representation that generates not a control file, but some piece of control data, which then tools can use. And like I said before, obviously you can get rid of a lot of boilerplate that way. Pretty much all of it, maybe there's some wrinkles from your programming language that you've picked. And, you know, you don't have the problem of the one up here where you run the, you know, some weird program that generates the control file. If you're using a purely functional programming language, you can limit what it does. And you can say, no, it can't read files outside the package. It can't actually, you know, do any IO at all, most as calls, whatever you really wanna do to lock it in can be done. But of course, speaking of lock-in, you're probably only gonna be limited to one language if you do this. And this can be a problem. Of course, we have the rules file that is already limited to one language. So, you know, I used to think that was a bad idea, but now it seems like it might have been okay. So anyway, this was just, you know, one thing that I wanted to talk about and I wanna move on away from just generating control files because I think personally, that DevDry is gonna shift the conversation. We'll see where we end up. But what I thought was interesting about this is this NixOS idea of taking, you know, just standard functional programming language concepts and applying them to a distribution kind of gives you an insight into the problem space and a different solution than all the ones that have come before and a solution is in some ways better. So I actually wanted to now do something kind of crazy and demo NixOS in front of Debbie and at DevConf, which is weird because I'm not a NixOS guy really. And I have to figure out how to use this slightly odd setup here. Okay, so let me make that a little bit bigger. Okay, so this is the NixOS boot screen using grub. I have some notes which I can't read anymore. It's a little bit smaller. Okay, because I'm not gonna remember all these crazy NixOS commands. So, you know, it's just a Linux system. And, you know, it uses UW like everything else. It has bugs like everything else. Okay, so let me show you a few funky things about this normal Linux distribution. Okay, can you read that in the back? If you can, I can't fix it because it's obviously the console. But look here, we have bash is linking to slash Nix slash store slash nine Y, blah, blah, blah, blah, blah dash read line. So that's read line is in some wacky place and so is every other library. And you'll notice that libhistory is in the same place as libreadline because it comes from the same upstream source. Other things have a different crazy hash because they can run someplace else. So, in fact, if we look through the tree, well, let me show you where bash is because that's also, of course, in a crazy place. It's in run. Yes. Why not? Yeah, let's find the entire user directory because, yeah, there's gotta be lots of stuff in user, right? Yeah, there's user bin ENV because you can't move that, obviously. And if you look at the entire system, bin is the same, there's bin S-H or something. Yeah. So let's look at this run current system. There's stuff in here. I don't really understand it but I believe it's the entire system somehow. Oh, let's see. I think it's SW. Yeah. There's the system. So it all still is there and some crazy place that'll go away when I reboot. Okay, what next? Oh, next does have to use this. Okay. Right. And just for clarity, those are all sim links, right? Yo, it's all sim links all the way down. Yeah. You know, Docker uses funky Winix features and this just uses some links, nothing else. Yeah. Yeah, this is a very long man page with very many warnings. The interesting thing about this is there's one config file which is configuration.nix. And that is the config file. There is no other configuration. So this man page is rather long. Jesus. Yeah. I haven't quite finished reading it. Could somebody like, could somebody just put their finger here? Oh, God, whoa. And one guy. Yeah. Are you surprised with that? Six years. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Six years. Yeah. Six years. That's a long trip for a day. So here's the config file and this is where you define the system. And you may notice that this looks a lot like that previous Nix file that I showed you which is some JavaScript-ish looking language. And yeah, it's the same language. Oh, and this is definitely not gonna work here. So it's doing things like saying, yeah, my boot litter is grub and it's installed here and also here's all the packages that I want to install. Let me install NetHack because that's something that every system should have. And then, huh? DI does. Well, Nix OS DI does. Oh, shoot. What did I do wrong? Oh, yeah. I don't have a cursor so it's kind of hard to, I don't know why it normally does. It's something about this presentation. Oh, it's, I do up here. Okay. That's just funky. So what I've just done is told it, oh, yeah, go look at the file and make the system look how I told you to make it look. And then I should have showed you, of course, NetHack wasn't installed, but trust me, it wasn't installed. And now it is. And all I've done is edit some crazy config file. Okay. So, right, I don't know if this is a good idea, but I'll try it. It says to install GitNX now. I have no idea if this will work. Oh, what does it work? Thank you. Okay, yeah. Yeah, I find there syntax to not what I would expect in every way, but it works. Why was this? Oh, oh no. Oh, it worked. Okay. Can you do it at night again? No. So what I wanted to show you here is I've installed GitNX. It's available. Now if I run nixm list generations, I get three generations. The current one is where I installed GitNX. The previous one is where I installed NetHack and the other one is where I installed the system. So I can roll back to these if I want to. So I'll roll back. GitNX is not installed and make sure you have a NetHack still is. And I can prove to you that it wasn't installed before. Oh, it was. I lied. Whoops. Anyway. Anyway, you saw that I rolled GitNX back. So this rollback thing works. It's just that I don't quite understand the packaging system. Yes. And yeah, it might have changed. I might have done it wrong. No, I'm back to one. Oh, you can. I just don't know how. Everything is still there because let me. Oh, here's where I should have showed you. This is Nick's store. This is where everything actually goes. So like if I go into this handy ZW37, yeah. And then I can run find and it's some crazy X library. Okay, that's handy. So everything goes in the store directory and it's actually a lot like Stowe or something like that in some ways I think. I haven't used Stowe. Madduck has a point. You can just yell. How does the security team feel about this? Yeah. How does the security team feel about this? The NixOS security team or the Debian security team? If you're looking at Debian through a functional lens and you're showing us these sort of things, I want to know what the security team thinks. Well, NixOS, I know, does some wackiness with SUID binaries, but otherwise I don't know what you're asking exactly. Just it seems like there's going to be a. 100 versions of send mail. Yeah, yeah. I actually think that when you set up the system, it actually probably, I know it does something about SUID and since you've mentioned it, I'm pretty sure now that what it is is it goes in terms of right-bid on or something because you obviously don't want them all floating around. But of course what this does mean is that Linus was ranting last night about how horrible it is that we can't provide us consistent environment for an app. Well, if you build a NixOS app, it's a consistent environment with hashes pointing to the version of the package that was built and they don't have fully reproducible builds, but they do have every input to that package also as part of the hash of that package and all the way up. So if you build something on NixOS, it's going to keep working until the Linux kernel breaks it. Kind of cool. And this can be installed as a normal user. So that's kind of neat. Can I get installed Nix right now? Can I get installed Nix right now? I don't know. I've never used the user mode version and you might be able to. Okay. So I think, I'll show people other stuff if there's anything that people are interested in that I can possibly figure out, but I think you get a basic idea. It's just, you know, hash-based packages. And I think a better way to explain this, let me get this out of the way again, is, okay. Well, it's really big now. So we basically have a functional runtime system, which is the NixOS distribution. And the runtime is these little script that I've showed you. So if you look at any, I think, I'm not a functional guru by any means, but I think these are the three big things you'll probably find in your functional language runtime. You're going to have immutable data. You know, you're going to have, you know, there's some value and it can't be changed. That's why it's functional. If you do need to change it, well, you make a copy of it and then you modify one little bit of it. So it's copy-on-write. And it has garbage collection because these other things require that. And that's the only way we found to solve not blowing up. And NixOS has garbage collection. NixM, delete generation, that's kind of complicated, but you can say, oh, I installed a new version to get Annex or a Denhack or some other useful program. I don't want the old one. So I'm going to go delete the old generations and then compact everything and free up disk space. And, you know, these things are pervasive now, aren't they? You can kind of look at Docker and Git and Nix and squint and see that you're kind of looking at the same thing. And you can look at the Haskell runtime system and squint and see the same thing. And I think this is fascinating. I think there's something going on here and maybe the Nix people have figured it out a lot better than the rest of us. But it's very, it's fascinating to me that these things are converging in this way. And that was the main thing I wanted to hit when this talk is, you know, I don't think any of these things except for maybe Git or other endpoint either. And so if we think about where these things are going, we might end up anticipating something interesting or maybe building it ourselves. Colin, does she yell or whatever? Sure, go ahead. Cheers. There's a thing that we've been doing for the Ubuntu phone project because for phones you want this kind of app management as well, so you want third-party apps that you don't need to necessarily upgrade along with the rest of your system and you don't want to have to fight with deep good going wrong on a phone and all that sort of thing. So we have a thing called Click which is basically Unpacked apps into a content directory. It's a little bit like Sto, like Nix in some ways, relies on rather than doing this clever hash-based thing it just requires some strict API management in the rest of the system and anything that breaks apps is forbidden, etc. So that's another example of this kind of thing. It's actually in some ways it's maybe not necessarily a terrible fit for integration with things like Docker as well in the future. So I don't know where that's going I don't know how it will help with being used on Debian with a different set of and in some ways a much more diverse set of underlying ABI's but it's another thing to throw into the pool. I've been going to do a talk at DebConf but it didn't fit into the schedule so let me know if you're interested. I'm sure there's more things like that out there too because it's where things seem to be going and there's more hashes in the world and more reason. We're certainly not the only people to have done that kind of app management. I mean, Linux MetaObjects are very much producing things like zero and still which are kind of in the same space. I think that what really struck me about this is while Docker and Git and all these things, they're using the same basic concepts in different ways Nix took it that step further and said well actually it's just a functional we're going to use a functional programming language as a configuration and is how we build it and so it's basically a functional program and then this is the runtime. They don't actually I think ever come out and say that. I was like what is it is kind of just the runtime system and that was just fascinating to me because it means that they're kind of leveraging all this in a way that everything else isn't. Docker for example it's got Docker files which I think, how did Paul put it like mildly declarative or something like that and so I wanted to kind of look at this too it's down here actually yeah you can kind of see a progression. We started out and just you know raw do whatever you want we call it IO and Haskell and we hate it and then you know things kind of started moving in a more declarative direction once we figured out that having lots of hairy hair balls of shell scripts and what not it's just as bad as you know a bunch of basically calls back to one ten and everything and so you know these configuration management systems and Docker have kind of been moving in a more declarative direction and my one of the things that I'm trying to figure out is is functional programming or some kind of programming language are we going to pull it back from this brink of you know really simple but maybe not really flexible stuff and back into some kind of a more principled realm where we have the benefits of you know it's simple you can introspect over it what not but it's not just pure random code machine code running and so here's a few other examples of this I need a little smaller yeah so you know we started out with Debian Rules just you know I'm calling it IO I'm just ad hoc code do whatever you like this made a depth helper made it just a little bit declarative not too much and then DH a little bit more declarative still not too much and well where could we go now often when people talk to me about a depth helper feature just this morning I was answering an email saying you know could you please put the multi-arrange triple in all the depth helper config files and of course send the question is what's the syntax and how do I avoid breaking everything and you know what else is going to go in there we started Feature Creep into some direction and a lot of depth helper features have you know been put off because of these kind of concerns or something has been thrown together and ad hoc and it's good enough but it'd be great if I didn't have to worry about that and I could just give you some reasonable config file syntax it was extensible maybe of course there's also the hack of the executable depth helper config file which the less said about that the better it might as well start using it everywhere because there's really nothing better it's like the alternatives are all worse go to line one the alternatives are all worse you end up with huge pods of crap over depth in reals to generate that's the thing when you have declarative stuff you end up repeating yourself you end up with inefficiencies and so that's why I think declarative isn't the end point and again I was talking at lunch with Russ the other day and we were talking about he's wanting to get rid of more maintainer scripts and we started off with simple do whatever you like in the script and depth helper kind of factored it out in a way and then triggers kind of made it a little declarative in a way so what would functional programming look like and I think that Russ you actually said something about well there should be in a DevCon config file it shouldn't bother it should just be some simple little domain specific language that maybe parses the config file that it's going to use on the system it can also write to it and of course this is you know very suited to functional programming in my opinion we have things in the functional programming world like parsers and generators that use the same code in a bi-directional way which is crazy stuff I want to wrap my head around that and then let's look at config files well they obviously started out declarative except for the odd ball one like whatever bind or something I have zero one minutes thank you yeah I have ten on it and so yeah I kind of reverted things in the wrong direction with DevCon because I obviously wasn't thinking about big picture stuff and that's one of the reasons I like this being a thought it's given me kind of a framework to think about things but then we kind of have moved back into some kind of well I said it was functional very much this is obviously a huge stretch to say that just the fact that we can take a set of files and get a file as a functional program but at least we're thinking about you know trying to move stuff and here's an even bigger stretch which yeah we used to have IOCode that ran in your head and then we went to nice declarative structural code but then if you actually look at the details it gets really complicated you're like wow this is complicated stuff you could do a lot of stuff with this language so this is probably just you can probably look at lots of things and get this kind of example I don't know how interesting how useful this digression at the end was my main mainly what I wanted to talk about was the functional run time but once you are thinking about things in terms of a functional run time you start thinking about other things like this so I think I'm pretty much done if someone would like to see something in NixOS I can show you or answer questions or whatever Remner so just to remark if you like parentheses then there's a guile version well simplifying things there's a guile version of Nix as well yes there is and it's kind of cool who's got a monad and stuff which Nix doesn't have yeah I had to walk it in somehow so the unique developer it doesn't seem to have a big community yet but is calling it the GNU distribution so hopefully that's not the case of death it is a GNU project well yeah so is BZR and it's actually it's actually fully compatible with Nix on the package level it's just they're running different code on top of the same functional run time so yeah I mean you said it's well just to respond directly to that it sounds like you're saying it's an independent implementation of the same functional run time and not different code on top of the functional run time well I'm saying the code that you run on top of the functional run time is the building of the packages and the configuration of the system which are written using scheme so the scheme code is running on top of the distribution which is the run time I don't know what the implementations of the actual I don't really care yeah but my question is really inside that Nix current generation directory I think it was called how far is that from other than the simulink stuff is it somewhat close? okay in here no not within each package but within the union of each package called the generation okay so I can actually show you where the generation is I think yeah another fun thing about Nix which I haven't mentioned is every user on a Nix system can install packages and they just get a directory in their home directory with everything simulinked all together you can even remove packages if you don't like something the admin has installed it's nuts it's awesome yeah and so yeah there's no difference I can go to my Nix profile and here's all the system and yeah I guess it isn't all the system because I don't understand I forgot to follow simulinks or something but yeah how policy compliant is it I think they kind of use the FHS as a point of departure and there's no user share talk or anything that's for sure there's got to be some better technology these days than simulinks for the stuff right I mean there's lots of interesting overlay FHS file systems and things that you think you would be able to use to accomplish something like this because in simulinks there's all sorts of really weird problems with simulinks and you kind of don't want to use them if you can avoid it yeah I mean I think they used it because it's lowest common denominator in use cases really to include running it on OSX and using it as the same alternative to other OSX things and what not yeah I mean I'm definitely not proposing that we implement this in Debian but I think we could think about how to do Docker containers and something like this and other things fit together and maybe come up with something interesting that would fit in the Debian yep here we go I'm kind of scared by the idea of having to write Haskell to devianize my things but I like the idea of making the common stuff declarative I liked a lot it seems like and it seems to be like a no brainer of a direction we kind of we would all like to go giving on the feedback that I got after the depth that I talked everyone's tired of writing everything twice and and there's lots of common things across packages that can really become like do what I mean or be refactored we really have a lot of potential for refactoring things that we don't really take advantage of I'm going to run this back to Colin and make the camera people unhappy sure one thing I'd like to think about kind of jumps of what Linus was saying last night about app packaging as well that we we haven't it's right and proper always tried to avoid repeating ourselves in terms of people using shared libraries and I think that's right for the distribution regardless of what Linus says but for app packaging for this sort of little third party apps that maybe don't have a very long lifetime maybe don't have a very long development cycle it sucks and I'd like some kind of way to express that much better than we can right now whether that's something like Nix where you you have garbage collected versions of something installed in your system or whether it's some kind of automatic way to bundle everything up into an app structure I haven't surveyed this very much I don't know if there's anything it does out today but it is something we need to look at and also it came to my mind that from a security perspective you also of course besides SUA day binary you can easily end up in some case where you build something yourself I believe and there's no upgrade path without throwing out a way and going back to the mainstream you know there's all kinds of complications with this system it's a play system that I think mostly Haskell developers use because it solves some of their problems and you know it has a few developers and it has a it's all hosted on github and stuff it's you know yeah a little trendy okay I have a minute question which is if I talk this loud is it okay to not use a microfilm no well that's my question to the video team is this loud enough for 4 minutes I thought about speeding things up for everyone else so great how feasible would it be to turn every deb into a next package automatically and let you nix install debian unfortunately I don't think that josh is in the room josh has basically done this I think before he did something with tracking all the inputs of packages that got built and then checking them in a git or something and he had a way it was basically the same basic idea where you have a hash that represents all the inputs of the package you know that would be really neat I suppose I don't know how you would get all the inputs in the debian context in the next packages well that's the main complication of packaging things this way is you have to make everything relocatable every you know possible or could a thing has to be fixed there's actually quite a bit of crossover between the problem of how do you generate a hash of every possible input into the package and the reproducible builds problem which also wants to do the same thing so I think we want to solve the problem of hashing the input into a debian package anyway nix is basically a few patches a gh or gcc I said ghc that too away from reproducible builds and one other at least a personal comment yes please make me learn you write haskell in order to do something really cool debian packaging because I've been trying to make my finds motivation to learn haskell for years and you'll give me a really good reason to finally do it maybe we have time for one more or so I have one question kind of along those lines and you may have touched on this briefly but you're mentioning embedded domain specific languages we're talking about specific languages like haskell is very good this is more of a language design question is very good middle ground between pure declarative and you have to understand haskell's specific quirks around how functions work how garbage collection works how like you have to learn an actual concrete functional language is it possible to design an edsl that works well in multiple functional languages so there can be multiple implementations of it I think I'm not a language designer either the feeling is yes you can probably transform x and z expressions yeah that's basically I mean or type plan the calculus whatever yeah I think that's a good point to end well then thanks