Hi! I’m new to Fedora coming from having Zorin OS on my old laptop that got me started using Linux. I just installed Silverblue on a new laptop and really liking it. I learned that Fedora, specifically Silverblue, is more secure than Zorin OS so I switched since I use my laptop for personal and work purposes. I do have a few questions that hopefully can be answered:
I read on the Fedora tips and tricks webpage that it’s best to hide Firefox rather than remove it. The instructions don’t show how to do it when using Silverblue. How do I do that in Silverblue?
Does Firefox use any resources when not open? I have never opened the app so hopefully that makes a difference.
I understand it’s best to install Flatpak apps but I had to install Virtual Machine Manager and the extras that go with it so I can use Windows 11 for work. On Silverblue I installed Brave and another app that are not Flatpaks. Have I degraded the security of Silverblue by doing that?
I looked at using Toolbx but it seemed a bit complicated to me. Is there an easy to follow guide to setup apps in Toolbx? Is there a GUI that can be used? Also, how are the apps updated using this method and are there icons that appear on my desktop after the apps are installed?
The recommendation is to hide Firefox from the base install when using another version (installation source) of Firefox, e.g. as Flatpak from Flathub. This documentation page is for Silverblue specifically. It is recommended to hide it instead of uninstalling it, given that removing an app from the base image should only be a temporary solution. Nevertheless, on one of my (not so important) systems I have removed it, given that there is an annoyance when clicking on notifications in the Notification Center from Fedora Discussion specifically, since the linked page gets opened in the hidden Firefox app as well. However, this is only needed if you have multiple instances of Firefox installed. If you’re using a different browser, then you can set it as default and leave Firefox as it is.
It shouldn’t.
There is the recommendation to install GUI apps as Flatpaks when possible, since it offers sandboxing and keeps the image deployments thinner, but apps can be layered on top of the base image with no issues. As for security impact, you should trust the sources of the apps installed. Flatpaks come with additional security because of sandboxing (but only if done right).
I find toolbox pretty easy to use for basic usage. The man page can offer some guidance. Once a container created (with toolbox create), the default terminal integrates it (see the + button on the top left), or you can enter it with toolbox enter). I find it a great environment for development and testing purposes, but not so much for regular usage, given the it’s basically a static image. Technically you could update the container from inside it with the regular DNF update commands, but officially it is not recommended. I don’t know of any command to export the desktop files to the host system, similar to how Distrobox does, but it should be possible to manually create them. Hence, I don’t use it for apps I would regularly use (but rather install them as Flatpaks or layer them on top of the base image). What apps would you want to install in Toolbx containers?
Avoid the usage of toolbox as much as possible if you’re not familiar with sandboxing.
For example, for VSCode, the flatpak and the toolbox installation have several problems like drag and drop not working or having to install the browser (for the third time) and having to navigate through missing dependencies and permission problems to make some packages work (like Arduino or Jupyter).
I know it goes against the atomic desktop philosophy, but I think the correct solution for many compatibility problems you may find in the future is this:
I have two examples of things that work better on toolbox:
Installing an older python version. For that I have to make wrapper scripts and for most uses it works fine.
Building an app from scratch. In my case it was a Beta version of Mixxx, I still have crashes and the Drag and Drop doesn’t work.
I’ve been using Silverblue for 2 months now, and I kind of regret it. So if you think you can go to Workstation without losing much time, DO IT!
That really depends on the use case. For developers who have issues with or prefer not to be working in containerized environments, a traditional Linux desktop such as Fedora Workstation might be a better choice. For many other use cases, an atomic desktop with seamless updates and rollback options might be preferred.
In my case, I have switched from Workstation to Silverblue over a year ago, and have no desire to go back.
I was just about to delete Firefox and I saw this. Is there some reason it shouldn’t be deleted? Is it integrated into the system in some way? I’m using COSMIC Atomic.
If you “remove” the Firefox package with rpm-ostree override remove firefox, it will still be present in the underlying OSTree repository in /ostree/repo, but it will not be visible in the generated derived commit.
You know what? You’re right, even if it was a bumpy road at the beginning, I like having a working system. I also like the challenges and the new things I learn with this OS and the plus that trying to solve them won’t break my system.
Well it can be removed from future deployments with the sudo rpm-ostree override remove firefox firefox-langpacks command. I have done so and went through an upgrade to a new major version without any issues. See caveat below though.
For better understanding of how removing base packages work, we could regard the rpm-ostree override remove <base-packages> command as the opposite of therpm-ostree install <new-package> command. While the latter command pulls the <new-package> and all of its dependencies (not available in the base image) from the enabled repos and layers them on top of the base image, creating a new deployment, the former command creates a new deployment from the base image and then removes the <base-packages> from it.
Now why is removing firefox (or any other base package for that matter) not officially recommended? I guess it has to do with how the rpm-ostree override commands work. This is from the man page:
override
Provides subcommands for overriding (modifying) the base OSTree layer. Such modifications should be done with care and are normally not intended to be long-lasting.
I expect that changes in dependencies could cause errors on upgrades. Note that in case of firefox, its dependent package firefox-langpacks has to be explicitly removed as well.
Thank you for the detailed reply. In answer to your question of what apps do I want to install in Toolbx containers that would be Filen and Brave. Currently I have them layered and also Virtual Machine Manager with the add-ons it needs. The rest of the apps I need are available in Flathub. So since I have a minimal number of apps layered I should be ok, correct?
Regarding Filen, if it’s about this service, I see they have an RPM available to download, I assume you’ve layered that one. I suppose that if at one point in the future there might arise some dependency issues, you’ll not be able to upgrade the system and will have to remove the layered (local) RPM package before upgrading. This package could be indeed a candidate for Toolbox. Or you could use the AppImage, which is also available on their website. I don’t use AppImages, so can’t tell much about their security, but generally AppImages should be contained at user level.
As for Brave, it is available as Flatpak from Flathub. If you have no issues using browsers as Flatpaks, this might be the easiest option. In case you don’t see the app in GNOME Software, it might be because you haven’t enabled Third Party Repositories, which you can do in the Software app.
BTW, Virtual Machine Manager is also available as Flatpak, both from Fedora and from Flathub. But there should be no issue in layering it either.
Yes, it is that service. I would rather not install the appimage as they Electron. I installed Brave from their website since they had a command-line install specifically for Atomic Desktops.
What about hardware driver installs? My laptop needs hardware drivers installed for the suspend feature to work correctly and other drivers, not video drivers though. I’ve read drivers should be layered but can there be dependency issues with those as well? Can drivers be installed in a container and work correctly?
I meant about possible future dependency issues above only because the discussion was about a static RPM package, and not a distribution and version dependent one. In case of RPMs from Fedora’s repositories or external repositories which follow the Fedora versioning (such as the RPM-Fusion repos), I don’t really see any issue[1].
Not really, but there is no need to. Drivers not available in the kernel should be layered. RPM-Fusion provides many such drivers.
There had been some isolated issues with slight lack of coordination between Fedora updates and RPM-Fusion updates, but those were usually fixed once reported/noticed. ↩︎
Oh man now I’m really confused. What is the difference between a static RPM package and one that is not a distribution and version dependent one? How to tell the difference? Again sorry I’m new to Linux.
“Static” is my way of defining an RPM that you download from somewhere (filen.io in this case), and install it as such (and, therefore, it won’t receive any updates).
On the other hand, we have the Fedora repositories, for each maintained version (43 being the latest stable version), where packages regularly receive updates throughout the lifetime of the release. E.g. in case of Firefox:
$ dnf list firefox --showduplicates
Updating and loading repositories:
Repositories loaded.
Available packages
firefox.x86_64 143.0.3-1.fc43 fedora
firefox.x86_64 146.0-3.fc43 updates
!