In the course of writing a little python command line RSS engine, I naturally came to a point where I needed to download the RSS feeds to store them and work with them.

My options looked like this:

• Use urllib2.urlopen which would download the feeds serially. When you have hundreds of feeds in your opml file, that takes too long. Besides, what do I have ADSL for?
• Use Twisted. But, my application is not a web app and frankly, switching the whole thing over to the Twisted event-driven model is overkill and unnecessarily complicated.
• Use wget with threads. The problem with that would have been that I'd have to jump through hoops to pass the data from the threads back to the main application, possibly with messy kludges like temporary files. No thanks!
• Use libcurl through the pycurl library. Ah, yes, perfect. Or so I thought.

Open Source Startup Marketing: Initial Steps

As innovative open source startups gradually grow ambitious enough to start thinking about an enterprise-class client portfolio, marketing becomes more of a pressing priority. My observation is that marketing is overwhelmingly regarded by open source geeks (an accolade I aspire to myself despite my sub-standard code-fu) as either superfluous nonsense-ridden hand waving, as arcane dark arts taught only in the bowels of the netherworld, or somewhere in between.

For a smaller open source startup, it doesn't have to fall into either category. It can be simple and straightforward, and that is what I have written this article for: to reduce the dimensions of kickstarting the marketing function for an open source startup by emphasizing on key areas with disproportionately emphatic results. More bang for your unit of effort. Less of a marketing department, and more of an image and a strategy for how to access the enterprise client market.

Think of this as an "We're a small open source startup and we're all arsekicking engineers, but it looks like we need to market if we're going to attract lucrative clients" HOWTO.

Here is a neat little application which extends the UNIX at daemon with the XOSD (X on screen display) for very effective, non-blocking, and simple notifications.

Most modern schools of requirements gathering and system specification development are user driven; this can often be the death of a development project. The truth which is known to the more successful technology development outfits is this: the user is irrelevant, the user does not know what is good for the system, and the user will often try to mislead you into developing software which does something they find useful.

Why do we develop software requirements specifications?

This article is aimed at the enterprise programmer. It aims to introduce sound practises around the naming of variables, with the objective of making life more productively busy for the maintenance programmer and keeping the technical writers busy enough to hang on to their meaningless little jobs.

Here's a very brief ten minute presentation on the position of F/LOSS in higher education which I was recently asked to do.

Creative Commons, as usual. Powerpoint to improve its reach.

Introduction

What is rate limiting with iptables?

iptables (http://www.netfilter.org) is the packet filtering firewall rolled into the GNU/Linux kernel starting with version 2.4.

In the transition from ipchains to iptables, many fairly significant changes were made. The most widely acknowledged was the introduction of statefulness, or 'connection tracking'. The more fundamental, and in my opinion, more exciting shift, has been the increased emphasis on modules.

This article will discuss the rate limiting module. The module itself is not overly complex, and I will try to emphasise application more than plain old invocation.