Initial commit: HPR Knowledge Base MCP Server

- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

hpr_transcripts/hpr1989.txt

@@ -0,0 +1,242 @@
+Episode: 1989
+Title: HPR1989: WDTV Makes Me Itch
+Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1989/hpr1989.mp3
+Transcribed: 2025-10-18 12:56:44
+
+---
+
+This is HPR Episode 1989 entitled WDTV Makes Meage.
+It is hosted by Epicanis and is about 31 minutes long.
+The summary is a step-by-step description of turning an old computer into a simple Linux media appliance.
+This episode of HPR is brought to you by an honesthost.com.
+Get 15% discount on all shared hosting with the offer code HPR15.
+That's HPR15.
+Better web hosting that's honest and fair at An Honesthost.com.
+Hey everyone, sorry for the long delay between episodes.
+I would have made an episode earlier, but crap, I forgot to come up with an excuse.
+Let's see, I've been on the run from killer robots, vampires.
+Yeah, robot vampires, that's why.
+Whatever.
+So anyway, I've been thinking about making userless appliances out of cast-off computers that can play videos or display information or whatever for years now,
+but I never really got around to actually trying it.
+Now, I'm specifically talking about automatically starting the kinds of things that someone would normally do manually on a regular Linux installation.
+Like starting up a media player and pointing it at a file or media stream to start it playing, not something like running a web server.
+I've already gotten a lot of use out of old computers to do all kinds of things that can be done by headless servers,
+but starting up a regular user space application the same way isn't something I've had a strong urge to look up how to do, until now.
+I have an ordinary job now working for the man again.
+The economy sucks up here in the Kansas of New England, and I'm, quote, old, unquote, by IT standards, meaning I'm not in my 20s anymore,
+and tech jobs around here are pretty rare to begin with.
+Lucky for me, technically competent people who haven't moved south to find some place with an economy with jobs is also rare.
+My employer, like most employers these days, has a variety of policies.
+According to my reading of what the lawyers put down in the social media policy, the first rule of talking about,
+name of employer.
+On social media is, don't talk about, name of employer, on social media.
+But I will say that other than being a bit windowsy for my tastes, and the pay scale currently putting me way down in the same range as an average Duncan Donuts assistant manager,
+the work environment is fairly pleasant, the benefits once you qualify for them are pretty good,
+and I'm working with generally competent and reasonable people, and there's some potential for growth.
+We'll see how this goes, at least it's keeping me from needing a Kickstarter campaign to buy a cardboard box to live in.
+Anyway, name of employer has a pile of thin client systems they're replacing because they're unupgradably ancient, which brings us neatly back to this episode's topic.
+Let me start by telling you a little about the Hewlett Packard T5740 thin client.
+It's a solid state gadget that's roughly the right size for its case to serve as a box for one of those tiny little personal sized pizzas you can get at some places.
+It's running on an atom into ADCPU, which is 32-bit only, with a single hyper-threaded core.
+It's got 2GB RAM by default, though it apparently supports up to 4 or maybe even 8GB via physical address extension,
+a tiny 2GB flash drive for a hard disk, a gigabit Ethernet port,
+6 USB ports plus two more quote secure unquote ports, which are under a plastic cover secured by one screw.
+It's got VGA and DisplayPort outputs along with the standard stereo analog audio out and microphone in jacks.
+It's powered by a laptop style power supply with a fairly typical 19 volt output rated at 3.4 amps.
+There's also an extra serial ATA connection inside the case on the board, but we're not doing anything with that right now.
+It was originally intended for an overpriced add-on flash drive, as I recall.
+For an operating system, it came with Windows XP embedded, including Internet Explorer 7, wow!
+I think you could even upgrade that all the way up to IE9!
+The suggested retail price for these things was $450 or so for the base configuration,
+but you can find them now on eBay for about $50 or around $20 each if you buy them in lots of three or more.
+Also, WDTV sucks, in my opinion.
+I know that sounds like a non-sequator, but keep listening.
+Western Digital makes a few models of consumer-grade digital media player boxes, name of employer,
+has a bunch of them that are only used to repeatedly play the company video in the lobby of our offices.
+They don't seem real reliable, as we get occasional reports that one or the other of them has mysteriously decided to stop looping for no apparent reason and has to be restarted.
+This has to be done in person, as does updating the video when the company puts out a new revision of it.
+This requires using the WDTV's remote control, assuming it hasn't gotten lost.
+The user interface is perversely oversimplified and over complex at the same time, presumably because Western Digital is manufacturing
+for what they assume to be dumb consumers who want to do everything imaginable but don't want to learn how to do it.
+So there's a pile of separate special built-in app-like functions for YouTube and Hulu and Netflix and Pandora and various other sources,
+but all of those features seem to have very limited flexibility, so as not to confuse people, I suppose.
+If anyone has lost the remote control or you just don't want to be standing in front of the TV in the room with the media box,
+there is a very limited remote control web interface, but it automatically locks out anyone outside the default subnet with no way to configure otherwise.
+So with name of employer, having a perfectly sensible arrangement of having each physical site on a separate subnet on the company-wide network,
+you still have to be on-site to attempt to remotely administer the box.
+These things probably cost more than $150 each if Amazon.com is to be believed.
+I was pretty confident I could do better.
+We've got all these high-band with low-power thin clients sitting around gathering dust and I'll bet they'd run VLC on Linux with proper networking just fine.
+I settled on using Arch Linux to scratch my WDTV itch.
+Why Arch? Well, it's easily minimized.
+It's already quite familiar to me since it's my preferred distribution for several years now, and it's just generally awesome.
+No, really, it is.
+You may have heard the variation on the old joke that you can always tell who's an Arch Linux user because they'll tell you, but that's just a ridiculous stereotype.
+After all, I use Arch and I haven't told you- wait, crap, I did, didn't I?
+Anyway, the Arch Wiki Online is a really great reference even for non-Arch users,
+and unlike a few distributions that I considered, Arch still supports 32-bit environments.
+Some of the sufficiently spiffy nerds out there may be wondering why I didn't go with Slackware instead,
+since it's even easier to minimize and ought to be well adapted for this sort of thing.
+I actually did consider using Slackware, in fact, but I went with Arch purely because I wanted System D.
+No stop laughing, that wasn't a joke, I'm serious.
+Hating on System D is pretty popular among old school nerds like myself, and all confess I do friggin' hate that obnoxious mandatory binary journal that needs a special binary journal reading tool to look the logs.
+But it's standard these days, and from my brief search, it looked like System D was actually the simplest way to do some of what I wanted.
+I know there is a third party Slack build of System D available, but having it standard by default in Arch, along with the Arch Wiki being a little more directly accurate for Arch Linux, then for Slackware, just makes it a little bit simpler for me.
+That said, you could certainly adapt the process I'm about to describe to Slackware or just about any other distribution with a few tweaks.
+This basic process should also work on nearly any hardware and could easily be done on anything that's Linuxable,
+like old laptops, desktops, netbooks, dead badgers, raspberry pies, whatever, with just a little bit of adjustment.
+I do this install by hand because it lets me strictly control what gets installed so we're not wasting too much space, since, like I said earlier, this thing's only got two gig of storage available.
+Here's what I did.
+First, I needed to bootstrap an installation of Arch Linux. For some reason, the Arch ISO image wouldn't boot on this specific device, so I just booted from an image of System Rescue CD using its 32-bit kernel.
+You could use pretty much any bootable image if you wanted to.
+The T5740 had two partitions on its little flash drive for some reason, partition 1 with its Windows XP embedded install, and a second tiny partition only 82 kilobytes in size.
+I still have no idea what was in there, perhaps some sort of configuration data backup or licensing information or whatever.
+It's not necessary to the operation of the device, so I just deleted everything and made one big partition.
+One important part of this, I needed to change the start of the first partition to be at sector 4096 instead of the default 2048, so that the bootloader would have enough space.
+I'll come back to that. In summary, start FDISC, delete the existing partitions, create a new primary partition starting at sector 4096, and taking up the entire rest of the disk, partition type 83 for Linux.
+Don't forget to mark the partition bootable before exiting, if you're using the basic FDISC utility you just hit A and then select partition 1, then hit W to write the new partition table to the disk.
+Now we create the file system.
+I'm using ButterFS for the Inline Compression features.
+Pay no attention to the fetching kobolds of Contrarianism back there. I've been using ButterFS for most of my systems for years now with no problems, and it's not like we're doing anything really difficult or complicated with it here, and having the Inline Compression makes it a lot easier to fit what we need onto this thing's minuscule storage.
+Normally, I find it pretty tedious to listen to people reading out command lines, so I'll try to avoid doing it here, but I'm going to do it a few times along the way just so you know which options I've chosen to use and just because sometimes it's faster than trying to describe in pros.
+Here's how I created the file system, mkfs.btrfs, space-capital-l, space-rootdisc, space-capital-o, space-skine-metadata, comma-mixed-bg, space-n, space-4096, space-slashdev-slashsda1.
+I like to give comprehensible human-usable labels like rootdisc to my discs because UUID is a tool of the devil. The skinny metadata option reduces the space taken up by metadata slightly, and mixed block groups means that it won't try to reserve separate sets of blocks for data and metadata, which is an option you don't normally want unless you're working with a really small file system, which we are.
+Both of these options should hypothetically reduce wasted disk space somewhat. Now it's time to actually get the operating system onto the disk.
+System Rescue CD by default has a few places set aside for mounting other file systems. I've somewhat arbitrarily chosen to use slash-mnt-slash-custom.
+I mounted the file system we just created on slashdev-slashsda1 there, remembering to specify the compress-equals-z-live option.
+Next, the network needs to be brought up so that we can download things. On System Rescue CD, there's a simple script called net-setup that deals with this.
+Once the network was up, I used a third-party shell script called Arch Bootstrap, which downloads and installs the handful of core packages needed to make a bare functional Arch Linux system.
+You can grab the current version of this script right out of its GitHub repository using Curl or WGet. It's at HTTPS, colon-slash-raw, that's R-A-W, dot-git-hub-user-content-dot-com-slash-tok-l-a-n-d-slash-arch-dash-bootstrap-slash-master-slash-arch-bootstrap-dot-sh.
+I haven't tried it yet, but I'm under the impression you can also just unpack the Arch Bootstrap tarball by hand, which you will find on the Arch Linux mirrors in the same places the install CD images.
+Either way, once that's done, we have a file system with the package manager and the fundamental basic command line utilities to install and configure whatever we need.
+What it doesn't have yet, though, is a Linux kernel or a bootloader or any of the other stuff we need to actually boot directly into it, so we're not ready to reboot yet.
+Instead, I use ChangeRoot to put myself directly into the new Arch Linux environment without actually leaving system rescue CD.
+First, I needed to put SlashDev, SlashProk, and SlashSys, where the new system could see them, which is what bind mounts are for.
+Recall that I had the Arch file system mounted at SlashMNT, SlashCustom in this example, so to put the current device nodes where the Arch system would be able to see them, I typed,
+mount, space-o, space bind, space-slashDev, space, SlashMNT, SlashCustom, SlashDev.
+This works like a temporary hard link for directories. After repeating the process for SlashProk and SlashSys, I set the file system in SlashMNT SlashCustom as my virtual new root directory,
+C-H-R-O-O-T, space-slashMNT, SlashCustom, space, SlashBin, SlashBash.
+And now it's like I've booted up a pre-installed Arch Linux system and logged in as root into the hash shell, and I can finally start customizing it.
+This part's pretty specific to Arch Linux, of course, but any other distribution you might be using would follow more or less the same progression.
+Arch Linux's package manager is called Pac-Man, and we'll be using it to install the rest of the software we need, so the first thing we need to do is get it initialized.
+This is started with the command Pac-Man-key, space, dash-dash in it. That's I-N-I-T.
+If you've never done this before, you might think the system has locked up at this point, because you'll get a message that says generating Pac-Man keyring a master key, and it just sits there, apparently unresponsive.
+What it's doing is generating your installation's PG-P key for verifying the signatures of packages that will be downloading and installing, and it's waiting to collect enough randomness to do it securely.
+This randomness, or entropy, as they like to call it, is actually generated from hardware interrupts, so you can greatly speed up this process by plugging in a mouse and moving it around, or switching to another virtual terminal and doing a bunch of disc reads or whatever.
+I promise it actually does finish eventually, and it's not just locked up, and you'll only need to sit through this once anyway.
+Once it finishes, probably in just a minute or so if you keep the hardware busy enough, we load up the public keys of the authorized Arch Linux package publishers, like so.
+Pac-Man-key, space, dash-dash, populate, space, Arch Linux. And when that's done, we can install the rest of the software, starting with the basics.
+On Arch, the command is Pac-Man-space-capital-s, followed by the names of whatever packages you want.
+In my case, I started with grub, iputils, iproot2, openssh, butterfs-progs, Linux, that's the package with the Linux kernel, sudo, systemd-sysv-compat, vim-nano, or whatever else you want to use as a text editor, and procps-ng.
+That gives us what we need to get the system ready to reboot on its own once we finish configuring it.
+At a minimum, we need a file system table and the bootloader installed.
+You can actually directly copy slash proc slash self slash mounts to slash ETC slash FS tab, which you then edit in whatever your preferred text editor is.
+Depending on which boot image you start from, there might be a lot of extraneous crap in slash proc slash self slash mounts that we don't need in the file system table.
+So delete everything in the slash ETC slash FS tab file that you made, except the root file system in slash dev slash sda1, and the lines for proc, sysfs, and you dev.
+In this case, you should also make sure to change the boot options for butterfs to no-a time comma compress equals z-live.
+I also recommend changing the reference to slash dev slash sda1 instead to slash dev slash disk slash by dash label slash root disk or whatever volume label you gave your right root file system.
+That's optional though.
+Now the bootloader.
+I installed grub, so I typed grub dash install space dash dash target equals i386 dash PC space dash dash recheck space slash dev slash sda.
+Oh, remember when I told you to move the partition to start at 4096 instead of the default of 2048? If you ignored me, at this point you would get an error message about not being able to fit into the embedded space and butterfs not supporting block lists.
+Otherwise, the bootloader loads right in and is now sitting at the very beginning of the hard disk, and it will be ready to boot on its own as soon as its configuration file is created.
+That part's easy. Grub dash mkconfig, space dash o, space slash boot slash grub slash grub dot cfg.
+There, all set. No wait, don't reboot yet.
+It's bad practice to be logging in as root unless you absolutely need to, so now we need to create two user accounts.
+One for administration and one ordinary user with no administrative privileges that will actually run the media player.
+To make this easy, I'll call the administrative user admin and the ordinary user media player, but you can obviously use whatever names you want.
+My assignment of user groups in this example is almost certainly excessive, and I'm only doing it in anticipation of maybe doing some more complicated stuff with it in the future. But anyway, here's what I did.
+User ad, space dash m, space dash capital g, space wheel, space dash g, space users, comma disk, comma log, comma HTTP, comma games, comma network, comma video, comma audio, comma storage, comma power, space dash s, space slash bin slash bash, space admin.
+And then you type psswd space admin and set a password for the admin user.
+You repeat that again with media player, except I only set the supplemental user groups of HTTP games, video, audio, storage, and power.
+Otherwise, the settings are the same and I gave media player a different password.
+Now, run vi sudo and give the wheel group permission to run as root.
+Oh, speaking of root, run psswd one more time with no parameters because you really need to give the actual root account a password too, you know.
+At this point, I also created a directory named media and a directory named dot vnc under media player's home directory and gave media player ownership of them.
+I'll come back to these. You should probably also now enable the secure shell demon and I strongly recommend editing the secure shell demon config file to turn off root logins.
+And if you're extremely paranoid, set up public key authentication and disable passwords, but you don't need to do that right now.
+Now we should configure networking, which I'm going to gloss over and keep moving because there is a surprisingly wide range of options for doing this and most are pretty easy.
+In my case, I just used system d network d and told it to use dhcp to get its network settings, which was trivial to do.
+At that point, I had a working bootable system. Meet, huh?
+Oh, wow, you made a server.
+I'm a model.
+Such an amazing unusual.
+You're a genius.
+Shut up. I'm not done yet.
+Yes, at this point you could install a web server, a mail server, an instant messaging server, a little database server,
+Sambo for Microsoft file shares, a finger server, go for whatever.
+And it would be handy, but nothing that I, and probably most other penguins, does haven't done many times before, possibly while sleepwalking.
+What's new and different for me, and maybe some of you, is getting the system to automatically log in and start a standard user mode graphical thing.
+In this case, I'm starting up VLC to loop through whatever video files are sitting in a particular directory with no interaction required.
+I'm using VLC because in addition to being able to play virtually any kind of old or new media you can throw at it, VLC has some handy remote control capabilities built in, and it's already pretty familiar to just about anyone else who might need to operate it later.
+I used Pac-Man to install the following packages.
+VLC, Xorg server, XF86 video Intel, Xorg server utils, Xorg X init, Tiger VNC, also utils, and Pulse Audio also.
+Wait, did I say VNC?
+Yep, I wouldn't recommend it for trying to watch movies or anything, but it's quite adequate for administrative use and its cross-platform.
+That means we need to set up a password for the VNC login.
+You do this with VNC, PASSWD, space, slash home slash media player, slash dot VNC, slash PASSWD, then change the owner of that file to media player.
+All of the necessary software is now installed, but don't reboot yet.
+Let's go ahead and set up the media player account so that whenever it starts up the graphical environment, the media player and the VNC server will automatically come up and run with it.
+In your preferred text editor, edit slash home slash media player slash dot X I N I T R C.
+Here are a couple more tedious command line recitations to put in that file.
+VLC, space, dash dash, extra I N T F equals HTTP, space, dash dash, HTTP, dash host, space 0.0.0.0 colon 8080, space, dash dash HTTP, dash password, space, whatever you want to use for a web control password, space, dash F, space, dash capital L,
+space, tilde, slash media, space, ampersand, and on the next line, EXEC, space, X 0, VNC server, space, dash display, space, colon 0, space, dash password file, space, slash home slash media player, slash dot VNC, slash PASSWD.
+The VLC line tells it to enable its web-based remote control interface, accessible on port 8080, on any network interface that's active, and to start in full screen, and to play the contents of the media directory in an endless loop.
+The next line starts Tiger VNC's server, monitoring the default graphical display, accessible by the password we previously specified.
+This is probably a good time to copy one or more videos or audio files into media players, media directory, since we just told VLC to play stuff in it when it starts, which will now happen automatically when the media play account starts up the graphical environment.
+At this point for me, the installation has involved sticking about a gigabyte of actual file data into the file system, before we take inline compression into account, which cuts the amount of actual disk space used up by about half.
+So we've still got a decent amount of space left for some media right on the built-in disk.
+No wait, still don't reboot yet? Well, okay, you can. If you want to test things up to this point, if you reboot now, the system should start up and provide a login prompt like a normal text mode Linux install, and if you log in as media play and run the StartX command, VLC should pop right up and start playing media files.
+Well, the very first time you run VLC, it'll pop up and ask you if you want to let it fetch metadata from the internet for files that you play.
+I always tell it, no, because there's no reason to have VLC announcing to servers on the internet what I'm listening to or viewing while begging for metadata.
+And in any case, my media is usually already properly tagged with its own metadata locally anyway, so no potential privacy violating internet queries are needed.
+The VNC interface to the display should also be running, and if you want to test that, you should be able to connect to it from any VNC client using the password you set earlier. We're obviously still not done yet though.
+We still have to deal with the part that made me think I ought to record this episode in the first place, which is how to make the system automatically log in and start on boot, with SystemD and probably other init systems.
+The AutoLogin part is actually quite easy. The Getty program that runs the virtual terminals that logins happen on actually has an AutoLogin option built in.
+For SystemD, you can just type Sudo, Space, SystemCTL, SpaceEdit, SpaceGetty at TTY1, and then just add dash dash AutoLogin space media player to the line that starts Getty.
+That gets you logged into the text console automatically. You may recall that in this example, we set the media player's user login shell to bash, which will automatically run any commands in the .bash underscore profile file if it exists.
+All we need to do is add exec startx to the end of that file in media player's home directory.
+However, before you do that, keep in mind that this means it'll try to start VLC anytime someone tries to log in as media player, no matter which terminal the login is coming from, or even if it's over secure shell.
+That's probably okay for our purposes, but I'll mention that the Archwicky has a nice article on x init RC, which includes a handy little one liner on how to start x automatically only if the login is taking place on virtual terminal 1.
+Okay, now we're pretty much done. Whenever the system is booted up, media player automatically logs in on the default display, which in turn automatically starts the graphical environment with VLC automatically repeatedly playing whatever is in the media directory.
+With this, the formerly abandoned thin client is now doing everything that the WDTV things are being called upon for by name of employer, except now we have three different channels by which we can administer and control the system remotely from anywhere on the company network.
+By VNC, through VLC's web interface, or through a standard secure shell login, we could also use SFTP to update the media files without traveling on site, and if for some reason the media player glitched out or locked up or stopped, one could either reboot from a secure shell login or someone could physically turn it off and back on again, and it'd start right back up with no fuss.
+That's all the needed functionality, and then some. Of course, there is even more that we might want to add or change. For example, we might want to install the openbox and x-term packages, then edit the .x init RC file to add exec space openbox stash session to the end, which is one thing I actually have done.
+That gives us an actual window manager running from which we can pull up a menu and start x-term to do maintenance or debugging right on the screen if we want to, instead of being left with a blank screen if VLC is killed for some reason.
+I'm pretty sure the .x init RC I threw together here could also be a rearrange to work a little bit better too.
+Another thing I've looked into a bit is updating the media on the fly. Presumably for security reasons, there isn't any sort of file picking option in VLC's web interface.
+So once you upload a new media file, there's no intuitive way to just tell VLC to start playing it without restarting everything.
+It is possible to use scripting commands made available through the web interface to reload a playlist, however.
+So by creating a playlist in plaintext.m3u format that points to the media files you want in the media directory, and changing the VLC line to load that instead of the directory, we can then log in and change the playlist file while VLC is running,
+and then issue commands to make VLC start playing from the new playlist without restarting.
+I tested this briefly using WGET to send the commands and it seems to work. It's also possible to customize VLC's web interface, though I've not explored that yet.
+A slightly more advanced addition would be UDEV rules that allow for someone to plug in a USB flash drive and have media in it automatically made available to the media player.
+The setup I've just described could also be used to make a variety of other kinds of computer appliances as well.
+With a few small additions, one obvious option would be to take what I just did and make it stream the media that it's playing onto the rest of the network while it's also showing it on the screen.
+VLC has the ability to be an ice cast client out of the box, and by running ice cast either on the same box or on some other server, you could make whatever the media player is playing available for simultaneous playback by any other device on the network,
+including, of course, more of these thin client media players. If you replace VLC with Firefox or Chromium, you have a simple web kiosk instead, which can automatically connect to a particular website.
+If you run the browser in private browsing mode, it won't even clutter up the drive with cached files, nor save any potentially privacy infringing information from any of the people who use it.
+You could also point the web browser to an internal web server that shows a web-based network monitoring system or productivity statistics from a factory floor or a log viewing system or current news from an internal or external aggregator or whatever.
+You could turn these things into intercom systems by adding a microphone and having a web browser initiate a web RTC session or starting up mumble or other audio conferencing clients.
+If you add a cheap webcam to one of the USB ports, you could even do a video conferencing this way.
+You could add some variety of controller and have the system load up a video game instead and you have an instant arcade machine.
+You could stick it in the data center and have it run a front end for snort or add a USB Wi-Fi interface and run a copy of kismet to monitor wireless activity or run a copy of drift net to keep an eye on what kinds of places people are pointing their web browsers at.
+Finally, here's a crazy thought. You could use these things as thin client terminals.
+Instead of VLC, just have the system start our desktop, VNC viewer or X to go depending on your target environment.
+You've got something a heck of a lot more modern than Windows XP embedded that you can use for remote desktop purposes.
+That ought to give you a few ideas. Hopefully at least a few of you found this inspiring or at least interesting.
+Tune in next time when I will probably be talking about making legal MP3 files before the patents run out.
+Unless I change my mind on what I want to talk about again. Hopefully this will happen far sooner than two years from now.
+If you want to, you can help make this happen by pestering me to keep recordings so that I can't keep telling myself that nobody's going to notice if I don't get around to it.
+You have been listening to hackerpublicradio at hackerpublicradio.org.
+We are a community podcast network that releases shows every weekday, Monday through Friday.
+Today's show, like all our shows, was contributed by an HPR listener like yourself.
+If you ever thought of recording a podcast, then click on our contribute link to find out how easy it really is.
+Hackerpublicradio was founded by the digital dog pound and the in-ponomicon computer club and is part of the binary revolution at binrev.com.
+If you have comments on today's show, please email the host directly, leave a comment on the website or record a follow-up episode yourself.
+Unless otherwise stated, today's show is released under a Creative Commons Attribution Sharelike 3.0 License.
+Finally, got a new episode recorded. I should probably get started on the next one now before I get distracted.
+What? I'm recording in here. What do you want?
+Ha ha ha we have found you again, you cannot escape and now I'm going to suck your blood.
+They've never leave me alone already!