The real purpose of "remote attestation" is to ensure users in the future can't watch videos or access their bank accounts from systems they have root access to (and could do corporate unapproved activities like have ad-blocking installed or save/copy/modify content like videos). Is this the future Linux users want?
Yeah, that was the line where I started to lose interest in the post. I even stopped and reread that bit several times, trying to find any positive interpretation to balance the huge negatives.
If he continues this design and proposes it to people who find it interesting and participate, that's great, I believe nobody would mind that. I just hope this approach is not pushed down everybody's throats just like the other one.
I would not enjoy the OS that he describes as his preference. In particular, these are the aspects of his vision that I find objectionable:
> 4. Everything should be cryptographically measured, so that remote attestation is supported for as much software shipped on the OS as possible.
Just no. Remote attestation is an unacceptable concept for me, full stop.
> 6. Everything should be self-updating. Today we know that software is never bug-free, and thus requires a continuous update cycle. Not only the OS itself, but also any extensions, services and apps running on it.
Be able to? Sure, I don't object to that. But I have learned that I, personally, really hate continuously-updating software, so being able to avoid it and do manual updates instead is mandatory. Continuous updates are one of the reasons why I don't use SaaS.
> 11. Things should not require explicit installation. i.e. every image should be a live image. For installation it should be sufficient to dd an OS image onto disk. Thus, strong focus on "instantiate on first boot", rather than "instantiate before first boot".
This isn't a strong objection for me, but I really do want things to require explicit installation rather than something like dd'ing an image. I value the ability to customize installations to fit my way of doing things.
The rest of his design goals seem relatively benign to me, although a number of them are things I don't consider important at all.
I simply don't understand what he means by this:
> 5. Everything should be self descriptive, have single sources of truths that are closely attached to the object itself, instead of stored externally.
A tangential note:
> Given that on Linux flatpak (or on servers OCI containers) are the established format that pretty much won they are probably the way to go.
I really dislike flatpaks and similar, personally. I suppose that I could live with a requirement to use them, but it would be very irritating. I suppose I could also work around the issue by building everything from source rather than using prebuilt binaries. I'd prefer to be able to ignore the entire issue from the get-go, though.
All in all, considering how much I dislike about the systemd way of doing things, I was pleasantly surprised that I found most of what he said here to be reasonably unobjectionable. Much of it is stuff that I don't particularly desire, but wouldn't make me angry at its existence (although some of it would increase the irritation level a bit just because of the extra complexity it brings).
> modernized security properties built around immutability, SecureBoot, TPM2, adaptability, auto-updating, factory reset, uniformity – built from traditional distribution packages, but deployed via images.
Seeing "security" and "auto-updating", in the same sentence, makes me suspicious. /s
Why? Because that's what the big boys at Android and Microsoft are doing?