Is Claude code better than ChatGPT?
Using Claude Code to modernize a 25-year-old kernel driver
131–140 of 343 posts
Re: Using Claude Code to modernize a 25-year-old kernel driver
#132I had a suspicion AI would lower the barrier to entry for kernel hacking. Glad to see it's true. We could soon see much wider support for embedded/ARM hardware. Perhaps even completely new stripped-down OSes for smart devices.
>new stripped-down OSes for smart devices.
What's wrong with exist one?
Re: Using Claude Code to modernize a 25-year-old kernel driver
#133Is Claude code better than ChatGPT?
In my experiments claude4 opus generated by far the best code (for my taste and purposes) but it's also a pretty expensive model. I think I used up $40 in one evening of frantic vibe-coding.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#134A good case study. I have found these two to be good categories of win: > Use these tools as a massive force multiplier of your own skills. Claude definitely makes me more productive in frameworks I know well, where I can scan and pattern-match quickly on the boilerplate parts. > Use these tools for rapid onboarding onto new frameworks. I’m also more productive here, this is an enabler to explore new areas, and is al…
For me is not so. It makes me way faster in languages that I don't know, but makes me slower on the ones I know because a lot of times, it creates code that will fail eventually.
Then I need to expend extra time following everything it did so I can "fix" the problem.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#135> so I loaded the module myself, and iteratively pasted the output of dmesg into Claude manually, One of the things that has Claude as my goto option is its ability to start long-running processes, which it can read the output of to debug things. There are a bunch of hacks you could have used here to skip the manual part, like piping dmesg to a local udp port and having Claude start a listener.
I think that's the thing holding a lot of coders back on agentic coding, these little tricks are still hard to get working. And that feedback loop is so important.
Even something simple like getting it to run a dev server in react can have it opening multiple servers and getting confused. I've watched streams where the programmer is constantly telling it to use an already running server.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#136Earlier quoted context omitted.
This is more of a reflection of how our profession has not meaningfully advanced. OP talks about boilerplate. You talk about grunt work. We now have AI to do these things for us. But why do such things need to exist in the first place? Why hasn't there been a minimal-boilerplate language and framework and programming environment? Why haven't we collectively emphasized the creation of new tools to reduce boilerplate a…
This is the glaring fallacy! We are turning to unreliable stochastic agents to churn out boilerplate and do toil that should just be abstracted or automated away by fully deterministic, reliably correct programs. This is, prima facie, a degenerative and wasteful way to develop software.
I guess this is probably what Lucifer said to God about why it was stupid to give humans free will.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#137Earlier quoted context omitted.
This is the glaring fallacy! We are turning to unreliable stochastic agents to churn out boilerplate and do toil that should just be abstracted or automated away by fully deterministic, reliably correct programs. This is, prima facie, a degenerative and wasteful way to develop software.
Saying boilerplate shouldn’t exist is like saying we shouldn’t need nails or screws if we just designed furniture to be cut perfectly as one piece from the tree. The response is “I mean, sure, that’d be great, not sure how you’ll actually accomplish that though”.
Love this analogy.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#138pipe dream - now automate Asahi development to M3, M4, and onwards.
the problem here is that Apple, while at least not standing actively in the way (like console manufacturers), provides zero documentation on how stuff works internally. You gotta reverse-engineer everything, and that either takes at least a dozen highly qualified and thus rare and expensive-to-hire people or someone hard on the autism-hyperfixation spectrum with lots of free time to spare and/or the ability to turn it into an academic project. AI can't help at all here because even if it were able to decompile Apple's driver code, it would not be able to draft a coherent mental model on how things work.
M3, to answer the second part why AI won't be of much help, onwards use a massively different GPU architecture that needs to be worked out, again, from scratch. And all of that while there is a substantial number of subsystems remaining on M1, M2 and its variants that aren't supported at all, only partially supported or with serious workarounds, or where the code quality needs massive work to get upstreamed into Linux.
And on top of that, a number of contributors burned out along the way, some from dealing with the ultra-neckbeard faction amongst Linux kernel developers, some from other mental health issues, and Alyssa departed for Intel recently.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#139Earlier quoted context omitted.
When humans are in the loop everything pretty much becomes stochastic as well. What matters more is the error rate and result correctness. I think this shifts the focus towards test cases, measurement, and outcome.
No. This is a fundamentally erroneous analogy. We don't generate code by a stochastic process.
Everything we do is a stochastic process. If you throw a dart 100 times at a target, it's not going to land at the same spot every time. There is a great deal of uncertainty and non-deterministic behavior in our everyday actions.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#140Off-topic, but I wish Linux had a stable ABI for loadable kernel modules. Obviously the kernel would have to provide shims for internal changes because internal ABI constantly evolves, so it would be costly and the drivers would probably run slower over time. Yet, having the ability to use a driver from 15 years ago can be a huge win at times. That kind of compatibility is one of the things I love about Windows.