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.
I have successfully had am M1 MacBook open and in active use (albeit not with very heavy workload, mostly text editor and web), while plugged into a Nintendo Switch 1 charger (only thing I had handy at that moment), and was watching the battery percentage slowly increasing over time. So even laptops can sometimes charge slowly while in use with a rather underpowered type C charger (Albeit still slightly better than a cheapo 5V 3A Type-C phone charger).
The original design intention of this approach was that wallet apps were independant and interchangable, with any wallet app able to talk to any attestation provider, to get age attestation tokens, and any site/app able to talk to any wallet. The wallet's job was merely to securely hold a bunch of attestations tokens, and dispense them to other sites/apps on request.
So you could use an open source app, or government provided one, or one provided by your bank, whatever you trust the most to not be recording data about relying parties and sending it somewhere you don't want.
The version of the document currently on GitHub has heavily deviated from that original intention. This is very unfortunate.
Even so this version is supposed to still be incapable by design of sharing any data with a relying party other than "over 18" and was designed such that the only way for a relying party to determine your identity is to be colluding with the attestation provider, or by colluding with the wallet app.
To attempt to address the first issue they have the unfortunately optional ZKP protocol. The original design assumed that users could find a wallet that they were certain would not collude with the RPs, and was considered a non-issue, but unfortunately it is a huge hole in the current version.
The PLC keys are normally intended to be held by your current PDS. Not a hard protocol requirement, but without it, certain things like migrating to a custom domain handle cannot be done cleanly though the app, and would need to be done manually. It might be a requirement of the bluesky hosted PDSes though, as those have some extra requirements beyond the reference self-hosted PDS.
The fact that BlueSky runs the PLC central server is supposed to be fixed by them creating a swiss association to run and control it instead, but while they announced this, it is unclear if it went anywhere.
If you migrate to a self hosted PDS using the all-in-one migration `goat account migrate` command, it will temporarily change your handle to a subdomain of your new PDS, and leave the new PDS managing the PLC. You can instead perform each step manually via goat or raw API calls, either of which would let you transition to direct PLC key management, and/or a new domain based handle as a single atomic plc update, as part of the overall migration process.
See https://atproto.com/guides/account-migration for a discussion of the process at the protocol level. See https://whtwnd.com/bnewbold.net/3l5ii332pf32u for a breakdown of both the automated, and step by step process via `goat`. It does not go into the details of switching to self managed, but it basically requires crafting your new PLC document, sending that one to the old PDS to sign, and then submitting the result. There are manual PLC signing, and submission commands available as `goat plc` subcommands, for use once you have manual control.
This more or less answered my question in exactly the way I was dreading.
The option to register and manage PLC rotation keys should be built into the Bluesky Appview itself, sitting right next to the existing option to verify a domain with your did:plc string. Having the option only exist as a command line tool means most people aren't going to use it and third-party PDS hosts are going to be a pain in the ass to use for people with data already on Bluesky's PDS.
I'm also not happy about the existence of the PLC directory at all, mostly because it's not really explained all that well in the Bluesky interface. I assumed PDSes were just identified by their domain name (like a Mastodon instance is) - and while that is an option with did:web, it's not the default option, and you cannot migrate an identity between PLC and DNS governance. Hopefully that will change.
> The fact that BlueSky runs the PLC central server is supposed to be fixed by them creating a swiss association to run and control it instead, but while they announced this, it is unclear if it went anywhere.
That I didn't know! So... Basically the whole solution is still "trust me bro"?
Kind of. From what I've been told, the non-trust-me-bro solution is did:web, which is just "you host a file on a web server containing all the same information the PLC serves". Problem is, if you already have a did:plc, you're stuck with it - you cannot migrate off a DID, as it's intended to be about as immutable as an SQL primary key.
There are also read-only mirrors of the PLC, but that doesn't really matter, given that the whole point of the PLC is to be a trusted[1] entity for arbitrating identity conflicts. This is necessary because the PLC is what lets you register new signing keys to overrule an uncooperative PDS - otherwise, you have the moral equivalent of Mastodon instances where an instance admin can hold your identity hostage.
And, technically speaking, did:web is also "trust-me-bro", in the sense that it ultimately relies on DNS to resolve names to servers. DNS and PLC are moral equivalents[0] in that ultimately there is a central authority to arbitrate disputes over who owns what identities. In fact, there kind of has to be. Every proposal for a true distributed identity system ultimately boils down to either pinning a self-signed key or web-of-trust, both of which have undesirable failure modes due to the lack of a central trusted authority.
Ultimately, the choice comes down to: do you want to pay the DNS people $15/yr for a zone to host your DID on, or do you trust Bluesky's PLC server to offer that hosting for free?
[0] Almost. In practice, DNS is a recursively nested set of central governors; every TLD imposes an additional governor on top of ICANN root zone management. In practice, almost all DNS shenanigans happen at registrars; and of the shenanigans not caused by registrars, most of them happen at the TLD operators and not the root zone itself.
[1] PLC stores all identity updates in an append-only log. I'd call it a blockchain, but the Bitcoin people ruined that term. Practically speaking, if the PLC were to "turn evil" and mess with people's identities there'd be irrefutable proof of it. How much this assuages your concern depends on what you think about Certificate Transparency.
Yeah, an agent should run with permissions no greater than that of the user on whose behalf it is executing, and ideally with less permissions. This is the scenario that is easier to fix, simply give the agent an API token with rights no greater than the user it is acting on behalf of. This could be a literal token for their account, or a limit-rights-to field or whatever, multiple possible approaches.
The harder problem is outside actors trying to prompt inject to get the agent to do something the user has rights to do but which the user doesn't want to happen. That is the hard scenario to fix, due to the nature of LLMs.
Thrashing is a well known known issue that can occur with swap, but it can also happen from page cache or memory mapped files. Indeed not having swap enabled can make things worse, as private pages that haven't been used in a hours cannot be swapped out to keep the important files cached or memory mapped.
Realistically for measuring physical memory sufficiency, you care about memory/data of any type (even files) that will be used in use upcoming time period, and ensuring that a sufficient percentage of it can be held in physical memory to avoid thrashing.
This is hard! Technically impossible to know for the general case (halting problem), and all methods of trying to approximate it involves trade-offs.
In theory, sure, an identity verifier could issue you you a bunch of single use JWTs signed by them that contain `{"over18":"true", "nonce": 12748583..., "iss": "<issuerurl>"}`, signed by their key. A relying party just needs to know the public keys of all the issuers they trust, and can consume this JWT, verify it, and never learn anything about your IRL identity.
The important things are that they must issue a bunch at once. (Otherwise, correlating who you are becomes easy). They must keep no record tying nonce or the full JWT to an individual identity. Something user local or otherwise trustworthy (not keeping logs), needs to hold on to these, and send them out as needed, being very very careful never to reuse one (as that would enable cross site tracking). Lastly a relying party must be required to trust many issuers, not just those they are colluding with track users across sites with this.
The European Commission actually proposed pretty much exactly this system, also with a variation where instead of revealing the signed token, a ZSNARK proof (that you possess a validly signed token with the over18 attribute from a specific issuer) could be given to the relying party instead (to make it impossible for issuer and relying party to collude to release your identity). Many people here seemed to not like it.
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.
That's it, the only two reasons.
reply