p-o

>For many years we had to rely on our own internally developed fork of FFmpeg to provide features that have only recently been added to FFmpeg

I really wonder if they couldn't have run the fork as an open source project. They present their options as binary when it fact they had many different options from the get go. They could have run the fork in an open-source fashion for developers of FFmpeg to see what their work was and be able to understand what the features they were working on was.

Keeping everything close source and then contributing back X amount of years later feels a little bit disingenuous.

Yes, I think you're right that it is not the end of the road for LLM and the application of LLM might be adopted over time across a variety of industries.

I guess what I failed to convey in my original comment was that, like the Internet 20 years ago, the current advancement made by AI might stall at a foundational level, while the landscape evolves.

Essentially, I believe what you're saying is really close in spirit to what I'm saying.

I think the brunt of the disruption regarding AI is already behind us for LLMs at least. It's possible we'll see improvements over the following months/years, but government will inevitably start to catchup to the level of disinformation and confusion that AI has brought to this world.

Laws & regulations that needs to be created to reign in AI will undoubtedly increase the opportunity cost of training LLMs.

For some, it might be similar to the early 2000s, but I think it's just a healthy rebalance of what AI is, and how the society needs to implement this new, hardly controllable, paradigm. With this perspective, OpenAI has a lot to lose as it hasn't been able to create a moat for itself compared to, let's say, Anthropic.

Interesting adjacent theory is how much are datacenters becoming military target to strike as part of disrupting initial defenses. It doesn't seem it was the case in this instance, but I could see this becoming a more important target in future.

Seems like it should be somewhat easier to bomb 50 datacenters than it would be to hack and disrupt 1000s of different services.

Again, this is just me thinking out loud on a tangent and this doesn't have much to do with this story, but I felt it was an interesting thought to share nonetheless.

The messaging is not normal, the intent is absolutely abhorrent. With every passing week, the rhetoric coming from him gets more violent: I'm worried.

Maybe AI is useful to you, but the US economy is currently buoyed by promises of AI replacing the workforce across the board.

Most of Mag-7 are planning to spend over 500B on capex this year alone on building out datacenters for AI pipelines that have yet to prove that it can generate a sustainable profit. Yes, AI is useful in some environments, but the current pricing is heavily subsidized. So my point stand, the hype is not warranted.

By the looks of it, 2026 might be the year where reality and fiction will finally collide with AI and we'll be able to see if all the hype was warranted.

But like all the previous hype, most of the people that were the loudest won't say they were wrong, and they'll move to the next thing, pretending like they never were the one that portrayed AI as the holy Graal.

Hashing is a part of encryption, maybe you are the one who needs to shore up on the topic?

What makes this move even more incredulous is that none of the two market they want to move towards are proven markets:

- Waymo is generating less than 150m in 2025.

- Consumer robotics is an absolute unknown.

How can the transition be rationally justified? Let alone the valuation.

There might be a subset of people, such as yourself, that looks for CUDA as a hard requirements when buying a GPU. But I think it's fair to say that Vulkan/Spir-V has a _lot_ of investment and momentum currently outside of the US AI bubble.

Valve is spending a lot of resources and AFAIK so are all the AI companies in the asian market.

There are plenty of people who wants an open-source alternative that breaks the monopoly that Nvidia has over CUDA.

I know you are making stuff up as I own a Tesla and live on the East coast and FSD is nowhere close to what you are describing. You can barely use FSD 4 months out of the year.

Unrelated to your friends, but a big part of learning is to do tedious tasks. Maybe once you master a topic LLMs can be better, but for many folks out there, using LLMs as a shortcut can impede learning.

API Keys are usually secrets and as such, if I wanted to commit those files to git, the API token would not leak to my repository.

That's really neat. I also had a similar need to dynamically manage DNS Record and decided to create a Kubernetes operator instead to manage it (https://github.com/pier-oliviert/phonebook).

I do like your approach, it's really refreshing. I'd probably want to split the API keys from the rest of the config files.

Great work!

How much I would love to be able to use this. Every few years, I try to replace my Macbook with a different laptop and linux. But the "finish" that the Apple products have is unmatched.

Specially the keyboard/trackpad support. It's always been underwhelming with Linux. I know this is a subjective take and it's unrelated to Hyprland.

I hope that my next laptop can finally be the final step off to the Linux laptop, because I would love to use Hyprland.

Decided after all these years to start to create open source libraries around things I've worked with in the past.

As worked a lot with Kubernetes in the past, I started with creating a Kubernetes Operator alternative to external-dns I call Phonebook: https://github.com/pier-oliviert/phonebook

It lets you control DNS record like you would any other native resources in Kubernetes through CRDs. Open-sourced it last week and there's already a bunch of features that are planned for the operator"

  - cert-manager's support for DNS-01 challenges
  - More support for other providers
  - Increase support for each provider that already exists
  - etc.

Check it out!

I think the Operator pattern will grow to become exactly what you describe. We're still at the early stage of that, but I can see that a group of operators could become a "distribution", in your example.

Congratulations on shipping! I like how opinionated Kardinal is, which means it should work nicely for anyone who shares the same kind of infras vision as you.

It's also such an interesting moment for you folks to show up on HN, I just shipped the first preview version of my Kubernetes operator(https://github.com/pier-oliviert/sequencer) that manages ephemeral environments. I can see some things that are similar with both our options as well as some things that are quite different.

Maybe if I had one question is: What made you go for Istio as the main network mesh?

