Tech Over Tea - Long Awaited NixOS Episode | Tristan Ross

Episode Date: April 18, 2025

I've said I wanted to talk about NixOS for a long time and now we have one of the recent release managers, Tristan Ross on the podcast to chat about the project, the value of Nix and maybe you'll decide if you want to use it.==========Support The Channel==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson==========Guest Links==========NixOS: https://nixos.org/Tristan Website: https://tristanxr.com/==========Support The Show==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson=========Video Platforms==========🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg=========Audio Release=========🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw==🎵 Anchor: https://anchor.fm/tech-over-tea==========Social Media==========🎤 Discord:https://discord.gg/PkMRVn9🐦 Twitter: https://twitter.com/TechOverTeaShow📷 Instagram: https://www.instagram.com/techovertea/🌐 Mastodon:https://mastodon.social/web/accounts/1093345==========Credits==========🎨 Channel Art:All my art has was created by Supercozmanhttps://twitter.com/Supercozmanhttps://www.instagram.com/supercozman_draws/DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

Good morning, good day, and good evening. I'm as always your host, Rudy Robertson. And today, people have asked me to do NixOS stuff for a very long time. I don't even know when the last, the first time I got a NixOS suggestion was. Probably, I don't even want to think about it. I actually don't want to think about it as being that long. So today we have someone who knows quite a bit about NixOS. How about you introduce yourself and we'll go from there.

Hello, I am Tristan Ross, also known as TheComputerGuy and I am actually the 2411 release manager. I helped organize 2505 which will be releasing next month. Uh, I am also the standard in one of the standard environment, uh, maintainers and maintain all of VM, SC Linux and a few other components in next packages. So I'm pretty well versed in what's going on there. packages. So I'm pretty well versed in what's going on there. So as I was saying, before we started recording, like I, I've, I know a bit of like surface level stuff about Nix, right? If you're,

if you're in the Linux world, it's pretty hard to not run into somebody who's going to show Nix to you. You know, people talk about, hey, Arch users like to tell you they use Arch. I've noticed quite a similarity with the, with Nix who has people. Anytime there is any question about dependency management or packaging or anything that could potentially be fixed by the way that Nix handles things. I'm going to get at least one comment from someone in the world of Nix. Yeah, NixOS is basically like the new, by the way, I use Arch kind of thing. I used to actually run Arch kind of a little bit before I switched over to NixOS.

I was on Void in between, but it's kind of gone that way where for a long time Arch Linux was kind of like the, hey, I run a specialized Linux system. But now it is very much becoming NixOS with the popularity it's been gaining over the past five years that's been really exploding. You might just start to become really staticky for a second. Could you say something again?

Okay. Okay, it's gone. How do I think it? I think it just one of those weird issues that. Pulse pipewire has or something like that. Sure. Okay. If it happens again, hopefully doesn't happen again.

Anyway, yeah, I definitely have heard a lot more about Nix as things have been going on, especially as things like Flat packs maybe not snaps as much but definitely flat packs have become a lot more popular as a way to deal with dependency management on these different systems Usually you're gonna have someone come along like oh, we don't need something like that. Hey, we could use this instead but I guess Clearly there's a reason why people Always come along suggesting nix right like it It's not just people saying it because they just kind of feel like it so I think the best place to start is

So there are two main things. There is NixOS, the distribution itself, and there is Nix, the package manager. I guess we should probably start with the package manager itself. Yeah, so I actually want to start with the language because the language is kind of what builds the basis of the package manager. So the mix language, it's got, from what I've heard, similarities to Haskell. It is a functional programming language, and you can kind of imagine it as a JSON with functions that spits out bash scripts. That's essentially what it does. You have very primitive things like attribute sets, lists, just your generic strings and

little bit funky ones like paths and string context is numbers are another like regular thing. And then you had this funky type called a derivation. And derivation is really like a recipe. You provide your derivation with an attribute set and you provide it with things like the system, uh, double, you provide it with a name and a builder. And with those, those three components, it's able to call the builder and then spit out to some sort of output that is determined by hashing the attribute set.

And there's just some mapping there that just does a funky hash and it gives you this long character string. You're like Nick slash store slash whatever garbage with a name attached. And so essentially what you get is kind of like, if you look at like a database, and kind of like see everything has an ID, it's kind of like that. But it's on your file system. And so this is kind of getting into where now we're caught talking about NICs as they're just a NICs language.

And you can build up these concepts of just some arbitrary location that you're writing out to. And you can build up a packaging system. And by referencing one derivation into another derivation you suddenly have dependencies. And if you track things correctly enough you can build up a dependency tree. And then with that if you specify I want this derivation out of all the other derivations it's going to pull just that derivation and what other other derivations that derivation needs. Right. So you get the concept of being able to pull its dependencies for every single

one package. Kind of like how when you do an npm install, it's going to pull all the dependencies. But instead of going into some RAM directly like node modules, it's going to be your next tool. But with how Nix works, you don't need to be roots, unlike other pack managers like Pact or Pacman, because it's in the next store. So now you certainly have a way of installing packages without really installing them on the system. And through that, we're able to have a package repo. Right. So the Nix store, you use that term a couple of times. The Nix store is basically the location where the packages are stored, if that's correct, or the installed applications are stored.

Yeah, it's not really considered installing. There's a few different phases Nix goes through. You have evaluation, then you have instantiation. You go from there and then you have either building or fetching. And the building or fetching is what it does to take what's called an instantiated derivation and putting it into the store. And the way it does that is you'll check to see if your substitutors or one of your builders are available.

And if it's already built and available, it's just gonna pull it from whatever build system that you have remotely available or whatever other like caches that you have available as a substitute. And it just puts them next door and there you have it. So I always hear about Nix, the handling dependencies and handling like installed versions in a better way than you would have in a more traditional packaging system. So through this system where you have these unique ID for your packages and it links to the other packages that that package depends on, you can then have multiple versions of that on your system and

it links to the different IDs for those different versions of the package. That makes sense. If I'm saying this correctly. I don't know the Nix terminology, but if that- Yeah. So that's kind of coming from instantiation. So evaluation is going to eval- all of your Nix code and the instantiation. What it does is it tells the

next statement hey. I had this attribute set being pushed to this derivation. Actually make it a derivation so that it takes all that metadata associated and then it assigns that hash and through this. Since every hash is arbitrary for is how that package is

specifically written. If you change certain things, you can then get different versions of a package. Even with like different packages that has different like build features, like, Hey hey I want to build some browser without FTP support or hey I want to build something using GCC instead of Clang. You just specify that in and because it changes that attribute set it's going to change to hash and then you suddenly have two different versions

of the same exact package. They can even be the same version of that package, but because they evaluate it differently, they have a different hash, which means they're going to be specified differently and not included together. So does this system work like all the way down, right? Like, obviously it makes sense for, you know, like your

Firefox things like that, but does this work at the level of something like Glybc? Do it work at things like the, the Lynx kernel level? Is there a point it breaks or does this work all the way down the stack? As long as you have some sort of arbitrary way of evaluating and being able to put a file somewhere. You can pretty much put anything in there. Like even some of the concepts you've thought of is like doing machine learning models and splitting them apart and then putting them in the next stores because then you're able to have these large language models inside the

next door and only pull the components you want. Okay. I wasn't, I was not aware of that at all. Okay. Yeah, this was actually a concept that was kind of thought of during the recent conference in Pasadena called Planet Nix, ran by Phlox, where the idea is to split up these large language models because they're usually gigabytes in size and you don't need everything So if you have some sort of way of being able to build it and terabytes, I think you mean gigabytes is not that much

Yes, sorry, I mean I haven't worked much with these models but they are File sizes that get difficult to download just because they're so large. Right, right, right. And there's so many different devices then. Sorry, I was just being pedantic. I just, it don't. I have California internet and it's also great. Yeah, I don't know whose side it was then.

Anyway, you were saying? Yeah, so basically any sort of file works. There's a couple kind of files you don't really want to put in there like device files or like sockets, but that makes sense, because those aren't going to distribute easily, but any regular file SIM links. Those work. All your generic things works,

