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

11–20 of 343 posts

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

#11

Post by bicx »

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…

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 having CC often one-shot a great UI for internal tools.

Being able to think at a higher level beyond grunt work and framework nuances is a game-changer for my career of 16 years.

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

#14

Post by anyfoo »

unethical_ban wrote: post #6
anyfoo wrote: post #4

Earlier quoted context omitted.

... which would allow you to load arbitrary code into the kernel, pretty much bypassing any and all security. You might as well not have a password at all. Which, incidentally, can be a valid strategy for isolated external dev boards, or QEMU VMs. But on a machine with stuff you care about? You're basically ripping it open.

He was already loading "arbitrary" Claude code, no? I'm suggesting there was a way to skip password entry by narrowly tailoring an exception. Another thought, IIRC in the plugins for Claude code in my IDE, you can "authorize" actions and have manual intervention without having to leave the tool. My point is there were ways I think they could have avoided copy/paste.

While I personally would have used a dedicated development target, the workflow he had at least allowed him to have a good look at any and all code changes, before approving with the root password.

That is a bit different than allowing unconfirmed loading of arbitrary kernel code without proper authentication.

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

#16

Post by rvz »

No tests whatsoever. This isn't getting close to being merged into mainline and it will stay out-of-tree for a long time.

That's even before taking on the brutal linux kernel mailing lists for code review explaining what that C code does which could be riddled with bugs that Claude generated.

No thanks and no deal.

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

#17

Post by tedk-42 »

Really is an exciting future ahead. So many lost arts that don't need a dedicated human to relearn deep knowledge required to make an update.

A reminder though these LLM calls cost energy and we need reliable power generation to iterate through this next tech cycle.

Hopefully all that useless crypto wasted clock cycle burn is going to LLM clock cycle burn :)

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

#18

Post by yeasku »

rvz wrote: post #16

No tests whatsoever. This isn't getting close to being merged into mainline and it will stay out-of-tree for a long time. That's even before taking on the brutal linux kernel mailing lists for code review explaining what that C code does which could be riddled with bugs that Claude generated. No thanks and no deal.

[flagged]

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

#19

Post by [deleted] »

rvz wrote: post #16

No tests whatsoever. This isn't getting close to being merged into mainline and it will stay out-of-tree for a long time. That's even before taking on the brutal linux kernel mailing lists for code review explaining what that C code does which could be riddled with bugs that Claude generated. No thanks and no deal.

[deleted]

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

#20

Post by geor9e »

rvz wrote: post #16

No tests whatsoever. This isn't getting close to being merged into mainline and it will stay out-of-tree for a long time. That's even before taking on the brutal linux kernel mailing lists for code review explaining what that C code does which could be riddled with bugs that Claude generated. No thanks and no deal.

"The intention is to compile this driver as an out-of-tree kernel module, without needing to copy it into the kernel source tree. That's why there's just a simple Makefile, and no other affordances for kernel inclusion. I can't really imagine any further need to build this driver into the kernel itself.

The last version of the driver that was included in the kernel, right up until it was removed, was version 3.04.

BUT, the author continued to develop the driver independently of kernel releases. In fact, the last known version of the driver was 4.04a, in 2000.

My goal is to continue maintaining this driver for modern kernel versions, 25 years after the last official release." - https://github.com/dbrant/ftape

Post reply on HN