Home

Recent notes

Sat 2020-02-22 02:36

  • Posted:
  • Edited:

Cory Doctorow sometimes posts insightful and interesting articles and talks but this piece isn't one of those, I'm afraid. In this latest editorial on the EFF website, Doctorow opines that adversarial interoperability was the downfall of the Gopher protocol. That the Web killed Gopher by... wait for it.. working with it.

Nice thought, but speaking as someone who is fairly familiar with it, what killed Gopher was that it was a rather shit protocol limited by inherent design flaws. The new kid HTTP was able to do everything Gopher could do (and in most cases, do it better) and could also do things Gopher couldn't. This was because of the HTTP protocol's flexible (and rather agnostic) design. It wasn't by some Machiavellian conspiracy that the World Wide Web supplanted Gopher. It was because HTTP was simply more capable and easier to use for most people, that the Web caught on.

Let's also not forget (as Doctorow apparently did in the above-linked article) that UMN (the university where Gopher was invented) shot their own baby in the head in 1993. The university placed their Gopher server implementation under a restrictive license, thus creating fear within the contemporary Gopher admin circles that other similar or derived server implementations might also be subject to UMN copyright claims.

Considering Doctorow is usually a staunch critic of copyright, it's odd he didn't see fit to mention that factoid. I guess it would have weakened his overall premise? I mean, given that CERN httpd (1990) was under a permissive license from the beginning, as were successors NCSA HTTPd (1993) and Apache (1995), it's really not that surprising that Gopher would drop out of favor with university computer science departments of the era who were concerned that deploying Gopher services might open their schools up to UMN claims for licensing fees. HTTP was the safer option.

In its day (an era of largely text-mode Internet communications and basic file downloads, where packet-level security was not a pressing concern), Gopher was a decent-enough protocol. But as soon as graphical web browsers hit the scene, people began to see the enormous possibilities of the Web and the writing was on the wall for its buck-toothed predecessor. These days, aside from the interest of retro-tech fetishists and those misguided persons who blame the sad state of the Web on its underlying protocol (rather than on the shit web developers who link 5MB+ of Javascript frameworks, ads, and trackers into every webpage they create) Gopher is a thing that ran its course a long time ago. And for good - technical - reasons.

Tue 2020-02-18 01:17

  • Posted:
  • Edited:

This crap is just one example of why I steer clear of WordPress. Install a theme and get a security vulnerability as a bonus.

The sheer breadth of the WordPress install base paints an enormous target on the back of not only the core product, but also every popular plugin. And frankly, it seems too many plugin developers don't take that reality seriously. In this case, ~200,000 websites are now vulnerable until patched (assuming they ever will be, I mean c'mon..).

I guess it could be worse. Given the WordPress market share, anyone who finds a serious security hole in the base WordPress package could potentially root a third of the Web.

Tue 2019-12-31 20:57

  • Posted:
  • Edited:

I've used PulseAudio on many Linux laptops and workstations over the years, and it usually works so well, so consistently that I've never felt the need to dig around under the covers. It was basically this magical software that I installed and my computer had sound.

Over the holiday break, I had some spare time to tinker and I thought it might be nice to finally put together some kind of audio streaming solution for the apartment. Sort of a "whole house audio" system - without the wiring. I setup a music server running MPD on an older Intel NUC I had sitting in my parts drawer, and NFS-mounted my music library from the NAS. Then I enlisted a couple of old Raspberry Pi 2B's I had sitting around collecting dust, added a USB WiFi adapter to each, and made them my audio receivers to connect to speakers.

The question then was, how to get music from the MPD server to the RPis?

It turns out the answer was pretty simple and - as you've probably guessed already - it involved PulseAudio. Did you know that PulseAudio has a network transport? I didn't. It was time for me to learn some new stuff about an old tool.

First off, because no one would be logged into a desktop session on these devices I had to set PulseAudio on the music server and the RPis to run in system mode. Some tweaking was involved to accomplish this (see the linked docs) and all of the config lines I used below go in /etc/pulse/system.pa rather than /etc/pulse/default.pa.

