If you are using an LLM, wouldn't it have been a lot easier to just have the LLM find the relevant CUPS driver decompile or just capture the USB traffic, and rewrite it in Go or something native? (No need to deal with the system printing framework, the goal was just an app that accepts JPEG input.)
Interesting suggestion: I guess that would have been possible. On the other hand I think this is a more general solution, and it does minimal reinventing-the-wheel.
Or ask the agent to write a Dockerfile (to abstract the build environment) that builds CUPS and all your stuff around it directl in WASM, instead of targeting x86 and then emulating x86 with WASM.
I did this with a Raspberry Pi. The printer in question only has WiFi and USB, no ethernet (the WiFi wasn't stable, and I don't trust the TCP/IP stack anyway). So what I did was I connected it to a Raspberry Pi via USB which is connected via ethernet to the living room. I added AirPrint and brscan, and the device can be shared via usbip.
For example, you can use a USB SDR and connect to it via usbip.
Initially, I also had to actually use qemu x86-64 for the scanner part which wasn't ideal.
The only UI computers which use it, are Apple's (iPhone and iPad). In a world where the network is the computer, usbip and iscsi are very cool tech.
The reason I went with a Raspberry Pi is since it already acts as an interface for Valetudo. So it was already in use anyway. Also, I want to add Bluetooth for IoT scanning, considering to run Home Assistant on it.
But yes, what it does lack is a UI. I was thinking of adding something with a reverse proxy, but I have no idea what, and this whole project isn't residing in my house. It is in my mother's apartment.
I've been using a pi print server for a few years now. Runs my shipping label printer, an excellent HP color printer from the early 2000s, and a few other oddball printers
>Perhaps I could set them up a Raspberry Pi as a print server? But that would make it not so cheap. And anyway, I’m not convinced they’d go for the extra plugs and wires.
$35 and it's yours, with tech support and CUPS/SANE development funding included, and all open source: https://printserver.ink
print spoolers typically consume space in /var/ for the files being printed and then stream them to the device through the output filters. The amount of data in play to render a page is not typically that big. Yes, there are corner cases analogous to a zip bomb which can make the print model explode. No, in practice this isn't very normal: printing is one of the spaces where compression of the data is entirely normal. "please print another row of black, where black is that thing I told you before, do that 2048 times and then come back"
Huh? I don't have any PDF files larger than 150 MB (2500+ pages long).
It won't be a problem. 512 MB is more than enough. The previous revision had 256 MB (that's a bit tight), and the newer PCB does not have RAM less than 1 GB.
Printing stack supports streaming, either per-band (part of a single page) or per-page. Even 1200 DPI CMYK color page is less than 50 MB.
> I must apologise that I haven’t so far open-sourced any part of this that I don’t have to. Mainly that’s because I think this would be an awesomely sticky web property for a printer consumables firm to integrate with their sales site. And I’d much prefer it if they paid me to white-label it for them, rather than just forking a repo and getting it all for free.
They might be interested if they cared at all about the ease of use of their printers
I'm using an ancient Canon Selphy photo printer... on Windows 11 without any issues. Using the Windows 7 64-bit driver, worked basically out-of-the-box. It's definitely not officially supported, but to date it works totally fine.
Okay, this is reasonably genius. I have quite a few USB devices lying around that are either old enough or were niche enough that they don't work on modern _anything_, even Linux. One of them is a GameBoy Advance flash cartridge.
One thing I appreciate here is that it treats old hardware as worth saving, not as a nuisance to route around. There’s a lot of hidden value in software that extends the life of perfectly functional devices, especially when the alternative is replacing them for reasons that are mostly ecosystem drift. This is the good kind of absurd.
Running automation pipelines with LangGraph agents that control real hardware (Raspberry Pi Pico W over USB HID) makes sandboxing non-negotiable. A rogue agent on a terminal is annoying, and sending the wrong HID commands to a device can brick it.
So here’s what I did: the agent only spits out a JSON action plan and never executes anything directly. A separate validator checks the plan against a whitelist of allowed USB commands before anything gets sent forward. In short, treat the agent like an untrusted external contributor—that’s exactly what it is.
The SSH/VM approach from the article works well for pure coding. But with hardware-in-the-loop setups, you need that extra barrier between "the agent wants to do X" and "X actually happens."
I know that it is a heavyweight solution, but it could be useful for some situations with old driver/devices/applications. I have some old hardware that is compatible only with pre-WinNT OS, and I could do something similar to provide a simple solution for the end user.
I do have an ancient Dr. Stika cutter plotter which works on an old WinXP with parallel port. I did try a few times to get it to work in a VM with an USB-Parallel adapter but haven't been successful so far.
"Fixed" it by replacing it with a new CriCut. But unfortunately there doesn't seem to be any open driver or software for CriCut - so I'm afraid I'll run into the same problem in a few years again :-/
So. Does this methodology mean someone can surreptitiously boot up a Linux VM running Wireguard in your browser and be inside your firewall via chrome.sockets API?
I have an old Epson MX80 dot-matrix printer in the closet, have thought about getting a Raspberry Pi and setting that up so we can wirelessly print to it. But... who would really want that?
Too bad Apple is still preventing the WebUSB spec from being standardized. They won't even make suggestions to get it through committee because WebUSB might cut into their native app store.
Oh neat. v86 is mentioned in the FOSDEM 2025 slides [0] for another wasm port of QEMU. Interesting that what appears to be v86's inability to run x86 executables didn't fuck you.
I wonder why the decision wasn't made to use the network sharing features of SANE and CUPS, instead of requiring one to use Chrome due to the WebUSB dependency. Seems to me that you'd have a way more general solution if you could usefully deploy your VM both in any major web browser and as a standalone program.
If you value reliability and have other things to do besides maintaining a Linux machine, I recommend https://www.decisivetactics.com/products/printopia/ for Mac OS (works on Tahoe). I scrapped my Linux box, got a Mac mini for a home server, and use printopia (not the pro version, just the buy it once individual version) for using my 2 10-20 year old printers on my lan. Can even air print to them.
I used to do this with Linux and it was a huge pain in the ass. Lowest common denominator and buggy driver support (duplex printing silently fails, old hp all in one works until the next Ubuntu major upgrade which introduces the odd impossible to debug cups problem or two).
For a Mac OS server based scanning solution, I attach my client Mac to my Mac mini server using https://www.virtualhere.com/.
98 comments
For example, you can use a USB SDR and connect to it via usbip.
Initially, I also had to actually use qemu x86-64 for the scanner part which wasn't ideal.
The only UI computers which use it, are Apple's (iPhone and iPad). In a world where the network is the computer, usbip and iscsi are very cool tech.
The reason I went with a Raspberry Pi is since it already acts as an interface for Valetudo. So it was already in use anyway. Also, I want to add Bluetooth for IoT scanning, considering to run Home Assistant on it.
But yes, what it does lack is a UI. I was thinking of adding something with a reverse proxy, but I have no idea what, and this whole project isn't residing in my house. It is in my mother's apartment.
>Perhaps I could set them up a Raspberry Pi as a print server? But that would make it not so cheap. And anyway, I’m not convinced they’d go for the extra plugs and wires.
$35 and it's yours, with tech support and CUPS/SANE development funding included, and all open source: https://printserver.ink
Extra plugs could be eliminated with the help of "IEC320 3 pin C14 TO Male C13+2" cable: https://ae-pic-a1.aliexpress-media.com/kf/S4c8681fb1283499b8...
> 1 GiB LPDDR4
Wouldn't this be a huge problem trying to print anything with images or more than a page or two (most PDFs for example)?
It won't be a problem. 512 MB is more than enough. The previous revision had 256 MB (that's a bit tight), and the newer PCB does not have RAM less than 1 GB.
Printing stack supports streaming, either per-band (part of a single page) or per-page. Even 1200 DPI CMYK color page is less than 50 MB.
> I must apologise that I haven’t so far open-sourced any part of this that I don’t have to. Mainly that’s because I think this would be an awesomely sticky web property for a printer consumables firm to integrate with their sales site. And I’d much prefer it if they paid me to white-label it for them, rather than just forking a repo and getting it all for free.
They might be interested if they cared at all about the ease of use of their printers
I have an old-ish Samsung laser printer that works perfectly and a Linux file server at home and the printer no longer supports AirPrint.
I never thought about using the Linux box as an AirPrint server! This will free me from all the odd print requests from my kids! (probably)
So here’s what I did: the agent only spits out a JSON action plan and never executes anything directly. A separate validator checks the plan against a whitelist of allowed USB commands before anything gets sent forward. In short, treat the agent like an untrusted external contributor—that’s exactly what it is.
The SSH/VM approach from the article works well for pure coding. But with hardware-in-the-loop setups, you need that extra barrier between "the agent wants to do X" and "X actually happens."
"Fixed" it by replacing it with a new CriCut. But unfortunately there doesn't seem to be any open driver or software for CriCut - so I'm afraid I'll run into the same problem in a few years again :-/
I wonder why the decision wasn't made to use the network sharing features of SANE and CUPS, instead of requiring one to use Chrome due to the WebUSB dependency. Seems to me that you'd have a way more general solution if you could usefully deploy your VM both in any major web browser and as a standalone program.
[0] <https://archive.fosdem.org/2025/events/attachments/fosdem-20...>
I have an old tank of a Brother laser printer whose only issue is feeding paper. 0 fuckery with DRM or spyware or subscriptions.
I used to do this with Linux and it was a huge pain in the ass. Lowest common denominator and buggy driver support (duplex printing silently fails, old hp all in one works until the next Ubuntu major upgrade which introduces the odd impossible to debug cups problem or two).
For a Mac OS server based scanning solution, I attach my client Mac to my Mac mini server using https://www.virtualhere.com/.