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"
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.
OP should probably add this to his list of accomplishments on LinkedIn...
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.
I am sooo tired of this AI generated slop.
After about 5 hours, feeding it the GIP spec, an export of sniffed usb traffic from Windows, prior art (xone driver for linux), and giving Claude connectivity to my Shield via adb, I had it working. This continuously blows my mind that I dont have to beg a developer on Github to do it for me.
Claude could do it for me for $20.
I have a Razer Wolverine Xbox controller that has extra back paddle buttons. The controller doesn't expose the paddles directly to PC's over USB. You have to use button remapping on the controller to map them to 'real' Xbox buttons for the PC to see them. But I wanted to use the back paddle buttons on Steam as separate controls.
So I downloaded the latest firmware update off the internet (because what device doesn't have firmware updates these days), installed Ghidra and an MCP server for it, and told Sol to look for how I can expose these extra buttons to a PC host. Maybe we could write a firmware patch?
Turns out the controller already has a special mode to expose those buttons, possibly as a hardware test. But it was enough to write a Linux driver to put the controller into that mode, and a little bit of extra driver code to map the paddles to a Linux controller button, and voila. Paddles working in Steam.
And it only took a few hours to do, too. I spent more time making an open source repository out of the concept than I spent making it work.
The "linux" support is pretty narrow (because I made this for myself). It's restricted to SteamOS. But I'm sure it could be ported easily, the repository contains documentation about the important parts from reverse engineering the firmware.
I used to feel proud of the fact I reverse engineered some of my laptop's features using stuff just like this. I suppose that's over.
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 constantly re-writing the same solution seems a bit inefficient.
LLMs can do stuff but this isn't a good example.
> Thanks for being such a game debugging partner through all the test pages. Enjoy printing, you and the family.
Maybe it's because my own LLM usage is very "Question > Answer" or "Do this > Agent does that" and I never say "Wow, that's crazy it works, thank you!" at the end or such, so I don't see that sort of things, but if I saw that regularly I'd turn me off so badly from using LLMs. I'm not exactly sure where this feeling is coming from though, it's relatively innocent but just feels so inauthentic, I'm guessing because it's simply a machine.
So I find it common (and fine, I suppose) for Claude to reply using that context. "Let me know what your wife thinks of the app" etc.
Seems an oddly specific thing to hone in on otherwise.
After digging around, I found a file that looked like it could be the settings file, but it was not plaintext.
Naturally, I told Claude all the options I knew existed in the settings and told it what I needed it to change.
After about 10 minutes poking around my system and the file, it correctly identified the bits (not bytes!) that corresponded to the two settings, and flipped them on. It. Just. Worked!
(Well, then I found out I actually needed to do quite a lot more than flipping those bits, but I still found it worth sharing).
I have many more experiences similar to these. LLMs are an amazing superpower.
For example, I needed to change something in a particular function of firefox (which was in and of itself an amazing claude adventure to find that solved a problem I've had for well over 2 years), but only that very specific function.
I didn't want to fork firefox and have to constantly rebuild it just because of this one function. So I setup an LD_PRELOAD (well, not LD_PRELOAD, but the macOS equivalent) trick that injects only my modified function, as well as a full mechanism that traps firefox's auto-update process to reinject/re-arm the LD_PRELOAD trick into newer versions. I've had it going on for 3 months without any issues.
I counted and I have about 18 custom built apps ranging from "full blown swift GUI" to "tiny helper script" that have really changed how I interact with my computers for the better. It's so cool to be living this revolution.
Unfortunately, as I look around, I see most of the hardware vendors around me as gatekeepers. They prevent me from writing custom code in various ways. Apple restricts access to NFC or their UWB positioning, Supernote Manta does not let me access a bluetooth microphone, the list goes on. Denon at least has an API in their amps/receivers: buggy, but it's there.
I unfortunately can't see it becoming in any way legally mandated either, just have to hope for a good vendor.
Makes it so if there’s an issue I don’t get a kernel panic
Maybe it could write something CUPS compliant though ?
linking this here for those who don't wanna read the threads https://github.com/Kuberwastaken/hp-laser-1008a-macos
genuinely very interesting case to learn from for me because this was one of the HP branded Samsung printers which doesn't have native non-windows support !
Reverse engineering seems like an AI sweet spot.
https://www.alecburton.co.uk/2017/printing-from-a-docker-con...
There are many such tutorials and Claude just plagiarized as usual.
The real trick is to have the AI do something that makes its own money, then tokens are effectively free.
People who are complaining about token costs aren't trying.
Same thing here brother: DCP-L2510D (laser printer + scanner).
Wife is on MacOS and cannot print/scan from there, so I'm the scanman.
codeberg.org/mjmvisser/infoframe if anyone’s interested.
Claude worked for a while and then spun itself into a loop of making a mistake, correcting it, then making it again.
That was 9 months ago so perhaps I should try again.
I usually answer saying there's not really a hack for it, you just work with it, convey thoughts decently and try out things with educated guesses until it sticks with these projects.
But I actually went ahead and exported the chat in a readable format for anyone curious enough to go through :) https://cdn.kuber.studio/chat/hp-laser-1008a-driver
It was crazy how the LLM held on to outdated information. It suggested so many things that might have worked on an older macOS but very obviously wouldn’t nowadays. It also tried to port from Linux for a while until it eventually discovered that cups on Linux didn’t support that printer either.
Given the positive results from what I've heard, this might be actually one are where LLMs could prove useful for once.
Edit: no, I was thinking of the older p1008.
But of course it's hard not to both marvel and lament (at) the fact that in the mid-1990s (so yup 30 years ago) I could:
nc 192.168.1.150 9100 < tiger.ps
I know, I know, about garbled print jobs, pages of codes being printed, etc.
But still: it's hard to not at least wonder if some things haven't been lost. For a start printers with their own IP addresses were sweet (instead of a USB cable and, now, people setting up, say, a Pi just to expose a LAN IP for/to their printer). Then of course another talk could be had about the "quality" of modern day HP laser printers compared to what you'd get int the nineties.
And now I can print to it via my Mac.
It's a fun time to be alive.
...I would have asked Fable.
This is what I do with two 4" USB-only thermal printers. They are connected to a Raspberry Pi running CUPS, so I can print labels to them from within my home network. I never need to print labels from my phone, but do sometimes need to print photos to one of the printers. Avahi on the Pi enables AirPrint, and iOS sees that and lets me do so.
But programming languages and operating system fragmentation didn’t let that really take off
Maybe now that original promise of personal computers can be realized :)
Imagine instead of going to the App Store, just telling ChatGPT etc to make a custom app and run it right away on your phone
I feel like both Google and Apple see that future, and are now actively working to make sure it can't happen to protect their app store commissions.
If you do AI fixes, for the greater good, at least publish them (or even better, try to submit upstream, although expect to be ignored if the upstream does not like slop...)! :)
Cool nonetheless.
https://wiki.debian.org/CUPSPrintQueues#hpuld
claude seems to have realized it was one of the samsung printer variants and just shoehorned in a samsung MFP driver to the OS.
I consider myself kind of an AI detractor but even I'll admit that the tool allowed me to do something it would have taken weeks-to-months to learn to do the hard way.
I only got it to the proof of concept stage. The patch adds aac but breaks flac support in the process. And it only works for aac in mp4 container files. But I’m sure with a bit of time we could make a patch which works everywhere and is additive only.
I say ‘we’ - I barely helped. Almost all the work was done by Claude.
Here’s Claude’s report, if anyone wants to build on this work:
https://claude.ai/code/artifact/87d38c2e-9ecb-4066-90cf-e0b2...
>Additional Old Linux Drivers Face Removal Due To Noise From AI/LLM Coding Agents
https://www.phoronix.com/news/Linux-Retiring-Moxa-Driver
Not a successful anecdote, but I have a Windows Hello compatible Kengsington fingerprint reader, and for some time I wanted to write drivers for Linux. Even without using C, it would have been a huge undertaking only to fail in the end; because Claude did much of the research and concluded that the device wouldn't work on Linux (can't remember why but it made sense). Then it suggested what could work.
In this case:
LLMs are also VERY good at transliteration, i.e., converting known-good Python to Rust.Basically, If you have a well-documented problem, the LLM is a shortcut to learning it yourself. LLMs fail when you have a novel or poorly documented problem. They also fail when you provide the LLM with terrible context or too much context.
This is a very novel, reasonably-poorly-documented problem, and so far it has batted 1.000.
After 5-6 consecutive approaches fail, I need a reason to think the next one might work out to stay motivated.
Claude will keep burning credits trying new approaches until something sticks. That's a huge advantage in a field where most of the things you try don't go anywhere.
Reverse engineering isn't so much hard as it is exhausting.
LLMs simply don't care about exhaustion.
It also has the benefit that it doesn't usually matter too much if it gets minor details wrong. It's definitely one of the areas - like hacking - where it's a) tedious and b) insensitive to mistakes where AI absolutely shines.
The whole thing took about a day, spread out over a week or so. Without AI, I wouldn't have even started the project, because I couldn't spare the time it would have taken.
None of this would have been possible (or at least practical from a time-value perspective) for me to do without Claude driving the whole exercise.
The odds of success go up a LOT when the stock firmware is easy to extract and reverse engineer.
Or are we in a really cool time where we've solved everything so much so many times we can focus on other things?
Tertiary question: If answer two, what the fuck is that?
For programmers this is the equivalent of when accountants got spreadsheets. We can just tell the machine what to do without manually performing all the steps.
Some programmers enjoyed the code writing more than the problem solving though.