A few newbie questions about Silverblue (and immutable systems in general)

[blind-confused (blind)]

hi, I’m considering changing from Workstation to Silverblue, but I had a few newbie questions before I do that (I’ve never used an immutable system before). I’m sorry if my questions are really common (or just silly). Also I’m sorry that there are so many of them. I just rly don’t feel like reinstalling my system just to run into some issue that makes me go back, so I just wanna know for sure before doing it.

1. I heard something along the lines of rpm-ostree being discontinued and replaced with some other things. Does this mean that there will be changes applied to Silverblue soon, and I should wait until that’s done before installing it? What will the commands for system updating and package installing/removing look like, after the changes take place? (I don’t prefer to use the gui software center)

2. for installing and running new flatpaks, is it also necessary to restart the system, like with layered rpm packages?

3. what about appimages, do they work fine on Silverblue?

4. speaking of flatpaks, is it generally recommended to install GNOME extensions as flatpaks, or as rpm’s? Any downsides or concerns about either method?

5. there are several apps (including important things like a browser) where the devs themselves say “sadly, out flatpak version is not as stable yet, so we recommend to install an rpm”. Apart from that, I’m also interested in installing quite a few apps as rpm’s (out of my preferences). I heard that in Silverblue, the way you install rpm’s is some sort of layering. Are there any downsides or difficulties to it, compared to a regular rpm install? Or is it just as easy and reliable as regular rpm installs on Workstation? If there are downsides to it, are there any other ways to install rpm’s on Silverblue?

6. are there any concern / issues from the fact that system packages are installed into a different directory than they would be on a regular Workstation? Like, do apps ever break because of this? Because I heard that sometimes you will install an app, but the resources / dependencies needed for it to work just aren’t there. I also heard some apps, like printing software (which I wanted to use), expect to be able to write to the immutable directories, but are unable to. So… are things like that still an issue? Are there workarounds? Generally, do apps designed for Workstation work well on Silverblue (I mean rpm’s, not flatpaks)?

7. are the system updates automated (downloaded in the background for me)? If yes, is there a way to disable that, and make them only download when I start the download? (a daily or even a weekly automated timer is not what I’m looking for)

8. generally, is Silverblue made to be more minimalistic compared to regular Fedora? Or does it have all of it’s features? (I know that CoreOS, for example, is said to be minimalistic, but idk whether that applies to Silverblue as well)

9. can I install COSMIC desktop on Silverblue, and have it there alongside GNOME? Or will that bring issues if I try to do that?

10. generally, is Silverblue… fullly ready? I mean, are there any unfinished work-in-progress parts to it, or is it just as finalized as Workstation?

11. will I still be able to disable services with systemctl like I am able to do on Workstation?

12. are containers (distrobox, toolbx, etc.) and the apps in them still within the scope of my firewall (which is installed on the main system)? Or does each container use it’s own firewall?

13. generally, are containers (distrobox, toolbx, etc.) similar to vm’s in terms of resource intensity? Or do apps in containers take just as much resources as regular rpm’s would?

thanks to anyone willing to answer this, and I’m sorry again for how many questions I wrote

[hricky (Hristo Marinov)]

I suggest you read the Fedora Silverblue User Guide :: Fedora Docs if you haven’t already.

[tqcharm (Mike B.)]

While I’m still using Workstation, I’ve switched to Silverblue as my main Fedora driver, so here’s some input:

@blind-confused

I heard something along the lines of rpm-ostree being discontinued and replaced with some other things.

There will be some change towards bootable containers as far as I know, but it would be a pity to wait for an undefined period of time. I haven’t seen a roadmap yet, and when the move will take place, I expect to be able to upgrade from one image system to the other.

@blind-confused

for installing and running new flatpaks, is it also necessary to restart the system

Flatpaks generally don’t need restart.

@blind-confused

speaking of flatpaks, is it generally recommended to install GNOME extensions as flatpaks, or as rpm’s?

