UPDATE: Noted, shifted to a 100% native MacOS version now :D

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"

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!".

He could have done this with 10-15 minutes of googling instead of spending 4 hours prompting a LLM.

This comment should be pinned, and the fact that a misleading post continues to be on the first page blows my mind.

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.

Ah, 2026... When the "tech write up" on page 1 of "Hacker News" is some genius selling an LLM creating a VM as "wrote a driver".

OP should probably add this to his list of accomplishments on LinkedIn...

It runs natively... did you even read the post at all?

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.

yup, clocked this in just the first few lines of the transcript.

I am sooo tired of this AI generated slop.

For the amount of electricity wasted by the LLM in the data center it would have been more efficient to buy a new printer that works out of the box.