Mastodawn

the vessel of morganna 1d ago

if you're using AI regularly to generate text/presentations that you intend to use persuasively i don't think i can trust a single thing you say. Where does the AI end and the human begin?

I think this is why im so against AI generated commit messages especially if the code was written by a human, you wrote the code so you should be able to demonstrate that you understand what the change does and why.

If you're deferring that to an AI and you made a subtle logic error that it decides to justify for you suddenly we have obfuscated our own fucking zero days. Good luck finding the bug if the commit message describes the error as if it was intentional.

For general text, if you start with the conclusion and let the AI write the justification then there is no justification!!! Details matter, having a paper trail for decision making matters.

I wonder how many executives will escape the consequences of their white collar crimes by blaming AI.

AI zombification is coming and it's going to create a distinct difference in communication styles between those who do and don't use it, honestly that point is already here.

And we're gonna find out yet again that marx was right when it becomes clear that AI usage correlates with class lines.

@cas At some level I agree re AI generated commit messages. At another I've had to deal with so many "some small fixes" commits that I'd almost rather have the slop machine give something at least somewhat relevant to what the "small fixes" were.

Erin 💽✨2d ago

@cadey @cas I feel like a lot of these things would be fine in a sort of overlay mode. If I could fold out the summary when the message someone else has written is bad, or if I could have its review comments while I’m going through the code, that would be somewhat neat.

But writing the commit message or posting actual review comments? Its just all bad vibes.

samueldr 2d ago

@cadey @cas I'd rather have --allow-empty-message than not being able to trust commit messages being accurate.

And yes, they may already not be. But when they're not, they were at least a human-made mistake.

And why the fuck should the generated commit message be baked into the commit? Why not let generation happen on-demand such that when the models improve, the message improves?

@samueldr @cas I hate to say it, but your suggestion makes too much sense for anyone to actually implement.

Erin 💽✨1d ago

@cadey @samueldr @cas we gotta hammer things into the existing holes because redesigning the stack is inconceivable and/or too hard

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!1d ago

@erincandescent @samueldr @cadey @cas Story of the Linux kernel development process...

Val Packett 🧉1d ago

@lina @erincandescent @samueldr @cadey @cas also the story of everything the current "ai" industry is doing heh

Cassandrich 2d ago

@cadey @cas Illusion of a meaningful commit description is worse than no description. It loses one very important bit of information: whether the commit is undocumented.

d@nny disc@ mc² 2d ago

