I know a ton of embedded shops that are running x86 (including some actual i386 still) in production, and will likely for years to come. That stuff was bullet proof, cheap and still runs today.
Some of these things have long lifetimes.
1,400 karma · joined August 17, 2020
Some of these things have long lifetimes.
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<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>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.
I have one for that reason, and it lives in the office alongside my work issued laptop.
The MacBook Air is still an M3 only as the highest end M-processor.
Python packages developed by third party developers and uploaded to PyPi are indeed not verifiable due to the key issues you mentioned, and is a minor note in the article.