Another Reason Closed Source is Harmful

Open Source/Free Software includes a number of tribes. There are the FSF true believers, epitomized by RMS, who hold that software should be free on philosophical/ideological grounds. Even if one could adduce facts showing that Free Software was less optimal than closed source, these folks would be unmoved; it’s a matter of morality.

Then there are folks like Cory Doctorow and ESR who still insist on using strictly Open Software but do so on (mostly) pragmatic grounds. Members of this tribe seek to avoid lock-in or loss of data. It’s easy to see why someone like Doctorow would fear having his data locked in some proprietary format that could become unsupported at the whim of some software company.

There’s also the tribe that is willing to use a proprietary program or OS, when necessary, as long as it doesn’t involve their data. As a Mac user, I fall into this group. Even though I prefer open source, I’m perfectly happy to enjoy the benefits that OS X brings me but I would never use Word, or Pages (the Mac answer to Word), or Numbers (the Mac spreadsheet). Instead all my data is held as plain text (even, thanks to Org Mode, spreadsheet type data). If OS X were to die tomorrow, my data would be just as useful and accessible on Linux or even Windows.

The key here is that you must never commit any data you care about to anything but plain text. If someone or something requires, say, word documents, you write and maintain it in Org- or Markdown-mode and export it to word as Mark Szepieniec and Christophe-Marie Duquesne outlined for résumés. Most of us know and practice all this no matter which tribe we adhere to.

It turns out, though, that it’s a bit more complicated. Jonathan Zdziarski has an interesting post on digital forensics and the threat that closed source poses to it. Most law enforcement agencies use closed source programs to extract data from phones or computers and for other forensic tasks. One problem is that the user has no way of knowing what the programs are doing or how they’re massaging the data. This can present legal problems when, for example, the defense insists on auditing the program that produced the data. In the case of breathalyzers, which are also mostly closed source, this has already resulted in DUI dismissals.

It gets worse though. Zdziarski reports that the results these forensic programs produce are often flat out wrong—even made up in some cases. That’s an obvious problem no matter which side of law enforcement you’re on. If you’re the defendant, you might get wrongly convicted. If you’re with law enforcement, guilty parties may be erroneously cleared.

Closed source isn’t the only problem that Zdziarski describes but it is a large one. We will certainly see cases involving forensics depending on these programs challenged and dismissed. In the mean time, those of us who support open source get to feel smug. Just don’t find yourself on the wrong end of a digital forensics investigation.

Posted in General | Tagged | Leave a comment

Version Control

Everybody agrees that version control (VC) is the right thing but, sadly, too often it’s ignored anyway. I use version control—Git via Magit—in two ways. First, it’s the primary way that I keep my machines synchronized. I could, of course, use something like Dropbox for this but Git works well for me and I’ve automated the process so I see no reason to change. The point is that synchronization is not something you need version control for.

The real reason for VC is that you have a history of the changes you’ve made and that, as a result, it’s easy to drop back to a previous state if you code (or write) yourself into a box. Eric Raymond has a revealing post neatly demonstrates the virtues of version control. He writes about a “phase-of-the-moon bug” that, despite frequent and comprehensive regression tests, suddenly appeared after a commit. Nothing too strange about that but when he dropped back to the previous commit the regression tests still failed even though they had passed just a few minutes ago.

It turned out that several commits had the mysterious bug but Raymond was able to locate the culprit pretty quickly with Git bisect. Even if you’re not a Git user, you could still perform the bisection process manually although a good deal less conveniently. The real enabling mechanism was VC. Without it, he’d have had a long and frustrating ordeal of trying to locate each change and test if it was the genesis of the problem.

I’ve heard many developers express the opinion that they don’t need VC because they work alone. As Raymond’s story illustrates, VC can save the day even for the lone developer1. Hop on over and read Raymond’s post and see if it doesn’t convince you that you should be using VC whether or not you’re working alone.

Footnotes:

1

The code Raymond was working on, GPSD, is, in fact, a multi-developer project but that doesn’t come into play here. The story takes place while he was working alone and all the code was his.

Posted in Programming | Tagged | 1 Comment

Extending Isearch

Nicolas Petton presents a nice bit of Elisp that extends the isearch functionality. With his code, you can search for the symbol at point or the active region if there is one.

The first of these is easily accomplished using【Ctrl+w】from within isearch but that takes an extra key chord. With Petton’s code you just invoke his isearch-thing function and it searches for the symbol at point unless there is an active region.

If you are a heavy user of isearch and find yourself typing 【Ctrl+s】 and then 【Ctrl+w】 a lot, this may be win for you.

Posted in General | Tagged | 2 Comments

Tramp with Multiple Hops

The Emacs Tramp package is a wonderful thing. With it, you can easily edit files on remote machines in a virtually transparent fashion. Most Emacs users are familiar with Tramp and use it to edit files on machines on the local network or on remote-network machines directly reachable on the Internet. Often times, though, those remote-network machines are not directly reachable.

