Lightweight Web servers

Don’t you hate it when you see something that you want to investigate further, but then you can’t remember what the project is called? That’s what happened to me: I recently saw some cool little web server, implemented as a single C file, and that could either embed or be embedded in other applications.

And for the life of me, I can’t remember the name.

While searching, I did find this cool list of lightweight web servers that was collected by IBM. It’s got a lot of them, and included most of the ones I knew about, but none seem to be the one I was looking for. I’ll keep looking, but I’m archiving this link because it will undoubtedly be useful in the future.

List of Lightweight Web servers, courtesy of IBM

Addendum: The one I was looking for was Mongoose..

Addendum2: The link above appears to be dead. But Wikpedia provides this comparison of lightweight webservers which may provide links to the information you need. I’ve used nginx, mongoose, boa, and thttpd, and all seemed very good with some interesting varying features. Check them all out.

Q: Should blogs make font choices for you, or not?

I’ve been making some minor tweeks to the excellent 1024 px WordPress theme that I started using a few weeks ago. I found a small issue with the CSS for images that are supposed to be center (a priority mistake meant it didn’t work) and I’ve made a few other minor tweaks. I finally got around to considering some questions regarding fonts, and I thought I’d ask you, my readers, give me the benefit of your opinions.

The 1024px stylesheet listed Verdana, Tahoma, Arial, and sans-serif as the search order for fonts. Not a bad list really, I think Verdana is an excellent screen font, with excellent legibility and good weight. Since my eyes have become somewhat presbyopic, and I spend a great deal of time reading stuff on screen, I’ve become somewhat more sensitive to these kind of issues.

But there are a couple of problems with the defaults.

First of all, Verdana and Tahoma (which are truly excellent, it must be said) aren’t really universal. I believe that they are installed by default on Windows and Mac OS, but not on most of the Linux installations that I have seen. On most Linux boxes, I end up using Dejavu Sans as a substitute.

If you don’t have either Verdana or Tahoma, this theme falls back onto Arial. I do have Arial installed on most of my systems, because lots of things need Arial or Helvetica. But here’s the thing: Arial is really ugly. It’s not pretty even in print, but it’s just wonky to use on screen. Sadly, this is what I get a lot of the time.

And, of course, if you don’t have any of those three, it falls to the browser default sans-serif, whatever the system default is, or whatever you’ve chosen.

Okay. So, I thought that perhaps i should just leave it up to you. I’ve all the font selections from the theme’s stylesheet. Whatever default you configure is what you get.

And yet, I’m not happy with that either. It appears (for instance) that on Mobile Safari, the default is always a serif font, and you can’t change it. That’s not very good: I think serif fonts are virtually by definition harder to read on screen. Mobile Safari does support Verdana. I could actually make a special style sheet just for my blog, but that seems to be a slippery slope.

So, the question is: do you think web page authors (and in particular, blog authors) should make font choices for you? If so, what choices are reasonable? If not, are there drawbacks?

Feel free to leave a comment below.

Addendum: Okay, I shifted back to specifying fonts. By default, mobile browsers like Safari on the iPad and iPhone seem to resort to a serif font, which on a tiny screen is simply not a good idea. The list I came up with was Verdana, Tahoma, DejaVu Sans, and then whatever “sans-serif” is. Arial is just too ugly to use.

The Broadcaster Project, revisited

One year ago today, I first published a link to The Broadcaster Project, a site which had several tips on using command line tools such as ffmpeg to assemble videos. I use a similar technique to do my more recent videos: I take the raw footage from the camera and resize it, denoise it, and add some overlaid text before uploading it to YouTube. Revisiting The Broadcaster Project, I see they have a few more recipes that can be useful, such as ones for assembling time lapse movies and the like. I also found a reference to youtube-upload, a command line python script that can automatically upload videos from the command line, a part of my process that I still did with the web interface.

HOWTO make a simple HTTP server…

It’s occasionally useful to have a basic HTTP running to serve the files in a directory. You might want to fetch some MP3 or movie files from one machine, or in my case, a PDF document that I’m hacking on my Linux box while ssh’ed in from my Windows laptop. In the past, I have used Jef Poskanzer’s mini-httpd, but there is an even simpler way, especially if you already have Python installed.

Just “cd towhatever directory”, and then type “python -m SimpleHTTPServer”. Voila! An HTTP server running, bound to port 8000 on that machine.

Very useful.

Revisiting TinyP2P

As I was driving in this morning, I entertained a train of thought that led me back to thinking about peer to peer networks. I recalled that I had seen a posting by Ed Felton some years ago about implementing a peer-to-peer networking scheme in a very few lines of Python. A few minutes of searching once I reached my desk reminded me that the name of this was TinyPTP, and that it was 15 lines of dense Python. A search of Ed’s Freedom To Tinker Website revealed nothing but dead links, but a few minutes with the Internet Wayback Machine resurrected it for our consumption:

TinyP2P

I recall that I tried to run this before, and had some difficulty, but haven’t tried again. Still, the basic idea is pretty interesting: you create a network of XMLRPC servers, whose basic functionality is to ensure that all network nodes have copies of all files. It uses the SimpleXMLRPCServer classes and some overly terse idioms to accomplish its task.

Here’s the thinking that leads me to here: I’ve been listening to a lot of stuff about the scalability of Facebook lately. Ironically, the scalability doesn’t contribute to user experience directly: no user uses very much of any of the Facebook resources. Facebook’s 60,000+ servers serve something like 200M+ users every day, so obviously each user is getting a very tiny fraction of any single server machine, a fraction so small that it could be easily subsumed by even the most tiny computing appliance. It is only the centralization which causes the need for scalability.

And, of course, a distributed architecture has the possibility of fixing a few of Facebook’s other ills, such as allowing more direct control over privacy.

So, here’s the idea: use ideas similar to the TinyPTP client to implement a distributed social network like Facebook. Implement it in a simple language like Python, and in a straightforward way (don’t be overly terse like TinyPTP). Pay attention to security, but also make it simple enough so that people can adopt it by downloading a single Python file and running it in a directory of their choosing on their machine at home.

It’s just a thought experiment at the moment. We’ll see if it gains traction in my head.