Many people who carefully designed such redundancy later found it gone due to mergers and acquisitions. Lumen has built one of the largest telecom companies in the world through M&A. So for example, you might have built your redundancy by getting links through Qwest, Savvis, and Level 3... all of whom are now part of Lumen. Over time, those links get "re-groomed" into the same fiber (DWDM may mean your "redundancy" ends up as just different wavelengths in the same strand).

It turns out to even be hard to hold anybody accountable, because contracts weren't written to say this can't be done (e.g. a contract with Qwest didn't say "and you can't carry this in the same physical route as Level 3")... and even it had been, custom information like that doesn't fit into the cable map databases and so doesn't filter down to the techs making design and change decisions years later.

Oh it's also definitely about the office. While the managers get their private offices, the rest of us are dumped in "open floorplans" to "encourage collaboration". Nobody wants to be stuck listening to Bill loud-talking to his customer on Zoom or smelling Janet's microwaved tuna and garlic lunch.

Columbia's flight could have been extended to 30 days (oxygen wasn't the problem, the 30-day limit was from lithium hydroxide canisters used to filter carbon dioxide from the atmosphere). Atlantis was already being prepared for a launch planned for 45 days after Columbia's launch, so could have been prepped and launched within the 30 day window (if the decision had been made quickly). It would have been risky, but it was not outside the realm of possibility.

They've always been a source of security issues; proper BMC setup should be putting it on a dedicated VLAN because of that.

The real problem though is SuperMicro's penchant for being "helpful" by automatically moving the BMC NIC from the dedicated port to sharing the first on-board NIC with link. I've seen systems with no plans to use the BMC get compromised that way, because SuperMicro also used a default user/password for far too long (as far as I know, they may still do that today).

No, it isn't about orbital elevation - that is not that hard to change. It's about inclination - the angle of the orbit vs. the Earth. That takes a very large amount of energy (i.e. fuel) to change. In general, the only time that's changed is for satellites headed to geostationary orbit (when the satellite ends up directly over the equator), and that requires special stages designed just for that.

Nothing involving the ISS was possible. Columbia's orbit was different from ISS; it takes a LOT of energy to change that, and neither had that level of fuel. Orbital mechanics is hard.

I have a handful of stamped movie DVDs that are now unreadable. It's not just the burned discs that are a lot more fallible.

Hmm, couldn't you just use CPU cycle counters? At 1GHz, that's 1ns per cycle. You don't really need 1ns resolution, even 5ns would do. You have to make sure you use a constant-time encryption algorithm, but that's not that hard. And all the timing "smarts" just needs to be on the vehicle end, so the fob (where power is more important) wouldn't use much.

Nobody talks about storage in terms of bits, it's always bytes. And there's a more applicable unit than 125,000 gigabytes, it's called 125 terabytes. And you can readily buy consumer 22TB hard drives today, so 125TB would require a stack of hard drives 6 inches tall, not 6 feet tall.

And oh yeah, multi-layer optical recording has been around for a long time, and multi-layer mastered discs even longer (the very first sentence of the summary is also dumb).

Being able to make a disc that can store 1.25TB on a single layer (I'm assuming all the layers are the same density) is a nice feat in itself, and 100 layers is interesting too. But a dumb article is just irritating. Maybe they could have told us how many Olympic-sized swimming pools full of punchcards this was equal to?

But the problem is neither a replay nor man-in-the-middle attack. A replay attack is recording a successful message in flight and playing it again later to trigger the same action again. A man-in-the-middle attack is recording a successful message in flight and decoding it to recover the contents (and in some cases to change those contents). Those are both handled with proper use of encryption (which in this case is not hard at all, since the fob and vehicle have to be paired in advance, as opposed to your browser talking to a remote website that it's never "met" before).

This problem is like someone sticking an extra hundred feet of fiber in your Internet connection somewhere. For secure Internet communication, that's no problem, because Internet communication has no assumptions about proximity between endpoints. The fob/vehicle communication DOES require proximity, and that's the point that is being attacked.

You can start a push-button-start vehicle with the key just outside, but when you drive away, it will stop because you've lost proximity to the fob. That proximity is part of the security, and is what is being attacked. You cannot change that by altering the signal (adding or changing encryption/authentication/etc.), because the signal CONTENT is not what is being attacked.

Authentication is built on encryption. It can be symmetric (with a shared secret learned at pairing) or asymmetric (with sharing of public keys at pairing). But neither does a thing to protect against relay attacks.

Part of the vehicle side of the security is built on the assumption that the fob is range-limited (push-to-start is a proximity system requiring the fob to be "in range" as well as answer an authenticated challenge response), and relay attacks break that assumption. It's the same as if I take your fob and put an amplifier on it, except with a relay attack, I don't have to access your fob. I just have to have something in range of the fob and something in range of the vehicle.

Authentication protects the content of the signal, timing is the only thing that can protect the distance/proximity part of the security.

You are not reading the problem, encryption is not a solution AT ALL to the current problem.

The current problem is that the communication between the vehicle and the fob is RF (of course). Car makers assumed that'd be secure because it's distance-limited (the fobs are really low power), but thieves are using radio relay devices. Asymmetric encryption between the fob and the vehicle still passes, it's just now instead of only working 10 feet away, it can be relayed basically any distance. Keep your fob by your house door? Thieves can stand outside the door and relay the signal to your vehicle. That's not a replay attack (that proper encryption prevents), it's not even a MITM (because the thieves don't learn any information).

The solution (as already stated) is to also check timing. Require the fob to be in a specific spot next to the vehicle transceiver when pairing and learn the minimum response time (this handles the possibility that a new fob might have a different speed processor and respond faster or slower). Then require all communication for that fob to be within that learned time plus N nanoseconds, where N is the number of feet away you want to allow the fob to work.

It makes the vehicle side cost slightly more (probably a few dollars), but the fob doesn't even have to change.

It's almost like the complaint itself was some LLM-generated ramble.

There's already another fork of nginx from a group of former nginx devs, Angie. Given this week's dev decided to make another fork rather than join them tells me there was already issues between devs... and it kind of feels like maybe this week's dev was the issue (can't work with the group that formed Angie, can't work with F5).

Except: part of the holdup for NASA landing people on the Moon again is SpaceX - that's who NASA is paying for the lander portion, and they're behind schedule.