nubskr

Won't something like scyllaDB be a better choice for such workloads ? as long as you're fine with eventual consistency ofc

Seems like sometimes the best tech stack is the one that refuses to die :))

I've been using Claude Code for my research notes and had the same realization, it's less about perfecting prompts and more about building tools so it can surprise you. The moment I stopped treating it like a function and started treating it like a coworker who reads at 1000 wpm, everything clicked

Mandiant releases rainbow tables for a 25 year old broken protocol because enterprises still won't disable it. It seems like sometimes the best security tool is just making the risk impossible to ignore.

That's actually the state of autonomous coding in 2026, scale the output, skip the verification.

Until I saw this, I thought my weirdest infrastructure decision was using NFS for swap. Now I'm wondering if I can mount my browser tabs over UDP.

Finding out "computer" was a job title because precise calculation was so hard to find makes me feel less bad about needing a calculator for basic arithmetic.

so they already queried the DB to know your link is broken, but chooses not to spend more compute telling you why?

It's fully how Max Brod saved Kafka's work by ignoring his dying wish and prague repaid him by turning Kafka into a hummus cafe.

Temporal being immutable alone is worth whatever migration pain we're about to endure.

The 'break it and it's gone' constraint seems weirdly empowering compared to cloud magic :/

Spent the last month building a FUSE mount and now I can't stop thinking about what else I can filesystem.

So negative temperature makes LLMs output their "forbidden words" i.e. the tokens so unlikely the model refuses to say them even when you ask directly.

Another day, another MCP server. Wake me up when we stop needing a new protocol for every AI tool to talk to every other AI tool.

Helping my mom recover from OneDrive's "cleanup" was the closest I've come to negotiating with terrorists.

Turns out the best GPU optimization is just being too scared of graphics drivers to do the fancy stuff, 10-15x faster and you can actually debug it.

I keep telling myself I'm using the sea approach but my git history says hammer and chisel

most of the financial systems are just as hackable as computer systems, but most "security" startups just build compliance checkboxes and culturally appropriate hacker ethos for VC money.

The holy trinity of modern hardware: update servers, firmware locks, and abandoned devkits

'Most code I don't read.' The 2026 senior dev: a product manager with commit access and a really fast intern.

Skip the dry dock, just chainsaw the river until it freezes deep enough, peak yakutsk engineering

On Demand GPUs got cheaper because Azure exists. Capacity Blocks got 15% pricier because your migration plan doesn't

Damn, Regrets already forming.

s3 charges per 1,000 Update requests, not sure how it's sustainable to do it every 250ms tbh, especially in multi tenant mode where you can have thousands of 'active' blocks being written to

In the current benchmarks, I only have Kafka and rocksdb wal, will surely try to add redpanda there as well, curious how walrus would hold up against seastar based systems.

Hi, the creator here, I think its a good idea to have S3 backed storage mode, its kinda tricky to do it for the 'active' block which we are currently writing to, but totally doable for historical data.

Also about the kafka API, I tried to implement that earlier, I had a sort of `translation` layer for that earlier, but it gets pretty complicated to maintain that because kafka is offset based, while walrus is message based.

Hey HN! recently I've been working on Walrus, a distributed message streaming engine that combines high-performance log storage with Raft-based coordination.

What makes it different:

- Segment-based sharding with automatic load balancing – Topics split into ~1M entry segments, leadership rotates round-robin on rollover. No manual partition management. - Lease-based write fencing – Only the segment leader can write. Leases sync from Raft metadata every 100ms, preventing split-brain without coordination on the data path. - Sealed segment reads – Old segments stay on the original leader after rollover. No data movement, reads scale with replicas. - Simple TCP protocol – Connect to any node, auto-forwarding to the right leader. Commands are just PUT topic payload and GET topic.

Performance: The underlying storage engine hits ~1.2M writes/sec (unsynced) and ~5K writes/sec (fsynced), competitive with Kafka and faster than RocksDB in benchmarks.

Correctness: Includes a TLA+ spec verified with TLC covering write fencing, rollover mechanics, and cursor advancement.

The repo has both the distributed system (distributed-walrus/) and the standalone storage engine library (walrus-rust on crates.io).

Would love feedback on the architecture, especially around the lease synchronization approach and sealed segment design!

ah, nice catch

They mostly play nicely together because they operate at different layers. Quinn's flow control handles transport level backpressure (receiver can't consume bytes fast enough), which naturally surfaces to OpenRaft as slower RPC responses. OpenRaft then handles consensus level backpressure by tracking replication progress and adjusting accordingly (e.g., switching to snapshots for lagging peers), it just works. The main benefit is that QUIC's built in flow control means I didn't need manual buffering logic that you'd typically implement over raw TCP.

I recently open sourced Octopii, A batteries-included framework for building distributed systems, it bundles everything you need to build distributed systems without hunting for individual components.