HN user

soamv

743 karma

Systems/Infrastructure software at various layers.

Previous work: cohesion.dev, fission.io, filesystems at VMware.

Generally: interested in the systems of change in software and people.

Specifically: working on developer tools at Stripe.

contact@soam.dev; no sales pitches please but I'm always interested in grabbing a coffee and talking about developer tools, infrastructure, or startups!

Posts16
Comments133
View on HN
Corrosion 9 months ago

New nullable columns are kryptonite to large Corrosion tables: cr-sqlite needs to backfill values for every row in the table

Is this a typo? Why does it backfill values for a nullable column?

This is a great point! But there's an important tradeoff here about human engineering time versus the "learning in the open" benefits; a PR discarded privately consumes no human engineering time, a fact that the humans involved might appreciate. How do you balance that tradeoff? Is there such a thing as a diff that's "too bad" to iterate on with a human?

This leaves me with more questions than answers, how did these three companies come up with the idea of using that logo? Did they just independently arrive at same design (seems unlikely)? And how did the trademark registration process go for the second and third companies that registered it?

It might have, I remember attending a talk by Peter Chen when I was at VMware around that time, and I know there was some kind of collaboration. (I wasn't involved in record-replay at VMware, but I was interested in it due to some ancient work I did with userspace record-replay debugging, https://lizard.sf.net).

rr is fantastic work, mad props! And the multiprocess stuff in pernosco looks super neat.

Well, it may be legal to create such a painting, but (depending on details) it may be a derivative work, in which case the original work's copyright still applies.

In other words, in your example, the painter is not necessarily free to distribute their painting while ignoring the original image's copyright.

They are privately operated since the 80s, but the vast majority of their initial development was government funded.

As far as I understand the privatized companies are monopolies-- these companies were formed from the JNR by geographic area served (hence "JR East", "JR West" etc.)

The bloomberg story is really light on details for why and how the privatization occurred; for a much more in-depth view, see S.Y. Lee's Substack, for example this post: https://seungylee14.substack.com/p/the-death-and-privatizati...

(An interesting fact is that most of JNR's debt at the time was retained by the government while the assets and revenue were privatized)

help me determine what % of the company I'd be getting in this stage?

Just ask them what % of the company you'd be getting at this stage. They should absolutely tell you that; that's the high order bit of equity compensation negotiations. If they don't tell you up front they're wasting your time.

Early-stage startups need mutually trusting relationships in the team. If they don't trust you enough to tell you, or you don't trust them enough to believe their answer, equity comp numbers are not the issue here.

For me, the context and reasoning behind why the recipe does what it does is much more important than the recipe itself; that makes such apps counterproductive.

I can imagine that "just the recipe" is useful for very novice cooks, but most of the time it's much better to learn the patterns and techniques than to follow the precise recipe. You'll be much more prepared that way when things don't go to plan, or when you're missing a few ingredients.

And this may be unpopular here, but I often enjoy the "life story" too: for me, many of the joys of cooking are in the connections made to other people. And if the recipe writer wants to build a connection with the cook because they poured so much effort into the recipe, I'm open to that -- and whatever it may bring to the actual cooking.

(Maybe I should make a "just the code" browser extension for Github that deletes README files ;) )

There is no clear definition with universal agreement. It's a hype-y term applied with... varying levels of rigor.

However, roughly speaking, "serverless" rolls together 3 features:

1. Fine grained pay-per-use (e.g. pay for a query by the number of rows scanned)

2. The pricing dial goes down to zero when usage is small enough.

3. You generally don't control VM/instance-level scaling but something closer to the abstraction level of the product being claimed as "serverless". For example in planetscale you get no control over how many mysql instances actually run your queries. This is great for reducing operational complexity but not so great for controlling performance. Performance tends to be quite opaque -- for example there's nothing I can find in Planetscale's docs about latency and throughput. The operational benefits are real, though. It's a tradeoff.