Live data from Hacker News

Bye CUPS: Printing with Netcat

retrohacker.substack.com

141–150 of 183 posts

Re: Bye CUPS: Printing with Netcat

#141
post #80
post #55

Earlier quoted context omitted.

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. Meanwhile, OSS on FreeBSD just worked.

OSS got that ability decades ago, yet we still have ALSA and then the others :(

I remember the mixer interface (channel volumes, mute states, routing matrix) was far superior with ALSA.

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.

Re: Bye CUPS: Printing with Netcat

#142
post #139

I used to dread setting up printers on any operating system. I've done it countless of times with Linux, Windows and macOS, and it's been quite common to have some kind of fight with the printer until I get my paper out. Only recently, by buying a Brother laser printer at home, and setting all my machines to use NixOS, I haven't been needing to think about printer problems anymore. All I need is this piece of config,…

Your config files make we wanna learn NixOs, but i'm in the process of backing up this one and installing Tumbleweed on it.

Thank you for sharing.

Re: Bye CUPS: Printing with Netcat

#143
post #116
post #55

Earlier quoted context omitted.

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. Meanwhile, OSS on FreeBSD just worked.

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.

dmix is what I meant. But you had to use ALSA to use dmix, so in practice, it was the biggest reason to switch for most.

Re: Bye CUPS: Printing with Netcat

#144
post #36

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…

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…

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.

Re: Bye CUPS: Printing with Netcat

#145

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…

I suppose if you have a printer that doesn't support PostScript or PDF then you could pipe the output through GhostScript. This is what CUPS is relying on anyway.

Right, there's no magic pixie dust in CUPS that you can't manually reproduce using a concoction of software packages, command line incantations and maybe some scripts. But then you're just re-implementing CUPS, manually.

Re: Bye CUPS: Printing with Netcat

#146

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 never print "as bitmap" if you could avoid it. OTOH printing "flat" postscript was very fast and yielded much better quality. I think the printers allowed loadable fonts and often had some of the standards (Times, Arial) pre-loaded.

Re: Bye CUPS: Printing with Netcat

#148
post #47
post #37

Earlier quoted context omitted.

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.

Re: Bye CUPS: Printing with Netcat

#149

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…

Is there any guide on how to make a Linux-based print server which would be autodetectable by all the major OSes? I feel like we need a dedicated print server for our office (where there are many computers running Ubuntu, Windows and MacOS) because the printer doesn't work reliably enough. I have never actually seen such a scenario in the wild - people seem to always connect to network printers directly (they also used LPT and USB printers shared via the standard means of Windows in the past).

Re: Bye CUPS: Printing with Netcat

#150
I hated the change to CUPS. I liked both the simplicity and complexity that I had going with lpd. The system itself was simple and my filters were a beautiful mix of AWK and Ghostscript. I even had a queue to email PDFs. I guess CUPS works fine but just working out of the box is not very fun.
Post reply on HN