Alt RPM Distro (CentOS?) in dom0

Some arguments for OpenSuse

I’d like to collect some Qubes-Dom0-specific arguments that would be in favor of OpenSuse.

Transactional Updates

The transactional-update feature could add a lot of benefit to Dom0, especially:

Good Stability

The Tumbleweed rolling release could be suitable for the testing release (currtently R4.1), while the Leap versions could be used for the stable release (currently R4.0).

I think OpenSuse Tumbleweed is the most recommendable rolling release distribution to daily drive as a desktop user (not sure when you have tried it the last time). They put quite some effort into making Tumbleweed as stable as a rolling release can be.
In combination with the filesystem snapshots provided by transactional-updates, Qubes’ testing release could be updated frequently without fear of breaking those installations permanently.

Good Xen support

OpenSuse is built to work with Xen. You can simply install it through their superb system administration tool YaST.
On other RPM-based distros I remember that Xen often requires some tinkering until it works properly.


Of course, there are a lot of big arguments against OpenSuse, too:

  • Why considering a distro that has not even proven to be useful as a template?
  • The transactional-update feature might require some adjustments regarding packaging until it would work.
  • The effort that is put into making Tumbleweed as stable as it is, will not benefit Qubes tools without further effort.
1 Like

Thanks for a productive post!

AFAIK, they also have put in a lot of work towards reproducible builds. I certainly think they would be more suitable than a purely community backed effort like Arch.

I think I would agree with you in that it’s probably the most professionally run rolling release distro, but I
don’t think a rolling release is desirable. Of course, I don’t count CentOS Stream as a rolling release :wink:.

Jumping late in this discussion.

After having read the whole thread (awesome btw) and having followed GitHub discussions for a long while (debate of switching to Debian for a long time with PoC having happened), I would love to understand concise criticisms against SilverBlue being the next step moving forward for Qubes, both for Templates and dom0? @unman? @marmarek ? @adw

As for Templates and release upgrades (Q4.0->Q4.1 being the last good example of problematic and iterative patching (there is still problems upgrading from Q4.0 to Q4.1 as of today, reported on GitHub), I again believe that a rolling Qube release would be ideal, while problematic, while SilverBlue seem to be a good middle point instead of moving to Nix/Guix, or switching to debian (longer release cycles, far from actual Fedora, drivers availibility problems etc)…

So my short question would be: have somebody tries SilverBlue enough to give an technical opinion of what would stop dom0/fedora template to be based on it? Relevant issues or other discussions pointers are good enough! :slight_smile:

1 Like

I would love to understand concise criticisms against SilverBlue being the next step moving forward for Qubes

SilverBlue would be very cool and there have been experiments that fully virtualize Flatpak apps. The problem is that Qubes doesn’t have the engineering resources to make the leap.

Even if they did, it’s not clear how the SilverBlue experiment will turn out. I think SilverBlue sees itself as the future of RHEL, but they are still busy building that future. RedHat might pivot and make major structural changes or drop the project entirely. Qubes would probably need to become a SIG within Fedora to influence engineering decisions. But even that wouldn’t guarantee they would be able to get the financial backers to put any effort into, for example, making Fedora or CentOS fully reproducible (because who would pay for a RHEL license if they could mathematically verify that their builds are identical).

TBH I think these discussions about alternative distros are moot unless someone advocating for a specific distro is willing to either put in the time and effort required to make it happen or pay someone else to do it.

I’d love to see SeL4 as the hypervisor, but just talking about how cool SeL4 is won’t make that happen any sooner… :frowning: