Claude writing a macOS driver for my obscure HP printer built only for Windows
151–160 of 241 posts
Re: Claude writing a macOS driver for my obscure HP printer built only for Windows
#152Unfortunately this is a very misleading article and headline. I don't doubt the end result - it's useful that it works, but it's not "natively" and, unlike what some people assume, Claude didn't write a driver. It basically used HP's existing proprietary driver in a Linux VM on macOS, and just bridged that to macOS. It also requires a root launcher that runs code from the user ~/.hp1008 dir, so security is weakened.
The "only built for Windows" is also a little dubious. Technically I suppose HP could have just intended it as a Windows printer, but the driver clearly already exists in CUPS, which Apple also uses, so porting the driver isn't an unreasonable thought.
Re: Claude writing a macOS driver for my obscure HP printer built only for Windows
#153All the people saying "it's not a driver, it didn't write a driver, it's wrapping the Linux one" are missing the point: no one cares - the printer prints. It didn't before, and now it does.
Re: Claude writing a macOS driver for my obscure HP printer built only for Windows
#154LLMs can do stuff but this isn't a good example.
Re: Claude writing a macOS driver for my obscure HP printer built only for Windows
#155I was able to (through heavy Claude use) successfully reverse engineer a golf cart motor controller that is programmable over USB, but only was supported by a Windows application. Claude walked me through using ILSpy on the .NET assembly, using Wireshark to capture the protocol over USB, and to completely map out all of the functionality in the Windows application. The output was a portable C library and CLI program…
Re: Claude writing a macOS driver for my obscure HP printer built only for Windows
#156Re: Claude writing a macOS driver for my obscure HP printer built only for Windows
#157Re: Claude writing a macOS driver for my obscure HP printer built only for Windows
#158Re: Claude writing a macOS driver for my obscure HP printer built only for Windows
#159Unfortunately this is a very misleading article and headline. I don't doubt the end result - it's useful that it works, but it's not "natively" and, unlike what some people assume, Claude didn't write a driver. It basically used HP's existing proprietary driver in a Linux VM on macOS, and just bridged that to macOS. It also requires a root launcher that runs code from the user ~/.hp1008 dir, so security is weakened.
https://github.com/Kuberwastaken/hp-laser-1008a-macos
Previous context I shared on X:
"Also some clarification on the "he's just using the linux driver in the VM" - not quite
This is one of the weirdest batch of printers HP made because it's a rebranded Samsung - it "comes" under HP's unified drivers system but specifically has Samsung's printer language so compatibility is extremely messy.
What this version does is take the Linux Unified Driver and extract just the relevant component, rastertospl, basically the codec that turns CUPS raster data into the Samsung SPL format the printer understands. That codec is then wired into macOS’s native CUPS stack, so printing happens through the system like a normal driver. There’s no Linux VM handling the actual print workflow and the entire process basically acting as a driver normally at system level.
In theory, yeah - rastertospl could be reimplemented from scratch. But that would be way more unreliable while turning this from a ~4-hour project into a ~4-day reverse-engineering project, when starting this, I really just wanted a working home printer and running a tiny compatibility applet in Docker just for that codec feels like a pretty reasonable compromise AND I get to not see my mac kernel crash if it messes up.
I didn't expect this to blow up this much lol, so I'll be experimenting with this further and am already in talks with the splix team to sort this specific version out"
Re: Claude writing a macOS driver for my obscure HP printer built only for Windows
#160Wouldn't it have made more sense for Claude to suggest using the existing Linux-Airprint-VM project/product that already does this exact thing? There's even a zero-install method via https://printervention.app where it runs that Linux VM isolated inside a WebUSB-capable browser. That website itself was posted right here on HN not too long ago. I get that the LLM code assistant software prefers writing stuff, but cons…
But it wouldn’t have used so many tokens ;)