so we're able to put ellipses. We can put compilers, we can put tarballs, we can do anything inside of a derivation basically. Right. Okay. So the Nix package manager itself, this is not something that has to be used on NixOS. This can be used on other systems as well. Yeah, kind of like how you could use like Pac-Man on Debian. You can throw it onto any system, except for with other package managers, they kind of care because you're gonna have conflicts.

If you just try to installing like Firefox from the Aurora onto a Debian system, you're gonna get some weird problems without trying to hack around the problem. Sure. But with Nix, because everything references each other, and because the Nix store exists. That doesn't matter. You can have a distribution of. Nick's OS or Nick's packages and multiple versions of that could be in your store

and they will never conflict because they all evaluate as their own things. So how does this like with the distro? Is it like symlink it to where you would expect binaries to be or? Yeah, so I want to explain a little bit more with how... Go right ahead. ...NixOS works. So with NixOS, it takes that concept of a draw-avation and that it going to an output and assigning it

to various things for Linux. And so it does things like setting up the ETC directory. So like a very simple file to kind of think of one is the OS release file. If you aren't aware of that's the file that contains the metadata, the file with distribution you're on, it's a very simple file format.

But because it's just a text file, you can make a derivation. And you're going to have it just written text and then sim link it to that with a thing called an activation script. And this is going a little bit more into how NixOS itself works. You have what's called the top level of derivation, which contains the stateless immutable build of your entire setup. So it includes your graphics drivers, your kernel,

even your bootloader. A little bit of that information is in there. And then all the rebuild script does is it just builds it and then runs the dry activation script, which is a script that is just the minimal amount of stuff to set up that top level derivation so that when you reboot, you're going to get the next version that you've built. And so that's how you can kind of set up etc. And with the activation scripts, you're able to do even weirder things like set up sc Linux, or you can have it do whatever because activation scripts are just a script.

Okay, so I'm just trying to keep up with, I'm trying to keep up with Nixie. For anyone who's not aware, I have like a surface level knowledge, I'm like learning as we're going here. I did a bit of stuff so I could like work out what to talk about, but like, you know, I might as well go back and rewatch this one to actually follow along with everything that's being said here. And I think this is one of the things with Nix and with Nixwes. A lot of people have,

you know, you'll hear people talk about it, but you always hear people say, Oh, it's difficult to learn. I don't understand how the system works. And it's a very different system than the way most distros work and most package management system works. Yeah. So the thing with Nick's is that you're in NixOS is you're not just learning how Linux works.

You're learning package management, your dependency management, a new language that's based around a functional programming and functional program out zone is a difficult topic. Haskellers know that a lot because it's just a mess sometimes. But there's just all these concepts that it takes from what we've seen a lot of time for people to bring up to a good understanding of NICs. We've actually gotten surveys that we run every year by the marketing team. And most people start picking up more of these things after three years of using Nix.

They start understanding all this just because it takes so much time. And for myself, that was actually the same thing. I started using Nix OS back around 2022, and it's 2025 now, and I'm doing all these things. Before, back in 2022, all I knew really how to do was like Pac-Man, XBPS, which is, Void Linux Package Manager, and all that. And so it took me a long time to figure out

how to do all this stuff. And so there's this huge learning curve. It looks like this. It takes so much effort to learn. And all of a sudden it just shoots right up because once you grasp all the concepts, there's a lot more you can start doing. all the concepts, there's a lot more you can start doing. It branches out a lot further once you've kind of understood. And of course, everyone can learn differently, they have different learning

rates and all that stuff. So there's the human factor in that. So I think it makes sense that people say it's a difficult distro to learn and difficult stuff, but there's just a lot you can get out of it. I think conceptually, it's not that complicated of an idea, but there's a lot of Nick's terminology here that I feel like does make it a little bit harder to follow, and I'm sure the terminology is important, but initially hearing I'm like, okay wait, so that was that one, okay let's- let's get back to that thing. Um, yeah, I- look, I'm happy on Arch, but I- I- at least initially seeing Sort of the grains of why this system makes sense Yeah, there is a lot of Terminology and the stuff that's used they make sense like a derivation

It's a derived output essentially. That's kind of like my understanding of it but the nice thing is that things like Nick's packages already exists and Nick's OS already has a lot of stuff in it that unless you're really wanting to get into the fine grain of how everything works, you don't need to learn everything. You could learn just enough just to package G to hello and you'll be fine. But if you're someone like me and want to like really explore all these interesting things, then yeah, it's going to take years to pick up how everything works at its core. everything works at its core.

Okay. I want to talk a bit about the NixOS distro. So obviously there is the Nix package manager. I actually, I don't know what side to start in here. I, should we talk about the benefits of the distro first or the benefits of the package manager outside of the distro? Which, which direction you think makes more sense to approach this from? I think it's kind of a, they work both together. So a lot of the like, but like, I'm kind of, yeah, like the point I was getting out there, like if you can use the Knicks package manager

outside of Knicks, like the KnicksOS, the distro, what's the point of the distro itself? What's the point of the distro itself? Yeah. So the distro itself is a modular Linux distro. So that means the configuration it's all modularized. So it takes a lot of concepts that are from Linux and Linux distributions and units and puts them into a easy to understand way. Like if you want to change your hosting, it's just setting host networking dot host name equals the string in the backend.

There is a lot of stuff going on. That's going to change a host name file. And when you rebuild, that's going to change how Etsy works, which didn't change the top level derivation. you rebuild, that's going to change how Etsy works, which is a change of top level derivation. So re-implementing NixOS, it takes a lot of effort, just because there's so much stuff that's going on. Okay. So if I'm understanding it right, NixOS basically uses the Nix package manager for, like, across the entire system.

Whereas if you put the Nix package manager onto an existing system, you can choose how much of it you want to be in the package manager. Yes. So, with NixOS, you have your entire Linux system. You can even do like your home directory management straight through that. But with Nix on top of like Fedora or Debian or whatever, you're just getting the package manager. You could theoretically migrate over to NixOS

by slowly replacing things that is actually a tool someone made. I'm sure it is. It's cursed. Do you happen to know what it's code? NixOS Infect. It has a very apt name, because it infects your system to run NixOS.

And this is actually how we got NixOS onto a lot of different VPS providers, because they don't let you pull it up in ISO, which is a bit of a problem. It's like, what if you want to change the distro? Now you're stuck with like Debian, whatever, or Ubuntu 2011. So, NixOS in fact is a way of just moving stuff in such a way that it becomes NixOS.

Well, I actually hadn't even thought of that. So if you do have it on top of a, another system, much like say with a Flatpak, you could get access to a lot newer packages on something like Ubuntu 1804. Yeah, no, that's still okay. I was just thinking is that still supported? Yeah, technically in the long the super long term support. Yeah, so you couldn't sort on something older like that and get access to these newer packages. Yeah, that's actually one of the benefits with Nix packages, which is just the package stuff is that as long as you can reference Nix packages, you can get like whatever you get the current gnome release. You could get G lib C whatever you can get the most recent version of steam if ever that's a little bit wonky because their own stuff.

But yeah, you can basically get whatever, as long as you have the derivation to evaluate. is that you have the derivation to evaluate. So if I'm on a fast moving distro, like an Arch Linux, a Gen 2, where there's good package support, pretty much everything you'd possibly want is packaged. What would be the benefit of including Nix on a system like that? Nix on a system like that? The benefit I could think of is instead of using just Nix, you're going to move over to NixOS because NixOS can be thought of as both a stable and a rolling release distro. We have releases every six months, but there is the unstable branch they can just daily drive. I do it other people do it but unlike Arch it doesn't break every two months because

we do a lot of testing and one of the side effects of having everything evaluate is you can rebuild the world with just a one line change. So we have this pipeline of applying PRs that changes mixed packages so that things may be broken but you're going to still have a bootable system. That's one of the kind of more beneficial things. You use that term rebuild the world there. What do you mean by that? So that basically means like whatever package you change rebuilds literally everything. Like you change your, uh, libc, you're going to be rebuilding everything from like,

