Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bye CUPS: Printing with Netcat

retrohacker.substack.com

Post reply on HN
Print view View original

161–170 of 183 posts

Re: Bye CUPS: Printing with Netcat

#161

Post by iso1631 »

axiolite wrote: post #127
gerdesj wrote: post #54

Earlier quoted context omitted.

Good skills. 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?

> 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

> 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?

Re: Bye CUPS: Printing with Netcat

#164

Post by chriscappuccio »

jcrawfordor wrote: post #97

While the article is correct, it omits most of the actual function of CUPS. Many printers are capable of accepting various types of documents directly over the network, with postscript, HP PCL, and PDF being commonly supported---and ASCII pretty much universally supported. The problem is that few printers support _all_ of these standards. Postscript, for example, is surprisingly complex to implement in practice, whic…

if you like nc, lpr/lpd is a natural graduation.

if you like CUPS, lpr/lpd with ghostscript processing is a natural grauduation. CUPS is a horrid mess.

Re: Bye CUPS: Printing with Netcat

#165

Post by chriscappuccio »

jim-jim-jim wrote: post #8

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 eventuall…

you can also use lpr/lpd to spool files, even over the network, to your local speakers

Re: Bye CUPS: Printing with Netcat

#166

Post by NelsonMinar »

What if you put CUPS... in the printer? And made it a network device?

Unix printing was designed in an era when most printers were dumb serial or parallel devices chained directly to a computer. Or if they had an ethernet jack, had some bizarro proprietary system that was very minimal and included no memory, queueing, or ability to interpret complex formats like PDF. That is the environment CUPS was designed for. And it was a huge improvement over the old lp system. The "l" in "lp" literally means "line".

Like everything else in the computer world printers have gotten a lot more capable. They may literally be running CUPS. That's why you don't need another complex print spooler and format convertor on your client machine.

Re: Bye CUPS: Printing with Netcat

#167

Post by coldpie »

bitwize wrote: post #155
woofie11 wrote: post #153

Earlier quoted context omitted.

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.

PipeWire solves this problem. It provides ALSA, JACK, and PulseAudio emulation (no one has actually used OSS on Linux in decades). 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.

Replace "PipeWire" with "PulseAudio" and hey look it's 2010 all over again.

Don't worry, THIS time we got right FOR SURE.

Re: Bye CUPS: Printing with Netcat

#168

Post by WhyNotHugo »

jim-jim-jim wrote: post #8

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 eventuall…

> 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.

I'd never though of that, so simple!

    # On the receiver
    nc -l 9000 > output.file

    # On the sender
    nc 172.17.0.7 9000
My only issue is that it seems to hang after it's done. What am I missing?

Re: Bye CUPS: Printing with Netcat

#169

Post by WhyNotHugo »

PaulDavisThe1st wrote: post #85
rescbr wrote: post #56

Earlier quoted context omitted.

Rinse & repeat when every desktop environment brought their own audio daemons, then later PulseAudio and now PipeWire. 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.

> 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.

You seem to have missed pipewire.

While it supports the same APIs as Pulseaudio, it's still a new audio (and video) daemon.

Re: Bye CUPS: Printing with Netcat

#170

Post by jcrawfordor »

captainmuon wrote: post #146
jcrawfordor wrote: post #97

While the article is correct, it omits most of the actual function of CUPS. Many printers are capable of accepting various types of documents directly over the network, with postscript, HP PCL, and PDF being commonly supported---and ASCII pretty much universally supported. The problem is that few printers support _all_ of these standards. Postscript, for example, is surprisingly complex to implement in practice, whic…

> Further, printers are very slow at rasterizing, and so while support for PDF rasterization is very common you probably don't want to use it. That's interesting. Back in the day (of HP LaserJet 4L and similar), I learned that rasterizing on the PC and sending to the printer was very slow because printers had slow connections and little memory. The resolution was also limited and it looked blocky. The rule was to nev…

The big issue is that, back when, printed documents were much simpler. Printers offer a set of embedded fonts that makes it very quick and easy to print simple text documents, if you are okay with one of the printer's embedded fonts. You just need to send a couple commands to set up the font parameters and then the text. PCL and moreso Postscript also give you some vector drawing capability that makes printing line art in vector format very efficient.

But the nature of printing has changed! People now want to print things in all kinds of arbitrary fonts, which requires either rasterizing to print resolution (which is a lot, 300-600dpi) or sending the printer all the outlines as vector instructions. Postscript and PCL take different approaches to this and sometimes different print stacks do as well. And then add graphics, and 99% of documents you encounter these days provide all graphics in raster format in the first place. The result is that something, either the host or the printer, needs to take a raster graphic (which can even just be little icons) and interpolate them to whatever dot pitch the printer is using. That tends to be the real killer... that interpolation can take a printer a very long time. Usually there's some way in the PCL (exposed via the printer driver) that you can tell the printer to interpolate to a lower DPI which will speed things up, but make your images look worse.

Unfortunately sending 600dpi graphics over the network can still be kind of slow and does contribute to the "Receiving Data..." and time to first page even with modern printers and drivers. Most laser printers have a pretty poor TTFP anyway, though, so it's not too big of a deal.

Post reply on HN