Robotic Toothbrushing Helmet
This art installation is very confrontational.
Baphomet unveils his fearsome "Troll" aspect.

Attendees for the event had to go through the following process:
- Show up at the location stated on the e-ticket.
- Go through a security checkpoint there.
- Sign a contract transferring their souls to Satan.
- Get the real location for the event, which was miles away.
I agree that by signing this document under any name, given or adopted, actual or pseudonymous, I am hereby avowing my soul to Satan (aka Abbadon, aka Lucifer, aka Beelzebub, aka The Antichrist). I do so knowing that He (aka The Fallen One, aka The Father of Lies) or any of His representatives may choose to collect my eternal soul at any time, with or without notice. I understand that my signature or mark representing any name, real or made up, upon these papers constitutes a lasting and eternal contract, and that there will be no further negotiations on the matter of my eternal soul.
I may need to add this to the stock DNA Lounge booking contract, right after the "Frisco" clause. Also a candidate: "Break a deal, face The Wheel".
The iTunes race to the bottom continues.

Dear iTunes team: you are bad at your job and you should feel bad.
Previously, previously, previously, previously, previously, previously, previously.
GUNMAN

This is an amazing story, and I also love that one of the players in this drama is named "Bob Surprise".
The typewriter bugs marked a new level of sophistication because they were electromechanical. For the first time, the Soviets gathered information from a piece of equipment that held written plain text information. Prior to the discovery of these bugs, the U.S. believed that the Russians had only used room audio bugs with micro- phones or listening devices to eavesdrop on American embassy activities. [...]
A total of sixteen bugs were found in twelve IBM Selectric II typewriters and four IBM Selectric III typewriters. Common features were found in all sixteen typewriters: six ferromagnetic magnetizable balls were replaced with six nonferromagnetic nonmagnetizable balls with a very strong magnet in the tip; all the typewriters contained a modified comb support bar which housed the bug; all used burst transmissions at the 30, 60, or 90 MHz range via radio frequency. [...]
Each implant had a magnetometer that converted the mechanical energy of key strokes into local magnetic disturbances. The electronics package in the implant responded to these disturbances, categorized the underlying data, and transmitted the results to a nearby listening post. Data were transmitted via radio frequency. The implant was enabled by remote control. Another advantage of these bugs was easy installation. Engineers estimated that a skilled technician could install an implant in a typewriter in a half hour. The integrated circuits were very sophisticated for that time period. The circuits contained one bit core memory, an advancement that NSA engineers had never seen. [...]
In reality, the movement of the balls determined which character had been typed because each character had a unique binary movement corresponding to the balls. The magnetic energy picked up by the sensors in the bar was converted into a digital electrical signal. The signals were compressed into a four-bit frequency select word. The bug was able to store up to eight four-bit characters. When the buffer was full, a transmitter in the bar sent the information out to Soviet sensors.
There was some ambiguity in determining which characters had been typed. NSA analysts using the laws of probability were able to figure out how the Soviets probably recovered text. Other factors which made it difficult to recover text included the following: The implant could not detect characters that were typed without the ball moving. If the typist pressed space, tab shift, or backspace, these characters were invisible to the implant. Since the ball did not move or tilt when the typist pressed hyphen because it was located at the ball's home position, the bug could not read this character either.
If you enjoy this kind of thing, you should watch The Americans. It's a really fun show. There were times when I was watching Agent Carter and I forgot which show I was watching because they're basically both about the Hydra Black Widow Program, but one of them has more boning and the other has more kung fu.
Javascript, locking and sound, brought to you by the letters W, T and F

Except then they added localStorage. Oh, what's this? Is it shared memory that can be accessed asynchronously by multiple contexts? Why yes it is! So now you really do need locking. Except then they didn't add mutexes, or even an atomic-read-and-increment operator. Hooray. And they also didn't add any IPC, like a socket that one process can write to and that others can select() on. Hooray.
So let's say you've got an app, it spans multiple documents, and you want a sound to play in reaction to some external, asynchronous event if any of your documents are open. But if three windows are open, you only want that sound to play once per event. The obvious way to do this is to nominate one of those documents as the leader, and pass the conch to someone else if the leader document goes away.
Well, good luck with that, since you only have a shared whiteboard, not real IPC. This means that each of your contexts needs to constantly poll the whiteboard, doing something like, "Has it been too long since the leader has updated their heartbeat timestamp? If so, now I must race with my brethren to try and acquire the lock and become the leader." So aside from that being stupid -- all those timers, all that polling -- it's also inefficient, because it means that there's always an interregnum during which there's no leader (your polling interval). Try to burn fewer cycles by increasing your polling interval and you increase the window during which your asynchronous notifications can't happen.
What kind of Mickey Mouse operation is this? There was better multitasking on MacOS 6.
Oh, and speaking of sound: on iOS, you flat-out cannot play sound unless somewhere higher up on the call stack is a touch gesture. Asynchronous sounds can't be done using the HTML5 audio tag, because... Apple are dicks, I guess? I'm gonna go with that. So apparently there's a newer and completely separate audio interface with a way more convoluted API, and maybe that one works on iOS? But I haven't investigated, having at that point run out of fucks due to the fact that I was starting to have ALSA versus OSS flashbacks and expecting it to tell me my EMU10K1 PCM setting was wrong.
Worst. Prisoner's Dilemma. Evar.
Even if you're overoptimistic by a factor of five and it's only a 20% savings we'd hire you tomorrow to build that for us. You can have a plane ticket to wherever you want to work and the best hardware money can buy and real engineering support to deploy something you've already mostly built and proven. [...]
And we look at that and say: what if you've got nothing? How can we know, without something we can audit and test? Of course, all the supporting research is paywalled PDFs with no concomitant code or data either, so by any metric that matters -- and the only metric that matters here is "code I can run against data I can verify" -- it doesn't exist.
Those aren't metrics that matter to you, though. What matters to you is either "getting a tenure-track position" or "getting hired to do work in your field". And by and large the academic tenure track doesn't care about open access, so you're afraid that actually showing your work will actively hurt your likelihood of getting either of those jobs.
So here we are in this bizarro academic-research standoff, where I can’t work with you without your tipping your hand, and you can’t tip your hand for fear I won’t want to work with you. And so all of this work that could accomplish amazing things for a real company shipping real software that really matters to real people – five or six years of the best work you’ve ever done, probably – just sits on the shelf rotting away.