Hit me up if you wanna talk about authentication, devtools, databases, or anything else.
n2d4xc (at) gmail.com
Other stuff:
- blog.konsti.xyz
- @konstiwohlwend (Twitter)
- @konsti.xyz (Bluesky)
- 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:
towards thinking about- transaction serializability - atomicity - deadlocks (generally locks) - occ (unless you do VERY long tx, like a user checkout flow) - retries - scale, infrastructure, parameter tuning
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!- separating data into shards - sharding keys - cross-shard transactions> 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.
And GPT-4o, GPT-4.1, and GPT-5. Almost every OpenAI release got cheaper on a per-input-token basis.> Notable exceptions are Deepseek 3.2 and Opus 4.5 and GPT 3.5 Turbo. - 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".
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.> They didn't have to join, which means they got a solid valuation.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://www.hackerneue.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.
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.)> it would compromise your anonymity to say more
Actually, I'd argue a lot of apps can do entirely without cross-shard transactions! (eg. sharding by B2B orgs)