There is literally a GitHub repository, six years old, that ports an out-of-tree ftape driver to modern Linux:
https://github.com/Godzil/ftape
Could it be that Misanthropic has trained on that one?
Using Claude Code to modernize a 25-year-old kernel driver
211–220 of 343 posts
Re: Using Claude Code to modernize a 25-year-old kernel driver
#212I 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...
There is no "from scratch" for "AI". Claude will read the original, launder it, strip the license and pass it off as its own work.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#213I wonder if the author could now go one step further and wrote some code to interface the take drive with an ESP32, thereby removing the floppy drive from the equation and going straight to USB.
I imagine pull requests are welcome :p
Re: Using Claude Code to modernize a 25-year-old kernel driver
#214I hope it gets mainlined again!
Re: Using Claude Code to modernize a 25-year-old kernel driver
#215Re: Using Claude Code to modernize a 25-year-old kernel driver
#216There is literally a GitHub repository, six years old , that ports an out-of-tree ftape driver to modern Linux: https://github.com/Godzil/ftape Could it be that Misanthropic has trained on that one?
> Maybe this driver have problems on SMP machines.
> Maybe this driver have problems on 64Bit x86 machines.
Ouch. The part where it says it’s not possible to use a normal floppy and the tape flip anymore seemed odd enough, but those last points should scare anyone away from trying these on anything important.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#217A 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…
[flagged]
Re: Using Claude Code to modernize a 25-year-old kernel driver
#218Earlier 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.
Isn’t trying to remove boilerplate how we end up with situations like left-pad?
I actually think I like the idea that, maybe by handling my boilerplate over to AI we can be more comfortable with having boilerplate to begin with.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#219Earlier quoted context omitted.
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.
But the moment I got the idea in my head, is the moment I got the code for it. The time spent is moslty checking the library semantics, or if there’s not some function already written for a specific bit. There’s also checking if you’re not violating some contract somewhere.
A lot of people have the try and see if it works approach. That can be insanely wasteful in any moderately complex system. The scientist way is to have a model that reduce the system to a few parameters. Then you’ll see that a lot of libraries are mostly surface works and slighlty modified version of the same thing.
Re: Using Claude Code to modernize a 25-year-old kernel driver
#220There is literally a GitHub repository, six years old , that ports an out-of-tree ftape driver to modern Linux: https://github.com/Godzil/ftape Could it be that Misanthropic has trained on that one?
> Maybe this driver have problems on SMP machines. > Maybe this driver have problems on 64Bit x86 machines. Ouch. The part where it says it’s not possible to use a normal floppy and the tape flip anymore seemed odd enough, but those last points should scare anyone away from trying these on anything important.
Yes, Godzil's repo could have the issues you point out but still give hints to Claude what APIs to replace. Or the latest possibly-Claude-plagiarized version perhaps has the same issues.