AFAICT this now gives them default permission to train an LLM on your code (as Posthog telemetry data is inextricably tied to your code) use it, and even sell it if they wanted to (as it's not your data anymore, it's their model). Yikes.

Pedantic answer: Unless the light source has different colors on different sides

Complex answer: Kind of. Even a linear color fade (from reality) can turn non-linear (and therefore induce color effects) when pushed through a color grading pipeline. So if you count e.g. film emulation as a "physical effect", then yes.

As I read it, the article is simply trying to help people understand what kind of work is valuable to a company and therefore what they should focus on to make themselves valuable. I presume that making yourself valuable pays dividends, including promotions! Somehow the idea of going to work and not trying your best because “you’re not getting paid … for that” just feels so cynical and divorced from how I’ve seen successful people grow and make big bucks in tech.

(And this is all a bit separate, of course, than the debate about whether staying at a company or job hopping is better for career trajectory.)

https://www.youtube.com/watch?v=eSFt38IS0QU

- $50 - Something rug-shaped exists

- $100 - Durability

- $200 - Materials

- $500 - Comfort and design

- $1000 - Basic craftsmanship

- $2000 - Refinement of craft

- $5000 - Artistry & identity

- $10000 - Tradition

- $20000 - Mastery

- $50000 - Rarity/historical importance

- $100000+ - ?

Because most people don't cross-shop $20k rugs and $200 rugs, most people are focused on one or two aspects around their personal budget. The essayist mentioned being amazing by the craftsmanship and artistry (see scale above). A broke college student might just want something that holds up in their dorm room and see what materials it's made out of and comfort as meaningless and abstract. And a billionaire shopping for a rug for their office might take everything other than rarity/historical importance as a given and just be thinking about that.

I think there is a large cognitive bias to consider everything you can easily afford "tangible and important improvements" and everything you can't as "abstract"!

So, it stayed with the world because it went semi viral in some tiny circles. But it didn’t stay with me because I personally learned little from it.

The thing that stays with me is all the things I learned spending years trying to implement an API you can describe in ~30 seconds really well. It’s a rare opportunity to be able to go so deep on a problem in a career.

I don't know the details know, but it was definitely configurable when I wrote it :) I remember arguing for setting it to a default of 30/60 seconds we decided against as that would have impacted throughput at our default RAM budget. I thought might have been a good tradeoff to get people going, thinking they could tune it down (or up the RAM) if they needed to scale up perf later.

> Another big problem I found with modeling real apps was the five second transaction timeout. This is not, as you might expect, a configurable value. It's hard-coded into the servers and clients. This turns into a hugely awkward limitation and routinely wrecks your application logic and forces you to implement very tricky concurrency algorithms inside your app, just to do basic tasks. For example, computing most reports over a large dataset does not work with FoundationDB because you can't get a consistent snapshot for more than five seconds!

I'm pretty sure that the 5-second transaction timeout is configurable with a knob. You just need enough RAM to hold the key-range information for the transaction timeout period. Basically: throughput * transaction_time_limit <= RAM, since FDB enforces that isolation reconciliation runs in memory.

But, the other reason that 5 seconds is the default is that e.g. 1 hour read/write transactions don't really make sense in the optimistic concurrency world. This is the downside of optimistic concurrency. The upside is that your system never gets blocked by bad-behaved long-running transactions, which is a serious issue in real production systems.

Finally, I think that the current "Redwood" storage engine does allow long-lived read transactions, even though the original engine backing FDB didn't.

In that second life, the vast majority of the powerful databases around the industry built on FoundationDB have been built by companies making their own custom layers that are not public. This release is cool because it's a rare case that a company that has built a non-trivial layer on top of FDB is letting that source code be seen.

The group to which the FoundationDB storage engine itself appeals is fairly narrow--you have to want to go deep enough to build your own database/datastore, but not so deep to want to start from scratch. But, for this group, there is still nothing like FoundationDB in the industry--a distributed ACID KV store of extreme performance and robustness. So, yes, it's still the hotness in that sense. (As others have mentioned, see e.g. Deepseek's recent reveal of their 3FS distributed filesystem which relies on FDB.)