17 ms·

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 exac

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 eventually did things the proper way with OSS and finally sndio on OpenBSD, but direct, universal interfaces like files invite that initial exploration and help you get things done quick and easy. netcat is also a secret weapon around the house. 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.

cogman10 5y ago
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, as if often the case, you can simply find the right /dev/xxxx device and read from it or write to it. 9 times out of 10, you'd not suffer any negative consequences from using the /dev/xxx system as intended and you get the bonus ability of being able to interact with the outside world using programming languages other than C.
- Denvercoder9 5y ago
  I don't think this has anything to do with the file approach per se, just with using an interface at a higher abstraction level.
- PaulDavisThe1st 5y ago
  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 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).
  - dredmorbius 5y ago
    Many character devices do in fact have a bitrate.
    - PaulDavisThe1st 5y ago
      It's mostly syntactic though, not semantic.
dv_dt 5y ago
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.
- bawolff 5y ago
  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)
  - bcook 5y ago
    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.
    - littlecranky67 5y ago
      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.
      - bcook 5y ago
        I was primarily using Android's busybox netcat, but I agree; there's always a better tool.
- technothrasher 5y ago
  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.
phamilton 5y ago
My favorite version of this is reading from /dev/dsp will capture audio from the mic. I would cat this audio to /dev/dsp on another host over ssh in the school lab.
krrrh 5y ago
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 varying length. We came to the conclusion that this was probably just what the kernel source sounded like.
- gerdesj 5y ago
  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?
  - reshie 5y ago
    ffmpeg can point directly to the webcam under /dev/.
  - toast0 5y ago
    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.
  - anthk 5y ago
    Plan9's /dev/draw.
  - axiolite 5y ago
    > 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
    - iso1631 5y ago
      > 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?
int_19h 5y ago
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.
- rescbr 5y ago
  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.
  - feanaro 5y ago
    > At least PipeWire is saner compared to PulseAudio. In what way?
    - PaulDavisThe1st 5y ago
      Pipewire implements both ALSA psuedo-devices, the JACK API and the PulseAudio API. You only need a single daemon to address all possible audio I/O needs, something that PulseAudio could not do.
      - jandrese 5y ago
        That doesn't sound like a recipe for sanity.
        yobert 5y ago
        My experience with pipewire is it works better than pulseaudio, is faster, has lower latency, and fewer bugs. And it gets better all the time!
  - ta988 5y ago
    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
chrisseaton 5y ago
How do the device files know what format the audio data is in?
- andrecarini 5y ago
  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)
- ajnin 5y ago
  It doesn't, it just plays the data as PCM and with whatever sample format and sample rate it is currently configured for.
sverhagen 5y ago
Is this a Linux feature or FreeBSD magic, as like the article seems to credit it?
- wolrah 5y ago
  > 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.
- nix23 5y ago
  It's Unix magic remembered in the FreeBSD Handbook.
kelnos 5y ago
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 we got ALSA, while some BSD folks decided to fork the last fully open source version of OSS and continue developing it. The irony, of course, is that the proprietary version of OSS failed, and it ended up going open source again.
- anthk 5y ago
  ALSA has compat modules for OSS.
- account42 5y ago
  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.
grifball 5y ago
Yeah I did this at work recently with netcat. Our file sharing "solution" wasn't going to work so I just thought to try it for the hell of it. I also setup a horrible video chat in bash using just vlc and netcat. Audio works better like this
TylerE 5y ago
I remember back in the day when I had some old HP behemoth my dad's office was throwing out... a 4100 or something like that. I never bothered with a printing system.. I'd just cat a ps file to /dev/lp0
chriscappuccio 5y ago
you can also use lpr/lpd to spool files, even over the network, to your local speakers
WhyNotHugo 5y ago
> 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 < input.file My only issue is that it seems to hang after it's done. What am I missing?
- bcook 5y ago
  Probably something about EOL, end-of-feed, CRLF-translation or something similar? Netcat has plenty of (confusing) options, but there's usually a solution.
  - majewsky 5y ago
    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 # then, on receiver ncat --recv-only 1.2.3.4 12345 > file.zip