Good luck with the launch!

It's always so enlightening to have articles like this one shed light on how companies at scale operate. It goes without saying that many of the problems Stripe faced with their monorepo isn't application to smaller businesses, but there are still bits and pieces that are applicable to many of us.

I've been working on an ephemeral/preview environment operator for Kubernetes(https://github.com/pier-oliviert/sequencer) and as I could agree to a lot of things OP said.

I think dev boxes is really the way to go, specially with all the components that makes an application nowadays. But the latency/synchronization issue is a hard topic and it's full of tradeoff.

A developer's laptop always ends up being a bespoke environment (yes, Nix/Docker can help with that), and so, there's always a confidence boost when you get your changes up on a standalone environment. It gives you the proof that "hey things are working like I expected them to".

That's great to see this show up today, I'm actually their wildcard certificate to build a DNS01 Challenge that connects cert-manager(ACME) and external-dns to create a fully open source "ephemeral environments" infrastructure on top of Kubernetes (https://github.com/pier-oliviert/sequencer).

It's crazy to think that not too long ago, these certificates would cost a small fortune. I'm really grateful to anyone working on making this available for the world to use.

I like your take on this. I think K8s offers a _lot_ and it has a bad reputation because of its early days. Kubernetes has room to improve, like everything else, but the API now are becoming a lot easier to work with and the Custom Resources allows folks to extend Kubernetes.

I still think that projects like this one come from necessity. Folks want to have an alternative for vendor lock-in.

I'm building something like that too (https://github.com/pier-oliviert/sequencer) for Kubernetes, and it's also out of necessity.

Vercel, Heroku and others have a lot of helpful tools that are empower developers, and I think people want to have those without being locked-in.

It goes without saying that I'm totally bias :)

It's fair that you had a different experience than I had. However, your experience seems to be very close to what I was describing. Cost got prohibitive (splunk), and you chose a different avenue. It's totally acceptable to do that, but your experience doesn't reflect mine, and I don't think I'm the exception.

I've used both grafana+metrics and logs to different degrees. I've enjoyed using both, but any system I work on starts with logs and gradually add metrics as needed, it feels like a natural evolution to me, and I've worked at different scale, like you.

I would say from my experience, for _application logs_, it's the exact opposite. When you deal with a few GB/day of data, you want to have logs, and metrics can be derived from those logs.

Logs are expensive compared to metrics, but they convey a lot more information about the state of your system. You want to move towards metrics over time only one hotspot at a time to reduce cost while keeping observability of your overall system.

I'll take logs over metrics any day of the week, when cost isn't prohibitive.

I never thought of that problem this way, but it sounds very cool. I imagine a sort of conversation between the LLM and the author.

- LLM: Did you mean to change A to B?

- Author: Yes, but [more nuanced information]

- LLM: Ah ok, here's the documentation updated: [Doc]

I really love this idea in theory, and I believe that for some system, specially mature ones, it may work well. I see good documentation as a super power; it empowers readers and motivate people to understand more about the system without being caught in the weeds of reading the source.

The source has baggages, and the intent of every single function calls is not always evident. Writing documentation up-front can help direct the source, but this is a tug-of-war environment. Each affect the other in its own ways.

And for that reason, documentation driven development can be a real drag. You start writing documentation with the best intentions, everything works great for this first release. But 2 months down the road you need to modify something and it has a ripple effect on many of the things you documented. It's a non-negligible cost.

I've been working on this open-source tool(https://github.com/pier-oliviert/sequencer) and I've spent a lot of time on the documentation. And what I described above happened. I wanted to make a not-too-big change, and it required me to rewrite 30% of the documentation. I still love the documentation aspect of it, but it definitively has a higher cost than tests, in my experience.

Aren't you jumping the gun a little bit? While it's a valid question, it's very premature.

First time I read about piku. I have no idea why, but the feeling of `git push` to initiate a deployment like piku does always felt magical to me. There's nothing simpler than that.

This is timely for me as well as I just open sourced (yesterday!) a project that is in the same space, but for Kubernetes (https://github.com/pier-oliviert/sequencer).

All of this to say, congrats! It looks great.

My own experience has definitively been frustrating at times. I think the main issue is the lack of consistency and breakage between the different libraries/languages. Even minor version could cause issues when trying to create gRPC message definitions for different languages.

The documentation was also lacking when it came to arguments for each of the libraries.

I vaguely remembered wanted to change a small piece of a message and it took me a whole day of spelunking to figure out how to do it, browsing C++, Go codebases.

Take this with a grain of salt, this was a few years ago and things might have changed.

I like to think that most people who are upset at Kubernetes don't hate on all of it. I think the configuration aspect (YAML) and the very high level of abstraction is what get people lost and as a result they get frustrated by it. I've certainly fall in that category while trying to learn how to operate multiple clusters using different topologies and cloud providers.

But from an operational standpoint, when things are working, it usually behaves very well until you hit some rough edge cases (upgrades were much harder to achieve a couple of years back). But rough edges exist everywhere, and when I get to a point where K8s hits a problem, I would think that it would be much worse if I wasn't using it.

These kind of facts always blow my mind. For instance, the Sun orbits the milky way once every 212m years.

That means that if the sun existed from the big bang to now, it would have only done ~63 complete revolutions around Sagittarius A*. If you account for the Milky Way's creation, that number gets even lower. I'm no expert, so maybe this makes sense to someone who knows more about this, but it definitively feel weird to me.