n2d4

What's the context here? When, where and for what did they recommend SVB?

(FWIW, it did end well, as going with a relatively large federally insured bank meant that no one lost any money during the crash)

50 crypto scams? Why do you link the same one thrice, then?

https://forum.effectivealtruism.org/posts/5mghcxCabxuaK4WTs/...

That's a very misleading way to say that Flock is a YC company [0]!

[0] https://www.ycombinator.com/companies/flock-safety

> Michael Seibel and Dalton Caldwell were publicly anti-Trump

Neither of these were "publicly anti-Trump" as much as Garry Tan has been.

Actually, where'd you even get that from? I cannot with my life imagine that Dalton would publicly post about politics. I've googled around a bit and found nothing either.

That doesn't pass the sniff test, many other pages on knowyourmeme correctly attribute memes to 4chan.

If you were right that would be easily verifiable. Do you have an example of a post dated before 2018? Maybe you're getting tricked by the fact that 2018 was 8 years ago?

I think I'm the opposite! The key is to ignore any language that sounds too determined and treat it as an opinion piece on what could happen. There's no way of knowing what will, but I find the theories very interesting.

If you're curious to play around with it, you can use Clancy [1] which intercepts the network traffic of AI agents. Quite useful for figuring out what's actually being sent to Anthropic.

[1] https://github.com/bazumo/clancy

This is a weird theory. Brex sent an email to all customers, alongside posting everywhere on social media. You are making your conclusions because they didn't put the announcement on their landing page?

Very much so. A better law would be conservative in both sending and accepting, as it turns out that if you are liberal in what you accept, senders will choose to disobey Postel's law and be liberal in what they send, too.

That paragraph could be the truth, or it could be a lie. Maybe Emacs really did make you more efficient, or you made it all up, I don't know. Best I can do is trust you.

If you don't trust me, I can't conclusively convince you that AI makes me more efficient, but if you want I'm happy to hop on a screen-share and elaborate in what ways it has boosted my workflow. I'm offering this because I'm also curious what your work looks like where AI cannot help at all.

E-mail address is on my profile!

This is extremely dismissive. Claude Code helps me make a majority of changes to our codebase now, particularly small ones, and is an insane efficiency boost. You may not have the same experience for one reason or another, but plenty of devs do, so "nothing happened" is absolutely wrong.

2024 was a lot of talk, a lot of "AI could hypothetically do this and that". 2025 was the year where it genuinely started to enter people's workflows. Not everything we've been told would happen has happened (I still make my own presentations and write my own emails) but coding agents certainly have!

Cross-shard transactions are only a tiny fraction of transactions — if the complexities of dealing with that is constrained to some transactions instead of all of them, you're saving yourself a lot of headaches.

Actually, I'd argue a lot of apps can do entirely without cross-shard transactions! (eg. sharding by B2B orgs)

That's right!

If you anticipate you will encounter the third type a lot, and you don't anticipate that you will need to shard either way, what I'm talking about here makes no sense for you.

Yes, but you could also flip it the other way around — make the business or customer your sharding key, and you'll only need to manage one schema!

I talk about these problems in the "How hard can sharding be?" section of the article — long story short, not all business requirements can be dealt with easily, but surprisingly many can if you choose a smart sharding key.

You can also still do optimistic concurrency across shards! That covers most of the remaining ones. Anything that requires anything more complex — sagas, 2PC, etc. — is relatively rare, and at scale, a traditional SQL OLTP will also struggle with those.

It's a different kind of complexity. Essentially, your app layer needs shift from:

    - transaction serializability
    - atomicity
    - deadlocks (generally locks)
    - occ (unless you do VERY long tx, like a user checkout flow)
    - retries
    - scale, infrastructure, parameter tuning

towards thinking about

    - separating data into shards
    - sharding keys
    - cross-shard transactions

which can be sometimes easier, sometimes harder. I think there are a surprising amount of problems where it's much easier to think about sharding than about race conditions!

> But with B2B, we have accounts ranging from 100 users per organization to 200k users per organization.

You'd be surprised at how much traffic a single core (or machine) can handle — 200k users is absolutely within reach. At some point you'll need even more granular sharding (eg. per user within organization), but at that point, you would need sharding anyways (no matter your DB).

The title should probably mention that this is for search results in the App Store, which already had ads.

Still an unfortunate development though.

What are some compiler flags that would compile the code such that an attacker could take advantage? And what would the attack be?

Or is this just a theoretical argument, "it is hypothetically possible to create a technically-spec-compliant Rust compiler that would compile this into dangerous machine code"? If so it should still be fixed of course, but if I'm patching my Linux kernel I'd rather know what the practical impact is.

I recommend you read Greg Koah-Hartman's thread instead of this article: https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM

    > Rust is is not a "silver bullet" that can solve all security problems, but it sure helps out a lot and will cut out huge swatches of Linux kernel vulnerabilities as it gets used more widely in our codebase.
    
    > That being said, we just assigned our first CVE for some Rust code in the kernel: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/ where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall.

    > Note the other 159 kernel CVEs issued today for fixes in the C portion of the codebase, so as always, everyone should be upgrading to newer kernels to remain secure overall.

Sure, but that's not really that interesting or controversial.

The more useful question is, how many CVEs were prevented because unsafe {} blocks receive more caution and scrutiny?

To be honest, I find Ryan Cavanaugh's argument against this quite convincing. It's weird to have something documented if you import the .ts file, but not if you import a .d.ts generated from it. If you want to show the value of the default argument of a function, you should probably just add it to the doc comment — not the type.

It hides the malware's trail, and disguises which keys were leaked, making rotation harder

That's not true.

    > Notable exceptions are Deepseek 3.2 and Opus 4.5 and GPT 3.5 Turbo.

And GPT-4o, GPT-4.1, and GPT-5. Almost every OpenAI release got cheaper on a per-input-token basis.

I would love to see the hallucinated comments of these! Some seem interesting — I wonder how HN suggests to prevent ad-injection in AR glasses?

Can't edit my comment anymore but Bun posted a pretty detailed explanation of their motivation here: https://bun.com/blog/bun-joins-anthropic

Sounds like "monetizing Bun is a distraction, so we're letting a deep-pocketed buyer finance Bun moving forward".

    > They didn't have to join, which means they got a solid valuation.

This isn't really true. It's more about who wanted them to join. Maybe it was Anthropic who really wanted to take over Bun/hire Jarred, or it was Jarred who got sick of Bun and wanted to work on AI.

I don't really know any details about this acquisition, and I assume it's the former, but acquihires are also done for other reasons than "it was the only way".

Here is dang's comment back when they banned Michael O' Church: https://news.ycombinator.com/item?id=10017538

The year was indeed 2015, and his political content would fit OP's description, but the reason for the ban was that he was repeatedly being a total asshole, not "YC is scared of anti-fascists".

> I'm assuming the user data would show that quite a lot of people would turn it off

You would be wrong — outside of the Hacker News bubble very few people mess with their default settings, in any app.

    > it would compromise your anonymity to say more

By saying he was part of these conversations, the people he talked to almost certainly already know who he is (if necessary, the fact he's undergoing through surgery definitely tells them). Not sharing the details about this sounds more like he doesn't want this individual to be rehabilitated. (Assuming this entire thing is not made up.)

You can agree with the goals of an initiative and still think it is poorly thought out.

OP is acting as if anyone criticizing this thing must clearly be opposed to their entire world view, accusing them of being paid shills. No. Maybe they just (rightfully) don't like Clippy, and don't want a movement they care about to turn into that.