rlnorthcutt

Author here. The thing that surprised me writing this was how wrong I understood the AOT story initially. I'd repeated the "native binary, no PHP needed" line, but thats not really the case: binary mode still links libphp and PHPX, which have to ship in your deployment package. It starts without the PHP CLI, but it isn't a static Go-style binary.

The more interesting mode is -m ext, which outputs a .so that PHP loads as a normal extension. Writing a PHP extension has always meant writing C. Being able to write one in PHP changes who can realistically do it.

So, now PHP devs can ship better CLI tools (with libraries, but with less environment issues), AND can create custom PHP extensions that can speed up parts of the app.

"There are moments when a dependency graph becomes performance art."

Hats off to the author for not only following the muse into the archives of ancient tech... but for stubbornly continuing forward even when all paths seem open.

I loved the trip down memory lane with some of these things, and really resonate with the dependency hell issue... though the hardware nature of this and multiple machines is a nice twist.

Really fun read. 5 Stars. Would read again.

Omnideck stress-tests its own browser tools on 50 real websites, diagnose failures by reading its own own source code, and files GitHub issues with the fix already identified.

It does NOT apply the fix itself to maintain separation of concerns and get human in the loop quality checks and planning.

A practical look at the two OpenAI API formats, why one became a de facto standard, and what the new Open Responses spec changes.

I built analyzerepo to solve the "cold start" problem for both new developers and AI agents. Whether you are jumping into a legacy codebase or trying to make Claude Code actually useful on day one, you usually spend the first hour just trying to figure out where the entry points are and how the pieces fit together.

This is a Go-based CLI that points Claude at any GitHub or local repo to generate three specific, high-context Markdown files:

1) ONBOARDING.md: A human-readable guide that maps out the project’s purpose, language stats, file tree, and a "doc library" of existing .md files. Hand this to a new contributor to save an hour of verbal walkthroughs.

2) ANALYSIS.md: A per-file audit that classifies roles (e.g., entrypoint, core, util) and provides structured improvement suggestions. Each suggestion includes a done_when condition specifically optimized so you can paste the block directly into a Claude Code prompt for a working implementation.

3) CLAUDE.md: A project-specific context file that Claude Code reads automatically to understand your architecture and conventions instead of being generically cautious.

Key Features:

- Zero Dependencies: No runtime or language install required; it’s a single binary. - Smart Selection: It uses Claude to identify the most structurally significant files instead of hitting token limits with junk files. - Flexible Backend: It automatically detects your ANTHROPIC_API_KEY or uses your existing Claude CLI installation.

I’d love to hear how this handles your repos or what other "AI-native" documentation formats would be useful for your workflow.

Wow - I really appreciate you taking the time to look at it again. My original comment was written quickly, and probably no where near as clear as it could have been.

I respect your willingness to modify your original stance upon closer examination. Non-ironic hat tip.

Straw man + slippery slope.

I never said that, or implied it. It would be dumb to say that someone who creates an open source project is at the mercy of the people who use it.

But, many people have had the experience of dealing with loud voices in open source communities, and sometimes abusive voices. Or people who are pushing/promoting things that they want but are actually contrary to the goals and well being of the project.

As I stated, that power is a potential route to abuse. This is absolutely true whether the person is a maintainer, contributor, or creator.

If you create an open source project, of course you have absolute power over it... to suggest otherwise is foolish.

And we have seen projects that fail or collapse due to lack of leadership, corrosive culture, myopia, or burnout. That is inevitable.

My point is that we need to be realistic about these things. This goes back to the original post that "open source is not about you". Users aren't "owe" anything by a project or its creator. At the same time, creators/maintainers have a relationship with the community.

How they choose to manage that relationship is their choice... but we should be aware and honest about what that means and how it impacts the project (and the community).

Its an interesting situation when an asset (like an open source project) is run by a team of volunteers (community)... but due to licensing, it kind of belongs to the whole world (community)

As a user of a project, I DO have a voice... but unless I am actively contributing (money, time, resources), then my voice has a different weight.

On the one hand, I don't like the idea that anyone should get more influence simply because they pay money... or that anyone should have more power just because they are active in the project. Both of those situations are possible paths for corruption or abuse of power.

On the other hand, the tragedy of the commons is a real thing. People who take, never give back, and then have the audacity to not only ask but demand things... well, that makes me angry.

I've moved from being an idealist to a realist, when it comes to open source. I think the evolving models we are seeing that restrict commercial competition are sometimes pretty good (overall), and the rise in COSS is a positive sign. We need to ensure that good projects have a way to sustain themselves.

The best projects have people (or even teams) who are focused on bringing new people in and helping them contribute. Not everyone can do that, but I think finding ways to enable people to contribute (money, time, etc) is an important part of building the community.

