Live data from Hacker News

Bye CUPS: Printing with Netcat

retrohacker.substack.com

61–70 of 183 posts

Re: Bye CUPS: Printing with Netcat

#61
post #54
post #36

Earlier quoted context omitted.

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

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?

ffmpeg can point directly to the webcam under /dev/.

Re: Bye CUPS: Printing with Netcat

#63
post #51

You can do the same with IRC and a ksh/Perl script implementing a loop and PING, Gopher, FTP, MUDs, Finger and NNTP servers. With Plan9/9front everything involving TLS could me made a script and an Acme frontend, except for video.

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

I'd prefer to have one based on nc and sh as it's more portable (think busybox systems).

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:

     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.

Re: Bye CUPS: Printing with Netcat

#64

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…

How do the device files know what format the audio data is in?

Re: Bye CUPS: Printing with Netcat

#65
post #51

You can do the same with IRC and a ksh/Perl script implementing a loop and PING, Gopher, FTP, MUDs, Finger and NNTP servers. With Plan9/9front everything involving TLS could me made a script and an Acme frontend, except for video.

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

Also, I forgot, poor man's dictionary:

   dict(){ echo "define * $1\\n\\q" | nc dict.org 2628 | less ; }

   dict unix

Re: Bye CUPS: Printing with Netcat

#66
Kinda similar, we could use LPT1 on DOS as a file and write to it or even just do a "copy" on the command line ( remember "copy CON LPT1" ?). This was pretty much the default way to print, with applications sending ESC sequences to pretty up the page.

The problems were to do with handling problems like printer jams, out of paper etc which require, in essence, a partial resend and was tricky. Print spoolers on all platforms managed some of this complexity.

The greater memory on printers and the ability to locally retry a page make it simpler today, but only in the most casual settings. If you want to print anything substantial, treating a printer as a file is not really a good idea.

Re: Bye CUPS: Printing with Netcat

#68
post #31

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…

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.

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.

Re: Bye CUPS: Printing with Netcat

#69
post #54
post #36

Earlier quoted context omitted.

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

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?

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.

Re: Bye CUPS: Printing with Netcat

#70

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…

How do the device files know what format the audio data is in?

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)
Post reply on HN