 If you've watched the Linux YouTube channels or you've listened to Linux podcast, you've probably come across fedora silver blue and you've probably heard the term immutable. And you may be wondering what those things actually are. So what we're going to do today is talk about fedora silver blue. And during that conversation, we're going to discuss what immutable actually means, why it's good, why it's bad, and maybe answer. Is it the future? So let's go ahead and jump in. So what is fedora silver blue? Silver blue is not a fedora spin. So if you're familiar at all with the way fedora works, fedora has a main version is called fedora workstation. It comes with a GNOME desktop. It is the version of fedora that is promoted on their website. And it's the main one, right? Similar to how Ubuntu has a main version of Ubuntu that's promoted on their website, fedora also has spins. And these are basically just regular fedora, but with different desktop environments and window managers. There's a KDE spin, there's an i3 spin, and so on and so forth, right? Fedora silver blue is not a spin. It is instead a different, basically a offshoot of the fedora project itself. And if you were to install it, and you didn't know any better, and you didn't know actually what you installed or have, and you haven't done any particular research on silver blue itself, you could use fedora silver blue and be confused because it basically looks and functions exactly like the workstation version of fedora, at least on a surface level. So what's the big deal? What is fedora silver blue? Basically it is an immutable version of fedora. Now, I say that and then a lot of people are going to be very confused, including myself, because when I first heard of the term immutable, I had absolutely no clue what it meant. And even now, after spending two weeks researching it and using it, immutable is still one of those fuzzy concepts that is really kind of... It's difficult to explain for someone who has no clue what it is to begin with and is not as technical as maybe a developer is or someone who works in IT, because a lot of the benefits that come with immutable system really have to do with people who run these kind of distros on multiple machines all at once, probably in a corporate or IT environment, right? That's one of the main benefits of these things. And to explain it to someone who doesn't have to do that can be a little bit difficult, but I'm going to try. So let's go ahead and see how I do. So first, we should talk about what is immutable, what does it do? Why is it good? So in basic terms, immutable basically means that the underlying system of your Linux distro is going to be the same always. Now, on a more broad level, it means that those system level files are somewhat read only. And I say somewhat because you can go into like the Etsy file and make changes if you want, but they are not going to be persistent. What that means is that when you do an upgrade, there's a good chance that those changes are going to be gone. And that's because the underlying base level part of your Linux system is going to be the same. Those files are meant to be untouchable. They're meant to be containerized so that whenever your system does an update or an upgrade, those systems are pushed forward, but your upper level user files and applications are separated from them so that there's no real interaction between them, and there's no real changes between upgrades and so on. So the idea is that every single version of Fedora Silverblue that is running the same version. So if you're both if two computers are running Silverblue and they're both on Fedora 37, then those underlying files are going to be exactly the same. Now, the benefits of this are, again, somewhat fuzzy for the regular person. So the idea is that by having an immutable system, not only do you increase security because those bottom line base level files are not being interacted with by any user files, but also you're able to upgrade your system knowing that every time you do so, because those files are exactly the same on your computer as they are on my computer, those upgrades are supposed to be more stable. And I know I'm not doing a very good job of explaining, but basically what it means is that because those base level system files are the same across every version of Silverblue, it removes the or lessens the chance of bugs and instability across the board. Now, obviously, the benefits of this are going to be grander when you're talking about managing many different computers. So if you're in an IT situation where you are managing multiple computers, maybe even hundreds or thousands of computers and they all run Silverblue and they're all exactly the same, when you update one, you know that the update process is going to be the same on every single computer that you are in charge of updating. So the benefits there are quite obvious for people who just run one computer, it's a little bit less so. In the documentation, they mentioned that the read only aspect of Silverblue allows them to make Silverblue more secure and that containers play a big role in this. So the next part we should talk about is containers themselves. So there are many different branches of this conversation that we can have, but we're going to talk about two of them. The first one is flat packs. So flat packs are the primary means of gaining access to applications on your system. So we've talked about flat packs on this channel before many different times, but they're a big deal on Fedora Silverblue because that's where you're meant to get every single application you use. If you're going to download a browser, you're going to get through flat pack. If you're going to download audacity or OBS or anything like that, you're going to download it from flat pack. The only exception to this are things that don't come in flat pack and we'll talk about how you'd go about installing those things here in a few minutes. So the idea with flat pack and like I said, we've talked about this before is that they're a containerized version of the application. They're meant to have all the dependencies and stuff like that baked right into a single package. And they're supposed to be secure in the fact that they're containerized to themselves. They are by default just functioning applications. They don't interact with your user files. And on Silverblue, they can't interact with any of those base level files we talked about earlier. So the idea is again, security is the number one aspect of containers. In this case, the number one aspect of flat packs themselves. Now, we've talked about the pros and cons of flat packs in another video. But for Fedora Silverblue, you're not given really an option for anything else. If you wanted to just install something like a snap or you know, something from DNF, you can't really do that. Now, at least you can't do that on the base level system because those things interact with those lower level things. Like you can't create the loopback devices that snap would have to have in order to actually use snap. So the same thing with using DNF, DNF just doesn't exist on Fedora Silverblue by itself. So you are, if you're going to use Silverblue and you want applications, you're going to be using flat pack very heavily. The other aspect of containers that we should talk about is going to be the toolbox. Now toolbox is very similar to a distro box if you've ever used it before. And the idea here is that you can create, and this is going to be the wrong term, but you can basically create virtualized containers for different aspects of doing things. Now, that's a really horrible way of explaining it. Basically what you can do inside of these toolboxes is run environments that allow you to do things that you can't do on Silverblue. So for example, you could run an arch environment where you basically had a full access to everything arch can do. You can also run a full Fedora environment where you could have access to basically anything Fedora can do outside of the Fedora Silverblue environment. So you could use DNF to install anything that you wanted. You could do a whole bunch of testing in terms of like development work and stuff like that. The idea behind toolbox is that there's another container system that allows you to interact with your machine in a way that Silverblue doesn't really allow. Now I'm going to make another video on toolbox itself because it does really deserve its own video. But basically what you need to know is that toolbox is another container system that allows you to install software and complete other distros in a containerized environment for testing and development purposes. One of the benefits of this is that it allows you to install basically anything. Because like I said, you can't really do that on Fedora Silverblue. Now there are or there is a big exception to that and I'll talk about that here in a minute. But if you want to do anything that interacts with that base level system, you really can't do that. So you would open up a toolbox and then deal with that environment where you could interact with a distro that has access to those base level files and such. And you can do that because it's a container and you can basically do anything you want with it. And then once you're done with it, you can dispose of it if you need to. And the idea there is that you can do your development work or whatever you need to do without compromising the security of your immutable system. So that all leads us to the next question of what happens if the application that you need needs to be on your base system so a toolbox isn't going to be working for you. But also it's not a flat pack. You want to say install them or neo them or neo fetch or, you know, Ranger or something like that. What do you what happens if you want to install those things? Well, you can do so because you do have access to a package manager that will install things on your system. And that is RPM OS tree. Now RPM OS tree is a very important part of Fedora Silverblue. And we're going to spend a little bit of time talking about what it is and what good it does. So this is all going to play back into the term immutable. And I'm going to try to tie it all together. We'll see how I do. So in terms of application installation, RPM OS tree functions somewhat similarly, similarly to DNF. I say somewhat because it's not one to one. And it does a whole bunch of other stuff that DNF doesn't do for obvious reasons because it has to deal with this immutable aspect. So in terms of actually installing applications, you can run RPM OS tree without pseudo because it doesn't deal with anything in the root file system. This is just installing stuff for your system user. So you don't have to have pseudo. So you do RPM OS tree install, say them or neo them or whatever, and it would just install it. The thing that's different here is because it's making a different version of the user layer that sits between your user files and that base level, you have to restart your computer. So every time you install something via RPM OS tree or you do an upgrade using RPM OS tree, you have to restart the system because it's making changes. So the best way to think of this is that there's that bottom layer that we've been talking about the bottom. That is read only. You don't make any changes to that. Every time you do an upgrade to a new version of fedora, those files are changed, but it still remains immutable, right? And then in the middle, there is a section of there's another layer that interacts with your user files and the applications that you've installed via RPM OS tree. And these two layers are the two layers that you interact with the most. It's a little complicated. But basically what it does is that any time that that middle layer is changed via RPM OS tree, you have to do a system reboot. It's that middle layer that RPM OS tree deals with when it installs applications. So anything that you install kind of ends up there. Now, like I said, in terms of like the technical aspect of this three layer situation, it's a little bit beyond me. Because it takes a little bit of it takes a while to get your mind around what this stuff is actually doing. And as long as you can kind of keep in mind that that bottom level stays the same all the time. And the top two layers are the things that you are always interacting with. You can kind of get a sense of how this works. And because each layer specifically the top two layers and the bottom layer are never really interact. That's where the security comes from, right? So you can use RPM OS tree to install basically any application that is available in the fedora repos. I say basically any application because it's not 100%. Right. So things like Neo Vim and Vim and Ranger and stuff like that all that stuff that works in the terminal is just fine. It's when you get into things that you'd be able to install like I three window manager or something like that. That that's not going to work because that would have to have access to that bottom level in order for it to work. And it doesn't have access to that. So running I three or, you know, something like herpes loft or any other window manager that is in the normal fedora repository is like normal. You wouldn't actually be able to install those and have them work because they don't have access to that bottom level because that bottom level is read only. You can't install anything to it. So installing applications is actually just a small part of what RPM OS tree does. RPM OS tree is also responsible for the snapshotting of your system when you do install or update your computer. So rollbacks and snapshots are a big deal when it comes to an immutable system. And it's one of the biggest features that is user facing. It's not doesn't have anything really to do with the big IT guys who have to deal with a whole bunch of systems, even though it's a benefit to them too. Before a single person who wants to use this rollbacks via RPM OS tree are a big deal because it allows you to go back to a certain snapshot of your system if something were to go wrong. So there are two types of rollbacks. One of them is temporary. So when you boot into your computer, you're presented with a grub screen. And if you've done any type of installation on your system in terms of RPM OS tree or any updates, you're going to have different snapshots available to you in that grub menu. And you can select a later version of your system and boot into it. That's a temporary rollback because if you were to then reboot again, the newer version or the newer snapshot is available to you also still through grub. So you can switch between them if you want to that's a very neat feature. Those don't go away. As far as I can tell from the documentation, there are three snapshots available to you at any given time. I'm not sure if that's configurable or not. I didn't look into it that far, but there are at least three available to you at any given time. So that's really nice. And that's temporary, right? So you can go back and forth between them. The other version of rollbacks is permanent. And you can see that in the B roll that I'm showing now. Basically, RPM OS tree allows you to permanently rollback your system from one snapshot to another. So basically what this does is let's just say you installed NeoFetch or NeoVem or whatever and you wanted to rollback from before you installed those. You could use RPM OS tree rollback to rollback to the system before those things were installed or before your system was updated. Now, obviously this only works if you have a snapshot from one update to another. So it's going to take you from update. Basically the snapshots are created whenever your system is updated and you could rollback from one place to another as far as I understand it. So that allows you to basically ensure that if something goes wrong with your system because you installed something via RPM OS tree, you can go back. Or if an update messes with your system, you can go back. So this is a very big feature if you are going to be tinkering with your system beyond what it's meant to do. So you can protect yourself from any mistakes or any bugs that do happen to come along and then go back to something that worked previously if something breaks. So that's a big deal with RPM OS tree. So how does all that rollback stuff work? Basically RPM OS tree allows fedora silver blue to create what the documentation calls a get like model for making changes to the underlying systems. So basically what that means is that when you install or upgrade packages via RPM OS tree, it creates a versioned checksum upgrade of those packages. So when you do an installation of a package or you do an upgrade to your system, it's going to create basically a version of your system as it does those changes. So that you then use those that version of your system for as long as it works. And you could if you want to rollback just like you could rollback in a get repository if you wanted to go back to previous changes based on the version that you created at the time of your push or pull. Right. All of this stuff happens without affecting that lower level read only system that we talked about when we talked about the immutable stuff. So any changes that you make the RPM OS tree are in that middle section that we were talking about. And because it's using a get like versioning system, anytime you make a change, you can go back to it. And that there are several different versions that it keeps and allows you to move between them either permanently or temporarily like we said. So let's talk about bottom line here. There's obviously a lot more that I could go into and a lot of this stuff was very surface level. And I hope that it helped you kind of get an idea of like a brief idea of what Silverblue is. No doubt that there are more technical explainers out there, more technical teachers out there that would do a better job than I did. But I'm hoping that the base level stuff that I talked about at least gives you a sense of how this stuff works. So let's now answer the question. Is it good? Is it bad? Is it the future? I guess those are three questions, right? The idea behind Silverblue I think is a good one. So the idea is that a new user would come in, they'd use Silverblue and they wouldn't have to worry about upgrades, breaking things that have to do with your user system interacting with that base level. So any upgrades that change a version of say like a package or whatever are done independent of whatever user files you have. So when you do an upgrade from one Fedora Silverblue version to another, it's that bottom level that is switched out. And your user levels, your two user levels that are handled by RPMOstry are left alone, right? The flat packs and stuff like that are all containerized. They never interact with that bottom level. So when you do an update, it's just that bottom level that gets swapped out. And in theory, that keeps your system more stable because nothing is interacting between those two levels. And while the stuff in the top two levels are ever changing because you're always installing new stuff, and the bottom levels in theory not ever changing, there's no interaction between them. So technically, nothing can break between an interaction between those three levels because they don't really ever interact. Now in practice, this is going to be good for some people, bad for some people. So let's talk a little bit about the good stuff. So the good stuff, if you're just a regular Joe Schmoe user, you're an amazing person, and all you do is messing around with the browser and stuff like that. You're not a technical Linux user. You don't care about tweaking or customizing or messing around at the root file system or any of that stuff. You don't care. That's not anything. That's not why you're using Linux. If you're that type of person, Fedora Silverblue or other immutable operating systems are fantastic for you because you don't have to worry about any of this stuff. Really, you're just there to use the operating system. And in theory, it should be more stable for you because of the things that we've already discussed in theory, right? And if you are the type of person who just uses, you know, your browser and your email client and stuff like that and you're perfectly happy living in flat pack world, you're going to like Fedora Silverblue because it's actually just Fedora workstation, but with some underlying changes, right? Chances are you won't ever have to deal with RPM Austria, but you'll still have the protection of it if you ever do, right? Because the software manager uses RPM Austria in the background. So you're going to have all the snapshotting and rollback features that it enables, but you don't ever have to worry about it unless something goes wrong. So if you're that type of person, Fedora Silverblue can be really good for you, right? It's the tinkerers out there where immutable starts to become a bad thing. So if you're the type of person who likes to install a window manager on your machine and you don't want to use a spin or whatever, doing so is basically impossible with Silverblue. Now, I say basically impossible because you can roll your own. There is a way to make your own immutable version of Fedora if you wanted to do so. It's just done before you install, right? So there's a way to make an ISO that's basically your own and then you can basically have a spin of your own Fedora Silverblue if that's what you wanted to do. I'm pretty sure that stuff is still pretty early days. I haven't really looked into it. I just know that it exists. But if you have already installed Fedora Silverblue and you want to make those types of changes that you're probably used to doing, then Fedora Silverblue is not going to be as big. It's not going to be as great for you because you can't make a lot of those changes, right? You can't install a new display manager or anything like that, at least as far as I'm aware, right? You can't install new window managers because that's just the way this is working. If you're using Fedora Silverblue, you're going to be stuck with GNOME. Now, again, not a big deal if you're not the type of person who likes to tweak things and install things like that. But if you are the type of person, this seems like a limitation for you because the idea behind Linux is that you have freedom, right? Freedom rings. It's free and open source software. When we talk about free, we're not talking about free as in cost. We're talking about freedom. You're supposed to be able to do whatever you want to do. Now, the problem with immutable systems like Fedora Silverblue is that you don't have 100% freedom to do whatever you want because that base level is read-only. You're not supposed to interact with it. You can actually interact with it, which means that there are certain things that you just can't do, right? Now, again, that's not a huge deal because the great thing about open source is that there are 9,000 different distros out there and only a few of them are immutable, right? So you're not going to have to... If you can't do the things you want to do on Silverblue, it's very easy just to go use Archer, Ubuntu, or whatever. You can very easily do that. And that's kind of the way things are supposed to work, right? If you can't do the things you do with its use case, then you just move on to something different. So the horrible idea of is it good, is it bad really depends on how you use it. If you're just going to use it without having to worry about any of the tinkering stuff, Fedora Silverblue can be very good for you. Now, way back last year, I did a long-term review of Fedora Keenowite. Now, Keenowite is the KDE version of Silverblue. Or it's a KDE version of the immutable part of Fedora, right? Now, my experience with that was that basically KDE wasn't a... It really wasn't ready for the immutable aspect, right? There was some interaction with KDE's that just didn't really feel like it worked very well with the immutable operating system. Some of that might just be that KDE is buggy, but it just didn't really feel like KDE worked well on the immutable aspect of Fedora. With the workstation or the Fedora Silverblue version, I had no problems whatsoever when it came to stability or whatever. It worked really, really well on my laptop, and I've been trying it now for three or four weeks. It's been on there for a while. It just really, really worked. Most of the stuff on my laptop, I don't do anything special with it. I didn't even really notice the immutable aspect of the Fedora Silverblue unless I was doing something for this video. It really was a fairly good experience. Like I said, if that's the type of work that you do, you just want to mess around with the browser or deal with flat-pack applications, you're going to be doing just fine. The only other real downside that I wanted to talk about is that when you install something via RPM OS tree, you do have to restart your system. That's a big... I'm not going to say problem, but it's a big deal for me because it just gives me nightmares. And the reason why it does is because if you've ever used Windows before and basically everybody has, you know that there are certain applications that you install in Windows that require you to restart your system. And Windows is big on rebooting, right? Every time you do an update to Windows, you're basically forced to reboot. Every time you install a driver for Windows, you're basically forced to reboot. If you make any changes to the registry, you're going to be forced to reboot. If you install just random software, sometimes you're going to be forced to reboot. It depends on how it interacts with the Windows kernel and the Windows registry and all that stuff, right? Now, obviously there's technical reasons why that's the case, but if you've ever used Windows before, you know how often you have to reboot your system and how often you're basically forced to do so. Now, with RPMOS tray, you're not forced to do so. You can install something, like save them and not restart your computer. You can continue to use it, but them isn't actually installed until you reboot your system. So that whole rebooting stuff just kind of rubs me the wrong way. It's not that big of a deal, but basically what I found myself doing was when I knew I had to install something from RPMOS tree, I would just install it or I would kind of like save it until I had a whole bunch of things that I wanted to install and then do a reboot after I installed like three or four packages and then reboot and have all of them done and just so I have to only reboot once, right? If you are just setting up Silverblue and you install things one by one and restart after every single one, first of all, don't do it that way. Install all of them and then reboot. But if you like forgot something, you can find yourself rebooting three or four times right after you get your system up and running and that can kind of, I don't know, it's not a great experience all the time now. Obviously, like I talked about before, there are technical reasons why they have to do this, but it's still an experience that I don't really care for all that much. For me personally, I just didn't really like it all that much. So that's one aspect that I wanted to talk about. So at the end of the day, Fedora Silverblue is a very interesting distribution and a very interesting idea. Now it's obviously not the only immutable operating system out there, it's not even the oldest one. NixOS and there's Geeks and there is OpenSUSA has one, there's a new one that just came out based on Ubuntu. There are several of these immutable operating systems out there. A lot of them use RPM OS tree, some of them use something different, but they all have the same general idea where they have that base level that is read-only and you're not supposed to interact with it and then you have the layers on top, right? Those are the basic ideas of every immutable operating system, although some of them tweak it somewhat. So is this the future? Is this where we're going? Now I think that distro maintainers, at least a lot of them, would love it if everything was immutable because it makes their job a little bit easier because every single ISO that they have is based on this one image. Everything in that base level is going to be the same for everyone that is running that version and that makes their job way easier. So I think that a lot of distro maintainers would like it if immutable became a thing. I also think that a lot of them don't really care for it. So immutable is a very polarizing aspect and whether or not it's the future, I think it's going to be one of those things just going to be an option. So you're going to be able to use the regular version of Fedora if you want to. You're going to be able to use Silverblue if you want to. They're both going to exist side by side for the foreseeable future. I don't foresee a situation where Fedora ever replaces the workstation version of Fedora at least anytime soon. I would say that those things are both always going to exist for quite a long time and even if Fedora were to say the workstation is going away and they're just going to use Silverblue, there are always going to be other distros out there that won't be immutable because there's always going to be a community surrounding distributions that are open for you to do basically whatever you want and immutable is not quite that. So that is it for this video. I hope I did a decent job of explaining what this is and if you have any questions you can leave those in the comment section below. I'll try to answer them or point you towards resources where you can get more answers if you have fairly good documentation so I will link to that in the video description as well. So thanks for watching. If you want to follow me on Mastodon or Odyssey those links will be in the video description. You can support me on patreon.patreon.com slash Linuxcast. Links for YouTube and Liberapay will be in the video description as well. Thanks to everybody who does support me on Patreon and YouTube because you're all absolutely amazing. Without you the channel just should not be anywhere near where it is right now so thank you so very very much for your support. I truly do appreciate it. Awesome. Thank you for watching. I'll see everybody next time.