|Page Name:||Experiment: mmmv_silkexec: spec Ideas 01|
This page is for a semi-random collection of ideas, how to improve/change/create the specification of the mmmv_silkexec.
Due to the fact that applications work as a combination of application specific code and the dependencies of the application, in some cases some code is loaded dynamically, at runtime, a proper formal verification task gets prohibitively large pretty quickly. Even, if formal verification were possible, the behavior of software packages can depend on hardware, which varies between different users. If hardware is guaranteed to be the same for all users, for example, if all users use a specific version of the Raspberry Pi, then the fact that compile-time parameters depend on the previously installed packages can be countered by installing all packages of the package collection in the exact order that they were compiled and tested at test server, but even then the test server at least partly relies on the tests that have been supplied with the software package, by the software package creator, which may be a different person than the author of the packaged software. It is possible for the software packager to accompany the upstream deliverables with its own, additional, tests. Tests can include partial formal verification.
All in all the general model for testing is black box testing, which may include some formal verification of some sub-components.
Social Aspects Related Observations
In addition to mistakes done by hardworking and meticulous persons, there are also people, who are sloppy or who do not mind intentionally placing malware to software packages. To avoid censorship, nothing can be banned, not even malware. Therefore, people have to use their own choice of label providers. The task of the label providers is to analyse software packages and label them according to a labeling system of their own choice, which can be their own custom labeling system.