aplanas

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])

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

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.

It is still under development, but try Keylime[1]. They have also a nice agent written in Rust[2] with low footprint.

I write some notes[3] about how to use it in openSUSE MicroOS / Tumbleweed, but can be extrapolated to many other distributions too.

[1] https://github.com/keylime/keylime [2] https://github.com/keylime/rust-keylime [3] https://en.opensuse.org/Portal:MicroOS/RemoteAttestation

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.

Seems that it can convert from Python to Perl:

https://beta.openai.com/playground/p/o4qZWSXVz8JMmVaI9j9NMIK...

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

This is going too far ... https://github.com/Vogtinator/doom-emojis

Done with 5 skin tones of the hand wave emoji.

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.

A non-trivial example is this: https://build.opensuse.org/project/show/systemsmanagement:sa...

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.

> Fun times

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)

SUSE bought Rancher in 2020, and that was also in the news.

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

TL;DR: https://www.eqtgroup.com/Investments/Current-Portfolio/suse/

But we are mostly independent now. I.e we choose the directions.

I think that is this a bit unfair for SUSE. We (I am employee here) have a long tradition of innovation and failing in communication.

We had OBS, that is some kind of build system as a service that guarantee reproducible builds and traceability of packages before that was a thing. We develop an automatically and deeply tested (openQA) rolling distribution (Tumbleweed) at the same time that other was telling in the forums that this was simply impossible to do. We have crazy ideas like MicroOS with transactional updates, together with good old classics like YaST, Zypper or linuxrc.

We are just a few, but we have tons of contributions in the kernel, gcc, btrfs, qemu, runc, openstack, saltstack, kubernetes and whatnot.

There is this too:

https://docs.saltstack.com/en/latest/ref/modules/all/salt.mo...

You can reuse all the playbooks and start scaling with salt.

There is MicroOS from openSUSE: https://en.opensuse.org/Kubic:MicroOS

> Maybe the UK’s working welfare system can’t cater for all of Europe’s economic refugees

The first time that I read about this argument in relation with the support to the Brexit I was a bit surprised.

Do you guys really believe in that? Massive amount of people from Germany, France, Italy, Belgium or Spain demanding refuge from those extremely damaged countries, and requesting support from UK?

But I must note something. Where I live I actually see in the hospitals (in medium and big cities) queues of lots British refugees looking for a better health care. If you take the train in those places you will not listen the local language, but only some Cockney variation of English.

> For example, detecting gravity waves does move the needle on any of these metrics

It will surely do. Those achievements are not possible without staggering advances in technology that can be later applied in different fields.

The same technology that we first developed for those expensive colliders is now used in MRI and others diagnosis tools that we have for granted today.

For one side GCC is becoming an impressive piece of technology, and for the other I loved how a full Linux distribution was used to analyze the impact of those optimizations.

This is why openQA and all the test coverage is so important.

But the GPD Pocket have the trackpoint. There is also a Pocket 2 and a new one still on design.

In Ender's Game there is a description of an Ansible, a personal handheld device used to communicate, join to public forums, read news and influence in political discussions.

That is a cool project:

* Transactional updates. No interference with the deployments. You can rollback to any previous state.

* Smart separation of /, /etc and /var, using volumes and overlays properly.

* Using RPMs! I can tailor my installation with traditional RPMs, and the result will be updated at once.

* Zero maintenance. This is kind of magic for me, you create the initial deploy and the system upgrade itself, and rollback if a problem is detected. I wonder how well this works IRL

On the downside is still a bit new, but I found more information here [1]

[1] https://kubic.opensuse.org/blog/2018-07-09-kubicatosc18/

> Is there a standard tool-enforced coding style for Rust that the community agrees on, in the same way that the Go community has by and large agreed on gofmt?

https://github.com/rust-lang-nursery/rustfmt

And is planned to be distributed with the compiler and the cargo stack by default