For strangers to the innards of PulseAudio, first grasp the basic concept that PulseAudio defines inputs and outputs as "sources" and "sinks". My first step was to create a new fake sink (a "null" sink) to receive the system audio, and transport the audio sent to that null sink (captured by the "monitor" of that sink) via RTP stream to my RPis.

On the server:


load-module module-null-sink sink_name=rtp 
load-module module-rtp-send source=rtp.monitor mtu=1408 destination_ip=[remote IP 1] 
load-module module-rtp-send source=rtp.monitor mtu=1408 destination_ip=[remote IP 2]

On the RPis:


load-module module-rtp-recv sap_address=[local IP]

Well, that was actually pretty simple. I configured MPD to use PulseAudio as an output, restarted both PulseAudio and MPD, and started playing a song in MPD. BINGO! Synchronous streaming audio to the RPis and their connected speakers, and the apartment was filled with music in every room.

I played with this setup for a day or so: adding music playlists to MPD, setting up M.A.L.P. on my phone to remote control MPD, etc. Then I thought, wouldn't it be cool if I could take the output from my SiriusXM receiver and stream that audio to every room, also? It turns out that yes - it is cool. But it was a task not without some challenges to accomplish.

For starters, my NUC didn't have a stereo line-in port so I picked up a no-name $15 USB sound card that did. Then I thought it would be a simple matter of plugging in the stereo out from the SiriusXM receiver to the line-in on the USB card, but nothing is ever that simple. I had to go back to the PulseAudio docs and this time learn about the loopback module, which acts like a virtual mixer.

First, I had to create an additional null sink dedicated for MPD:


load-module module-null-sink sink_name=mpd_out

Next, I had to tell MPD to send its output to that sink (in /etc/mpd.conf):


audio_output {
    type    "pulse"
    name    "Pulse Output"
    sink    "mpd_out" 
}

Then I had to use pactl list sources to find the cryptic ass name PulseAudio had given to the USB sound card interface, which turned out to be:


alsa_input.usb-0d8c_USB_Sound_Device-00.analog-stereo

Say that five times fast.

Finally, I had to mux the monitor of the MPD sink and the line-in source together by sending them both through the loopback module to the RTP stream sink:


load-module module-loopback source=mpd_out.monitor sink=rtp
load-module module-loopback source=alsa_input.usb-0d8c_USB_Sound_Device-00.analog-stereo sink=rtp

I turned on the SiriusXM receiver and... nothing. The USB sound card has both a mono mic port and a stereo line-in port, and for whatever reason the mic port has a higher default priority and the system preferred it as the capture device. I had to tell PulseAudio to prefer the line-in port instead. While I was at it, I set the volume on the line-in port to normalize it with the MPD output, and made sure the port was not muted:


set-source-port 1 analog-input-linein
set-source-volume 1 15000
set-source-mute 1 0

I restarted PulseAudio and the SiriusXM output started piping to all of the speakers in the house. So cool. Now I have a whole house audio system with a choice of either playlists from my music library or live SiriusXM satellite radio. I think my next project will be to setup an IR receiver/repeater system so I can change the radio station while sitting on the couch in the other room.

Latest articles

How much is data ownership worth?

  • Published:
  • Updated:

From email to chat, cloud storage to social networking, there are personal financial costs to self-hosting your own information services infrastructure and freeing your data from centralized platforms like Google and Facebook. Looking at those costs may show you how much your data is worth to the companies that siphon it up.

Read more

Project updates

Repository Last commit Updated (UTC)
personal-shortener doc update (markdown fix) 2020-02-05 01:53
personal-pastebin doc update 2020-02-05 01:49
redball million dollar bug 2019-11-21 04:46
ELLIS updated links 2019-09-30 00:09
dotfiles OCD is a PITA 2019-05-03 00:36

Newest photos