This kind of integration testing is best left up to the individual distros. Same as the integration (as in: packaging) itself.
Distros don’t want your binary package, they want your source code, build instructions and a build system that won’t make them cry. Some distros even explicitly disallow re-packaging external binary distributions.
As a distro maintainer, I appreciate your wish to do QA on all the distros but that’s just too much work. You focus on making your software better, we focus on making it work with the rest of the software ecosystem.
Providing a package for one or two distros (i.e. your favourite one) is good practice to ensure your software can be reasonably packaged but it’s not the primary way your users should receive your package in the traditional Linux distro model.
Additionally, you might want to package your software for one of the cross-distro package managers such as Flatpak, AppImage, Snap, Nix, Guix, distri or homebrew. This can serve distro maintainers as a point of reference; showing how it is intended to work so they can compare their packaging effort. If there’s some bug present in the distro package but not the cross-distro package, that’s a good sign the issue lies in the distro packaging for example.
Again, don’t put much time in this. Focus on your app.
Voting is another concept that would become unhackable overnight
No. Voting on the blockchain is an even worse idea than money on the blockchain.
In many cases, there are good reasons why these things are done they way they are. I have yet to see a software system that is better at preventing voter fraud than humans looking at your government-issued ID at a poll site and humans overseeing other humans manually counting votes.
A single actor might be able to commit voter fraud in the order of dozes or hundreds of votes perhaps but with a digital voting system based on blockchain, they could do so on the order of thousands or even millions by compromising end-user devices used for voting or buy enough work/stake/whatever to perform a 51% attack.
Same goes for money btw. Our current system is by far not a perfect one but removing the ability for governments to i.e. freeze accounts of bad actors is not a boon.
The “cache” on HDDs is extremely tiny. Maybe a few seconds worth of sequential access at max. It does not exist to cache significant amounts of data for much longer than that.
At the sizes at which bcache is used, you could permanently hold almost all of your performance-critical data on flash storage while having enough space for tonnes of performance-uncritical data; all in the same storage “package”.
AMD platform support is coming to coreboot in the next few years, consumer platforms much later and even there I’m doubtful it’d come to your laptop in particular.
Get a Frame.work with Intel chip if you want coreboot on a modern laptop soon-ish. I know the guy working on that port ;)
It is however more of a mitigation for bad distro installers than general good practice. If the distro installers preserved /home, you could keep it all in one partition. Because such “bad” distro installers still exist, it is good practice if you know that you might install such a distro.
If you were installing “manually” and had full control over this, I’d advocate for a single partition because it simplifies storage. Especially with the likes of btrfs you can have multiple storage locations inside one partition with decent separation between them.