> From what I can tell, dsl of any type didn’t really take off in America.
VDSL was the core of the AT&T U-verse offerings in the US for a good decade perhaps a little more. This was marketed as a full cable replacement, as it included Internet, TV (including the normal cable channels), and optionally landline phone (over ip, but without some of the normal headaches of VOIP, as AT&T could treat this more like a digitized POTS line on their side, much like the normal pots lines they digitized behind the scenes). There were also some other smaller deployments here and there, but that seemed to be the biggest one in the US.
ADSL/ADSL2/ADSL2+ certainly did exist, but to work well you need to be relatively close to the local exchange, needed copper wires in good condition, etc. It was offered fairly widely, like by most companies offering phone service over copper lines, but because the quality could vary quite significantly depending on things not obvious to the purchaser, it tended to get a bad-rap. If you tried it once, but was unluck enough to have it not work well, you would write off the tech, and tell all your firends not to bother, and go go with the cable offering.
For me personally, in its heyday, ADSL2 beat cable hands down, as in that time frame cable was only using a tiny fraction of its bandwidth to provide internet service, and only a few feeds coming out of the local office, so the amount of oversubscription was insane, and amounted to basically fraud, as you could only ever get anywhere near your advertised speed at like 4 am.
That's at best a partial fix for the API side. Python side CPython sill exposes a LOT of implementation details, and as a result occasionally projects will choose to rely on some of these details. Then other implementations need to decide whether to also pick the same implementations details and expose them, or use different details, and lack compatibility with any library that depended upon them.
The python documentation has historically also not been especially clear at distinguishing between what the language guarantees, vs what is just implementation details of the cPython implementation. So even if libraries wanted to try to avoid depending on implementation specifics, it isn't always clear what those are.
The net result is that for the end user python the language is effectively: whatever cpython does. This really, really discourages creating alternate implementations, as the only way to be an alternative implementation with good compatibility is to be a living fork of cpython, constantly merging in all the changes from it, while also maintaining your improvements.
The current WebP Spec RFC9649 defines the format as effectively:
A 'RIFF' chunk containing formtype 'WEBP' and a mandatory 'VP8 ' or 'VP8L' chunk, and optional 'VP8X', 'ICCP','ANIM', 'ANMF', 'EXIF', 'XMP ' chunks and possibly some unknown chunks, where if any of these optional chunks appear 'VP8X' must be first, and with certain ordering restrictions on the chunks.
It is true that earlier spec versions only allowed the core 'VP8 ' or 'VP8L' chunk, and the spec does warn that some older software might not support files with the newer chunks, so they should only be used if really needed for best compatibility.
This is the spitting image of old pre-CRM thinking:
If I try to force the captain to go around, (or follow procedures or whatever), then i am exceeding my authority and will probably be fired. Some cultures have this sort of mentality a lot stronger than others, and it has zero place in the modern cockpit.
While a captain can pull rank, they really should only ever do it with respect to the first officer if: an inexperienced first officer is trying to insist on something dangerous or forbidden by law or policy, or if the captain fully understands an FO's concerns, is fully accounting for them, and as the person ultimately responsible for safety, has determined from experience and training that the current action is safer than alternatives, and would explain but cannot explain right now for workload/emergency status reasons.
This seems like a no win situation for the subordinate pilot. Grabbing the wheel of an aircraft while landing must have its own set of risks. We also only hear about the times when the subordinate pilot didn’t prevent a crash. Never hear about the times they were mistaken and did nothing.
A big part of the monitoring pilot's job is noticing when things have gotten too far and taking over controls. This does very much include scenarios when the pilot flying has fallen to tunnel vision, subtle incapacitation, and the continuation/sunk cost fallacy.
He doesn’t need to “grab the wheel”. Simply saying “go-around” would have been enough, it’s highly highly unlikely that the captain would have ignored that.
Yes I was wrong. Looking at the transcript that go-around call out was likely from the PF; that's where the data recorder indicates the brakes were released the throttle set to max for the go-around (and go back to braking only 4 sec later).
Still, the PM notified PF that they were going too fast many times during the approach. All warnings were ignored.
I don't think there's a law mandating it, but CRM (https://en.wikipedia.org/wiki/Crew_resource_management) has been used and trained by all major airlines since the 1980s. The reason is simple: it doesn't really help to have two people in the cockpit if only one of them is making all the decisions.
And all Military air forces AFAIK. The military of course also takes rank very seriously, but there was existing understanding that Mother Nature doesn't give a shit about rank and so CRM makes sense in that same practical vein.
Also, you'll see that says "Crew" not just "Cockpit". Turns out that from the cockpit of an airliner you've not always got the best possible view of the problem. If the steward who has no idea how to fly a plane insists it's the right engine that is on fire, her input is valuable, from back where she's serving customers with coffee she can see the engines, the fire is on the right, whereas you're just looking at sensor outputs and you were maybe about to turn off the left engine.
I don’t think it’s required, but my friends who do flights for remote mining operations in SE Asia use the same concepts — so it really is pretty standard for commercial flying, even down to remote private operations.
A bad bump on a commercial plane can be hundreds of thousands to millions in damage + downtime + inspection/repairs. And tens or hundreds of millions if you wreck a big plane. Companies may be evil, but most would still prefer you waste $2k in go around fuel than $200k because you decided to set it down badly or $20M+ because you drove their plane off the runway.
Yeah, my bigger worry here is more about if somebody direct edits a file in their venv and uv was unable to make the venv with reflink/COW semantics and fell back to hardlinks.
This could happen with a user asking their editor to show definition, and then not realizing the result was in some other package, changing it, and saving it, but only if the editor's normal atomic replace mode is disabled. So perhaps that sounds farfetched. But if an AI agent wants to patch some package in a venv, I've seen them bypass the editor and use command line tools to make edits often enough to be concerned. Like corrupting the cache for one package version is already not ideal, and this could potentially affect multiple versions now?
I suppose is this happens the right fix is to nuke the cache completely?
But keep in mind that there are multiple kinds of exceptions.
Some exceptions, indicate scenarios the caller could reasonably have avoided. This include things like argument bound or null checks. A caller absolutely could avoid these exceptions by doing its own checks. This can be split between checks that the caller really should have done, like not passing null to a function that cannot take null, vs those where baking the relevant knowledge into the caller would be undesirable (perhaps because future versions of the library expect to accept more values).
There are exceptions that in theory a caller could avoid, but in practice it is impractical, like an exception thrown by a parser of some complex format if the provided input isn't legal. The only good way to avoid such an exception is to have a non-throwing parser that you can check with, but you probably don't want to parse twice. An alternative interface for the parser might be able to totally avoid the exception, returning either succeeded (with result tree) or fail with error message, but that would be a design choice of the implementor, not the caller.
There can be exceptions that indicate a logic bug in the impleentation (things like throwing if some invariant the implementation is in charge of is violated), but more often this is assertions instead.
Lastly, you have exceptions that there is no possible way the caller could always avoid. IO exceptions are among these. While you can sometimes do existence, space, or permission checks or similar to reduce the probability of getting certain exceptions, something else could race your app between the check and performing IO, and make them happen anyway.
The primary target for contracts are exceptions that callers both could and should have avoided, and the exception/assertion case that is trying to verify the implementation is working as expected.
The other categories of exceptions are more or less totally out of scope.
To be clear, they are billing for all the coded line items at the listed prices, it is just that the agreements with the insurance company will disallow many of the line items in favor of other ones. They bill everything, because they may accept some insurance that has not negotiated a day rate, and in that case, the day rate code would be disallowed and some of the other line items will be paid at relevant negotiated rates instead (with others still likely disallowed). It needs to be the same bill in both cases, so they need to include everything, and the list prices need to be greater than or equal to what any insurance would pay, or they might lose out on the difference.
This is one of the areas where more standardization would certainly help. If there were more standardization of which codes disallow which other ones (which can currently vary wildly by plan even with the same insurer, must less across insurers), then a lot of line items could actually get removed as truly redundant, vastly simplifying the bill.
VDSL was the core of the AT&T U-verse offerings in the US for a good decade perhaps a little more. This was marketed as a full cable replacement, as it included Internet, TV (including the normal cable channels), and optionally landline phone (over ip, but without some of the normal headaches of VOIP, as AT&T could treat this more like a digitized POTS line on their side, much like the normal pots lines they digitized behind the scenes). There were also some other smaller deployments here and there, but that seemed to be the biggest one in the US.
ADSL/ADSL2/ADSL2+ certainly did exist, but to work well you need to be relatively close to the local exchange, needed copper wires in good condition, etc. It was offered fairly widely, like by most companies offering phone service over copper lines, but because the quality could vary quite significantly depending on things not obvious to the purchaser, it tended to get a bad-rap. If you tried it once, but was unluck enough to have it not work well, you would write off the tech, and tell all your firends not to bother, and go go with the cable offering.
For me personally, in its heyday, ADSL2 beat cable hands down, as in that time frame cable was only using a tiny fraction of its bandwidth to provide internet service, and only a few feeds coming out of the local office, so the amount of oversubscription was insane, and amounted to basically fraud, as you could only ever get anywhere near your advertised speed at like 4 am.
reply