Ubuntu Core works by having everything on the system, kernel included, be a snap. Or, as another way of describing the same thing, everything on the system is installed by mounting a squashfs image (which by its nature is read-only) and applying groups to the processes in those images. This applies all the way down to the level of the kernel, although a kernel snap, on install or upgrade, does write out to a boot partition.
The net result is that you get many of the benefits of immutability, but also many of the benefits of traditional distros. For example, you can replace the kernel snap (and even build your own kernel snap if you choose) without replacing the rest of the base system, since the kernel is installed separately from the base. This is especially important for non-x86 systems that may need different (mutually incompatible) kernel builds for different SOCs, but even on x86 an example of replacing parts like that is NVIDIA drivers. But you don’t need a separate version of cups just because you have an Nvidia GPU. And because cups is in its own snap, it’s isolated too. You get the same benefits of confinement that applies to desktop apps, but for services, where it can be even stricter. After all, cups doesn’t need to even know that you have a GPU, so an attack vector of hacking cups and then using it to attack your GPU gets foiled in a way that an immutable base with unconfined services doesn’t.
And that’s one of the annoying things about snap: It’s fundamentally a nice system with neat capabilities but it’s spoiled by Canonical’s proprietary backend.
That’s pretty fundamentally not how flatpak works. It could theoretically be modified to do all of that, but by that point you’re recreating snapd and it would likely be easier and more straightforward to start with the current snapd and change what you dislike about it.
Ubuntu Core works by having everything on the system, kernel included, be a snap. Or, as another way of describing the same thing, everything on the system is installed by mounting a squashfs image (which by its nature is read-only) and applying groups to the processes in those images. This applies all the way down to the level of the kernel, although a kernel snap, on install or upgrade, does write out to a boot partition.
The net result is that you get many of the benefits of immutability, but also many of the benefits of traditional distros. For example, you can replace the kernel snap (and even build your own kernel snap if you choose) without replacing the rest of the base system, since the kernel is installed separately from the base. This is especially important for non-x86 systems that may need different (mutually incompatible) kernel builds for different SOCs, but even on x86 an example of replacing parts like that is NVIDIA drivers. But you don’t need a separate version of cups just because you have an Nvidia GPU. And because cups is in its own snap, it’s isolated too. You get the same benefits of confinement that applies to desktop apps, but for services, where it can be even stricter. After all, cups doesn’t need to even know that you have a GPU, so an attack vector of hacking cups and then using it to attack your GPU gets foiled in a way that an immutable base with unconfined services doesn’t.
And that’s one of the annoying things about snap: It’s fundamentally a nice system with neat capabilities but it’s spoiled by Canonical’s proprietary backend.
There was an open backend for a while. A complete lack of interest killed it.
that is very interesting, however, why can’t that be done wth flatpak?
That’s pretty fundamentally not how flatpak works. It could theoretically be modified to do all of that, but by that point you’re recreating snapd and it would likely be easier and more straightforward to start with the current snapd and change what you dislike about it.