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

191–200 of 343 posts

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

#191

Post by jillesvangurp »

I think this is illustrative of the kind of productive things you can do with an LLM if you know what you are doing. Is it perfect, no. Can they do useful things if you prompt correctly, absolutely. It helps knowing what you are doing and having enough skill to make good judgment calls yourself.

There are currently multiple posts per day on HN that escalate into debates on LLMs being useful or not. I think this is a clear example that it can be. And results count. Porting and modernizing some ancient driver is not that easy. There's all sorts of stuff that gets dropped from the kernel because it's just too old to bother maintaining it and when nobody does, deleting code becomes the only option. This is a good example. I imagine, there are enough crusty corners in the kernel that could benefit from a similar treatment.

I've had similar mixed results with agentic coding sometimes impressing me and other times disappointing me. But if you can adapt to some of these limitations it's alright. And this seems to be a bit of a moving goalpost thing as well. Things that were hard a few months ago are now more doable.

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

#192

Post by peteforde »

not_that_d wrote: post #134
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…

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.

My daily experience suggests that this happens primarily when the developer isn't as good as they assume that they are at expressing the ideas in their head into a structure that the LLM can run with. That's not intended to be a jab, just an opportunity for reflection.

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

#193

Post by fruitworks »

DrNosferatu wrote: post #187
fruitworks wrote: post #181

Earlier quoted context omitted.

If we allow it

If it delivers what we need, isn't it a net positive? And clearly define what we need with specs and thorough tests.

Do we need code generated from a stochastic model of previous code? I think we need actual people who are familiar with the kernel and hardware and are capable of reasoning about it.

We are constantly reminded that LLMs are the future despite the real world evidence to the contrary. Look at what happens when LLMs are trained on the output of other LLMs, such as the low quality code flooding the internet. It is all a self-solving problem set in motion.

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

#194

Post by jay-barronville »

elzbardico wrote: post #101
jclarkcom wrote: post #72

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

I think that both of you are right to some extent.

It’s undeniable that humans exhibit stochastic traits, but we’re obviously not stochastic processes in the same sense as LLMs and the like. We have agency, error-correction, and learning mechanisms that make us far more reliable.

In practice, humans (especially experts) have an apparent determinism despite all of the randomness involved (both internally and externally) in many of our actions.

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

#195

Post by d4rkp4ttern »

> using these tools as a massive force multiplier…

Even before tools like CC it was the case that LLMs enabled venturing into projects/areas that would be intimidating otherwise. But Claude-Code (and codex-cli as of late) has made this massively more true.

For example I recently used CC to do a significant upgrade of the Langroid LLM-Agent framework from Pydantic V1 to V2, something I would not have dared to attempt before CC:

https://github.com/langroid/langroid/releases/tag/0.59.0

I also created nice collapsible html logs [2] for agent interactions and tool-calls, inspired by @badlogic/Zechner’s Claude-trace [3] (which incidentally is a fantastic tool!).

[2] https://github.com/langroid/langroid/releases/tag/0.57.0

[3] https://github.com/badlogic/lemmy/tree/main/apps/claude-trac...

And added a DSL to specify agentic task termination conditions based on event-sequence patterns:

https://langroid.github.io/langroid/notes/task-termination/

Needless to say, the docs are also made with significant CC assistance.

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

#196

Post by skydhash »

TheDong wrote: post #105
dymk wrote: post #94

Earlier quoted context omitted.

What boilerplate is there in rails?

html is like 90% boilerplate, and so .html.erb in rails is mostly boilerplate.

We have the component architecture pattern to reduce the amount of html we have to write. If you’re duplicating html element in every page, that’s mostly on you. There’s a reason every template language have include statement. That’s a problem that’s been solved for ages.

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

#197

Post by peteforde »

rvz wrote: post #28
tedk-42 wrote: post #17

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 :)

> 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. You would certainly need an expert to make sure your air traffic control software is working correctly and not 'vibe coded' the next time you decide to travel abroad safely. We don't need a new generation who can't read code and are heavily reliant on whatever a chat bot said…

Have you ever read David Graeber's Bullshit Jobs? Because if not, you really should.

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

#198

Post by jay-barronville »

jxf wrote: post #139
elzbardico wrote: post #101

Earlier quoted context omitted.

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.

As much as it’s true that there’s stochasticity involved in just about everything that we do, I’m not sure that that’s equivalent to everything we do being a stochastic process. With your dart example, a very significant amount of the stochasticity involved in the determination of where the dart lands is external to the human thrower. An expert human thrower could easily make it appear deterministic.

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

#199

Post by skydhash »

lenkite wrote: post #143
zipzapzip wrote: post #111

Earlier quoted context omitted.

Because of the obsession with backwards compatibility and not breaking code. The web development industry is the prime example. HTML, Javascript, CSS, a backend frontend architecture - absolutely terrible stack.

I don't even know why things like templating and inclusion are not just part of the core web stack (ideally declaratively with no JS). There should be no need for an external tool or build process or third-party framework.

Html is rendered document. It’s ok to write it if you only need one document, but it’s better to use an actual template language or some generators if you’re going to have the same layout and components for many pages.

You’re asking to shift this job from the editor (you) to the viewer (the browser).

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

#200

Post by undebuggable »

IshKebab wrote: post #166

> From this point forward, since loading/unloading kernel modules requires sudo, I could no longer let Claude “iterate” on such sensitive operations by itself. Hilarious! https://xkcd.com/1200/

Imagine the horror when a random stranger finally installs and sets up that bloody printer on your laptop.
Post reply on HN