What's in my podcast roll

I’ve always been interested in learning and developing my skills, and over the past couple of years i’ve been increasingly targeting my professional development.  On a long commute, a great way to explore different areas of interest is listening to podcasts.  Here are a few of the things i’m listening to at the moment:

  • SANS Internet Storm Centre daily podcast [feed] – If there is only one podcast that should be on every IT professional’s podcast roll, this is it.  Johannes Ullrich‘s daily recap of security & Internet news is my “must listen” podcast.  Pros: Fast-paced, no fluff, edits out blank spots; very balanced coverage – i value Johannes’ opinion on almost every security topic; his enthusiasm is infectious – you can even hear his voice pitch getting higher and more excited as the podcast goes on.  Cons: none unless you like being uninformed or don’t like German accents.  Released every weekday (Johannes never seems to get sick; my son thinks he might be a cyborg 🙂 and usually around 5 minutes long.  I would pay for this podcast if i had to.
  • SANS ISC Monthly Threat Update [feed] – This is a long-format security update from Johannes Ullrich and sometimes a sponsor representative.  Pros: more in-depth coverage of certain topics, e.g. IPv6, DNSSEC.  Cons: covers many of the same news topics that have already been covered in the daily podcast; based on a webcast, so sometimes you have to go back and look at the slides to make sense of it.  Often a fair amount of time is spent on the monthly Microsoft Patch Tuesday update, which may be good or bad depending on your interests.
  • Risky Business [feeds] – This is an Australian podcast focused on security.  Pros: in-depth interviews with world-class guests who offer varied and fascinating insights; considerable time devoted to opinion and analysis of news; Patrick Gray is quite accessible on Twitter, and actually replies to messages meaningfully; quirky and sometimes outstanding full music tracks as outro.  Cons: Patrick and Adam/Mark laugh at their own jokes a bit too much and are a little obsessed with lulz; the electronic fart track for theme music makes me want to stab my eardrums out (tip: skip the first 30-40 seconds).  But the biggest con is that it’s not suitable for work – the podcast contains frequent coarse language and not all of it is beeped out.  I would love to share some of their material with my wife and kids, but references to anal rape in prisons goes beyond edginess to just plain poor judgement.  (Have you ever actually been into a prison where this was a risk, Patrick?  It’s really not a laughing matter.)  This isn’t enough to make me stop listening, but it’s a definite audience-limiter.  Make sure you subscribe to the RB2 feed as well – it covers AusCERT conferences and other similar events.
  • Cisco TAC Security Podcast [feed] – Four to six Cisco security TAC engineers talk news, tips, and products.  Pros: efficiently edited; engaging hosts, not boring; useful practical information (i’ve listened to their IPsec troubleshooting podcast more than once whilst working on a VPN problem).  Cons: feels a little too scripted sometimes; very Cisco-centric (understandably), but this means a lot of focus on ASA, which to my mind is not a compelling firewall platform.
  • Packet Pushers [feeds] – This podcast revived my interest in networking, and is a major contributor to my renewed interest in certification and professional development.  If you’re new to the podcast and like it, it’s well worth subscribing the to the all audio feed, starting from the beginning and listening to all the episodes.  Until very recently (with the Cisco Nexus series and the various SDN-related episodes) there was very little repetition of topics.  Pros: experienced presenters; world-class guests; never boring.  Cons: Greg Ferro dominates a bit too much, often talking over the top of his co-hosts; a little Cisco-centric; sometimes too many presenters, which means not everyone gets a chance to share their expertise.  Greg, Ethan, and most of the guys with a Cisco background are somewhat uninformed about Linux/Free Software/Open Source licensing, values, and culture.  They can also be uncritically fanboyish when it comes to Fruit Company laptops and tablets.
  • The Linux Action Show [feed] – A desktop/mobile/gaming-centric podcast in both video and audio formats.  Pros: lots of different news from the Linux world; CC-BY-SA licensed (o/); assumes Linux on the desktop is normal (!); metal-styled theme music is easy on the ears.  Cons: Bryan Lunduke seems to think he’s a cross between James Hetfield and Patrick Warburton, and only occasionally pulls it off; could be edited more compactly without losing its feel; a little too much material released.  I find it a little hard to keep up; a weekly podcast should be targeting around 30 minutes, in my opinion.
  • Tuxradar [feed] – a UK-based Linux news & opinion show from the creators of Linux Format magazine.  Pros: good format which incorporates listener feedback; strongly committed to Free Software from a socio-political perspective as well as a technical perspective; as expected, doesn’t assume you’re a freak if you run Linux on the desktop.  Cons: audio often muffled, slurred, and crowded with random chit-chat & laughter – this is as much a result of poor diction and too many presenters as it is of low budget or technical issues.  Released fortnightly, which is about right for a long-format show.
  • DevOps Cafe [feed] – DevOps news, interviews, and opinion.  Pros: good interviews with people from various perspectives, creative commons licensed.  Cons: a little too concerned with what’s cool & trendy in the industry (which one might argue is inevitable with DevOps).
  • The Cloudcast [feed] – Cloud industry news and opinion.  Pros: helps to de-cloud (bad pun fully intended) some of the vagueness around many *aaS (… as a Service) terms.  Cons: assumes cloud is good, doesn’t get into much technical or philosophical discussion about why we should use cloud.
  • Geeks and God [feed] – God meets nerds.  Pros: provides a unique perspective on technology that is more aware of “soft” issues (and not just spiritual ones).  Cons: content is a bit Drupal-centric (not a con for me, but if you don’t use it you might want to skip the drupal spotlight section); podcast has gone a bit quiet lately (the old team of Rob Feature and Matt Farina was prolific and particularly well-practiced at keeping discussion flowing and making a podcast interesting).
  • Andy Stanley – In my opinion, the best Bible communicator of our generation.  Even if you don’t consider yourself a Christian or “religious”, he’s worth a listen to moderate the fringe elements of Christianity who seem to dominate popular media.  His content comes in several different podcasts:
    • Your Move – a “best of” series; tends to be shorter than the weekly podcast.
    • North Point Weekly Podcast – I’ve often found the topics in this one more interesting than the “best of”.  Not all of the messages are from Andy Stanley, and i find them rather bland and traditional by comparison.
    • Leadership Podcast – good insights and the some interesting interviews on various leadership topics, not just church leadership.  Released monthly, usually around 30 minutes in length.

Some shows i’ve previously had in my podcast roll:

  • No Strings Attached – Wireless networking podcast.  I found this too slow and too scripted and got bored quickly.  I probably could have given them more of a chance to impress me, but i didn’t even make it through one episode.  No doubt as it went on it got better, but i’m less involved with wireless networking than i was previously, so it hasn’t made it back onto my radar.
  • FLOSS Weekly – Randall Schwartz’ Free Software podcast; felt too slow and scripted to me.
  • Linux Weekly News – verbatim reading of the LWN.net news articles; a bit dry.

What’s missing?  One thing that i haven’t found is a podcast that deals with system engineering in the enterprise from a Linux/networking perspective.

Source: libertysys.com.au

Back to the future for the Ubuntu desktop

The Register has a review of the Ubuntu 11.04 beta release which suggests there are some rocky times for existing Ubuntu users ahead.  The part the article that stuck out to me reads:

The highlight of the current launcher is the plethora of keyboard shortcuts, which let you to launch applications, open file browsers and call up system-wide searching without taking your hands off the keyboard.

This is basic functionality which X11 window managers have had for years.  I use IceWM which has had these features available through editing simple text configuration files for as long as i can remember (probably more than 10 years, since the SourceForge history for icewm’s 1.2 branch extends back to the year 2000).  And icewm provides many keyboard features which are simply not exposed to the user in current versions of the default Ubuntu GNOME desktop (e.g. go back to the previous virtual desktop used regardless of which number it was).

The paragraph continues:

There are also a few nice touches in the various indicator apps – for example you can simply hover your mouse over the volume indicator and use the scrollwheel to adjust the volume without ever actually clicking anything.

Again, this is basic functionality.  I use this feature in Amarok 1.4 (a really old version that i’m not supposed to admit that i still use – but that’s the subject of another blog post 😉 all the time.  Is it really so innovative?  Not only that, Ubuntu has been pulling functionality (like tooltips which tell you how much battery time is remaining) out of the indicator apps for the past several releases.

What this all suggests to me is that we’re about to embark on a period in Ubuntu’s history where functionality will be back to basics.  (Similar to what happened when Apple first released iOS and it lacked basic functionality like cut & paste.)  As for me, i’ll stick with Ubuntu classic desktop or perhaps take refuge on Debian while things settle down.  At the moment, Ubuntu 10.04 LTS actually fulfills all of my desktop/mobile computing needs, and i’m not prepared to iron out the bugs for them on a user interface which is targeted at users with very basic skills and with much more limited functionality needs than my own.

Source: libertysys.com.au

Observium and GPL misconceptions


EDIT: As of 2013-10, I’ve started an Observium fork called LibreNMS.  This is just here for historical reference.

I recently started using Observium (a great network monitoring package which you should use), and found that I had some useful patches to contribute fairly soon afterwards.  I submitted a patch to enable bulk selection of checkboxes in JavaScript and it was initially rejected, in part because I included my own copyright header on a new file.

This started a discussion on the IRC channel during which numerous common misconceptions about the GNU GPL (the Free Software license under which Observium is released) were thrown around.  To summarise, these were the opinions given:

  1. Maintaining individual contributors’ copyright notices in a Free Software project is nonsense.
  2. The GPL is open source, but isn’t free.
  3. The GPL is not about the user, it’s about Richard Stallman wanting your code and not wanting anyone to use his.
  4. The GPL does not coexist with the LGPL.
  5. The GPL does not provide any benefits to the user of the software.
  6. The GPL is hypocritical; as it restricts the use of the free software it supposedly protects.
  7. The GPL is unclear and untested when it comes to linking restrictions.
  8. Free Software has more restrictions than commercial, closed source software.
  9. The GPLv3 and GPLv2 are incompatible and so cannot be used in the same software project.

Eventually the discussion degenerated into name-calling and personal insults.  (Unfortunately, I was denied permission to publish a copy of the relevant IRC logs so that the above summary could be independently verified.  I guess you’ll just have to take my word for it. 🙂

I will address some of the individual points above later, but I think most of them share a foundational assumption which drives most of the BSD-loving crowd’s fear of the GPL.  This assumption may be summed up as follows: the original author of a software package is the most important person or organisation in its existence.  (You may substitute “project leader”, “main copyright holder”, or similar in place of “original author” in the cases where a project is is active but no longer maintained by its original author.)

On this point there is no question: Adam Armstrong is much more important to Observium’s existence than I am.  But I think the question of licensing requires a little more nuance than simply assuming that the original author’s wishes trump everything.  One way of thinking about this is to compare the time investment by the original author and the other parties involved.  To do this, let’s think about some scenarios:


I don’t know how many hours Adam has spent on creating Observium, but I’m sure it was a substantial time investment.  Running a quick shell script over all the PHP, JavaScript, CSS, shell script, and SQL files in my copy of Observium (excluding the jpgraph, jquery, and overlib libraries) shows that there are over 45,000 lines of code in Observium r1957.  Assuming that the overall number of lines written since the beginning of the Observium project in 2006 is four times what is currently in the svn trunk (a total guess – if I cared to, I could get much closer to the real figure by processing the svn logs), this means that there were about 225,000 lines written over 4.5 years, or an average of over 136 lines per day.  Assuming those 136 lines took 2 hours to write (again, a total guess), this represents a total coding time investment of over 3200 hours over 4.5 years.  This figure does not include any time spent supporting the project, maintaining its infrastructure (e.g. web site, source code repository), or coordinating with other developers, but it does give a useful minimum figure.

Another major party with a significant time investment in Observium is its user base – the people who install it, configure it, and use it for monitoring real networks on a daily basis.  I have no way of knowing or even guessing how many such people there are, but let’s assume for the moment that my experience with Observium is roughly normal.  Over the past two months, I have installed it on an existing VM in my client’s ESX cluster, then created a new VM for it, migrated the RRD data from the original 32-bit VM to the new dedicated 64-bit VM, configured Observium to monitor the majority of my client’s Linux servers (both virtual and physical) and network equipment (mostly HP ProCurve switches).  I’ve made Observium the number one web page I visit when I arrive on site.  I’ve submitted a few patches, some of which have added useful functionality.  Overall, I would say that I’ve invested about 2 hours per week in Observium over the last 2 months, for a total of about 16 hours.

It should be obvious where I’m going with this: it would only take 200 users with similar experiences to mine a total of two months to roughly equal the time investment of the baseline coding of Observium.  My guess is that there are a lot more users than that (probably an order of magnitude more), and that most of them have been using the product for a lot longer than I have (probably an order of magnitude longer).

Other software

Observium is not a typical end-user product – it’s targeted at enterprise and service provider networks and requires some skill to implement (although not as much as some of its “competitors” in the network monitoring space).  Consider the CPU scheduler of a desktop or mobile operating system kernel such as Linux, Android, Microsoft Windows, or Apple iOS.  It would typically be roughly two orders of magnitude smaller than Observium (around 500 lines of code, let’s say).  The original developer(s) may have spent a significant length of time researching and testing it, but if a CPU scheduler doesn’t have workable functionality within a few months, it would likely be considered a failure.

Compare this with the number of users who depend upon that scheduler every day, and the difference is dramatic: the overall time invested by the users (in simply operating their devices and relying on them to perform at expected levels) vastly outweighs the time investment by the developer, probably within the first week of its release.

What does this have to do with the GPL?

What I’m getting at here is that for most software, the time investment on the part of the users is often roughly equal to (in the case of specialised software like Observium), and in many cases massively greater than (in the case of a generic CPU scheduler) the time investment on the part of the developers.  Software developers put their time into design, programming, testing, support, project infrastructure, etc.; users invest time in installation, testing, configuration, supporting other users, promoting, etc.  Both parties are major stakeholders in the software, and a good Free Software license should strike a balance between the rights of the different stakeholders.

What the GPL offers users

(In this post, I’ll assume use of version 3 of the GPL unless otherwise specified.)

The GPL’s preamble says that its purpose is “to make sure it remains free software for all its users”.   The primary benefit the GPL brings to users of GPL-licensed software is the guarantee that the software they have will remain free.  That is, no one can revoke their right to use the software, nor can anyone change the conditions under which they are allowed to copy and redistribute it.  (It doesn’t guarantee that future versions will be free, since the copyright holder might choose to relicense it, but it guarantees their access to the software they currently use.)

This offers adopters of GPL-licensed software a key advantage over proprietary software, since they know that time they invest in the software will not be wasted.  No vendor can come along (like Amazon did with one of their Kindle books) and decide that all customers need to delete their copy.  No copyright holder can demand additional license fees in order to maintain a customer’s right to run an existing installation of the software.  No party can sue them for using the software inappropriately, since the GPL explicitly excludes the executing of GPL-licensed software from its terms.  [See section 2 (“This License explicitly affirms your unlimited permission to run the unmodified Program.”) and section 9 (“You are not required to accept this License in order to receive or run a copy of the Program.”) for further details.  Incidentally, I believe this to mean that typical Windows-based installers of GPL software should NOT require the user to accept a copy of the GPL license in order to install the software.  However, I am not a lawyer.]

So the GPL offers conditions which are strong incentive for users to adopt the software.

What the GPL offers 3rd-party developers

Another stakeholder in the Free Software ecosystem is the 3rd-party developer.  Often these developers will be users of the software as well, and will make their own modifications, then pass on these modifications (or updated copies of the software) to others.  The GPL offers such developers essentially the same benefits which it provides to users, guaranteeing that their time investment in improving, distributing and supporting the software will not be wasted.  This is further enhanced if a distributed copyright model (such as that employed by the Linux kernel) is employed, because not only are currently-released copies of the software protected, but any licensing change to future versions must be approved by all copyright holders.

For me as a very part-time Free Software developer (among my other roles), this means that I’m much more likely to contribute towards a GPL-licensed project (or one using a similar license, such as the AGPL or LGPL), and also much less likely to be suspicious of the original developers’ motives if they do not ask me to waive copyright on my contributions.

Specific misconceptions

Now on to some of the specific issues raised in the Observium IRC channel.  I am not a lawyer, so these are just my opinion.  However, I hope that they are justified and well-documented opinions.

  1. Maintaining individual contributors’ copyright notices in a Free Software project is nonsense.  Because 3rd-party developers can be assured that their time investment in a piece of software is not wasted, using shared copyright on a GPL-licensed project is a way to gain developer mindshare and encourage further contributions.
  2. The GPL is open source, but isn’t free.  This seems to stem from an understanding of “free” which assumes that the original developer is the only major stakeholder in a software project.  When seen from the perspective of total time investment, the GPL’s restrictions on modification and redistribution (but not on use) are essential to maintain the freedoms of users, distributors, and 3rd-party developers alongside those of the original author.
  3. The GPL is not about the user, it’s about Richard Stallman wanting your code and not wanting anyone to use his.  The Free Software Foundation is mentioned in the GPLv3 only as
    1. the publisher of the GPL, and
    2. an example of an organisation which publishes GPL-licensed software.

    Nothing in the license requires any involvement of the FSF or Richard Stallman.  The fact that Red Hat have built an incredibly successful commercial enterprise on a codebase that is allegedly more than 50% GPL-licensed should be sufficient evidence that this is not the case.

  4. The GPL does not coexist with the LGPL.  The FSF has a detailed FAQ entry about this.  The kernel of truth behind this misrepresentation is that software licensed under GPLv2 only (as opposed to GPLv2 or later) is incompatible with the LGPLv3, which is unsurprising, since the provisions of the LGPLv3 could hardly be anticpated at the time of the GPLv2’s drafting.  The latest versions of GPL and LGPL are explicitly designed for compatibility.  Due to this design, if a project is licensed under GPLv2 or later (which most GPLv2 code is – the notable exception being the Linux kernel), then it is LGPLv3 compatible.
  5. The GPL does not provide any benefits to the user of the software. I hope that in this post I have justified the position that GPL offers great benefits to the user.
  6. The GPL is hypocritical; as it restricts the use of the free software it supposedly protects.  As it stands, this statement is factually false (see the references to sections 2 and 9 of the GPLv3 above).  However, I suspect that the thought behind this statement has re-use (presumably in a non-GPL-licensed project) by the author or a 3rd party developer in view rather than use by the end-user.  There is no question that the GPL has restrictions; however, they fall upon the parties modifying and distributing the software, not upon the user.Additionally, there is nothing to prevent a copyright holder from re-releasing the same code under a different license.  Licensing my code under GPL means that a large company can’t come along and commercialise my code without complying with the same conditions as everyone else.  To me, this is a great protection for my software and my time investment.
  7. The GPL is unclear and untested when it comes to linking restrictions.  I’m not a lawyer so I cannot comment on this with any authority.  I personally feel that the GPLv3 has cleared up a lot of ambiguities in this area and I’m much more comfortable with it in this respect than I was with the GPLv2.
  8. Free Software has more restrictions than commercial, closed source software.  All I can say in response to this is that this description doesn’t fit most of the closed source software licenses I’ve ever had the displeasure of reading.  Most of them specifically disclaim granting the recipient of the software any rights whatsoever over the software.
  9. The GPLv3 and GPLv2 are incompatible and so cannot be used in the same software project. This is true at the strict level, since if a project is licensed under GPLv2 only, it is not GPLv3 compatible.  However, the majority of GPLv2 software is licensed under GPLv2 or later (the Linux kernel is a notable exception), or dual-licensed (e.g. with the MIT license), so this shouldn’t be a major concern.

Where to next for me and Observium?

Where this leaves me with Observium is a little unclear.  I’ve tried to fit in with the original developers as best I can so far (including going back to Subversion for version control, despite its annoying limitations).  I’ve started small, but I was hoping to ramp up my contributions over the next few months.  Being required to assign copyright of contributions is an enthusiasm sapper for contributions, as is the suggestion that at the first chance Adam will relicense the project to BSD or MIT.

Observium is a great piece of software: it offers killer features for minimal configuration, saving me a lot of time and effort, and it’s fun and easy to hack on.  So while it remains GPL-licensed, I’ll probably swallow my pride and keep contributing.  My contributions are only a tiny fraction of the overall project, anyway.  If it all goes pear-shaped, I can always fork.  😉

Source: libertysys.com.au

dircproxy for always-on, unobtrusive IRC

I use IRC a lot for asking questions (and hopefully answering some as well) about Free Software projects, particularly Ubuntu-AU.  Most of the time i use IRC from my laptop, which means that every time i shut the lid or disconnect from the wired network and reconnect via wireless, my IRC connection drops out.  This results in disconnect/reconnect messages which inconvenience my fellow users, and sometimes even causes multiple accounts to be logged in.  I’ve also had a few instances of flaky Internet access causing multiple disconnects/reconnects in quick succession.  The solution i came up with for all this was to run an IRC proxy on my personal server.  I found dircproxy a really simple, easy-to-use proxy server which just worked.  Check out my wiki page for more info.

Source: libertysys.com.au