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
The hardest part would probably be convincing someone to pay to white label something for which most of the key design choices and implementation came from one unfamiliar dev prompting an £18 Claude Code subscription.
Claude was great, but I did put a fair amount of my own time and (non-printing-specific) expertise into this. OTOH, sure, I wouldn’t be asking for a million dollars.
Xerox just removed all the Linux drivers first for the majority of older models (even actual ones, which you can still buy), Windows and macOS drivers second for selected models (yet).
Canon, Pantum, Brother, Kyocera, HP, they all still produce new devices on older hardware base, which require driver and does not support AirPrint/Mopria even over USB. They just don't care, they reuse what they wrote 20 years ago and ship it. Xerox and HP use Samsung printing engine and drivers, Pantum uses Lexmark.
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.
Oh, there's a thought - v86 supports lots of old DOS/Windows versions too, so assuming you could get the right port through (probably easy with anything USB, maybe possible with other things?) you could probably use your choice of old drivers:)
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."
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.
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 :-/
As a Silhouette owner (for the plotter), same - I genuinely wonder whether the Chinese market have models... the type of Chinese-market product that seems to live on because it gets rebadged.
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.
Sorry, I wasn't clear. By old hardware, I meant peripherals connected to the computer via serial or USB. We are at a level of performance where running an entire VM as a driver is kind of feasible, if wasteful.
It's not that wasteful if you don't need this stuff most of the time. I have an old HP laser printer from 2008 or so. Nearly 20 years old at this point. Works fine but HP does not provide new drivers and the current x86 ones for my mac will stop working when Apple stops supporting x86 emulation. HP could fix this but they probably don't want to. There likely is a decent Linux driver for this thing. A solution like in the article, or qemu or docker with some way to access this thing over USB could probably get the job done.
I rarely print anything in any case; which is why replacing this thing is not a really a priority for me. I print something maybe once or twice per year at best at this point. It works and does the job. I can get replacement toner cartridges on Amazon. There are decent non branded ones that are really affordable. I've only ever bought two, I think. I just don't print a lot. If somebody provides something that works indefinitely, I might still be using this thing in another 20 years.
It’ll work great if you can get the drivers all aligned properly. I’ve tried a few times to get my 12 year old Brother laser setup like that, and each time I end up throwing in the towel.
Maybe I’ll try it again someday with an LLM assisting.
I have a Samsung ML-1740 kicking around still that I just can't bear to part with; I've been meaning forever to RasPi-ify it, but it's one of those projects that feels like it's going to end up being a rabbit hole.
>but it's one of those projects that feels like it's going to end up being a rabbit hole.
I know your feelings. I've started https://printserver.ink because I wanted to buy a retail print server and could not find any. I was expecting half a year overall work for everything, but fixing all printer-related bugs for 3 years already.
Ah nice. If I supply my own raspi zero 2W, can I buy just a software license from you? Doing the software integration is the part I'm least looking forward to. :(
Unfortunately the firmware supports only Orange Pi Zero3. It's a hardware+software solution, because to make reliable print server, you have to control both and fix SoC/board specific bugs.
Greg does not accept my patch and does not reply to me, presumably because I'm Russian and he doesn't want legal consequences.
Raspberry Pi unfortunately have quite list of USB hub bugs and Wi-Fi module bugs (according to their GitHub and reports all over the Internet), and I'm not familiar with it and don't know how to fix. That's why I don't make generic firmware or container images, and stick only to my board which I know from start to end.
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?
No? It's still a web page. And the chrome socket API was deprecated and removed for everyone except ChromeOS users in certain cases. The closest you can get is installing a Chrome extension that exposes sockets, but if someone is able to do that, they don't need the browser for help.
Moreover, you don't even need Linux and Wireguard. WebRTC accomplishes p2p encrypted traffic without libraries.
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?
For a printer like an Epson MX80 an esp32 should be enough to share the printer on a raw TCP interface (AppSocket I think the protocol is named) on port 9100. It is supported by Windows and CUPS.
Very easy implementation as it essentially it just forwards the data to the printer. Since it's a raw interface you need the proper driver, but luckily Epson provides a Windows 10 driver for the Epson MX-80 (!) [1] CUPS doesn't have driver for the MX-80 but it has a number of generic Epson drivers and my guess is that one of those will work.
The most difficult part is probably the parallel interface (unless you have a printer with a serial interface in which case it will be much easier)
As for the "who would want that", I think the use case for that kind of printer today is slow logging. With a laser printer that outputs a page at a time, if you log one line per day the power fails after 65 days, you lose the 65 lines that was in its memory. The MX-80 can print a line, or even a character if you poke it in the ribs a bit, at a time, so if the power goes away, your printed lines are still there.
You might think that such an important and long-standing feature as printing would undoubtedly be backed up by a large company. This was true until 2019, when it was backed by Apple. Currently, however, CUPS and all related projects are supported by volunteers, including myself.
All the current development runs in OpenPrinting github: https://github.com/OpenPrinting, and mostly focused on newer projects, such as CUPS v3, PAPPL, Printer Applications.
Recent versions of CUPS v2 are still used in Chrome OS and Chromebooks though (apart from all Linuxes).
As of July 7, 2024 the Gutenprint project has formally deprecated MacOS support. This means that no further MacOS-compatible binaries will be produced.
Gutenprint has not had an active MacOS maintainer for over three years, and the remaining developers lack the technical ability to produce MacOS binaries, much less undertake the substantial amount of work necessary to produce, test, and support binaries on newer (post-Mojave/10.14) MacOS releases.
It looks like it's just because they had no way to test, and bandwidth to deal with it. But should still mostly work, once whatever issue (that sounds like app notrization) is fixed.
It seems like the better option would have been to fix whatever was blocking them just two years ago, rather than this wild rube goldberg machine of a Linux VM emulated in a browser tab.
I mean, anyone is welcome to do just that! But I guess coding Rube Goldberg machines in JS (to push the boundaries of the web) is a thing I really kind of enjoy.
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.
From: https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API
"WebUSB provides a way for these non-standardized USB device services to be exposed to the web. This means that hardware manufacturers will be able to provide a way for their device to be accessed from the web, without having to provide their own API."
Firefox's non-reasons are just as lame as Apple's non-reasons. These APIs aren't security risks, the user has to explicitly opt-in on every website that requests USB access, just like every other privacy-risky API that a website requests, like microphone and camera access. WebUSB is no different.
The only thing that has changed since camera and microphone access was allowed is that Apple now considers web apps to cut into their app store business, so they are unwilling to let any new APIs get approved that would make a web app as capable as a native app. This includes WebBluetooth and other APIs.
Apple is also getting sued by the DOJ for exactly this type of shady business practice.
And I don't really think what Firefox says is relevant, they are so cash-strapped I would not doubt that Apple pays them to have a negative opinion about new web APIs just so people like you can say "Firefox doesn't want it either".
The truth is there is no good reason to block WebUSB and WebBluetooth from becoming standards.
The user gets spammed with a million permissions popups a day and has no idea what they are actually accepting or what the risks are. The same looking permissions popup usually means something incredibly trivial like notifications or camera, while the webusb spec is exposing you to potentially high risks of damage to hardware or data theft.
>The user gets spammed with a million permissions popups a day and has no idea what they are actually accepting or what the risks are.
"A million" is quite the hyperbole. So let's just not do anything anymore because it might cause a permission popup? Or because some idiot might trust a scam website? That's your argument? Sorry, it's not a good argument.
>while the webusb spec is exposing you to potentially high risks of damage to hardware or data theft.
Please explain a realistic scenario where a website >that someone trusts< is going to "damage hardware or cause data theft".
I'll wait.
I don't care about someone's stupid grandfather that is going to find a way to get hacked one way or another - he's not a good reason to hold the rest of us back.
That’s the source of the issue. Apple sells products that are safe for someone’s stupid grandfather. WebUSB is not safe for people who don’t understand the implications. Which is most people.
>Apple sells products that are safe for someone’s stupid grandfather.
Then then they should be selling it in "grandfather mode". The rest of the non-stupid people that have iPhones (there are non-stupid people with iPhones, aren't there?) should be able to do what they want with their devices. But they can't because Apple puts profit over progress.
>The rest can choose a different browser.
Except on iOS you can't choose a different browser. Apple has blocked all other browsers on their mobile platform, so if you try to install Chrome, you're really just getting a Safari webview with a wrapper around it. It's just another example of abusive business tactics that the DOJ is suing Apple for.
On iOS you can’t use usb anyway. Even an actual app can’t use usb outside of the wrapper APIs for file access and stuff. So it doesn’t really matter what safari supports here. And on macOS you can use any browser you want.
That's nonsense. You have to opt-in on any website that is requesting USB access, just like every other useful but potentially privacy-risky browser API.
Plenty of sites ask for camera access, and that is typically a USB device. Plenty of sites ask for microphone accesss, which can be a USB device. And even if those aren't always USB devices, they are still very much a privacy risk that browsers all allow. USB access is no different, a website can't just do whatever it wants, you have to give it permission to use it first. And it doesn't have to be all-or-nothing either, it could be implemented to allow the browser to access only specific USB devices.
Apple is holding back progress in favor of profit. They profit when developers are forced to create a native app where Apple can extract 30% of revenue through the app.
It's not about if the camera is a USB device or not, it's about what the capabilities being exposed is. Web browsers aren't just handing over the webcam as an arbitrary USB device, they are presenting a media stream from them. Which means they can't for example send arbitrary commands, flash firmware, or do any of the infinite things a USB device might present.
I'm not giving any old website access to all of my USB devices. I'd expect to give a website I trust access to a specific USB device. I'm not sure why you think this has to be a willy-nilly free-access-to-everything feature.
Yes, I want to give access to site XYZ to a product purchased from site XYZ to do amazing things over WebUSB.
If that isn't the current spec, then change the spec so it's good.
But Apple just doesn't give a single shit to propose any changes because doing so would hurt their precious app store just a little bit.
I don't really think what Mozilla says is relevant, they are so cash-strapped I would not doubt that Apple pays them to have a negative opinion about new web APIs just so people like you can say "Mozilla doesn't want it either".
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.
Can you elaborate on how using the network sharing features of CUPS would let you achieve the same thing (printing to old USB printers) in any major web browser?
> I just don’t think I fully understand what you’re suggesting.
Sure, sure.
Like I said, given your commercial (and closed-source) aspirations, I'm happy to consult on your project as a paid contractor. Doing work for free on a closed-source for-profit project is neither interesting nor in my interest.
You could bridge the ipp server of cups over webrtc to a native listener that talks to the usb port. Webrtc to localhost might raise some red flags, but could be a neat alternative to the chrome requirement. Use at the very least some hmac key pairing to ensure others can't easily piggyback on the listener. I just saved you a few bucks.
> And if you're not going to spell it out due to your morals...
Nah, this isn't a moral issue.
I'm willing to do free labor for an open-source project (whether or not it's a commercial project), as that labor benefits everyone. I'm unwilling to do free labor on a closed-source project, as that labor only benefits the entity that owns the code. This goes double for a commercial closed-source project, because in that case I don't see a cent of the money that the code owner gets from my labor. [0]
If you think that wanting to get a piece of the fruits of one's labor is a moral issue, you have a very strange relationship with work.
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/.
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.
Is there a Docker-to-WASM pipeline, and how does it do anything differently from emulating x86?
That's definitely possible for simpler drivers (CUPS filters) which accept CUPS-raster data for input. That's a majority of drivers for old printers.
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
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)?
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"
Most network printers don't have that much right? I remember seeing a few 256MB sticks in those old copiers that served a whole buildings.
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
The hardest part would probably be convincing someone to pay to white label something for which most of the key design choices and implementation came from one unfamiliar dev prompting an £18 Claude Code subscription.
Claude was great, but I did put a fair amount of my own time and (non-printing-specific) expertise into this. OTOH, sure, I wouldn’t be asking for a million dollars.
These printer makers have the source code and the ability to write firmware. If they wanted to support WebUSB, they could and would.
Xerox just removed all the Linux drivers first for the majority of older models (even actual ones, which you can still buy), Windows and macOS drivers second for selected models (yet).
https://discussion.fedoraproject.org/t/xerox-removed-linux-d...
https://forum.support.xerox.com/community?id=community_quest...
Canon, Pantum, Brother, Kyocera, HP, they all still produce new devices on older hardware base, which require driver and does not support AirPrint/Mopria even over USB. They just don't care, they reuse what they wrote 20 years ago and ship it. Xerox and HP use Samsung printing engine and drivers, Pantum uses Lexmark.
They are referring to aftermarket ink cartridge companies, not the printer OEM.
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.
Huh, interesting. Is the driver built in to Windows, downloaded from Canon, or acquired some other way?
TBH the web app story on Windows isn’t ideal anyway because you have to install Zadig before it will work.
I think I downloaded it from Canon 5-6 years ago. It should still be around I guess, but I can share it if needed.
EDIT: you can find it here for example: https://asia.canon/en/support/0100304802
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.
Oh, there's a thought - v86 supports lots of old DOS/Windows versions too, so assuming you could get the right port through (probably easy with anything USB, maybe possible with other things?) you could probably use your choice of old drivers:)
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."
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.
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 :-/
As a Silhouette owner (for the plotter), same - I genuinely wonder whether the Chinese market have models... the type of Chinese-market product that seems to live on because it gets rebadged.
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.
Would such old hardware even be able to run a modern browser needed for this?
Sorry, I wasn't clear. By old hardware, I meant peripherals connected to the computer via serial or USB. We are at a level of performance where running an entire VM as a driver is kind of feasible, if wasteful.
It's not that wasteful if you don't need this stuff most of the time. I have an old HP laser printer from 2008 or so. Nearly 20 years old at this point. Works fine but HP does not provide new drivers and the current x86 ones for my mac will stop working when Apple stops supporting x86 emulation. HP could fix this but they probably don't want to. There likely is a decent Linux driver for this thing. A solution like in the article, or qemu or docker with some way to access this thing over USB could probably get the job done.
I rarely print anything in any case; which is why replacing this thing is not a really a priority for me. I print something maybe once or twice per year at best at this point. It works and does the job. I can get replacement toner cartridges on Amazon. There are decent non branded ones that are really affordable. I've only ever bought two, I think. I just don't print a lot. If somebody provides something that works indefinitely, I might still be using this thing in another 20 years.
You run old operating system in browser as a gateway.
Thank you, loved this and it made me "duh!".
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)
Been doing something similar with a Samsung printer and CUPS for years, it’s great
Found this helpful for generating some of the config files: https://github.com/tjfontaine/airprint-generate
It’ll work great if you can get the drivers all aligned properly. I’ve tried a few times to get my 12 year old Brother laser setup like that, and each time I end up throwing in the towel.
Maybe I’ll try it again someday with an LLM assisting.
I have a Samsung ML-1740 kicking around still that I just can't bear to part with; I've been meaning forever to RasPi-ify it, but it's one of those projects that feels like it's going to end up being a rabbit hole.
>but it's one of those projects that feels like it's going to end up being a rabbit hole.
I know your feelings. I've started https://printserver.ink because I wanted to buy a retail print server and could not find any. I was expecting half a year overall work for everything, but fixing all printer-related bugs for 3 years already.
Ah nice. If I supply my own raspi zero 2W, can I buy just a software license from you? Doing the software integration is the part I'm least looking forward to. :(
Unfortunately the firmware supports only Orange Pi Zero3. It's a hardware+software solution, because to make reliable print server, you have to control both and fix SoC/board specific bugs.
For example, USB 1.1 OHCI has too high latency to work with my old printer, and needs a kernel patch: https://lore.kernel.org/linux-usb/3fe845b9-1328-4b40-8b02-61...
Greg does not accept my patch and does not reply to me, presumably because I'm Russian and he doesn't want legal consequences.
Raspberry Pi unfortunately have quite list of USB hub bugs and Wi-Fi module bugs (according to their GitHub and reports all over the Internet), and I'm not familiar with it and don't know how to fix. That's why I don't make generic firmware or container images, and stick only to my board which I know from start to end.
ML-1740 is supported by the driver available here: https://www.bchemnet.com/suldr/index.html Works on my arm64 sbc as a cups printer for another samsung printer
It's a Samsung SPL device, it's supported by SpliX: https://github.com/OpenPrinting/splix
Yup, I used splix with it for years on Mac, so I think that will be the way to go.
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?
No? It's still a web page. And the chrome socket API was deprecated and removed for everyone except ChromeOS users in certain cases. The closest you can get is installing a Chrome extension that exposes sockets, but if someone is able to do that, they don't need the browser for help.
Moreover, you don't even need Linux and Wireguard. WebRTC accomplishes p2p encrypted traffic without libraries.
You don’t need a VM. Do what Netbird does. Compile wireguard-go to WASM and you’re g2g
https://docs.netbird.io/about-netbird/browser-client-archite...
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?
For a printer like an Epson MX80 an esp32 should be enough to share the printer on a raw TCP interface (AppSocket I think the protocol is named) on port 9100. It is supported by Windows and CUPS.
Very easy implementation as it essentially it just forwards the data to the printer. Since it's a raw interface you need the proper driver, but luckily Epson provides a Windows 10 driver for the Epson MX-80 (!) [1] CUPS doesn't have driver for the MX-80 but it has a number of generic Epson drivers and my guess is that one of those will work.
The most difficult part is probably the parallel interface (unless you have a printer with a serial interface in which case it will be much easier)
[1] https://epson.com/Support/Printers/Impact-Printers/MX-Series...
As for the "who would want that", I think the use case for that kind of printer today is slow logging. With a laser printer that outputs a page at a time, if you log one line per day the power fails after 65 days, you lose the 65 lines that was in its memory. The MX-80 can print a line, or even a character if you poke it in the ribs a bit, at a time, so if the power goes away, your printed lines are still there.
Doesn't Apple outright uses CUPS in the first place ? Did they just removed old drivers in their version ?
You might think that such an important and long-standing feature as printing would undoubtedly be backed up by a large company. This was true until 2019, when it was backed by Apple. Currently, however, CUPS and all related projects are supported by volunteers, including myself.
Apple abandoned CUPS years ago, and recently have archived the repo on github: https://github.com/apple/cups
All the current development runs in OpenPrinting github: https://github.com/OpenPrinting, and mostly focused on newer projects, such as CUPS v3, PAPPL, Printer Applications.
Recent versions of CUPS v2 are still used in Chrome OS and Chromebooks though (apart from all Linuxes).
I'd be curious if cups works on wsl as well...
It does: https://openprinting.github.io/wsl-printer-app/
This is pretty cool! Thanks for sharing.
I would have asked Claude to write a driver. But this works, too. :)
Isn't cups a de facto apple project? What's the VM getting you?
No. Most cups changes nowadays happen in https://github.com/openprinting/cups?tab=readme-ov-file
See here for the details: https://openprinting.github.io/achievements/#cups-upstream-h...
Oh, OK, new information, thanks!
But this driver is older than OpenPrinting's fork from Apple CUPS.
The gutenprint drivers to support the specific printer don't support darwin
Gutenprint supports macos as a first class citizen, including this particular printer AFAICT.
From the Gutenprint home page, https://gimp-print.sourceforge.io/:
As of July 7, 2024 the Gutenprint project has formally deprecated MacOS support. This means that no further MacOS-compatible binaries will be produced.
Gutenprint has not had an active MacOS maintainer for over three years, and the remaining developers lack the technical ability to produce MacOS binaries, much less undertake the substantial amount of work necessary to produce, test, and support binaries on newer (post-Mojave/10.14) MacOS releases.
It looks like it's just because they had no way to test, and bandwidth to deal with it. But should still mostly work, once whatever issue (that sounds like app notrization) is fixed.
It seems like the better option would have been to fix whatever was blocking them just two years ago, rather than this wild rube goldberg machine of a Linux VM emulated in a browser tab.
I mean, anyone is welcome to do just that! But I guess coding Rube Goldberg machines in JS (to push the boundaries of the web) is a thing I really kind of enjoy.
What I'd really like to know is how to rescue an old printer by making its rubber rollers sticky enough not to jam.
I have an old tank of a Brother laser printer whose only issue is feeding paper. 0 fuckery with DRM or spyware or subscriptions.
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.
From: https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API "WebUSB provides a way for these non-standardized USB device services to be exposed to the web. This means that hardware manufacturers will be able to provide a way for their device to be accessed from the web, without having to provide their own API."
That doesn't sound secure at all!
Which is why Firefox doesn't support it either.
Firefox's non-reasons are just as lame as Apple's non-reasons. These APIs aren't security risks, the user has to explicitly opt-in on every website that requests USB access, just like every other privacy-risky API that a website requests, like microphone and camera access. WebUSB is no different.
The only thing that has changed since camera and microphone access was allowed is that Apple now considers web apps to cut into their app store business, so they are unwilling to let any new APIs get approved that would make a web app as capable as a native app. This includes WebBluetooth and other APIs.
Apple is also getting sued by the DOJ for exactly this type of shady business practice.
And I don't really think what Firefox says is relevant, they are so cash-strapped I would not doubt that Apple pays them to have a negative opinion about new web APIs just so people like you can say "Firefox doesn't want it either".
The truth is there is no good reason to block WebUSB and WebBluetooth from becoming standards.
The user gets spammed with a million permissions popups a day and has no idea what they are actually accepting or what the risks are. The same looking permissions popup usually means something incredibly trivial like notifications or camera, while the webusb spec is exposing you to potentially high risks of damage to hardware or data theft.
>The user gets spammed with a million permissions popups a day and has no idea what they are actually accepting or what the risks are.
"A million" is quite the hyperbole. So let's just not do anything anymore because it might cause a permission popup? Or because some idiot might trust a scam website? That's your argument? Sorry, it's not a good argument.
>while the webusb spec is exposing you to potentially high risks of damage to hardware or data theft.
Please explain a realistic scenario where a website >that someone trusts< is going to "damage hardware or cause data theft".
I'll wait.
I don't care about someone's stupid grandfather that is going to find a way to get hacked one way or another - he's not a good reason to hold the rest of us back.
That’s the source of the issue. Apple sells products that are safe for someone’s stupid grandfather. WebUSB is not safe for people who don’t understand the implications. Which is most people.
The rest can choose a different browser.
> WebUSB is not safe for people who don’t understand the implications. Which is most people.
Why? What is the worst that could happen? The user needs to choose which device(s) to allow access to and browsers do not allow access to all of them.
>Apple sells products that are safe for someone’s stupid grandfather.
Then then they should be selling it in "grandfather mode". The rest of the non-stupid people that have iPhones (there are non-stupid people with iPhones, aren't there?) should be able to do what they want with their devices. But they can't because Apple puts profit over progress.
>The rest can choose a different browser.
Except on iOS you can't choose a different browser. Apple has blocked all other browsers on their mobile platform, so if you try to install Chrome, you're really just getting a Safari webview with a wrapper around it. It's just another example of abusive business tactics that the DOJ is suing Apple for.
On iOS you can’t use usb anyway. Even an actual app can’t use usb outside of the wrapper APIs for file access and stuff. So it doesn’t really matter what safari supports here. And on macOS you can use any browser you want.
I don't care about WebUSB on iOS, but I do care about Apple blocking WebBluetooth on iOS, as well as blocking every other browser engine.
That's nonsense. You have to opt-in on any website that is requesting USB access, just like every other useful but potentially privacy-risky browser API.
Plenty of sites ask for camera access, and that is typically a USB device. Plenty of sites ask for microphone accesss, which can be a USB device. And even if those aren't always USB devices, they are still very much a privacy risk that browsers all allow. USB access is no different, a website can't just do whatever it wants, you have to give it permission to use it first. And it doesn't have to be all-or-nothing either, it could be implemented to allow the browser to access only specific USB devices.
Apple is holding back progress in favor of profit. They profit when developers are forced to create a native app where Apple can extract 30% of revenue through the app.
It's not about if the camera is a USB device or not, it's about what the capabilities being exposed is. Web browsers aren't just handing over the webcam as an arbitrary USB device, they are presenting a media stream from them. Which means they can't for example send arbitrary commands, flash firmware, or do any of the infinite things a USB device might present.
I don't care?
I'm not giving any old website access to all of my USB devices. I'd expect to give a website I trust access to a specific USB device. I'm not sure why you think this has to be a willy-nilly free-access-to-everything feature.
Yes, I want to give access to site XYZ to a product purchased from site XYZ to do amazing things over WebUSB.
If that isn't the current spec, then change the spec so it's good.
But Apple just doesn't give a single shit to propose any changes because doing so would hurt their precious app store just a little bit.
Sounds like it's time for you to learn a proper programming language, little boy.
You're a shitty troll. Not engaging with your level of shithead.
Mozilla doesn’t want it either.
I don't really think what Mozilla says is relevant, they are so cash-strapped I would not doubt that Apple pays them to have a negative opinion about new web APIs just so people like you can say "Mozilla doesn't want it either".
what the heck we're not in web 1.0 anymore are we
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.
[0] <https://archive.fosdem.org/2025/events/attachments/fosdem-20...>
Can you elaborate on how using the network sharing features of CUPS would let you achieve the same thing (printing to old USB printers) in any major web browser?
Given your commercial aspirations, I'm happy to consult on your project as a paid contractor.
Fair enough! I just don’t think I fully understand what you’re suggesting.
> I just don’t think I fully understand what you’re suggesting.
Sure, sure.
Like I said, given your commercial (and closed-source) aspirations, I'm happy to consult on your project as a paid contractor. Doing work for free on a closed-source for-profit project is neither interesting nor in my interest.
I dont understand what you're suggesting either given the whole point was to avoid having separate hw).
And if you're not going to spell it out due to your morals, don't comment.
You could bridge the ipp server of cups over webrtc to a native listener that talks to the usb port. Webrtc to localhost might raise some red flags, but could be a neat alternative to the chrome requirement. Use at the very least some hmac key pairing to ensure others can't easily piggyback on the listener. I just saved you a few bucks.
> And if you're not going to spell it out due to your morals...
Nah, this isn't a moral issue.
I'm willing to do free labor for an open-source project (whether or not it's a commercial project), as that labor benefits everyone. I'm unwilling to do free labor on a closed-source project, as that labor only benefits the entity that owns the code. This goes double for a commercial closed-source project, because in that case I don't see a cent of the money that the code owner gets from my labor. [0]
If you think that wanting to get a piece of the fruits of one's labor is a moral issue, you have a very strange relationship with work.
[0] "Exposure" also doesn't pay the bills.
Another AI add.
surely a glorious OS like osx would not be without support for hardware that linux supports? when will it be year of osx desktop?
wdym?
OSX has literally always been supported only on very limited hardware so how would it support anything else?
did you read what this is about? support for a printer people buy in stores. the kinda thing people expect working?
Oh I thought you were referring to the VM part
Anyway Apple created CUPS so it should support anything Linux does when it comes to printing
edit: looks like they didn’t create it, they just hired the guy who did and shipped it
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/.
It’s pretty easy now days on Linux. Including AirPrint bridging to legacy (even real old) printers.