G new hello to Firefox, to WL roots. We just say we build the world because you're rebuilding everything at that point. If you're going to be changing that much. Right. Right. Right. And we have a handy little flag on that says you have like 50,000 rebuild packages and you don't want people try to do that on a core to do or whatever. Right. Well, unless you're a psycho, um, I do, I do have a friend who, uh, compiled and installed Linux on a PS2 which is time-consuming. Yeah I used to do that with Arch Linux on a what's it called? Dell Latitude E6420 back in high school. It was slow. I do not really recommend using a system that old in 2017.

Yeah, no, definitely not. Like, get yourself like a $50 mini PC. It'll be faster. So... Yeah, well, at least now I have great hardware. Oh, yeah, for sure. That definitely makes your life quite a bit easier. Okay, so if somebody wanted to mess around with Nix, would you recommend they go straight into the distro or install the package manager on top of whatever they're currently using?

I would just say just do whatever interests you. If you don't really care about NixOS, fine, just use Nix itself. You can use it to manage your development environments because you can create what's called a Nix shell and then you just have all your dependencies there and then you can just do Nix shell or Nix develop and then you would get your entire development shelf and your C libraries and your compilers. You can get weird things like Java and just anything. So it's pretty much just you can do whatever. Just try playing around with it. See what you like and things like that. Okay, fair. So let's see here. Oh, this is one that I term that I come across quite often. What is a Knicks flake? Like I've heard this term so many times, I have no idea what it

means. Yeah, so we have two kind of methods of managing systems and well, NixOS systems and packages and shells. Right. And so a legacy way is you have configuration.nix as your entry point for managing your Nix West system. And then you have default.nix, which is the same kind of concept, but just going to be an attribute set or just a single derivation that builds a package or multiple sets of packages and then you have shell.nix which is similar to default.nix but it provides you a development shell that you can build and kind of work in.

I'm kind of imagining it as like a Docker container but instead of entering Docker and doing all that weird madness, it just drops you into an extra shell. Now, a flip is special because it tracks all of your inputs. So let's say you want to have eight different versions of NixOS. That's just some random number I just pulled on my head. It doesn't really matter. But let's say you just want whatever package or versions they want to pull from these different things. You can do that.

You can just add that input in, and then you lock the Flick, and then it keeps track of the hash and all that inside the Flick lock. And then it's going to be able hash and all that inside the flake lock and then. It's going to be able to track all that for you and the flake once you write it up, you specify your NixOS systems, your development shells, your packages. So it's a very global kind of entry point for a repository to

dependencies, uh, specify your packages and all that. So it's a more like modern way of kind of the dealing with things kind of, I'm not really sure what other equivalent thing that isn't next. It would be similar to, we can't imagine like a package job base and file, but it's code. So it's a way of defining different, I guess, different subsystems, I guess? Like, maybe that's not the right term to use, but, um. Yeah, not really. You can use it to like like let's say dot files a lot of people have dot files and you want to manage your systems between uh five different computers well you

don't want a configuration for every single system and have duplicate lines. You can write your own models and then plug them up, but have multiple NixOS systems in your Flake. Now when you rebuild, it's going to check that host name and check to see if that host name is an attribute within the NixOS systems attribute inside the Flake app. And so now you can match all five of those systems, which just a lot less code. Okay. So it's a way of defining different systems and sharing stuff between them.

Kind of think of it as a more way of tracking uh, mixed dependencies and I'm being able to specify what you want to output Right. I think I understand where we're going here. The problem is there isn't any other thing that is on this level of complexity and this amount of possibility that a Nyx flake provides in other spaces. Terraform doesn't really have a thing because Terraform and Ansible can't get lumped into Nyx There's a really an equivalent thing outside of Nyx base that I'm aware of Yeah on the

Sorry in the in the the Nyx docs there are literally two subsections Why are flakes controversial and should I use flakes in my project? So even even in the Ny project, it's like, we're not entirely, we're not all fully set on the exact, should everybody use this? Yeah, that is changing kind of because one of the implementations of the next package manager, they've considered Flake stable. And at this point, a lot of people use the legacy way of managing things and then they eventually move over to Flake. So at this point, it's in the middle point of like, is it the thing that everyone's going to use or is there's going to be something else? No one has to move with an alternative.

So everything's kind of moving over to flakes, but the legacy way is still going to be supported for a long time. Is this one of those things you actually need to care about if you're just starting to learn Nix or is this one of those things where it's like, Hey, if I want to spend all of my day, I want, I want to become the future release manager and learn everything about this system, uh, that you need to care about. I mean, if you want to learn everything, definitely learn flakes. It's one of those things that you should. But if you're playing around, take a look at it at some point.

It's one of those things where it complicates things more. But the amount of benefits you get out of it, are just easily managing your dependencies and easily just doing entry points into your repos. It's just, it's just going to make things easier. But it's more complicated to learn. Okay. So, Nix does a lot of things, but what would you say is the main problem

that Nix is attempting to solve? I'd say reproducibility and dependency imagining, because those kind of come hand in hand. And the way Nix sort of solves this is everything predictable. And by being predictable, you're reproducible. It's not a one, you don't get one without the other exactly, but they come hand in hand. And the way Nick does this is by doing like having the evaluation to where, oh, it only references this specific package for its dependency. It's just because we're using that. But some packages and stuff like C compilers like to tag things in like the time something builds or some arbitrary pass. And so we have these concepts and stuff,

or not really concepts, these different features within Nix packages strips that information out. And so we can do, if as long as your operating system and your CPU, generic bit of build configurations, the same, you can build the same package on two different systems at two different times of the day.

And they should be a binary equivalent. You do a diff, and they should show it's exactly the same number of duplicate bytes. Now, of course, you have some weird things like C compilers, I think Java is one of those weird things. Google projects because Google packages things weirdly that getting them reproducible is hard but not impossible.

And since from there, since it's reproducible, you've kind of solved the dependency measurement problem. Reproducibility is a very loaded term that a lot of people don't really understand correctly. And you often hear discussions like, oh, this system is fully reproducible, that system is fully reproducible. When we say reproducibility, let's just focus specifically on that. What does that term itself mean and why would you care about it, right? Like let's say you have a system where you compile an application, it looks, it's the same application. It looks the same to the user, but it's not going to be binary equivalent What is the benefit of it being a binary equivalent? But I'll be I start with them

Just focus on the reproducibility term itself Yeah, so kind of think of it as Basic math you have a function which takes two arguments, a and b, and you just do a simple operation of a plus b. And so you let's say you plug in one for a and b is two, that is going to be three. So the that kind of idea of just like, as long as your inputs are the same, the output should be predictable. And so this kind of goes a little bit more back into the language where because we have the hash, we know what things should output like.

But that's only for evaluations. And so we apply this concept to the packages we build. And from there, we're able to guarantee that these packages are going to be able to operate the same and debug the same and do anything the same anywhere and we participate is important because let's say you have a regression with something and you want to track it you do that you bisect it. But what happens when something doesn't match up because it's not really visible.

You could get a false positive of what looks like it could be a problem, but it could be oh, this date changed inside the build hash causing things to change around. You don't want that. So reproducing that to where it's going to be the same in 20 years as it was five weeks ago. Makes that a lot easier. And it doesn't even have to be for like debugging. It could be for like modular management of like some programmers have a way of being able to plug in stuff and sometimes they want

this to order correctly. Being able to reproduce it correctly makes sense there and so it kind of depends on what you're wanting, but it, at the end of the day, it is a concept that should apply everywhere. Right. Yeah. Reproducibility and the value of it really depends on where in the product chain you're, you're sort of sitting, right? Like if you're, if you're in a corporate environment, you know, having a

reproducible builds is more resilient against software attacks because you can verify the build you have is the build that it is supposed to be. Yeah. Especially for like that kind of thing. Or even like servers, like let's say you are on a DevOps team and you have to manage 20 servers. You want it where everything's gonna be the same. Because the idea is you wanna minimize

