Building an HTML-first site doubled our users overnight

Hey gang, you may remember me from such books as _The Lean Startup_ and _The Startup Way_.It&#x27;s been fifteen years since I wrote The Lean Startup, and in that time I&#x27;ve seen some things. In both big companies and tiny startups, NGOs and governments, in almost every industry you can name.I&#x27;ve helped a lot of people create a lot of amazing companies, but I&#x27;ve also seen so many ways this can go wrong. There&#x27;s a darkness in our industry that we often don&#x27;t talk about.I kept watching good companies drift away from the missions they were founded on. Not because anyone woke up one day and decided to be evil, but because the structure they were built on slowly pulled them there. I call that pull &quot;financial gravity.&quot;We&#x27;ve all experienced watching a company we love or admire be warped and broken beyond recognition; until it&#x27;s a husk of its former self, or worse. I wanted to understand why. And I wanted to know what all of us can do to stop that from happening.My new book _Incorruptible_ is my attempt to explain the invisible forces that shape organizations, and how a handful of companies (like Costco, Patagonia, and Novo Nordisk) have successfully been structured to resist gravity and thrive for decades -- or even centuries.Along the way, I founded the Long-Term Stock Exchange, co-founded an AI R&amp;D lab called Answer.AI with Jeremy Howard, and helped a number of notable companies with their governance (yes, including Anthropic).I won&#x27;t pretend I have this all figured out, but I&#x27;ve probably spent more time than is healthy on the &quot;why do good companies go bad&quot; question. Ask me anything!

I'm Eric Ries, author of "The Lean Startup" and new book "Incorruptible" – AMA

PgDog is funded and coming to a database near you

Textbooks Should Be Free

GitHub Authentication issues related to API requests

Apache Burr: Build reliable AI agents and applications

Postgres by Example

Mercedes‑Benz starts large‑scale production of electric axial flux motor

macOS Container Machines

All 9,300 Japanese train station, animated by the year it opened (1872–2026)

Buy a train, bridge or tracks from the Swiss Railway

DiffusionGemma: 4x Faster Text Generation

