Unfortunately 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.
"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"
You didn't have what you needed; you asked an AI to help make what you needed.
Problem solved. New problem created.
New problem?
Justifying the use of AI to do something these people act like would magically get done if you were just slightly more patient. Or, if you put in 60+ hrs of time.
Haha perfectly said and reminds me of the time I used AI to fix my neighborhood's comcast outages by correctly diagnosing the issue and there was a guy in the comments thread angry with me for burning down rainforests
"hpl1008-usbd: native macOS USB bridge for the HP Laser 1003-1008."
By contrast, the README is still lying about this being a printer driver.
You need a lot of clarifications, since the presentation is chaotic, the repo is chaotic and this is a marketing stunt with exaggerated language and promises.
I do not want to call anyone names but the level of pedantry and gatekeeping in this comment and the replies is outstanding. I can hear Chuck McGill screaming "You're not a real driver!".
requiring a full blown VM (with a different OS) to implement a driver (normally that would work in ring-0 along with the original OS) is not pedantry.
for instance the 'windows' part is also entirely nonsensical as the printer works on a default mint installation w/o any issues. The "obscure" part is weird as you can just buy the printer online as well.
> A device driver is software that operates or controls a particular type of device that is attached to a computer.[1] A driver provides a software interface to hardware devices, enabling other software to access hardware functions without needing to know precise details about the hardware.
It's strange, because I have zero doubt in my mind that Claude could 100% genuinely reimplement the driver and port it to actually natively run on macOS, were it prompted that way.
I bought some cheap host-managed SATA drives the other day that the BIOS can't see and Windows won't recognize. I asked Claude to write a Windows app so I can use them, and it resisted at first, but then gave up and wrote it and they now work great.
It had to implement the entire stack of bare-metal drive functions over SATA and a whole new filesystem to go with it.
Generate the VM, send it crafted PDFs to print, see what it produces, and build a driver. Not that “hard” even for a human, an AI could probably one-shot it.
Yeah, that was rather disappointing. I wouldn't have minded that the Linux driver had been used as an input, allowing Claude to reason about the functionality and interface. That seems like a reasonable approach.
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.
I'm not GP but I assume the point they were making was that throwing away the old printer a buying a new one would consume less world resources than using Claude to build this driver.
Yes, they probably read it 15 hours ago when that comment was posted, before OP changed it, in response to these comments.
Though I'm not convinced it actually is. OP said the same the first time around, and I don't think actually understands what they (or rather Claude) is doing. The HN comment here claiming they updated it, clearly written by Claude, doesn't inspire much confidence.
It also requires a root launcher that runs code from the user ~/.hp1008 dir, so security is weakened.