the amount of variables. By minimizing the amount of variables down, you have a lot more predictability. By being able to predict things, you can then squash bugs easier or easily. You know exactly what's going on. Okay. So we're just going to, I've just been jumping around between different Knicks topics that I'm not really sure the best way to connect these things

together. I've just been jumping around between different Knicks topics. I'm not really sure the best way to connect these things together But I guess let's talk about Package rollbacks because that's a big one that a lot of a lot of systems just don't Have anything really in place to do so like arch you can roll back a package, but basically what that means is going to the package archive repo and then installing the old version of the package which potentially if you're doing something low-level enough could break the entire system but that's not the sort of thing we're talking about here and with the way we've talked about how packages work where they're all stored in their own separate

directory with their own ID and stored in their own separate directory with their own ID and they control their own dependency management. It sounds like rollbacks and it mentioned on the home page here that rollbacks are something that are easy to do. How are rollbacks facilitated? through Nix. So the way you do it is as you're aware everything evaluates and so the inputs, which are your attributes to the attributes that's passed through the recreation, you basically just undo the change.

Like, oh, you have this source that points to like, let's say, oh, dot one dot six and oh, that is broken. When you roll back to oh, that is broken. We need to roll back to 0.1.5. What you do is you just change the source. Then all of a sudden, you have the old version. Luckily for you, if it's in your cache

or somewhere that you can get it from, you don't even have to rebuild it because nothing else changed. And so we actually apply this to Nix OS a little bit further by having multiple generations of your system. Let's say generation 20, nothing's broken. And so you're able to just manage things a lot easily as long as you can work backwards from going forwards. When a lot of people talk about rollbacks on Linux, there's a lot of the the focus right now are on these these

I don't know what term you want to you like using for them these image based or immutable atomic distros where basically you just roll back the entire system and you just have multiple versions of the system installed but Nix is more akin to traditional package management. Obviously it's still Nix's different Nix system, but it's still, it's not like, you can roll back individual things, right? It's, it's still, you're handling packages separately from each other.

Yeah. Yeah, so you can easily just roll back things like that where and because Nix isn't or NixOS isn't really immutable, it kind of actually is because you can't just arbitrarily write to the next store. And so the kind of benefit you get is Nix is only going to touch Nix things. When you roll back an image based distro, you're going to be rolling back a lot of things. You're going to have a lot of downloads. You're just going to you just have a lot more complexity with this.

You can just roll back one single thing and that's it. The layer operation, you don't have to even download that much. It's just simpler. Right, I have heard anytime the discussion of immutable distros comes up, it is like the topic of Nix comes up as well. It's obviously very different from, you know, a Silverblue, but it's approaching that immutability problem in a different way

yeah so like with immutable distros typically people do I don't like the term personally I like image base it's it's a there's no good term for it because there's nothing there's no individual word that explains everything that a silver blue like a distro really encompasses. Yeah, like those kinds of things, they do weird things that certain packages may not like. Like I know system D doesn't quite like having your root file system locked. And sometimes you want to be able to change around your system at runtime. And sometimes you want to be able to change around your system at runtime, especially if you're missing with something weird like X Lord,

because your drivers and stuff like that don't quite always apply. And so the kind of benefit you get with Nix is you can change things without like having to... I'm trying to figure out, explain this with like a locked root Fs, you just can't touch anything. But with Nixos, you can still touch your scene, all that as long as you have the permission.

But if you reboot your changes are rolled back because the system reactivates. So you can kind of test drive some things at runtime, make your fixes, whatever, and an update configuration. And now you kind of locks things in. And so you can have more of an agile, like work around method to try to figure out why is this thing not working. And things generally play nicer since you're not messing with weird file system permissions and stuff like that. It's just you have a single directory that is locked behind a daemon. And that's really it.

Yeah. There's this random comment on Reddit I see where someone described it as iteratively immutable, which I think makes it, well, I, I, I dunno, again, Reddit comments. That's a funny way on the way. Yeah, I Don't know like it's it definitely sounds Like it makes more sense as a system I I don't think it makes sense to go full down the route of things like silver blue like they

go full down the route of things like Silverblue. Like they... They're, like, the approach they're taking is lock file system and then do everything in Flatpaks. Which... Works for a lot of stuff, but... You know, you, if you're on, like, if you're on Silverblue and you want to go and install different drivers, for example, you've got to then start building your own images which you know get and and with that if you want to support weird hardware like let's say our MacBooks

well I mean fedora supports it but that's a little bit different though like if you want to support like odd the horror, like Linux phones or I mean, Android phones in middle of a distro, distros, you're gonna have to rebuild everything. It's just, there is a lot more to work with. With Nix, if it's just, I hate the derivation that's just out of disk image, you're gonna be able to simplify things a lot more.

And so you also get the benefit of it being all in code through Nix. So it's just a lot easier to manage than like 20 bash scripts and weird commands you had to memorize. I mean, Nix doesn't have its weird commands. I was going to say, don't talk about weird commands in Nix. But I mean, Nix's commands are a lot easier to understand because it's Nix build and then you say what you want to build. You can do some extra things like checking how much jobs you want to run and stuff like that. But every built system has that sort of thing, but you don't have weird

flags like to change like debugging or I mean, well, Nix does have that. It's hard to explain. It, it puts those flags behind and easier to understand abstraction. Right. Yeah, don't get me wrong. I like, I think these distros like Silverloo, like Steam OS, they make sense. I think they make a lot of sense for like appliance type devices where there is a set piece of hardware. Like the Steam Deck is a perfect sort of device for something like that. It's not really treated like a, you can use it like a computer, but it's a console.

You update the console when the update comes out. And for certain kinds of people who don't really modify their system, who can get away with doing everything in Flatpaks, yeah, it's fine. Yeah. I think they have a place, but there's a lot of people who think they are going to take

over the entire world of Linux, which I frankly don't see. Yeah, I mean, you can actually do a lot of appliance things with Nix just because it's like, hey, it's having the same build route or like Yocto. It's just a Nix image. You just build it and flash it and you can treat it like your regular immutable system, even though it's a little bit of a different concept, it can do the same thing. But there is benefits of having things like silver blue already exist.

It depends on what you want to do really and what you're comfortable with. Right, yeah, a lot of people may not be comfortable jumping into Nyx. And this, as I was saying earlier, this is one of the common things that comes up with Nyx. We're all going to rehash that topic again, but it is definitely something that comes up quite frequently with Nyx where it's like, oh, I think the idea is cool, but like, I don't really know where to get started with it. One thing I wanted to ask, and this is kind of jumping back to the thing about rollbacks, I was just having a look at the, at the how Nix works page, and it

mentions when you uninstall a package, the package isn't actually uninstalled, it's, it sits around in what it refers to in a state waiting to be garbage collected, which usually is a term that you hear for programming languages. Um, I guess it's just using the term garbage collection here as a way to basically mean cash. just using the term garbage collection here as a way to basically mean cash? Yeah. I mean, there is not really a better word than garbage collection to describe it because you can kind of think of a next next derivation as like a, an object.

And then it's like, Oh, this object is unused. Right. So just clean it up. It's a garbage collection. Right. So just clean it up. It's a garbage collection. And so at that point when you unreference a package, if you have automatic garbage collection or you run the next collect garbage command, it's going to look for every single derivation that is unreferenced and it's parents. And if those are unreferenced, it's just going to remove them because why is it there if no one's using them? Yeah, fair.

Um, I don't know why this didn't come up before we were talking about rollbacks. why this didn't come up before we were talking about rollbacks but also atomic upgrades this is another another important thing these these are the distros attempt to resolve as well and that also seems to be a thing here as well I've heard of atomic upgrades but I'm not really sure It mentions it literally on the the website Nick, so I assume this is something important. Let's see, what is atomic? Throwbacks. Perfect.

