Besides PureOS I’ve also installed various libre systems like Parabola, Devuan, Trisquel etc, but now PureOS is still based on the Debian userland and systemd init system, that’s quite common and too much similar to Trisquel (the only difference is PureOS is rolling but Trisquel is LTS), then will future PureOS try OpenRC init system and pacman or source-based userlands?
I really wish the Purism team would adopt the Deepin DE. It needs polishing though, making sure it has only free code and that everything inside it is freedom respecting.
IMHO, with such a DE people will know that they have both a secure and an awesome looking DE.
p.s. though sure, this is not such a huge issue to me, it’s only a matter of “being more special” and how I see this “special” being implemented.
I don’t know the full roadmap and scope of all that PureOS is meant to accomplish, but with the current trends I can at least hypothesize a few things:
- There could be tighter integration to allow Librem hardware to conveniently use the TPM in an easy, “well integrated” way. For example, when applying package updates that change the boot/kernel, if you’re one of those leveraging the verified boot allowed by the TPM+coreboot+Heads, PureOS could then propose you to insert your compatible smartcard/encryption key and prompt for the passphrase to cryptographically sign the changes as part of the update process, instead of having you sign those manually with coreboot+Heads on the next reboot.
- I believe it would make sense to move towards OSTree for “atomic” operating system upgrades, and Flatpak for various userland applications. EndlessOS are doing that, and Fedora (and eventually RHEL/Centos) are looking into that too. In our case, this would make particular sense for the phone platform, though I don’t know when this will happen exactly for the general PureOS platform because this is such a massively intrusive architectural change…
- I know that @matthias.klumpp is currently working on replacing the old Debian installer by Calamares, but there is significant upstream work we need to accomplish for it to be suitable for the usecase of true OEM preloader images (to allow Purism customers to set their own encryption key, like with our current/old installer)
So those would be some pretty big differentiators to many other distros, and I’m sure it wouldn’t be the only “architectural features” as things evolve. But that’s already a pretty good set of goals to start with