News for hackers. Stuff that matters.

cbrake

Re:Why Are Coding Agents So Dumb? on Friday October 09, 2026 @01:37PM (#50024028)
Enjoyed this article, lots I can relate to.

One thing that seems to help for me is to do the docs before plans (collaboratively edit with agent). Then I understand what this change is going to look like from the user's perspective before we start implementation. This seems to help keep things on track.

While I don't use this plugin a lot anymore, I think doc-driven development is one of the most effective ways to do development in any paradigm, I should probably refresh this plugin and use it more:

https://github.com/tmpdir-org/tmpdir-claude-code-marketplace...

Re:Is it time for a new Embedded Linux build system? on Thursday June 25, 2026 @09:25AM (#48673009)
Thanks for the detailed explanation!
Re:Is it time for a new Embedded Linux build system? on Thursday June 25, 2026 @09:22AM (#48672977)
Agreed, building on the typical target is a terrible idea. None of my suggestions are to build on target, but rather specific units on some capable hardware of the same architecture. The main build will still run on your own workstation of any architecture. Only specific units get farmed out to another machine, but worst case can be run in QEMU user mode emulation if there is no native machine runner available.

This remote build runner is not implemented yet, just ideas.

Re:Is it time for a new Embedded Linux build system? on Wednesday June 24, 2026 @05:33PM (#48665883)
Is this similar to QEMU user mode emulation?
Re:Is it time for a new Embedded Linux build system? on Wednesday June 24, 2026 @05:31PM (#48665866)
I wrote the orignal draft, but used Claude to integrate some feedback. In hindsight, this was a mistake, and I will not do that again. Thanks for the frank feedback.

I'm glad Yocto is working for you.

I'm by no means a Yocto expert like many of you, but I've used OpenEmbedded/Yocto since the start, so I'm quite familiar with it. I started the following project, which Khem mostly maintains these days:

https://yoedistro.org/

Re:Is it time for a new Embedded Linux build system? on Wednesday June 24, 2026 @05:25PM (#48665822)
Thanks, I was not aware of this - will look into this more.
Re:Is it time for a new Embedded Linux build system? on Wednesday June 24, 2026 @05:19PM (#48665770)
https://yoebuild.org/faq/#is-yoe-created-with-ai

Yes, much of Yoe build is implemented using Claude Code, driven by specs.

Re:Is it time for a new Embedded Linux build system? on Wednesday June 24, 2026 @05:17PM (#48665750)
https://docs.yoebuild.org/comparisons.html#vs-bazel

Note, this is generated by Claude as I've not used Bazel and may not be 100% accurate. PR's welcome.

Re:Is it time for a new Embedded Linux build system? on Wednesday June 24, 2026 @05:15PM (#48665727)
There are several ways to compile for the target:

1) Cross compile. Yoe build still does this where it makes sense. (Go apps, likely kernel builds in the future) 2) QEMU user mode - 5-20x slow, but fine for some things. 3) Run yoe-build on any ARM machine (AWS, rPI5, Jetson) 4) Farm unit builds out to runners on cloud ARM machines. (future)

The yoe-build architecture allows for this. Choose the container, host architecture, and location that makes the most sense on a unit-by-unit basis.

Caching is also part of the vision, so we never rebuild something twice, unless it changes.

For me, it is a lot simpler to host at Linode (or simpler) than figure out the AWS/GCP crazy complex IAM stuff.

However, there are cases where being able to spin down the server, and not pay for downtime is useful - like 36-core Yocto build machines.

Re:Merlin Bird ID on Thursday June 05, 2025 @04:52PM (#44195670)
I tried this yesterday and set it up for my wife. I was amazed at how many birds it picked up. There must be some amazing technology in the audio processing.
When we want to advance something, we often need to simplify it first. Piling on layers of complexity will only get us so far — at times, we need to go back to ground zero and re-think things.

There are many ways to specify contracts between systems, such as APIs and schemas. A more fundamental contract focuses on a more granular unit of data. Points in an IoT system are like atoms in matter. A Node tree in an IoT system is like the DNA in a living organism. The composition of points and structure of nodes (like atoms and DNA) is infinitely flexible. It is this simplicity and flexibility that allows atoms and DNA to define so many different types of matter and species of organisms. It is time to throw out the custom struct as the defined unit of data between systems and focus on something more granular, flexible, and scalable.

Re:The Ability to Improve on Wednesday March 13, 2024 @09:13AM (#39690935)
If you don’t continually improve, you soon lose the ability to do so …

This article discusses how a culture of improvement is essential and provides compounding returns, several case studies, and ingredients for improvement.

Re:Why Open Source for Product Development on Monday December 04, 2023 @02:09PM (#38521633)
Some thoughts on why companies are turning to OSS for parts of their software stack.