S0 is a step forward. Disabling CPU entirely is just a "workaround". Both S3 and hibernation has a lot of security implications which S0 solves. Apple uses their own S0 alternative and it works... Perfectly?
The real problem is that both AMD and Intel S0 implementations are mediocre at best and this is what they should fix. Also most vendors are dickheads and cannot even verify that their system even goes to S0ix states without any problem before releasing it. Because of their laziness you can buy brand new certified "Linux ready" machine which won't even achieve S0ix states out of the box.
In other words, for the user, it's not a step forward. It doesn't matter if the spec is perfect.
I really wish all the various open source packaging systems would get rid of the concept of source tarballs to the extent possible, especially when those tarballs are not sourced directly from upstream. For example:
- Fedora has a “lookaside cache”, and packagers upload tarballs to it. In theory they come from git as indicated by the source rpm, but I don’t think anything verifies this.
- Python packages build a source tarball. In theory, the new best practice is for a GitHub action to build the package and for a complex mess to attest that really came from GitHub Actions.
- I’ve never made a Debian package, but AFAICT the maintainer kind of does whatever they want.
IMO this is all absurd. If a package hosted by Fedora or Debian or PyPI or crates.io, etc claims to correspond to an upstream git commit or release, then the hosting system should build the package, from the commit or release in question plus whatever package-specific config and patches are needed, and publish that. If it stores a copy of the source, that copy should be cryptographically traceable to the commit in question, which is straightforward: the commit hash is a hash over a bunch of data including the full source!