Especially Project Bluefin: https://projectbluefin.io/
Of course, it's great to have a Debian based alternative!
In between Bluefin and Bazzite, most of my zero-maintenance Linux usage is catered for (although I still rely mostly on macOS).
Recently made the switch after having a terrible upgrade to Ubuntu 24.04, very happy so far with the use of brew and flatpaks in the OS.
The distribution looks very fun. Something quite new to play with for distro-hoppers and to learn more about some techs.
Last time I tried fedora-silverblue I didn't like it. My packages were scattered in 2 or 3 distrobox containers. It's not that much, but they can be different distributions, and then we add flatpak to the mix, and apps installed in the base OS with rpm-ostree... It felt like a frankenstein distro. Upgrades were time consuming, and not smooth at all. Not only did I have to learn how to manage a fedora-silverblue, but I also had to maintain a debian container, upgrade another fedora (a regular one, not silverblue), learn the quirks of flatpak, and... that was too much work. It doesn't really matter that I can confidently upgrade the empty base OS, if I still need to manually upgrade my fedora container and it can break the package I need from that container.
The approach here with Apx is worth a closer look. It abstracts away the different package managers of the main distro (`apx search` PACKAGE will translate to `apt-cache search` in debian container, `pacman -Ss` in arch container, `zypper search` in opensuse...). The concept of "exporting" the packages, and the UI around it, makes me think they aim at making the management of these distrobox containers easier.
I... don't think you're supposed to do that? Like, I haven't used silverblue specifically, but on suse microos there's a big warning with metaphorical flashing lights that says in so many words "don't touch the host OS unless there is literally no other way to possibly do what you need". You should never use it for normal applications, at the very minimum. And as to multiple distros in multiple containers - why not just run everything on Fedora container(s)?
> # nvidia and codecs necessary for firefox and youtube: > # You'll need rpmfusion repo (see dedicated section for how to install them. Ugly.)) > rpm-ostree install akmod-nvidia ffmpeg xorg-x11-drv-nvidia xorg-x11-drv-nvidia-cuda
Maybe I used it wrong, idk, but here is how my .zshrc looked like:
> alias "hx"="toolbox run -c devops hx" # I installed there all the mess for LSP server > alias "aws"="toolbox run -c devops aws" > alias "mpv"="flatpak run io.mpv.Mpv" > alias "yt-dlp"="toolbox run yt-dlp" # default distrobox is fedora
I could go inside containers ("activate" containers), but then, if I want all my tools... they need to reside in the same container, right?
I didn't feel like installing all the utils in all containers, or running exa and ripgrep in some fedora "basic-utils" containers and adding more aliases for very basic tools. So I ended up overlaying the utils I cannot live without, thinking they are not really unstable software, it can't possibly break the upgrade (and indeed it never did for the time I used silverblue) :
> rpm-ostree install bat exa git-delta ripgrep vim zsh zsh-syntax-highlighting zsh-autosuggestions fzf jq
I also needed some stuff to fix the thumbnails of the default gnome (I don't remember, but I'm pretty sure that if I did it with rpm-ostree it's because I didn't find another way):
> rpm-ostree install ffmpegthumbnailer gstreamer1-libav gstreamer1-plugin-openh264
I also couldn't install some ibus packages (with too much integration with the desktop/keyboard) in a container so I resorted to rpm-ostree there as well.
So while I really tried to keep everything out of rpm-ostree as much as I could, I felt like it was a constant trade-off: going against the spirit of the distribution VS managing every single util and running little cli tool in containers (that need to be maintained).
I'd be happy to read about some workflows, the "correct way to do it", or if silverblue changed since the last time I used it. But for me it's in the design itself: "use containers" mean "do the plumbing between or your tools yourself" (even if distrobox makes it easier by exposing/sharing pretty much the whole home, network, env vars etc...)
> [...] through Apx, a wrapper around Distrobox. The latter, in turn, is a wrapper around Podman, Docker, or the simple container manager lilipod
I filed a bug report to add a function to copy error messages from the installer - would be really helpful to file meaningful bugs reports
I'm also curious if there is really no way to install things on the host - is there a way to install NVIDIA drivers or the like?
> abroot pkg add PACKAGE_NAME
Not sure what it does exactly under the hood. I'm not sure it persists after an upgrade.
In the release announcement blog post they also mention a way to build your own (base OS?) image with something called VIB [1]
Regarding space efficiency, the distribution relies on a "LVM Thin provisioning" feature. [2] I don't know enough about it (nor about ostree) to compare the two.
This is all very refreshing! Many new techs and concepts to look into :)
[0] https://docs.vanillaos.org/handbook/en/install-additional-dr... [1] https://vanillaos.org/blog/article/2024-07-28/vanilla-os-2-o... (section "Make it Truly Yours") [2] https://github.com/Vanilla-OS/ABRoot#thin-provisioning
But the website makes no effort to relate to enterprise-level administration. Strange.
It’s less about experienced users screwing up and more about safely running software.
I do lots of small experiments and regularly clone repos from GitHub to try various projects. I prefer to do this in an environment that’s been a bit more hardened and locked down. I like the ability to get my system back to a known good state.
I’ve primarily been using NixOS as a daily driver, but have been pretty curious about Vanilla OS and plan to try it out.
sudo apt install overlayroot
#edit the setup script vars
sudo nano /etc/overlayroot.conf
overlayroot="tmpfs:swap=1,recurse=0"
#set different role contexts for grub
sudo nano /etc/default/grub
GRUB_SAVEDEFAULT=true
GRUB_DEFAULT=saved
GRUB_TIMEOUT=3
GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT
GRUB_TIMEOUT_STYLE=menu
GRUB_TERMINAL=console
GRUB_CMDLINE_LINUX_READONLY="quiet splash i915.tuxedo_disable_psr2=1 i915.enable_psr=0 "
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.tuxedo_disable_psr2=1 i915.enable_psr=0 overlayroot=disabled fsck.mode=force fsck.repair=yes "
#etc...
#then insert an auto menu item for the read only OS boot up
sudo nano /etc/grub.d/10_linux
if [ "x$is_top_level" = xtrue ] && [ "x${GRUB_DISABLE_SUBMENU}" != xtrue ];
then linux_entry "${OS}" "${version}" simple \
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
linux_entry "${OS} READ ONLY OS" "${version}" simple \
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_READONLY}"
#etc...#and finally enable the role selection with your current kernel
sudo update-grub
sudo update-initramfs -u
For systems that have enough ram and cheap SSD it ensures the flash memory will last longer. Additionally, running /home on F2FS for workstations can improve long-term hardware health, as Desktop users do not require the OS to be writable in many use-cases.
It is not a perfect approach, as silly things done as root can always bork the backing partition.
Best of luck =3
https://www.digitalocean.com/community/questions/how-to-move...
Hardly the epic task it once was... =3