Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dmitrybrant.com

Post reply on HN
Print view View original

51–60 of 343 posts

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

#51

Post by travisgriggs »

kccqzy wrote: post #30
bicx wrote: post #11

Earlier quoted context omitted.

This is a good takeaway. I use Claude Code as my main approach for making changes to a codebase, and I’ve been doing so every day for months. I have a solid system I follow through trial and error, and overall it’s been a massive boon to my productivity and willingness to attempt larger experiments. One thing I love doing is developing a strong underlying data structure, schema, and internal API, then essentially hav…

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…

My take: money. Years ago, when I was cutting my teeth in software, efficiency was a real concern. Not just efficiency for limited CPU, memory, and storage. But also how you could maximize the output of smaller head count of developers. There was a lot of debate over which methodologies, languages, etc, gave the biggest bang for buck.

And then… that just kind of dropped out of the discussion. Throw things at the wall as fast as possible and see what stuck, deal with the consequences later. And to be fair, there were studies showing that choice of language didn’t actually make as big of difference as found in the emotions behind the debates. And then the web… committee designed over years and years, with the neve the ability to start over. And lots of money meant that we needed lots of manager roles too. And managers elevate their status by having more people. And more people means more opportunity for specializations. It all becomes an unabated positive feedback loop.

I love that it’s meant my salary has steadily climbed over the years, but I’ve actually secretly thought it would be nice if there was bit of a collapse in the field, just so we could get back to solid basics again. But… not if I have to take a big pay cut. :)

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

#52

Post by AdieuToLogic »

Something not yet mentioned by other commenters is the "giant caveat":

  As a giant caveat, I should note that I have a small bit of 
  prior experience working with kernel modules, and a good 
  amount of experience with C in general, so I don’t want to 
  overstate Claude’s success in this scenario. As in, it 
  wasn’t literally three prompts to get Claude to poop out a 
  working kernel module, but rather several back-and-forth 
  conversations and, yes, several manual fixups of the code. 
  It would absolutely not be possible to perform this 
  modernization without a baseline knowledge of the internals 
  of a kernel module.
Of note is the last sentence:

  It would absolutely not be possible to perform this 
  modernization without a baseline knowledge of the internals 
  of a kernel module.
This is critical context when using a code generation tool, no matter which one chosen.

Then the author states in the next section:

  Interacting with Claude Code felt like an actual 
  collaboration with a fellow engineer. People like to 
  compare it to working with a “junior” engineer, and I think 
  that’s broadly accurate: it will do whatever you tell it to 
  do, it’s eager to please, it’s overconfident, it’s quick to 
  apologize and praise you for being “absolutely right” when 
  you point out a mistake it made, and so on.
I don't know what "fellow engineers" the author is accustomed to collaborating with, junior or otherwise, but the attributes enumerated above are those of a sycophant and not any engineer I have worked with.

Finally, the author asserts:

  I’m sure that if I really wanted to, I could have done this 
  modernization effort on my own. But that would have 
  required me to learn kernel development as it was done 25 
  years ago.
This could also be described as "understanding the legacy solution and what needs to be done" when the expressed goal identified in the article title is:

  ... modernize a 25-year-old kernel driver
Another key activity identified as a benefit to avoid in the above quote is:

  ... required me to learn ...

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

#54

Post by yeasku »

squeakywhite wrote: post #48
yeasku wrote: post #41

Earlier quoted context omitted.

[flagged]

If you are eating the baked shit and enjoying it, and a subset of shit-eaters might also like your baked shit recipe, then yes - it would be wrong to say "nobody will eat that shit". I suspect HN readers won't see enough value in your baked shit recipe for it to reach the front page - sorry. But bake away!

[flagged]

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

#55

Post by marcus_holmes »

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…

>> Use these tools for rapid onboarding onto new frameworks.

Also new languages - our team uses Ruby, and Ruby is easy to read, so I can skip learning the syntax and get the LLM to write the code. I have to make all the decisions, and guide it, but I don't need to learn Ruby to write acceptable-level code [0]. I get to be immediately productive in an unfamiliar environment, which is great.

[0] acceptable-level as defined by the rest of the team - they're checking my PRs.

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

#56

Post by rmoriz »

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

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

#57

Post by yeasku »

anyfoo wrote: post #47
yeasku wrote: post #41

Earlier quoted context omitted.

[flagged]

Why do you call what the author did shit? It is resurrecting an old tape driver for archival purposes. It may not have much commercial use, but anyone having those old tapes will appreciate it.

[flagged]

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

#59

Post by measurablefunc »

Brendinooo wrote: post #13

When I read an article like this it makes me think about how the demand for work to be done was nowhere close to being fully supplied by the pre-LLM status quo.

It's never about lack of work but lack of people who have the prerequisite expertise to do it. If you don't have experience w/ kernel development then no amount of prompting will get you the type of results that the author was able to achieve. More specifically, in theory it should be possible to take all the old drivers & "modernize" them to carry them forward into each new version of the kernel but the problem is that none of the LLMs are capable of doing this work w/o human supervision & the number of people who can actually supervise the LLMs is very small compared to the amount of unmaintained drivers that could be ported into newer kernels.

There is a good discussion/interview¹ between Alan Kay & Joe Armstrong about how most code is developed backwards b/c none of the code has a formal specification that can be "compiled" into different targets. If there was a specification other than the old driver code then the process of porting over the driver would be a matter of recompiling the specification for a new kernel target. In absence of such specification you have to substitute human expertise to make sure the invariants in the old code are maintained in the new one b/c the LLMs has no understanding of any of it other than pattern matching to other drivers w/ similar code.

¹https://www.youtube.com/watch?v=axBVG_VkrHI

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

#60

Post by rmoriz »

AdieuToLogic wrote: post #52

Something not yet mentioned by other commenters is the "giant caveat": As a giant caveat, I should note that I have a small bit of prior experience working with kernel modules, and a good amount of experience with C in general, so I don’t want to overstate Claude’s success in this scenario. As in, it wasn’t literally three prompts to get Claude to poop out a working kernel module, but rather several back-and-forth co…

Gatekeeping is toxic. I love agents explaining me projects I don‘t know. Recently I cloned sources of Firefox and asked qwen-code (tool not significant) about the AI features of Firefox and how it‘s implemented. Learning has become awesome.
Post reply on HN