Hey HN, it’s been just over a year since we launched HelixDB (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43975423">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43975423</a>), a project a friend and I started in college. It’s an OLTP graph database built on object-storage, with native vector search and full-text search (FTS).Why graph, vector and FTS? Graph databases provide a natural cognitive model for data, vectors allow for a semantic understanding of the entities and relationships in the graph, and FTS provides more specific filtering. Many AI-driven applications attempt to combine all of these functionalities by stitching together multiple disconnected systems, but even then there’s no native way to perform joins or queries that span all systems. You still need to handle this logic at the application level.Helix started as a graph DB, but we moved to a hybrid graph&#x2F;vector approach after attempting to build an AI memory system, which led us down the GraphRAG and HybridRAG rabbit hole, where we would need separate graph and vector databases.We knew scalability would be a challenge at each stage of our product&#x27;s development, however our initial focus this past year was to prove out the product through local deployments and was only meant to be run on a single node. Scaling graph DBs remained a difficult and expensive problem we’d have to solve later.
Some common ways other graph DBs solve scaling is by duplicating entire datasets across distributed machines (extremely expensive per node), or by sharding the data.Sharding databases is effective and affordable, however, graph data doesn’t have explicit partitions like relational databases do. For example, sharding a relational DB involves splitting up tables. When it comes to graph DBs, the edges can span across any of the partitions, and hopping across multiple machines when traversing nodes is ineffective and computationally expensive.Replicating graph DBs for high availability and better throughput drastically increases the operational cost of the db and still has a limit of how big you can vertically scale. The workload that we’re used for requires storing a huge amount of data for agents, where only a subset of that data is ever needed at any one time. So rather than having the whole thing in memory, we can store it all in object-storage and get the bits we need when they’re needed.Agents benefit from better context, which is achieved from more and better data (more relationships etc). By using S3 as the persistence&#x2F;data layer there is no limit to how big the graph can be or how many relationships you can have, and we can scale to serve throughput and requests by horizontally spinning up nodes and caching relevant subsets of the graph on each node. This way, you get extremely low latency for “hot” data and a p99 of ~100ms for writes and ~50ms for reads from cold storage (S3). Plus you get the benefit of dirt cheap storage.Workloads that HelixDB is currently supporting:
- Huge amounts of data (TBs) from which the agents need to search and traverse over
- Offering affordable graph storage for companies where cost of graph data is a bottleneck
- Consolidating multiple databases, enabling AI agents to have autonomy over companies, helping them become more autonomous.
- AI memory
- Company brainsWe’re currently working on our own generalised AI memory layer which will use HelixDB under the hood and be completely open-source. Also, we’re finishing up on pre-filtering for vector search which will allow you to pre-filter based on relationships in the graph, metadata, and sub-graphs. And lastly, GA cloud will be available in the coming weeks.If you want to run Helix locally (either on-disk or in-memory), you can find more info on our github (<a href="https:&#x2F;&#x2F;github.com&#x2F;HelixDB&#x2F;helix-db" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;HelixDB&#x2F;helix-db</a>) or via our docs (<a href="https:&#x2F;&#x2F;docs.helix-db.com&#x2F;database&#x2F;local-development">https:&#x2F;&#x2F;docs.helix-db.com&#x2F;database&#x2F;local-development</a>). If you’re interested in getting started with our distributed cloud, please email us founders@helix-db.com.Many thanks! Comments and feedback welcome!

Show HN: HelixDB – A graph database built on object storage

Who Runs Your Rust Future? Hands-On Intro to Async Rust

'They take you out of life, out of time': a journey into Spain's cave paintings

A €0.01 bank transfer could compromise a banking AI agent

Smudging the game disc to make speedrunning 'SpongeBob' faster

The Last Evolution, by John W Campbell Jr. (1932)

Reviving Papers with Code

The large companies I’ve worked at (including FAANG) seemed to thrive on kudos via performative actions. Like the majority of the team is doing useless stuff that management thinks is impressive while the couple all stars get the team closer to the goal.Meanwhile, a lot of managers calendars are purely just 1:1s with devs on the team which clearly has very little value add to the team.Anyone else notice this? Not sure if there’s a word for it, but it’s somewhat demoralising working with a bunch of corporate office workers cosplaying as engineers

Ask HN: Are most corporate SWE jobs performative?

&gt; For Fable 5, Mythos 5, and future models on Bedrock with similar or higher capability levels, Anthropic will require 30-day retention for all traffic on Mythos-class models. Retaining data for a limited period allows Anthropic to detect patterns of misuse that are not visible from a single exchange. Once you opt into data retention, your data will leave AWS’s data and security boundary.From the announcement here: <a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;blogs&#x2F;aws&#x2F;anthropic-claude-fable-5-on-aws-mythos-class-capabilities-with-built-in-safeguards-now-available&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;blogs&#x2F;aws&#x2F;anthropic-claude-fable-5-on...</a>&gt; After 30 days, the data is deleted automatically, except in the rare cases where it&#x27;s part of a safety investigation or we&#x27;re legally required to keep it.From: <a href="https:&#x2F;&#x2F;support.claude.com&#x2F;en&#x2F;articles&#x2F;15425996-data-retention-practices-for-mythos-class-models" rel="nofollow">https:&#x2F;&#x2F;support.claude.com&#x2F;en&#x2F;articles&#x2F;15425996-data-retenti...</a>

AWS Bedrock to require sharing data with Anthropic for Mythos and future models

The iPad was on Tailscale: a WebRTC debugging story

System Card [pdf]: <a href="https:&#x2F;&#x2F;www-cdn.anthropic.com&#x2F;d00db56fa754a1b115b6dd7cb2e3c342ee809620.pdf" rel="nofollow">https:&#x2F;&#x2F;www-cdn.anthropic.com&#x2F;d00db56fa754a1b115b6dd7cb2e3c3...</a>

Claude Fable 5

Upcoming breaking changes for npm v12

Hi HN,Over the last few days I&#x27;ve been building USTPS (UDP Speedy Transmission Protocol Secure), an experimental encrypted transport protocol built on top of UDP.The primary goal of USTPS is low-latency video streaming. A server can take a video source and expose it through a USTPS endpoint, while Linux and Android (Termux) clients receive the stream and expose it locally to applications such as VLC, mpv, and FFmpeg.Although streaming is the main focus, USTPS is not limited to media delivery. It can also be used for other reliable encrypted UDP-based applications, which is why I built USSH on top of it.Some of the main design differences compared to TCP-based transports are:- USTPS is reliable but unordered.
- If packet N is lost, later packets can still be accepted and processed immediately.
- Missing packets are recovered through selective retransmission.
- Ordering is handled by the application layer when needed.This means the transport layer itself does not introduce Head-of-Line Blocking. The tradeoff is that applications which require ordering must implement reordering themselves. I consider this a reasonable tradeoff because it avoids forcing every application to pay the cost of transport-level ordering.For media player compatibility, the default USTPS client creates a local TCP endpoint at 127.0.0.1:1238.The client maintains a small reordering buffer (350 ms by default) to give retransmissions time to arrive before forwarding data to the local TCP stream. This allows existing software such as VLC, mpv, and FFmpeg to work without modification.USTPS currently provides:- Reliable delivery using ACKs and selective retransmissions
- X25519 key exchange
- AEAD encryption (AES-GCM and ChaCha20-Poly1305)
- Optional unordered live output mode
- Stream position metadata
- Multi-client support
- Local TCP compatibility output
- No congestion control (currently intentional)While developing USTPS, I also built USSH, an SSH-like remote shell running entirely over USTPS.USSH uses the same unordered transport underneath, but the client reconstructs and orders terminal data before presenting it to the user. This prevents terminal corruption while still allowing the transport layer itself to remain unordered.USSH includes:- Interactive terminal sessions
- PTY support
- Password authentication
- Host key verification (TOFU)
- End-to-end encrypted communication through USTPSI&#x27;m currently using USSH from my Android phone through Termux to manage my VPS.The project is very young (less than a week old) and is primarily experimental and educational. I&#x27;m interested in feedback from people working on transport protocols, streaming systems, SSH implementations, QUIC, SCTP, and networking software.USTP-Secure:
<a href="https:&#x2F;&#x2F;github.com&#x2F;x1colegal&#x2F;USTP-Secure" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;x1colegal&#x2F;USTP-Secure</a>USSH:
<a href="https:&#x2F;&#x2F;github.com&#x2F;x1colegal&#x2F;USSH" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;x1colegal&#x2F;USSH</a>Internet-Drafts:USTPS Draft:
<a href="https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-x1co-ustps&#x2F;" rel="nofollow">https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-x1co-ustps&#x2F;</a>USSH Draft:
<a href="https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-x1co-ussh&#x2F;" rel="nofollow">https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-x1co-ussh&#x2F;</a>Questions, criticism, and suggestions are welcome.