Monday, July 30, 2018

On the Joys and Perils of YouTube

For want of a social aspect to my technology addiction, of late I have been recording video content and placing it on YouTube.  It has been an interesting endeavor, because it involves skills that I heretofore have never trained.  How does one look good on camera?  What does one do with one's hands?  What it the efficient way to record and edit video.  What is the right way to do lighting and audio?  It has been fun so far, largely because the videos I've recorded still look so amateurish.  That I will be able to learn and progress at something new enchants me.

YouTube is an amazing platform, and the result of untold man-years of effort. The voice recognition involved in the automatic closed captioning is impressive.

But as any graybeard GNU-ster will attest, placing you content solely in the hands of a faceless evil corporation like Google is unwise, since I am not their customer.  Their advertisers are their customers, and their users are just free content creators and a source of training data for their AI.  So, in parallel, I've been revisiting the idea of resurrecting my website.

It is a somewhat overwhelming idea for me because there are infinite possibilities.  I could (and should) just do a WordPress instance and call it a day, for that would be efficient, but, I would love to take the opportunity to learn something new.

Over the weekend, I enumerated my many sources of internet content.  So far, I've discovered
  • YouTube
  • Twitter
  • A code blog on Blogger
  • A personal website, hosted by a hosting provided, that is never updated
  • Another personal website that is just a parked domain right now
  • Yet another personal website, on my home PC, that is rarely updated
  • A security camera
Over a weekend's pondering, I have decided that I will keep three projects, and that each of these will just be different skins on the same content.
  • The true content backend -- not publicly visible -- which will be the source.  Video, images, audio will be stored in their native resolution and formats
  • A website.  It will be GNU-friendly.  No weird javascript.  Video will be medium resolution to split the difference quality and download time.  Probably 720p Ogg+Theora+Vorbis.  Audio will be Ogg+Vorbis or MP3.  Images will be JPEG.
  • YouTube.
  • A gopher server where the 1990s will live on forever.  Video will be shrunk to 352x288 pixel MP4 or CIF-sized 3gp+h.263+AMR_NB.  Audio will be MP3.  Images will be 640x480 GIF.
I will probably end up with a LAMP instance with Python/Django or whatever because hosting VMs like that.

---

In my personal archaeology, I also found these projects that are not externally visible or not working
  • An instance of the never-completed telnet PupperBBS, which has no content
  • A real-time chat service called Jozabad
  • A shoutcast/icecast server that has been serving up the same song for who knows how long

Thursday, January 25, 2018

The Ridiculous Gopher Project: BBSs and ZModem

In the previous entry, I talked about the ridiculous Gopher project, in which I might try to make a presence for myself in Gopher Space.

So my first though was that I would have a blog and a webgallery over gopher.

The blog entries are a very simple prospect, since they need to be plain text.  I don't really like the block paragraph style, but, I did sketch out a conversion from markdown to troff to text that does some nice formatting.

The directory of the blog entries is a bit more complicated.  I had an idea for a cgi that handled directory structures and indices that are date-based with a parallel directory structure and index that is keyword based.

But anyway, I got stuck on my first step, and fell down a rabbit hole, as per usual.

So I thought to myself, what if I wanted to have comments for my gopher blog?  How would that work?  What technology would I used?  Well, in the original Gopher spec, there is a capacity for a Telnet session.  I thought that I could make a tiny Telnet-based BBS with just enough functionality to let one leave a comment or read comments.

So I went on the internet to find a tiny BBS to examine.  I found just about the simplest BBS one could imagine.  It is called Puppy BBS.
I found it in here: http://cd.textfiles.com/simtel/simtel20/MSDOS/FIDO/.index.html

So there this California-based guy named Tom Jennings who does a lot of stuff in the intersection between tech and art. Once upon a time he was a driving force behind FidoNet, which was a pre-internet community of dial-up BBSs. He's done many cool things since FidoNet.

Check out his cool art at http://www.sensitiveresearch.com/

I guess Tom wrote PuppyBBS as a reaction to how complicated BBSs had become back in the late 1980s.

So I thought, hey, does this thing still build and run? Well, not exactly. First off, it uses a MS-DOS C library that handles serial comms, which, of course, doesn't work on Microsoft Windows 10 or on Linux. And even if that library did still exist, I couldn't try it even if I wanted to. I mean, if I wanted to try it I would need two landlines and two dial-up modems so I could call myself. I do have a dial-up modem in a box in the garage, but, I'm not going to get another landline for this nonsense.

Anyway, I e-mailed Tom and asked if I could hack it up and post it on Github, and he said okay. And so this is what this is PuppyBBS.

Puppy BBS has four functions:
  • write messages
  • read messages
  • upload files
  • download files
From there, I started writing a Telnet-based BBS, which PupperBBS.  And that went pretty well.  It took very little time to get the message reading and writing running.  I was on a roll, so I decided that I would quickly tackle the other two functions that PuppyBBS had: uploading and downloading files.  And that was where it all got complicated.

PuppyBBS used XModem for file transfer, because it was the 80's and that was what people did.  But I thought ZModem, which was faster and more reliable, would be the way to go.  So, I thought I'd just link a zmodem library to the BBS and I'd be ready to go.

But, I couldn't find a zmodem library that was ready to go.  All zmodem code seems to be derived for lrzsz, so I downloaded the code from lrzsz and made it into a library.  To do that, I had to understand the code, so I tried to read it.  That code is so very 1980s.  It is terrible, so I had to fix it.

(Let the record show that by "terrible" I mean terrible from a reader's point of view.  It was written with so much global state and no indication of which procedures modify that state.  There is no isolation, no separation of concerns.  As a practical matter, it works great.)

And that led to a full week of untangling it all, which is what became the libzmodem library.  Now my libzmodem isn't really much more readable than the original code, but, at least it makes more sense to me.

Great, now I linked libzmodem to PupperBBS to add some ZModem send and receive functionality.  Now to test it.  I set up PupperBBS.  I telnetted in to the system, got to the BBS, and tried to upload and download some files.  It became apparent that for ZModem to work, the telnet program itself has to have some parnership with rz and sz, launching one or the other as appropriate.

Since this had to have worked in the past, some internet searches led me to zssh on sourceforge  . zssh has a telnet program that has a built-in zmodem send and receive functionality.  Unfortunately, it wasn't packaged on Fedora didn't compile out of the box, so I started trying to understand it and fix it.

So, anyway to summarize:
  1. Let's do a Gopher blog!
  2. How do you do comments?
  3. Telnet works on Gopher!
  4. Let's make a BBS
  5. BBS's do Zmodem
  6. Let's make a ZModem library
  7. Let's make a Telnet client that does ZModem.
And this is why I never finish anything.