andrybak

> agriculture is that we need one to survive as a species

true for some agriculture, but growing the corn for ethanol is stupid

the discussion of the his reddit comment itself: https://news.ycombinator.com/item?id=49146757

The way pull requests and commits work in the OpenJDK repository -- a bot squashes each pull request into one commit: https://github.com/openjdk/jdk/pull/31120#issuecomment-51378...

The final singular commit is cc278db (8389219: Implement JEP 401: Value Objects (Preview), 2026-07-31) https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842...

> Articles for Deletion votes -- original with comments

>

> Summarizing it, 5/7 for delete have accounts, and 1/4 for keep have accounts. Not along after the final vote, a Wikipedia admin deleted the article. Being a little bit lax with my language, the majority's consensus agreed that Odin isn't notable, and the article had no reliable sources.

important clarification about a popular misconception: "Articles for deletion" discussions on English Wikipedia are not decided by vote.

For more details, see

- https://en.wikipedia.org/wiki/Wikipedia:Polling_is_not_a_sub...

- https://en.wikipedia.org/wiki/Wikipedia:Guide_to_deletion#Ov...

in addition to a relevant xkcd, there is also a Wikipedia article about the phenomenon and a behind-the-scenes list

- https://en.wikipedia.org/wiki/Circular_reporting#On_Wikipedi...

- https://en.wikipedia.org/wiki/Wikipedia:List_of_citogenesis_...

- previous discussion: https://news.ycombinator.com/item?id=35535407

Git is more robust than Jira. Git log is accessible offline. Jira descriptions exist only as long as people managing the Jira instance are competent and are migrating the necessary data correctly when migrations are needed. Even migrations from one Jira instance to another (e.g. when companies get acquired and two Jira servers get merged) can be extremely brittle.

It's fair that maybe such simple trivial changes don't deserve such a wordy commit message. But these are just fictional examples that I came up with on the spot. Refactorings, new features, and bugfixes can all have various levels of complexity.

A good commit message helps answer the "why?" questions first and foremost. If a diff is fairly large, pointing out the most important change can be useful. Explanations for non-trivial dataflow can sometimes not make sense in separate documentation, but still be relevant in a commit message.

if IDE supports converting them into clickable links, then scrolling through a log in its Git integration (kinda like `git log --oneline`) will be a convenient list of links to issues. If the commit messages are good, you just skip over the Jira issue/ticket key/ID. If what you want is to see the requirements of a feature or steps to reproduce of a bug or some other context for the ticket, then a clickable link is very convenient. Of course, sometimes it does make sense to include some of that information in the commit message as well.

When working in big teams, it can be very hard to increase the usefulness of commit messages. On the other hand, enforcing inclusion of a Jira issue key in commit messages is easy to implement. Relying on issue tracker descriptions can be a difficult proposition as well. Quality of individual ticket descriptions can be low; depending on how responsibility for maintenance is handled, the bug tracker migrations can sometimes be handled improperly and information can be more easily lost than in a Git log.

The difference is that the Jira ticket is for everyone involved in a project (business analyst, UI designer, QA, support, DBA), while commit messages are written with developers being almost exclusive audience. PRJ-123 might explain why an end user might need it, but the commit message explains why the change (diff) is the way that it is. The ticket answers requirements-level questions, the commit message answers code-level questions. Commit messages are useful both during the review and when a future maintainer is reading the code.

> Additionally, if a change requires multiple commits, you don't want to be repeating the justifications for the entire feature in every commit message. It's redundant. But the commits will all be tied together by the ticket reference in the commit message.

Different commits do different things, so require different justifications. Here's a fictional example to demonstrate:

First commit:

    [PRJ-123] Server: extract class Foo
    
    In the next commit, we're going to need to re-use the foo logic from
    class Bar. Extract new class Foo from Bar to make it available for
    re-use.

Second commit on the same ticket

    [PRJ-123] Server: use Foo in Baz
    
    The users of BazClient need to be able to see foo information in the
    baz dialog.  Include Foo in the data sent by class Baz in the server.

Side note: the user might not even know that they are looking at Foo and Baz, it might be called something else in the UI they are shown. Whether or not this needs to be included in the commit message depends on the situation.

And later in a commit fixing a bug:

    [PRJ-456] Server: check ID for null in Foo
    
    When class Foo was extracted from Bar in commit deadbeef ([PRJ-123]
    Server: extract class Foo, 2026-06-06), a null check for the field
    ID got lost by accident.
    
    Check the field ID for null in class Foo to avoid a
    NullPointerException when a foo event is sent to Baz.