A typical example occurs when a developer is working from home and needs to access a machine on his work network that is protected by a firewall. Emacs, of course, can also handle this case. The normal way is to set rules for how to reach remote-network hosts in your .emacs or init.el file. The rules are a bit complex but are documented in the Tramp manual. Sometimes, though, you just want a one-off access to some protected host and it’s a pain to temporarily add Tramp configuration rules for it.

Fortunately, David Vázquez has tweeted the answer:

Unless you need to repeatedly access some remote host, this is a much easier method. The tweet tells you just about everything you need to know but you can see the details in the Tramp documentation.

Posted in General | Tagged | 4 Comments

Awesome Emacs

If you’re new to Emacs, after you learn the basics, can navigate around in buffers, and deal with finding and saving files you’ll probably start looking for packages that can help streamline your work flow. ELPA makes installing those packages easy but how do you find the ones that suit you?

One answer is the Awesome Emacs project, a community driven effort to curate a list of Emacs packages that people find particularly useful. Each package on the list has a link to some elementary documentation—usually, but not always, a GitHub README file. A testament to the quality of the list is that almost all the packages I have installed are on it. That gives me confidence that I’ll find the others on the list useful too.

You probably won’t want to install them all because many are for specialized environments such as Erlang development. The packages are listed by category so it’s easy to find packages relevant to your needs. Even if you’re an experienced Emacs user, it’s worthwhile taking a look at the list.

Posted in General | Tagged | 2 Comments

Wisdom

Some wisdom from Bozhidar Batsov

Posted in General | Tagged | 2 Comments

Building a Dynamic Menu

John Kitchin, whom I’ve written about many times, has another post up on a nice little utility. He describes how to build a dynamic menu in Emacs that gets rebuilt as things change.

He gives the example of a menu item that lists every file in a directory. As files are added and deleted, the menu adjusts to the directory’s new contents. The menu is recalculated only when it is activated so there’s no need for it to track the directory in real time.

It’s easy to imagine all sorts of situations in which having such a menu might be useful. For example, I could have a menu that let me choose a post from my post queue to publish to Irreal. Kitchin’s code is just the latest of the many interesting things he’s contributed to the Emacs community lately. It’s worthwhile subscribing to his blog to keep up with his output.

Update: Kitchen → Kitchin

Posted in Programming | Tagged | 2 Comments

PGP Problems

I’ve often written about the need to encourage wider use of encrypted emails. As everyone knows, the main problem is that existing email encryption solutions are too hard to use: Aunt Millie simply won’t deal with the complexities. But what are those problems? On the Mac, for example, GPGMail integrates more or less transparently with the Mail App. There are two buttons for choosing signing and/or encrypting an outgoing email—which can be set to perform their functions by default—and incoming encrypted mail is automatically decrypted, perhaps after prompting for a password for the private key. Probably easy enough for even Aunt Millie.

So what are the problems? Matthew Green has a post that offers an answer. The real problem is what it always is with crypto systems: key management. Current email encryption systems, which are mostly all based on the OpenPGP protocol, illustrate this nicely. After you’ve generated a GnuPG/PGP key, how do you communicate it to Aunt Millie? How she can she be sure it’s really your key and not that of her other, conniving, evil nephew? Those are just some of the problems that an email encryption system must deal with. Read Green’s post for exactly what those problems are and some possible solutions.

Posted in General | Tagged | Leave a comment

Map Reduce Explained

If you’re a Lisper, the chances are that you understood the basics of Google’s map-reduce framework before you even read the paper. However, many people without a Lisp background find the ideas difficult to understand. Fortunately, if you fall into this group, Mathieu Blondel has you covered

Posted in General | Tagged | Leave a comment

The Editor of a Lifetime

Recently, I wrote about Sacha Chua’s chat with Harry R. Schwartz and his work with EmacsNYC, which, among other things, releases videos of talks that its members give to the group. The latest video is a talk by Perry Metzger about his 31 years as an Emacs user.

Metzger talks about Emacs’ enduring popularity and why anyone would keep using it for more than 3 decades. There are many answers to that, of course, and Metzger talks about several of them but the main reason is that Emacs excels at the thing programmers, writers, and others whose jobs mainly involve working with text do the most: edit text. He says that a modest effort in becoming proficient in Emacs pays daily dividends in time saved editing text.

The talk is not all cheerleading though. Metzger talks about the shortcomings of Emacs and what we can do to address them. These include better email support, CALDAV and CARDDAV integration, improvements to the extensions language, threads, HTML and PDF display, and others.

Metzger is an interesting guy (I remember reading his blog years ago before he abandoned it) and his talk is well worth watching. The video is 68 minutes so plan accordingly.

Update: There’s an interesting discussion of the talk at the Google+ Emacs Community. Metzger expands on his discussion of Email and Web page rendering, so it’s definitely worth a look if you liked the talk.

Posted in General | Tagged | Leave a comment