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

301–310 of 343 posts

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

#301

Post by Aperocky »

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…

> collectively emphasized the creation of new tools

In fact, collectively created 1000s of them and all of them a various flavor of mid.

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

#302

Post by lenkite »

cestith wrote: post #275
lenkite wrote: post #246

Earlier quoted context omitted.

Maybe it was a "viewer" in the 90s. The viewer is not a viewer - it is a full fledged application runtime that has a developer environment and media stack, along with several miscellaneous runtimes. A standard template language and document inclusion feature is very small peanuts compared to that. A teeny house compared to the galaxy already built-in - with several planets worth of features being added yearly.

You both make good points, and I come down on the side of adding some template mechanism to web standards. Of course, that all starts with an RFC and a reference implementation. Any volunteers?

Would raise my hand to volunteer for the reference implementation. I guess it would need to be in C++/Rust ? RFC, however, involves way too much talking and also needs solid networking amongst the web crowd. Not qualified for that. For a template language, it would be better to copy a subset from an existing de-facto standard like jinja2 which already has a lean, performant subset implementation at https://github.com/Keats/tera.

Document/template inclusion model should be OK now in modern era thanks to HTTP/3. Not really sure how that should ideally look like though.

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

#303

Post by theptip »

skydhash wrote: post #223
johnisgood wrote: post #207

Earlier quoted context omitted.

I think you can do this already. If you do not know the underlying concepts, or have no idea about how you have to architecture your project and so forth, then you will have problems with LLMs. So I think many if not most people who have problems with LLMs, it is most likely due to their lack of knowledge and/or their expectation that you can just simply write two sentences and it will figure out what you want and ho…

The thing is, is it slower to code with LLMs if you already have the knowledge? I think it is so. Coding is formal. There’s usually one correct way to tell the computer to do something (all the alternatives are equivalent through abstraction or transposition). The other ways are what we called bugs and there’s an infinty of them. The programming language eliminates some (incorrect syntax) while the type system get ri…

> Coding is formal

I just don’t see it like this; code is craft, and there are ten ways to solve any given problem. Reasonable people can select different tradeoffs, and taste is also a big factor.

Maybe if you are working in very low-level algorithmic, compiler, or protocol development it’s less ambiguous. But almost all software is written many layers above that.

I’m sure if you already sat down and thought through every detail, you might find LLMs slow you down vs typing. Many people use the process of writing, or the process of iterating with customers, to flesh out the ambiguous detail; in which case improving cycle time can improve your time to PMF.

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

#304

Post by chii »

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 haven't we collectively emphasized the creation of new tools to reduce boilerplate and grunt work?

i think it has. How much easier is it today than yester-decade to write, and deploy an application to multiple platforms (and have it look/run similarly)?

How little knowledge it requires now than before?

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

#305

Post by marcus_holmes »

AdieuToLogic wrote: post #99
nchmy wrote: post #93

Earlier quoted context omitted.

are you advocating for not having code reviews...? Just straight force push to main?

> are you advocating for not having code reviews...? Just straight force push to main? No, not at all. What I was speaking about was if the person to whom I replied is not a s/w engineer, then perhaps a better contribution to their project would be to define requirements in the form of RSpec specifications (since Ruby is in use) and allow the engineering team to satisfy them as they determine appropriate. I have seen…

I'm the person you replied to. I've been developing software for >30 years now. In this case I have domain knowledge, architecture knowledge, experience with the type of systems we're building, but not the language (it's an odd situation). I'm using an LLM to avoid the weeks/months of getting up to speed with Ruby myself, and it appears to be working.

To address your comments about PRs: without the LLM I would be submitting shitty PRs with lots of basic Ruby mistakes. With the LLM I am submitting PRs that are on a par with everyone else's PRs (Ruby has many ways of doing the same thing, so most suggested changes to my PRs are the usual "or you could do it this way and that might be more elegant" discussions). It's not that the rest of the team are picking up my slack, it's actually better this way.

I was a bit sceptical when I started, and like you I assumed that I would end up having to learn Ruby, but in fact it's working well.

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

#306

Post by marcus_holmes »

skydhash wrote: post #226
maccard wrote: post #170

Earlier quoted context omitted.

> 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. I lead the engineering team at my org and we hire almost exclusively for c++ engineers (we make games). Our build system by happenstance is written in c#, as are all the automation scripts. Out of our control to change. Should we require every engineer to be compet…

Programming language are not actually that different. There’s only a few models of computation and paradigms. The effort is mostly about learning the syntax, the standard library and whatever abstractions built around the above paradigms and computation models. And learning the standard library is the tough one. I would expect every engineer to be able to read C#. It’s not that hard.

This. Reading a language (and not only programming languages) is very different from being able to construct good, elegant, routines (or sentences) in that language.

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

#307

Post by mrheosuper »

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

Earlier quoted context omitted.

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

There are countless different RTOS. The most polishing one is Zephyr. FreeRTOS is more like "Scheduler" than a proper OS.

Also am i correctly assume you want an OS that's truly "cross-platform", that can run on every architecture ? Or you just want to "have an app on ESP32 to run on Android" ? Because the latter can be done with proper abstraction layer.

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

#308

Post by sedatk »

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.

Ideally, yes. But, obviously not possible for every driver in existence.

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

#309

Post by antonvs »

piskov wrote: post #249
antonvs wrote: post #244

Earlier quoted context omitted.

You've misunderstood the study that you linked. LLMs certainly memorize, and this can certainly skew benchmarks, but that's not all they do. Anyone with experience with LLMs will have experienced their actual problem solving ability, which is often impressive. You'd be better off learning to use them, than speculating without basis about why they won't work.

What exactly did I misunderstand? Also “learn to use them” feels you’re holding it wrong vibes. See also https://machinelearning.apple.com/research/illusion-of-think...

The study doesn't show that "these things just memorize, not achieve any actual problem-solving."

Re learning to use them, I'm more suggesting that you should actually try to use them, because if you believe that they don't "achieve any actual problem-solving," you clearly haven't done so.

There are plenty of reports in this thread alone about how people are using them to solve problems. For coding applications, most of us are working on proprietary code that the LLMs haven't been trained on, yet they're able to exhibit strong functional understanding of large, unfamiliar codebases, and they can correctly solve many problems that they're asked to solve.

The illusion of thinking paper you linked seems to imply another misunderstanding on your part. All that's pointing out is a fact that's fairly obvious to anyone paying attention: if you use a text generation model to generate the text of supposed "thoughts", those aren't necessarily going to reflect the model's internal functioning.

Functionally, the models can clearly understand almost arbitrary domains and solve problems within them. If you want to claim that's not "thinking", that's really just semantics, and doesn't really matter except philosophically. The point is their functional capabilities.

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

#310

Post by rmoriz »

seba_dos1 wrote: post #266
rmoriz wrote: post #102

Earlier quoted context omitted.

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

You overestimate hallucinations in known settings. If you ask to show source code, it‘s easy to check the sources (of a framework, language, local code)
Post reply on HN