This is really cool. I have a little node.js script I wrote that generates a funky little beat I call "egypt.js"[0] and outputs the PCM data to stdout, just for weird things like this.
My local WSL1 install of ffmpeg has an issue with the LAME encoder so using a few extra pipes I was able to get this working! Confirmed with a friend they were able to listen across the planet.
I think the dissenting / mocking comments here are missing the spirit of the post.
Since bash can evoke any Turing complete program, feasibly anything could be done with one line of bash.
The authors intent as I saw was to show what that line was. Would you have known without this article?
Whether or not people are just being sarcastic, I feel we should definitely not mock but rather encourage any open and free attempts at teaching us cool things that are more novel than the “how to get started on Linux” type bs the market is inundated with.
"To solve this problem I wrote a simple server that runs in the cloud which can handle any number of realtime broadcasts uploaded using a simple curl command. This allows you to essentially broadcast radio feeds with a single line. My solution to the problem of broadcasting audio without port-forwarding was to create a free and public “dummy” server that handles any incoming traffic and forwards to any number of connected clients. This server keeps track of connected clients and routes incoming packets to them, otherwise discarding the packets."
If the author had perhaps titled their post "I wrote a multiplexing server for audio streams" it might go over better, although that doesn't have the proper click-bait appeal.
I think the spirit of the post got overrun by (likely accidentally) making the title so clickbaity.
Bash can run any program, that's why you don't advertise running a program with it in your title unless the program is (at least mostly) in bash which is an interesting constraint to go check out. There are some really whacky crazy interesting things done in actual bash scripting including internet applications like this via bash's builtin /dev/tcp functionality... come to think of it this might actually be one of those crazy "I did it in pure bash"able things.
I'm sure most on HN knew you could pipe the output of a media application like ffmpeg into something like curl instead of locally. All of the exact options and methodology used here off the top of their head? Very unlikely but is that really what this title sets the expectation of?
I don't think mocking is the best recourse but I'm not sure it's much more useful to argue the author should only be receiving blind encouragement in cases like this either. Like I said I highly doubt the author had any malice when changing the title for HN but I also understand why many don't want to blindly encourage posts where the title can be so misleading/confusing.
Ironically "Creating my own free and easy to use internet radio station host" would probably have gotten even more attention with almost never of the pushback and the project work on norns is probably worth its own post.
I like how you redacted the target but not the password – though I’m pretty sure the real password is alphanumeric and based on a family member: http://www.bash.org/?quote=244321
One of the actual big-P Passwords decades ago was actually
0000000
> during the height of the Cold War, the US military put such an emphasis on a rapid response to an attack on American soil, that to minimize any foreseeable delay in launching a nuclear missile, for nearly two decades they intentionally set the launch codes at every silo in the US to 8 zeroes
Wow! From an InfoSec perspective, that’s hard to believe but when you understand that every large group of humans has competing interests and large bureaucracies don’t have perfect chains of command, it’s totally believable. I guess it’s a high-stakes example of the difficulty in getting the right balance between security and convenience.
Edit: on a related note, a few years ago I was shocked to hear the story of how a simple accident while carrying out routine maintenance of liquid-fuelled nuclear missiles almost resulted in a devastating nuclear explosion in the American heartland: https://www.thisamericanlife.org/634/human-error-in-volatile...
It's also visible in the process table (ps auxww). It can be erased by rewriting the arguments from inside the process (I think this is OS-specific, not the same as changing argv in-place), but that is a race condition.
The safe way is to either read it from stdin/fd (maybe call isatty(3) to check if someone doesn't echo password | ./foo), or open a file (check if permissions are 600). You could also have a named socket (check permissions!) talking to an authn agent, which could be doing some other fancy stuff like pinging your smartwatch to confirm, etc.
where the gpg key has a password and is stored on a hardware dongle that doesn't allow copying the private key off. If you really want to be fancy, there are some hardware security keys that also require a biometric to confirm.
The other option is something like Hasicorp Vault, but we're way out of "one line bash" territory :p
This article isn't very useful for a "one liner radio", but I use icecast2 in a couple of ways
1. I host a VGM radio [1]
2. I use a combination of icecast2 and darkice to have a full home audio networking.
With the home audio network, there's a lot to optimize, but I haven't implemented it much more to experiment with it further.
Basically I have a Ubuntu Desktop VM on my home server.
A long range bluetooth receiver [2] is feed from Proxmox host into the VM.
The audio from the Bluetooth source (say your phone or your computer) is pulled from Darkice and renders an MP3 file/stream into Icecast2, which then broadcasts it on 10.0.0.10:8000/home
I can use devices like Raspberry Pis to continuously listen on that URL for playback and play if it's available. There's CLI audio players like mpg123.
This could be used for whole home audio playback, but there's weird quirks to deal with like the delay between the audio in and when you hear it, as well as it becoming desynced over time.
It can also be setup in reverse where a RPi ingests audio from it's audio jack and sends it to the audio hub VM and the audio hub sends it out to the network.
> weird quirks to deal with like the delay between the audio in and when you hear it, as well as it becoming desynced over time.
You may want to check out Snapcast. I use it to distribute audio to 6 clients on diverse hardware (several Raspberry Pis, a Windows PC, a Linux PC) and it handles synchronized playback very well, after tweaking the latency offsets for each device (once).
Yes, I highly recommend it. You can express your broadcast in a nice functional DSL. We are running a community radio and use it there in production for couple of years now.[0] (Ours linked is a very suboptimal solution but performs w/o any hiccup even though we got some pretty specific constraints.) We could've gotten many more mileage out of it, if we really would have had the time to focus on creating libs and functions for our specific needs as the API is really powerful, the docs are a good read. Also, on a more subjective note: It's developed by nice guys and even if some built-ins fail from time-to-time since there's no real rush to update we can help test w/ them & give some input on features.
I did something similar so I could listen to my vinyl records over an in home ip radio station on my Sonos without buying their $500 box that lets you add arbitrary audio input.
Nobody has problems with dropped TCP connections when streaming?
Tried icecast2 on several servers at distinct hosters and audio tag on various browsers and platforms, in maybe tens of minutes it always seized up. I had to add script to client page had to detect it and reconnect, the pauses were annoying, gave up.
Did not dig deeper seems as if routers drop the connection when there are no data transmitted in one direction.
The original title did include the word "bash" (it was the one and only instance of the word "bash"). I removed this word from the main article because including the word "bash" superseded a conversation that was nominally about internet broadcasting. Maybe the title of this HN submission can be changed too.
I appreciate the commenters that picked up on the main theme of article and shared some interesting links! But I did enjoy the humorous comments too (who doesn't enjoy some good-natured bashing (pun-intended)).
If I write a complex piece of software that does something even marginally interesting, I'm going to post it to HN with a similar title. After all, I'm sure I can execute it with one line of bash, so the title is appropriate, right?
Did you read the article? It's probably the most honest version of "one line of bash" given how prolific ffmpeg is, and the fact that, beyond one line of shell commands, I was able to listen to the streamed audio in my browser.
What more do you want? It works, quite literally, as advertised.
My local WSL1 install of ffmpeg has an issue with the LAME encoder so using a few extra pipes I was able to get this working! Confirmed with a friend they were able to listen across the planet.
Neat stuff! I love things like this.[0] https://gist.github.com/Qix-/7c131c6eb83bef7c44ef6faaf1eab10...