mpyne

So use the C standard library instead of the C++ one. You still get RAII / constructors/destructors and runtime polymorphism, along with stronger compile-time type safety.

I frequently do that myself on simple C++ programs just for compile time reasons alone, where I'll use stdio.h instead of std::iostream or std::format.

All of which have solutions in this thread too. Nothing forces you to use a passkey provider that enforces attestation if that’s what your threat model worries about.

TOTP does not replace passwords, and frankly I’m sort of confused why you think they do. Doing passwords right across a multitude of websites is more than a minor inconvenience unless I am willing to simply give up on security.

And I am not.

> Yes the big boys get volume discount. But that doesn't magically entitle them to last decades's pricing.

You’re trying to refute an argument I did not make.

They do not have to be cheaper than 2016. They have to be cheaper than what your business could otherwise string together paying current market prices. And they will be.

No it's not. If "bad software delivered faster" is a problem, it's a problem long before LLMs. But the history of software-based products has shown that "delivered faster" is consistently more important, as bad software that attains significant usage will be made into good software one way or another.

I don't think it’s a conflict at all.

The invested time consistently into the things that were important to improve. If the art was good as-is (and it was), they didn’t waste time “perfecting” it further.

But as long as the gameplay itself still felt fuzzy or like there was friction, they spent time improving it up until their deadline. This was not a lack of project management, this was project management actually done well, for once.

In fact they accidentally optimized Super Mario 64 around its debug-mode performance, and shipped the game in that state, with debug symbols and everything. But they could get away with that because the game they shipped still landed in the performance budget they needed for the gameplay they were after.

Yeah it was light-years better than other games at the time of its release. Even now it’s very playable even though it’s not “fully modern”.

Then they've been fucked since C beat Lisp, and that hasn't been enough to cause Silicon Valley to implode.

> Cloud providers have to buy new hardware too to grow and to replace failing/obsolete units.

They can negotiate better prices based on their scale, and even on their ability to internally source key components if needed.

E.g. if AWS/Microsoft/Google/Apple buy 80% of Micron's entire output it's probably at a much better price than the rest of us competing over the other 20% are going to get.

Third parties manage nearly all my money, my future wealth, the quality of the water I drink, etc.

Yes you need to put thought into who you trust to provide password management but for most people having a professional third party help them improve how they use passwords will be a benefit to security overall.

> There is virtually no difference to writing down a password on a piece of paper. Well, I guess a passkey is a lot longer than the avg password.

The big difference is not just that a passkey is a private key, it's that the server you register the passkey within holds only the corresponding public key. They don't have a copy of your password (long or otherwise), not even a hashed version of it that could be recovered from a password database dump of the server.

This is a big improvement compared to the days of having your "strong password" end up on the dark web somewhere.

> "Online" in the sense of "loaded in a device", as opposed to "sitting in my safe".

The "device" can be entirely virtual. I've written a passkey-compatible OIDC provider for use on my homelab and it uses passkeys. But the passkeys are just in a SQLite database, which can be copied wherever.

That's not advisable for security, which is one reason I've not released the provider for others to use, but passkeys can operate just fine with that.

If I wanted, the private key itself just be in something like AWS KMS instead of a SQLite database, and it would all still work fine. Nothing about passkeys itself requires a hardware device or that the key be unexportable.

" and ' are themselves conjoined with other uses.

" can be inches or arcseconds from cartography.

' can be feet (of measure) or arcminutes from cartography.

These actually all have slightly different symbols, and the symbols for the left/right quotation marks are actually farthest from this approximation, even if they are the most frequent usage.

It’s always been wrong in some respect to use a single available symbol to emulate three or more different typographical tasks, but quotation marks may actually be the one where the emulation is the most wrong.

    0 -> token_THE
    1 -> token_PART_prefix
    2 -> token_FULLSTOP
    ...
    0x3100 -> token_BYTE_00
    0x3101 -> token_BYTE_01
    0x3102 -> token_BYTE_02

and so on

The tokenizer would have to know to switch over to lexing as individual bytes rather than whatever else it might have been able to tokenize into but that seems like a question of labeling more than anything else.

They are typographically the right thing to have been using all along.

Using ' and " to pretend to be ‘/’ or “/” is on par with the typewriter days where people would use the l key to stand in for 1 also. A justifiable approximation when technology limitations prevented using the real deal, but an approximation all the same.

It's not specific to C or C++, though it is more prominent there.

Rust's unsafe mode, for instance, has undefined behavior. A whole list of them, in fact.

> It's not as smart as Claude Opus 5.5 High according to the AA benchmark.

If it's smart enough to do the job then it won't matter that Opus is smarter. At the right price and performance, at least.

Well, you're going to be in for a shock about how many government websites are in an unacceptable state.

And the fact is that he had to reverse that position because it was not supportable by the statutory law he was trying to use. So the DoW policy changed.

I'm a big fan of checking the facts, which is why I encourage you to stay current on the discussion. Companies that do defense work are already familiar with the need to setup corporate structures to ensure that the blast radius of changes to FAR, DFARS, statutory requirements etc. don't reach the main corporate entity.

Like, the whole term "defense industrial base" is a known category treated as "critical infrastructure" by the U.S. government for years now: https://www.cisa.gov/topics/critical-infrastructure-security... and https://www.congress.gov/crs-product/R47751#_Toc192775742