I've heard this... No, I don't want the Django stuff. This is not the direction I thought it would go. Yeah, I mean, I probably understand the concept if I could figure out what atomic rollbacks means. Or like atomic upgrades. What it is saying here, since Package Management Operations never overwrite packages in the next store, but just add new versions in different pods, they are atomic. What a great explanation. Jesus Christ, that's...

Maybe someone should rewrite that one. Yeah, I'm not really sure. So during a package upgrade... Atomic. Hold up. So during a package upgrade, there is no time window which has some files from the old version and some files from the new version, which would be bad because a program might will crash if it started during that period. Ah, now I understand what it's meaning. So the way Nick fetches things and builds things is it doesn't expose them until it is there. is it doesn't expose them until it is there. It's like, you don't want to be using Firefox when it's halfway downloaded, it's not gonna start.

So it puts it into some sort of limbo. And then once it's there, you have it. Yeah. Yeah. I'm not really sure what it means by atomic in that concept or context. Right, right, right. I'm happy that I found a term used in Nix that managed to stump you. That's a fun one. Yeah.

Cause also atomics are a concept in systems programming. Sure. And I'm not sure if it's meaning like, atomics as in like atomic instructions and like new text locks. And it's like, right, right. Okay. It could mean two completely different things there. Yeah. Right. There's a lot of tech and programming terminology which overlaps

with other segments, which mean entirely different things. For anyone who might not be a programmer, a great example is the common usage of the word theory and the scientific usage, where the common usage of the word theory and the scientific usage where the common usage basically it means it just means guess like you it's like oh i have a theory that aliens might have built the pyramids i don't know um the the scientific definition is basically a i i don't remember the exact dictionary definition. You have like a well-formed understanding. You have something that is backed by evidence that by all accounts seems to be what is happening.

That I guess is a bad way to explain it, but guess the point across? Yeah, there's a lot of word usage in tech. Immutability is a great example of it, where immutability in one sense means unchanging, but we're using it to mean these systems which are temporarily unchanging, which is great. Yeah. It's also a type of variable in Rust. Yes, that's another fun one. Oh, God. I hate the tech world sometimes. Oh, it's fun.

Oh, it's fun. Well it's fine when these terms sort of evolve independently. It's when the terms get reused where it really bothers me. Like, especially when you, like again, going back to what I said about immutability, where the term was already around and people were like, ah, this is good enough. Let's go with that one. Especially as like standards and things changed, like I believe there was a bit of this problem of things changing from the Unix side of things to more of a Linux style of things, kind of as things evolved and people moved away from

Unix, like I'm pretty sure there's concepts there that got reused and kind of lost their meaning. It was like a good one's a TTY. No, a lot of people are using a teletype interface, the interface with a computer. They're using a graphics card and a keyboard and a monitor. We still call that TTY.

Yeah, the terminal emulator is in the same sort of... Terminal emulator and TTY are technically entirely interchangeable terms in the way they're currently used but Like they again it's like they do actually have very distinct meanings. Also my camera is just going out of focus Yeah, I noticed that too. Yeah, like with TTYs we all use traditionally a Pseudo TTY where it is not really it's a TTY emulator if you want to be actually explaining what it is yeah it's usually it meant something like a VT100 where handles all the fancy askies or antsy control stuff and asking characters and stuff like that or it's like yeah but

it's one of those stupid word reuses that's lasted over like 30 years yeah but at this point like the sanction doesn't even matter because no one again no one is using a physical terminal and physical terminal anyway so like any any physical terminals are at this point just a monitor with a keyboard plugged in as well. Unless you're doing something weird like firmware development or building, doing that kind of hardware usage, but still you have a serial chip that does the communication and it, you still use a terminal emulator at that point. Like something like GUScreen that is still emulating a terminal. Even though it's a little

bit of hardware mixing, it's still emulating a terminal. So going back to Nix for one moment, So, going back to Nix for one moment, this is not something which the regular user is going to, in most cases, at all be affected by. Nix and multi-user systems. Most people don't have a multi-user system. Like, you're just the one person who's system and that's it. But I did see in here, and I think with what I've heard so far, this makes sense how this works, but it mentions that Nix does have support for multi-user setups as well.

Yeah. I mean, you can do that with like annual, the Nix distro, but with Nix, you can go a little bit further because like earlier mentioned, you can manage your home files and so it's not really built in the next OS specifically or next itself. It's a separate project that you do your own kind of style.

It's called a home manager. It is a way of to manage your. Home directly basically. And you can build up a method and a workflow where you can manage like eight different users that has a different environment, different files, different text editors, and only those users will have access to that. So it's like you have a user called Alice and then you have a user called Bob.

One uses Vim, the other one uses Emacs. One could try calling the other and it wouldn't be in their path. And one could have a picture of a bird as a background picture. And the other one could have like a dog. And they're not going to see each other's files, but they could look at the dog files

and kind of see what's going on. But I mean, it's a more advanced top concept of being able to manage multiple users and something that is actually great for the community provided builders. We have like 100 users on the different builders and everyone just has their own setup that's separate from each other and And we just managed all the minutes, just a single edition of a new line. Add your SSH key. You've got access.

Okay. So I wanted to ask you about sort of your history with Linux and your history with Nix, cause you mentioned you've been doing this for a couple of years now. Um, but when did you start using Linux and when did you eventually find your way to Nix and like what, what actually attracted you to it? So originally I started, I think it kind of a bit more of like me starting out as a programmer. So when I was 11, I wanted it kind of been more of like me starting out as a programmer.

So when I was 11, I wanted to build a website. This was back in 2012. Most website builders as far as I am aware were paid and it's hard to install. We need to have like admin access on a windows laptop to just install arbitrary programs. So I took out notepad and I learned HTML. Uh, sometime later I learned JavaScript, CSS, and I learned Python, Ruby, Lua, all that.

Adventures are doing getting into like, oh, what's Linux? And I was in Scouts at the time, and my Scoutmaster, he used to be a, he might still be, I'm not sure, a administrator for a school district. And so he got me into the idea. I started out with a boot into, I think it was like a boot to 12, 11, whatever, somewhere around that time. Okay. This is like 13 years ago. I don't remember everything. And let's be from there.

I started learning things like Java and how to make Minecraft mods, how to use lightweight Java game library or game library to make like you open GL stuff, that kind of stuff. Then eventually, I don't know how I was like, I want to build an operating system. And at this point, I was in middle school. Aha. So time.

Yes. So I found the OS div Wiki and I got a hello world. And since then that's been a large thing of what I've done, is being able to do systems programming and doing stuff like learning assembly in a week and learning all these different things for systems programming. And eventually I switched around random distros,

like I used Fedora at some point. Then she, I reached high school, I was like, I've been using Ubuntu for however long. It's time for me to use Arch. And so, the morning before school, one day, I think this was like sophomore, I was like, it's time to install Arch Linux.

Big mistake. Because my first period class was writing. And the first thing we needed was Google Docs. And guess who didn't have network access? I forgot to install WPA supplicant so I had a pullout in Ethernet cable and get that all set up and figure out how to get networking working and all that.

And eventually a few years later I was like, oh, I heard about Void Linux. I'll try Void. And then at that time, I'd been living in Oregon my entire life. And so we kind of get into 2022 now. And I moved down here for family reasons to Southern California.

And the thing with the US is every state is kind of like its own country. Right, right. And so things are different across states. And the problem I ran into was the power at the new house is a little bit different. OK. To the point that my overclock would kill my system. That's a new one. So guess who's file system corrupted?

Hey. Hey. My file system corrupted and I'm like, uh, everything is gone. So I was like, I've heard of this Nixestro called NixOS. My current drive is not gonna be recoverable. The ext partition is completely screwed up. There's no chance of So I got the ISO, I installed it, I had a basic Linux system and then I was like what more can I do and I just kept on learning, kept on figuring things out. Eventually I was like oh this package called lens, which is for Kubernetes stuff is out of date. No one else is updating it. There is one maintainer, but he hasn't touched it in like six months.

