Thank you, everybody, can everybody hear me find their sounds like it, it's kind of echoing
right here.
But yes, I'm going to be talking on building the future, understanding and contributing
to immutable Linux distributions, and I'm going to be, there's another bison, and I'm
going to be talking about four different immutable Linux distributions, those being vanilla
OS, Fedora Silver Blue, NYXOS, and RDE in addition to the title topic.
So a little bit about me, as I mentioned, just a few seconds ago, my name is Jorge Gomez,
but I'll repeat that.
And my handle online is J-Guard, so if you see me rambling on IRC, you might see someone
there called J-Guard or something like that.
I'm a senior software engineer at Recondigital, we're a small consultancy providing software
services to the United Nations and other clients.
In a past life and current life, I've been a musician, composer, and sometimes a dancer,
I like dancing in the hop, but I've also had a traditional jazz group playing like 1920s
music for over 10 years, and that's something I've really enjoyed doing.
I'm also an immutable Linux contributor and chronic distro hopper.
I've contributed to GeekSystem, I have nearly 700 commits to GeekSystem, and I have
commit access to GeekSystem and RDE.
I've also contributed packages to NYXOS and updated packages and things like that.
I also started a small community to work on Geek's related projects called Where is everyone?
And for more on that, check out Where is that social on the Internet.
We like to just work on Geek's related projects, but sometimes we work on random things,
kind of like the bison that you saw there.
So raise your hand if you've ever worked Ubuntu, I have definitely, okay, that's a lot
of hands, a lot of people have worked Ubuntu.
Have you worked it more than once?
Yeah, I don't want to, I can't even remember how many times I've worked Ubuntu, okay,
raise your hands if you've ever worked Ubuntu, raise your hands if you've ever worked Ubuntu
within like the first 20 minutes of working Ubuntu, okay, raise your hands if you've
ever worked Fedora, okay, raise your hands if you've ever worked arched by the way.
I definitely have worked arch at least twice, maybe more.
Yeah, so one of the main value propositions that in mutable Linux distributions provide
is that they are a work free.
In the sense that if you mess anything up, you can always roll back to a previous state
in which things are as they once were.
This is possible through the concepts of immutability as conceptualized and applied
to operating systems.
So traditionally operating systems were mostly imperative and mutable.
You'd change the state of the OS and there would be no way of going back to where you once
were with regards to software provenance and system state.
So the key definitions that I'm using to define an immutable distra are that it has an immutable
core.
And by the way, now I'm going to mention that immutable is a bit of a misnomer in the sense
that it means the entire thing is not immutable.
If that were the case, you wouldn't be able to do anything because everything would be
read only.
But it's primarily core system paths usually owned by root that you want to not change
state.
So those things are immutable in that sense, but immutable is also a consortium of things
that make an immutable distro.
What it is, that brand, that idea of the things that an immutable distro or that brand
is looking to provide.
So the other thing is that usually they promote isolated developer environments.
In the case of the first two distros, I'm going to talk about those are OCI container environments
that, so instead of they want to promote, you're getting into a container and they want
to make that easy for you.
So you want to do all your hacking there instead of installing stuff into the base of the
system, although you can also, but it's encouraged.
Different workflow is encouraged in the traditional, mutable OS workflow.
Also there is this concept of animosity, which maybe you're familiar with get or databases.
But in the case of operating system, animosity means like, for example, if you make a system
update, you want to make sure that you're able to make that whole update and you're
not left in some partial, partially updated state, otherwise being in the box in the
box zone.
So we need this animosity in order to have the confidence to do updates.
And that gives us automatic updates also, which we, um, federal or core OS was one of
the early pioneers of that.
And then with this animosity, with these atomic feature, then you get this really
cool feature called Robax, which allows you to basically go back to the previous state
that your OS was in, so imagine you apply some update to your system, you're in in the
board area, and now you're like, oh, shit, and you could just basically go back to
your previous state where things were once as they were things are as they once were.
So the first, uh, this drum going to talk about is vanilla OS, sometimes they also like
save vanilla for short.
Um, and this distro's based on, uh, Debian, and it uses the Genome desktop environment
by default, and it encourages using Flopax for installing general GUI applications, so
you'll feel right at home if you've been, uh, checking out Flopax and using those.
Um, but a vanilla's answer to an immutable root file system is a technology called AB
root.
So in other words, AB root is the course software that provides immutability on vanilla
OS, and so vanilla works by, uh, dividing the system into an active and then an inactive
partition, the inactive partition will be booted into on restart of the OS and transitioning
to it is atomic, meaning that if the transition fails, then you can safely revert to the
previous the active partition.
In other words, on restart, you can roll back to the previous state of the operating system
by selecting the previous version of the OS state in the boot menu, and this is a little
nice plain text.
Look at something that looks like grub, but basically you could either choose current state
A or previous state B and, you know, you could just pick the previous state or the
current state and in case current state is messed up.
So vanilla OS's default package manager is APX, which is a wrapper around distrobox, which
in turn is a wrapper around podmen that has tight integration with the host system allowing
you to access your file system easily.
So have a little plain text diagram there for you APX, distrobox under distrobox, distrobox
is a post-exile project, which wraps podmen, also supports Docker, but it's primarily people
know it to be using podmen containers, and then you get your OCI container come out.
So APX has a developer focus in that it promotes creating container environments for doing
software development.
The general workflow is that you create something called a stack, which is an environment
with a particular package manager and group of packages.
So here's an example from the AUR, in this case you have a wrapper around the AUR tooling
so that you don't have to think about AUR specific tooling.
So that's another nice thing about APX.
In this case we want to install this package called Deezer.
Look that one up, it's an interesting package in the AUR, and then once you install that
you can enter that container by doing APX enter dash dash AUR.
In just in case you're not familiar with distrobox and these type of container wrapper
systems is that the cool thing about it is that it exposes your host file system very easily
without having to know much like podmen specifics.
So you just get in and it really feels like you're just using your host file system.
So your regular files in your directory are available, but you're actually in a podmen container
or a Docker container.
So I think the biggest perks of why you'd want to try vanilla is that it's a very familiar
environment.
So if you're used to Dezer, you're going to feel right at home.
For example, if you open the default terminal in vanilla OS, you could just start installing
stuff with ABT.
So immediately the learning curve is very low.
If you're coming from those ecosystems and those communities, you could just use
app install.
RPMOS tree uses hard links to content address files on each update in this way files
that don't change or reference the cross updates.
And this is just a quick TLDR of how you would use RPMOS tree to install the get executable.
So in that using OS tree or RPMOS tree, adding that get binary that I just showed on the
previous slide, that will create a layer on top of an immutable core and then on reboot
of the operating system that get binary would actually then be available.
And you could then either add layers up or peel layers back, rolling back to previous
generations of your file system history.
So Fedora Silverblues answered to developer container workflows is a tool called Toolbox.
And this is their own implementation.
It doesn't use distrobox or the APX wrapper around distrobox, but it uses Toolbox.
And this provides a similar experience to APX and that OCI containers tightly integrate
with the host and can be easily created for development and user purposes.
So this is a really quick TLDR on how you can use Toolbox.
You can do Toolbox create and because we're on Fedora, this is very opinionated and it
will just create a Fedora OCI image for you by default.
That's not going to be the case with APX, tool with the APX tool.
And then you could do Toolbox enter.
That said, this Toolbox, you can spin up other containers, other distro's like arch Linux
or Ubuntu.
But I've seen that it does have a more core focus on very well-known Linux distributions
instead of using more esoteric distros.
So that's something to just be aware of.
Maybe that's a deal breaker for you in between choosing something that's built on top
of distrobox or this Fedora tooling.
So here are some reasons, some of my reasons why you might want to use Fedora Silver
Blue is that you've been wanting to try out an immutable Linux distribution and you
feel at home in the Fedora ecosystem.
So if that's you, then you might want to try this for a duck for your immutable desktop.
And you don't want to learn a whole programming language to configure your operating system
more on that next.
So the second half of my talk will cover another breed of immutable Linux distributions
that can be further described as functional distros.
So functional distros are also immutable distros in the same sense that vanilla and silver
blue are.
But in addition, functional distros can be described as having the following features.
So they have this full declarative first class functional solution for deploying your
desktop and they provide that.
And they provide a DSL, a domain specific language, or embedded DSL for managing the state
of your desktop.
So there's a bit more of a learning curve.
But without of course comes more power in certain areas like deploying et cetera.
So these distros follow functional programming principles.
And I'll explain what that means in the sense that the configuring your operating system
is functional in the sense of a function.
So you can think of configuring your operating system like literally calling a function, passing
in a config down here if you look at this plain text diagram.
You pass in a config in a lock file and with those two inputs out comes your operating system.
So this is pseudo code, but I just wanted to demonstrate that.
So just think the config is like the language that it's providing.
And then the lock file is like the provenance and with those two things you could provide
the operating system state that you're declaring.
So next OS is the first functional distro that I'll cover, which provides the set lock
file mechanism called the flake.
Your dollfouse package of services, et cetera, can all be reproduced from a configuration
specified in nix code.
NixOS is declarative in the sense that you declaratively specify the state of the operating
system that you'd like to see as code and reconfigure the OS to produce the declared state.
This is a quick example of what the nix language looks like.
It kind of looks like JSON, IBM, Fedora, you'll have things in user bin Firefox, but in
nix you're going to have this path with a hash that directly is directly pointing to that
particular Firefox that you built with particular inputs to that function as mentioned earlier.
So it outputs a particular package.
In this case we're actually using that functional model that I mentioned to build a particular
version of Firefox with particular inputs, which is nix jargon for your dependencies.
They like to call it inputs.
So every time you build a package, service, stop files, et cetera, with nix, you get a new
unique path or paths in the store that potentially reference each other.
It's that of forward slash bin, s bin, lib, user, and so on.
Everything's kept inside this one path and forward slash nix.
NixOS is answer to developer workflows is a feature called the nix shell.
This is similar to the distra box that I mentioned earlier, but in this case this is all
completely managed by nix shell, which is a custom implementation of Linux namespaces.
It doesn't use OCI images in this particular in the nix shell, but it just uses things
that come from their package, Providence, which is called nix packages.
And some of the reasons why you might want to use nixOS is that you want to benefit from
having access to one of the largest package ecosystems, which is nix packages.
It's the largest software distribution in the world, according to them in their wiki.
And yep, and you want, and you're very excited about learning the nix language.
So if that's you, nixOS.
I'd like to mention, make a special mention for snowflake, which is a variant of nixOS.
And the main thing I just want to say about it is that they provide like this thing called
snowflolib, which provides opinionated file structures for your nix flakes.
There's a nix software center, which is kind of like the Genome Software Center.
But underneath the hood, it's actually just installing stuff with the nix package manager.
And it also even has a nixOS confeditor, which basically lets you edit your nixOS configuration
from a GUI.
So it's a pretty cool project that I would check out if your hesitant to get into nix
and it feels like intimidating because of the language.
So the fourth and last just row that I will talk about is this one called RDE.
It's a newer distro based on geek system.
So geek system is a distribution that is directly influenced by nix.
So I'm going to talk about geek system a little bit just because RDE is based on it.
And the difference with geek system is that it basically forked the nix demon.
And it replaces it and also it replaces the nix language,
on which I showed earlier with the Scheme programming language.
So as anybody heard of the Scheme programming language,
that's like good percentage of the room, that's great.
And so RDE also provides a mechanism similar to nix's nix shell.
That's provided by geeks, which is called geek shell.
So the main core thing here is the language, which I'll show you a little bit more about.
I'm going to do a quick detour.
I'm just going to give a quick Scheme crash course for those who didn't raise their hands.
This is basically how you define a function in Scheme.
This is a function called greet.
It takes a parameter of user.
This function you could think of like print and Python.
The hash t is exactly what you might be thinking.
It's a boolean and that means print is standard output.
And then there you put in a string and the little squiggly till the A basically means
that's where you interpolate the user parameter that goes into the function.
And until the A specifically means print this in a human readable way.
So that we have our function greet and then you could pass it.
For example, 2025, a particular Scheme object and that will print out, you know,
welcome to Faustem 2025 and that will interpolate it into the string.
So that's my Scheme nano crash course, you're welcome.
Okay, so RDE, this is how you set up your desktop on RDE.
It's literally Scheme code.
So in this case, we're using that same define.
We're creating a variable called RDE desktop and this is set to a list.
It's a list just like in Python and these are all function called features.
And if you've ever heard of space max, it's basically like space max layers.
But for your entire operating system, that's just for e-max.
So you can configure your entire operating system with this layer mechanism
or like with configurable layers of configuration, which is pretty cool.
I'll just make a quick pass of this.
This is a full definition of a feature in RDE and this is to configure your mail settings.
So this is just an ordinary Scheme function with these keyword arguments.
Like I just mentioned, it does type checking on those arguments.
It creates home services for your user, your home user.
And it will then return in Scheme.
There's no return keyword like the last thing of a Scheme function is just implicitly a return.
So in this case, it's returning a feature record, which is kind of like a Python dictionary.
And it holds all this configuration values that you need in order to configure e-mail.
So this is how you would actually call that.
So here I'm passing in a list of mail accounts.
So in case in that case, I might have like a Gmail account.
And you could basically then configure your e-mail configuration completely declaratively, which is pretty cool.
So if you want to get started with RDE, I recommend to check out the RDE Kickstarter project,
which could be found at that address.
And my own configuration is at this address of confetti.
So the reason you might want to use RDE is you like the idea of features that I just described.
You think that's a pretty cool thing to have that sort of hackability in your system.
You like sway, although you could use Genova as well.
It doesn't prevent you from doing that.
That's just the different service that you'd get from geeks.
But it has really just really killer configurations that are opinionated for swaying,
in case you don't want to think about that.
That's the main reason I use RDE.
I don't want to think about e-max, I just end sway, I just want to use it.
And you like the idea of learning a list or scheme to configure your immutable Linux distro.
So immutable distributions give users more control.
Because as a user, you can confidently reason about the state of your OS.
This provides a more humane computing environment in which the user has confidence of not
working their system.
If you've ever worked a Linux distribution and have been frustrated that you now have to reinstall
the whole thing in order to get things to work again, then immutable Linux distro's are for you.
If you've ever wanted to update your Linux distributions when other major version are commit,
in the case of a rolling release without fear of breaking anything, then immutable Linux distro's are for you.
Let's build a future in which we are using systems that are humane for end users.
Let's move towards immutable distros.
If you want to contribute to any of these distros, I check out the links there.
I'm going to have this up on slides that you can find at this address.
And thank you very much.
If there's any questions, I suggest some questions here, but you could do five and give me your
thoughts on what you think about immutable Linux distros. Thank you.
APPLAUSE
So some of these are, like, the first two of these immutable distros are heavily focused
or heavily rely on containerization.
Is this going to be a problem overhead-wise on older, weaker hardware?
Yeah. Will this be an issue overhead-wise on older and weaker hardware?
I mean, in my agree, very lightweight, I have not done testing on old machines.
There's an error when I was running old things, pads from, like, on what to ask.
Thanks. I basically just want to know the answer to question number two.
OK, is this inevitable? I mean, it's inevitably a yes.