The lack of vertical integration in the modern stack is surprising. We’ve spent 30 years treating the UNIX paradigm as the "end of history," while burying ourselves in layers that add zero mechanical value.
I initially thought the containerization movement of the early 2010s would be the first step toward redefining the OS—a way to finally slim things down. Instead, it just became a more efficient way to pack up the same baggage. We created a "reduction" in deployment complexity, but we haven't seen a continued effort to use those tools to actually change the paradigm.
I expected vertically integrated systems to become the norm by now—where building an executable would be an experience similar to containerization, but resulting in a lean, data-centric unikernel.
Instead, we are burning CAPEX on YAML sidecars in K8s clusters and N-tier abstractions that exist solely due to the large heterogeneity of the deployments that they never should have entered in the first place. We are spending more energy on the friction between layers than on the actual business of computation.
I was hoping for a return to sanity with the DBOS [1] research, looked like an attempt to rethink systems from first principles. But it seems that effort hasn't fully kicked off in the way the industry desperately needs.
After my old homelab laptop died, I decided to over-engineer its replacement.
A question for the homelabbers and infra folks here: Do you actually find value in people open-sourcing their personal infrastructure repositories?
All of my configurations are currently in a private repo because they feel too customized to my specific environment (domain names, specific storage tags, etc.) to be useful to anyone else. Have you ever genuinely learned from or reused someone else's opinionated personal configs?
Happy to open mine up if people find that kind of reference material helpful.
Also happy to answer any questions about the Turing Pi hardware or the Talos experience!
I wrote this post after giving a talk on AI to a non-technical audience. I found that the analogy of baking a cake without a recipe was a powerful way to build intuition for how ML models are trained and, more importantly, the common ways they can fail.
I hope this is a useful mental model, whether you're an expert trying to explain your work or a newcomer to the field.
I'm here to answer any questions.
I'm also curious: what are your favorite analogies for explaining complex technical topics?
The news feels bittersweet. With 10+ of experience in healthcare AI, I have seen enough shitty products to genuinely welcome strict regulation for critical sectors; however, this shift threatens to dilute the sense of urgency that was growing in the sector.
We recently built a platform specifically to navigate the complex intersection of MDR (Medical Device Regulation) and the AI Act, relying on the pressure of hard deadlines. By introducing flexible timelines linked to technical standards, the EU risks signaling that compliance is a secondary concern, potentially stalling the momentum... and at this point patient safety is my biggest concern, not our platform
This introduces chaos rather than relief. Companies do not need lower standards; they need clarity.
We can compete effectively against high standards as long as the rules are clear. EU AI Act was clear. This proposal substitutes the certainty of a high bar with the confusion of a sliding scale, which may hinder the industry more than it helps :/
Macron’s focus should be on making sure that France’s existing AI successes like Mistral, Owkin, and Bioptimus have the right business environment for scaling and internationalizing, closing big initiatives with big corps/institutions rather than launching yet another public-sector initiative. These startups already demonstrate France’s AI potential, but they need strategic support to compete globally. Instead of reinventing the wheel with new government programs, why not double down on making these companies world leaders?
FondationDB is such an incredible resource, but it’s so hard to access for the general public. It’s no wonder so few people know about it. I’ve always thought that if there were easier ways to interact with it, or some dev-friendly layers built on top (or public) it would become way more popular. it has shown how well it scales with Apple and snowflake, but is not an obvious choice for non-internet scale applications.
If you don't know about FDB; there's an amazing video about how they test it that really got me into learning more:
Yeah, this is the bit for me. We have almost no good OSS layers for folks to "plug and play".
Its a bit of a vicious circle - because there is low exposure, no one is building those layers. Because no one is building the layers, there is no exposure.
All my kudos for the OrioleDB team, they have been working for years with the Postgres core devs to get the extensibility patches they need for their storage extensions merged back.
It’s not just about building their extension but actually making Postgres better for everyone. I would have loved that big corps would have taken this approach, as it opens the doors to others to add features for different use cases and making postgres more of a DBMS framework
> I would have loved that big corps would have taken this approach, as it opens the doors to others to add features for different use cases
EDB and Cybertech definitely made a great start with Zheap[0] although the initiative stalled for whatever reason
Hopefully the community can support this effort to improve the Table AM API - it would be beneficial even beyond oriole. As you point out, a Pluggable Storage system in Postgres would open up a few new use cases
I initially thought the containerization movement of the early 2010s would be the first step toward redefining the OS—a way to finally slim things down. Instead, it just became a more efficient way to pack up the same baggage. We created a "reduction" in deployment complexity, but we haven't seen a continued effort to use those tools to actually change the paradigm.
I expected vertically integrated systems to become the norm by now—where building an executable would be an experience similar to containerization, but resulting in a lean, data-centric unikernel.
Instead, we are burning CAPEX on YAML sidecars in K8s clusters and N-tier abstractions that exist solely due to the large heterogeneity of the deployments that they never should have entered in the first place. We are spending more energy on the friction between layers than on the actual business of computation.
I was hoping for a return to sanity with the DBOS [1] research, looked like an attempt to rethink systems from first principles. But it seems that effort hasn't fully kicked off in the way the industry desperately needs.
[1]: https://dsail.csail.mit.edu/index.php/dbos/