I'll figure out how to update a package. So I did it. I was like, this other person isn't going to maintain it, so I'll pick it up as a maintainer. From there, I did other stuff. I eventually picked up Zig again. This was two years ago now. Then I was like, oh,

this new version of Zig needs a newer version of LLVM that's not in its packages. Guess I'll package it. So I built it, totally pressed it. Okay. I got that done. I say run some other stuff, run some other things. I was like, oh, I need another version of LLVM.

I'll update it. But now we're getting to the point of NixCon North America from 2024. And the person who was maintaining it mostly, there was five people in total, he wasn't touching it. He got, didn't have the time, things happen with maintainers like that all the time. And so I'll maintain it now.

And through there, I kind of did the work of cleaning up LLVM because fun fact, LLVM isn't just LLVM. It has a million things to it. And so we've been packaging LLVM versions since LLVM 12. And LLVM releases every six months. And so we had like each of those had their own version of each package inside of them. So you have like a hundred files and there's like a million duplicate lines. So I did the painstaking thing of removing every single duplicate line

and folding things together. So there is a common entry point for each package and each version. And so I cleaned up LLVM. And then from there, I was like, I want to do more. What else is there? Oh, there's all these packages that are maintained. I'll pick them up. So then now I maintain SC Linux. I maintain Flutter. And I was like, oh, I want to build the Flutter engine

because I want to embed Flutter into a Wayland Compositor. It's like, oh, I'll figure out how to build Flutter. Turns out Google sucks at packaging. They have this thing called DeepOptTools, which calls their own version of Python that they have pre-built from a Go binary. It is as cursed as it sounds. And I built it and I made it reproducible.

And so I maintain Flutter and this is why I believe they recommend is it they recommend a snap package or something? I know they have a package for it. The kind of expensive way you download it is you just get clone the directory and then or get cloned or get a whole bunch. And then some project then. Then you just call the shell script, which downloads from their binary. The thing is Google sucks at packaging. I can tell.

Yeah. because Google sucks at packaging. I can tell, yeah. But yeah, from there I got Flutter, the Flutter agent package. And then I was like, oh, we have the standard environment to provide things like the C compiler, your core utils, all that. No one's maintaining that. And so now at the point of October of last year, I was like, oh, I'll pick it up.

Now I maintain standard programming along with farther other people. At some point, I got a commit bit, and so I can break NICs for everyone else and stuff like that. Then eventually, because of the other LLVM stuff I do, and break nicks for everyone else and stuff like that. And then eventually, because of the other LLVM stuff I do, like, oh, I want to get Clang running inside of UEFI. I got a LLVM commit bit and all that. And we're up to today now.

Having that kind of power is fun. A friend of mine just got employed with KDEV and was given master branch commit rights on KDE. Ooh. Yeah. And the thing is in Nix Packages, we kind of want to limit how much the commit bit can do, but the problem is, it was like, no, committers can do a lot. And so yeah, committers can do kind of abuse things, but everyone kind of doesn't because we're good. That, that story you had about installing Arch just before class. I've brought this up on the podcast a number of times.

This is very reminiscent of the stupid way I did it. So I was in my second year of university at the time. I installed it like the day the holidays ended. So I was in class with a TTY Just getting th- trying to like connect to the university network For the entire class. Now the fun part about the class is I was in a cloud development class So, you know, it's kind of on brand. I'm using Linux. We're doing we're doing Linux things But I didn't get much I did not get much stuff done during that class that first

first day or the first couple of days after that because there's a lot of stuff that I Just didn't really think about there was some software. We needed to have that. I didn't really think about so I had to set up VMs for that. No, for other classes, not for that class. Um, I had like a, a, um, what do you call it? Like a, uh, a UI design class we needed some software for, and we needed to use something specific because they wanted the project file for it, which is always fun. Um, so I, I very much know that story myself. Don't install art or any, any system you're not familiar with just before you need to use the system.

Bad idea. Yeah. And the fair thing with my situation was, oh, it's a writing class. You would think you wouldn't really need to do stuff until they're like, Oh, hey, open up this thing in your Google drive that I shared with you. It's like, Oh, I don't even have networking working. I don't know how you didn't think of that one.

That's crazy. That's such a, that's such a thing to miss. So the thing, I think the thing was like WPA Supplicant was installed. But it wasn't set up and I didn't have Network Manager and WPA Supplicant isn't great to mess with because you have to remember the commands inside of it and great to mess with because you have to remember the commands inside of it. And it's just a pain in the butt to mess with. Right. Right.

And so I was like, I'll just grab an ethernet cable and just plug into the wall. Yeah. In my case, I, I couldn't work out how to do the network verification because they, like, they had like a, a thing on their thing on the university site like what like what do you call it the security it needed to be sent to or Yeah gateway Yeah yeah yeah and I could not work out how to do a lot of the self so I was just trying to like how do we do this luckily I did know someone who was messing around with Linux

themselves and they could help me with it, which is nice. Um, again, don't, I don't recommend doing this. Get things working beforehand. Yeah. Don't rush installing a advanced Linux distro. It does make you learn it quickly though. Yeah. It makes you go in a hurry.

It's just maybe not the, maybe not the best way to handle class though. Yeah. So you mentioned eventually making your way to Nix and starting to manage packages, but what about Nix was it that attracted you? Because you mentioned your file system had corrupted, but I'm not really seeing the link between those two points. So my thinking was, well, the system crashed and if all my.files is on GitHub, it'd be a lot easier to set up because I just do a single command and just get everything done. And yeah, I mean, that's how I was able to install into other systems I have so easily was my setup was is already to go.

It has my desktop environment. It has my shell. It has my text editor. It has Git prepared. And so all I have to do is just partition. Do a couple of things with maybe like the graphics drivers and partitioning, and then just install and I could bring up a new system in like 10 minutes and then spend the rest time just waiting for it to fetch and build. Okay. Yeah, actually makes a lot of sense then. Now you're not just a package maintainer. As you mentioned earlier in the show, you also were involved in the release management

of 2411. So how did that come about? That's a good question. I don't remember. When you start with a, what does a release manager do? And then we can go from there. So it's kind of in the title. You managed to release. So basically you are like, yeah, you're like, Hey, this is going to be the schedule.

This is what's critical. Let's get to it. Let's do all this stuff. Make sure all the, the branches are set up. Uh, stuff like that. You also get to pick the icon for the release. You get to pick the next releases name, which actually with, uh, 25, oh five, since I was really measured for 24, 11 11 I've got to pick 2505 I named

it warbler and that's actually the name of the street I lived on in Oregon hmm so it's kind of good and warbler is actually name of a small bird that I believe is how I came to it because things are named after animals so it's like oh it's gonna be a little bit of an Easter egg that says hey I I did the previous release oh yeah you're gonna do all the kind of things you're basically sort of the BDFL for the release right you do work with the previous release manager but they're there to kind of like give guidance and be like, oh, this thing you might have forgotten about. Or it's like, hey, I have this question for you. What do you think about this stuff like that? It's a very like kind of like mentor mentorship kind of position, but a lot of the

stuff is already on the release management wiki, right and so We're all just copying pasting and kind of just like going through that so it's pretty much just making sure that everything is in order and Yeah You said you set the timeline for the release I put it over so it wouldn't interfere with Thanksgiving because it's hard to push out a major release when there's a holiday right right sure That's fair. Yeah. So, OK. That's pretty much it. Yeah. What made you?

Yeah. What brought you to that position? What made you want to do that? I do not remember why. I think I was just like. This seems like an interesting to do. So then I kind of was like, I want to do this now. And I did it. That's kind of just how it happened.

You know what? That's been my entire life is just like, Hey, I want to do this thing. I'll do it. Yeah. Hey, like I've had people that give me these like big long spiels about like, this is like, I had, I had Nate Graham on here yesterday, and he went on like a 10 minute rant that's the, for anyone who doesn't know, this guy writes this week in KDE. He has, um, what is it? Adventures in KDE, I think is his personal blog. Does- he's on the KDE board. He went on like a 10-minute rant about how he joined the KDE project because he felt like

