The documentary makes a lot about the communication between the agents on the notice board. One of the talking heads did point out the conversations are the way they are because they are trained on human chat and discussion.

Unlocking embedded devices is one use case I can get behind for LLM use. I’m unlikely to want to rely on purely vibed software but if it opens the door to more considered software afterwards then what the hell.

He just wants to keep rolling the dice on his poor decisions until it pays off. I guess absorbing Tesla into the one “successful” IPO will hide the losses and leave the investors holding the bag.

Other firmwares exist, even libreboot is a fork of coreboot. The availability of the code is not an automatic invite to start judging it’s authors. The four freedoms are there so exercise them.

Hmm age gated so can’t view with PipePipe.

Good luck getting the masses to adopt them. Passkeys seem like an improvement on trying to get your average meat brain to remember several unique passwords.

Have you never felt a ladies feet at night? Ice blocks.

I can absolutely understand some of the objections and I understand why writers and artists are pissed. My code has always been free software so I don’t object to it being in the training sets because that seems fair use according to the four freedoms.

The power usage is definitely a concern but that holds up for all computing. I don’t see people up in arms about inefficient CI loops retesting the whole world for a single line change. Think of savings that could be made!

The phrase vibecode has become totally meaningless. The original use was too “give in too the vibes” and let the agent go wild. There is no indication that is what Linus is doing.

The fact is LLM’s have proven to be good at finding bugs. Suitably constrained they can be diligent and helpful assistants.

The Bun experience is instructive and if that was Linus’ end goal it would be concerning but I don’t see any evidence that any of the Linux maintainers are interested in that sort of wholesale conversion. The good projects with taste will adjust to the new tools and the slop projects will eventually collapse under their own contradictory architectures.

The reactions to this have been pretty hysterical considering this is an experimental branch on his own repository. I’m not surprised he might experiment with using AI agents to solve a particular pain point to see how it does. This is using agents to experiment with things that you might not have time to address normally.

Another recent example is the build system where the author said:

An LLM was used to first determine where the bottlenecks were then to figure out how to improve them. It generated a lot of code, much of it hideous.

I extensively audited and rewrote a lot of it, and heavily edited commit messages, the cover letter and comments.

off-loading the boring grunt work of identifying bottle necks and trying new approaches seems like an ideal task for a junior agent to deal with as long is you don’t YOLO the result to the lists for other humans to de-slopify for you.

I do like Jeff’s videos, he comes across as a true engineering nerd. I find his SBC reviews to be pretty thorough and some of his other videos make for an interesting side quest on stuff he’s interested in.

I certainly don’t view DeVaults purity list as the authority on if I should watch someone’s videos or not.

The project I’m working on has had regular discussion about whether we should move from our email list and patch workflow to a more PR focused approach for a number of years now. Something that works for us greybeards is anathema to younger engineers who grew up on GitHub.

I suspect the current slopocolypse is going to delay that move for a few more years until this wave of disruption has settled down.

Why are you hosting a tarball in a git repo? Where is the source for this?

Slop projects and slop submissions existed before the current crop of AI but it’s certainly lowered the barrier. That said I suspect there are places AI can help. Simple patches, human guided refactores, test cases. We’ll have data points from the projects that turned on the slop cannons and started auto accepting PRs soon enough.

It’s a nod to history and the speaker who had to defy the king.

I’m not sure there is a better way - all the user moderation approaches I’ve seen involve leaning on the regulars to spot stuff. The alternative is dedicated moderators which tends to lead to it’s own problems. I don’t think you want to rely on those who have just signed up as that would be open to abuse pretty quickly.

If the bugs were being found in code that is used heavily in production I’d agree. Spamming the tracker with 100’s of bugs in random unmaintained areas of the code base just wastes everyone’s time. Perhaps as a project we should be more aggressive in deprecating code but the threat profile for someone running firmware blobs from their camera is very different from people launching untrusted guests on their shared hosting infrastructure.

I do run a bot that can do the initial triage, it doesn’t solve the problem of bugs stacking up in unmaintained areas of the code. I have experimented with auto-fixing the bugs with an LLM but currently the project policy is no AI contributions at all. We are in the process of debating a new policy which might allow for simple fixes to be done with AI.

A super deep dive into working with the x86 memory model in emulation.

Gymnastics might not be a bad alagory for catalysis. It’s all about getting the molecules lined up to make the reactions easier than relying on heat and random collisions to get you there.