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

311–320 of 343 posts

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

#311

Post by namibj »

jonstewart wrote: post #225
jama211 wrote: post #86

Earlier quoted context omitted.

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

Carpenters/framers are less skilled and paid less than cabinetmakers. But the world needs more carpenters.

While it sounds likely true for the US, it's the opposite in Germany: likely due to societal expectations on "creature comforts" and German homes not being framed with 2x4's but instead getting guild-approved craftsmen to construct a roof for a brick building (with often precast concrete slabs forming the intermediate floors; they're segmented along the non-bridging direction to be less customized).

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

#312

Post by player1234 »

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…

[dead]

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

#313

Post by player1234 »

bicx wrote: post #11
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 hav…

[dead]

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

#314

Post by neop1x »

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.

I fear of it hallucinating a shitty code which will introduce bugs and vulnerabilities.

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

#315

Post by dd_xplore »

fruitworks wrote: post #183
sedatk wrote: post #140

Off-topic, but I wish Linux had a stable ABI for loadable kernel modules. Obviously the kernel would have to provide shims for internal changes because internal ABI constantly evolves, so it would be costly and the drivers would probably run slower over time. Yet, having the ability to use a driver from 15 years ago can be a huge win at times. That kind of compatibility is one of the things I love about Windows.

I think this would be terrible for the driver ecosystem. I don't want to run 15 year old binary blob drivers because they technicially still work. Just get the source code published into mainline.

And publishing shitty code invites wrath from Linus

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

#316

Post by MrContent04 »

It’s fascinating to see LLMs breathe new life into legacy code. But I wonder — if AI rewrites outpace human review, are we just creating a new layer of technical debt? Maybe the real challenge is balancing modernization with long-term maintainability.

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

#317

Post by Chris2048 »

jazzyjackson wrote: post #100
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.

Yes and its why AI fills me with impending doom: handing over the reigns to an AI that can deal with the bullshit for us means we will get stuck in a groundhog day scenario of waking up with the same shitty architecture for the foreseeable future. Automation is the opposite of plasticity.

I find it more likely it will result in an influx of new architectures.

Eventually, prog-lang designers will figure out how to get llms to create new prog-langs.

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

#318

Post by Chris2048 »

tankenmate wrote: post #296
utyop22 wrote: post #167

Earlier quoted context omitted.

Go say this to a darts player who has hit a 9 darter….. Actually no wait let’s expand it. Why not go say this to Ronnie O’Sullivan too! The way you’re describing is such that there is no determinism behind what is being done. Simply not true.

a stochastic system can can deterministic sub-parts, a deterministic system cannot have stochastic sub-parts.

If we are talking in terms of IRL/physics, there is no such thing as a deterministic system outside of theory - everything is stochastic to differing degrees - including you brain that came up with these thoughts.

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

#319

Post by Chris2048 »

lukan wrote: post #150
tankenmate wrote: post #126

Earlier quoted context omitted.

I have a strong suspicion that the world is not as deterministic as you'd like it to be.

Or it is deterministic, but infinitely complex, so that also leaves us only with stochastic.

stochastic vs deterministic is arguable a property of modelling, not reality.

Something so complex that we cannot model it as deterministic is hence stochastic. We can just as easily model a stochastic thing by ignoring the stochastic parts.

separating subjective appearance of things from how we can conceptualise them as models begs a deeper philosophical question of how you can talk about the nature of things you cannot perceive.

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

#320

Post by bicx »

jazzyjackson wrote: post #100
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.

Yes and its why AI fills me with impending doom: handing over the reigns to an AI that can deal with the bullshit for us means we will get stuck in a groundhog day scenario of waking up with the same shitty architecture for the foreseeable future. Automation is the opposite of plasticity.

Maybe if you fully hand over the reigns and go watch Youtube all day.

LLMs allow us to do large but cheap experiments that we would never attempt otherwise. That includes new architectures. Automation in the traditional sense is opposite of plasticity (because it's optimizing and crystalizing around a very specific process), but what we're doing with LLMs isn't that. Every new request can be different. Experiments are more possible, not less. We don't have to tear down years of scaffolding like old automated systems. We just nudge it in a new direction.

Post reply on HN