AlotOfReading

Not all companies do that.

There's a certain vendor that requires me to place same-day orders by a specific time. You can easily place an order from the website. If you need to cancel one, you have to ignore the grayed out cancel button and call their cancellation support line. There you'll talk to an agent that doesn't have access to cancel orders, so you have to convince it that it can't help you before you can transfer to a real employee with the ability to hit the "cancel" button.

Normally I think "CRC" when someone uses the word checksum, so my initial question was "why is this not calling sha256sum?". Lo and behold, it just calls GitHub to get the hash.

That's fine, I guess. Nothing wrong with utility scripts. But I feel like "old man yelling at cloud" when I see a codebase with 178 stars, 527 commits, discord channels, and dozens of indirect dependencies for it.

If you rename +/- Inf, that's what saturating arithmetic is. Very likely your language and hardware already supports it.

NaN is almost always a mistake, and adding it breaks the law of identity. You don't want it.

Rust's definition of memory safety doesn't consider leaks unsafe, which isn't to say your system requirements can't .

It's a much more useful correspondence than just an isomorphism. Take your base-2 2-adic integer. Truncate it to whatever bitwidth you want. That's the two's complement representation of that number. Unsigned pops out as a special case, obviously.

I've mostly seen this used by cryptographers to prove results over arbitrary bitwidths, since you can prove it over the p-adics and deal with truncation/division separately.

Modulo arithmetic is taught to American students as clock arithmetic in elementary school as well. Signed integers are better described as truncated 2-adics, which are definitely an advanced topic. It's basically a Greenland/Iceland situation. The complicated, difficult one is given a friendly name to trap naive programmers.

It's not about legal liability, though I admit the example of tickets was informal and confusing.

Let me state it a little more clearly: the driver is the component in the vehicle system design that's ultimately responsible for ensuring the safety invariants are maintained. In a normal car, that's clearly the human in the driver's seat. Less obviously, the same is true of a Tesla with FSD. If we move that human to a remote control room, they're still the driver even if they're not physically in the vehicle.

It's only when the computer itself becomes responsible for maintaining system safety that it becomes the driver. Waymo is an example. Waymo also employs people in a remote call center, but those humans aren't responsible for safety and hence aren't drivers. But a Waymo employee out on the street using their <5mph remote control mode is driving it, because they've taken on the safety role again.

Legal liability can follow from this, but it's a much more complicated classification that I don't expect to ever have a singular answer, or even a knowable answer in many cases.

This is a common misconception. People tend to think driving is controlling the steering and pedals, so if FSD does those things it must be driving.

It's not. Driving is whatever has ultimate responsibility for the vehicle and its occupants. If a cop pulls you over while FSD is enabled, it's not Tesla who's paying the ticket. If FSD has an issue, you're the driver who has to respond.

Think of FSD as a very nice cruise control. You're still driving, even if you aren't touching the wheel.

The reason this wasn't done by the standards committees is that they spent decades refusing to admit there was even a problem they could help fix. And if there was a problem, it was easily avoided by just writing better code. And if writing better code wasn't enough, well it was certainly too expensive to provide as a debug option. And if it wasn't too expensive to provide as a debug option, the implementors should really lead the way first. And on and on.

The C committee at least seems to get it now. The C++ committee still doesn't, led in large part by Bjarne.

It doesn't have to. It raises an error that the system can detect and take action on. Usually that'll be some combination of interrupt/reset and an external pin to let the rest of the system know what's happened.

As always, improving accessibility for humans makes automation more effective. If the humans need to remember a PhD's worth of source code/documentation to contribute effectively, your codebase stinks.

We'll be much closer to a greenhouse earth than a glacial earth if we get that 4°C warming, so the distinction is more academic than practical in most contexts. What's a century here or there in geologic time?

In the US, a vehicle with an outstanding recall technically isn't roadworthy, though consumer level enforcement of this is non-existent in practice. It's mostly enforced on dealers, who can't sell a vehicle with active recalls. The only way I can imagine it mattering to a consumer is if they sold it.

How would they do that? I'm sure you can buy some sort of aerospace component that has the signal integrity to do radios, but it sounds expensive. There's a reason these kinds of components (e.g. muxes) aren't usually physical disconnections.

