WEBVTT 00:00.000 --> 00:12.000 Thank you, everybody, can everybody hear me find their sounds like it, it's kind of echoing 00:12.000 --> 00:13.000 right here. 00:13.000 --> 00:17.760 But yes, I'm going to be talking on building the future, understanding and contributing 00:17.760 --> 00:23.360 to immutable Linux distributions, and I'm going to be, there's another bison, and I'm 00:23.360 --> 00:29.960 going to be talking about four different immutable Linux distributions, those being vanilla 00:29.960 --> 00:38.240 OS, Fedora Silver Blue, NYXOS, and RDE in addition to the title topic. 00:38.240 --> 00:42.880 So a little bit about me, as I mentioned, just a few seconds ago, my name is Jorge Gomez, 00:42.880 --> 00:44.840 but I'll repeat that. 00:44.840 --> 00:50.440 And my handle online is J-Guard, so if you see me rambling on IRC, you might see someone 00:50.440 --> 00:52.520 there called J-Guard or something like that. 00:52.520 --> 00:59.700 I'm a senior software engineer at Recondigital, we're a small consultancy providing software 00:59.700 --> 01:04.260 services to the United Nations and other clients. 01:04.260 --> 01:09.980 In a past life and current life, I've been a musician, composer, and sometimes a dancer, 01:09.980 --> 01:16.180 I like dancing in the hop, but I've also had a traditional jazz group playing like 1920s 01:16.180 --> 01:21.780 music for over 10 years, and that's something I've really enjoyed doing. 01:21.780 --> 01:27.460 I'm also an immutable Linux contributor and chronic distro hopper. 01:27.460 --> 01:34.420 I've contributed to GeekSystem, I have nearly 700 commits to GeekSystem, and I have 01:34.420 --> 01:36.900 commit access to GeekSystem and RDE. 01:36.900 --> 01:43.860 I've also contributed packages to NYXOS and updated packages and things like that. 01:43.860 --> 01:51.060 I also started a small community to work on Geek's related projects called Where is everyone? 01:51.060 --> 01:54.940 And for more on that, check out Where is that social on the Internet. 01:54.940 --> 02:00.860 We like to just work on Geek's related projects, but sometimes we work on random things, 02:00.860 --> 02:04.900 kind of like the bison that you saw there. 02:04.900 --> 02:11.260 So raise your hand if you've ever worked Ubuntu, I have definitely, okay, that's a lot 02:11.260 --> 02:15.900 of hands, a lot of people have worked Ubuntu. 02:15.900 --> 02:17.900 Have you worked it more than once? 02:17.900 --> 02:24.380 Yeah, I don't want to, I can't even remember how many times I've worked Ubuntu, okay, 02:24.460 --> 02:30.940 raise your hands if you've ever worked Ubuntu, raise your hands if you've ever worked Ubuntu 02:30.940 --> 02:37.660 within like the first 20 minutes of working Ubuntu, okay, raise your hands if you've 02:37.660 --> 02:48.380 ever worked Fedora, okay, raise your hands if you've ever worked arched by the way. 02:48.380 --> 02:55.340 I definitely have worked arch at least twice, maybe more. 02:55.340 --> 03:01.980 Yeah, so one of the main value propositions that in mutable Linux distributions provide 03:01.980 --> 03:04.060 is that they are a work free. 03:04.060 --> 03:08.460 In the sense that if you mess anything up, you can always roll back to a previous state 03:08.460 --> 03:11.820 in which things are as they once were. 03:11.820 --> 03:17.180 This is possible through the concepts of immutability as conceptualized and applied 03:17.180 --> 03:19.740 to operating systems. 03:19.740 --> 03:24.300 So traditionally operating systems were mostly imperative and mutable. 03:24.300 --> 03:29.020 You'd change the state of the OS and there would be no way of going back to where you once 03:29.020 --> 03:33.900 were with regards to software provenance and system state. 03:33.900 --> 03:38.860 So the key definitions that I'm using to define an immutable distra are that it has an immutable 03:38.860 --> 03:39.860 core. 03:39.860 --> 03:44.140 And by the way, now I'm going to mention that immutable is a bit of a misnomer in the sense 03:44.140 --> 03:50.620 that it means the entire thing is not immutable. 03:50.620 --> 03:55.020 If that were the case, you wouldn't be able to do anything because everything would be 03:55.020 --> 03:56.020 read only. 03:56.020 --> 04:02.620 But it's primarily core system paths usually owned by root that you want to not change 04:02.620 --> 04:04.020 state. 04:04.020 --> 04:10.500 So those things are immutable in that sense, but immutable is also a consortium of things 04:10.500 --> 04:12.940 that make an immutable distro. 04:12.940 --> 04:17.780 What it is, that brand, that idea of the things that an immutable distro or that brand 04:17.780 --> 04:20.500 is looking to provide. 04:20.500 --> 04:24.300 So the other thing is that usually they promote isolated developer environments. 04:24.300 --> 04:30.220 In the case of the first two distros, I'm going to talk about those are OCI container environments 04:30.220 --> 04:34.780 that, so instead of they want to promote, you're getting into a container and they want 04:34.780 --> 04:37.180 to make that easy for you. 04:37.180 --> 04:40.660 So you want to do all your hacking there instead of installing stuff into the base of the 04:40.660 --> 04:44.500 system, although you can also, but it's encouraged. 04:44.500 --> 04:49.580 Different workflow is encouraged in the traditional, mutable OS workflow. 04:49.580 --> 04:56.460 Also there is this concept of animosity, which maybe you're familiar with get or databases. 04:56.460 --> 05:00.380 But in the case of operating system, animosity means like, for example, if you make a system 05:00.380 --> 05:05.060 update, you want to make sure that you're able to make that whole update and you're 05:05.060 --> 05:11.180 not left in some partial, partially updated state, otherwise being in the box in the 05:11.180 --> 05:13.500 box zone. 05:13.500 --> 05:19.220 So we need this animosity in order to have the confidence to do updates. 05:19.220 --> 05:25.140 And that gives us automatic updates also, which we, um, federal or core OS was one of 05:25.140 --> 05:27.300 the early pioneers of that. 05:27.300 --> 05:33.180 And then with this animosity, with these atomic feature, then you get this really 05:33.260 --> 05:39.420 cool feature called Robax, which allows you to basically go back to the previous state 05:39.420 --> 05:45.180 that your OS was in, so imagine you apply some update to your system, you're in in the 05:45.180 --> 05:51.380 board area, and now you're like, oh, shit, and you could just basically go back to 05:51.380 --> 05:57.660 your previous state where things were once as they were things are as they once were. 05:57.660 --> 06:02.260 So the first, uh, this drum going to talk about is vanilla OS, sometimes they also like 06:02.340 --> 06:03.740 save vanilla for short. 06:03.740 --> 06:10.580 Um, and this distro's based on, uh, Debian, and it uses the Genome desktop environment 06:10.580 --> 06:16.460 by default, and it encourages using Flopax for installing general GUI applications, so 06:16.460 --> 06:21.420 you'll feel right at home if you've been, uh, checking out Flopax and using those. 06:21.420 --> 06:27.480 Um, but a vanilla's answer to an immutable root file system is a technology called AB 06:27.520 --> 06:28.480 root. 06:28.480 --> 06:33.720 So in other words, AB root is the course software that provides immutability on vanilla 06:33.720 --> 06:40.080 OS, and so vanilla works by, uh, dividing the system into an active and then an inactive 06:40.080 --> 06:46.080 partition, the inactive partition will be booted into on restart of the OS and transitioning 06:46.080 --> 06:51.200 to it is atomic, meaning that if the transition fails, then you can safely revert to the 06:51.200 --> 06:54.120 previous the active partition. 06:54.120 --> 06:58.200 In other words, on restart, you can roll back to the previous state of the operating system 06:58.200 --> 07:03.560 by selecting the previous version of the OS state in the boot menu, and this is a little 07:03.560 --> 07:06.000 nice plain text. 07:06.000 --> 07:10.880 Look at something that looks like grub, but basically you could either choose current state 07:10.880 --> 07:16.920 A or previous state B and, you know, you could just pick the previous state or the 07:16.920 --> 07:23.080 current state and in case current state is messed up. 07:23.080 --> 07:30.240 So vanilla OS's default package manager is APX, which is a wrapper around distrobox, which 07:30.240 --> 07:35.360 in turn is a wrapper around podmen that has tight integration with the host system allowing 07:35.360 --> 07:37.720 you to access your file system easily. 07:37.720 --> 07:44.860 So have a little plain text diagram there for you APX, distrobox under distrobox, distrobox 07:44.940 --> 07:54.220 is a post-exile project, which wraps podmen, also supports Docker, but it's primarily people 07:54.220 --> 08:01.380 know it to be using podmen containers, and then you get your OCI container come out. 08:01.380 --> 08:05.420 So APX has a developer focus in that it promotes creating container environments for doing 08:05.420 --> 08:07.140 software development. 08:07.140 --> 08:11.020 The general workflow is that you create something called a stack, which is an environment 08:11.020 --> 08:13.820 with a particular package manager and group of packages. 08:13.820 --> 08:21.060 So here's an example from the AUR, in this case you have a wrapper around the AUR tooling 08:21.060 --> 08:24.500 so that you don't have to think about AUR specific tooling. 08:24.500 --> 08:26.860 So that's another nice thing about APX. 08:26.860 --> 08:30.540 In this case we want to install this package called Deezer. 08:30.540 --> 08:35.100 Look that one up, it's an interesting package in the AUR, and then once you install that 08:35.100 --> 08:42.260 you can enter that container by doing APX enter dash dash AUR. 08:42.260 --> 08:47.780 In just in case you're not familiar with distrobox and these type of container wrapper 08:47.780 --> 08:54.980 systems is that the cool thing about it is that it exposes your host file system very easily 08:54.980 --> 08:58.780 without having to know much like podmen specifics. 08:58.780 --> 09:03.020 So you just get in and it really feels like you're just using your host file system. 09:03.020 --> 09:08.540 So your regular files in your directory are available, but you're actually in a podmen container 09:08.540 --> 09:12.820 or a Docker container. 09:12.820 --> 09:19.660 So I think the biggest perks of why you'd want to try vanilla is that it's a very familiar 09:19.660 --> 09:20.980 environment. 09:20.980 --> 09:24.540 So if you're used to Dezer, you're going to feel right at home. 09:24.540 --> 09:29.500 For example, if you open the default terminal in vanilla OS, you could just start installing 09:29.500 --> 09:31.140 stuff with ABT. 09:31.140 --> 09:33.980 So immediately the learning curve is very low. 09:33.980 --> 09:38.100 If you're coming from those ecosystems and those communities, you could just use 09:38.100 --> 09:39.100 app install. 09:39.100 --> 09:43.740 RPMOS tree uses hard links to content address files on each update in this way files 09:43.740 --> 09:46.660 that don't change or reference the cross updates. 09:46.660 --> 09:57.140 And this is just a quick TLDR of how you would use RPMOS tree to install the get executable. 09:57.140 --> 10:04.780 So in that using OS tree or RPMOS tree, adding that get binary that I just showed on the 10:04.780 --> 10:12.340 previous slide, that will create a layer on top of an immutable core and then on reboot 10:12.340 --> 10:17.460 of the operating system that get binary would actually then be available. 10:17.460 --> 10:23.460 And you could then either add layers up or peel layers back, rolling back to previous 10:23.460 --> 10:29.540 generations of your file system history. 10:29.540 --> 10:36.420 So Fedora Silverblues answered to developer container workflows is a tool called Toolbox. 10:36.420 --> 10:37.780 And this is their own implementation. 10:37.780 --> 10:45.220 It doesn't use distrobox or the APX wrapper around distrobox, but it uses Toolbox. 10:45.220 --> 10:49.700 And this provides a similar experience to APX and that OCI containers tightly integrate 10:49.700 --> 10:55.060 with the host and can be easily created for development and user purposes. 10:55.060 --> 10:58.380 So this is a really quick TLDR on how you can use Toolbox. 10:58.380 --> 11:03.100 You can do Toolbox create and because we're on Fedora, this is very opinionated and it 11:03.100 --> 11:08.300 will just create a Fedora OCI image for you by default. 11:08.300 --> 11:12.100 That's not going to be the case with APX, tool with the APX tool. 11:12.100 --> 11:15.100 And then you could do Toolbox enter. 11:15.100 --> 11:22.420 That said, this Toolbox, you can spin up other containers, other distro's like arch Linux 11:22.460 --> 11:24.220 or Ubuntu. 11:24.220 --> 11:32.100 But I've seen that it does have a more core focus on very well-known Linux distributions 11:32.100 --> 11:37.940 instead of using more esoteric distros. 11:37.940 --> 11:40.060 So that's something to just be aware of. 11:40.060 --> 11:43.860 Maybe that's a deal breaker for you in between choosing something that's built on top 11:43.860 --> 11:49.180 of distrobox or this Fedora tooling. 11:49.180 --> 11:54.140 So here are some reasons, some of my reasons why you might want to use Fedora Silver 11:54.140 --> 11:58.700 Blue is that you've been wanting to try out an immutable Linux distribution and you 11:58.700 --> 12:00.940 feel at home in the Fedora ecosystem. 12:00.940 --> 12:06.380 So if that's you, then you might want to try this for a duck for your immutable desktop. 12:06.380 --> 12:12.340 And you don't want to learn a whole programming language to configure your operating system 12:12.340 --> 12:17.980 more on that next. 12:17.980 --> 12:24.260 So the second half of my talk will cover another breed of immutable Linux distributions 12:24.260 --> 12:28.980 that can be further described as functional distros. 12:28.980 --> 12:36.140 So functional distros are also immutable distros in the same sense that vanilla and silver 12:36.140 --> 12:38.500 blue are. 12:38.500 --> 12:44.780 But in addition, functional distros can be described as having the following features. 12:44.780 --> 12:49.980 So they have this full declarative first class functional solution for deploying your 12:49.980 --> 12:53.060 desktop and they provide that. 12:53.060 --> 12:58.580 And they provide a DSL, a domain specific language, or embedded DSL for managing the state 12:58.580 --> 13:00.060 of your desktop. 13:00.060 --> 13:02.780 So there's a bit more of a learning curve. 13:02.780 --> 13:09.060 But without of course comes more power in certain areas like deploying et cetera. 13:09.060 --> 13:13.940 So these distros follow functional programming principles. 13:13.940 --> 13:19.140 And I'll explain what that means in the sense that the configuring your operating system 13:19.140 --> 13:22.100 is functional in the sense of a function. 13:22.100 --> 13:27.060 So you can think of configuring your operating system like literally calling a function, passing 13:27.060 --> 13:32.180 in a config down here if you look at this plain text diagram. 13:32.180 --> 13:38.100 You pass in a config in a lock file and with those two inputs out comes your operating system. 13:38.100 --> 13:42.220 So this is pseudo code, but I just wanted to demonstrate that. 13:42.220 --> 13:47.260 So just think the config is like the language that it's providing. 13:47.260 --> 13:51.900 And then the lock file is like the provenance and with those two things you could provide 13:51.900 --> 13:57.780 the operating system state that you're declaring. 13:57.780 --> 14:03.060 So next OS is the first functional distro that I'll cover, which provides the set lock 14:03.060 --> 14:06.140 file mechanism called the flake. 14:06.140 --> 14:12.500 Your dollfouse package of services, et cetera, can all be reproduced from a configuration 14:12.500 --> 14:15.060 specified in nix code. 14:15.060 --> 14:19.100 NixOS is declarative in the sense that you declaratively specify the state of the operating 14:19.100 --> 14:27.260 system that you'd like to see as code and reconfigure the OS to produce the declared state. 14:27.260 --> 14:33.180 This is a quick example of what the nix language looks like. 14:33.180 --> 14:39.820 It kind of looks like JSON, IBM, Fedora, you'll have things in user bin Firefox, but in 14:39.820 --> 14:47.860 nix you're going to have this path with a hash that directly is directly pointing to that 14:47.860 --> 14:54.380 particular Firefox that you built with particular inputs to that function as mentioned earlier. 14:54.380 --> 14:56.380 So it outputs a particular package. 14:56.380 --> 15:01.100 In this case we're actually using that functional model that I mentioned to build a particular 15:01.100 --> 15:08.100 version of Firefox with particular inputs, which is nix jargon for your dependencies. 15:08.100 --> 15:11.660 They like to call it inputs. 15:11.660 --> 15:16.100 So every time you build a package, service, stop files, et cetera, with nix, you get a new 15:16.100 --> 15:21.260 unique path or paths in the store that potentially reference each other. 15:21.260 --> 15:26.340 It's that of forward slash bin, s bin, lib, user, and so on. 15:26.340 --> 15:35.340 Everything's kept inside this one path and forward slash nix. 15:35.340 --> 15:40.340 NixOS is answer to developer workflows is a feature called the nix shell. 15:40.340 --> 15:46.020 This is similar to the distra box that I mentioned earlier, but in this case this is all 15:46.020 --> 15:51.820 completely managed by nix shell, which is a custom implementation of Linux namespaces. 15:51.820 --> 15:58.140 It doesn't use OCI images in this particular in the nix shell, but it just uses things 15:58.140 --> 16:04.180 that come from their package, Providence, which is called nix packages. 16:04.180 --> 16:10.140 And some of the reasons why you might want to use nixOS is that you want to benefit from 16:10.140 --> 16:15.140 having access to one of the largest package ecosystems, which is nix packages. 16:15.180 --> 16:20.220 It's the largest software distribution in the world, according to them in their wiki. 16:20.220 --> 16:27.020 And yep, and you want, and you're very excited about learning the nix language. 16:27.020 --> 16:31.700 So if that's you, nixOS. 16:31.700 --> 16:37.580 I'd like to mention, make a special mention for snowflake, which is a variant of nixOS. 16:37.580 --> 16:41.020 And the main thing I just want to say about it is that they provide like this thing called 16:41.060 --> 16:46.940 snowflolib, which provides opinionated file structures for your nix flakes. 16:46.940 --> 16:51.620 There's a nix software center, which is kind of like the Genome Software Center. 16:51.620 --> 16:58.260 But underneath the hood, it's actually just installing stuff with the nix package manager. 16:58.260 --> 17:04.540 And it also even has a nixOS confeditor, which basically lets you edit your nixOS configuration 17:04.540 --> 17:06.380 from a GUI. 17:06.380 --> 17:10.540 So it's a pretty cool project that I would check out if your hesitant to get into nix 17:10.540 --> 17:16.460 and it feels like intimidating because of the language. 17:16.460 --> 17:22.260 So the fourth and last just row that I will talk about is this one called RDE. 17:22.260 --> 17:27.340 It's a newer distro based on geek system. 17:27.340 --> 17:33.340 So geek system is a distribution that is directly influenced by nix. 17:33.340 --> 17:38.900 So I'm going to talk about geek system a little bit just because RDE is based on it. 17:38.980 --> 17:45.860 And the difference with geek system is that it basically forked the nix demon. 17:45.860 --> 17:49.700 And it replaces it and also it replaces the nix language, 17:49.700 --> 17:52.020 on which I showed earlier with the Scheme programming language. 17:52.020 --> 17:55.060 So as anybody heard of the Scheme programming language, 17:55.060 --> 17:59.860 that's like good percentage of the room, that's great. 17:59.860 --> 18:04.500 And so RDE also provides a mechanism similar to nix's nix shell. 18:04.500 --> 18:07.740 That's provided by geeks, which is called geek shell. 18:07.820 --> 18:15.820 So the main core thing here is the language, which I'll show you a little bit more about. 18:15.820 --> 18:17.180 I'm going to do a quick detour. 18:17.180 --> 18:24.140 I'm just going to give a quick Scheme crash course for those who didn't raise their hands. 18:24.140 --> 18:27.020 This is basically how you define a function in Scheme. 18:27.020 --> 18:28.780 This is a function called greet. 18:28.780 --> 18:31.260 It takes a parameter of user. 18:31.260 --> 18:34.500 This function you could think of like print and Python. 18:35.220 --> 18:37.540 The hash t is exactly what you might be thinking. 18:37.540 --> 18:41.940 It's a boolean and that means print is standard output. 18:41.940 --> 18:49.060 And then there you put in a string and the little squiggly till the A basically means 18:49.060 --> 18:53.220 that's where you interpolate the user parameter that goes into the function. 18:53.220 --> 18:58.100 And until the A specifically means print this in a human readable way. 18:58.100 --> 19:00.900 So that we have our function greet and then you could pass it. 19:00.900 --> 19:06.660 For example, 2025, a particular Scheme object and that will print out, you know, 19:06.660 --> 19:11.140 welcome to Faustem 2025 and that will interpolate it into the string. 19:11.140 --> 19:14.500 So that's my Scheme nano crash course, you're welcome. 19:16.340 --> 19:20.740 Okay, so RDE, this is how you set up your desktop on RDE. 19:20.740 --> 19:22.420 It's literally Scheme code. 19:22.420 --> 19:24.900 So in this case, we're using that same define. 19:24.900 --> 19:30.340 We're creating a variable called RDE desktop and this is set to a list. 19:30.340 --> 19:34.260 It's a list just like in Python and these are all function called features. 19:34.980 --> 19:40.740 And if you've ever heard of space max, it's basically like space max layers. 19:40.740 --> 19:43.220 But for your entire operating system, that's just for e-max. 19:43.220 --> 19:46.580 So you can configure your entire operating system with this layer mechanism 19:46.580 --> 19:49.860 or like with configurable layers of configuration, which is pretty cool. 19:51.620 --> 19:53.300 I'll just make a quick pass of this. 19:53.300 --> 19:58.900 This is a full definition of a feature in RDE and this is to configure your mail settings. 20:00.420 --> 20:04.100 So this is just an ordinary Scheme function with these keyword arguments. 20:04.100 --> 20:08.100 Like I just mentioned, it does type checking on those arguments. 20:08.660 --> 20:12.500 It creates home services for your user, your home user. 20:13.780 --> 20:17.220 And it will then return in Scheme. 20:17.220 --> 20:22.820 There's no return keyword like the last thing of a Scheme function is just implicitly a return. 20:22.820 --> 20:28.100 So in this case, it's returning a feature record, which is kind of like a Python dictionary. 20:28.180 --> 20:31.940 And it holds all this configuration values that you need in order to configure e-mail. 20:33.380 --> 20:34.900 So this is how you would actually call that. 20:34.900 --> 20:38.020 So here I'm passing in a list of mail accounts. 20:38.020 --> 20:41.140 So in case in that case, I might have like a Gmail account. 20:41.940 --> 20:49.060 And you could basically then configure your e-mail configuration completely declaratively, which is pretty cool. 20:51.540 --> 20:56.260 So if you want to get started with RDE, I recommend to check out the RDE Kickstarter project, 20:56.340 --> 20:57.780 which could be found at that address. 20:59.220 --> 21:02.740 And my own configuration is at this address of confetti. 21:05.700 --> 21:11.700 So the reason you might want to use RDE is you like the idea of features that I just described. 21:12.660 --> 21:17.460 You think that's a pretty cool thing to have that sort of hackability in your system. 21:18.020 --> 21:20.900 You like sway, although you could use Genova as well. 21:20.900 --> 21:22.580 It doesn't prevent you from doing that. 21:22.580 --> 21:25.140 That's just the different service that you'd get from geeks. 21:25.220 --> 21:28.900 But it has really just really killer configurations that are opinionated for swaying, 21:28.900 --> 21:30.180 in case you don't want to think about that. 21:30.660 --> 21:32.260 That's the main reason I use RDE. 21:32.260 --> 21:35.460 I don't want to think about e-max, I just end sway, I just want to use it. 21:36.180 --> 21:41.780 And you like the idea of learning a list or scheme to configure your immutable Linux distro. 21:43.700 --> 21:48.420 So immutable distributions give users more control. 21:50.020 --> 21:54.180 Because as a user, you can confidently reason about the state of your OS. 21:55.220 --> 22:00.020 This provides a more humane computing environment in which the user has confidence of not 22:00.020 --> 22:01.060 working their system. 22:02.340 --> 22:06.500 If you've ever worked a Linux distribution and have been frustrated that you now have to reinstall 22:06.500 --> 22:10.980 the whole thing in order to get things to work again, then immutable Linux distro's are for you. 22:12.580 --> 22:16.660 If you've ever wanted to update your Linux distributions when other major version are commit, 22:17.060 --> 22:22.980 in the case of a rolling release without fear of breaking anything, then immutable Linux distro's are for you. 22:23.860 --> 22:27.620 Let's build a future in which we are using systems that are humane for end users. 22:28.180 --> 22:29.940 Let's move towards immutable distros. 22:31.540 --> 22:35.060 If you want to contribute to any of these distros, I check out the links there. 22:35.060 --> 22:39.620 I'm going to have this up on slides that you can find at this address. 22:40.260 --> 22:41.860 And thank you very much. 22:41.860 --> 22:47.300 If there's any questions, I suggest some questions here, but you could do five and give me your 22:47.300 --> 22:50.740 thoughts on what you think about immutable Linux distros. Thank you. 22:53.620 --> 22:57.620 APPLAUSE 23:04.500 --> 23:10.340 So some of these are, like, the first two of these immutable distros are heavily focused 23:11.140 --> 23:13.460 or heavily rely on containerization. 23:15.220 --> 23:19.060 Is this going to be a problem overhead-wise on older, weaker hardware? 23:19.060 --> 23:26.500 Yeah. Will this be an issue overhead-wise on older and weaker hardware? 23:40.500 --> 23:46.660 I mean, in my agree, very lightweight, I have not done testing on old machines. 23:46.660 --> 23:51.860 There's an error when I was running old things, pads from, like, on what to ask. 23:56.580 --> 24:00.500 Thanks. I basically just want to know the answer to question number two. 24:01.460 --> 24:07.460 OK, is this inevitable? I mean, it's inevitably a yes.