Using Claude Code to modernize a 25-year-old kernel driver • Hacker News Board

Re: Using Claude Code to modernize a 25-year-old kernel driver

#251

Post by ok123456 » Mon, Sep 08, 2025, 2:27 PM UTC

rmoriz wrote: post #56

I was banned from an OpenSource project [1] recently because I suggested a bug fix. Their „code of conduct“ not only prevents PRs but also comments on issues with information that was retrieved by any AI tool or resource. Thinking about asking Claude to reimplement it from scratch in Rust… [1] https://codeberg.org/superseriousbusiness/gotosocial/src/bra...

"You used AI!" is now being weaponized by project maintainers who don't want to accept contributions, regardless of how innocuous.

A large C++ emulator project was failing to build with a particular compiler with certain Werror's enabled. It came down to reordering a few members (that matters in C++) and using the universal initializer syntax in a few places. It was a +3-3 diff. I got lambasted. One notoriously hostile maintainer accused me of making AI slop. The others didn't understand why the order mattered and referred to it as "churn."

Re: Using Claude Code to modernize a 25-year-old kernel driver

#252

Post by criticalfault » Mon, Sep 08, 2025, 2:29 PM UTC

Would be good to do the same to 'modernize' disassembled drivers for various devices in mobile phones.

Would give postmarketos a boost.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#253

Post by scotty79 » Mon, Sep 08, 2025, 2:31 PM UTC

codedokode wrote: post #240

scotty79 wrote: post #182

Earlier quoted context omitted.

> I have to do it manually every time. You can tell it to move it and they'll move it and use this shared code from now on.

Sometimes it seems like explaining what I want could take more time than actually editing the code. For example, imagine if you test a vector-like collection. In every test case dumb LLM creates vector manually and makes inserts/deletes. It could be replaced by adding a helper function that accepts a sequence of operations and returns the processed vector. Furthermore, once you have that function, you can merge multi…

Try something like:

"Don't create vector manually inline in every test case, make a helper function for that."

and see what agent does. It might do something smart. It might do something a bit dumb but by understanding why exactly it's dumb, you can communicate what correction is needed pretty smoothly.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#254

Post by philsnow » Mon, Sep 08, 2025, 2:32 PM UTC

jama211 wrote: post #86

abathologist wrote: post #37

Earlier 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”.

Even Star Trek has self-sealing stem bolts, they don't just 3d print their ships

Re: Using Claude Code to modernize a 25-year-old kernel driver

#255

Post by wg0 » Mon, Sep 08, 2025, 2:34 PM UTC

piskov wrote: post #249

antonvs wrote: post #244

Earlier quoted context omitted.

You've misunderstood the study that you linked. LLMs certainly memorize, and this can certainly skew benchmarks, but that's not all they do. Anyone with experience with LLMs will have experienced their actual problem solving ability, which is often impressive. You'd be better off learning to use them, than speculating without basis about why they won't work.

What exactly did I misunderstand? Also “learn to use them” feels you’re holding it wrong vibes. See also https://machinelearning.apple.com/research/illusion-of-think...

You did not misunderstand anything. Sure, LLMs have no cognitive abilities. So even with widely used languages, they do hit the wall and need lots of hand holding.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#256

Post by kccqzy » Mon, Sep 08, 2025, 2:35 PM UTC

kwanbix wrote: post #67

kccqzy wrote: post #30

Earlier 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…

It used to be. When I learned to program for windows, I will basically learn Delphi or Visual basic at the time. Maybe some database like paradox. But I was reading a website that lists the skills needed to write backend ant it was like 30 different things to learn.

That's exactly what I have in mind when I wrote the original comment. I learned Visual Basic as a kid faffing around a computer and it was so little boilerplate to make an app. It's been a regression since the.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#257

Post by bcrosby95 » Mon, Sep 08, 2025, 2:38 PM UTC

rmoriz wrote: post #147

baq wrote: post #124

Earlier quoted context omitted.

In a startup, especially early, the only thing that isn't optional is shipping. You can fix any and all issues later, first you have to ensure there is a 'later'. (That's not to say you shouldn't do it at all, but definitely focus on the business before the tech.)

I‘ve been with a couple of startups that shipped and not a single one was cutting corners in this area anymore. Last time I saw this was probably around 2005-2008.

Cutting corners here is one of the worst decisions you can make. Especially in an environment where you don't know your end product and you're likely to rework your code over and over and over again.

Piling shit on top of shit only pays off on very short time scales - like a month or two. Because once you revisit that shit code all your time savings are out the window. If you have to revisit it more than once you probably slowed yourself down already.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#258

Post by davidw » Mon, Sep 08, 2025, 2:41 PM UTC

theptip wrote: post #3

A 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…

I'm feeling quite wary of the fact that if it's a real productivity booster, it's all in the hands of one company. Perhaps some of the others will be able to compete with it, but: still all big corporations.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#259

Post by rmoriz » Mon, Sep 08, 2025, 2:48 PM UTC

skydhash wrote: post #230

rmoriz wrote: post #83

Earlier quoted context omitted.

The bugs are on them. I‘ve fixed them in my fork but of course I‘ll migrate to a non-discriminating alternative.

Your fork works, so why are you so unhappy? You can always publish you diff to help other people if you really want to do so.

I don‘t want others to get trappend, hence I‘ve unpublished my fixes. I‘ll also migrate to another software as I clearly have no time dealing with such exclusive politics. There is no point in discussing with stubborn and brain-washed people, the only solution is to move forward and warn others.

That’s the reason I posted my comment.

Re: Using Claude Code to modernize a 25-year-old kernel driver

#260

Post by Keyframe » Mon, Sep 08, 2025, 2:57 PM UTC

mschuster91 wrote: post #138

Keyframe wrote: post #53

pipe 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…

You mean to tell me those agents aren't PhD-level experts in every field as we were told by OpenAI?? I'm shocked!

Seriously though, it does seem a menial task in itself to reverse engineer what's going on. Would be a really powerful show of force by one of leading AI providers if they setup shop like that to do it in the open.. if they could.