jamietanna

> What's next? "$X isn't patching this CVE fast enough, here's a binary blob of our fix [...]"

https://www.chainguard.dev/athena

The PHP Foundation's official writeup of the vulnerability and details about the timelines to disclosure + fix: https://thephp.foundation/blog/2026/10/21/todays-php-securit...

More info further down the thread from Ellie (creator of Atuin): https://news.ycombinator.com/item?id=49914235

I'm resisting linking to several posts I've written on these lines before - I very much agree that - at least personally - writing the commit message helps me work through what's changed and most importantly why.

When AI writes the code for me, I then end up still writing the commit message so I can take ownership of the change myself, make sure I can explain why the change was made and see if there's any missing context that may lead to a different result

I did find that distilling some of my style choices to a `commit-style` skill helps when an AI writes a commit message (for me to rewrite) to be not quite as generic, but it's still needing my ownership to get it right

I've definitely seen at least one tool in the past - maybe via simonw - to use `git notes` to track that

Which fonts are you seeing not looking good? It seems perfectly readable sans-serif and monospace wise, but could be system preferences on what fonts to use?

And of nohello.com: https://news.ycombinator.com/from?site=nohello.com

+1 on this - Jake's done the best thing with deprecating the package (which shows up locally in tooling and will also be surfaced by static analysis tooling (ie security vendors) based on that, but also archiving the repo indicates it to anyone who lands on the repo

There are many reasons: https://news.ycombinator.com/item?id=47164481

At any time I'm working across 5-30 branches (some when I'm reviewing other folks' code) so it's handy to see my latest branches

Very much agree, and per https://www.jvt.me/posts/2026/02/25/llm-attribute/ there are a number of other benefits to attributing correctly - you know what parts of the code may be "tainted" by AI-generated code, and allow yourself to clarify to the reader what parts are AI and what are not

If it helps, in the Renovate project we don't usually request a full CVE ID, but use the GitHub Security Advisory (GHSA) ID

You can use those numbers in changelogs as soon as they're published

There is some human review, which takes time, before the GHSA is "GitHub-reviewed" which then allows security scanners to pick it up

Then, the CVE ID can be assigned to it after-the-fact if need be, but the GHSA should be a sufficient starting point

https://github.blog/security/supply-chain-security/inside-th... goes into it more

As mentioned by another commenter, they intentionally have a human reviewer in the process before a GitHub Security Advisory (GHSA) becomes "official" post-publish

(this is separate to getting CVE ID assigned, if wanted)

I would love for there to be some way to review commit messages - and suggest changes - alongside reviewing the code itself

FYI the code snippets have no indentation

That was a few days ago: https://news.ycombinator.com/item?id=48313577

*11.x

I personally prefer Free Software (FSF-approved) or Open Source (OSI-approved) licenses, but I also agree that there is a place for other licenses. It's better that there's space for kinda-open, rather than it being open vs completely closed repositories.

I've previously worked at a company using an "open source" license (Elastic, with the ELv2) and have enjoyed having to explain the difference to folks between what it meant to be "open source" vs "Open Source", and the fact that a lot of folks generally don't understand the difference and some of the nuance. Mentioning the BuSL was because it's something a lot more folks may be aware of, i.e. given Hashicorp's recent relicense (as with other companies in recent years)

Sustainability is hard, and having different ways to describe this is good! But it's a lot harder when people don't understand why something calling itself "open source" when it's "but you can't run it if you're a company" is bad

I must say, I'm honoured this commenter is so angry about this post, they've read through many of my blog posts, and gone through microsites like my Manual of Me[0], to pull this quote to attempt to criticise me

[0]: https://manual.jvt.me/

Hah, yes very true!

If you've not read up on the background between the two - I'd very much recommend it (and sorry if I'm re-explaining something you understand)

With Free Software, it's "free as in freedom", not "free as in gratis". Free Software is generally a bit more strongly biased towards the users of a piece of software, but as businesses started to use it they were a bit unhappy with that, so Open Source came to reduce that a little bit, making it easier for companies to use it, without as many strong protections for a user

See also [1]

[0]: https://www.gnu.org/philosophy/free-sw.en.html [1]: https://www.gnu.org/philosophy/open-source-misses-the-point....

I think using `open source`, and clarifying that it includes non-OSI-approved licenses could work.

Alternatively, "source available" is a term that's been used to imply the source is there, but it's not "open source" (which led to the Fair Source folks working on their own naming for it, so as some folks have negative views of "source available")