There are many who indulge in such fantasies, but I would instead give a warning. The reason you have such fantasies is likely because you, yourself, are competent in the necessary skills. But from there it is only a hair-thin line that separates you from having feelings of actively wanting such a catastrophy to occur, because it would make you and your skills valuable. Beware of such self-indulgence.
It is self-indulgence, because we can see similar fantasies in people with other skills; people collecting guns often secretly long for a collapse of law and order, people who live in the countryside and have horses imagine themselves to be cowboys in a car-less world. People who like to tinker with old cars imagine Mad Max scenarios. Et cetera. None of these scenarios are especially likely to occur; they only persist in people’s imaginations because many secretly hope for them to come to pass.
I would guess that this was close to (if not the same as) the laser printer that Richard Stallman was so frustrated by that he created the concept of free software¹, just to never have to deal with unfixable bugs again?
It seems to me that moving the processing from the computer to the printer had a reasonable rationale, but has been a huge detriment to us all ever since; printers are notoriously, almost legendarily, mysterious and opaque. The NeXT machines moved the logic back to the computer (since NeXTSTEP had PostScript as part of its operating system), and I think it’s time that we do that as well.
There existed "PostScript printers" that rendered PostScript themselves, and "raster printers" that had the host PC handle it for them. The latter being infamous as "winprinters", because they relied on Windows infrastructure for it, and often lacked the driver support outside Windows because of it.
Nowadays, any device that wants to send a print job has more than enough juice to just render whatever the fuck it wants. Modern connectivity trivializes bitmap transfer. And modern printer standards support things like "this engine wants 1b B/W rasters at 1200 dpi". Dealing with PostScript is very much a choice nowadays.
I think the free software world needs to shift its focus more to freeing all sorts of hardware that isn't computers. As you say there's a reasonable rationale for running some printing code on the printer. The problem isn't that the code runs on the printer, the problem is that the printer is a black box. If it ran Linux and we could get a root shell that'd be a very good starting point for integrating it better with the host system.
Running Linux (or another free software OS) on all your peripherals would be one way to solve it. Another way would be to not have so much CPU power in the peripherals in the first place. I sometimes suspect that the CPU in all our peripherals are present only to take control away from the computer owner; i.e. us. I instead suggest that the computer should have a device driver; that’s it. No computing should take place in peripherals at all. It may sometimes be necessary, but most often not.
I think you are underestimating just how many computing devices have CPUs of some sort in them. For example:
- Optical mice have a processor running an image processing algorithm to detect motion.
- Hard disks have a processor implementing error correction, block remapping, and SMART. SSDs and SD cards are similar.
- Pretty much any USB device has a processor to implement the USB stack - pure hardware implementations exist but are uncommon (and are little more than hard-wired CPUs).
etc, etc. Exposing all of that complexity to the CPU is not useful, and would dramatically increase the scope of software that has to be written to make anything work.
Yes, this. It's good that the mouse, by default, only returns dx/dy/buttons. It's bad that you can't reprogram it easily if you want to and it's bad you can't view the source code of how it works.
I expect reprogramming to require a JTAG board. Easily reprogrammable (via USB) peripherals will be a malware vector really quickly.
Not just that, but also - it's not as though there's a single Optical Mouse Interface which every mouse uses internally. There's probably hundreds of slightly different sensors, all of which work differently - having a single, standard interface to them (USB HID) is a lot better than having to support every single one with its own driver.
(And that's even without getting into the bandwidth issue - the camera on a modern optical mouse captures far more data than it can transfer over USB.)
The free software world has enough on its plate already, and there are a lot of other higher-priority targets for free firmware - e.g. mobile phones, GPUs, certain NICs, etc.
Display / imaging as a "big data" problem[0] is turtles all the way down. If we separate "creating something to display" and "displaying something" and call that the "display processor divide" and then ask "what passes across the divide?" in terms of information density then we see that it ebbs and flows.
Suppose I say "print a line". Some program creates a line to my specifications, a driver[1] converts that into something to be shipped across the display processor divide, the display device (printer, monitor, [2]) runs the program.... oops, excuse me "print job". Sometimes the instruction granularity is something like "print a line", other times it's a bitmap, sometimes it's some of both ("print dot at"). Once upon a time "vector displays" expected "dot at" semantics, and "raster displays" did lines and fills; bear in mind, this was mostly done in hardware.
An 8.5 x 11 inch piece of paper at 300dpi is 8415000 bits (33,660,000 at 600 dpi); at 30 frames a second it's 252,450,000. That's black and white. If you do 256 color, then 2Gbps. You (still) might need to throw hardware at that problem. Or throw software at the problem (compress it) so you can get by with the existing hardware. One final note: you won't be able to save that 250MB file and later print it out on something which doesn't exactly match the shape and density of the original device[3].
On the other hand an intermediate representation, like scalable vector graphics, or Postscript, allows different devices to be targeted but the ownership of that final conversion and where it should live depends. It depends on the "big data" nature of the problem in terms of what the final device is capable of (is it capable of running a Postscript interpreter), and who wants to pay to license the Postscript interpreter (don't forget about that!); and don't forget about firmware / driver updates. By the way, the intermediate representation is likely smaller; you can always compress that to feel good about yourself.
The opacity is because the shear forces require everybody writing for one of these interfaces to take at interface value that what the other side sends / expects is blessed by the standards gods. Everybody feels like a Christian Scientist with appendicitis.
I think you've got this backwards, you state "...moving the processing from the computer to the printer had a reasonable rationale" as fact, but what I've observed over the past 40 years has been a tendency to favor sending bitmaps across the divide, even when the display device (printer specifically, I'm talking about buying printers at Office Depot here) supports a higher level of abstraction. I am more than pleasantly surprised that my Canon G3270 is supported on reasonably modern SuSE Linux with a PPD (for printing, haven't bothered with the scanner).
Mental exercise: suppose you had enough printers to dedicate one per pixel. Would you decompose the job and send every printer individualized instructions, or would you send the printer a program to allow it to pick its designated pixel out of the broadcast plan?
[0] Big Data: when it gets too expensive to keep scaling what you're doing in a presumably integrated fashion, so you optimize by smacking the problem upside the head with dedicated hardware for one or more aspects and pave over the problems with software.
[1] or... a compiler.
[2] drone swarm?
[3] emulating turtles
“For the love of money is the root of all evil: which while some coveted after, they have erred from the faith, and pierced themselves through with many sorrows. ”
RFC 3986 (STD 66) recommends (in appendix C) delimiting URLs in angle brackets to avoid the problem which your link now has. I.e. if you’d written <https://tug.org/TUGboat/tb08-1/tb17knutmix.pdf>¹ there would have been no problem.
They stole that from the Tao Te Ching, chapter 17:
When the Master governs, the people
are hardly aware that he exists.
Next best is a leader who is loved.
Next, one who is feared.
The worst is one who is despised.
If you don’t trust the people,
you make them untrustworthy.
The Master doesn’t talk, he acts.
When his work is done,
the people say, “Amazing:
we did it, all by ourselves!”
reply