81–90 of 183 posts
Have fun printing a shipping label from your phone using Netcat.
My wife (not technical) figured this out one day and I didn't believe her at first that this would all "just work".
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…
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, a…
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).
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) &…
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…
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.
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…
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.
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.
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.
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.
> At least PipeWire is saner compared to PulseAudio. In what way?
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 :(
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.
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…
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.
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.
Since I switched to pipewire, my audio is crackling every time the cpu is loaded (a ryzen 7...) not even jack was struggling with that on this machine