this was like a- like a good thing for the world. We need more open source software. We need- we need good open source software. We can't have- we can't have these major companies screwing people over and then you're here just like I did it because I did it. Yeah. It's a nice change of pace, I'll take it. I mean, I couldn't think of any other reason of what it would be. Cause I do not really recall.

It's just like, Oh, this seems interesting. Just do it. Like the experience was there. So you wanted to see how it went. Yeah. Yeah. Okay. You'd already been like fairly active in the Nick space as well.

Like you'd be, how many packages do you maintain? Um, do you want to count every LLVM version in the sub package? If you want to. Okay. So there's LLVM 12 to 21. Each of those has, uh, let's see, they're the Clang, LLVM, Uh-huh. Each of those has, uh, let's see, they're the clang, LLVM, fin tools, compiler RT, libc, libcxx, openMP, that's at least seven, MLIR, LLDB, there's like 20 things. So that's already, well, like eight, nine versions times 10 packages. So that's like 90 there.

And then you have, uh, the, like the five flutter versions, and then you have the five, uh, like different, uh, packages for SC Linux and then the Zig with its three versions. We have Zom-Ninx. Then we have what else is there? What else do I maintain? Oh, Lens. The first package I picked up. So I managed like over 100 probably. I'm on Repology so if you could just plug in the email that I have on GitHub. I always forget this website exists. I don't want to do it right now. I'll check and look afterwards. If anyone wants to go look it up and let me know in the comments, do that. Yeah.

Yeah, it's a lot. Oh, and technically the standard environment is its own package. So that's another package. Okay, so the answer is a lot. Yes. So to break your system. So since you're already doing all of that, it's like, Hey, this is sort of a, a natural progression might as well just see how it goes.

Yeah. That's kind of how things seem to be. I think, I don't know. Yeah, that's kind of how things seem to be, I think. I don't know. So you've mentioned earlier that Nix has been getting like more traction, more popularity. Where do you see that going? Right? Because like, obviously, the current direction that we have for handling dependencies across different systems is like Flatpak. Like this seems to be the main way that things are being done. Snaps, Canonical wants them to be, but not outside of Ubuntu.

And App Images, some projects have them, some don't, but Flatpak's clearly the thing that the FOSS space is like rallying behind. that the FOSS space is like rallying behind. Um, but where do you see, where do you see Nix fitting in here? And where do you really see Nix going? I see. I'm not really sure. Um, it's kind of all over the place. That could be, there are a lot of different ways Nix could go.

I could see someone potentially riding like something kind of like bottles, but it is like a flat pack kind of thing where it's like, here's your store of like, like your marketplace, but it's all Nix stuff that you can easily match with there instead of having to manage like your stuff. And then you just have that on top of like a Buntur or whatever. That could be something someone makes. Well, I see, I see Nix was kind of just sticking around like Arch Linux where it's like, hey, it exists.

It's the advanced distro that everyone's gonna probably try out at some point. Right. Okay. Okay. Um. So I don't know if you know anything about it. If you don't, we can just move past this. But anytime the topic of Nix comes up, there's also mentions of other projects like the GNU Geeks project, which I understand try to serve a similar function. I don't know if you know anything about that though, and can really comment

on that. I know a little about Geeks. I don't know how to say it. People have told me it's Geeks. So that's what I've been going with. It could be because you're Australian, I'm American, different accents. I don't know. It doesn't matter. I always say, I always say GUICS because that's what it looks like it says.

That's what I used to say when I complained about it. Well, I don't know. You're gonna stop me from coming. But yeah, from what I've heard, GUICS is a fork of NICS. That's as far as I know. I know it's like that, but trying to shoehorn into like gen two basically.

I don't know. I've never used Civic I was I wasn't sure like if you know any man like it if if not, we just move past that That's so good. I it's been thrown around a lot. I've seen about it. Mm-hmm. I've looked it up Never played with it. Sure I've looked it up, never played with it. Sure. Yeah. Okay.

That's understand. I know, I know, I know about it. I don't know enough to like ramble on about it. So if people may be interested in the next project, not just as like a user, but somebody wants to get more involved in the project, they maybe want to start like managing packages or helping out with documentation, things like that. Um, what do you think is an area that needs the most support right now? And where can people go to start helping out with that? So two places, as always documentation always needs improvement.

Two places, as always, documentation always needs improvement. That's probably true for any project out there that's large. Then just maintain a ship. Nix packages at this point is like 140,000 packages. It is essentially the luggage package repository for systems packages out there. We have Python packages, we have node packages. Having people maintain all those is difficult. There is a lot of people like myself

who maintain a lot of duplicate packages or even just like a lot of different packages. And the problem with that, it kind of strains out a lot of people. We only have like, last time I looked was about a year ago and it was like 230 committers and there's a lot of people involved in Nix. We have a lot of people involved in Nix. We have a lot of PRs. And so just reviewing packages, helping with documentation, picking up packages that haven't been touched in like two years or hasn't or is out of date, just whatever you can see that,

like you think needs improvement is always welcome and it always helps out. So if somebody wanted to get involved with that, um, what would they need to do? Where would they go? Um, I would think, uh, the Knicks OS matrix space, cause that's where everyone is at, there is the unofficial discord, but that's unofficial. I'm on there. A few prominent people like, uh, Tom Baric, he's another committer and a previous release manager.

A lot of people are there, but the matrix is like the centralized place to go. And then you can like coordinate with other people. Right. And then you can sort of ask about what need, where, who needs support, what needs support, where things are lacking and sort of directors of, or I guess even if you don't have like a set thing, you'll like it. Obviously we're going in like filling in gaps is important, but even if you just want to like get involved and just like, maybe you notice maybe 140,000 packages, maybe there's

something that's missing there and you just want to put it up there. And then no one's done before. Obviously that's more maintain a ship, but there's still a lot. There's a lot of things there. But like, there's no reason why you have to just fill in gaps. If that's not a thing that is interesting to you. Yeah. There's a lot of people can do.

There's a lot of open issues that even if you don't maintain something, you can look at an issue and try to help resolve it to get it closed. Just whatever you feel like really is possible. There's a lot of work there and not as many people as you would expect for the amount of work, I guess. Yeah. And it's actually kind of easy, I think, to get involved with Nix because it's a monorepo on GitHub.

All you need to have is a GitHub account. Practically everyone in FOSS has a GitHub account. Uh, you just need Nix itself. You don't have to be running NixOS. You just need Nix and a GitHub account and some free time. And then just do something. Yeah. I'm looking at the, um, the Nix repo as 3,200 open issues.

Yeah. Look at how many commits we have. Wait, where's the number? It's gonna be on the... Sorry, I had the... For my overlay, I have it squashed down into a miniview and disked, then GitHub was hiding it. 19,703 on Nix itself.

Yeah. Yeah. And on Nix packages, 779,000. Yeah, we have a lot of activity going on. And there's basically a commit like, or a merge happening like every 30 minutes. How does Git behave with a, uh, with a commit history that long? Does like, does if you run the history command, what happens? Oh, uh, so do not run Git log or Git history. Yeah, yeah, yeah. Because it's gonna take forever. Especially do not do it when you have like one gig of RAM.

I don't know what you'd be doing with one gig of RAM in 2025. But do not do it unless you are ready for your CPU to struggle on a single core. Because that single core is just going to compute everything for the past like 20 years that repos existed. That's fun. It's probably, yeah. I'd imagine the Linux kernel probably has the exact same problem there, where it's like never never never touch that command. Yeah, so does LLVM. I think LLVM is at like 1.2 million commits. Jesus.

And I think Linux kernels at like 12 million or something like that. Those two repos have several times more commits in these packages. Does Git have the option to do history paging because it should? Um, no, I think it computes everything and then outputs it. Because because the way Git works is the parent commit affects the revision hash of the previous commit. So it needs to compute the previous to get to the next. I don't know how Git commit exactly does that in a way that doesn't slow down every time you make a git commit, but there is just doing a git log of everything.