Automotive power relays are at least a thing, but they're expensive consumables that have significant power draw.

In either case they would have had to add the components at design time and do the physical validation/testing, not ship it as a software update.

The demo above uses the prompt "hi". The openclaw string is in the git history, which Claude goes looking for.

Shedding is not a significant concern. You almost certainly use glass fiber reinforced plastics in products like your car and power tools.

If I had to guess, this is a continuation of Anthropic's ongoing war to make third party tool usage go through per-token billing, specifically against a tool called Hermes-agent [0]. You can easily imagine why Anthropic might want to silently re-bill a customer violating their silly ToS restrictions and how an LLM told to implement the feature might arrive at this "solution".

[0] https://github.com/NousResearch/hermes-agent

Someone once coined a related term, "disassembler rage". It's the idea that every mistake looks amateur when examined closely enough. Comes from people sitting in a disassembler and raging the high level programmers who had the gall to e.g. use conditionals instead of a switch statement inside a function call a hundred frames deep.

We're looking solely at the few things they got wrong, and not the thousands of correct lines around them.

What's wrong with Grace Hopper if you want to throw buckets of local memory at a problem?

Can you provide a different source on that? The govcloud page you've linked says operated by US citizens, not built by US citizens. I'd be pretty surprised if they did the latter. Standard practice as I understand it is to simply run the standard software in a separate environment. A recent Propublica report [0] pointed out that Microsoft was hiring citizens to escort the actual engineers that aren't citizens, for example.

[0] https://www.propublica.org/article/microsoft-digital-escorts...

ASML is in Europe because Philips/NXP is in Europe. The fundamental research EUV is based on was done in the US, then made available to industry via a holding company called EUV, LLC. Intel tried to bring in Canon and Nikon, but was rejected by the US government. Two others were approved, ASML and an American company called SVG. ASML spent a couple decades doing the incredibly hard work of productizing EUV and acquired SVG along the way. Canon and Nikon tried playing catch-up with an Asian consortium, but arrived late to the party.

My experience is that if you write an interface that (rarely) returns NaNs, someone will use it assuming it's never NaN no matter how good the docs are. Then their code does bad things and you have to patiently explain why they're wrong and yes, they are holding isnan() wrong (in C/C++).

How many checks are we talking? A well-implemented monotonic system should be able to do tens of thousands of these checks (or more) in the time budget I associate with a heavy page, and start before the entirety of the permissions/feature data is available.

You don't necessarily have to choose one or the other. The Blue lagoon in Iceland is a famous example. The water comes from a power plant nearby.

You're not required to site them that close either, because of how regional the conditions usually are. A couple miles plus or minus doesn't change things too much.

    Isn't that too wide a range of humans and ancestors to characterize in one group?

Yes, that's one reason why I have high standards for arguments from ethnographic analogy.

    Are you skeptical about 11 kya ancestors doing similar things? Why?

Because modern forager groups have survived for centuries on the margins of colonial states. The environment they inhabit is very different from late pleistocene humans and we should default to skepticism in the absence of other evidence.

It was personally related to me that it occurs among the northern Aché by an anthropologist who lived with them and had photos of him carrying coals.

The warlpiri and the yuqui are two other examples, along with certain andaman groups.

Tasmanians do start fires, but often prefer to carry. This is a surprisingly common practice. Starting fires is a lot of work.

It shouldn't. It's been extensively documented among modern human groups.

The major question is how much our understanding from recent forager groups applies to pleistocene foragers ("ethnographic analogy"). I'm in the generally skeptical camp. Many other anthropologists aren't, particularly those in older generations.

There's a large subpopulation of people flying who seem to have no idea how planes and airports work. Maybe they're sleep deprived or it's their first time flying, but these announcements are targeted at them.

The advantage is that the inevitable chemical spills won't make the atmosphere any more hazardous.

The "usual" process in big tech is a recruiter call, 1-2 technical screening calls (sometimes an EM call), then the main series of 3-6 domain knowledge interviews are done over 1-2 days.

The latter are pretty grueling, especially when conducted on-site. Apple recommends you show up 1-2 hours ahead so you have enough time to get through security, for example.