@cas people currently right now inject vulnerabilities into our shared source code by doing exactly as you describe and describing it as intentional. about 6 commits by red hat / IBM engineer david howells in linux-crypto were live on his linux-fs fork from friday to late sunday, before he reset and force pushed. linus agreed with include/crypto/public_key.h turning digest_size -> m_size. he was able to hide these commits not through "AI" (arguably it wasn't hidden at all) but at each point relying upon the right people to not say a thing. i throughout monday and tuesday i recorded ingo molnar adding a make syncconfig that weaponizes the howells config. i guess it makes sense that PREEMPT_RT was actually a fiction—it makes more sense than a monolithic kernel doing anything by half

d@nny disc@ mc² 2d ago

@cas i that you can quickly determine if I am wasting your time: if you have a local checkout, the following abbreviated refs modify what I believe to be precisely an area coreutils builds using the --with-linux-crypto configure script would subsequently become affected by. These are from two engineers, one David Howells from Red Hat / IBM, and Eric Biggers of Google.

965e9a2cf23b066d8bdeb690dff9cd7089c5f667 pkcs7: Change a pr_warn() to pr_warn_once()
91db696adea4d76017b1e1f45915a5cbf04e8da3 pkcs7: Allow authenticatedAttributes for ML-DSA
0ad9a71933e73c8a2af101d28e9a1dc35bae02d5 modsign: Enable ML-DSA module signing
8bbdeb7a25b4cd3d829136a2e12982b8ee7d7991 pkcs7, x509: Add ML-DSA support
f3eccecd782dbaf33d5ad0d1fd22ea277300acdb pkcs7: Allow the signing algo to do whatever digestion it wants itself
f728074f1f577565c97e465652c3d4afb0964013 pkcs7, x509: Rename ->digest to ->m
2c62068ac86bdd917a12eef49ba82ec8b091208b x509: Separately calculate sha256 for blacklist

fbfeca74043777b48add294089cd4c4f68ed3377 lib/crypto: aes: Drop 'volatile' from aes_sbox and aes_inv_sbox
9ddfabcc1ed884ef47bcca317e77596c797bef83 lib/crypto: sha1: Remove low-level functions from API
5023479627e3e85a97807f612bea2eddbf202e1d ipv6: Switch to higher-level SHA-1 functions
20d6f07004d639967dcb00994d56ce6d16118e9e lib/crypto: tests: Add a .kunitconfig file
4478e8eeb87120c11e90041864c2233238b2155a lib/crypto: tests: Depend on library options rather than selecting them
beeebffc807531f69445356180238500f56951cc lib/crypto: powerpc/aes: Fix rndkey_from_vsx() on big endian CPUs
ffd42b6d0420c4be97cc28fd1bb5f4c29e286e98 lib/crypto: mldsa: Clarify the documentation for mldsa_verify() slightly

This is my checkout of Linus's checkout:
https://codeberg.org/cosmicexplorer/linux/src/branch/master

This is Linus's checkout:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

c369299895a591d96745d6492d4888259b004a9e

In particular, there was:

ML-DSA module signing added with this openly broken config section:config PKCS7_WAIVE_AUTHATTRS_REJECTION_FOR_MLDSA
bool "Waive rejection of authenticatedAttributes for ML-DSA"
depends on PKCS7_MESSAGE_PARSER
depends on CRYPTO_MLDSA
help
Due to use of CMS_NOATTR with ML-DSA not being supported in
OpenSSL < 4.0 (and thus any released version), enabling this
allows authenticatedAttributes to be used with ML-DSA for
module signing. Use of authenticatedAttributes in this
context is normally rejected.
wide-ranging changes to cryptographic APIs (I was under the impression include/crypto/public_key.h is shared with dependents such as coreutils)
finally, there is this new directory scripts/livepatch, with two files of significance:
fix-patch-lines, which pretty openly states that its goal is to create patch files that work after nontrivial modifications
klp-build, which will modify and update the kernel configuration so that it the above is not exposed.

linux

linux fork for silly nonsense

Codeberg.org

d@nny disc@ mc² 2d ago

@cas in fact, to put these two points together, the post-"quantum" key shit is used as a pretext to fundamentally alter everything we used to believe was safe. signal instituted a new protocol and i don't plan to break it, but it's not scientific and weak against adversarial randomness. signal doesn't let you choose, so for postmarket i'd recommend immense caution with tbh any of the crypto changes but especially those two men. the new signal cryptographer, at the last lines of the 60 pages plus appendix, mentions that randomness is the os's job—someone has to protect them. you also may genuinely be able to just run an older version—but the way these things go, i assume they released some devastating vulns right after adoption

d@nny disc@ mc² 2d ago

@cas seeing linus this way hurt me deeply to my core. i believed in him. he will be one of the many interchangeable innovators of history, too cynical to build protection

Cassandrich 2d ago

@hipsterelectron @cas Louder for the folks in the back:

"The post-'quantum' key shit is used as a pretext to fundamentally alter everything we used to believe was safe."

So. Much. This.

matthewcroughan 2d ago

It has been devastating to watch AI go from interesting and maybe something I'd like to get into and support the open source aspects of, to a destructive pollutant of mind, planet and soul with trust eroding social consequences. It is so fucking boring and annoying.

@matthewcroughan it's genuinely depressing and i unironically think once we return to sanity there will be a grieving process for those of us who will no doubt spend the next few years advocating for people to actually be themselves and not engage with the world through the filter of an LLM.

The collective trauma of social media aint got nothing on this shit

Enola Knezevic 1d ago

@cas @matthewcroughan It is comparable to letting covid rip, and now I think that the (long) covid cognitive damage probably made us more susceptible to LLMs, more likely to outsource thinking.

Ariadne Conill 🐰

@cas AI commit messages are an excellent way to shoot yourself in the foot

@cas @ariadne “don’t trust, verify everything” is the overwhelming feeling I see from all genAI/LLM output.

If I’m trying to watch or learn from someone, the last thing I need is to not actually believe or trust every single word they say, and have to question all of it. I’ll just find someone who actually finds it worth it to just use their own brain.

@cas Why is the keyword here. What I can read from the code, why I can’t. Neither can an AI.

@cas I agree completely regarding things you are intending for communication. That being said, my line for 'communication' in a shared repository is at the PR level. I would much rather have extremely accurate and over documented commit messages made by AI paired with an 'artisanal' human written message for **why** the change needs to happen, and what they where thinking when they made the change.

I feel like I am only really reading commit messages to figure out why a bug happened, and having very thorough (honestly usually too thorough) commit messages is nice.

@sbysb having a "---" line break at the end of the commit message followed by some AI generated description would be less harmful, it also has the bonus that it gets removed if you export it with git format-patch and apply it with "git am", so could be removed easily from being committed permanently to the repo while still being easily found in MRs or mailing lists

@cas I think for most of the git as a service websites that would mean you still would end up with a timeline of 'fix' 'fix 2' 'linting' 'fix again' with the description of what actually changed hidden. The value of my commit messages is already about zero as it stands if I am writing them, mostly because I can't stand writing commit messages.

A lot of this comes down to how you use git - I might have 30 commit messages in a PR, because I commit and push religiously on basically any change. In my experience Claude is 100% correct when writing a commit message for these small changes so the average value of a commit message on my projects has skyrocketed.

On the flip side I have played around with having Claude create the PR itself and am frequently disappointed in how it describes the change. I think what you are describing is actually essentially how it works in my flow: I hand write the PR title and description, and if you wanna look at a summary of what was done specifically there is a whole timeline of very detailed commit messages

@sbysb yeah idk, i generally subscribe to the kernel/uboot workflow where you prepare patches carefully and actually have to write good commit messages. I make heavy use of git absorb and manual commit --fixup to make improvements to a patch series so it encompasses sensible changes from the context of the codebase rather than representing a timeline of changes from the context of the developer (which generally has a lot of unnecessary context and is missing more important context) overall making code harder to understand

thats the mindset from where im speaking anyway, if you don't care about the quality of individual commits in the same way then whether they're human or AI written becomes quite a different question

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!1d ago

@cas @sbysb Those two flows are not incompatible. You can have sensible commit messages describing individual logical changes, and a PR describing a group of related changes. It's exactly the same as the cover letter model.

If your commit messages are essentially worthless and you rely on the PR description to actually describe what is going on, then the solution is to hit the "squash" button instead of the "merge" button and promote the PR description to a single commit message.

I think that once you're collaborating with others, a messy commit history has negative value. The tiny commits are useful ephemerally during development, but not as a historical record. It's better to have larger commits with good documentation than it is to have meandering small commits which hardly make sense on their own. Just squash. That's also very important because PR descriptions are often lost. You don't want important information about code history to exist only in the forge database.

Squashing also makes rebasing and pulling patches out easier, especially if the development process involved trying and redoing things to any extent. Having commits that revert portions of each other in the history is actively harmful in this case. Essentially, if your PR model involves reviewing the "global changes" view, you want to squash. If you review individual commits, you don't.

Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!1d ago

@cas @sbysb And both models can coexist in a single project. Usually what you see is more experienced contributors doing the careful commits thing as part of a complex change, and less experienced contributors sending in simple changes with revisions tacked on as extra commits. As a maintainer it's very easy to see what you're dealing with and choose the right approach to review the PR and whether to hit the merge/rebase or squash button.

You don't need to force people into either model (if you don't insist on archaic submission processes like uboot and the kernel do). Forges make it easy to handle both.