Interesting bit from that article wrt to transport infrastructure:
"most distributors simply stick to the industry standard transport of Grade 5. That is why for and [sic] end user of helium, a lower grade can cost more than the higher grades."
I've got the Android app and love it, as well as Knots 3D.
Most knot enthusiasts will already know about it, but in the analog world The Ashley Book of Knots is fantastic. Beautifully illustrated; the author, Clifford Ashley, was a marine painter and spent decades documenting almost 4,000 knots.
112 and 911 (US) work on almost every mobile phone anywhere in the world. It's part of the GSM/UMTS standard. 999 is supported with either no SIM card or a UK SIM card. See §7.1 here: https://www.ietf.org/lib/dt/documents/LIAISON/file562.pdf
They also don't require a phone to be activated in most countries. I believe there are some exceptions in EU countries, but in the US it just needs to have a working antenna and be in range of a tower.
It's not good as a first line of defense for failover, but with some client software and/or failure mechanisms there aren't any better approachs I'm aware of. Some of the software I administer doesn't understand multiple A/AAAA records.
And a BGP failure is a good example too. It doesn't matter how resilient the failover mechanisms for one IP are if the routing tables are wrong.
Agreed about some providers enforcing a larger one, though. DNS propagation is wildly inconsistent.
I have mine set low on some records because I want to be able to change the IP associated with specific RTMP endpoints if a provider goes down. The client software doesn't use multiple A records even if I provide them, so I can't use that approach; and I don't always have remote admin access to the systems in question so I can't just use straight IPs or a hostfile.
Maybe, but I don't think TTL matters for speed of initial propagation. I do set it low when I first configure a website so I don't have to wait hours to correct a mistake I might not have noticed.
Agreed; I have no idea how you'd implement that across multiple ASNs, which is definitely a requirement for multi-cloud or geo-redundant architectures.
Seems like you'd be trying to work against the basic design principles of Internet routing at that point.
This seems... deeply idiotic on GitHub's part. Consider the following scenario:
1. A script/CI/etc is pulling the latest releases from the repository.
2. Ownership of the account is changed.
3. The new owner controls the contents of the repository, and can perform a supply chain attack.
I'm not sure GitHub would be liable there, but personally I wouldn't want to find out the hard way.
There are comments saying it's worked on several Quickbooks integrations.
Regarding hardware drivers, I _think_ the same fundamental process of removing signatures should work, but you'll get a UAC prompt to force installation of an unsigned driver.
I'm not as familiar with driver signature enforcement though, so take that with a grain of salt.
P.S: I still have running XP installs for some $300k industrial hardware. It could be worse...
I've also had great experiences with Tumbleweed for the most part, but be careful using ZFS, as it frequently breaks with updates. Probably not something most people use, but it does force me to run Leap on my home server.
> open access "allows for manipulation of systems on a vehicle, including safety-critical functions such as steering, acceleration, or braking."
I assume this is just FUD, but if true it raises another question: why are braking, acceleration, and steering manipulable in real-time through network-facing software?