cogman10 5y ago

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, as if often the case, you can simply find the right /dev/xxxx device and read from it or write to it. 9 times out of 10, you'd not suffer any negative consequences from using the /dev/xxx system as intended and you get the bonus ability of being able to interact with the outside world using programming languages other than C.

Denvercoder9 5y ago
I don't think this has anything to do with the file approach per se, just with using an interface at a higher abstraction level.
PaulDavisThe1st 5y ago
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 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).
- dredmorbius 5y ago
  Many character devices do in fact have a bitrate.
  - PaulDavisThe1st 5y ago
    It's mostly syntactic though, not semantic.

dv_dt 5y ago

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.

bawolff 5y ago
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)
- bcook 5y ago
  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.
  - littlecranky67 5y ago
    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.
    - bcook 5y ago
      I was primarily using Android's busybox netcat, but I agree; there's always a better tool.
technothrasher 5y ago
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.

phamilton 5y ago

My favorite version of this is reading from /dev/dsp will capture audio from the mic. I would cat this audio to /dev/dsp on another host over ssh in the school lab.

krrrh 5y ago

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 varying length. We came to the conclusion that this was probably just what the kernel source sounded like.

gerdesj 5y ago
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?
- reshie 5y ago
  ffmpeg can point directly to the webcam under /dev/.
- toast0 5y ago
  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.
- anthk 5y ago
  Plan9's /dev/draw.
- axiolite 5y ago
  > 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
  - iso1631 5y ago
    > 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?

int_19h 5y ago

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.

rescbr 5y ago
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.
- feanaro 5y ago
  > At least PipeWire is saner compared to PulseAudio. In what way?
  - PaulDavisThe1st 5y ago
    Pipewire implements both ALSA psuedo-devices, the JACK API and the PulseAudio API. You only need a single daemon to address all possible audio I/O needs, something that PulseAudio could not do.
    - jandrese 5y ago
      That doesn't sound like a recipe for sanity.
      - yobert 5y ago
        My experience with pipewire is it works better than pulseaudio, is faster, has lower latency, and fewer bugs. And it gets better all the time!
- ta988 5y ago
  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

chrisseaton 5y ago

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

andrecarini 5y ago
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)
ajnin 5y ago
It doesn't, it just plays the data as PCM and with whatever sample format and sample rate it is currently configured for.

sverhagen 5y ago

Is this a Linux feature or FreeBSD magic, as like the article seems to credit it?

wolrah 5y ago
> 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.
nix23 5y ago
It's Unix magic remembered in the FreeBSD Handbook.

kelnos 5y ago

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 we got ALSA, while some BSD folks decided to fork the last fully open source version of OSS and continue developing it. The irony, of course, is that the proprietary version of OSS failed, and it ended up going open source again.

anthk 5y ago
ALSA has compat modules for OSS.
account42 5y ago
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.

grifball 5y ago

Yeah I did this at work recently with netcat. Our file sharing "solution" wasn't going to work so I just thought to try it for the hell of it. I also setup a horrible video chat in bash using just vlc and netcat. Audio works better like this

TylerE 5y ago

I remember back in the day when I had some old HP behemoth my dad's office was throwing out... a 4100 or something like that. I never bothered with a printing system.. I'd just cat a ps file to /dev/lp0

chriscappuccio 5y ago

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

WhyNotHugo 5y ago

> 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 < input.file My only issue is that it seems to hang after it's done. What am I missing?

bcook 5y ago
Probably something about EOL, end-of-feed, CRLF-translation or something similar? Netcat has plenty of (confusing) options, but there's usually a solution.
- majewsky 5y ago
  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 # then, on receiver ncat --recv-only 1.2.3.4 12345 > file.zip