Thats a great idea, and was my original plan. However, it just didn't make sense given the time and level of the response. The audit report is pretty straightforward, and has all of the details. I assume the technical folks who want to go deeper will read the full report.

The response to the feedback and to give some background was what was needed on our side, and we wanted that to be accessible to non-devs as well.

Imagine it. This is the result of multiple internal documents, comments, versions, etc. across marketing and engineering teams. Real people doing real work trying to share real information.

But, that does raise an interesting point.

Content produced by pure LLMs are actually a statistical aggregation of lots of human authors (initially, anyway). So, the non-deterministic "average" takes a specific tone (regression to the mean).

Perhaps you can get similar patterns when combining work across multiple authors, especially when there are different goals, styles, and expressions that are being combined.

You can blame me for the more marketing focused phrases - its an attempt to appeal to both engineering readers and business leaders. I try to find a balance being interesting (so people actually read it) and informative (so it is actually useful), but it can be a fine line.

The technical insights can be attributed to Willy, much of which came directly from his notes. Honestly, we could write a whole other blog post with the stuff we couldn't fit from him.

Thanks for reading.

From the post: "In this post, we’ll explore Go’s memory allocator in depth. We’ll look at its core components, how they interact to serve allocations of different sizes, and how stacks are managed alongside heap objects. Along the way, we’ll examine some case studies to understand the practical implications of Go’s memory allocation strategies. By the end, you should have a clearer picture of how Go abstracts memory management while offers high performance."

Actually this is a problem for anyone that either: - needs to rely on LTS versions - runs multi-threaded software (like HAProxy) - has real performance and scalability needs.

Note on #2 above that there are other LB/RP projects that don't have a problem here because they chose to be single threaded. This means their performance is not greatly impacted.

HAproxy is incredibly performant because the project chooses to prioritize performance. Also, as an open source project, we should applaud the efforts of the team to provide the best product possible and not just push everything of value into the commercial offering.

Thats pretty rare these days.

Actually, I'm trying to give the team the benefit of the doubt and assume good intentions. That may not be the case, but its a reasonable place to start.

And yes, they did choose to prioritize DX over performance - that was the major driving factor behind the re-architecture of the 3.x version. You stated this yourself: "OpenSSL 3.0 was a release that added new, cleaner APIs and deprecated older, uglier APIs, so the focus was on that and not performance"

If you read the article, it is clear that while they have improved some of the worst performance issues, the core architectural problems (like being dynamic and poor multi-threading support).

In fact, that is the entire point of the article. Even if you look at OpenSSL's self-reported metrics, you can see that there are improvements from the 3.0 release, but still not up to the level of 1.1.1 or the other libraries tested.

Upgrading an LTS library is a problem for many orgs... which is why we have LTS versions in the first place. Suggesting it is not a problem just because you don't have a problem upgrading doesn't remove the problem.

Finally, you can see in the article that these points were brought up many times over many years, and even again after 3.0 was released, and the OpenSSL team was not responsive.

No crying over spilled milk here - simply trying to clarify that this is a problem for some users, and actually trying to support the OpenSSL team's decisions... even if they aren't the ones I made. AGain - assuming good intentions.

It does no one any good to blindly attack or blindly defend anyone. Lets be honest about the problems, honest about the issues, and honest about the choices the team has chosen to make.

I agree that it is great to see the improvements. However, in the absence of comparisons to other libraries, it is tough to see the real impact. Even a comparison to the 1.x version would be helpful.

The concern is that relative to 3.0, it is improved... but relative to 1.x or a different library, it is not scalable.

There is also a RHEL/CentOS 8/9 + QuicTLS / AWS-LC package available to test out or start with.

https://github.com/haproxy/wiki/wiki/Packages

I have yet to find a perfect community anywhere - open source or not. And, as a general rule, I agree that we should try to support open source communities with whatever path they choose to take.

In this case, it seems to me that OpenSSL has chosen to prioritize DX and broader accessibility over performance. Even as we have seen some performance improvements since the initial 3.0 release, it is still not where it was.

Thats ok.

As a widely used library, it may actually be a good idea for the project to prioritize the longtail of users over those who have the highest performance needs. This is a valid response.

The only issue I see is that this may not have been clearly thought out or communicated, which is a completely understandable oversight. There is another potential issue with rolling out an LTS release that was not "fully baked" but again - these things happen.

Overall, we should look to refine and understand the goals for the project, and be clear on the priorities of those leading and maintaining it.

A decision-making framework breaking down the strengths, weaknesses and ideal use cases to help users choose the proper protocol for their systems.

"FileMaker is a powerful low-code platform that can build some pretty amazing apps, but the developer experience isn’t always as… let’s just say — modern. And while curl requests still have their uses, these days, I’d much rather use a Postman-like interface for making API calls. So I built one! And I wanted to share it with the FileMaker community."

