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

71–80 of 343 posts

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

#71

Post by wyager »

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?

Haskell mostly solves boilerplate in a typed way and Lisp mostly solves it in an untyped way (I know, I know, roughly speaking).

To put it bluntly, there's an intellectual difficulty barrier associated with understanding problems well enough to systematize away boilerplate and use these languages effectively.

The difficulty gap between writing a ton of boilerplate in Java and completely eliminating that boilerplate in Haskell is roughly analogous to the difficulty gap between bolting on the wheels at a car factory and programming a robot to bolt on the wheels for you. (The GHC compiler devs might be the robot manufacturers in this analogy.) The latter is obviously harder, and despite the labor savings, sometimes the economics of hiring a guy to sit there bolting on wheels still works out.

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

#72

Post by jclarkcom »

abathologist wrote: post #37
kccqzy wrote: post #30

Earlier quoted context omitted.

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…

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.

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.

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

#73

Post by AdieuToLogic »

marcus_holmes wrote: post #55
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 def…

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

If Ruby is "easy to read" and assuming you know a similar programming language (such as Perl or Python), how difficult is it to learn Ruby and be able to write the code yourself?

> ... but I don't need to learn Ruby to write acceptable-level code [0].

Since the team you work with uses Ruby, why do you not need to learn it?

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

Ah. Now I get it.

Instead of learning the lingua franca and being able to verify your own work, "the rest of the team" has to make sure your PR's will not obviously fail.

Here's a thought - has it crossed your mind that team members needing to determine if your PR's are acceptable is "a bad thing", in that it may indicate a lack of trust of the changes you have been introducing?

Furthermore, does this situation qualify as "immediately productive" for the team or only yourself?

EDIT:

If you are not a software engineer by trade and instead a stakeholder wanting to formally specify desired system changes to the engineering team, an approach to consider is authoring RSpec[0] specs to define feature/integration specifications instead of PR's.

This would enable you to codify functional requirements such that their satisfaction is provable, assist the engineering team's understanding of what must be done in the context of existing behavior, identify conflicting system requirements (if any) before engineering effort is expended, provide a suite of functional regression tests, and serve as executable documentation for team members.

0 - https://rspec.info/features/6-1/rspec-rails/feature-specs/fe...

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

#74

Post by wyager »

do_not_redeem wrote: post #44
anyfoo wrote: post #39

Earlier quoted context omitted.

Because people think learning Haskell is too hard.

Haskell isn't immune to boilerplate. Luckily if you're stuck using Haskell there's a package to help you deal with it all: https://hackage.haskell.org/package/boilerplate

It's very minimal-boilerplate. It's done an exceptional job of eliminating procedural, tedious work, and it's done it in a way that doesn't even require macros! "Template Haskell" is Haskell's macro system and it's rarely used anymore.

These days, people mostly use things like GHC.Generics (generic programming for stuff like serialization that typically ends up being free performance-wise), newtypes and DerivingVia, the powerful and very generalized type system, and so on.

If you've ever run into a problem and thought "this seems tedious and repetitive", the probability that you could straightforwardly fix that is probably higher in Haskell than in any other language except maybe a Lisp.

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

#75

Post by brainless »

Empowering people is a lovely thing.

Here the author has a passion/side project they have been on for a while. Upgrading the tooling is a great thing. Community may not support this since the niche is too narrow. LLM comes in and helps in the upgrade. This is exactly what we want - software to be custom - for people to solve their unique edge cases.

Yes author is technical but we are lowering the barrier and it will be lowered even more. Semi technical people will be able to solve some simpler edge cases, and so one. More power to everyone.

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

#76

Post by DrewADesign »

measurablefunc wrote: post #59
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 t…

AI doesn’t need to replace a specialist in their entirety for it to tank demand for a skill. If the people that currently do the work are significantly more productive, fewer people will be necessary to the same amount of work. Then, people trying to escape obsolescence in different, more popular specialties move into the niche ones. You could easily pass the threshold of having less work than people without having replaced a single specialist.

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

#77

Post by DrewADesign »

lordhumphrey wrote: post #69
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...

> 2. We will not accept changes (code or otherwise) created with the aid of "AI" tooling. "AI" models are trained at the expense of underpaid workers filtering inputs of abhorrent content, and does not respect the owners of input content. Ethically, it sucks. Do you disagree with some part of the statement regarding "AI" in their CoC? Do you think there's a fault in their logic, or do you yourself personally just not…

[flagged]

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

#79

Post by petesergeant »

SV_BubbleTime wrote: post #70
meander_water wrote: post #63

> Be as specific as possible, making sure to use the domain-specific keywords for the task. If you don't have the technical understanding of a language or framework, there is going to be a lot of ambiguity in your prompts. This specificity gap leads the LLM to fill in those gaps for you, which may not be what you intended. And that's usually where bugs hide. I think this is the flip side to being a "force multiplier"

“I need a C class that has a constructor for a tuple” I would hope Claude would be like “Hold on man…”

> I need a C class that has a constructor for a tuple

| I'll create a simple C++ class with a constructor that takes a tuple. Here's an example...

> nah C

| C doesn't have classes or constructors - those are C++ features. In C, you would use a struct and create an initialization function. Here's how you'd handle a tuple-like structure:

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

#80

Post by giancarlostoro »

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.

If used correctly it can help you get up to speed quicker, sadly most people just want it to build the house instead of using it to help them hammer nails.
Post reply on HN