Why over-complicated? I’m genuinely curious, as I think it sounds pretty cool that you can install apps from different package managers in containers, but export them to use them in your main environment.
I briefly looked documentation, all the tools they provide, etc. Why we need supporting both rpm, deb and own format too? Why Debian? A/B is better than btrfs or symlinks? Maybe I should read documentation more, but why? It sounds really complicated with too many whys (and whay more why’s even compare to NixOS, being hardcore, but plain simple why).
Technically, only apt exists, as per Debian. The filesystem is ext4 but with two system partitions, so that you:
have one backup partition
can install updates to the unused partition for seemless and atomic updates
Be immutable whilst offering easy updates
It gets compared to NixOS because NixOS is also an immutable distribution and the package manager is equally as flexible as apx (even tho apx also allows you to use nix)
Multiple package managers outside of apt/dpkg from Debian get managed automatically using the apx tool, only if you wish to use it. Otherwise, for the desktop they promote the use of Flatpaks or AppImages.
What are updates if it is Debian Sid? Updates to software will replace A and B? Or do you install everything to A and B replaces A only with next OS update?
Looks bad in comparison with Silverblue where I can pin many previous version. Thanks to OSTree, you can downgrade to any point in the history or even switch back to an older release.
The A/B Partition method and OSTree are both great, but have different strengths
VanillaOS described it in their FAQ once:
Vanilla OS uses an A/B structure (ABRoot), which transacts updates atomically between two root micro partitions. The benefits of this system are the guarantee that the system is altered only when the entire transaction is successful (concept of atomicity), furthermore, the double root partition structure allows you to roll back to the previous state, directly from your boot, you will always have a home to come back to.
This structure, unlike others, is compatible with already existing distributions and does not require a complex setup and allows easy re-initialization of the system without data loss.
That is what I also read on main page. It is not clear will Firefox package require reboot to be applied.
BUT!
Than you read this in documentation:
abroot allows you to install kernel modules, drivers and other essential packages without compromising the filesystem’s immutability.
When a command gets executed in abroot, a transaction gets started in the transactional shell in the second root partition. If the transaction succeeds, the changes are applied using an overlay and synced with the current root on reboot. If the transaction fails, no changes are applied (due to a property known as atomicity). abroot also allows for on-demand transactions using the abroot shell command.
So Firefox is probably not a thing to switch A and B? But what happens if some package is successfully applied, B synced with A, after reboot it did not worked and you can not boot back.
Also both partitions will be minimum 20gb, that’s 40 allready. If you install 5gb package, it is successful, it will install 5gb package again… That’s double time! And No garantee the system will boot. Or it won’t be synced until it boots… Yet it could hang in 3 minuted after ram leak, and both A and B are synced, you will have 3 minutes to fix things after boot. Like uninstall that package. Instead of simple rollback.
The 40gb total are both already reserved, and a normal user isn’t supposed to modify it so it shouldn’t fill up.
For desktop apps, Vanilla will primarily stick to Flatpaks, so Firefox will also be a Flatpak.
VanillaOS already has a custom boot menu that can be used to switch slots in case an update went wrong, so that you can go back to your older, but working system.
The partitions are also not synced.
If you install something using abroot (e.g an update) it will only be installed to the unused slot.
So if you run abroot --update or use the included updater, and you’re in Slot A, it’ll modify Slot B, and vice versa.
Looks really over complicated…
Why over-complicated? I’m genuinely curious, as I think it sounds pretty cool that you can install apps from different package managers in containers, but export them to use them in your main environment.
I briefly looked documentation, all the tools they provide, etc. Why we need supporting both rpm, deb and own format too? Why Debian? A/B is better than btrfs or symlinks? Maybe I should read documentation more, but why? It sounds really complicated with too many whys (and whay more why’s even compare to NixOS, being hardcore, but plain simple why).
Technically, only
aptexists, as per Debian. The filesystem is ext4 but with two system partitions, so that you:It gets compared to NixOS because NixOS is also an immutable distribution and the package manager is equally as flexible as
apx(even thoapxalso allows you to use nix)Multiple package managers outside of
apt/dpkgfrom Debian get managed automatically using theapxtool, only if you wish to use it. Otherwise, for the desktop they promote the use of Flatpaks or AppImages.What are updates if it is Debian Sid? Updates to software will replace A and B? Or do you install everything to A and B replaces A only with next OS update?
When you’re on A, updates go to B. When you’re on B, updates go to A.
After an update, a reboot will switch slots.
Looks bad in comparison with Silverblue where I can pin many previous version. Thanks to OSTree, you can downgrade to any point in the history or even switch back to an older release.
If OSTree suits you better, that’s fine!
The A/B Partition method and OSTree are both great, but have different strengths
VanillaOS described it in their FAQ once:
That is what I also read on main page. It is not clear will Firefox package require reboot to be applied.
BUT!
Than you read this in documentation:
So Firefox is probably not a thing to switch A and B? But what happens if some package is successfully applied, B synced with A, after reboot it did not worked and you can not boot back.
Also both partitions will be minimum 20gb, that’s 40 allready. If you install 5gb package, it is successful, it will install 5gb package again… That’s double time! And No garantee the system will boot. Or it won’t be synced until it boots… Yet it could hang in 3 minuted after ram leak, and both A and B are synced, you will have 3 minutes to fix things after boot. Like uninstall that package. Instead of simple rollback.
IDK I do not get it.
The 40gb total are both already reserved, and a normal user isn’t supposed to modify it so it shouldn’t fill up.
For desktop apps, Vanilla will primarily stick to Flatpaks, so Firefox will also be a Flatpak.
VanillaOS already has a custom boot menu that can be used to switch slots in case an update went wrong, so that you can go back to your older, but working system.
The partitions are also not synced.
If you install something using abroot (e.g an update) it will only be installed to the unused slot. So if you run
abroot --updateor use the included updater, and you’re in Slot A, it’ll modify Slot B, and vice versa.Thanks, makes sense.