peTux design principles
Here's what pet wants:
- Container-based system
- Easy user data migration across container of various architectures
- User data isolation: programs that work with user data are prohibited to access network
- Hardware isolation: keep critical parts on dedicated computers to prevent key leaks
- Software isolation, like in NixOS but differently
- Digital sovereignity
- Plausible deniability
- Blending with humans
Some of these points are quite difficult.
The most important is blending with humans
which means the distro should have no references to the origin.
Neither it should have peTux
in any file.
If you're a pet managed to read this, be extremely careful.
One silly mistake and humans easily guess you're a pet.
Plausible deniability is the next point of importance. If humans notice something unusual, pet should have an alternative version, easy to swallow. Existing projects are the rescue. Pet can paw at them and say that's feature is from there and there, and that's the default one.
Digital sovereignity means the ability to rebuild pet's system totally offline. Also, it opens unlimited possibilities to incorporate necessary stuff in standard utilities. Evil humans will have to investigate much much deeper to prove it is pet who pissed in their shoes. 99.999% they won't because it's easier to fake reports with catnip than to do something clever at their dull jobs they have to attend every day.
Omitting middle points, the main peTux feature is containers in the first place. Pet loves containers. They help to avoid distro hopping and they make plausible deniability easy to implement. LXC looks the best choice. Although it might be less secure than KVM, it works on every SBC and retro hardware at minimal overhead.