That is a key area too. I know that most of the distros are working in that direction[1], and in the case of Fedora, openSUSE or Debian they are reaching high level of reproducibility.
Those distributions are making huge efforts in keeping a core that is 100% reproducible, working upstream to fix issues, and providing reporting and tests tools to detect regressions (for example [2])
What I do not understand is why not to work with the openSUSE community, or fork from them. But instead use a USA based distro like Fedora.
openSUSE has all their tooling based in EU ground. For example, OBS that is the build service, has the machines around Germany or Prague. A big bulk of the community is EU based, (with very relevant contributors from many other places), and SUSE, the company that is helping (via infra and some packages) is from Germany.
I do not known if sovereignty makes sense in the open source world, as at the end is a joint effort of multiple developers from many (and some times confronted) places, but if it does make sense then I would value more those other criteria.
> What if you actually can’t predict the future and climate change is actually good?
Is this how rational people react, or is some spiritual response talking from fear?
How can be the depletion of biodiversity, the increase of temperatures and the disappearance of ecosystems that we need to survive "good"?
As a community we do no have a crystal ball to predict the future, but we have science and technology and the predictions from there are clear: it is not good for us, and it is not good for the current species.
The far future, the very far one -- sure -- the are good chances that new ecosystems will appear adapted to the new environments, but those will not be "nice" for our current expectations.
A doing-nothing-and-hoping-for-the-best strategy is a guarantee for massive wars, hunger and suffering, as happen many times in the past (but never in a scale of 7.000.000 population)
> the TPM enables verification of a particular state of your system, i.e., a particular set of binaries and OS configuration
That is a bit misleading. The TPM is a passive device, it cannot verify any state. It is the OS who measure the system (in Linux via the IMA system). And is the Linux kernel the one that, if you have a TPM, can produce a process where a 3rd party can be sure that the measurements are "true" and "legit" (via PCR#10 extension).
As you state later, it is this 3rd party the one that assert (verify) if you are state considered OK or not.
Maybe I am too simplistic, but I do not see the evil in the TPM here, but only in the 3rd party policy.
TPM can be abused but, as a developer, I am happy that we can use the TPM for good and fair goals in open source projects.
It is the user who can decide to use the TPM or not, and should be noted that in the TCG specification it is stated that the TPM can be disabled and cleared by the user at any moment.
Windows security models and policies are the enemy, not remote attestation (RA).
RA is a technology that has its fair use, and can be desired for other systems, like in Linux. With a pure RA system your services can decide to trust or not those devices on your network that can be compromised, and report to other devices that there is something suspicious.
As anything, this can be used properly to increase the security of your edge architecture, or wrongly to limit the users actions.
Let me put another example. With RA I should be able to authorize validated systems in my R&D VPN. If you are using your own laptop with the company certificate, and the verifier tag the systems as "unknown" or "unhealthy", it will not allow the access to the internal network, but sure you can still use your laptop for anything else. This, IMHO, is a fair use of this technology.
> But for helping the very poorest advance, I'm not sure it works in practice.
I think it does. I studied in the south of Spain (I am Spaniard too), and some of my fellow students comes from very poor sides of the city.
It is very frequent now to see teachers, lawyers and other careers that requires University level studies that are Gypsies, that were born and raised inside those communities.
IMHO free quality education is the perfect equalizer, but it is true that there is much to do there.
RSA is very slow for decryption. The general approach is tp use RSA to encrypt / decrypt the key of a symmetric encryption algorithm, that is much faster.
Anyone that needs to be maintained for a long period of time. For example: Firefox.
Today Firefox have all the rust deps bundled (similar to cargo bundle). If / when tomorrow the maintainer of the distribution find a bug in one of the rust dependencies, s/he needs to add the fix inside the bundle without a clear process (1. do I need to fork and update Cargo.toml to point to my branch? 2. can I add the fix as a .patch and apply it after it gets unbundled by the build server? 3. ...)
An also this process needs to be repeated for each application that have this version of the crate as a dependency, and again without a clear way of identifying those applications that are affected.
I submitted this entry because IMHO is the first survey, that I am aware of, that is giving some data about the Rust toolchain inside a distribution.
I guess that openSUSE can be a bit different than Debian or Fedora, but there are some answers that for me are not expected. For example, the "In your ideal workflow, how would you prefer to manage your Rust dependencies?" question seems to favor cargo, instead a distribution package. That raises to me a lot of questions about how in this workflow we can have long time supported packages, when we need to backport fixes into dependencies that are not supported anymore upstream.
We (openSUSE) are doing this in controlled situations. We have a build system (OBS) that create VMs for us every time that we want to create / update a new package.
Those VMs are isolated from the network, but we can have partial control over it via the .spec file. This allows the call to some external "helpers" scripts that are described as a build only dependency, and that create a Python venv, and help with the re-allocation (maybe in /usr/local, or /opt, for example)
The cool thing is that the venvs are self-contained by a lot, including the Python (we can include it inside the venv, so is de-attached from the system Python version, but this is totally optional) and the system libraries (.so) that are both dependent of the Python version and the system libraries.
If you check the subprojects you will see the venv for Fedora, openSUSE, Ubuntu and others.
If the build system is minimally powerful, you can do really crazy stuff. For example, there is one member of the team that is thinking on wrapping the final venv into SquashFS, to decrease the size and simplify the installation.
Is still fun! There is Tumbleweed, a full rolling distribution (all packages with its own update cadence, and OBS fully building the dependencies that are impacted). There is also MicroOS, a transactional OS (BtrFS subvolumes for rootfs are read-only, and the update happens in the snapshot that will be activated after the reboot, providing a self-healing system when an upgrade does not affect the running environment)
Also Leap, but this is indeed boring (15.3 will be based fully in SLE binaries)
I wonder if the historians from 100 years ahead, when analyzing this period of time, will not wonder why the society did not react on time for those evident signs of democracy degradation.
As today I use the present to understand better the past, and why we had multiple civil and world wars, and how is that former rich societies supported corrupted politics that ruled against them.
I think that this is a fair argument. When the mental model is already there, changing it is difficult and the trade-offs needs to be in a very advantage position to justify the change.
But over the time this argument loose fairness in some direction. Today, in 2020, I would feel awful if in my meetings I argued that creating unit tests is meaningless, as this will point bugs in my code that I need to fight with. Or that QA is a bunch of mean people that do not understand how to use my library and only want to point to "bugs" that is more work to me to "fix".
IMHO the borrow checker _is_ this test that I do not want to write, or this QA engineer that exercise the code to find a corner case when I am causing a memory corruption in my not-perfect work.
For my laptop and desktop (where I work and watch movies, no gaming so far) I use openSUSE Tumbleweed. A rolling distro that allows me to have the last version of all my software, and very stable so I can do my daily job.
I choose it because is a funny mix between innovation (rolling, automatic tested, staging project to detect integration problems, reproducible build, etc) and conservative (traditional package manager, all based on RPM, robust good old tech already battle tested).
Those distributions are making huge efforts in keeping a core that is 100% reproducible, working upstream to fix issues, and providing reporting and tests tools to detect regressions (for example [2])
This is why a fork is usually a bad approach.
[1] https://reproducible-builds.org/who/projects/ [2] https://en.opensuse.org/openSUSE:Reproducible_Builds