On Debian, you can use .bash_history as a log file of your changes, and repeat the same steps when you upgrade.
If you only installed software, you can execute the history as a shell script.
1 Like
Neat! Thanks for the tip
Does this mean a Debian in-place upgrade (executed by Salt/dom0) would be easier to implement?
It would be dangerous to blindly replay the history, I wouldn’t do it without looking in the file first.
But you can already choose to install only Debian templates in the installer. Do you mean simply having the Debian box checked and the Fedora unchecked by default in that section?
It may not sound like much, but for your average Joe, the current default implies that Fedora is recommended by the Qubes Team over Debian.
When their security is on the line and there’s isn’t enough time to scrutinize every setting, they’re far more likely to go with the flow. This will end up costing them a lot more time and effort in the long run, but they wouldn’t know–nor should they be expected to.
Little UI changes like these make huge differences
A post was split to a new topic: How is the SecureDrop Workstation doing? Does it need frequent template upgrades?
All your concerns can be solved by automating your installation. (not advertasing because it’s mine).
https://forum.qubes-os.org/t/fresh-installation-shell-script-minimal-templates-app-qubes-default-settings/16992
If you struggle with bash functions, follow the Sven’s guide.
https://forum.qubes-os.org/t/automate-debian-minimal-based-template-creation/11421
It takes some time to setting it up, but it’s a one time job. When it’s done, it’s done.
Update your script as you go, or make a note/todo at the top for new packages/settings/etc.
It’s based on Fedora, but you can easily adjust it to use debian.
When a new Fedora version is realeased, you just have to run the script.
In 1 or 2 hours tops, you get the exact same config than the previous release.
To me, the release cycle of fedora is not an issue (or too short) (YMMV).
(And you can still skip 1 version and update it every year).
1 Like
Thanks. I am not into scripting at all. I looked at your valuable resource, and as expected I couldn’t find at a first glance how to exactly automate upgrade from f37 to f38, copying all the settings and tweaks from f37 to f38 and setting lower level qubes based on f37, now to be based on f38.
I am almost sure it would be probably too much to ask you for such a script example, but thanks anyway…
yeah, as I said, it requires some time. The script is already an example of what you want.
It’s also a bit outscope of this thread. I post it, because it solve the issue of short release cycle.
I advice to read the Sven’s post. He explain a lot more than I do in my guide.
1 Like
The script alone won’t just upgrade you (at least not if it’s like Sven’s stuff, which I used as a starting point). What the scripts do is reliably generate the same thing, every time you run them. That doesn’t sound very useful but follow me just a bit.
If you went that route, you’d write scripts that re-create what you have now. Then when the next version comes out, you can hopefully change one line in the script (to reference the new version), re-run the scripts and now you have your own configuration, only now built with the new template.
I’m on Debian, and I think a new version of that will drop in a couple of months. After waiting perhaps a month for early adopters to find issues, I will find out for the first time whether I did the job properly on my scripts. (Meanwhile I used mine to largely recreate my desktop environment on my laptop when I switched it to Qubes.)
1 Like
I’ve encountered a few problems with using Debian due to the fact that new versions get into the repo slower. On few occasions things just stopped working as they used to because the version wasn’t “high” enough. In fact, just last week I had a web-based management console not loading at all (blank page). Turns out the provider (one of the big names in remote support systems) did some update on their system and the Firefox version for Debian (ESR) wasn’t good enough for it. I had to manually install the “stable” version and persto - it all works again. (I really don’t like installing things outside of the official repo).
However, I totally agree that Fedora lifecycle is a bit too short. From a user perspective, I think that releasing a new version every year is fine, but would like to see it supported for 24months. Upgrade takes time, applications and configurations don’t always slide smoothly into the next version even when doing in-place upgrade, so it makes it all very time consuming.
Could Qubes wonderful dev-team maybe consider to add qubes-official Ubuntu templates just for the LTS versions? 
Edit: just found out that it may violate Canonicals’ IP or something. 
The two-year freeze can be annoying, but you can use flatpak, snap, appimage, or alternative repos to get a newer version.
The Debian release cycle isn’t perfect, but it does provide a lot of stability.
Indeed it does.
And once that rabbit was stupidly pulled out of the hat, it’s not so
easy to put back in.
There have been approaches to Canonical on this issue.
An alternative might be to use Mint, which doesn’t so violate - I build
mint templates, and make them available here
Thank you @unman , Mint should do it !
Debian will probably give more stability, but when something more “fresh” is needed, I will probably prefer Mint over Fedora for the reasons discussed in this thread.
Apparently, I knew about your templates but somehow missed the fact that Una = Mint 20.3 
More transparent naming would help, no doubt, but I tend to think in
terms of the names.
I’ll make the Mint names consistent with other templates.
I am sure that Qubes Team has been suggested many times and decided not doing so on purpose, but I wonder if Qubes OS would be built on AlmaLinux or other RHEL downstreams.
An obvious downside of RHEL downstreams is theirs old(er) applications though they can remedy with Flatpak, Snap or such. Another disadvantage may be old(er) Xen if they are used for Dom0.
FYI (if you meant having dom0 use a rhel clone rather than fedora): quoting @marmarek’s reply to the same question:
That isn’t really helping - RHEL indeed is provide stable support long time, and they do that by supporting extremely limited package set. @fepitre tried to port dom0 to CentOS 8 before, and even when adding EPEL repositories many required packages were missing (see #1919 (comment)). So, we’d get longer support for base packages at the price of maintaining a lot more packages ourselves.
Now - that’s a bit old, maybe things have changed since then…
3 Likes
Thank you, @taradiddles ! Yes, that is another problem we will face if Dom0 is based on RHEL downstreams.
@unman I installed the Una template from your link and wanted to use Qubes native update tool (salt?) to update Una template. I can see the template in the gui and ask it to update but the circle keeps turning and nothing else happens . (is updating this way even possible? is it just something I missed?)
:EDIT never mind all that, it seems I just needed to wait long enough (veeeery long 
)
@unman just in case you don’t see the edit.
(@redmind the post edits only make it to the mail-based version of the thread if made within a few minutes of the post being created. So it might happen that folks using the forum via the mail sometimes don’t see the edits. Because of its content I assume yours came a bit later than that a few minutes 
)
1 Like