aplanas

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 common component here is Microsoft, not the TPM.

> 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.