While it is technically no longer supported, you can still install the whole kit and caboodle using pip in a Python virtual environment, but why would you?

you mean an image like this?

This is what I've been running on my generic x86-64 system for a couple of years now, 0 issues. Even migrated to a newer system recently because I wanted something that was slightly faster for ESPHome compilations.

They don't want shipments stuck in port because storage there is expensive.

The XSLT can also be served once, and then cached for a very long time period, and the XML can be very small.

If the goal is to reduce security bugs, then we should stop introducing niche features that only make sense when you are trying to have the browser replace the whole OS.

Instead Google and others just use it, and expect that any issues that come up to be immediately fixed by the one or two open source maintainers that happen to work on it in their spare time. The power imbalance must not be lost on you here...

If you wanted to dive into what [3] does, you could do so, you could then document it, or refactor it so that it is more obvious, or remove the compile time flag entirely. There is institutional knowledge everywhere...

That is how I am locked out of a gmail account... eventhough I have the right username/password, and backup email, and typed in a phone number, Google won't let me back in.

  lo0: flags=8049 mtu 16384
   options=1203
   inet 127.0.0.1 netmask 0xff000000
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
   nd6 options=201

https://bsky.app/profile/lina.yt

https://github.com/AsahiLina

Even now it has been a lot of trouble trying to get vendors to provide us a way to rebuild/repackage their Golang binaries using the FIPS-140 support from RHEL, and if it is still the case that they need to build one-offs, teams will still need to rebuild/repackage a lot of Golang tools just to be FIPS compliant because it's not as simple as setting a flag like it is for OpenSSL.

Golang projects however don't compile against OpenSSL instead using the internal cryptography. In many cases rebuilding and repackaging a Golang based tool is a no-no since now you are accepting ownership of it in an audit, when instead you want to point to an upstream vendor, or source code is not available.

So in many cases in production while the system itself is in FIPS mode (Linux kernel), and applications using system crypto libraries (OpenSSL primarily) are in FIPS mode, Go binaries are not in FIPS mode and may end up using algorithms that are explicitly disallowed by the FIPS standards.

With OpenSSL installed system wide you can turn on a flag and the library will force it into FIPS mode internally, with Go unless you build your binaries to link against OpenSSL like this Microsoft Go release seems to be doing you don't get that instant on system wide.