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

261–270 of 343 posts

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

#261

Post by encom »

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

That particular CoC is a colossal red flag that the maintainers are utterly deranged. This might actually be the worst CoC I've ever seen. Any CoC is a red flag, but people often get pressured into it, so it's a sliding scale.

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

#262

Post by rmoriz »

bcrosby95 wrote: post #257
rmoriz wrote: post #147

Earlier quoted context omitted.

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

And you can add an AI code agent (Copilot, Opencode, Claude) to the workflow just to deal with failing tests, automatically create PRs to fix the issues. It may boost the productivity a lot doing housekeeping while coding manually.

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

#263

Post by emilecantin »

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…

One area where it really shines for me is personal projects. You know, the type of projects you might get to spend a couple hours on once the kids are in bed... Spending that couple hours guiding Claude do do what I want is way quicker than doing it all myself. Especially since I do have the skills to do it all myself, just not the time. It's been particularly effective around UI stuff since I've selected a popular UI library (MUI) but I don't use it in my day job; I had to keep looking up documentation but Claude just bangs it out very easily.

One thing where it hasn't shone is configuring my production deployment. I had set this project up with a docker-compose, but my selected CI/CD (Gitlab) and my selected hosting provider (DigitalOcean) seemed to steer me more towards Kubernetes, which I don't know anything about. Gitlab's documentation wanted me to setup Flux (?) and at some point referred to a Helm chart (?)... All words I've heard but their documentation is useless to newcomers ("manage containers in production!": yes, that's obviously what I'm trying to do... "Getting started: run this obscure command with 5 arguments": wth is this path I need to provide? what's this parameter? etc.) I honestly can't believe how complex the recommended setup is, to ultimately run 2 containers that I already have defined in ~20 lines of docker-compose...

Claude got me through it. Took it about 5-6 hours of trying stuff, build failing, trying again. And even then, it still doesn't deploy when I push. It builds, pushes the new container images, and spins up a new pod... which it then immediately kills because my older one is still running and I only want one pod running... Oh well, I'll just keep killing the old pod until I have some more energy to throw at it to try and fix it.

TL;DR: it's much better at some things than others.

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

#264

Post by 0xbadcafebee »

mrheosuper wrote: post #132
0xbadcafebee wrote: post #5

I 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?

The popular OSes/kernels are too bloated and don't have wide embedded support (and porting to new devices takes considerable time), and the few free embedded OSes don't have much traction (and aren't used on more powerful platforms). Would be nice to have a middle ground.

For example, FreeRTOS doesn't support 64-bit intel arch. And you don't "ship an app on FreeRTOS", it's more of an API and framework you use, and you sort of write a module in C and compile one big app. Quite different from non-embedded app design/shipping. You won't be able to run an Android app on an ESP32, but it should be possible to write apps for ESP32 and run them on Android-compatible hardware. But FreeRTOS would need optional MMU support, and you'd need extra components to load the app, in addition to hardware support.

If you're asking "why would you do that", it's because I want to write simple purpose-built apps without all the trappings of a larger OS and run them on all types of hardware. You could technically build a 'smart watch' that isn't so smart but runs on a single battery charge for 1 year. But not if you use a power-hungry SoC. Want a more efficient SoC? Good luck figuring that out. Making that whole process easier unlocks more technical solutions and products.

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

#265

Post by lukaslalinsky »

I mainly use Claude Code for things I know, where I just don't want to focus on the coding part. However, I recently found a very niche use. I have a small issue with an open source project. Instead of just accepting it, it occurred to me I can just clone the repo, and ask CC to look into my issue. For example, I was annoyed with Helix/Zed that replacing parameter in Zig code only works for function declarations, not function calls. I suspected it will be in the tree-sitter grammar, but I let it go through the Zed source code, then it asked for the grammar, so I cloned it and gave it access to that, and it happily fixed the grammar for me and tested the results. It needed a few nudges to make the fix properly, but I spent maybe 5 minutes on this, while CC was probably working for half an hour. I even had it fork the repo, and open the PR for me. In the end I have an useful change that people will benefit from, that I'd never attempt myself.

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

#266

Post by seba_dos1 »

rmoriz wrote: post #102
nine_k wrote: post #31

Earlier quoted context omitted.

Yes. The author essentially asked Claude to port a driver from Linux 2.4 to Linux 6.8. Very certainly there must be sufficient amounts of training material, and web-searchable material, that describes such tasks. The author provided his own expertise where Claude could not find a good analogue in the training corpus, that is, the few actually non-trivial bits of porting. "Use these tools as a massive force multiplier…

You can still ask, generate a list of things to learn etc. basically generate a streamlined course based on all tutorials, readmes and source code available when the model was trained. You can call your tutor 24/7 as long as you got tokens.

You have to keep guard at each step to notice the inconsistencies and call your tutor's mistakes out though, or you'll inevitably learn some garbage. This is a use case that certainly "feels" like it's boosting your learning (it sure does to me), but I'd like to read an actual study on whether it really does before reaching any conclusions.

It seems to me that LLMs help the most at the initial step of getting into some rabbit hole - when you're getting familiar with the jargon, so you can start reading some proper resources without being confused too much. The sooner you manage to move there, the better.

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

#267

Post by driverdan »

jabl wrote: post #103

Blast from the past! When I was a kid we had such a floppy tape device connected to a 386 or 486 computer my parents had. I think it was a Colorado Jumbo 250. I think the actual capacity was 125MB, but the drive or the backup software had some built-in compression, hence why it was marketed as a 250MB drive. Never tried to use it with the Linux ftape driver, though. It wouldn't surprise me if the drive and the tapes…

I've been trying to remember the tape drive we had on our 486 when I was a kid and that's it. Thank you!

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

#268

Post by driverdan »

sreekanth850 wrote: post #64
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...

/ Suddenly i saw this: //Update regarding corporate sponsors: we are open to sponsorship arrangements with organizations that align with our values; see the conditions below.// They should know that beggars cant be choosers.

It's pretty funny that they say "We are not interested in input from right-wingers, nazis, ... or capitalists." and then say they're open to corporate sponsorships. If they want to be consistent they'd only be open to government or individual sponsors, not corps.

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

#269

Post by DrewADesign »

pjc50 wrote: post #159
DrewADesign wrote: post #77

Earlier quoted context omitted.

[flagged]

Conversely, if the only motivation is profit, that's no ethics at all. (and of course without non-profit motivations, none of the open source ecosystem would exist!)

Yeah that’s what I was getting at

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

#270

Post by jcelerier »

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…

> Why hasn't there been a minimal-boilerplate language and framework and programming environment

Because everyone needs a boilerplate but it's a different boilerplate for everyone unless you're doing the most basic toy apps

Post reply on HN