My first introduction to the internet was downloading Magic the Gathering card lists as postscript files via FTP and then FTPing them to a postscript printer. Would have been 1994 and they were some sort of Sun machine at LMU. Internet has been all downhill since then.
A few years later (2002-ish), I setup a Zebra barcode/label printer that had a similar mechanism. I’d write the code for the label in the printers language (ZPL?) and then FTP a file to the printer.
I was in grad school in a wetlab, so I had to label a ton of microcentrifuge tubes. Having a quick web interface e to generate the ZPL files that would be FTP’d to the printer let me avoid writing all of that out by hand.
It was such a simple system. And the FTP server was basically a queue, so you could print a bunch of labels at a time.
Oh fascinating. If I use the system dialogue, I can choose the application to print to. There is an `lpr` option, and I can specify the application it invokes in a "Command Line" field.
I can put `nc [printer_ip] 9100` there and it will just print. I just printed your comment this way.
If I want to print multiple pages per sheet: Open PDF in Firefox, CTRL+P -> Save to PDF and configure the document. You can also pipe through `gs` to do this.
For _huge_ documents (100s of pages), I'll pipe through `gs` first to do the pdf->ps conversion on my laptops CPU. The printer can do it, it just takes a lot longer.
Hah. I had a similar moment of enlightenment with FreeBSD when somebody explained that you can just cat a wav file into /dev/audio (or /dev/dsp? forget the exact name). And that you can produce white noise by catting /dev/random to the same destination. With no barrier to the sound card like that, I was free to experiment with programming dfferent noise algorithms and figuring out how digital audio works. I eventually did things the proper way with OSS and finally sndio on OpenBSD, but direct, universal interfaces like files invite that initial exploration and help you get things done quick and easy.
netcat is also a secret weapon around the house. My girlfriend runs macOS, but it's way more reliable to just nc files to each other over wifi than deal with all the cloud and airdropping bullshit.
The secret of *nix that people don't like accepting is the file approach is often the right approach.
Consider lowly embedded linux. You COULD dig down deep into the documentation of which register, which interrupt, which special memory address needs to be written to interact with the right ports on a embedded linux board. All while adding a bunch of safeguards and checks to make sure "Only you are doing this".
Or, as if often the case, you can simply find the right /dev/xxxx device and read from it or write to it.
9 times out of 10, you'd not suffer any negative consequences from using the /dev/xxx system as intended and you get the bonus ability of being able to interact with the outside world using programming languages other than C.
The file approach ignores anything that exists (at least in part) in the time domain.
Audio files are (for me) the canonical example. A text file has no inherent bit-rate. An audio file being handled without knowledge of (even just) its sample rate has its semantics distorted or destroyed.
There's an awful lot of things you can do with the file approach, and I love it. Cross into the time domain and try to retain the same approach, and I say you're making a serious mistake.
What's worse is when the actual programming APIs (as opposed to just redirecting stdout to /dev/dsp) also fail to model the time aspect, and encourage programmers to think that you can just shovel data at a device without any consequences for your software's properties (like latency).
At some point you may get bitten by just nc’ing files around as tcp checksums alone are not that great. A lot of transfers or large files will at some point introduce errors. This is where an application layer error check may be desirable.
Is that really the case? (I mean i know in theory, but in practise does it matter?). Its not like http has its own checksum, and i've never had problems downloading over http (yes https does have better checksums, but i suspect it would just fail and not auto retry, which has never happened to me)
I've always verified the checksums of files transmitted via netcat and occasionally I have had different checksums. It's rare, and only on gigabyte+ files, but it has happened.
You should just use rsync - its been the best tool for transfering files between UNIXoids for the last 15-20 years for me and comes preinstalled with most distros (even macOS). It will take care of transferring only the required parts, and if you supply -c (slow!) it will even perform checksumming on both ends to assert files were correctly transferred and are bit-identical.
TCP checksums aren't that great, but you've usually also got lower layer CRCs which are much better. Though you can still get tripped up by misbehaving network hardware that corrupts a packet and then masks it by recomputing the CRC as the packet goes out again.
My favorite version of this is reading from /dev/dsp will capture audio from the mic. I would cat this audio to /dev/dsp on another host over ssh in the school lab.
When I was first learning Linux many years ago a friend and I got intoxicated and catted /dev/hda into /dev/dsp. It was all basically static with sometimes very structured patterns that we would try to guess as to what filetype was producing them. He had download and forgotten about a long uncompressed audio recording of a piano performance on his drive that suddenly started breaking through the static in chunks of varying length. We came to the conclusion that this was probably just what the kernel source sounded like.
If you've got a framebuffer console, I think you can cat to /dev/fb ... Although pixels are less friendly than audio, it's kind of helpful for identifying patterns if you preprocess so everything is shades of one color, or a byte -> color map anyway.
Change that to w=720 h=576 (for pal countries) and you can relive the glory days of analog TV static. Except not - mey memory seems to tell me it's more colourful. I guess it's to do with the limited chroma resolution in pal?
Analog color television color information is sent "out of band" from the point of view of black-and-white television (as a sideband frequency, with neat analog trickery to cancel out its effect on main signal). Color TV is backwards compatible. It's unlikely that random input happens to look like meaningful properly encoded color information, so television static is largely black and white.
I remember when I discovered that while in engineering school. I would try to pipe all kinds of files to see which ones had interesting acoustic signatures. I remember .iso files to be particularly interesting.
I remember back when ALSA was a hot new thing on Linux, and it kinda sorta solved the "only one app can play things at the same time" problem that existed with the traditional OSS.
Pipewire implements both ALSA psuedo-devices, the JACK API and the PulseAudio API. You only need a single daemon to address all possible audio I/O needs, something that PulseAudio could not do.
Pipewire is not finished at this point. It is being deployed "early" by some distros, apparently in the belief that it will help find bugs and help them being fixed.
> every couple of years when somebody releases a yet another Linux audio daemon.
You seem to be stuck in, oh, maybe 2008.
There hasn't been "yet another Linux audio daemon" in more than a decade. JACK came along in the early 2000's (I wrote it), and PulseAudio in 2004 or thereabouts. All that nonsense with esd, artsd etc. was over because the aughts were over.
The GP is about pipewire, and was complaining that it's "just another linux audio daemon". I concluded that it wasn't necessary to mention it in the context of my comment.
My problem is that all of these are incompatible. Woe be to whomever has an OSS app, an ALSA app, a JACK app, and a PulseAudio app, all of which want to run at the same time.
I don't get why this was never fixed at the kernel level. You have onions of layers.
PulseAudio never intended to replace Jack. And in fact, that's one of its biggest failings.
FWIW, I have recently switched from PulseAudio to PipeWire. I remembered how rough the switch from plain ALSA to PulseAudio was, and thus was utterly baffled how smooth the transition to PipeWire is. I just uninstalled PulseAudio, installed PipeWire, rebooted, and everything just worked, down to the Bluetooth headset that I never quite got to work well with PulseAudio.
Yeah, I had the same experience. With PipeWire it (mostly) just works, and reliably. The only thing I'm missing is always presenting the microphone as an usable device and only switching codecs/profile when the microphone is being used.
What I don't like is that audio systems on Linux are too complicated. For example, all that ALSA needs to do is to provide exclusive access to a device (only one program at a time) and send samples into it unmodified (no bit depth change, no resampling, no mixing, no volume adjustment etc). But open source developers cannot do such a simple thing. They added thousands of unnesessary features, hundreds config options and turned ALSA into a monster. When it should be just a dumb backend for PulseAudio.
OSS did not have the ability when it was removed from the kernel and replaced by ALSA, which did have that ability already.
There were (and are) many problems with the OSS API, a number of which continue to exist in the ALSA API too.
All serious audio APIs (plugins, or native audio I/O) use a pull model at the bottom of the stack, so that i/o is driven by the hardware. You can layer a push model (where software does blocking read/write calls whenever it wants) on top of that, but not the other way around.
And yes, OSS and ALSA both implement select/poll etc. for audio devices, but do not enforce the use of this model, resulting in the 2000s being filled with Linux (and *BSD) apps that couldn't function correctly without oodles of buffering.
It didn't, though, initially. On hardware that supported multiple streams, it worked (assuming the driver for that hardware knew how to do it), but for hardware that didn't, you had to use the ALSA dmix plugin, which for the longest time wasn't enabled by default because it was the cause of some audio artifacts.
I'd guess the device files just pass through the binary data to the hardware, and then it's up to the audio device/driver what their defaults are (probably PCM 16-bit 44.1khz)
> Is this a Linux feature or FreeBSD magic, as like the article seems to credit it?
Being able to just send wave data to the audio device "file" is pretty common on most systems that smell like Unix.
The netcat trickery from the article works on any platforms where netcat is available, what file formats are specifically supported varies by printer. Most will take text and Postscript (though some famous printers like the LaserJet 4 still had PS as an optional addon), anything more complicated is implementation-specific.
You used to be able to do that on Linux when its sound system was OSS ("Open Sound System", not "Open Source Software"), the same as FreeBSD uses today (I believe Linux still has an OSS compat layer). A long time ago the project lead was employed by a company to write support for some newer sound hardware, and decided to make those changes proprietary. The Linux folks decided to do something completely different, and we got ALSA, while some BSD folks decided to fork the last fully open source version of OSS and continue developing it.
The irony, of course, is that the proprietary version of OSS failed, and it ended up going open source again.
The difference is that on Linux, only one process can open /dev/dsp, which is why you need shims like aoss or padsp to run older games or other audio-programs without stopping all other sound sources / your sound server.
IMO, /dev/dsp was the right approach and should have been extended instead of being replaced with entirely different interfaces.
It also depends on which netcat you use. I usually use ncat (which comes with nmap) with the following invocations, and that never gave me any encoding/EOF/CRLF trouble:
# on sender
ncat --send-only --listen 12345 < file.zip
# then, on receiver
ncat --recv-only 1.2.3.4 12345 > file.zip
This is how this Hackernews printed several pages worth of the plaintext representation of a PDF on an office printer a few years ago before figuring out how to cancel the job.
Happens all the time when something goes wrong, like malformed files, wrong driver loaded, etc. All printers have an internal buffer, so when one goes crazy printing pages of gibberish, the only solution is to kill the job directly on the printer, or turn it off asap, then go to the computer and empty the print queue should something exist there as well, then do the same at the print server, if there is one.
The point is that once a print is started, all buffer will eventually end up to the printer, so it's the 1st device we must stop and the last one to restart once we're sure no data to print is left between the application and the paper, that is, not before all spoolers have been emptied.
If you have a single host, and a single printer, or your printer itself is both network-enabled and can manage its own print spool, direct TCP/IP printing may indeed work for you.
The value of CUPS is that it enables the CUPS-serving computer to run as a print server. This means not only print drivers (document format support --- typically plain text, Postscript, and one or more PDL (printer definition languages) & PCL (Printer Control Language), but status on the printer, queue management, job control, and access control. Note that if your printer is generally available on your local WiFi network, you might want to give more thought to that last element.
If those are overkill for you and your printer Just Works with generated output, then yes, you can get by without the complexity.
Note that you can also often telnet directly to the printer port.
Be aware of what you're trading off, though, and whether or not you actually need what CUPS, or direct network access, offers.
The CUPS web front-end also has rough edges; Apple maintains CUPS these days and OS X now ships with the web interface on :631 disabled.
If you still need a print server, it can be well worth the extra $100 or so to buy a business-class printer with an IPP server in it, so that CUPS runs on a chip inside the printer instead of on a separate computer. (Generally anything that supports "Airprint" will do this, and also at the mid range you avoid the "printers whose ink cartridges are more expensive than the printer" zone.)
Apple never really maintained CUPS. They hired the author, Michael Sweet, and he pretty much served as the printing team. He left Apple a couple years ago, and basically stalled their printing department.
He’s recently become head of the Printer Working Group, and they’re all pushing IPP Everywhere towards greater adoption. It’s a laudable effort.
After he left, all his cups commits to Apple's public CUPS repo stopped[1] and his work continued in the OpenPrinting fork of CUPS[2]. Interestingly though, it seems he resumed committing to the Apple repo in March. I'm glad CUPS on macOS isn't going to be left behind, but I'm curious what happened there.
I just tried this and while it worked, it was very slow. It takes a minute to start printing a page in a PDF, meanwhile nc is still hanging and sending the data, seemingly very slowly. The printer is constantly showing "Receiving Data" on its screen. The PDF is only 450KB.
Edit: It took about 5 mins to print a 3-page document, with long pauses between each page.
I suspect it's the printer doing the pdf->ps conversion. I have a beefy printer, so only run into this for large documents. But I'll cat through `gs` then to `nc` to do the pdf->ps conversion locally, and it is much faster.
That makes sense. That's why you want to do print spooling on client devices, which run on extremely fast CPUs in comparison. I guess that is why we don't send documents directly to printers.
YMMV as the printer needs to support PCL/PDL and not all HP network servers have it built-in.
HP chose to save some money by making dumb network cards that forced the PCL/PDL rendering on the Windows computer which made using Linux difficult.
I once did something similar to that on my previous job. A colleague came by asking who printed several pages of garbage. Me: "Sorry, I just inferred every reputable printer supported postscript". The problem: the job was an outsource for a pinter vendor. They obviously did not like my comment.
FWIW, the Internet Printing Protocol (and IPP Everywhere in particular) make printer setup in CUPS far, far easier, but distributors seem reluctant to encourage it. I wrote about my experiences with IPP back in June (https://lwn.net/Articles/857502/). I expect to never have to hassle with printer drivers again...
I own a HP MFP and for several years HPLIP generally worked for several to many months at a time, until it didn't. Me and the wiff both run Arch on our laptops (she doesn't know or care).
After a particularly rubbish time trying to get HPLIP working again after a pacman -Syu I did a literature search: Mr CUPS had deprecated everything apart from IPP Everywhere. So, I tried it out.
Me and the missus send docs to print and they get printed. I cannot remember the last failure (apart from running out of paper.) I also have toner levels monitored via Home Assistant.
I also have an office with several MFPs and inkjets, accessed via Windows (Server 2019) print queues. They are not so reliable. I often have to restart the Print Spooler service on our print server. To be fair, it is generally one queue that is at fault.
>To be fair, it is generally one queue that is at fault.
Printer drivers run in process as well as the port monitor (for older printers). You might find the situation improves if you use an inbox driver (one that comes with Windows) and/or the standard port monitor.
Magic in printing is still an arcanum. PPD files. Windows 10 as a print server. (some print devices are not networked)
Prelude files. in-printing logic like line reversal, density adjustments for photos. Double sided printing meta-signalling, n-up..
"oh, I don't need that stuff" fine, fine, nc is going to work for you, at the end of a bumpy road to a printer which supports it. And, right up until its 2am, you want to colour print that late birthday card for your favourite aunt, and the printer is stuck on nc...
I guess some people need CUPS but.. I have a $90 Brother laser printer and it has support for all kinds of protocols, and I can send multiple text files (9100 is the "raw data" port, not anything else) to it at the same time on port 9100 and it figures everything out and doesn't get confused.
I can send stuff to it over FTP, too.
$90!
I will never use CUPS again. I'll need a printer driver, yes, but I'll never need CUPS.
I used to do this at home all the time (from Linux though): networked printer with its own IP address and then good old netcat. I'd do it with PostScript files and send them to HP LaserJet 4M+: not only do these beauties speak PostScript natively, they can also be made to display the infamous "PC LOAD LETTER" message.
I'd try to find these printers used then I'd upgrade them: more RAM, more fonts, adding a network card inside the printer etc.
I still have several of these printers in a garage, some of them have printed more than 300 000 pages. They probably still work: some things were that good back then.
And, yup, there's something feeling magical when netcat'ing a .ps file (or another format) directly to the printer.
Proprietary, not PCI, but expansion slots, yes. On HPs it was called the MIO slot and later the EIO slot. If your printer came with a MIO card that only did serial and parallel, you could swap it for one that added networking.
And if it stops working, try re-soldering it in an oven before throwing away. Some infamous batches had bad soldering problems that can be fixed. See i.e. [0]
I recently tried that with my Epson Ecotank, but instead of rendering the document, it just printed out the literal source code. It then held the paper halfway through the machine until I sent enough newlines.
Because Apple "owns" both CUPS and iPhones, you can print from an iPhone directly to a printer shared on a Linux machine if they are on the same network.
My wife (not technical) figured this out one day and I didn't believe her at first that this would all "just work".
The point of CUPS and of server middleware in general like PulseAudio and what not is when multiple clients all want to send output streams to the same sink. Just sending the stream directly to a device with no middleman works fine provided 1) the stream is encoded in a way the device understands, and 2) no one else is trying to use it at the same time. For a shared network resource like a printer, unless you live alone and are the only user on your LAN, betting no one else is sending a job to the printer at the same time might be a rough bet.
Even when it works, there might be downsides, as some other comments are alluding to. The long print time one mentioned is likely because while you're lucky that your printer understands how to transcode pdf to ps in order to print a pdf, the onboard processor on the printer is much weaker than whatever you have on your computer. Also beware that if you're doing this on a radio network, I don't think netcat can encrypt the traffic. So don't be printing your credit card statements this way.
>2) no one else is trying to use it at the same time.
Printers are fine with accepting jobs from multiple clients and have been for a long time. After all this is pretty much standard practice for any small office without a server.
> Also beware that if you're doing this on a radio network, I don't think netcat can encrypt the traffic. So don't be printing your credit card statements this way.
Of course netcat does not encrypt anything. But if your printer accepts encrypted traffic you can send that over netcat. The question is what encryptions do the printers support? What protocol (stack) CUPS uses in the end? I have never heard that a printer certificate has expired, so my first guess would be it's all in cleartext.
Well, seems to be missing that for many, the point of CUPS is to take a regular, non-network enabled printer (parallel port, USB etc) and turn it into a networked printer...
That's definitely not true. That is a side-effect of CUPS, but CUPS exists very much in the same realm as PulseAudio and other service-enabling frameworks around hardware. It allows software/clients to interface with printers in a seamless and safe manner.
In a former life, I was doing tech support for UPS in the early-mid 90's I played around quite a bit with the commands to reset the various serial printers via echo and port targets. Not surprised things have moved beyond this.
KISS Linux taught me this! Once I realized I could read/write to IRC over netcat, I paired that will all the Bash magic KISS taught me and created a pure bash IRC client in 54LoC: https://github.com/retrohacker/irc-sh
Now you can browse HN, play IF, read news, and so on
over Gopher with just Busybox (sh, grep, tail and netcat requiredin the busybox build)
and an internet connection:
gopher://hngopher.com
gopher://mozz.us
Altough with just less, echo and nc:
echo / | nc mozz.us 70 | less
echo /long/selector/to/a/text/file.txt | ncmozz.us 70 | less
Crazy but it could work on heavily tiny restricted devices
such as a RetroBSD with nc, echo and less in a tiny
microcontroller.
It’s odd that the author does not mention that because this is FreeBSD, the recommended print spooler is the Berkeley line printer daemon, not CUPS. It’s discussed right on the page he linked to.
182 comments
[ 3.2 ms ] story [ 207 ms ] threadI was in grad school in a wetlab, so I had to label a ton of microcentrifuge tubes. Having a quick web interface e to generate the ZPL files that would be FTP’d to the printer let me avoid writing all of that out by hand.
It was such a simple system. And the FTP server was basically a queue, so you could print a bunch of labels at a time.
There is nothing magic about netcat. You are just dumping Postscript/PDF data on a TCP port the printer is listening on.
I can put `nc [printer_ip] 9100` there and it will just print. I just printed your comment this way.
That's cool! Thank you for teaching me something!
If I want to print multiple pages per sheet: Open PDF in Firefox, CTRL+P -> Save to PDF and configure the document. You can also pipe through `gs` to do this.
For _huge_ documents (100s of pages), I'll pipe through `gs` first to do the pdf->ps conversion on my laptops CPU. The printer can do it, it just takes a lot longer.
https://en.wikipedia.org/wiki/JetDirect#Protocols
(Very few printers in the world seem to be setup to use secure connections unfortunately)
netcat is also a secret weapon around the house. My girlfriend runs macOS, but it's way more reliable to just nc files to each other over wifi than deal with all the cloud and airdropping bullshit.
Consider lowly embedded linux. You COULD dig down deep into the documentation of which register, which interrupt, which special memory address needs to be written to interact with the right ports on a embedded linux board. All while adding a bunch of safeguards and checks to make sure "Only you are doing this".
Or, as if often the case, you can simply find the right /dev/xxxx device and read from it or write to it.
9 times out of 10, you'd not suffer any negative consequences from using the /dev/xxx system as intended and you get the bonus ability of being able to interact with the outside world using programming languages other than C.
Audio files are (for me) the canonical example. A text file has no inherent bit-rate. An audio file being handled without knowledge of (even just) its sample rate has its semantics distorted or destroyed.
There's an awful lot of things you can do with the file approach, and I love it. Cross into the time domain and try to retain the same approach, and I say you're making a serious mistake.
What's worse is when the actual programming APIs (as opposed to just redirecting stdout to /dev/dsp) also fail to model the time aspect, and encourage programmers to think that you can just shovel data at a device without any consequences for your software's properties (like latency).
It has never occurred to me to do that but it is actually quite an obvious thing to do when you "know" that everything is a file.
Any idea what the visual equivalent would be?
Perhaps:
head -c800 /dev/urandom > /dev/tty
Or:
mplayer -demuxer rawvideo -rawvideo w=80:h=60 /dev/urandom
Change that to w=720 h=576 (for pal countries) and you can relive the glory days of analog TV static. Except not - mey memory seems to tell me it's more colourful. I guess it's to do with the limited chroma resolution in pal?
mplayer -vf eq2=1:1:0:0.6 -demuxer rawvideo -rawvideo pal /dev/urandom
Analog color television color information is sent "out of band" from the point of view of black-and-white television (as a sideband frequency, with neat analog trickery to cancel out its effect on main signal). Color TV is backwards compatible. It's unlikely that random input happens to look like meaningful properly encoded color information, so television static is largely black and white.
It's for you.
Warning, headphone users: may hurt your ears. Trust me on the volume lowering.
With 16 bit samples and (default) two channels, you can recognizeably hear small integer values in your left ear. :)
Meanwhile, OSS on FreeBSD just worked.
I still roll my eyes and I don’t get surprised every couple of years when somebody releases a yet another Linux audio daemon.
Maybe it’s some kind of Linux tradition.
At least PipeWire is saner compared to PulseAudio.
In what way?
It is really important to run a sound daemon with realtime privileges. This is the only way to ensure no cracks.
You seem to be stuck in, oh, maybe 2008.
There hasn't been "yet another Linux audio daemon" in more than a decade. JACK came along in the early 2000's (I wrote it), and PulseAudio in 2004 or thereabouts. All that nonsense with esd, artsd etc. was over because the aughts were over.
Even though i don't do audio on Linux.
While it supports the same APIs as Pulseaudio, it's still a new audio (and video) daemon.
I don't get why this was never fixed at the kernel level. You have onions of layers.
It is the audio solution for Linux.
PipeWire does video too, and when combined with a compatible Wayland compositor, serves as a replacement for remote X11.
Don't worry, THIS time we got right FOR SURE.
FWIW, I have recently switched from PulseAudio to PipeWire. I remembered how rough the switch from plain ALSA to PulseAudio was, and thus was utterly baffled how smooth the transition to PipeWire is. I just uninstalled PulseAudio, installed PipeWire, rebooted, and everything just worked, down to the Bluetooth headset that I never quite got to work well with PulseAudio.
There were (and are) many problems with the OSS API, a number of which continue to exist in the ALSA API too.
All serious audio APIs (plugins, or native audio I/O) use a pull model at the bottom of the stack, so that i/o is driven by the hardware. You can layer a push model (where software does blocking read/write calls whenever it wants) on top of that, but not the other way around.
And yes, OSS and ALSA both implement select/poll etc. for audio devices, but do not enforce the use of this model, resulting in the 2000s being filled with Linux (and *BSD) apps that couldn't function correctly without oodles of buffering.
I used a script to toggle the SPDIF output stream of my Soundblaster Live to get track marks on the Mini Disc player recording the output.
Being able to just send wave data to the audio device "file" is pretty common on most systems that smell like Unix.
The netcat trickery from the article works on any platforms where netcat is available, what file formats are specifically supported varies by printer. Most will take text and Postscript (though some famous printers like the LaserJet 4 still had PS as an optional addon), anything more complicated is implementation-specific.
The irony, of course, is that the proprietary version of OSS failed, and it ended up going open source again.
IMO, /dev/dsp was the right approach and should have been extended instead of being replaced with entirely different interfaces.
I also setup a horrible video chat in bash using just vlc and netcat. Audio works better like this
I never bothered with a printing system.. I'd just cat a ps file to /dev/lp0
I'd never though of that, so simple!
My only issue is that it seems to hang after it's done. What am I missing?Netcat has plenty of (confusing) options, but there's usually a solution.
The value of CUPS is that it enables the CUPS-serving computer to run as a print server. This means not only print drivers (document format support --- typically plain text, Postscript, and one or more PDL (printer definition languages) & PCL (Printer Control Language), but status on the printer, queue management, job control, and access control. Note that if your printer is generally available on your local WiFi network, you might want to give more thought to that last element.
If those are overkill for you and your printer Just Works with generated output, then yes, you can get by without the complexity.
Note that you can also often telnet directly to the printer port.
Be aware of what you're trading off, though, and whether or not you actually need what CUPS, or direct network access, offers.
If you still need a print server, it can be well worth the extra $100 or so to buy a business-class printer with an IPP server in it, so that CUPS runs on a chip inside the printer instead of on a separate computer. (Generally anything that supports "Airprint" will do this, and also at the mid range you avoid the "printers whose ink cartridges are more expensive than the printer" zone.)
Apple never really maintained CUPS. They hired the author, Michael Sweet, and he pretty much served as the printing team. He left Apple a couple years ago, and basically stalled their printing department.
He’s recently become head of the Printer Working Group, and they’re all pushing IPP Everywhere towards greater adoption. It’s a laudable effort.
Google shut down Google Cloud Print in 2020 and moved to IPP.
Microsoft announced that they were moving to IPP (branded as Universal Print) in 2020 as well.
CUPS still exists because legacy printers don't have built in IPP support.
1. https://github.com/apple/cups/graphs/contributors 2. https://github.com/OpenPrinting/cups/graphs/contributors
Edit: It took about 5 mins to print a 3-page document, with long pauses between each page.
http://danieru.com/2013/06/06/what-is-port-9100-how-to-print...
While you're at it you may as well try out the printer exploit kit https://github.com/RUB-NDS/PRET
There is no need to suffer if that will do the job.
Pragmatism is not the enemy of perfection.
After a particularly rubbish time trying to get HPLIP working again after a pacman -Syu I did a literature search: Mr CUPS had deprecated everything apart from IPP Everywhere. So, I tried it out.
Me and the missus send docs to print and they get printed. I cannot remember the last failure (apart from running out of paper.) I also have toner levels monitored via Home Assistant.
I also have an office with several MFPs and inkjets, accessed via Windows (Server 2019) print queues. They are not so reliable. I often have to restart the Print Spooler service on our print server. To be fair, it is generally one queue that is at fault.
Printer drivers run in process as well as the port monitor (for older printers). You might find the situation improves if you use an inbox driver (one that comes with Windows) and/or the standard port monitor.
Now printers integrate the IPP functionality.
Magic in printing is still an arcanum. PPD files. Windows 10 as a print server. (some print devices are not networked)
Prelude files. in-printing logic like line reversal, density adjustments for photos. Double sided printing meta-signalling, n-up..
"oh, I don't need that stuff" fine, fine, nc is going to work for you, at the end of a bumpy road to a printer which supports it. And, right up until its 2am, you want to colour print that late birthday card for your favourite aunt, and the printer is stuck on nc...
I can send stuff to it over FTP, too.
$90!
I will never use CUPS again. I'll need a printer driver, yes, but I'll never need CUPS.
I'd try to find these printers used then I'd upgrade them: more RAM, more fonts, adding a network card inside the printer etc.
I still have several of these printers in a garage, some of them have printed more than 300 000 pages. They probably still work: some things were that good back then.
And, yup, there's something feeling magical when netcat'ing a .ps file (or another format) directly to the printer.
[0] https://community.spiceworks.com/how_to/2077-how-to-bake-an-...
I was only half disappointed.
That is what a form feed character is for (ASCII 0x0C).
My wife (not technical) figured this out one day and I didn't believe her at first that this would all "just work".
I've printed from my phone to my pi CUPS server. Even Windows 10 understands IPP.
It actually blew my mind after doing Linux for 10 years. "Everything is a file" isn't a lie.
http://tkrh.co.uk/netcat.html
Untested, but code reviewed with one eye.
Even when it works, there might be downsides, as some other comments are alluding to. The long print time one mentioned is likely because while you're lucky that your printer understands how to transcode pdf to ps in order to print a pdf, the onboard processor on the printer is much weaker than whatever you have on your computer. Also beware that if you're doing this on a radio network, I don't think netcat can encrypt the traffic. So don't be printing your credit card statements this way.
https://patrick.wagstrom.net/weblog/2003/05/23/lpdforfunandm...
Printers are fine with accepting jobs from multiple clients and have been for a long time. After all this is pretty much standard practice for any small office without a server.
Of course netcat does not encrypt anything. But if your printer accepts encrypted traffic you can send that over netcat. The question is what encryptions do the printers support? What protocol (stack) CUPS uses in the end? I have never heard that a printer certificate has expired, so my first guess would be it's all in cleartext.
https://www.freedomit.co.nz/kb-centos/76-using-port-9100-to-...
Nice to see that .pdf pretty much just works.
With Plan9/9front everything involving TLS could me made a script and an Acme frontend, except for video.
Also, check this for gopher:
https://github.com/hb9kns/nago
Now you can browse HN, play IF, read news, and so on over Gopher with just Busybox (sh, grep, tail and netcat requiredin the busybox build) and an internet connection:
gopher://hngopher.com
gopher://mozz.us
Altough with just less, echo and nc:
Crazy but it could work on heavily tiny restricted devices such as a RetroBSD with nc, echo and less in a tiny microcontroller.Equally cool and terrifying. I can dig up my notes if someone is interested.