Thanks to Antoine Martin we have now a alpine(.rpm package for dom0) template. Thankyou very much!
alpine? 
awesome!
1 Like
Interesting. I would like to see an official Alpine template.
For an official release, this should be first implemented:
- Service VMs (sys-net, sys-usb, sys-firewall)
- Firewall (not tested)
apkproxying from within template (thus you must allow internet access to template to install packages)qubes-vm-kernel-supportNot adapted for use on Alpine yet, due to it providing a Dracut module. In most cases, it is not necessary as Qubes provides the kernel. This package is only neccessary when VM uses its own kernel, thus a hook is added to Dracut to generate the initrd for use within qubes.
1 Like
Since I’m using only minimal templates, I admit I don’t see a reason to use any more than single-distro based templates, beside whonix. Well, if you choose fedora minimal based templates only, and you want to use cacher qube as well, you’ll need one debian minimal template for it in addition.
I mean, they’re templates - untouchable from outside, and app qubes are considered as compromised by default in Qubes philosophy, regardless of template. So using “secure” template as Alpine is, could give a false sense of security while using app qubes based on this template?
I respect if there’s a specific application that cannot be found in fedora/debian repositories and is needed, though.
Alpine Linux is very lightweight, so I expect to Alpine-template.
But now APK in Alpine-template can not use proxy of Qubes os, and Qubes repository of Alpine-template is not yet compatible to torify-apk.
So if now Alpine-template upgrade, user must connect template to sys-firewall.
Template must always be kept to upgrade for security, but now Alpine-template must connect to clearnet, this is very danger issue.
I think this issue should be resolved first, but Ayakael gives priority to make sys-vm.
The solution to this issue is to either allow APK to use proxy of Qubes os, or connecting torify-apk to Qubes repository of this template.
Is there anything I can do to help with Alpine-template?
And I hope to use Alpine-template as minimal, I removed FireFox from template.
I search alternative lightweight package, I found BadWolf browser.
BadWolf is using WebkitGTK and designed itself to security oriented browser like as LibleWolf(But BadWolf is not forked from FireFox), but review of BadWolf is almost never found.
Code of BadWolf is very small, this is the lightest browser next to Rose(Rose browser is not in APK repository), I installed and tested, BadWolf can view Qubes forum and YouTube.
What do you think about BadWolf?
1 Like
Size of debian-12-minimal template is 1.2GB.
Alpine template is 1GB as default, but this template is pre-installed of FireFox.
FireFox is not installed on debian-12-minimal, so FireFox purges on template, minimal size of Alpine template becomes to 600MB.
600MB is half size of debian-12-template, this is very lightweight!
I think longer ssd life by size of 600MB only.
So if it is implemented all functions, Alpine template is greatly!
1 Like
It’s more likely your SSD controller dies before its cells wear out.
It may take a dozen years of daily heavy I/O before your SSD cells are getting unusable. From experience, most SSD will die before. The bigger the SSD, the more it’s unlikely to wear out as it have more cells for rewriting.
2 Likes
Beside @solene’s valid point, I could add the default template is f38-minimal which is 748MB. Still big? Well, the thing that helps the most with saving SSD is if you use zram swap, if I’m asked.
But, as I may, Qubes’ choices shouldn’t be based on this characteristics, just like I’m sure one day someone in the know enough will contribute with Alpine template too.
To me, it just looks that it isn’t important almost at all which template you use until you use qubes based strictly on your threat model aligned with Qubes philosophy. And default templates (the ones found in repos) are more than enough for that.
Opinion of you and @solene is correct.
Big storage SSD wear out unlikely than minimal storage, price of 1TB SSD is going down today.
But minimal system requirements of Qubes os are 6GB RAM and 32GB storage, and recommends are 16GB RAM and 128GB SSD as first storage.
Because Qubes os v4.2 is recommending to 128GB SSD, Qubes os must be considered to user of having 128GB SSD.
If Qubes os was installed by following to default on 128GB SSD, vm-pool becomes to about 78GB.
And if user installs fedora-38-xfce (This template is required for light user) and debian-12-xfce and whonix-17 (As they are default options on official installer), total size of three templates is 18GB, total disk usage (Not usage of vm-pool) is about 30% to 40% by clean install.
Concept of Qubes os is security by separation, user makes many AppVM and run apps on them in normally use case.
User doesn’t trust USB storage (This is concept of Qubes os!), so important works are be doing on SSD.
And some user needs other template for certain use case, such user needs to install minimal template or Arch or Gentoo template for use case.
TRIM is enabled as default on dom0 and all templates by systemd, but Qubes os frequently rewrote to cells of SSD by user of having 128GB SSD.
Most lightweight of template on official and community repository is debian-12-minimal, this is 1.2GB.
But Alpine template of Ayakael without FireFox is 600MB, this is half size of debian-12-minimal.
If Alpine template completes and adds into community repository, Alpine template can reduce risk of wear out for 128GB SSD.
So Qubes os recommends 128GB SSD, it is legitimate to think about life of minimal SSD.
I’m not so sure it’s enabled by default because of LUKS. It’s possible to enable TRIM over LUKS but it has some security drawbacks that may be unacceptable for many Qubes OS users.
that’s a one-time usage, do you have any proof that using alpine itself uses less I/O than Debian or Fedora? I’m not talking about the template size, but the i/o required for updating it and using it in AppVM. This could be more interesting than the template size itself which is basically a dead weight.
I have run by sudo systemctl status fstrim.timer on dom0 terminal after clean install, fstrim has already enabled.
Of course I installed by default setting (So SSD is encrypted by LUKS) and I didn’t enable TRIM myself, so I think fstrim probably enables as default.
Difference of TRIM schedule between fstrim and cron, is Qubes os need manually TRIM setting for user hope to TRIM every day?
Concept of Alpine is to use as server or embedded, so Alpine is static distribution.
For example Alpine has LBU, and Alpine can run from RAM.
Their features can reduce risk of minimal SSD.
And concept of Fedora is advanced features, so Fedora frequently upgrade than Debian and Alpine.
Whonix developed as harden of user privacy, if user hope to use it, user must immediately upgrade Whonix.
Arch, Gentoo and Kali core are existing in community repository as template, but their distributions are rolling release, required cells of SSD are more than not model of rolling release.
And AppVM doesn’t necessarily have to be connect to online.
User can separates template between offline and offline templates for AppVM.
For example user doesn’t touch fedora-38-xfce (This is used by dom0 as GUI of Qubes tools), uses Alpine template for offline work, uses Whonix for online works.
This reason is same to Windows template, QWT is perfectly work on Windows 7 only, but Windows 7 is EOL, if it connects to online, security is very danger.
But if user keeps ofline, Windows 7 template is safely.
Rewrote of SSD is less in this model, using Alpine is less than Debian.
it’s not, dom0 isn’t using a template
1 Like
Sorry, fedora-38-xfce is used by dom0 as default GUI tools, not template of dom0.
I run sudo systemctl status fstrim.timer once more, dom0 terminal outputs:
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset:enabled)
And I run this command on debian-12-xfce template, fstrim also enables.
If TRIM works, TRIM must enable both dom0 and template on Qubes os,
So TRIM is enabled by Qubes os as default.
This week-end, Antoine Martin added the apk proxying from within template. 
So you no more need to connect your alpine template to a NetVM (
).
See the 7323 issue Feb 8 comment.
If you connected your alpine template to a NetVM, for security reasons the preferred update way is to install the new alpine template RPM.
2 Likes
How to fix - Denied: qubes.UpdatesProxy from test to @default ?
Template updating throuth apk-proxy.sh works, but i cannot update AppVM or StandaloneVM from Alpine.