Nix Freaks 17

Nix Freaks Spontaneous topics Passionate discussions Wild takes Programmer humor A full-time Nix production For silence skipping and other useful features consider using a podcast app one cool thing we have there is Release 290 of nix d Which we all use don't we Um, is this a lsp? Yes Um, I've used nil. I don't think I used nix d to You don't use nix name No, well the other thing too is that pretty much I already am just a nix ll or like lsp or like I just use Highlighting like a very wind-winter high text highlighting and that's that's about it um Well then uh, maybe now's a good time to start because they've introduced uh refactoring actions like Converting between nested set literals and Dotted paths I just let my linter do that Which linter is that? Um what linter do I use usually is nix format? Um, unless someone else specifies something in there they're like Um, yeah, whatever nix packages nix pages format Uh, the nix f and t r f c styles the one I usually use just to avoid sure. Well, it doesn't do that Uh, that's true. That's true. It doesn't do things like that. However, I also am not very opinionated on one of these things just because um Okay, okay, I'll try to catch your interest with a different one. Okay Um Converting explicit bindings to inherit syntax or expanding them back That Seems potentially cute. I don't know Yeah sure. Yeah, that's fair. Cute's fair Or how about eliminating with Converts with to explicit Um, that would be potentially useful. I mean that sounds more like a nix packages useful thing because I think right now nix packages is on kind of um Religious charge to get rid of with But uh, I'm actually no shall have no with I'm actually relatively okay with with usage in minimal cases if that makes sense uh if it's like on the single attribute So like one example would be something like the python with packages Uh, python packages ps colon with ps Well, I'm actually fine with that usage Um, but I'll agree like it's kind of an anti-pattern if you just got that slapped up there at the beginning of the year File like a lot of the old nixos modules used to just do like with lib at the top Um, I'll agree that that is Quite a smell There's also another there I think there's a couple more uh similar in Refact earnings, but there there's one that is kind of unusual Aaron's trying to join the call but cannot You cannot because I miss your I miss your pop up or You have some other blockage I'll take a look into two nix d um One thing that I was gonna say though since we're on the the with uh story already um one thing that I wish did Kind of come to fruition though. There's there's an old rfc called um inherit syntax for list um inherits for list Yeah, so like for example we have inherit and then that works in add adder sets right so you could do uh inherit whatever the Select your attribute set and then Then you can select the keys off of that Um, but there's a rfc where they try to introduce a inherit like syntax for lists um is it called that I've see one ten inherit as list Yeah, I think I think that's the one But um There then Because that's my major usage for with right now is pretty much uh take Darius in an attribute set and then populate them into a list That's the that's the one like kind of for me remaining ergonomic situation for with uh if we had something like that where uh There's it was a different syntax support for Projecting certain things from attribute set onto a list that that's what I would Can you confirm whether it's this one I've based it It should be by uh Ryan Burns. Yes, this is the one Gotcha Yeah, joining children The proposed syntax is adders dogged And then open brackets and then identifiers and then close brackets Yeah, one of the unfortunate things is like you For for these like language editions you had to do something that is currently a not supported and be um Try to find something that's as ergonomic as possible and so then uh, does that compose Well, sorry. Does that compose with another Like inside of an existing list or does it is it turn Turn out as as a list on its own only It seems like it's the latter about the uh Where I mean Implementation aside that's the one that's the one area where I still use with And if there was a language supported feature for Avoiding the width in that case I I think I would be totally fine with just not allowing with usage I see it now while you brought it up. Yes Yeah Why not oh I like language features Yeah, you can see at the very bottom there. There's a there's a show alternative proposals in terms of like how to actually do that so look at one of the like so for example the inherit adders That works inside of like a web block and inside of an attribute set Um, but like if it's enclosed into a list so you have a open Square bracket inherit blah blah blah that'd be one thing And a few others where like maybe they are a little bit more ergonomic in that regard um Oh, it does not preserve the order What's up in in uh adder values The in yeah adder values and the inherits That does not preserve the order that does not give you all means to the to declare the order For the members because as soon as you inherit it creates an adder set and an adder set has the order of the I don't know what the key is to be ordered um We'll respect to each other um Yeah, I mean well that's that's true for attribute sets, but like one of the use cases for a list is that then you get a supposed to ordering mm-hmm And then to expand on that for people that are kind of new or did it uh one of the reasons why we call them attribute sets As opposed to dictionaries is that they do have that uh Reproducible ordering of the keys um which makes serialization and all of the mercury calculations actually possible Uh dictionaries are notoriously Generally like not stable in which case the ordering is just kind of up as an implementation detail for the hashing algorithm usually for the key Key look up so I didn't realize how important that feature of an next adder set is Uh, yes, that's It's it's like imperative that you're able to order the keys in a consistent way. Uh, otherwise the When when you did the serialization and like the derivation calculations like you need to have Nate nicks internally is using a term so I think it's actually a list of tuples Uh, if I remember correctly um eight term is what A term is uh, it's like some If I okay if I remember this correctly a term it was like some Just like very basic uh configuration language which The main reason why nicks uses it is because of um actually reason I don't I don't remember um Elco gave a talk in like 2017 and dog So I'm interested in the ARM status of my fan as to why he was using Aterm. It used to be a total separate project outside of Nix. And then pretty much, I think the Aterm stuff has just been vended. Like the code has just been copied and pasted into the Nix source code. And I don't think there's actual external repo. It was like another research project. Something that was going on around the time in which Nix was getting written back in like 2003. So I thought Aterm was a little bit older than that. No. No, I think it is. But I mean, like, I think it was, I don't think it really kind of was a word graduated outside of academia. Yeah, yeah, yeah. Yeah, and so that's. You're called it though. Yeah, yeah, yeah. So that that's kind of why it just lives as part of Nix now. There's no, it's not like a separate library. But if you look, if I remember correctly, like if you do cat on a derivation path that derived macro, I think that is a term. If I remember correctly. Yeah. Yeah. Yeah. So like if you do Nix derivation show gives you like this nice json rendering of it. And that's not what's actually going on underneath the hood. The Nix is the next evaluator is doing a little bit more effort to actually do these little derivation things. Anyway, very, very interesting kind of just like was the word archeology on the next side of the house there for for 99% of people you will never need to know this. The only people who really need to know this is anyone who's having to deal with like a violation store specific. Like if you're hacking on the Nix CLI or David. It's not even the worst file format ever. It's just that different other file formats exist. It feels terrible. Yeah. And that's that's one of the things that's kind of interesting to remember about Nix too. Like so like a lot of times people were like, why wasn't Jason like more supported. And it's like, I think Jason wasn't even a term when Nix was first getting started. I think there was the precursor name I can remember is like, no, no, no, no, no, I think it pretty much to, but I don't remember the term now because this was like 2002, I think is like when they when they first adopted the term g song. But yeah, you're right. We're getting into archaeology. Yeah, we are getting into archaeology. I wish Russ was back in 2003. And Nix was rushing to rust. Feel a lot easier to contribute to it today. C++. Oh my god. I don't want to get my C++. But boy, how do you use it a complex language with multiple. Yeah, whatever. It's very non-standard language system. Found the repo. Part of me, it has this like weird tinfo hat theory that a uncle made Nix so that he could build Nix. I don't know if you ever seen the package expression for Nix, but whole my god. Before they did the components re reorganization, it was like a 400 line file. That was a autocomph build that had I think like 80 direct dependencies or something like that, which is absolutely insane for most C++ projects. Yeah, I didn't know that about the Nix expression at all. I heard you say that for the first time sometime ago. And yeah, I found that pretty comical to find out I had no idea the Nix expression, such as the vast and never even looked at it. Yeah, it's it's it's a big boy. I mean part of the reason too is that the way that it's done on Nix is like it's also where it kind of multiplexed over multiple versions. So that's a little bit more of a compounding complexity there, but yeah, it's probably one of the top 10 largest expressions trying to encapsulate the build logic there. The Mason move did make it nicer. That's all I'm going to say auto conference just auto tools just never don't my recommendation to people it do not use auto tools in 2026. Oh my god. That that era is behind us. Thankfully. Oh, not every project. I mean, there's a few that have I feel like Python. I think still uses auto tools if I remember correctly, but like I mean a lot of these projects though were like 90s era or before. So I'll give them the benefit of the doubt, but or give them the benefit of what is a relevant that was relevant for their time. But Mason is major step up. See make is a half step up arguably arguably. Well, I mean, the nice thing about see make is that then it's pretty easy to abstract over windows and Mac and Linux. And if you do kind of like modern see make it's still verbose, but it's not as bad as hand rolling your own make follow or something like that. Auto tools is just a massive amount of complexity up in your face. Yeah, yeah, I have to do a lot of tools sometimes and yeah, never fun. Does nicks use many libraries. Because that is a lot like because if you think about nicks, it's a CLI utility, right. And so then needs to do like resource stuff. But then also to it's a evaluator. So it's like a lay has an interpretive language inside of it. So there's all the machinery for that. There's like a geez the ball home, garbage collector. And we have like all of the information at yaml, toml, then there was a refactor too. So technically, I think about it like lib store for nicks is now a separate target as well. So, yeah, I don't know, there's a there's a lot going on there. And then you would think it also to like what was it. I think was like 2018 he tried to do rust integration with it as well. And then I think he tried to do like built in fetch your own rust because I was kind of like a nice little isolated thing. And it's true though, because like the URL logic, I think within the nicks interpreter itself has to do curl and curl is just very robust. If you want SSL and all these other kind of just normal networking features that you would expect. Whereas like the rest implementation is like 10 months long and it's literally just like use request crate and then just use a very simple SSL whatever call. And there's a package under nicks versions in nicks packages called nicks components, actually the variance per version of this per version, not per version per version of this package. And it has quite a few components there. Yes, I think it's like a dozen or more nicks components. If I remember correctly and there's like lip expert store. I can't remember them off the top of my head. But then. It's kind of an interesting thing. So the idea there was nicks takes a long time to build for if you start from scratch. But if you built up these little components where like a lot of these libraries kind of have a directory so we graph themselves. So like if you do a single change in something like the Damon, then you don't need to rebuild the XX per part. So you can actually have it where like your rebuild like the nicks. The nice thing about nicks is it's like reproducible and hermetic and something that the downside though is that if you change anything, you have to rebuild the whole thing. But if you kind of break it. Most of it like decompose it down into these more granular build targets, then you can do it where like you get some amount of incremental building. It's still pretty large granularity, especially if you come from like a world of basil or something like that where basil like you can have per file granularity, which is really nice. Nicks is a little like lower level of detail, which is kind of both good and bad. For a package manager, I would I wouldn't make the argument that it's good. But a lot of people try to treat nicks as like a near incremental build system sometimes. And that's not necessarily like a good use case for nicks nicks nicks is that nicks excels for like here's a big software release. A little package and build the software release. How would the basil, what does per file even mean? How does that work? So, basil basil basil, whatever, you know, a basil for people that are not aware that was a like the brainchild of Google. I'm probably going to get some details. was wrong here. But if I remember correctly, Google had a very similar tool internally. And their use case there was that they have a massive amount of C++ code. And what they're able to do with like super fine granularity and it distributed kind of scheduler is use a lot of compute resources to rebuild all these things. So like if you if you make a change to a very fundamental technology, I get it's consumed almost everywhere at Google, then you could feasibly rebuild all of the Google C++ codebase and like non ridiculous amount of time. And so then how they go about doing this though is that they have like really low levels of granularity. And like I change one file that then gets referenced by 500 things. Then like the basal language is able to then like be leveraged to construct a directed acyclic graph that then can compute all these like hundreds, thousands or millions of little translation units or build targets. And then it can just kind of walk that treat. And then the nice thing about a directed acyclic graph is two sibling nodes can be scheduled and built in parallel. So what was the original question basal? How does that work? How I'm trying to understand the difference in the model. So Nick's next is fingerprinting through Merkel trees. And then the way that it constructs a Merkel tree on the next side is through the derivations and then derivations come in two flavors. You get the fixed output derivations which are hashed by their content. And then you get the input address derivations which are hashed by their inputs and they're like recipe themselves. And in that world, we can get like a very unique package in Nick's by just asking like, Hey, what's the identifier? Whether or not it's like a Nick's tour path or it's a derivation path. That's like a unique identifier across time and space. In the basal world, they do a very similar thing, which is like each source file is hashed. But then also they have that small target granularity where then it's also been able to kind of create this directed acyclic graph node. And but the thing that was like on the next side, like I am doing one node in my graph is a package on the basal side. It is like each file is a node and then each kind of consumer of that is also a node usually. And so then you let's do like the chromium one, for example, I think there's four thousand source files or something like that in the chromium project. On the next side, that's just one node in the graph on the basal side that could be millions or it's I think a thousand's if not millions of lines because they have a lot of fender libraries in their two. But the nice thing about that if you're iterating on that code base is that because there's such a smaller level of detail, like then you get less invalidation in the trees if that makes sense. Like any change to the chromium project, you had to rebuild it from scratch on the next side. On the chromium side, if you had the previous version, like the previous commit already built, then all you have to do is just rebuild the delta of what was validated. So. Yeah, which is kind of the best case scenario in that domain problem. Yeah, but I mean, in a similar way where nicks asks a pretty high price of like you need to declare your fetching independent of your building and you can't like enter mix the two basal kind of does a similar thing, but almost at a greater level detail, which is like I need to reference every single source directory and then also any of your dependencies also need to be basalified for this logic to work. And so then it's it's it's pretty much like nicks on steroids if that makes sense. And because they both do mergeltry construction, they both walk a mergeltry to then get at the buildup that you kind of queried for. But basal is just like basal pernicious nicks at like a higher level of granularity and it kind of a different approach to. Yeah, part of the reason why like input derivations is the thing. So for those people that are out of where input derivations are of see I think by Eric some very, very quickly. But what what the goal there is that if you have a derivation generally you just have multiple outputs that you can produce, but input derivation sorry, computed derivations, I'm sorry, I said input derivations that's something else. A computed derivations what you could do is you could have a derivation which then also makes other derivations. And so this is kind of beneficial for kind of like that basal use case where now you can have smaller derivations with smaller granularity. And then you don't necessarily have to have like your nicks build be one large opaque bill. The reason why this is important though is that like Ericsson is really concerned. If I remember quickly, Ericsson is really concerned that like basal may take over nicks. And so like we need to have kind of a nicks solution that is able to do kind of more basal leafings. Yeah, the if I remember quickly, basal 9 is now able to bootstrap its own tool chain through basal. That was kind of like a missing, what's the word kind of the bootstrapping like we was missing its bootstrapping. Like the hurt it had hermetic builds, but the problem is that it's still had to pull the tool chains from the post system. Now that's no longer like a constraint if I remember quickly. So that's kind of in the next world now where it's like truly hermetic builds going on. Yeah, anyway, whatever basal basal nicks is it's just so weird that they are like kindred spirits in a lot of way, but like the two kind of users are just so dynamic, so like hugely different. Like there are like almost opposite ends of this, like ideological spectrums. What I mean by that is like basals usually like C++ people and the so C++ people not really functional programmers generally, whereas nicks is like very functional programming, bleie, bra, free software kind of world. So it's very interesting contrast. Yeah, for each he did some he did some work with those computer derivations, right? Wrote a couple blog posts and experimented around some stuff, the fire call. Yeah, and also he also works a lot with basal as well, which is an interesting thing and experiments with nicks. So he's kind of he's probably the most yeah, besides Erickson, he's probably the most most worried. Familiar with those those those intersectionalities. Commercial break. One on one mentoring sessions with full time nicks host Don, that's me to get started on the code mentor platform. I'm offering an unusual sale price only three dollars for every 15 minutes for first time code mentor users first 15 minutes free. You want to get to know nicks better, nicks OS flakes, flake parts, dev shells, packaging, home manager, xvm, grab this opportunity before prices increase go to full time nicks.com, click mentoring. Because that is one of my biggest gripes with nicks is that it's if you do need to rebuild something like it's it's a terrible experience. I'm not going to lie. Oh, you do an overlay where you like accidentally affects data and you're now rebuilding your entire system from scratch. Like that is just an awful experience. Yeah, so so I mean, I haven't used Gen 2 in quite a few years now, but when I when I started messing around with lib U dev 0, I guess it was the first time I missed my my gen 2 days. Gen 2, it's like, yeah, I mean, you just flip the library and there it's a bi compatible, a bi compatible great. I'll just throw it in there and we're good to go. But with next just like, no, we're going to we're going to rebuild the whole world. Yeah. Speaking of rebuilding or not rebuilding the world. A couple of weeks ago was another release of great tunics. Which I'm looking forward to to trying. It added some new features that I think cumulatively might make it more likely to be a viable solution for some arbitrary rust project. Yeah, that would be that would be another good component for computed derivations though. So like one of the big pain points with rust rust projects is like you're building all the dependencies. Like Right now, a next package is the build Russ package. It effectively does two derivation builds. It like fetches your crates in one hash and then it has to fetch the source in another hash. But like there could be a world where like a computer derivation may be able to just kind of consume the cargo lock and then just spit out a bunch of like, I need to fetch these things because the cargo lock has the integrity shell inside of it. So in theory, you should be able to construct like, here's a list of my ingredients from my recipe. And unfortunately right now, that's not like a thing that can be realized. But the hack there is that that cargo hash that you have to specify is pretty much just like two source checkouts. - When you say computer derivations, do you mean dynamic derivations? - Oh, no, you're right. Dynamic derivation, sorry, oh my God. These terms I am getting all next up. I thank you, I appreciate that, don't, yes. Dynamic derivations, yes, sorry, sorry, sorry. The one where a derivation can make other derivations without doing IFD or recursive nicks, which is also cursed. (laughs) - But I was gonna say, 'cause like, you could think of each crate as a separate build too. So if you do some of the larger rest projects, they got 70 to several hundred crates inside of them. And each time you update one of those sources, you have to build them all over again. But there is a world where you could individually build each crate. And then you could reuse the previously built crates, even in later builds. And so then for CI and CD purposes, it would be nice for that world to exist. The other thing that's painful too is that the build rust package, if you do check, it goes true. It actually has to build your project twice, once in release, once in debug, 'cause cargo test requires debug. And so you kind of pay a two X price for building all that. - It seems you were not entirely wrong. When I look at the RFC pull request, RFC 92, it's called computed derivations. But then in the nicks repo, tracking issue for RFC 92 is titled dynamic derivations. So it seems that sometime after the merging of that RFC, after the merging of it, the feature has been renamed to dynamic derivations. - Okay, all right. So my confusion was, what's the word? - Not entirely unfounded. - Yeah, there we go. Yeah, thank you. No, actually that makes sense. I did a whole review of all the nicks RFCs, I think like two months ago. And so that I think computed derivation is the one I had typed down and make notes of. That one makes sense. But yeah, no, if we could do that and the ergonomics is good, like that would be a huge win for nicks. The potential downside though is like, for example, if you're evaluating your nix host system, you probably have on the order of a few thousand derivations going into it. If you could have it where dynamic derivations now could like, let's say, ripgrap, for example, if you build ripgrap instead of it being three, like two source derivations and one input address derivation for ripgrap. If it was like four-- - Can we, sorry, can we enumerate those? Why is there three source there? - Okay, so for ripgrap, for example, like you gotta do a source checkout, right? So that's one fixed output derivation, right? So source equals some type of build time fetcher that produces a fixed output derivation. Then you have the cargo hash one, which is actually just a separate hash. So it's now fetching the cargo crates from crates.io. So then that's number two. But then your actual build of ripgrap is an input address derivation. So it's three total for the build-rust package. - And hopefully you have the granularity of each crate being a derivation. - Yeah, so in a world where we could like individualize these things, then each 70 to several hundred of those crates, then would be a separate checkout. The reason that you would need to do that is that if that invalidation logic, like if you just fetch them into one big blob, then like pretty much you're starting for a new starting point anytime, anything in that changes. Like if you're going to go the granularity route, you should go to like, you want to make it as granular as possible then. Anyway, where I'm going with this though, is that then each one of those, that's like 70-ish checkouts there. And then then you need to do a build. So now if you want to like build a crate for debug and build a crate for release, then that would be two separate builds for each one of those. So where I was going with those, that like if you did do something like that, instead of rip-grap being kind of like three derivations when Nix is constructing the graph for your computer, now if it has to do several thousand, that actually makes the evaluation potentially a lot slower. Because now it has to kind of instantiate a lot more things on the fly. And this is probably not that bad for like a package or two, but you know, if your whole system's like 80 different Rust programs and each one of them is now, you know, 600 derivations each, it actually becomes like quite a bit of an overhead. And Nix is already like a pretty memory, heavy thing to evaluate on the large. So that would be my major concern. - So we're saying Nix is great, the concept is great, but actually real world cases, some cases the actual hardware that we use, evaluation is simply not fast enough. So. - Or small. - Actually, Sergey, what's his name on GitHub? X, K, D, V, M? - Yeah, yeah, yeah, him. He's been doing like a lot of optimizations on the Nix CLI side of the house. So like luckily that's helped with evaluation time. And I think memory quite a bit as well. Like I think they did a strings overhaul if I remember correctly, so that there's less copy of constructoring going on. But like stuff like that where, like Nix, Nix for example, I just generate a massive amount of strings. Like if you think about it, we did a little like text scripts and then we're embedding little paths all the time. Like we're doing actually like a lot of string manipulation, which is pretty costly because Nix is, you know, purely functional. And so then each time it pretty much has to construct like, you know, thousands, if not millions, of these like little string segments. And it does become costly. Like if you look at the evaluation performance of Nix, it's usually like a gig or more for kind of like non-trivial packages. It's a, it's a lot actually. And then if you're doing something like a Nix OS system, where now you got like system D units all over the place and stuff like that, it actually becomes pretty costly to do so. I think when I'm doing a Nix packages evaluation for my hydro thing, or my hydro instance, it's like four to 16 gigs if I remember correctly. It's a lot. - Yup. And then if you do several Nix OS machines at one, you try to do that at once, then you're toast. - Yeah, and that's my other major concern with flakes as well. Like a lot of people hate on flakes for good or bad reasons. But one of them too is that kind of each time you do like a flake output and you reference a package set, like each of those is usually like a Nix packages version, which doesn't share any dependencies with other Nix packages versions. So you're kind of instantiating a bunch of these Nix packages, package sets, which also kind of just increases the cost, right? So like for example, if you have one flake that exposes a like hydra, for example, like if you just use a hydra flake, like that's instantiating Nix and hydra and all of Nix dependencies separate from all of your other system packages as well. So it can't reuse any of the directed acyclic graph as already constructed. - I have a question about dynamic derivations. I can see that some things are a bit much to do in pure Nix. Okay, fine. But I wouldn't like, I have this concern that I wouldn't like dynamic derivations to be a solution for things that we actually should try harder to do a nix. I have an example. Okay. Yeah, what's an example? It was concrete. Maybe nix should be able to parse Tomo. It's parsing of some, you know, formats. Maybe you mean YAML. It can't parse the YAML. Oh, yeah, I think. Yeah, there's a built-in from Tomo. I don't know if there's a two-tomo. Right. Sorry. Whatever format, YAML, I and I, which is particularly under specified, I suppose, but. Yep. It's simply not being able to parse something. It seems like us. It's because it does seem like an escape hatch. Right. An escape hatch is by default, should be regarded as not the desirable default way of doing something. We want to do. We are motivated to do as much as we can in NixLang. I'll do a quick rebuttal. So usually whenever I see like from Jason from Tomo, usually to me, that's like almost always a smell, because it's usually pretty easy to introduce I F D. And a lot of these cases input from derivation. The from Jason and the from Tomo effectively have to make sure that. That file exists. And if that file gets manifested through a build. And then you need to read it out of valuation time. That's not input from derivation. And so then that's my, that's one thing is that you usually it's like. I really, I really try to stray away from doing the, the, the from the, the from Jason from Tomo. It's, it's fine if the thing that it, that created the file is also added valuation time. So like the built-ins dot fetch, whatever, those are fine. But the packages dot fetch, those are build time. And so then that, that will cause. And then I'm going to do a little bit of that. And so then that, that will cause like pretty serious evaluation degradation. Potentially. The work. And so it's like a valtime. Yeah, to valtime because what happens with I F D is like evaluation has to pause. Then has to conduct a build and it has to wait for the build to succeed. And then it can resume evaluation again. And so like if the build was cashed, that's relatively cheap. But if the build is not cashed, then it may have to touch network and may have to do all these other things. And it actually becomes quite like non trivial to to then evaluate something. And the, the unfortunate thing about nix is like the evaluation performance, like highly coincides with like the nix. Well, how pleasant nix is to use. Because like if you have to wait for your nix build command to spend 20 seconds to then even figure out what it needs to build, it's a very bad experience. Because the other thing too is like the build output is actually can give you information like, hey, these are how many builds are going in progress. I'm downloading that so much things. But like the evaluation thing is effectively a black box. Like it's just the nix tool just looks like a haze during all the evaluation. So like, I FD will also I don't think. No, I think I FD does, does spit out some stuff, but it's kind of just annoying because then you can see like your build count go up. I don't know if you've done a lot of I FD in the past, but it's like I need to build 10 things. And then it starts building like two things. And now it's like, oh, actually, I need to build a few hundred more things. And you're like, oh, what is this? But you're talking about those rolling up refreshing outputs in terminal and CLIs. Yeah, we're like the next 2.0 commands were stuff like norm. They'll give you kind of like a activity monitor of your current nix command. And yeah, like if you have I FD, you can like see the build count go up, which is like really inferior because like actually the issue is. Introduce a special. Detect I FD detection and do a little on screen effect when when those bumps occur. Yeah, but I mean, the thing though, the thing those like I FD does enable certain scenarios that are really nice ergonomic wins. So like one example of this would be Haskell.nix and then its usage of I FD is I can consume your Haskell, Cabal project stuff. And then I can have nix kind of like obscure over some of the details to then actually like construct the dependency graph for you. But it needs to call Cabal, which is the build portion of that to make the plan. And then it needs to read import that as part of the nix evaluation to then actually have nix respond to that. That you could use some materialization, which is effectively like the equivalent of like a lock file. If you want to think about it that way, it's not quite the same. But where I'm trying to go with this though is like I FD does make certain certain things that you kind of want to do possible. But for me, it's usually at just such a high cost. Okay, who's a cause. Yeah. Who's familiar with the to fix nix history code base. I can't recall the top of my head, but wasn't there at one point earlier in the conception of that project where they said something like we want I FD to be a first class citizen. I could be missing miss remembering here, but. I think you're right. In kind of the rfc theoretical space, a lot of people have kind of opposed like if I remember correctly, Shay lovey's no me a project is also like another kind of instance of this is where like there are ways that you could potentially at least abstract over I FD where it's not nearly as painful as the way that nix currently does it. And I don't know. I don't know. I don't know. I don't know. I mean, unfortunately, I'm not well versed in this area. I haven't I haven't thought about it at all, but I mean I FD is fairly simple at a tie level concepts like you said. Correct. You. It's like the most naive implementation possible of like let me do a little bit of building and then let me reread it in. Yeah. Yeah. I remember like I guess you can you can optimize on that a bit, but I wonder how much can you optimize on that right because again it is well like one one potential solution for the air well one potential ergonomic win is that like nix right now is just single threaded evaluation. So has to halt the world. And then it can't progress at all until that build finishes like one potential solution would be like hey I ran into some I FD I can actually defer I can like start the build and defer the further evaluation of this thing until that build resolves. But well, that's going on I can still evaluate other things like right now effectively nix evaluation is like a global walk effectively so like like yeah, right. Snickers is going to be multi-stranded right that's right you can get huge wins then relatively speaking. I found it. Yeah, and actually I'm kind of really curious about the parallel evaluation that's already in determinant nix, whether or not this would also be heavily mitigated. I mean, I don't think it is at this point they haven't made any blog posts about that, but yeah, I mean considerably in the future it could be or or made private builds. Yes, yeah. To fix and blog posts said we want to make I FD first class citizen without significant per cost. Right. Yeah, yeah, yeah. So if you have like a queue builds and you can start pulling and pushing on that more effectively in like a multi-stranded environment. Yeah, there's like a lot you can do there isn't there. In their first blog post it says no more. It's a high level one of the high level goals no more strict separation of evaluation and build phases generating nix data structures from build artifacts. Code I FD should be supported first class and not incur significant performance cost. Yep. I don't quite understand what that strict separation is supposed to be in nix. Why is it strict in nix and how would it be not strict in how would the separation not be strict and how would it not incur this significant performance is there is some distinct design decision around that that makes it more costly in nix than it can be. Then it must be. I don't know how to respond to that in a principled manner, but what I will say though is like for example if you do nix dash build minus capital A pro buff or something like that. Like the way that Nick actually wants to kind of strategize around completing that problem that you gave it, is like, first it is a valuation to create, like, here's the blueprint that I want to make. And like, here's my game plan effectively. And then eventually out of that, I should make a Prudabuff.drv. And then I can take that over to the build Damon. And now it has like a very explicit build plan to realize that. And so then in the next world, like, there's the instantiation inside of the house, which is creating the blueprint. And then there's the realization inside of the house, which is actually building the thing. And then I have D kind of blurs those two worlds. And so I think that's the strict separation there is that, like, in the next world, you're either making the game plan or executing the game plan, whereas something like here in Snicks, it looks like those two things aren't nearly as separate in principle. And like, like I was saying earlier, like, if you could just say, like, hey, I hit a node where I need to conduct a build, but that doesn't pause all my other work. Like, I think it could be reasonable, whereas like, hey, now this I have D can be promoted into like, the build arena or whatever, but it's just one of many things going on. And like, there could be a world where, like, now I'm able to progress on significant fronts without having the current pain of IFD, which is I have to halt the world. I have to wait for that one build to finish. Now I can see what came out of it. Like, I think, I think globally, there's still like the same amount of work to sort of like, if you want to think about it, like concurrent builds, if that makes sense. Like, right now, Knicks is like, I have to do A and then B, then C, then D, then F or whatever, but like, you could theoretically have it where, if those were separate threads of execution, like doing them all in parallel could make the cost of IFD significantly lower. To me, I'm not familiar with the design of the evaluator, but to me that simply sounds like, yeah, sure, if we, if the evaluation was concurrent, then we would have been able to do some more evaluation while we identify that an item, what are they called, a thunk? Oh, this thunk is actually building now. So, you know what, let's try to do this, or if it was parallel, we would be doing any arbitrary number of evaluations in parallel. And we would only be waiting on what really ends up blocking. Yeah, I think. And maybe that's what they're referring to there in a very general sense. Well, I think, I think one of the major reasons why parallel evaluation Knicks has just been hold off for so long, it's been a while since I read the blog post by Alco where he was inducing the, the turn Knicks parallel evaluation, but it's just that those thunks, like you mentioned before, it let, and you're now trying to force the thunk to be evaluated. It's hard to kind of share that context between multiple threads. And one, one kind of nice benefit of purely functional languages is that, even if you have two concurrent threads kind of evaluate the same thunk, in theory, they should produce the same thing. So, like sometimes they have it where they will kind of just redo work, because our work will always arrive at the same kind of computed value. It's okay, actually, like you don't have to worry about mutable state is usually the greatest sin in concurrency. But Knicks does have mutability. So that's one potential win. I mean, like there's probably a lot of, what's the word? Already prior artwork on this with like things like J. H. C. The Glasgow Haskell compiler. The problem though is like they have their own runtime, which is highly optimized for kind of Haskell semantics. Knicks is just kind of reusing like Bohem G. C. and a bunch of other tools where like we kind of have to shoehorn a lot of concerns into. Being kind of a local maxim of all these kind of other technologies going on. Yeah, I don't, I don't, I don't know. I mean, that's one of the nice things about Snicks having their own kind of re. They kind of already have a strategic game plan like, hey, this is one of the things that we do want to enable. And so we will not make decisions which hinder us from being able to achieve that, which is really nice. Whereas like Knicks is like, you know, PhD thing where it's like, I just need this to be technically correct. And in four years, I need to be able to write PhD thesis. But, uh, yeah, it's, it's like one of the many things with Knicks where it's just like, I mean, I'm like, if there, if there was just one person that was like really adamant about making something happen, you probably couldn't make it happen. But the thing that was like a lot of these non trivial complex feature sets is just like, it's going to be a long road to get it over the finish line. And actually, I think, I think Knicks, Knicks in particular, because it's such a complex co-base, has just been constantly pulled in like 10 different directions. Um, you could see this with like the formation of the Knicks maintenance team, where prior to that, it was pretty much alcohol being kind of a gatekeeper, uh, on a lot of the kind of feature and work on Knicks. And one of one of the reasons why kind of Knicks maintenance team kind of came into being was that it's like, hey, you really need to distribute the load, alcohol. Like, you can't be kind of the, the single bus factor. You can't be the, the one person that has to do other reviews and, and has to maintain complete context on everything that goes in. Like, that's just not going to scale for you or for the project. So, um, where I'm going with this though is that like Knicks, everyone can ask their own different priorities. So like, for example, John Erickson, uh, he implemented IPFS support. Uh, he, uh, also, then like content, interdisable derivations also is like a major complex there into which like I think is there experimentally, but it's not polished to the state of being really usable yet. And like that's just it's kind of just these things were as like there's probably a 20 of these kind of like muscle groups. Really nice to have things that Nick could do, but it's really hard to find someone to kind of champion any one of these individually over the line. And sometimes these are kind of hard to develop in tandem with other efforts as well. So like the content addressable derivations like that has to touch the store and a bunch of other stuff where like there's other things going on as well. Like the remote overlay store and all these other things were now it's like. I don't know. It would be interesting to see if Nick's was like a commercially sponsored project if that makes sense like a lot of these technologies historically. Let's take an example of like another ecosystem like what would be like Python or something like that Python has a lot more commercial interest in it. Maybe that's not a good example. Pipy is absolute. I don't know what's going on with pipy, but like Python interpreter development. If I remember quickly though, like that's that's like pretty, pretty process heavy like like they're there were this casual is like very like I wish Nick's kind of had more of a principle. Release schedule burned down contributor pipeline, all these things whereas it still feels kind of just like they split Elco into a oligarchy and the next maintenance team. And so it's so it's like still kind of like dynamic, but it's just got more horizontal scale to it. Anyway. I guess what I'm trying to say like if I if I wanted to still all the my rambling so the past two minutes is that like Nick still feels very personality driven if that makes sense like individuals are kind of having to champion things. It would be really nice if there was kind of more of a concerted effort to kind of see that all moved together and actually I would say like this is kind of one thing that the the forks actually kind of hinder a lot like now we kind of have all this development effort. So I just split up between you know, licks, nicks and determine nicks. Determinant nicks is kind of like a half point there just because in theory, Elco should be up streaming stuff that's been stabilized and determined next back into the nil next. But. I think I think in general though, I think it would be even more of a benefit if everyone was just kind of hacking on the same code base. It would be amazing if we had content addressable derivations like landed and usable and like if snicks their block content addressable store if that was inside of nicks that would be absolutely amazing. And a lot of these things would just be like nicks nicks just gets all the stuff kind of for free because the abstractions allow for this kind of. separation of concerns. And so then as a user, I don't have to think about it. But Nick's does the kind of correct, constituted stewardship on its side. And so I don't know. I guess what I'm saying is like, Nick's has a lot of potential. I'm very sad that it hasn't been able to realize that potential as much as it could. Sorry. - Am I following you, Craig, here in John, where you're saying you wish that more people just like, you wish that we would just focus on Nick's instead of splitting off into Lix and Snix and tricks and all that? Is that what you're saying? - In a perfect world, yes. But I fully understand that those sports were made with good intentions. Like I'm not, I'm not, I'm not saying like it was, yeah. - I got to point out the irony of you moaning and bitching about C++ for the last. - Oh, no, no, no, no, no. I mean, that's the thing. - That's the thing. - You know, like the Snix one makes sense to me. Like C++ is not ergonomic language. Like if you're packing on a tool for a long period of time, like, oh, I want this thing to be usable for decades and then like making the migration to rust absolutely makes sense. Yeah, like a lot of this is kind of the, I feel like with technology, it's kind of like, choose your poison type of thing. Like, either way, you're still gonna get sick. (laughs) - Totally. - It's just in what ways do you, in what ways do you mind not being, or what are the most tolerable ways of experiencing the symptoms and that is kind of your decision making process? Yeah, I mean, the, the Lix one is probably the biggest one where it's kind of just like, it's largely a shared code base. More and more, Lix is kind of diverging. It would be pretty hard at this point, I think to unforeka Lix. Just because they did just a bunch of like, header, renames and all those other stuff right now, it's gonna be actually kind of hard on a source basis to actually merge that stuff back in. But like, Snicks though, like that one to me was like, okay, yes, that seems like a principal decision, which is like for technology reasons, we should be separating these things. I feel like Lix, primarily being a political first for being decision was not the right call there. I mean, it's what it is, but things are pretty much stalled on the CPP, CPP, Nix, whatever you wanna call it, Nix side, I mean, like a lot of, on a lot of fronts, things are stalled, for example, Flake, right? Like, again, I mean, I'm very sympathetic to it as someone who's trying to do a Nix package is fork, you know? That's also probably in a very similar vein of like, the juice, the squeeze is probably not worth the juice, but we will see, like, I don't know. Yeah, it's, I don't know, like with all this, you know, like, I don't know. Who knows what I'm trying to say? I don't even know what I'm trying to say at this point. (laughs) I call it OGNix. I call it OGNix, yeah? Yeah. I call it usually vanilla Nix, no, or Nix O/Nix, 'cause that would be the GitHub owner repo. Yeah. But, yeah, I'm not a big fan of CPP Nix 'cause-- I don't think so. It's not ambiguous between Lix and Nix. And then also too, like, if you start introducing a little parts of Rust, like, is it now fully CPP Nix? No, it's now C++ Nix++ Rust, and it's like-- But none of the Nix developers want it to be called that. They're uncomfortable that their product is being called that. Continue to name them by names that they don't want to be named to buy, so that's unfortunate. Yeah, well, I think the first product to use the term CPP Nix was Twix, okay, now Snix, sorry, this is also confusing 'cause they renamed themselves. But like, originally those blog posts were, like, too differentiated, they're rewrite from the upstream, they use the term CPP Nix because-- Obviously, if you're choosing a different language ecosystem, then that's one way to identify the difference. Yeah, of course. They came up with that. And I mean, some of those people I haven't really heard them use the phrasing after the Nix developers said how much they disliked it. I think some of the Snix developers stopped calling it that at some point, so. Yeah. Yeah. Well, I think Flock Lee is the most consistent-- Florian. Florian. Yeah, Florian, Florian. Yeah, he's the most consistent contributor to Snix, so I-- Yeah. Yeah. We'll see. I guess-- Oh, sorry. The case for OGNix, it does not rename the project. It's merely-- I was like saying, the original Nix, but in a shorter manner. So I think no one would-- I think if they didn't mind, I could call it OGNix. But speaking of-- and you mentioned what is in the context of CPP Nix, what if Nix gains more languages such as Rust than CPP Nix won't work? I actually want to talk about that, and also in the context of possible moving forward with Nix. Because it is well known that Rust is more ergonomic, and it invites more contribution. I would consider contributing because I can do some Rust, and I wouldn't dare do any C++ because I'm too-- I don't know in C++, but it's like there's no in C++, and then there's no in C++. Yep. Yeah, C++ is a very tricky language. And then if you looked at the source code of Fort Nix, I would almost consider it a domain specific language. A lot of the conventions inside of that code base are pretty Nix specific that I don't think you would really see commonly outside of that code base. It's like the opposite of the automatic. It's a huge code base as well though, right? So I'm not entirely convinced. I mean, yeah, most people here are-- Well, it's like-- The command structure that they use for the CLI flags and stuff like that. It's interesting. I've never seen another C++ project use that. Most people use boost options or something else. But Nix has its own hand world CLI, I think, and just a bunch of other stuff. Which is probably-- they're almost all likely to be symptoms of just like it being a passion project originally, and then that's when the conventions were established. And now it would just be more effort to move to something that's more standard than it's really worth. Yeah, I mean, in 2002, a lot of people who took their own C++ because there just wasn't that many great things around. Yeah, exactly. And even now, I think boost options is just OK. Like, Russ has clap, which is just amazing. It's beautiful colors. Yes, it is. Hence, all this other stuff. Yeah. So towards that end, there was recently a call for ideas for Google Summer of Code Nix participation. One of the ideas that I submitted is bootstrapping Rust Toolchain in OG Nix. And I don't see that it was added to the list that was compiled. Is it a silly idea? Is it not practical? Is it undesired by the NIC current NIC team? Why would it not be-- I think Alco would be in support because he already tried to do this in the past. I think in 2019, he did experiment where-- No, actually, it might have been during COVID. Maybe this was 2020. He got shot down pretty hard about this. This was like, people were about happy about it. People weren't avidate. So-- What were the arguments against this? I don't remember the specifics, but I think it's probably similar to the Linux debate that they're having right now. It's just now that you introduce two different language paradigms. Now it's people have to be accustomed to two different things. And then there's just the people that are invested in one but not the other language. It becomes harder for them to work on that. And then also now it's from a maintenance burden. Now, maintainers can't just traverse the entire code base by the language or preference. They have to know another one. I mean, rest to me is probably-- the thing is C++ is just such a high barrier of maintenance. Rest in general, as long as it's safe for us, to me, at least just such a lower amount of ongoing maintenance, it's hard to make that argument. But yeah, and then also FF. five boundaries, foreign function interface boundaries, like being able to serialize data structures across the language barriers, also notoriously difficult, especially C++. Like even with the CFFI efforts going on right now with Nix, that's just purely C. So they had to pretty much like dumb down a lot of the stuff into just a C compatible interface before they can kind of export it. But like if you're trying to do C++ to Russ, I don't remember the, there's like a crate that tries to do it, but it's not one to one and it's very unforgiving. And then you had to worry about things like, I don't know, it's hard, it's hard. Like the example that Elco did in the past was just like trying to, I think it was implementing built-ins Fetch URL or someone with that, if I remember correctly. And so it's like very limited in scope, it's like just this one little piece that got switched out. And even then it's just kind of like a whole, if you wanted to do more Russ adoption, it would be very hard to do like a gradual transition. Hard, on the other hand, an increase of willing contributors. Why do we have a Nix team of, I don't know how many countries, when there's a Nix release, there are approximately 30 for the last couple of major. For C++ codebase, I think that's actually fairly good. Granted, but then again, I just made the qualifier for C++ codebase. Yeah. How many will it be? Will it be 50, will it be 100? Look at all these Russ projects everywhere on the open source ecosystem. Explosion. Everyone wants to contribute and do their own Rust project. It's a project that have to do with developer productivity, all sorts of TY tools. It's a huge untapped resource. And it's blocked by this language that's, you know what? And if these people probably will never learn. Yeah. Full heartedly agree. I feel like a lot of tooling these days is made either in russ or go. And it's kind of just a, if you prefer simplicity of the language, you choose go. If you want a little bit more type cohesive ecosystem. More, more, more, more expressive types plus a cohesive ecosystem. You choose Rust. But, uh, Yeah, I don't know. I, I think, I think it would be worthwhile to make an argument for getting Rust at least supported. Then again, I just, I just don't know. I feel I don't want to set you up for failure either. I think it's like, oh, hey, let's just propose or whatever. I got like a nice example of like using some, some Rust inside of the existing code base. And then, and then you just meet a wall of resistance. Because I think even Elco, uh, meta wall. So like it, it's interesting to me where it's like Elco is almost like a prisoner in a lot of the. Now that Nick's got like some, some adoption. It's like he's almost a prisoner to kind of steering the ship in the same direction, I guess. Um, at least that's not the music at times. You know, I remember the. That, uh, some, some, some Linux conference, Linux itself, conference. Where there was this audience member saying. We don't, we will never accept your, uh, Rust called. Remember that was accusing Rust of being a cult and trying to take over. And the guy on having a talk, it was in, I think it was in the question phase of a contributor, doing a talk about Rust in the, in the kernel. And I can't imagine what it was like being in, in, in his position, receiving that kind of response of this rust being some kind of a cult and trying to take over the software world. I mean, a lot of ways you could make things better. I'm just, I'm doing my work here. What are you, what's called? What are you talking about? I mean, I, I feel like you could probably make a argument that it feels like Rust is kind of very culty. But I mean, like, the other thing too is like I'm also a big fan of Rust just because like from, from the ergonomics of the language and how kind of cohesive the ecosystem, like cargo is an amazing tool. If you've ever had to deal with the pain of language ecosystems that didn't have a good package manager like C++, cargo is just delightful cargo ad. And done. Here's your dependency that you wanted. But I don't know. I feel like for the, for the Linux argument though, it's like they're so used to just using C. Like it's a very familiar language. Like I could, I could see where it's like I've been running C literally since like the mid 90s, 30, 30 years now professionally. And I like, I just don't want to learn another thing. Like, you know, maybe I got like another decade left in a professional career, something like that. And like, I just don't want this thing to be this unknown thing to be forced upon me. Like I don't like my workflow being influenced by external factors. I think that's probably the biggest argument. And then a lot of the kind of culture war. I don't know if you want to call that between the Rust and C people is probably this like. It's something new. It's something different. I don't feel like becoming a subject matter expert on this thing. And if I want to call myself a maintainer of the Linux kernel, like maybe five years from now that is a hard requirement that like I know Rust and that that might be too much. But I like, I think it's kind of interesting though, because like for the next side of the house where C++ like to me, Russ is a simpler language. At least in terms of like total ownership complexity. But like for C though, C is such a very simple language like you still have double freeze and what's the other one, like dangling pointers and all this no, no pointer references and stuff like that. But the thing that was like the Linux, most of word, conventions usually are like pretty well like you just should and shouldn't do these parts of the language. Whereas like C++, it's like almost inevitable that you're going to like she's something to see. I could feel like you just do these certain patterns that are very familiar and you just avoid 99% of all the issues like C++ to me is like. You always always will accidentally like even if it's not nefarious like overuse of a copy constructor or something like that where you're allocating too many things more things than you should or whatever like. My main thing that I like about Russ is like it really influences you to do the right thing first and then to do any more things like allocates something on the heap, you effectively have to add complexity to the way that you write the code. So you have to like go out of your way to make it so that like you you are expressing something that's bad. Whereas C++, it feels like you also have to go out of your way to express the right thing like you have to add const, you have to add all these things where like they're not on by default like just skip go. Oh yeah skip Haskell good good. Yeah I mean but that's the thing that was like Haskell and Idris are like whistle were maybe more correct languages especially Idris where I think it's like a full. Dairy solver affair or correctly like that's a very complex one. But the thing that's like it's a very different mental model from all the other program languages is that that's one thing I like about rest if I want to think about it my problem space in a functional way I can if I want to think about it in an imperative staple way I also can do that as well which is very nice. Haskell you had to go into doing like. No nads or moon runs transformers taxing it's like pretty complex for me to just like do an algorithm anyway. And value I've heard of of rust in the Linux kernel much of it is about making either go state not representable. the meeting place between the two languages. It is there where often rust contributors have requested more information from the maintainers of the existing C code such as, well, what are the possible states? What is the concrete contract? When can this function be called? When must it not be called so that equivalent rust types can be written for this C code or interaction against the C code? I think that conversation might have triggered some of the C maintainers that wouldn't have this conversation. No, we have done well with C until now and this behavior, this request or this demand that we need to know these semantics. This is a cult behavior. I'm just guessing. I'm not really trying to inflame this speculative conversation of what people might have gotten into, but I do want to ask, wouldn't the same benefit be beneficial for the next code base? Maybe, but they use the next team. They use pretty good leverage to the C++. The other thing to the Linux is I don't remember what flavor of C it is. Stuff like const and how much const and like references, const references I think is the thing that you cannot do in C if I remember correctly. Where it's kind of, yes, there's a little impedance mismatch of what you can express in the language itself. Another example of another concern that I don't think you mentioned was also like, if I allocate a object, then like if I pass the object in this call, is it now my responsibility or your responsibility to free the thing after? Those kind of lifetime concerns are also not reflected at all in C, whereas they are reflected in Rust. That's one of the beautiful things that I like about Rust is that pretty much, a lot of your decision making has to be kind of more front loaded. And so then you're less likely to have surprising behavior. Whereas with C, it's like there's always some amount of potential surprising behavior because things can be ill defined. And then like C++, I just convinced runs on undefined behavior at this point. I only made your C++ just because I had the C++ 17, 20, anything, and then clang and GCC, changing like, let's interpret the standard differently. Okay, that's great. Oh, speak of standard. Like that's another thing that's really interesting. Like Rust doesn't have a standard. And I'm convinced that that's actually a good thing. If you look at the C++ ecosystem, like they will do the unorganomic thing because the standard will write in that like, hey, by the way, this is how we defined it. Even though it's like surprising, unintuitive, whatever, like because we, you know, like ossified this in stone as a standard, these now clang and GCC have to implement it in this fashion. Because, you know, 10 people sitting around on a table thought that was the best idea at the time. And I don't know, maybe that was six hours into the session. Then they went to go pizza and then they overlooked it or something. I don't know. I don't know how like rigorous that review processes. But like, so some of the things where I'm just like, what the? Well, Rust has additions. And even if it had a standard, the standard would not, you know, make additions a thing of the past. Yeah. Well, the nice thing about the additions though is that it's kind of like the rest has like multiple layers of representation. So like you have the source code layer, but then you also have this MIR, the middle, oh my god, middle IR MIR. No, it's a one of immediate representation. Yeah, intermediate. I remembered. There's like multiple levels to it and then it eventually goes to LLVM. But the, the thing those like the additions are just that first layer. So like it's a little easier to, what's the word, kind of like go between additions. That's the other thing that's kind of nice about it is that you just set that in your cargo.tomal, but like your crates can still be of previous versions. Like you can mix and mash these things because when you're actually like consuming rust stuff, the, it doesn't have to do a per source thing. You can do it at the intermediate representation. Yeah. So like that's another major benefit to it. Like C++ having to read the headers of other things like you have to also be kind of within scope. Like for example, concepts are C++ 20 specific thing. So like your header, if you want it to be used from C++ 11 on, like you can't use any of those, those language features. Here is my poor request suggesting introducing the rust tool chain to nicks as part of Google Song of Code. Feel free to express your opinion on there. Yeah, that got shot down so hard last time. It was like, I mean, it's, you know, I couldn't find it. Grok could also not find it. Where is it? My only reference to it is just a video that I watched. I think it was a talk that he gave during one of the COVID nicks cons. Yeah, this, this was probably before your time, John. I think, I think sound of the conversation happened in discourse maybe here. Was it shot down? I mean, as much as I should have been able to find discourse. So which is interesting. Yeah. Yeah. I don't know. It's so long ago now. It's our number. But yeah, I mean, maybe, maybe some some fresh use on this would be good or maybe, maybe people still have really shithur taste in their wealth from last time. I don't know. Was it too early? Perfect. Last time. Maybe. But the thing that will now is, I feel like there's so much bad blood in the water over flakes. Yeah. Like even if you put the community drama aside, the the flake technical direction, handling road map, whatever you want to call it, stabilization, experimental, whatever we're out, like that has just almost poisoned. I feel like almost all these conversations. You're not wrong. Like there's, that's one thing that really makes me sad about all this is like, I feel like now there's just so much, what's the word, unresolved animosity amongst a lot of these these characters that like the forks were almost inevitable. And that's one of the reasons why it makes me sad. Like if it was forks for good reasons, like I think Snicks wanting to do a full rust rewrite, you know, like, oh, we can take 20 years of flessons. Let's remake this for when we're grow up. Those sound like good reasons. And I'm not I'm not trying to disparage the likes as a project. So like they they I would say that them doing their own thing kind of lit the fire to solve some UX stuff and a few other things that like have just been constantly put forever. So like maybe maybe it's good. It's kind of like having competition, I think is is good. But like there's but there's better and worse ways to do competition. And I think the original reasons were bad. But like, I don't know. This kind of interesting parallel between this and Vulcan. I don't know if you guys are interested in Vulcan at all. But like the. Well, I'm just an in video games. Yeah, the the people behind OpenGL, the Kronos group, I think. I don't remember the the body that's behind OpenGL. Like they pretty much were just like super happy at like OpenGL 4, I think, where they just didn't want to do another iteration. But then Apple was they made their metal, which was very similar to kind of the attraction later that Vulcan has now. And like pretty much if Apple didn't make their competitor to OpenGL, this is me misremembering probably a talk from my seven years ago. But like it's like having that competition then gave them the the motivating reason to actually do like a major overhaul of that graphics API. For people that are not aware, OpenGL is like a very stateful pipeline thing where like pretty much just like a bunch of heavy context and then it's the responsibility the drivers to infer intent. Whereas Vulcan is like very you have the abstractions in your face and it's very There's a lot more lovers, but if you have holistic context as what you're doing, you can make much greater use of the hardware. And that's kind of the benefit of Vulkan and why a lot of games that run on Vulkan usually perform much better is that the game engines can better utilize those resources. Whereas that open GL, you just pretty much have a draw context and then like you have to hope that your thousand draw calls or whatever you're going to interpret it correctly. You're sorry, doom 2016, the eternal that talk was that talk was amazing. The guy who was doing the implementation, the first round implementation, he was like, it took me a month to get a triangle. And then it took me another month to get doom 2016 running. That's just like, that's insane. Those like those 10 X engineers, I just always inspired me. I would see that. Lighting the fire here, John, but yeah, I mean, you mentioned you just listened to the to the last week, next week's call. Yeah, I watched your I listened to it a couple days ago or whatever and it was really good. I really like to talk about what to still had talking about, you know, flakes alternatives and things like that. He said he just he hasn't bought into flakes and he wants to do something else. No, I mean, I don't know. I think flakes is saturated so hard now that's that's an upro battle. But I appreciate that to still fighting that battle. I wanted to, you know, fight that battle. I'm not fighting that battle. Yeah, no, I 100% agree with the motivation that he had to like flake flakes. The way I like to describe them is like flakes in the small are good. Like if I'm just doing my next was configuration, it's it's a good it's a good use case. But like flakes in the big really are painful. Yeah, apparently. Yeah, and like to give some like substance to my claims here, it's like a lot of them are just like the flake inputs are kind of just these underlying implementation details, but they kind of become the API for downstream consumers. So for example, like if I want to consume someone else's flake, but then I don't want to have, you know, 200 flake inputs in my flake file. And so I do my dot follows now I'm effectively like modifying the structure of those flakes now their input structure has to be reflected in my input structure. And so it's like this kind of it kind of breaks the law of the meter. I don't know if you're familiar with that, but like a lot of demeaners that like you should only be able to interact with something at like the surface layer. Me having to interact with the flake inputs themselves deeply is like I'm now reaching into the details of that, which is too much knowledge on my end. But there's that the flake evaluation performance because it has to do a get all of us filter on all your stuff is also just horrible sure lazy trees will help with that, but you know what that that's been toxic like years now, you know, and then like the general evaluation performance. What I'm trying to say is that like flakes kind of make evaluation a little bit heavier nicks can't progress with anything until evaluation finishes so like the UX of nicks just gets diminished quite a bit because of it. And then the other thing too is like the only parameter that's really kind of respected is the system parameter, but like if you hack on nicks, like there's the whole config thing too, like we forgot about like you can instantiate nicks packages with a bunch of options. Me just selecting system is just one detail like where where did my allow on free, where did my like whatever all these other kind of details that I also kind of usually care about those kind of just got handwaved away so my recommendation if you do use flakes is still use the abstractions that are normal in the nil and nicks world so like overlays doing overlay add all your stuff through the overlay and then pretty much all that you're doing is just applying it over and selecting a few things out of it. That's that's one recommendation and then also helps with like nicks less configurations to because they also respect overlays pretty much times just be overly fanatic so anyway for all you complex me and overlays and then your flakes is just a little thin shim that just instant chasing the packages with your overlays. Yeah, yeah, yeah, I will say though even on the small though there are some annoying parts or shahara, I think you said it best on the last week's fall where you're like if I type one letter in my next so has configuration now the whole thing is copied back to the next door and every time I type a single letter it's copied back which if you're continuously hacking on your stuff if you're I don't all like say a nicks. The nicks break perhaps you might you might modify your configuration that nicks a whole bunch and it is kind of just annoying to know that you have 3000 copies of your project directory in the store right. Yeah, yeah, that's a that was one thing that was very painful very quickly for me was like. Yeah, yeah, I mean like like for for work we have a large multi repal so it's like extremely painful right but even a side like even just on my tiny little configuration just conceptually like it's just. Yeah, yeah, pardon me would just be super happy if nicks packages got rid of all of the environment and home directory logic and then we just have like a better abstraction for just pinning a general. You're totally right you're totally right like a lot of this isn't even like a next problem itself it's a next packages problem like and I think that's that's overlooked yeah. Yeah, yeah, I prefer I could packages I took out all the logic in no longer reads your home directory in no longer reads environment variables. If you if you didn't call next package you didn't call it packages I guess with it then you didn't call it so. Yeah, yeah, I mean like I knew that but yeah, I mean somewhat recently when I was was working on this little tricks project and I dug into it and it sort of reminded of it again and how much it is that way and it's yeah you're right there'd be so much fixed if they if they yeah fix it next. Yeah, I mean, but I mean okay to why do forks in the first place like nicks packages kind of has their hands tied because they could potentially be breaking user behavior. Oh, I've removed it so no they they pretty much can't yeah so that that's one of the things is that it's like sometimes like for as much as I just cracked on forks earlier this talk like sometimes it's kind of just like hey I also don't have to deal with the legacy debt. That's the way you have so now you you you create something like that you can you can experiment you can do all sorts of things you can you can learn a lot and and and that that's a valuable contribution to the ecosystem somebody else is going to read what you did have some ideas maybe it gets back into the original maybe it spawns something new I mean a lot can happen from that right. Yep, 100% agree yeah if I were correctly actually the standard nymph team I think Tristan got some inspiration by me me trying to make a standard nymph repo so hey hello. Hello, how's it going? Do you mind introducing yourself I'm not familiar with who you are. Oh, hi, this is Austin Eric can I leave in. I just got back to my money that dinner so I saw you guys were still chatting to get a join for one of these nights and so I feel like I keep dipping on most of this. Great thanks for joining us. It's real to see you again. Yeah, we're doing all right. Just chatting about forks at the moment forks in animation. Yep, fun fun fun. What have you been up to Austin. In general or next related. If it crosses some barrier for being generally interesting then general is okay otherwise next related. I don't know I kind of heard last little bit here so I was kind of just enjoying listening but I guess on my side. I kind of took a little break from being heavily into a lot of interesting things for a little bit with a lot of work stuff and then now that work is kind of toned down a little bit of and just kind of messing around with jumping back into some home manager things and some next packages development. I kind of you know I'm kind of siloed into my little Vim world and home manager world for a bit now but not I don't know if it's anything really too exciting right now. I like the news. I think we discussed that when we did our episode. Discussed how one would consume home manager news and. Since there was this. News effort really picked off I hope that most of the do you think that most of the significant news end up. I feel like I've been kind of like after our conversation I've been kind of like pushing it a little harder I feel like it's kind of one of those things that like most people don't like to kind of seek out a change log and or release log to kind of figure out what's been changing so almost anything that's remotely interesting I've been asking people to add to the news entries or I will just do it myself because I kind of feel like it's one of those. utilities that just makes it easy to discover any kind of changes that have happened. So after our talk, I've been kind of like encouraging the use of the new stuff. I still don't use it personally because I think I need to still make some changes and home manager and make it easier to work with flakes and everything, but at least for the people that do use it, I'm trying to make it full of more information. Oh, you're talking about the home manager's CLI news. And I'm assuring those two bots, one on Blue Sky and the other on Master Don. Oh, those ones. Yeah, no, I haven't really done anything with those. I basically have just focused on at least documenting the things in our current system right now. I do remember us talking at that one point about the kind of automating some of it to be broadcast out a little bit more. And I think that is an interesting idea. I just haven't spent any time on it yet. So I'm kind of curious, Austin. How do you get started with Nix? I had just stumbled upon it. I'm trying to remember. I think we talked about it a little bit in like the call that we had. I don't know how long ago that was now. I feel like time is just a blur. But I originally got in the next just from dot files and trying to race my machine and then eventually I started realizing the different potentials for it. And then I think it started with just wanting to update a random package and then all of a sudden I was just like addicted. It's just you start realizing how convenient it is. Yeah, Nix kind of requires you pretty high cost of like explicitly saying what you want. But like if you're a racer, you like that's your life. And so like, I feel like I feel like Rysers like if you go to like Reddit Unix porn. Like they it's pretty it's pretty like every other post is like next one. I mean, that's what I think I remember I was like just getting started in Hyperland and Arch Linux at the way back when. And then all of a sudden I'd see like this weird little logo pop up on like the Unix porn and I'd be like, what the fuck is that? And then all of a sudden I'm just like, okay, this whole Nix OS. What is this nerds? And eventually I was like, okay, well, maybe I'll try it someday. And then I'll send you like deeper toe in there. And you're like, okay, I get the concept and then you build your own config out of it. And you're like, okay, now I get it. I'm sucked in. Yeah, I think I think the really beautiful part of it too is like a lot of the rights in configurations like the dot files are kind of like what's this word like? It's like the aesthetics, but it doesn't like lacks the packaging context to make it real. A hundred percent. Whereas like a next setup like literally is like here is my entire system. Like literally you could just run a command somewhere else and congratulations. You have my system. It's able to actually bridge the usability gap. I don't know how else to describe that. And no, I, I, okay, I mean, this is called Nix Fricks. Okay, we're in good company here. No, it's like that's another thing that like really sold me on next to is just like, oh my god, I can actually use the software that I wanted to use. No more like PPAs, no more. Oh my god, I, whatever it like. I could just like build the stuff. Oh, that was the other thing too is like, oh, hey, maybe, you know, 98% of this isn't next package is cash, but like the remaining 2% isn't. Guess what? I can also just build it locally. You know, it might be painful if I'm on the underpowered laptop, but like I at least have the option of like making the last mile myself. Yeah, I think like five years ago, I felt like it was more inconvenient to try to do an override or an overlay. I think I heard you guys talking about overlays for a little bit. I remember like just a few years ago, I felt like it was like I tried to avoid that and then now with the power of machines, I'm like, whatever, if I want to make a change to tweak something, I'll build it. It takes not that much time. Even Firefox recently, they made a change to do some like link time optimizations and I accidentally realized that I was like throttling my next builders because I was like keeping them down to a few cores or something and then when I unlocked them, it was like 40 minutes to build firefox. So I was like, whatever, whatever you need all over right. Yeah, and it's kind of interesting too because like some some packages also like require you to effectively kind of do overlay so like my big example for me because you mentioned them earlier is that if you do the neovim right now, the new v in wrapper currently gets utilized as an override. So you have to actually do the base wrapper dot override it with all your custom stuff. So you bring that up because I know Tito and I have been talking about it for a while and like getting in a mat and stuff we've all been working on next for a long time and Tito is on this like kick right now to try to get us to kind of tweak the next packages provision for Neo Vim to be a little less forced wrapper so that we can kind of offer the idea of like you just give pass through attributes for some of the like the Lua and then you can just do a normal Neo Vim installation where you just have like an unwrap Neo Vim and then you can access the pass through attributes to kind of reach for the Lua that you want to install instead of forcing everything to be on the wrapper like you know wrap program and add it to the path you can just say here are the dependencies here's the Lua you do with it what you want to do. And if you want to inject it into the Lua and you're config you do that however you want to do it. So I kind of I've been enjoying watching it because I've been dealing with a bunch of his PRs for home manager and then now we starting to do some for next packages and so it's kind of interesting because I haven't had the energy to do it. It's kind of exciting things lately so it's been fun to see someone with some motivation right now. Yeah, well is it I kind of came up with a strategy sorry for self fuck you but like for for my little fork effort though I try to standardize how like multiple variant packages work so like think of like FF and Pag words like multiple major. But it's not restricted to that either so like one of them is like see make for example now I can do like see make dot V4 dot minimal dot with like with no actually you can't compose us do you do the graphical one you can't be minimal but no but like you can actually just build it so it's almost like a builder pattern. So I think that would be kind of interesting where you do like was it like new of them dot with Lua 5 dot whatever and then you can kind of can compose it that way so I like that I do yeah I know but the thing that was that it's really weird and then also it doesn't really work well with cross compilation and a lot of cases because you have these kind of like pseudo nested namespaces. Any way for like for for some things though it's actually very nice especially the past through aspect of it like set of books for example I think is also a thing that's under utilizing packages everything's just at the top level packages part and the the the one thing that we really like to see is like for example we have like recon hook it would be nice if you could just do like auto conf version dot recon hook of that or whatever anyway but that's that's my opinion. A lot of this kind of goes out the window though if you with the current package spicy and cross compilation almost all those instantly in your fun because of how package spicy works not to open up that can a word so that could be a whole server talk. Cross compilation next packages oh actually that that was another major draw to me for for next though was that you could it's like actually feasible to do cross compilation index packages it's like notoriously difficult to do cross architecture compilation just like with like see make tool chain files or whatever choose your poison of sadness. Knicks makes it actually like quantifiable which is quite beautiful and when I first started like 2019 like it was pretty hit or miss whether not something would actually cross compile but I don't think in the past like two years I've really had any issues with like the most common 10,000 packages like this is kind of work no it's nice and never good. And I never even attempted to do any kind of cross compilation until next like I feel like the convenience of just learning the few command line tools and kind of setting up a derivation a specific way makes it so much more accessible than having to learn all the different compile systems and their ins and outs and yeah I never yeah super into compiling until next land and then I just started learning more of that from being embedded in the ecosystem really. Yeah like I mentioned see making tool chain files earlier like that's the traditional way for you to cross completion with see make and it's like notoriously hard because effectively you have to specify all your tool chain stuff outside of your host tool chains on some crap. But the next thing about next though is like pretty much it just gives you this like pseudo build where it's like hey here's like the dumb native way to do it I will just introduce things that you know make it so that actually just cross compilation but you don't have to majorly refactor all your see make logic which which is really nice and then the more mature build systems like Mason see make itself like that you. Usually they have enough levers that Nick's is like, "Hey, I actually have very "as opposed to opinions about these things, "and I can communicate these things very accurately to you." And everything I actually just like works fine. That's another thing that I love about Nick's is like, it pretty much gives the scaffolding to enable a bunch of these really difficult workflows to be actually quite easy. Easy with the asterisk, obviously. I'm not gonna say, Nick's easy. (laughing) But easy with the experience. Yeah, easier than generally like the ad hoc solutions that have kind of risen across whatever, 30 years of people thinking that they are reinventing the wheel. (laughing) That does remind me though, just I don't know randomly. The introduction that you were talking about and like getting into Nick's. And I feel like, I remember just first getting into it and like the mountain of a hill that it felt like you were climbing just to figure out what the hell everything was and how it worked and just getting into just basically installing a package, let alone being able to customize your system to the degree that we probably all do at this point. And then once you're kind of in that, you kind of just already have like the documentation trail to remind yourself of how you got where you were because you have that whole declarative config and you've got, you know, you get history of everything that's ever happened and it just makes it so much easier to look back at like why did I make this decision? And it's like, okay, well then at this revision I was looking at this state of the repository and I had these things to work with them. I feel like you just gained so much more of an understanding of how your system is built and then obviously take it to another level of like this, you know, just attributing that across all the different machines that you have and everything. And it's just, it's a fun journey. I don't know, I like it. I think it's kind of, so like doing packaging, yes, I agree with you 100%. Next those modules I feel like has made me dumber. Like just being able to do, well, yeah, well, okay, so like the example that I like to give is I can just go in and I could do, oh crap, they used to be X server desktop managers, anyway, whatever, whatever it is now, where I can switch from dome to KDE, I can just plasma. - Oh, I should know this. - Yeah, like in a single line change, I don't know anything about what's going on underneath but boy, it doesn't just work. Like I rebuild my system and congratulations, I have completely, - You also are probably able to read the source code and see how everything interrupts and you do technically know what's going on. - Yes, yes and no. But like that's the other issue with the Nixos modules. It's the good problem with the Nixos modules is that it's global read. And so then any module could be affected by any change. And so then effectively it's a nightmare when I'm dealing with like home manager and all the different downstream consumers of it. And everyone has their own little like, I'll inject this or I'll try to override this where I'll assume that this is at this location and they're all just fighting over state. Oh gosh, yeah. - Yeah, where it's, what, where was it going to go with? From like a user perspective, just being able to kind of like swap out my entire system, which is a very complex operation. Like Nix handles that super gracefully. And so then like I become smooth brain because the experience is just like smooth brain-esque. But, - Yeah, right. It's instead of having to run like 20 different commands to try to like configure your system and figure out where to change these different files across your entire file system. - Yep. - I just turn in able to false and then enable the true on these two different things. And all of a sudden every dependency is just going with it. - I find that duality of Nix, they'll just hilarious where it's like, "Oh, I can switch my entire desktop manager automatically." But on the flip side of that is, I wanted to update a patch version to this thing that I use. Oh, now the build system was to fetch something of build time. Oh, congratulations. Like I am in a world of hurt now. I like completely blocked. (laughing) - It's like whenever I try to like, we have like a swift breakage and all of a sudden the entire.net tool chain's broken and then the bootstrap for Darwin's broken. And it's like, well, I'll override to do install check equals false. So now I gotta build the entire bootstrap just. (laughing) Yep. - Yeah. (laughing) That Darwin standard name now is pretty chunky. - Oh yeah. - But I still prefer it. - I prefer it. - I still prefer it over the granular add to mention every single court, foundation. - Oh God, yeah. After Randy did all that refactoring, it's been like so much smoother. - That thank you Randy Echinodon, I believe is his name, right? - Echinodon, thank you. - Echinodon, yeah. Thank you kindly for that. Oh my God, that was a skewed. - Yeah, the work that Echinodon did. - Echinodon, Darwin, so far in Nixpeck, is from like we were talking about getting started. When I first got started, it was just on nightmare and I remember reading every single GitHub issue that was related to how they needed to just like cut Darwin out of Nixpeckages and how it was just like the bane of existence for maintainers. And now it's less hassle than Linux at this point for a lot of the stuff. It's been so nice. - Other than I don't know about that. - I don't know about that. - You still have to do is supposed to allow networking if you want the work to be. - Oh yeah, but that's just a minor inconvenience. (laughing) - Well I mean the thing though is, I mean it's still kind of true. Oh actually at the beginning of this talk, we talked about like the riff between like a C++ and Rust maintenance, Spurden. In a similar vein though, like that's kind of very similar to like the Darwin Linux split in the Nixpeckages node where it's kind of just like you get a building on your home system, but then like you may be breaking the other team. And then the other team is always angry about you. I mean obviously for Nixpeckages in particular, like Linux is the one that is usually breaking Darwin. Yeah and so then like Darwin users are constantly just like all this used to do. This is, you know, this is the C++. - It's gotten so much better though. Like I've been using NixOS and Nix Darwin for the last like five years now. And I remember when I started it was non-stop Linux breaking Darwin every single flake update. And then now it's like a rarity and where I'm like, oh great, something else broke in Darwin. Okay, let's go figure out what happened and then you find like the staging next commit that you know, introduced some kind of breaking thing and you got to figure it out and it's annoying but it's not nearly the nuisance that it used to be. - Yeah, I agree. I think the really big one was the foundation. Not it being implied through the standard and not having to be explicitly mentioned, which requires someone with a Darwin machine to do is the major, major puzzle word, successful build kind of when there. - I think another annoyance that I've run into recently with just Darwin in general on the Nix ecosystem. And I think anyone who's constantly following close to the sun with Nix Packages Master or Nix Packages Unstable can really do is we don't really have a good infrastructure for Hydra for Darwin so things get cached really slow or sometimes the build will fail on Hydra even though it's a fine derivation, it just. Sometimes our weak machines just time out. - Yeah, well I remember there was a Cling Test regression or if you had an M4 Mac book, it would fail the Cling Test Suite. But three and older still fine. So it was like, so no, we're kind of just me. Of course Cling is part of the stadium. So like it feels pretty low on the stack and it's not fun. - Where I was gonna go with this though. My major grievance though with Apple in general is that they really treat that platform as kind of just like a very consumer-esque Fisher Price thing where it's like, you are not allowed to be your own system administrator. I'm sorry, but we retain the right to new any amount of your Etsy directory between any update and congratulations. Oh, you wanna run a server? Too bad, you are a customer, you are not a producer. Like. - Another funny thing related to that is I feel like I remember when I worked at Best Buy and we used to have like the tech server room basically in the back where we'd have like everything serving. Like they'd have like the ISO images for stuff we would use for diagnostics and repairs. And like if you ever had to work on a Mac, you'd be pulling images off from that. And then it was like, that used to be like they had some semblance of, you know, some server concept or enterprise concept. And eventually that just got replaced with like, I'm just gonna put a random Mac menu in the back and like. You know that you're just basically using things that they don't care about. (laughing) - Yeah, that's my major grievance. Like for the longest time, the Nick's experience was trash on Darwin because every single minor update would nuke the CSH entry that then put Nick's on your path. And so I forgot about that. - Yeah. - So like yeah. And then determine Nick's, of course, you know, found an inventive way to rectify that, which is just a one shot service on every single boot up. It will restore it if it's missing. You know, it's like, it works. But it should also not be a problem in the first place. Apple, please for the love of God. Just like allow people to do that. Also the other thing that annoys me now too, is that if I remember correctly, slash Nick's on Darwin has to be a synthetic user space mount now, which is, quite a bit slower than like actual kernel file system. Yeah, so it's just the, I don't know, the the next experience of someone has what's up? Is it a mounting itself slower or the fastest and as I think it's access and I know because it doesn't have the privilege of going through kernel space to to be able to do those operations. And so it has like, I don't know the specifics. And so that this is kind of like where my knowledge drops off. But I just know that like the IO performance on Darwin is noticeably slower than like a EXT 3 or 4 on on Linux. So that's that's my major major sadness on that. I also feel like I'm bougie and out of touch at this point because I got an M4 max. And so like a lot of the issues I had with my M1 pro, I don't even have anymore. Congratulations. Because I do remember like what you were talking about with like the performance things I remember it felt noticeably slower when I would do like a next packages review and I'd have to review it like a Darwin derivation or something or even just like testing, you know, rebooting next demon and trying to start all my launch control service or agents and everything. And it's gotten a lot faster. But I think that's one of those not improvement in coding and more of just brute forcing that resources. Yeah, I'll tip my hat to the Apple hardware team. They're the hardware is beautiful. And then the quality of like the MacBook line is also it just feels nice. Like they did a very good job on the hardware. Like I will give them a problem that the the MDM, the model mobile device management team and all their decision making though that that's where I'm like very upset with them. Anyway. I buy a computer. I want to be able to use my computer. Okay, like let me mount a route. All right, a two hour next week. All right. Thank you very much. Making next week's 17. I think thank you for thank you for hosting Don. Yeah, nice. Sure. Always great. Until next time. Be well. I'll be honest. Never going to. For past and future episodes search full time nicks on a podcast app or visit fulltimenicks.com. Nicks freaks takes place weekly. You are welcome to show up and chat or even ask to join the call. For details visit fulltimenicks.com. I am pleased to be in full time service of the Nix ecosystem. Should your budget permit supporting open source consider sponsoring me. Thank you. Fulltimenix.com