I recommend only using GNOME extensions scarcely, as many of them tend to break the system. My approach generally is to install GUI apps as flatpaks, except when a tighter system-level integration is needed. E.g., I have installed a theme for legacy GTK apps via RPM-OSTree layering.

@blind-confused

I heard that in Silverblue, the way you install rpm’s is some sort of layering. Are there any downsides or difficulties to it, compared to a regular rpm install?

Every layering action will generate a new deployment, which is generally more time-consuming. After that, the system should be as stable as their traditional counterparts. However, the more layered RPMs, the more time each upgrade will take.

@blind-confused

are there any concern / issues from the fact that system packages are installed into a different directory than they would be on a regular Workstation?

I haven’t experienced that. Could be with apps that don’t follow XDG and other directory specifications.

@blind-confused

are the system updates automated (downloaded in the background for me)?

Only if you go with GNOME Software. You can disable automatic updates there, and go with the command line, using rpm-ostree upgrade.

@blind-confused

generally, is Silverblue made to be more minimalistic compared to regular Fedora?

It’s rather a different approach. The OSTree image is reduced to initrd, kernel, system apps and libraries, GNOME Shell and a few other components, while the rest of the “base install” is provided via Flatpaks from Fedora’s own remote (not Flathub), mainly GNOME’s core apps (Contacts, Calendar, Evince, Baobab etc).

@blind-confused

can I install COSMIC desktop on Silverblue, and have it there alongside GNOME? Or will that bring issues if I try to do that?

It’s easier to try rebasing to a different branch.

@blind-confused

generally, is Silverblue… fullly ready? I mean, are there any unfinished work-in-progress parts to it, or is it just as finalized as Workstation?

I would say it’s as polished as Workstation, but you have less flexibility (and therefore smaller chances to break your system).

@blind-confused

are containers (distrobox, toolbx, etc.) and the apps in them still within the scope of my firewall (which is installed on the main system)? Or does each container use it’s own firewall?

I would suggest starting to get familiar with Toolbx first, given that it’s included in the base install. Containers are certainly less resource-intensive than VMs.

As a general advice, I would strongly suggest to install Silverblue in a virtual machine first, which will really help you figure it out if this is for you. You can also try all kinds of experiments before moving to a bare-metal installation.

[katflap (Jasper)]

@blind-confused

what about appimages, do they work fine on Silverblue?

Haven’t actually tried it, but I don’t see why not.

@blind-confused

is it generally recommended to install GNOME extensions as flatpaks, or as rpm’s

I can’t find any gnome extensions in flathub or fedora flatpaks, and considering that they work by directly modifying GNOME Shell’s code… I doubt that is really going to be a thing in the immediate future. You should probably just use something like Extension Manager from Flathub, which I think puts the extensions somewhere in your home folder or /usr, so they’re neither flatpaks nor rpms.

[blind-confused (blind)]

@hricky

I suggest you read the Fedora Silverblue User Guide :: Fedora Docs if you haven’t already.

yeah… that’s probably true I’ll give it a read. I still feel like some of my questions are too specific for it, but it can help with the rest of them.

@tqcharm

I haven’t seen a roadmap yet

hm, so that means for now we still use the rpm-ostree commands like usual, to manage packages and images?

@tqcharm

I recommend only using GNOME extensions scarcely, as many of them tend to break the system.

yeah, I use few of them. I was just wondering, because nowadays everyone recommends that blue app called “Extension manager”, but it;s missing in Fedora’s rpm repositories, we only have the classic green one, called “Extensions”. So I was just confused as to which one to use, especially since an extension seems like something that’s supposed to integrate into the system, so why would it be a flatpak, which is separate from the main system, no? idk…

@tqcharm

the more layered RPMs, the more time each upgrade will take.

any time estimates for that? Like… if I have 2 or 3 layers, how much longer would it be?

@tqcharm

