delsarto
A while ago (like ~10 years ago) VMWare workstation, or some of the things virtualbox graphics drivers did, seemed to be the only reasonable ways to run a virtualised desktop with 3d or at more than 5fps. But these days virtio and spice seems to work just fine.
Anyone can propose changes to practically all of the infrastructure via the https://opendev.org/opendev/system-config project.
Anyone can look through all of the changes; https://review.opendev.org/q/project:opendev/system-config+s...
Every change gets run through an extremely thorough CI system that tests the change and reports results, e.g. https://zuul.opendev.org/t/openstack/buildset/50ce144851224b...
Most of these CI jobs do things like apply your proposed change, deploy the service, then connect up a headless client and take screenshots of the results so you can confirm the correct behaviour of your change; e.g. http://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b62... is from a job that was modifying the gita deployment.
Humans approve changes for merge with Zuul, but Zuul commits the code. When Zuul merges the change, another set of jobs will push things to the production hosts automatically. There is a talk on the overall process at https://www.youtube.com/watch?v=apLHQ4DkIHU
There are obviously bastion hosts and private components to the production deployment, but as much as practical is completely open. There have been contributors with no special access that have developed the deployment of infrastructure services and admins helped only at the end committing some secrets and providing production hardware resources. More commonly, people who have CI issues can jump in and fix their own problems, especially relating to things specific to them (e.g. mirror setup on CI nodes, software versions used, etc.)
One cool thing is that the Zuul jobs publish their production deployment logs in public, but encrypted (these might contain secrets, so are not made open by default). If you work on a particular system, you can request to commit your public key to the service you like and access all the deployment logs. For example, say you are interested in maintaining codesearch.opendev.org. The "infra-prod-codesearch" job deploys changes relating to this service. You can look at all the jobs at https://zuul.opendev.org/t/openstack/builds?job_name=infra-p..., and every job has an artifact that lets you download the logs; e.g. https://zuul.opendev.org/t/openstack/build/c76ec695d19a4e9e9.... Details are at https://docs.opendev.org/opendev/system-config/latest/open-i...
Wikimedia is the only other platform I've seen with a comparable commitment to open infrastructure (unsurprisingly there has been collaboration between the two over the years)
Attribution Armored Code
[1] https://twitter.com/ethan_iverson/status/1479513450900377603
Is all the best ideas of keybase. Basically if you trust someone has control over multiple different accounts you can also trust their pgp key.
Elon Musk Painted over the ‘W’ on the Twitter HQ Sign, Which Now Reads Titter
Whistleblower threatening to sue ChatGPT for falsely claiming he was a criminal
https://www.merriam-webster.com/words-at-play/what-does-crom...
Git security vulnerability announced
Meeting Mike Burrows - Guido van Rossum
https://www.google.com/maps/@-37.9293496,145.0051951,3a,59y,...
https://www.google.com/maps/@-33.7710688,151.0985503,3a,75y,...
As the usual speed limit is quite a bit higher at 70km/h, driving at 40km/h (25mph) outside these times would make you, at best, a rather annoying obstacle to surrounding traffic.
https://opendev.org/opendev/system-config/src/commit/0a27974...
is really nice practical example. What it does isn't even really that important; but it runs a simulation of deploying production code in OpenDev. This is a "devel" job, we deliberately test any changes against all the latest HEADs of the master/main/development branches of projects we use. This is a non-voting job -- a notice that what you're introducing might be fine now, but there is trouble brewing when our dependencies release their next version. Sometimes that's fine and a known issue, or upstream is broken, and other times it's something totally unique and needs to be fixed (this is why, despite AI being able to write code for you, so far the implications of using that code still need a human in the loop :)
The "required-projects" in the job definition tells Zuul what repositories this test needs.
You can clearly see how it handles various projects having "devel", "main" or "master" branches to pull from to get their latest versions.
In the "vars" section you can see we're setting variables that get passed to the job roles flagging "this is the devel job, don't install the latest release but use the source Zuul will checkout for you from here".
The amazing thing? If I make a change and this job fails, I may debug it and find that it wasn't actually my fault, but something in upstream Ansible committed recently. I can propose the fix upstream. They do all their CI, and that's fine. But I now put in my change comment
Depends-On: https://github.com/ansible/ansible/pull/1234
and magically Zuul will recognise that I want to apply that pull request to the Ansible tree in testing and set it up for me (as noted, Zuul can do this for all sorts of systems, not just github). Additionally, Zuul will not merge the change until the dependency is satisfied -- I can NOT commit broken code!
The podcast below sums it up perfectly:
Three years ago, tobacco giant Philip Morris announced they were moving away from cigarettes and that they were campaigning to "unsmoke the world".
They said they would offer people a better alternative to the cigarette, a device that would give you your nicotine fix from a "HeatStick".
Author and documentary maker John Safran discovered the HeatStick is made primarily from tobacco, and that it still generates carcinogenic tar.
John soon found that Philip Morris were financing "anti-smoking" initiatives all over the world.
They look just like conventional Quit programs, but they are designed to shift people onto this new device.
https://www.abc.net.au/radio/programs/conversations/john-saf...
Although I had to laugh at https://en.wikipedia.org/wiki/Firewalker_(The_X-Files) which is about a contagious alien(?) virus which I remember being super scary. The whole idea of viruses, pandemics and quarantine didn't really phase the kids at all. How times have changed.
Weirdly there's some stock footage scenes that aren't HD. This led me to finding https://www.reddit.com/r/XFiles/comments/3w3lxl/the_blurays_... which is a great thread with lots of info on how the restoration was done.
I seem to remember the later parts of the series going a little off the rails. But so far it's great family watching for the right age.
I think you'll find better UFOs and conspiracy theories rewatching this than grainy fighter jet videos.
I would encourage anyone to get involved in real open infrastructure through efforts such as https://opendev.org. Yes, resources are donated, but by a range of providers who have a vested in interest in what the community is producing. ARM64 has been a great example; Linaro providing hardware resources, which has enabled services to perform functional testing and build ARM64 Python wheels for publishing for a number of projects. This is a rising tide that floats all boats. No need to send a resume [2] and you can start contributing immediately [3,4].
It has been good run with IRC but I forsee moving to Matrix as the medium-term future and there's plenty of opportunity for others to get involved with that (building home servers, admining, writing bots that provide the services we current provide on IRC, doc updates, community building).
[1] https://fosshost.org/news/freenode-faq
[2] https://docs.fosshost.org/en/home/volunteering-opportunities
[3] https://opendev.org/opendev/system-config/
[4] https://review.opendev.org/q/project:opendev%252Fsystem-conf...