Getting Adobe Digital Editions to work in Ubuntu

Today we have a guest blog post from my wife Angela.  She is an avid Ubuntu user (in fact, so are our kids) and a great web researcher in general.  She wanted to borrow digital editions of books from our local library; however, the books are only available in the form of digital handcuffs.  So she set herself the task of getting Adobe Digital Editions (DE) working on Ubuntu lucid.  Without further ado, here’s her story:

  1. You need to install Wine (available in the package manager).
  2. On the Adobe Digital Editions page is a link to an installation TechNote (not far below the message that your system doesn’t meet the minimum requirements).
  3. Under the heading “Windows Solutions”, subheading “Manually install Adobe Digital Editions” is a link to download the latest installer for Windows. Click this and choose to SAVE it to your computer (not the RUN option).
  4. On my computer it appeared as “Adobe Digital Editions.desktop” which is an unknown file when you click on it. Right click on this icon and in the drop down box go to Properties -> Permissions and make sure the box “Allow Executing File as a Program” is ticked.
  5. Downloading an ePub book that runs in DE gives you an .acsm file. This is just a digital key or certificate. I found the first time I used it, I needed to drag and drop the .acsm file onto it for it to load into the library. After that I only had to click on the .acsm file, and it worked as it apparently does in Windows.

I have now installed this on three separate computers, and have noticed inconsistencies, probably related to the version of Ubuntu and/or Wine installed.  These are some possible bugs I have noticed – sadly I didn’t pay attention to which versions they correspond to:

  • For some reason DE did not always appear in the list of applications available in Wine (under the Applications drop down menu). Not sure why.
  • I noticed that although everything else seems to work okay (bookmarking the pages in the book I am reading, etc.) books “borrowed” from the library that have expired say on the bookshelf marked “expired” instead of disappearing. However this might be normal for Adobe DE even in Windows. 
  • On one install, the next time I restarted my computer after shutdown, the digital editions application icon on my desktop had lost the permission to allow it as an executable program (see above) and I had to re-enable this.
  • On one install it won’t close from the [x] in the window; I have to click on the little book icon on the upper left hand side and choose “close” from the drop down menu.
  • Occasionally I get an .acsm file that doesn’t work and find I need to go into Properties -> Permissions and tick the “Allow Executing File as a Program” option (this appears to be random and may be related to the certificate, not the DE install.)
  • An I/O error has almost always been a problem at my end, and I have needed to check the settings in the Wine registry.


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.  😉


Queensland floods IT relief being wrapped up

I has been our privilege at Liberty Systems & Software to support the flood relief efforts of High and Dry Computers 4 U, a volunteer effort to provide computers for those affected by floods in the Ipswich area who are least able to provide them for themselves. Our thanks go to Redlands College, who provided a number of systems for us to refurbish and donate to the flood relief effort. We recently received the attached letter of thanks to all involved.

Attachment Size
LetterofThankstoSponsors.pdf 191.12 KB


An interesting performance difference between perl and awk

(I used to love Stan Kelly-Bootle‘s column in Unix World, so i thought i’d share an experience a little like the ones he used to write about.  Hope some old-timers out there can get into it…)

The task i was working on involved taking a file containing a very large directory listing (about 158 MB) and determining the total size of all the files listed in it.  The file’s contents looked like this:

$ head -5 transaction.list 
-rw-r--r-- 1 root root 6575 Aug 5 2009 file-7647833002.log
-rw-r--r-- 1 root root 8223 Aug 5 2009 file-8304157181.log
-rw-r--r-- 1 root root 6929 Aug 5 2009 file-7605687521.log
-rw-r--r-- 1 root root 6802 Aug 5 2009 file-8408844563.log
-rw-r--r-- 1 root root 6787 Aug 5 2009 file-8420786471.log

So to sum the size of the files, i thought i’d write a one-line awk script.  But then i second-guessed myself.  I thought: for a file this size, perl has to be faster, right?  So i wrote a perl one-liner instead.  When i ran it first, it took a lot longer than i expected, so i checked the time it took:

$ time perl -we 'my $sum = 0; while (<>) { my @F = split; 
$sum += $F[4]; } printf "%dn", $sum; ' transaction.list

real    0m8.062s
user    0m7.970s
sys    0m0.080s

This seemed a little excessive to me, so i went back and ran the awk script which i had originally intended to write, and it turned out to be more than 4 times faster:

$ time awk '{ SUM+=$5 } END {printf "%dn", SUM}' transaction.list

real    0m1.474s
user    0m1.390s
sys    0m0.040s

Then i thought, “obviously i’m just a hack and i don’t know how to make perl sing”.  So here was the next cut:

$ time perl -we 'my $sum = 0; while (<>) { my ($size) = /d+[^d]+(d+)/; 
$sum += $size; } printf "%dn", $sum; ' transaction.list

real 0m4.387s
user 0m4.300s
sys 0m0.070s

Nearly twice as fast as the first perl version, but still nearly 3 times slower than the awk version.

I couldn’t be bothered optimising it any further, but i wondered: is there an inherent performance limitation in perl’s split function, or is it just that the overhead in booting up the perl interpreter is higher?

I ran these scripts on my laptop, a Lenovo ThinkPad X200s, with an Intel Core 2 Duo SL9400 CPU and 4 GB RAM, running Ubuntu Linux 10.04 (lucid) 64-bit.  A few of my normal desktop apps were also running.  I ran the scripts a few times each in succession to ensure that i was getting reasonably reliable results.

Any thoughts?  How could i have written the perl version more efficiently?