archive.is is one of the domains of archive.today, which used its end users for a DDOS attack on a blog. This caused English Wikipedia to deprecate it with the end goal of blacklisting: https://en.wikipedia.org/wiki/Wikipedia:Archive.today_guidan...

According to the original reporter, the bug is still exploitable and that's why the issue on the bug tracker got hidden again.

> OH NO I JUST REALIZED THIS IS NOT ACTUALLY PROPERLY FIXED AND STILL WORKS

> even worse, edge no longer even makes the download menu pop up, so it's completely silent js rce that keeps running even after you close the browser !!

> all from just visiting a single website once !!

> issue set to private again, hopefully it'll get fixed properly this time :p

original comment: https://old.reddit.com/r/bcachefs/comments/1rblll1/the_blog_...

Reported by several researchers on Mastodon:

- https://infosec.exchange/@hovav/115731038692335809 - https://mastodon.acm.org/@tadd/115730400064282479

A 2022 Technology Connections video explores various ways to boil water: https://www.youtube.com/watch?v=_yMMTVVJI4c

And a 2020 video about different voltages in the US electrical systems: https://www.youtube.com/watch?v=jMmUoZh3Hq4

"Uncurled" by Daniel Stenberg, maintainer of curl, is a great resource for FOSS maintainers as well:

https://un.curl.dev/

Do chlorofluorocarbons (CFCs) mostly banned by the Montreal Protocol count?

A different UI to the mailing list with the whole thread on one page and diff coloring, if anyone is interested: https://lore.kernel.org/lkml/20250319-rfc2203-seqnum-cache-v...

The kernel repository has pretty extensive documentation on how to describe the code changes in the commit messages:

- https://docs.kernel.org/process/submitting-patches.html#desc...

- https://github.com/torvalds/linux/blob/master/Documentation/...

- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Git's own guidelines also have a nice description on how to write a better commit message:

- https://git-scm.com/docs/SubmittingPatches

- https://github.com/git/git/blob/master/Documentation/Submitt...

- https://git.kernel.org/pub/scm/git/git.git/tree/Documentatio...

> In this second test, the word error rate was 43.75 percent, meaning participants identified a bit more than half of the recorded words correctly.

> [...]

> “We’re not at the point where it could be used in open-ended conversations. I think of this as a proof of concept,” [Sergey Stavisky, a neuroscientist at UC Davis and a senior author of the study] says.

The ability to produce sound without a use of a dictionary sounds awesome. It is an interesting result, a proof of concept as the author of the study says, but the title is editorialized at best and effectively clickbait at worst, because most readers will assume that "near instantaneous speech" means "clear intelligible speech and ability to communicate".

> One thing that put me off is how so much of what I saw was just talking about Bluesky vs Twitter. I hope they can move past that.

Judiciously using the muting features is required to have a good time in social media. Add "Twitter" to muted words to move past that on your own.

Also no search by episode titles.

It's covered a bit at the bottom of the article.

  Where do you find these exceedingly winnable contests?
  
  Sorry, that’s a trade secret — but it’s not any of the standard various contest aggregators out there.

> I remember watching a design documentary years ago

Was it Map Men? They mention not forcing the London tube map onto the geographical map. It has two parts:

1. "The Tube Map nearly looked very different" https://www.youtube.com/watch?v=cTLCfl01zuE

2. "What went wrong with the Tube Map?" https://www.youtube.com/watch?v=jaEhvWXmLyk

> We have used IPGs to specify a number of file formats including ZIP, ELF, GIF, PE, and part of PDF

For PDF, that's fair. Video "Types of PDF - Computerphile" covers this: https://www.youtube.com/watch?v=K7oxZCgO1dY

> Their "Statement" is remarkably aloof for having brought down flights, hospitals, and 911 services.

Their lawyers certainly won't allow mentioning such dramatic (is "dramatic" appropriate here?) consequences.

One of the problems possibly preventing this is that budgets for buying software aren't controlled by people administering the software. Definitely not by people using it.

> unchecking “Make searches and browsing better”

Before that, you can make it audible: <https://github.com/berthubert/googerteller>

The version that was put on the Main Page of English Wikipedia today also has the accordion part: https://en.wikipedia.org/wiki/Template:POTD/2024-01-01