kjgkjhfkjf

Given the sums of money involved, it's hard for me to take these highly publicized heroic resignations at face value.

A spec-compliant Unicode renderer is expected to render 259 flags [1]. So 8 bits isn't quite enough. You would need 9.

Obviously an arbitrary bitmap of dimensions that could be used for a recognizable flag would need orders of magnitude more storage. The constraint that we are representing a finite set of flags is what admits such a compact representation.

[1] https://www.unicode.org/Public/emoji/latest/emoji-sequences....

In case anyone else was curious about using a lookup table: there are there are fewer than 256 recognized countries or territories [1], so 8 bits should be enough for a key.

This would be superior to the 11-bit encoding presented here because it handles complexities such as coats of arms. It would also handle bizarre situations such as two countries having almost identical flags [2].

[1] https://en.wikipedia.org/wiki/List_of_countries_and_territor...

[2] https://www.worldatlas.com/articles/country-flags-that-resem...

Perhaps it would be simpler to make all non-essential cookies illegal. I cannot imagine why any reasonable person would want to accept non-essential cookies, other than in the course of following a path of least resistance.

I wish Cloudflare provided a paved path for user auth.

Better Auth seems to be the most common recommendation for Typescript applications, but there currently doesn't seem to be an official integration with Workers either from Better Auth or from Cloudflare.

I currently use Supabase to avoid having to set up my own user auth on Workers, but I would much prefer to use D1 etc.

I like the concept. It's fun. Feedback:

1. The ball seems a bit soft. I suggest you get a real golf ball and putter and see how they behave, if you haven't already.

2. It would be nice if the camera positioned automatically so that it's roughly in the direction the ball should go on the next shot.

3. There were a bunch of flying yellow blobs. I was not sure what they were supposed to be.

The script to create the benchmark numbers appears to be inserting 100 batches, not 10. (The benchmark numbers in the table appear to be consistent with the text, so I guess the actual script used to create them was correct.)

When I left Google in the mid 2010s, there were a couple unusual constraints: 1. They had the majority of their code in a vast++ monorepo. 2. There was a policy that forbade having code from this monorepo on your laptop.

Most companies and projects have orders of magnitude less code, and don't restrict where that code can be stored. It's interesting to learn about Cider and the other things Google built to address their unusual situation, but it's worth keeping in mind that their approach probably isn't ideal in ~most modern dev scenarios.

Markdown is much easier to write quickly than HTML. Situations where I write Markdown quickly include writing messages on Slack and for AI chatbots. I wouldn't want to use HTML in either of those cases.

Seems like it would be simpler to give the agent tools to issue ChromaDB (or SQL) queries directly, rather than giving the LLM unix-like tools that are converted into queries under the hood using a complicated proprietary setup.

It seems like the author feels like a fraud because they successfully made a contribution without learning anything.

The quality of a contribution is not a function of how much you learned or grew while you made it. Learning and growth are part of your compensation for making the contribution. The author is not a fraud for not learning anything. If anything, it seems like they should feel short-changed!

When voluntarily making contributions to open-source projects, everyone should of course feel free not to use AI tools if they want. However, I would argue that using AI tools is a valuable skill itself, and worth practicing.

> if you have a job where you create complexity for others, you will be found out

This explains the panic. It describes most roles in big tech.

The article seems to conflate complexity and scalability, but there's a kernel of truth to its premise. The larger the tech company, the more maddening the processes tend to be. Maybe the next generation of AI-enabled companies will be smaller and less bureaucratic.

The article is a bit dense, but what it's announcing is effectively golang's `defer` (with extra braces) or a limited form of C++'s RAII (with much less boilerplate).

Both RAII and `defer` have proven to be highly useful in real-world code. This seems like a good addition to the C language that I hope makes it into the standard.

I was very impressed by AI-generated CSS when I didn't know CSS.

Then I learned CSS.

Now I am not as impressed by AI-generated CSS.

I feel like this book has aged badly, particularly the parts about encounters with very young girls. It's also very repetitive and far too long, in my opinion.

I clicked on the link expecting information on how to shed big tech's golden handcuffs. Instead of that, I was assaulted with a bunch of barely coherent bragging about the author's career and sex life.

1/5 would not click again.

Cloudflare's goal is to become the default choice for anyone deploying an app to the cloud. It makes sense for them to support popular frameworks such as Astro, so that they can ensure that the frameworks work very well on their Workers platform.

Proposals like these seem to assume that FOSS is mostly produced by unpaid volunteers. But a lot of the open-source stuff that I personally use is produced by massively profitable companies.

For example, I am currently working with React, which was produced by Meta. I write the code using TypeScript, which was produced by Microsoft (and other corporate behemoths such as Google). I am writing this comment in Chrome (produced by Google). Etc.

Yep, and I think it is a great way to draw attention to their work!

I'm glad you wrote it up. Thanks! But I feel like the folks behind the HTML5 spec and the comprehensive test suite deserve the lion's share of the credit for this (very neat) achievement.

Most projects don't have a detailed spec at the outset. Decades of experience have shown that trying to build a detailed spec upfront does not work out well for a vast class of projects. And many projects don't even have a comprehensive test suite when they go into production!

It would be very interesting to see a post-mortem for each of the design mistakes, with links to the original design discussions and docs, and analysis of how the decision-making process went astray.

That's an interesting point, but in many (most?) cases productivity doesn't depend on all services being available at the same time. If one service goes down, you can usually be productive by using an alternative (e.g. if HN is down you go to Reddit, if email isn't working you catch up with Slack).

The system rewards people who can exploit it.

To be fair to Rust, the issue was an "unwrap" in the Rust code[0]. "unwrap" means "if the operation did not succeed then panic". Production Rust code should not use "unwrap", and should instead have logic to handle the failure case.

You don't need exotic formal verification methods to enforce this best practice. You just need a linter.

[0] https://blog.cloudflare.com/18-november-2025-outage/#memory-...

My guess is that Claude's "bad days" are due to the service becoming overloaded and failing over to use cheaper models.

Seems like a substantial fraction of the web was brought down because of a coding error that should have been caught in CI by a linter.

These folks weren't operating for charity. They were highly paid so-called professionals.

Who will be held accountable for this?

The repo[0] currently has been forked ~41300 times.

[0] https://github.com/wesbos/JavaScript30

This is quite likely to be in the training data, since it's one of the projects in Wes Bos's free 30 days of Javascript course[0].

[0] https://javascript30.com/

I love it!