The OSTree image is reduced to initrd, kernel, system apps and libraries, GNOME Shell and a few other components, while the rest of the “base install” is provided via Flatpaks from Fedora’s own remote (not Flathub

so if you say it’s “reduced”… does that mean that it has less features/parts than Workstation?
I’m just asking because, if that’s the case, I wouldn’t prefer that… I don’t like minimalistic systems like Arch, I want my system to be fully feature complete (and not require me to make it happen manually, like Arch does, since I’m not tech savvy). I’m just worried because Fedora docs say “Fedora Silverblue uses the same core technology as Fedora CoreOS”, and the official Fedora website says that CoreOS is a minimal system

@tqcharm

I would strongly suggest to install Silverblue in a virtual machine first, which will really help you figure it out

well… my laptop is a bit potato, I don’t know if it can handle vm’s very well haha. Probably would have really reduced performance. But I guess I could see if some stuff works or not.

@katflap

I can’t find any gnome extensions in flathub or fedora flatpaks, and considering that they work by directly modifying GNOME Shell’s code… I doubt that is really going to be a thing in the immediate future. You should probably just use something like Extension Manager from Flathub, which I think puts the extensions somewhere in your home folder or /usr, so they’re neither flatpaks nor rpms.

yeah I’m sorry, I didn’t realize that I worded it wrong. By “extensions as flatpaks” I meant extensions from the blue app called “Extension manager”, which is missing in Fedora’s rpm repositories, so it’s only available as a flatpak, and that’s why I assumed that extensions installed with it are also “flatpaks”. The other way would be to install the classic green “Extensions” app as an rpm, and install each extension as an rpm as well (which is what I’m currently doing)

[katflap (Jasper)]

@blind-confused

does that mean that it has less features/parts than Workstation?

No, it’s pretty much the same. I think he was just pointing out that the image/immutable part is kept somewhat small (basically Workstation with some apps removed), and the rest of the apps are flatpaks. But the overall image+flatpaks should be pretty much the same as Workstation (or maybe some apps missing, like LibreOffice perhaps, but that would simply require you to install the apps you want). The actual OS has just as many features as good old Workstation.

@blind-confused

The other way would be to install the classic green “Extensions” app as an rpm, and install each extension as an rpm as well (which is what I’m currently doing)

You could probably still do this with rpm-ostree too.

[blind-confused (blind)]

@katflap

You could probably still do this with rpm-ostree too.

I wonder if either of the methods is “intended” or “unintended”. Because knowing that each layer of rpm-ostree packages increases updating time, makes me more inclined to use the flatpak app. Which btw, I rly hope that the time increase isn’t a lot, because I wanted to layer quite a bit of packages like my 2 browsers (one of them is the default Firefox though), several video editors + players, and a few picture editors… I wonder what would my update time look like

[boredsquirrel]

1. The systems use ostree, which is pretty cool and similar to git. But it is kinda a duplicate efford with what container people are already doing. The rpm-ostree tool will still be used, you can rebase from an ostree-based system to a container-based system, so no, you dont need to wait
2. no, everything is like everywhere else. Only RPM packages are different.
3. Yes, but you might in general want to use a manager tool like appman. Not specific to atomic
4. GNOME extensions are neither flatpak nor RPM. Some may come as RPMs, none as flatpaks
5. Browsers should be installed as RPMs for security reasons. The browser sandbox, which they need to isolate the most vulnerable part of your OS (random javascript code running from dozens of domains for every site you visit). Install browsers as RPMs. See my helper script. Layering is fine, you can layer as many packages as you want and will still have a more stable system than regular workstation.
6. they are installed in the same location
7. Not sure, should be automatic for flatpaks and RPMs. There is a systemd service, but GUI stores handle it. UBlue does it automatically in the background, which you likely prefer. Use their tooling if possible.
8. Yes it contains way less RPM packages. Hardware support is the same. Just less apps. Some are preinstalled as fedora flatpaks. You may want to replace those with flatpaks from flathub
9. you can layer COSMIC packages on atomic desktops yes. There is a COPR by @ryanabx . To use the greeter (login manager) you need some more changes. You can use COSMIC apps on GNOME or the entire COSMIC desktop. I currently use the media player and terminal, but they are not comparable to Konsole and Celluloid which I normally use
10. Yup, last major issues were fixed with automatic updates for the bootloader
11. Yes, systemd services are in /etc/systemd/ and /etc is writable, like /var (and /usr/local which is actually /var/usrlocal/)
12. Not sure, they are likely just blocked? You shouldnt really need containers for lot of apps. Even QGis works now as a Flatpak
13. Containers use more RAM than native but the system kernel. They are the same speed as other apps. Virtualization is more secure but way slower, often lacking any GPU acceleration. Apps in containers are packages of the distro you use, so Debian, Ubuntu, Fedora, OpenSUSE, Arch, Gentoo, Alpine… and they are the same but you need a small OS as dependency of those apps. composefs might change this some time in the future

[blind-confused (blind)]

someone actually spent the time to answer each one wow. Thank you a lot haha. This is actually very useful to me.

@boredsquirrel

4. GNOME extensions are neither flatpak nor RPM. Some may come as RPMs, none as flatpaks

yeah, this one… I didn’t realize I was explaining it wrong. What I meant is, there is a classic green app called “Extensions”, which is available as an rpm, and then there’s this new fancy blue one called “Extension manager”, which is not available as an rpm, only as a flatpak. So I thought that the extensions installed with it are also “flatpaks”. And I was wondering if that is intended or not (since I thought extensions are something that integrates into the system, and flatpaks are a bit opposite from that).
right now I’m using the classic green app, with each extension installed as a separate rpm, just because that seems more reassuring.

@boredsquirrel

5. Layering is fine, you can layer as many packages as you want and will still have a more stable system than regular workstation.

that’s very good to know.
although people are warning me about increased update times. I hope it doesn’t go too far. I don’t mind a few more minutes, but if it’s something like +10 minutes or more, that might be a bit of an issue.
I was going to layer several video editors and players, and some picture editors. Hopefully it would go fine.

@boredsquirrel

6. they are installed in the same location

are they? I mean, I was watching one video that said: “you can use layering to install rpm’s just like you would on a regular Workstation, but instead of being installed in your usr bin directory, they’ll be installed in a usr writable section of memory, which is mostly going to be fine, but just like using aur, sometimes you’re going to install an overlay package and what it needs to run is not going to be available in that current image.”

@boredsquirrel

7. Not sure, should be automatic for flatpaks and RPMs. There is a systemd service, but GUI stores handle it.

should be automatic?
even if I disable auto updates in gnome software? (I usually use the terminal to update anyway)

@boredsquirrel

7. UBlue does it automatically in the background, which you likely prefer. Use their tooling if possible.

nope, I actually prefer non-automated updates, and generally I prefer Silverblue to what the UBlue team is doing (it’s a different topic, so I’m not going to get into the reasons why). But hey, at least I have no Nvidia parts to my computer, so using regular Silverblue should be fine.

@boredsquirrel

8. Yes it contains way less RPM packages. Hardware support is the same. Just less apps.

okay. I just hope no parts of the system itself are removed, like it’s not a minimal system like CoreOS (or Arch-based distros, I guess), and is rather a fully featured experience like Workstation. I was just concerned because Fedora docs say “Fedora Silverblue uses the same core technology as Fedora CoreOS”, and the official Fedora website says that CoreOS is a minimal system. So I hope that doesn’t apply to Silverblue.

@boredsquirrel

12. Not sure, they are likely just blocked? You shouldnt really need containers for lot of apps. Even QGis works now as a Flatpak

well, the only reason I was considering containers at all is because people said the update times increase quite a bit, the more layered packages there are.

@boredsquirrel

13. and they are the same but you need a small OS as dependency of those apps.

you mean a minimalistic version of whatever distro I’m using for the container? That sounds like it could be less secure, if it’s removing a lot of system parts…

[tqcharm (Mike B.)]

@blind-confused

hm, so that means for now we still use the rpm-ostree commands like usual, to manage packages and images?

Yes! rpm-ostree for upgrades, package installations, rollbacks etc.

@blind-confused

I was just wondering, because nowadays everyone recommends that blue app called “Extension manager”, but it;s missing in Fedora’s rpm repositories, we only have the classic green one, called “Extensions”.

The “classic”, green Extensions app is installed by default, and it works just fine. You can install extensions from https://extensions.gnome.org just as you’d normally do on Workstation.

@blind-confused

any time estimates for that? Like… if I have 2 or 3 layers, how much longer would it be?

I didn’t run benchmarks (with and without layers) to see the actual difference. As a rough estimate, I would say that for every layered package the time for such package and its dependencies to be upgraded on a traditional system should be considered. But it doesn’t really matter that much, given that you run the rpm-ostree upgrade command in a terminal session and carry on with whatever task you’re performing. The upgrade doesn’t affect the booted system (deployment), and the new deployment will only be loaded after a restart, whenever that may seem fit.

@blind-confused

so if you say it’s “reduced”… does that mean that it has less features/parts than Workstation?
I

It’s a full-featured system, only that its components are divided between the base image and Flatpaks, as already noted above.

@blind-confused

I wanted to layer quite a bit of packages like my 2 browsers (one of them is the default Firefox though), several video editors + players, and a few picture editors…

Most of the mentioned GUI apps are good candidates for Flatpaks, rather than layered packages.

Remember though that you can’t tweak the system as easily as you would do on Workstation or another non-atomic system. If possible, a VM, or even a temporary install on an external SSD would help at this point more than any additional advice here.

[blind-confused (blind)]

@tqcharm

I would say that for every layered package the time for such package and its dependencies to be upgraded on a traditional system should be considered.

oh well if it’s mostly like regular updates, then I don’t care about it. I mean it doesn’t take long, and I have to do it anyway, so.

@tqcharm

Most of the mentioned GUI apps are good candidates for Flatpaks, rather than layered packages.

true, I just prefer rpm’s for them, due to my own reasons. But I would consider flatpaks if it gets really problematic to install them as rpm’s.

@tqcharm

Remember though that you can’t tweak the system as easily as you would do on Workstation or another non-atomic system.

well, thankfully I don’t really tweak almost anything. Just about 5 extensions, some icons, a different default sound effect, a wallpaper, some apps. Some tweaks to my browser (within what it’s gui provides, usually). That’s about it.

[tqcharm (Mike B.)]

@blind-confused

oh well if it’s mostly like regular updates, then I don’t care about it. I mean it doesn’t take long, and I have to do it anyway, so.

Not exactly. What I was describing is in addition of downloading (chunks of) the latest OSTree image and creating a new local deployment.

[blind-confused (blind)]

@tqcharm

Not exactly. What I was describing is in addition of downloading (chunks of) the latest OSTree image and creating a new local deployment.

oh so you’re saying I will need to redownload the entire OS with each regular system update? (sorry if I’m getting it wrong lol)

[tqcharm (Mike B.)]

@blind-confused

oh so you’re saying I will need to redownload the entire OS with each regular system update?

No, it only downloads parts of the image tree that need to be upgraded.

I have made a comparison between two VMs with the same specs, installed on the same host: one with F41 Workstation and the other with F41 Silverblue (with only three small packages layered), both systems upgraded 10 days ago.

An rpm-ostree upgrade issued on Silverblue downloaded some 20% more data than a dnf upgrade --refresh command on Workstation, however, Silverblue finished the transaction some 10% faster than Workstation.

On the other hand, if we add Flatpaks into the equation, and assuming that both systems have some Flatpaks installed, then Workstation wins here, but not by much, given that the Flatpaks with higher size are the application runtimes, available on both systems, even if there are more user applications on Silverblue. It’s a different story if one doesn’t use Flatpaks at all on Workstation.

So overall, I wouldn’t consider the time taken to upgrade the OS a significant criteria that should favor the decision towards one system or the other.

[blind-confused (blind)]

that is a very detailed comparison haha, thank you for that.
I was mostly just thinking “if people feel the need to warn you about longer update times when you install more layered packages, then it must be significantly longer, to the point of it being a problem”
but sounds like it’s not the case, and I’m really glad to hear that. It was one of the biggest things stopping me from using Silverblue.
(I know it’s intended to be used with flatpaks for keeping your system clean, which is what I like too, but I have a need for some of my apps to be rpm’s, and if there was no need, I would happily use flatpaks for like any app).

[siosm (Timothée Ravier)]

Some clarifications:

@tqcharm

I haven’t seen a roadmap yet

The roadmap is at Roadmap to Fedora Bootable Containers (#26) · Issues · fedora / Fedora Atomic Desktops / SIG Issue Tracker · GitLab.

@tqcharm

when the move will take place, I expect to be able to upgrade from one image system to the other.

Yes, this is part of the roadmap.

[boredsquirrel]

4. The extensionmanager is better, the old extensions app is obsolete. Flatpaks can place files in your home folder if they have the permissions. Install flatseal and have a look, harden your apps if you want, to get to know them better. GNOME extensions are not flatpaks, but installed per user, outside the system and thus not touched by rpm-ostree. Actually that contributes to “state” buildup, is not easily reproducible and could cause breakages. So be aware if you install extensions, that you trust them, or test them on a separate user account (that is not in the wheel group)
5. I layer like 20 packages with even more dependencies. It works. It is not great of course, but works fine. It saves bandwidth compared to using toolbx/distrobox (which is better btw), as you dont maintain a separate system. For video players, try Celluloid, it is great. I maintain a repo of recommended apps on github but it needs an overhaul.
6. that was wrong then. rpm-ostree is the replacement for dnf, does some extra stuff but installs packages in the same directories. Actually there is work on making dnf work for the newer bootc technology, the container tool you mentioned that will replace rpm-ostree some day. When installing a package, a clone of your system is created and the package is installed there. Then that image is set as the next boot target, so if you reboot, you boot into that image. There is a way to install packages without rebooting, and to test packages which will be gone after rebooting, but those are not the common way.
7. Updates go through the GUI stores. If you disable them there, they are not done automatically. you can do them automatically, I am not motivated enough to fix my systemd service (that respects battery state, network metered state, CPU load, idle time…) so I have an alias to do an update and then shutdown. If you do manual updates there is often some issue you try to prevent by that, and you may want to address that to have it work. The GUI stores are supposed to respect that, but I also am not a fan of them.
8. Fedora Atomic Desktops have the same core system, as I wrote. Just less additional stuff.

12. Yes layering increases update times, BUT with toolbx you have no way to easily update all containers so they might become outdated, and you have 2 separate systems, storage space, bandwidth usage, time. I doubt that is way faster than just layering.

The issue you try to prevent by layering is state buildup through layering. Apps can place files in /etc and more which are not managed by rpm-ostree/dnf and can result in weird stuff happening over time

The goal is to have a managed system where you can get to a new state with no custom stuff + the changes you want and need at the current time and nothing more

13. Read into containers. It is just the kernel and firmware and stuff missing. Not less secure.

[blind-confused (blind)]

@boredsquirrel

4. the old extensions app is obsolete.

as in, discontinued?

@boredsquirrel

4. Install flatseal and have a look, harden your apps if you want, to get to know them better.

been always hesitant to do that, I’m really not tech savvy, I don’t code and don’t know too much details of how things work, so… I feel like I’ll probably break something. With a lot of permissions in that app, I read them and I have no clue what they’re about. At least I can still easily disable access to things like microphone, etc.

@boredsquirrel

4. GNOME extensions are not flatpaks, but installed per user, outside the system and thus not touched by rpm-ostree.

hopefully they’re still updated then, since I don’t use the gui app store for updates, I just update my flatpaks though cli. I guess extension manager will probably take care of the updates.

@boredsquirrel

4. that contributes to “state” buildup, is not easily reproducible and could cause breakages.

well, I stick to just a few, which are pretty popular, and I never had them break yet, so it should be fine.

@boredsquirrel

5. It saves bandwidth compared to using toolbx/distrobox (which is better btw), as you dont maintain a separate system.

you mean, layering is better than toolbx/distrobox?
it’s great to know it saves bandwidth.

@boredsquirrel

5. For video players, try Celluloid, it is great. I maintain a repo of recommended apps on github but it needs an overhaul.

yeah I’ve been using it for a while, I like it the most, but I’m still the person that downloads several other players just in case I need support for other formats or something
thanks for the recommendations, I’ll probably take a look later.

@boredsquirrel

5. I layer like 20 packages with even more dependencies. It works. It is not great of course, but works fine.

speaking of, there should be no difference between layering all my rpm’s in a single command, and layering each one as a separate command, right?

@boredsquirrel

7. If you do manual updates there is often some issue you try to prevent by that, and you may want to address that to have it work.

wdym exactly?
you’re saying, I should try to figure out the problem that makes me prefer cli over gui, or?

@boredsquirrel

12. with toolbx you have no way to easily update all containers so they might become outdated, and you have 2 separate systems

yeah, that sounds a bit meh, plus from “2 separate systems” I’m gonna assume it has it’s own firewall (or perhaps none at all, idk)

@boredsquirrel

12. The issue you try to prevent by layering is state buildup through layering. Apps can place files in /etc and more which are not managed by rpm-ostree/dnf and can result in weird stuff happening over time

um… this sounds quite concerning.
what do I do about it?..
I assume it happens the same way on Workstation, but still… it sounds like something that would need some sort of solution.

@boredsquirrel

12. The goal is to have a managed system where you can get to a new state with no custom stuff + the changes you want and need at the current time and nothing more

honestly, I have no clue what is the difference between “custom stuff” and “the changes I want”, it sounds like the same thing. But then again, I just do some beginner tweaks to my browser and desktop. I don’t ever change any config files or anything like that.

@boredsquirrel

13. Read into containers. It is just the kernel and firmware and stuff missing. Not less secure.

good to know.

[boredsquirrel]

To the players: on linux there are VLC, MPV, gstreamer and ffmpeg

They share libraries etc, but also duplicate a few things

MPV (Celluloid, Haruna) likely supports just as many or more formats than gstreamer (Totem, Dragon, Glide, Clapper, Light Video), ffmpeg (QMPlay2, Cinema) or VLC.

[boredsquirrel]

@blind-confused

layering all my rpm’s in a single command

It takes longer. No other difference

@boredsquirrel

If you do manual updates there is often some issue you try to prevent by that, and you may want to address that to have it work.

Why dont you just use automatic updates? In my case I dont want them if

• battery is low
• network is metered like a hotspot
• I am working on something intensive
• …

These can all be excluded in the script so it doesnt interfere.

@blind-confused

I’m gonna assume it has it’s own firewall (or perhaps none at all, idk)

I dont know, I guess it has it’s own firewall in the container namespace, but actually never thought about it.

You might want to open a new thread about this, with toolbx podman firewall firewalld

@blind-confused

it sounds like something that would need some sort of solution.

Solutions are to keep the system clean, install random stuff in containers, separate config files in conf.d/a.conf b.conf c.conf and we need to work on reset mechanisms

Factory reset with OSTree