Note that 5th grade papers are always just horrible to read. This is why I don’t like LLM output, because it sounds just like 5th grade papers. Not a soul wants to read middle school papers.

So I think broadly speaking the LLMs can generate middle school papers generally fine, at least they fit in.

The parent comment was “no phone”, which I read to mean that buying EU wouldn’t be worth it for the premium.

If you need a basic smartphone and aren’t too picky, then you can get unlocked new for that.

A fair number of Moto G models go unlocked, new for under $200.

If the code actually works and is vaguely important, I think you are right.

If anyone ever has to fix it because it’s also broken on top of being a mess, well they aren’t quite so safe. Maybe if you are always available to fix it same day, but if you ever go on vacation and it hits the fan while you are unreachable…

I can’t speak to this situation, but broadly speaking I am familiar with general messed up stuff like this as well as perhaps adjusting some fine details to make the scenario relatable to an audience unfamiliar with the specifics of the real situation and/or obfuscating the details so that the person doesn’t out themselves to someone else familiar with the specifics enough to recognize.

The broad strokes seem plausible and any oddities in details I consider to be less important and/or understandable if it was tweaked for an internet audience.

Think the issue is, practically speaking, we don’t have a good track record of modeling precisely where the camera feed goes to decide if it is stored or not. Mobile OSes do present a more sophisticated permission structure that gets closer, but things are still too flexible to really comfortably assure that nothing that was a party to the feed didn’t somehow store it.

Assuming the system ecosystem is locked down, one could conceivably indicate only for retained camera data. App has camera permission but no internet and no storage premission, ok.

Of course, realistically speaking they kind of tried that with camera modules having their indicators OS controlled, and the practical reality is that malicious use could independently operate the camera from the LED and so the lesson learned was to keep it simple and have the LED control inexorably linked to camera activation at the module level without any sophisticated OS control possible.

I feel like when ‘Zero Trust’ first became a thing, the theme was ‘you should have every endpoint under your control hardened so it need not feer untrusted peers being able to connect’. E.g. if you think you absolutely need VPN to a ‘private network’ for security, then you are failing to be hardened in a ‘zero trust’ way, because you implicitly fear that your systems would fall to untrusted peers.

I feel like it’s evolved to ‘don’t let anything be able to connect to anything under your control unless you have admin privilege over it as well’. Which is particularly a nightmare when you try to collaborate between two companies, each balking at the other’s hard requirement to have admin access to all network peers of interest.

There’s nothing in the text that indicates that’s what he was thinking.

She isn’t a telepath, it’s not about what he was thinking, it’s a risk of how it may be perceived. Taking offense/getting defensive is not about what was intended, but how it was taken. So if she, even incorrectly, thought there was a ‘pity date’ being offered she might have been overly mean in her reaction.

It’s not about judging, it’s about feedback and offering an outside perspective on facets that could be done better next time. Even if you are thinking this should be a good opportunity for both of you because of her stated problems, don’t bring it up explicitly. It’s clearly something she is likely to be touchy about.

I think it’s not so much that he approached a stranger or even that he overheard the conversation, but using his overhearing of the conversation as the whole pretense of asking her out.

“I heard you talking about how you need a date so here I am”

The problems are:

While you don’t expect privacy, it is still kind of weird for someone to explicitly mention that they were an unintended participant to the conversation. It amps up the awkwardness which is the last thing you want if you are trying to make someone comfortable. She may very well be explicitly aware that her conversation was overheard, but it’s something that can be put aside, except it was explicitly brought up.

Further, the rationale makes it sound like he thinks he is doing her a favor. The takeaway is not “you seem interesting/attractive and I’d like to get to know you” it seems more like “you seem like you are in need and I could do you a favor by taking you out”. That takeaway is going to feel like the offer makes her just seem more pathetic, like a “pity date”. Particularly in front of her friends, any whiff of a “pity date” will trigger being defensive.

