Unfortunately markdown formatting has broken your code. I can make a guess based on where the italics starts and ends, but you might want to indent that code.
I have this version and the authors "sad" version playing together. It's weird because after about 10 or so minutes they stop sounding random and become almost like chiptune jazz.
I received an email suggestion yesterday of a variant of this command that places it inside a function, so that you could play multiple instruments at once with function calls. I guess you could make an entire music composing utility in bash if you wanted to.
Someone recorded what they got working on OSX, and it sounded terrible (not how it sounds on my Ubuntu machine). I haven't tested this on a mac since I don't have one.
I was surprised that many people suggested listening to the music for pleasure or inspiration. There are a few things I could do that would probably improve the sounds quality: One is experimenting with the sampling rate of the sin wave, and another is adjusting the for loop to make sure that it ends on the end of the sine curve close to y = 0. Right now, for some notes it will just stop halfway through close to y=1, and the next note will start at y=0. I think that is the source of the 'poping' sound between notes.
> If you're a level 500 elite hacker like I am, you will note that the cryptographic quality of numbers from /dev/urandom is not the same as numbers from /dev/random. In our case, we don't want this operation to block, so we use /dev/urandom.
There's nothing Ubuntu-specific there: it works fine on other Linuxes.
It's gotten more than a little annoying, this widespread equivalence between Ubuntu and Linux. Ubuntu is a Linux distro, albeit hardly the best, most idiomatic or most traditional. It's just a single distro, out of many.
But lets admit that distros of Linux have become idiomatic. Its reasonable to give a caveat when describing any Linux procedure. This is not an Ubuntu issue at all.
In fact, what's the point of different distros if they aren't idiomatic?
It's incorrect to assume that a shell script that uses tools like xxd and awk is distro-specific. Almost every distribution ships the GNU coreutils and other GNU base tools. It's going to work on basically every distribution. What makes distributions unique is their package manager, release and security philosophy, amount of cruft, etc.
Even the same distro line but different versions may have significant issues. This is why every build on top of Linux (e.g. Android) calls out a particular kernel version. Even a particular version for the build machine. Because things like command line tools differ over time. Versionology is a whole universe of hurt on Linux.
That's the cost of supporting code that is constantly being updated, you need to start freezing versions and backporting fixes. Also, I'm not sure what command line tools you're referring to as "differing over time". Kernel version freezing is mainly fear of new code (or out-of-tree vendor patchsets that depend very strongly on the kernel ABI which changes every few months -- but that's not user visible). Sure, if your system never changes anything you don't need to worry about software versions. But there are many other problems with that.
Part of this exercise was to leverage highly portable and backward compatible utilities as much as possible, so I expect stuff like cat and awk to work mostly the same everywhere. 'aplay' is the one I was not sure about. If I recall correctly, it was even necessary to explicitly 'sudo apt-get install' on older versions of Ubuntu.
That's quite a delight for the ears. Reminds me of Stéphane Picq's work on the Dune computer game soundtrack, back in the early 90s. It had some similar sounds.
A triangle/sawtooth wave sounds nicer without any filtering or other effects. It's the only "elementary" waveform that I know of that doesn't sound earpiercingly harsh.
I don't know if I'm the only one who have noticed that, but on 64 bit machines you have to change "%08X\n" to "%016X\n". Although using %08X sounds interesting, the result is not a major scale and probably not the original intent of the code.
If you're into jazz, you can check the label Rune Grammofon; you can start bands that are easy to listen to, such as Elephant9 (just listen to Fugl Fønix and try to resist the groove), and then get into the rest (woohoo, Shining). After that, you shouldn't find these bleep-bloops that hard.
Handy smoke test for a good RNG? Not sure I see any case where it would actually be useful for this in practice, but I find the idea amusing in theory.
You may be able to hear or see that a very bad RNG is bad (there are certainly sufficiently bad ones for which you can), but you can not hear or see that one is good.
Always paste to the browser url bar and then copy again. This clears any extra tags you might carry over and will display anything that might be hidden. You could copy and paste to notepad, but the browser bar is closer.
It was an excellent share you although I don't quite think "turning off CSS" would be my preferred defense.
You can paste to an intermediate area to be sure you didn't catch something hidden from whichever site you don't trust (which allows users to inline arbitrary HTML elements with arbitrary styles).
This is a habit one already might be in if they want to avoid being tracked from clicking on, say, Google search results. You'll avoid some of their tracking features if you copy the link you want and paste it to some text-holding zone first. (This also avoids the site you land on knowing your "referer".)
I knew it would take a few bare minutes before someone would come to make that distinction about how Google search links work.
Then I would have to say "okay copy the domain and path from your search result, which isn't a link, and which Google probably hides already (so this new advice won't work any more) or they will hide it some day, so the system doesn't work as literally as I described it."
So if Google has found more and more ways to avoid people avoiding their tracking, that's fine, and what I said literally doesn't apply if you take it 100% literally, but at least you understand what I'm saying about how to avoid the naive copy paste surprise.
