Live data from Hacker News

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

dmitrybrant.com

101–110 of 343 posts

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

#101

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.

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.

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

#102
post #31
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…

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.

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

#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 are still somewhere in my parents storage. Could be a fun weekend project to try it out, though I'm not sure I have any computer with a floppy interface anymore. And I don't think there's anything particularly interesting on those tapes either.

In any case, cool project! Kudos to the author!

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

#104

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.

We don't understand how human minds work anywhere close to well enough to say this.

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

#105
post #94

Earlier quoted context omitted.

There's boilerplate in Rails too. We move the goal posts for what we define as boilerplate as we better explore and solve a class of problems.

What boilerplate is there in rails?

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

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

#106
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…

I disagree with their CoC on AI. There are so many projects which are important and don’t let you contribute or make the barrier to entry so hard, and so you do best effort to raise a detailed bug description for it to sit there for 14 years or them to tell you to get fucked. So anyone who complains about AI isn’t worth the time and day and I support not getting paid as much if at all.

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

#109

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.

You don't? I do.

A few days ago I lost some data including recent code changes. Today I'm trying to recreate the same code changes - i.e. work I've just recently worked through - and for the life of me I can't get it to work the same way again. Even though "just" that is what I set out to do in the first place - no improvements, just to do the same thing over again.

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

#110

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.

things were on the backlog, but more important things absolutely needed to be done.
Post reply on HN