This tutorial tells you how to create a reusable JS library on Github and use JSDelivr to serve it. As a bonus, there is an example repo that includes auto-generated documentation.

This is a decent fallback, but it really doesn't solve the underlying problem. The whole point of web components is the ability to encapsulate and reuse your work... and _specifically_ to extend the HTML tag library.

The fact that you need JS to load/run to parse your custom web component is an issue. But, the solution is to allow users to cache these components or add them to the browser itself.

Ideally, <user-avatar> should be available without JS just like <img> is. Imagine a world where we have this capability - a large library of reusable components that can be used as easily as native HTML. This is the vision, is it not?

Last line is good:

"Remember, all online content purchases are really just rentals."

This seems like the same basic tech problem - how to balance uninformed user protections with advanced user capabilities.

The problem is browser extensions and the ability for bad actors to use malicious code to harm users. This is a real threat - how do you protect users from their own actions?

Putting aside the cynicism about Google's "true" motives and assuming the best intentions on their part... this still seems like an overly broad limitation without a good workaround.

Personally, I use as few extensions as possible, and I'm very particular about which ones. I'm sure most readers here are as well. So, for me (us?), this is a problem, especially if we also maintain extensions. But - what about my mom? She doesn't even know how to remove extensions, never mind review them for potential problems. We should not sacrifice the many (and encourage the bad actors) to ensure that the few have the access they want.

Why not put in settings that allow the user to allow extensions outside the bounds of MV3? Why not put a warning on the extension page that it "could be risky", or even hide those extensions entirely from the users who don't know to adjust their settings?

There is a difference between inflation, which affects the entire monetary system, and money expiration which affects individual units of currency.

In the first case, there is no incentive to use the money any faster, and as long as inflation isn't too high, there could be incentives to hoard/save it.

In the second case, each unit has an expiration, and like the game of hot potato, you want it out of your hands quickly. This should heat up the economy overall, while inflation is seen as the result of an overheated system.

The trick, as noted, is who is poised to benefit? The "new" dollars would be worth more, so the people at the top of the flow would have more advantages than those at the bottom.

In order for something like this to work, it would also need to recognize the creation of value, and not just the creation of the currency. The person who turns a pile of wood into a chair is creating value, but they are usually not able to capture the true value of their time and skill.

Overall, this is an interesting idea especially in that it changes the way we think about money.

An interesting look at theories around "perishable" money.

A very interesting concept. Most resources in the world have a lifespan - even an iron bar will eventually rust. However, a dollar is as perpetual as the system itself.

On top of that, the entire economic system is designed to reward those who take more and give less - that is how you become rich, and being rich is the highest ideal.

However, if money had a lifespan... if it could "decay" just like the crops we grow, then things would change. If you try to sell a bushel of corn today, and there isn't much demand, you will need to lower the price to sell it. This is because it will go bad and then you will have nothing.

If you get paid a dollar today, and you know that dollar has a lifespan, then you are incentivized to spend it! If you have a million dollars that can expire, there isn't much use in holding or hoarding it... like the corn, it will go bad. So, you want to spend it - on things you need, or services, or by investing in equipment, training, research,etc. Heck - even just going on a trip or getting a nice meal is better than letting the money "rot" in a bank account.

I'm not so sure that something like this would work at scale. It seems to be more workable in smaller circles, like a LETS or local trade system. Still, the thought experiment is useful, and I thnk it helps to highlight how some of the problems we face are actually baked into the system.

From the article: 'Gesell believed that the most-rewarded impulse in our present economy is to give as little as possible and to receive as much as possible, in every transaction.

In doing so, he thought, we grow materially, morally and socially poorer. “The exploitation of our neighbor’s need, mutual plundering conducted with all the wiles of salesmanship, is the foundation of our economic life,” he lamented.'

Oh - that is freakin' amazing. - Using CSS to load an endpoint - clever - Hashing ip + date for anon tracking - thoughtful - Using :hover to ensure its a real user - genius

I made a quick app to adjust your sleep schedule for daylight savings time. Its public and forkable, so you can make your own version and adjust it as needed.

I made a simple app that lets you calculate a modified sleep schedule to help you adjust to DST more easily.

This is a tutorial so you can make your own in less than 20 minutes, OR you can just use my app. Alternatively, you can fork my app and customize or extend it.

NOTE: I'm not associated with UploadThing

I appreciate the transparency and the deep dive into what happened, why, and how they fixed it. It is always helpful to hear about the troubles of others AND the solutions so we can hopefully avoid some of the same issues

I've used Git for years, but never really dove into rebase or when/how to use it. I've always been fine with merge. But, I've been wanting to expand my skills, so this is an overview of git rebase and how it works.

A quick look at the history of the CLI, and an update on a project to re-imagine it with - inline help, undo functions, better security, and more. A very clever approach