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.
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:)
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.
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 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."
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?
[dead]
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:)
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)
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.
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...
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?
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.
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.
This is pretty cool! Thanks for sharing.
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!
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?