Of course the story is probably all a fabrication, but taking it at face value I certainly see how it is ‘off’.

It certainly means something, it means that every time we make a system at scale, someone games it to exploit the rest, it’s just a question of how gaming the system looks, and how much we preserve a fluid dynamic where that can change over time.

I think we can have pretty decent progressive economic principles in essentially pure form in tight knit communities where everyone has a decently nuanced understanding of what everyone is doing for everyone, but scaling up those concepts to extend that to more loose economic relationships has proven elusive…

We don’t really have ‘pure’ socialisim and we don’t also have ‘pure’ capitalism, which is for the best really.

Capitalism cannot model societies needs. Collective risks and fundamental human needs in the moment are areas that socialism is a decent starting philosophy.

The things that societies ‘want’ is often better done with capitalism. Entertainment, luxuries, some sorts of technological advancements.

Key thing is to apply nuance to get the best out of whatever system we choose to game ourselves with.

Any ideal stretched to ‘black and white’ is going to go badly, just differing on what startegies the ‘winners’ must employ to game the system.

To the ‘infinite growth’, that’s actually possible, because we define ‘growth’ with this currency abstraction and with a whiff of inflation, the numbers can grow without end, satisfiying the “must do better than last year” itch while being able to stay level or even ertract in practical terms.

"“Under capitalism, man exploits man. Under communism, it’s just the opposite.”

If I provide passkey support and still require a password, most users will get annoyed and not bother. If I provide it as a replacement for password, then I can get them onboard more often. I’d rather have them using passkey than sticking with password.

It’s client specific and my phone requires whatever can unlock the phone and chrome requires either windows hello or a pin if under linux.

Certain implementations do whatever, and as far as the backend is concerned, there’s no way of knowing, unless you want to get into the business of locking down specific vendor keys…

But I say MFA is overrated versus just getting away from generally crappy password factors. Also passkeys are less phish-able than OTP type solutions.

I wouldn’t even mind wrangling some normalized data, but it doesn’t seem very normalized in their examples.

Their first example suggests “great, there’s a human appropriate title and detail, and maybe this standard will say you should at least have those and they should be ready for pass through to a human operator”, with extensions providing room for more sophisticated behavior.

Then the second example, no more top level detail, now there’s an ‘errors’ array, and detail is under the children (which they don’t formally describe the concept of reparenting attributes, just incidentally showing it in an example of what an implementation could do with ‘extensions’). Well, at least I can still pass through the details if I find them and it will make sense right? “must be a positive integer”… Ok, nope, error information that requires the client to process a json pointer in order to manufacture some sort of actionable feedback. Again, this could be a neat optional feature, but a generic core client really has nothing they can bite into that generically applies to the standard.

The cited RFC I think is close to some ideas but softens it by trying to be open ended. If it specified mandatory top level “detail” member that is reasonably directly informative to a human operator without further processing, great, I know exactly where to find it even if I don’t otherwise understand your problem type. Mandate that errors may be a collection under an ‘errors’ list, but otherwise identical to top level? Cool. Saying that here’s some recommended members, but they are all optional and the behavior is really up to you, and you can just freely change everything you want and call it ‘extensions’… Just not prescriptive enough despite the long words…

Ok, got you, thought you were saying a bad url from client was inherently a backend mistake.

It’s ok, as long as you make sure to use mongodb it will be webscale no matter what. But if you date use anything else, it won’t be.

misdiagnosing errors originating from transport as application errors, and vice versa.

Shouldn’t the response body disambiguaite clearly whose fault it is? I mean you have to anyway if you advocate for ‘200 for everything’. You still have that same response body whether the HTTP status code is 200 or 500.

We honor the status code while providing an error body and it’s always blatantly obvious whether it’s an infrastructure issue or “true backend” issue when we see an issue. In my team I can’t recall anyone ever getting confused for even a little bit about whether an observed anomaly was web infrastructure or the backend, despite us setting HTTP status codes to error when, you know, we see an error.