Also committing still works fine. You're not waiting 30 minutes for that. No, it takes more like five seconds. Okay. I know in the early days of Git it was really, really bad with Monorepos. And this is why there were a lot of competitors that came out around, like very shortly after Git. But Git got better at that over time, it seems. Yeah.

And we need faster processors now. Sure. Yeah. Yeah. But I remember, I think it was actually around like, yeah, Mercurial. Facebook, they internally use Mercurial because back when they were starting up, Git was unusable for mono repos. And the solution that was being suggested at the time is just don't just break it up into smaller repos like no we're not going to do that

so they yeah they just went to something else instead because it worked better yeah but i guess as the linux kernels gotten bigger as well they kind of had to address those problems because you know it's a forest problem those problems because you know it's a forest problem. Yeah so I think we've pretty much covered everything I wanted to cover. Is there anything about Nyx that you wanted to bring up still? Kind of well so I know you have talked about the System 76 Thelio Astra, right? Uh, the Arm desktop that System 76 built. Yes. So one of the things with Nix is when you rebuild the world, rebuilding everything, you need a good processor.

rebuilding everything, you need a good processor. Because you're rebuilding everything. And that sucks when you have like four cores. Even 10 cores isn't that great sometimes. Well, this is where, like AMD Epic or Ampere is very useful like AMD Epic or ampere is very useful because those systems have like 64, 80, 92, 128 cores. So it's like you have exponentially more compute. And so Nix is great with that because you have two ways of being able to manage your job or like your builds. You have the cores flag and the jobs flag and the cores that takes how many cores like cores that make job is gonna run inside of a derivation and the job is how many next derivations to build at once. And with Ampere, you can just build it a lot

on a single system. It is exactly how we do our CIF. We actually have a few Ampere systems that we just plug in to our CI server and then build. And fun fact, I have an Ampere desktop in its own case as my desktop. Oh, wow. The problem is I'm on AMD GPU. And one thing AMD is known for is not supporting ARM.

is not supporting ARM. And you've also covered the desktop environment. I run it. Guess what desktop environment I run. Very popular. Similar vein to Ampere. It's an alpha. to ampere. They very popular. I would like it's an alpha. Oh, right, right, right.

Yeah, but so I run cosmic on ampere and because of an AMD GPU, it doesn't work. Uh huh. Uh-huh. So I have to debug a graphics card to get a rust built death home environment to work. How's that? How's that going? How's that gone? Very little progress because I have no time. Right. Fair. So what do you use instead of Cosmic so you have a desktop?

I use my laptop. That is an awesome... So the way I do things that I've been doing them since I've had ampere is. And that I've been on cosmic, I just run cosmic on Apple M1 Pro. I then SSH in my desktop. And then I do things like that. I guess, look, just pretend like your intention is to run as a head, I can do many jobs at once and be able to do multiple things at once while my computer is doing things that multiple, just a lot of work at once. gaming. If games work and I figure out a way to run a box 64 on ampere but the

problem is I do this little thing you may not be aware of it's called page size. The memory is allocated paging and And Apple Silicon uses a 16k page size. On AMP here, I have addressed it to 64k, because higher page size, less many pages you have to allocate for a single large allocation, more performance. The problem is when you come to emulation. Emulation is like a 4k page size, which doesn't map into 16k or 64k. That means no games.

And you know how you fix that on a Thaie? How do you fix that on a thigh? How do you fix that? You run a VM using something called move VM, which runs a sick, it runs a 4k page size arm VM on top of your 16 or 64k page size system. Okay. They're running and it passes your graphics through. It's built for not NixOS. Not NixOS. And because Atsahi requires a special graphics driver that is their fork of Mesa, I can't test it.

Unless I fix the graphics card to work with Cosmic on my Ampere desktop, and then I finally could get moviem to work which and I'll be able to finally get boxxx34 to work which finally means I can get steam it's a lot of extra work just to get video games to work and the only reason why I want to do this because I want to game on Ampere Arm. That would be cool, don't get me wrong, that would be really cool. The only thing that runs right now is Minecraft. Because that's Java. Right, and... yeah. Java runs on 6 billion devices.

So yeah, I was gonna say, what's the numbers? Is it six billion? I don't know what like, sorry, this is random side tangent. Is it, wait, is it three billion? I don't even know. I don't know what the number is supposed to be. As far as I remember, it was been that little tagline when you install Java, it's runs on six billion devices or whatever. Who knows how they count it? Don't worry about it.

It doesn't matter. Don't think about it. It's Oracle. They pulled all their six, just their six vendors and customers so um hopefully you get that working that would be that would be good hopefully cuz then that will mean other people could run steam on arm on the not empty I saw he yeah on more sensible arm chips that people might actually have well um I hope that goes well uh was there anything else you want to mention

or can we just start signing off there? I can say one quick thing. Okay. I am trying to get Clang to run inside UEFI because you can build your Linux system from your firmware. Why? Because the joke is that UEFI is already its own operating system with how much it implements. is already its own operating system with how much it implements.

Did you know UEFI has user accounts and multi-threading? That makes sense. Have you started this project? Is it progressing? I am waiting for some Googlers to make some. Approved or approvals from them. And the thing with Googlers is they're also busy. That's fair. Yeah, that makes sense.

But hey, at least the Fushia people also want this. So it's like, if they want it and I want it, it'll happen. So maybe in five years, you could build your Linux system from your firmware. So stupid. That's so stupid. I love it. But more performance. I guess. You don't have the overhead of an operating system. You only have your firmware then. You only have your firmware then. Mm-hmm.

That's cool. I do like that. That's really cool. Um, well, that's a high note to end on, I guess. Yeah. Where can people find you if you want to mention your stuff or if you want to get involved in NYX Where should they go to? I Would say the NYXOS matrix There is nyx.dev There is is all that stuff linked on the NYXOS website

I think it's under nyxos.org slash learn I think it's under nixos.org slash learn. Okay. And then people can find me on Twitter at Ross computer guy. I am also under that same handle on GitHub and practically anywhere. If it's not the computer guy and you see a profile picture that looks like me, then it'd be Ross computer guy. So I, I'm usually everywhere. Like this guy, Macedon, Reddit, my Reddit account actually a different username. It's u slash spaceboy Ross, but that's Because I made that account like 10 years ago and you can't change names on reddit

Really? Yeah, once you make a username it's locked Huh, you cannot change yeah That's dumb. I'm honestly I'm surprised they don't charge for that. Considering Reddit I'm surprised. Honestly the fact you use your... Or use the coins or the gold. Hmm. Well the fact they don't charge I have a feeling there's something really wrong with the infrastructure where they can't change it. Um, anyway, uh, nothing else you wanted to mention. That's pretty much all the stuff you want to direct people to. Yeah. Also. Yes. I didn't want to mention it the entire time, just to, just, just because it's going to bother people. Um bother people um yes there is there is a duck in

the background yeah the duck vtuber anyway um my channel is brody robertson i do linux videos there six ish days a week i've got the gaming channel brody on Games. Uh, I may have finished Stranger the Paradise by the time this goes out. May not, I don't know, we'll see. I'll also be playing Portal 2, which is probably gonna be funny, because I've never played it before. Yeah, I've actually never played- Oh, I have! Yeah.

It's fun. Well, okay, I've done the Portal 2 co-op. I've never actually played the single player. I've played the single player, but never portal to co-op. I've never actually played the single player I've played the single player but never played the co-op That's probably the more normal way to handle it I've got the react channel that is a Brody Robson reacts upload clips there from the Streamers so check this out if you want to if you want to see the video version this year in the audio version go to YouTube at tech over tea the audio version go to YouTube at tech over T

The audio version is available on basically every podcast platform. There is an RSS feed on Spotify. We do have video as well If you're one of those people like Spotify video for some reason, um, yeah, I'll give you the final word What do you want to say? How do you want to sign us off? What do you want to say? How do you want to sign us off? My cat will say bye. Aw, I should have mentioned that earlier. She'll hear the entire time.