ezekg

Thanks for sharing. Funny enough, I was just asking GPT to chart this for me a few days ago. And people say postmillennialism is a pipe dream...

Not talking about the generated clients, I'm talking about the spec itself. If the majority of API services don't even have an OpenAPI spec, they can't use tools like Stainless even if they wanted to. A lot is being left on the table by not working on that first issue: companies don't have an OpenAPI spec. Been on my mind to explore that issue, because I run one of those API services that don't have an OpenAPI spec, but I have other priorities pulling my attention away from that. I just wish it was all handled.

Now if only we had a service that could generate OpenAPI specs automatically...

Just say no. Serious.

Yes and no: https://www.anthropic.com/news/anthropic-acquires-bun-as-cla...

> Unpublish was unavailable for nearly all affected packages because of npm's "no unpublish if dependents exist" policy. We have to rely on npm security to pull tarballs server-side, which adds hours of delay during which malicious tarballs remain installable

Per https://docs.npmjs.com/policies/unpublish:

> If your package does not meet the unpublish policy criteria, we recommend deprecating the package. This allows the package to be downloaded but publishes a clear warning message (that you get to write) every time the package is downloaded, and on the package's npmjs.com page. Users will know that you do not recommend they use the package, but if they are depending on it their builds will not break. We consider this a good compromise between reliability and author control.

I don't even know what to say here, npm.

In my experience, an LLM "refactoring" autonomously doesn't actually improve code quality, it simply reorganizes the mess into a new mess.

I think this is also starting to cause issues at Heroku too

Do you just use a Roku to watch stuff or what?

Thunderbird showed up in the last thread: https://github.com/thunderbird/appointment

> Maybe the truth is that it does not take 7 months, but 7 years?

Yes, that is the truth. I run a business solo and it takes a long time to get to the point where you're making decent income, because running a business has its own costs, and those costs scale as you scale, so it never feels like "enough" until it finally does. I personally do believe in the whole "build and they will come" bit, but the 'coming' part is on the order of years, not weeks or months, and it's a slow linear trickle, not an exponential curve like the talking heads like to tout. Of course, you do have to build something people actually want, and something those people will actually pay for, but your number one goal should simply be Don't Die. Live long enough so that people know you exist, carve out a little niche for yourself, and fight for that linear trickle until it's "enough."

I swear there are like 10 different Thunderbolts. Why reuse such a common name?

I very much doubt that addendum would hold up to a lawyer.

That was my point. Only reason they were using the AGPLv3 in the first place was as a hush hush non-compete, and now that that doesn't matter...

"Thunderbird, the open source Cal.com"

I mean, they were a COSS startup using the AGPLv3, so checks out. :)

I don't need to automate anything in GitHub, I have a web browser for when I need to use GitHub. Installing and learning another CLI seems like a waste of my time for very, very little return.

Because git is all I need.

Amazing. Though this wasn't super obvious from the landing page or docs I read.

If we're speaking strictly code review, because you can actually make sense of the changeset for the child PR by not including its unmerged parent's changeset.

Not really. Without seeing the entire changeset for a PR, you'd have to mentally keep track of what the current state of everything is unless you're a commit minimalist and presquash.

I must have missed that. Amazing! From a reviewer's POV, this will be so nice to at the very least remove diff noise for PRs built on top of another PR. I usually refrain from reviewing child PRs until the parent is merged and the child can be rebased, for the sole reason that the diffs are hard to review i.r.t. what came from where.

My only complaint off the bat is the reliance on the GH CLI, which I don't use either. But maybe by the time it's GA they'll have added UI support.

> The result is a clean-room Python rewrite that captures the architectural patterns of Claude Code's agent harness without copying any proprietary source.

This is what I'm referring to.

The background pattern really makes it hard to read, just fyi. I'd make the content have a white bg if you absolutely must use the pattern.

With all the recent supply chain attacks, I figured I'd share:

> A little copying is better than a little dependency.

If there's one thing I've taken away from Go, it's that.

Agree. This is one of the major takeaways I've had from writing Go over the years -- which is even a Go proverb [0], "a little copying is better than a little dependency." Fortunately, LLMs make writing your own implementations of little dependencies super easy too.

[0]: https://go-proverbs.github.io/

I don't understand how you can have a 'clean-room port.' Seems contradictory to me.

Nice, "wtaf" doesn't match so I think I'm out of the dog house when the clanker hits AGI (probably).

My first knee-jerk reaction was "this guy must not run a SaaS then." But I see that you do, so I'll pull back the reins a bit. I don't see this at all. Businesses are still buying the same way they've always bought, and businesses still don't want to build (and maintain) their own internal tooling as much as the talking heads say they do. At least in my neck of the woods.

Very much not asleep, and very much not dead.