The thing that is novel here is that requirements traditionally focused on protecting for undue linkage with potentially-hostile foreign sources are being applied against Anthropic. But it's also novel that Anthropic is trying to apply conditions of use restrictions through its contract with the military.

I don't personally feel that's novel enough to warrant a ban across the whole supply chain, but that's been the net effect of quite a few other FAR and DFARS restrictions over the years, which have caused companies to either exit the defense space or avoid selling into it in the first place.

They already had that with 3D formulas. (Not even kidding... you can sum the same range across multiple spreadsheet tabs)

> The red lines that the Department of War wanted to cross were made extremely clear: They want to build Skynet with Claude, and build a mass domestic surveillance system.

They claim they want to use AI for "any lawful purpose". They didn't go further to say that they want to build either Skynet or engage in mass surveillance.

Anthropic wanted the DoW to specifically disclaim those things, and the DoW position is that it will not disclaim any specific mission set that it's legally allowed to engage in, whether that's Skynet, targeting, surveillance, or anything else. Not for Anthropic, not for any contractor.

But refusing to disclaim a mission isn't the same as saying you want to do, just like refusing to answer "when did you stop beating your wife?" doesn't mean you're beating your wife.

Is the DoW response to this tiff over the top? Sure, but it's also not 100% political either, I've run into many government bureaucrats who love bureaucratic knife fights like this.

> What if an Amazon employee uses Claude to develop the S3 storage service, which is a core product offering unrelated to the DoD but also something that will be provided to the DoD in govcloud?

Honestly that question has been open for as long as GovCloud has been around. I've used it myself as an exercise in pushing within the Navy to adopt public cloud where security requirements permit, rather than forcing everything onto GovCloud.

After all, if it's the same S3 either way then the real point of security isn't the Amazon datacenter employee changing out dead hard disks in a physical GovCloud datacenter, but the S3 service team developers who are frequently not even American citizens, but whose code may very well go on to touch the most sensitive data the nation generates.

They're not allowed to use it for military work, precisely so that the military supply chain cannot be broken by an unaffiliated private contractor acting at its own behest.

The Federal government often imposes terms on its contractors that specify what sub-contractors are allowed to do, including "flow down" requirements that ensure these terms are themselves enforced recursively all the way down to leaf suppliers.

None of those amount to a ban, after all private companies are also able to do the same thing, and often do. E.g. when Apple requires its suppliers to pursue clean energy efforts as in https://www.apple.com/newsroom/2023/09/apple-advances-suppli...

An analogy that might make more sense is horizontal scalability vs. vertical scalability. A leader's ability to understand all the details of the proposal brought to them by the team inherently caps the organization's ability to scale up.

Offloading the detail onto the team allows the org to scale higher by allowing the leader to bring more teams/problems into the mix. But it also introduces the complexity of keeping those teams in close enough alignment that the overall effect is still positive.

This is by no means guaranteed to be positive, and there's a lot of details to get right for leadership in making this work. But they are different details than what each individual team was bringing to leadership.

Abstractions are helpful, in business management as much as in systems architecture.

C++ also special-cases the `main` function. Probably because `main` is the interface to the OS so it gets special language treatment.

Cosmic rays and dying hard drives are not force majeure though.

Are you saying that most data loss happens because your data center gets blown up in a shooting war? Like, AWS is the first digital service provider to lose data in decades?

It may, but the latency it contributes to the end-to-end AI processing has been not noticeable in practice for our users.

That's not to say Bifrost wouldn't have been better, but the choice to use LiteLLM was arrived at after a fair bit of internal discussion (most of which predated my addition to the team), and so far we've seen nothing from LiteLLM that has been contradictory to the pros/cons they thought would be the case when LiteLLM was adopted.

Or in other words, the org will be happy indeed when they have solved so many of the rest of the problems we've had in AI uptake that the difference in latency between one AI gateway or the other becomes a problem to be solved.

Sure Rust is better on it, my point is that it is there, despite that community making it a Big Freakin' Deal to have all the memory safe they could design into the compiler and language.

If even they had to add escape hatches despite the presences of powerful language primitives like types, traits, borrow-checking, maybe the people charged with making it all work with 80s compiler technology weren't the literal Antichrist for also having UB as Rust does.

For what it's worth, C and C++ are much different in terms of hazard, so when you bucket them together it makes me wonder how familiar you are with the actual risk of UB in practice.

Nowadays it generally stems from doing weird things.... but no one is making you do weird things, any more than people are making you use Rust's unsafe keyword.

Well yes, that's what UB means. It's a singularity, you run into it and there's no longer a specified requirement for the behavior that will follow.

Rust also has UB, btw, https://doc.rust-lang.org/reference/behavior-considered-unde..., so I don't know where it is that people have imagined this is something the C and C++ language designers went out of their way to foist upon you.

If you want to write code for a VAX, then you can use the K&R C compiler where it had defined outcomes for everything. If you want to write portable C code for modern CPUs then it's fair to ask what the C language standard is supposed to define for each of those CPUs and OSes and ABIs.

And a bunch of people were nice enough to do that for you and I, but because they are not deities, there are things that they had to leave out to make the language useful, so they did.