No tests whatsoever. This isn't getting close to being merged into mainline and it will stay out-of-tree for a long time.
That's even before taking on the brutal linux kernel mailing lists for code review explaining what that C code does which could be riddled with bugs that Claude generated.
"The intention is to compile this driver as an out-of-tree kernel module, without needing to copy it into the kernel source tree. That's why there's just a simple Makefile, and no other affordances for kernel inclusion. I can't really imagine any further need to build this driver into the kernel itself.
The last version of the driver that was included in the kernel, right up until it was removed, was version 3.04.
BUT, the author continued to develop the driver independently of kernel releases. In fact, the last known version of the driver was 4.04a, in 2000.
My goal is to continue maintaining this driver for modern kernel versions, 25 years after the last official release." - https://github.com/dbrant/ftape
Test coverage between subsystems in the Linux kernel varies widely. I don't think a lack of tests would prevent inclusion.
> No thanks and no deal.
I mean, now we have a driver for this old hardware that runs on a modern kernel, which we didn't before. I imagine you don't even have that hardware, so why do you care if someone else gets some use out of it?
The negativity here in many of these comments is just staggering. I've only recently started adopting LLM coding tools, and I still remain a skeptic about the whole thing overall, but... damn. Seems like most people aren't thinking critically and are just regurgitating "durrrr LLMs bad" over and over.
Yes, the negativity is infuriating. This is the mindset that is going to get left behind. I'm no LLM maximalist but they clearly have their uses in the right context and the right hands.
Even without that other article, this really reads like the author tried it for menial tasks on a neat passion project, and reports his success on it. (I'm a kernel developer, so I can empathize.)
The post was created to show how AI helped this person solve their particular problem - which it appeared to do successfully.
Other people commenting about AI hype on the post isn't an indication that the post itself was created to hype AI, or that that the post itself is "bad".
If you are eating the baked shit and enjoying it, and a subset of shit-eaters might also like your baked shit recipe, then yes - it would be wrong to say "nobody will eat that shit".
I suspect HN readers won't see enough value in your baked shit recipe for it to reach the front page - sorry. But bake away!
Why do you call what the author did shit? It is resurrecting an old tape driver for archival purposes. It may not have much commercial use, but anyone having those old tapes will appreciate it.
> I said nobody will use the driver. But I am terrible wrong because one person will?
Yes, you are wrong. And also, if you look around in these HN comments, there's at least one person here who says they have a bunch of these tapes lying around and would love to try the driver themselves. So that's two people!
> Second, any post on hackernews is made to generate hype.
Blanket generalizations like that aren't useful. You don't and can't know any random person's motivation for posting something here.
I don't even really understand why you're commenting. The things you are saying are either just rude or unnecessary. Honestly, if you are that cynical about things posted on this site, why even bother visiting it at all?
Upvoted you however it did solve the author’s problem and if he decides to post to GitHub then it could help someone later. Plenty of people working on retro architectures that wish they had things like this
That's even before taking on the brutal linux kernel mailing lists for code review explaining what that C code does which could be riddled with bugs that Claude generated.
No thanks and no deal.