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

171–180 of 183 posts

Re: Bye CUPS: Printing with Netcat

#171

Post by PaulDavisThe1st »

WhyNotHugo wrote: post #169
PaulDavisThe1st wrote: post #85

Earlier quoted context omitted.

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

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.

Re: Bye CUPS: Printing with Netcat

#172

Post by PaulDavisThe1st »

dredmorbius wrote: post #115
PaulDavisThe1st wrote: post #82

Earlier quoted context omitted.

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…

Many character devices do in fact have a bitrate.

It's mostly syntactic though, not semantic.

Re: Bye CUPS: Printing with Netcat

#173

Post by bcook »

littlecranky67 wrote: post #148
bcook wrote: post #47

Earlier quoted context omitted.

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.

I was primarily using Android's busybox netcat, but I agree; there's always a better tool.

Re: Bye CUPS: Printing with Netcat

#174

Post by bcook »

WhyNotHugo wrote: post #168
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?

Probably something about EOL, end-of-feed, CRLF-translation or something similar?

Netcat has plenty of (confusing) options, but there's usually a solution.

Re: Bye CUPS: Printing with Netcat

#175

Post by ta988 »

m45t3r wrote: post #104
ta988 wrote: post #77

Earlier quoted context omitted.

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

Double check that you're running PipeWire with rtkit (this is the default with PulseAudio, AFAIK it is not the default yet on PipeWire). It is really important to run a sound daemon with realtime privileges. This is the only way to ensure no cracks.

Thanks I'll check that

Re: Bye CUPS: Printing with Netcat

#176

Post by axiolite »

iso1631 wrote: post #161
axiolite wrote: post #127

Earlier quoted context omitted.

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

You can reduce the saturation as desired (0.6 below):

mplayer -vf eq2=1:1:0:0.6 -demuxer rawvideo -rawvideo pal /dev/urandom

Re: Bye CUPS: Printing with Netcat

#177

Post by majewsky »

coldpie wrote: post #167
bitwize wrote: post #155

Earlier quoted context omitted.

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.

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.

Re: Bye CUPS: Printing with Netcat

#178

Post by majewsky »

bcook wrote: post #174
WhyNotHugo wrote: post #168

Earlier quoted context omitted.

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

Probably something about EOL, end-of-feed, CRLF-translation or something similar? Netcat has plenty of (confusing) options, but there's usually a solution.

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

Re: Bye CUPS: Printing with Netcat

#179

Post by account42 »

kelnos wrote: post #105
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 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…

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.

Post reply on HN