From the category archives:

Computing

Here’s my favorite line from an article Life on the Command Line by Stephen Ramsay:

I also don’t do this [work from the command line] out of some perverse hipster desire for retro-computing. I have work to do. If my system didn’t work, I’d abandon it tomorrow.

That’s refreshing. Some of the more ardent command line advocates give the impression that they use the command line out of pride rather than out of a desire to get work done. Ramsay is recommending his way of working, not bragging about what he’s able to do. He has some interesting ideas, especially in his follow-up article The Mythical Man-Finger.

By the way, I’m no command line wizard; I’m a fairly typical computer user. On the other hand, my use of the command line and Emacs has been increasing.

Related posts:

Confusing familiar with simple
Superficial convenience

{ 17 comments }

Two-finger scrolling on Windows

by John on July 19, 2011

One of my favorite features of Mac laptops is two-finger scrolling. This lets you scroll down a long document similar to the way the middle wheel does on a Windows mouse.

I mentioned on Twitter this evening that it would be nice if Windows had this feature. Apparently many newer Windows laptops come with this capability.  Todd Brooks replied that my laptop might be able to the two-finger scroll if I upgraded my touchpad driver. He was right. I went to the Microsoft Update site and saw that one of the optional updates was exactly what Todd suggested I install.

So far it seems that the two-finger scrolling on my ThinkPad isn’t as smooth as it is on a MacBook Pro, but it’s still nice to have.

{ 2 comments }

Sorting

by John on July 4, 2011

From Knuth’s book Sorting and Searching:

Computer manufacturers of the 1960’s estimated that more than 25 percent of the running time of their computers was spent on sorting, when all their customers were taken into account. In fact, there were many installations in which the task of sorting was responsible for more than half of the computing time. From these statistics we may conclude that either

  1. there are many important applications of sorting, or
  2. many people sort when they shouldn’t, or
  3. inefficient sorting algorithms have been in common use.

Computing has changed since the 1960’s, but not so much that sorting has gone from being extraordinarily important to unimportant.

{ 5 comments }

From the world, to the world

by John on July 1, 2011

Edmund Harriss describes an interesting pattern he sees in mathematics and constructivist art in his interview on Strongly Connected Components. For most of history, mathematics and art have been fairly direct abstractions of physical reality. Then in the 20th century both became more and more abstract. But then a sort of reversal took place. After reaching heights of abstraction — Harriss cites Gödel and Picasso as examples — both mathematics and art began to apply abstractions back to the physical world.

… starting from clearly abstract structures and building something real from the abstract rather than abstracting something from the real. … You have models that you can then apply to the world rather than models you took from the world.

Stephen Wolfram has an analogous idea about computer programs. Until now we have written programs to solve specific problems. Wolfram suggests we reverse this and explore the space of all possible computer programs. As he demonstrates in his magnum opus, simple programs can have surprisingly complex behavior. We may be able to find some relatively small but useful programs that way.

As Edmund Harriss alludes, people have successfully applied very abstract mathematics, mathematics developed with no physical application in mind, to physical problems. I’m more skeptical of Stephen Wolfram’s proposal.

Suppose you find a program that appears to solve some problem, such as optimally controlling a nuclear reactor. How do you really know what it does? You didn’t write it; you found it. It wasn’t designed to solve the problem; you discovered that it (apparently) solves the problem. Wolfram is optimistic that we could discover programs that we might never be able to write. But a program that powerful would likely also be impossible to thoroughly understand.When Wolfram says “Look what interesting behavior tiny programs can have!” I think “Look how hard it can be to understand arbitrary programs even when they’re small!”

Computer science might not be that helpful in determining what a found program does. It is theoretically impossible to write a program that can always determine whether another program stops. We would have to study the program empirically. This process would be more like squeezing an extract from some plant root and testing its medicinal properties than designing drugs.

Related post:

What does this code do?

{ 2 comments }

Platform lock-in

by John on June 22, 2011

From Baron Schwartz speaking at the O’Reilly Media MySQL Conference:

We talk about proprietary vendor lock-in, but in many cases the reality is that anyone who uses any platform, even an open source one, ends up being locked-in to some extent. Switching is something you just can’t contemplate after a while.

{ 3 comments }

Software under-represents reality

by John on June 20, 2011

From Jaron Lanier:

I love software, but software always under-represents reality. Reality has this depth to it and potential for surprise and subtlety that you just can’t get from software.

Related posts:

The bipolar Internet
Underwhelmed with progress
Make something and sell it

{ 9 comments }

Clutter-discoverability trade-off

by John on June 1, 2011

There’s a tension between presenting a user an uncluttered interface and helping the user discover new features. This post will begin by discussing two extreme examples. On the cluttered but discoverable end of the spectrum is Microsoft Word 2007. On the uncluttered but also undiscoverable end is Emacs.

Microsoft added the ribbon toolbar to Office 2007 to make it easier to discover new features. Before that release, 90% of the feature requests the Office team received were for features that Office already supported. The functionality was there, but users couldn’t discover it.

Word 2007 ribbon

According to this report, the ribbon has been remarkably successful.

Data is showing that the redesign of Office really did reach this goal — Word 2007 and Excel 2007 users are now using four times as many features as they used in previous versions, and for PowerPoint, the increase in feature use is a factor of five.

Power users often dislike the ribbon, but most of the estimated half billion people who use Microsoft Office are not power users.

(By the way, you can collapse the ribbon with Control-F1. The ribbon will reappear when you click on a menu. On a small screen, say on a netbook, this could greatly increase your vertical real estate.)

In some ways Emacs may be the exact opposite of Microsoft Word. It has an enormous number of features, and yet it doesn’t feel cluttered. The downside is that discoverability in Emacs is pretty bad. The best way to discover Emacs features is to read the documentation. There are ways to discover features while using Emacs, but you have to be fairly deep into Emacs before you learn how to learn more.

Can you increase discoverability without adding clutter? Maybe if your design is not very good to begin with. But after some refinement it seems inevitable that you’ll have to decide whether you’re willing to increase clutter in order to increase discoverability.

One suggested compromise is to have interfaces adapt over time. Applications could start out with voluminous menus when discoverability is most important, then hide uncommonly used options over time, reducing clutter as users gain experience. Microsoft tried that approach in Office 2003 without much success. It sounded like a good idea, but changing menus scared novice users and annoyed advanced users.

A variation on this approach is to make controls visible based on context rather than based on frequency of use. People find this easier to understand.

The trade-off between discoverability and clutter may be a question of where you want your clutter, in the UI or in external documentation. I suppose I’d prefer the clutter in the UI for software I use rarely and in the documentation for software I use the most.

Related posts:

Is helpful software really helpful?
Good user interface design: EpiPen
Bad user interface design: hotel showers

{ 22 comments }

Bumblebee software

by John on May 16, 2011

Some say that aerodynamics can’t explain how a bumblebee flies. Perhaps that was once the case, but as far as I know there are no difficulties now. The bumblebee story persists as an urban legend. And it makes a nice metaphor for things that work better in practice than in theory.

Here’s the passage that brought the bumblebee story to mind.

Almost every software engineering principle that has become generally accepted as useful and valuable, Emacs flouts. The code is 24 years old, huge, and written by hundreds of different people. By rights, the whole thing should blow up. But it works — and works rather well.

This comes from Jim Blandy’s chapter in Beautiful Architecture. Blandy explains that Emacs’ architecture has allowed it to thrive despite some apparent disadvantages. Emacs is mostly written in its own programming language, Emacs Lisp.

Emacs Lisp has no object system, it’s module system is just a naming convention, all the fundamental text editing operations use implicit global arguments, and even local variables aren’t quite local.

In short, Emacs expects developers to be self-disciplined and does not enforce a great deal of external discipline. However, because the software is so light on bureaucracy, it is easy to customize and to contribute to.

TeX is another bumblebee project. Like Emacs, it has thrived for decades without following currently fashionable software techniques. Knuth implies in this presentation that TeX would have been a dismal failure if it had used technologies that are trendy now.

Related posts:

Serious lessons from Knuth’s joke
Giving Emacs another try

{ 6 comments }

Command option patterns

by John on May 12, 2011

Here are some common patterns in Unix command options. This is a summary of the patterns Eric Raymond describes here.

Option Typical meaning
-a All, append
-b Buffer,block size, batch
-c Command, check
-d Debug, delete, directory
-D Define
-e Execute, edit
-f File, force
-h Headers, help
-i Initialize
-I Include
-k Keep, kill
-l List, long, load
-m Message
-n Number, not
-o Output
-p Port, protocol
-q Quiet
-r Recurse, reverse
-s Silent, subject
-t Tag
-u User
-v Verbose
-V Version
-w Width, warning
-x Enable debugging, extract
-y Yes
-z Enable compression

 

{ 5 comments }

Superficial convenience

by John on May 5, 2011

Here’s an interesting phrase:

superficial convenience at the expense of real freedom

This comes from the conclusion of the 1998 essay The Elements of Style: UNIX as Literature by Thomas Scoville. The author sums up his preference for UNIX culture by saying he prefers the “freedom and responsibility that UNIX allows” to the “superficial convenience” of Windows NT.

I’m not interested in arguing here the relative merits of Unix and Windows. I’m more interested in broader ideas that spin off from the quote above. When is a convenience superficial? How well does convenience versus freedom explain technological controversies?

I could see substituting “short-term convenience” for “superficial convenience” and substituting “long-term efficiency” for “real freedom.” But that may lose something. Thomas Scoville’s terms may be more nuanced than my substitutions.

Related posts:

Is helpful software really helpful?
Ford-Chevy arguments
Would you rather have a chauffeur or a Ferrari?

{ 12 comments }

Why Food for the Hungry runs Ubuntu

by John on February 8, 2011

Rick Richter is CIO of Food for the Hungry. In this interview Rick explains why his organization is moving all of its computers to Ubuntu.

Ethiopian farmer Ato Admasu

Ethiopian farmer Ato Admasu. Photo credit Food for the Hungry.

John: Tell me a little about Food for the Hungry and what you do there.

Rick: Food for the Hungry is a Christian relief and development organization. We go in to relief situations — maybe there has been a natural disaster or war — and provide life-sustaining needs: food, shelter, whatever the need may be.  For example, the recent earthquake in Haiti. But the other part of what we do is the sustained, long-term development on the community level. The idea is to work with leaders and churches to better take care of themselves rather than relying on outside organizations for support.

I’m the CIO. I’m in charge of the information and technology for the organization. We’re in 25 countries. I have staff all over the world, about 25 people. There are about 12 who work directly for global IT, mostly in Phoenix, and the rest in various countries.  There are also people who work directly for local offices, for example in Kenya, that coordinate with global IT. We’re responsible for about 900 computers.

John: You and I were talking the other day about your organization’s project to move all its computers over to Ubuntu.

Rick: We started an informal process to convert to Ubuntu two and a half years ago. It started when my son went to Bangladesh. He spent the summer there and converted some of their computers to Ubuntu. At first we didn’t have full management support for the process. They don’t really understand it and it scares them.

There were individual country directors interested in the project and I talked it up. There’s some independence in the organization to make those kind of decisions. Now, for the first time, we have full support of management for the conversion on a wide scale. I’m going to Cambodia next week. Right now they’re all running Windows but before I leave they’ll be running Ubuntu. In Asia we probably have about 80% of our computers on Ubuntu. We don’t have big offices in Asia. Our bigger offices are in Africa and they’re a little slower to adopt. Until now, a lot of it depended on whether the local country director was ready to change.

We found it was important for a number of reasons. One is security. Linux is not as vulnerable to viruses. We have so many places where entire computer systems have been totally crippled because of viruses. A lot of networks are very primitive, so the network is basically a thumb drive between offices in a country. A thumb drive is the best way to transmit viruses you can find.

We’ve also found in the last few years anti-virus software has become less and less effective. Three or four years ago, if you had up-to-date anti-virus software you wouldn’t get a virus. These days, you still get them. Some of our staff have other jobs within FH besides their IT responsibilities and may not have a lot of IT experience. As a result, staff often do not have the time to pro-actively manage IT.

Another issue is maintainability. Windows computers don’t run as well over time. With Ubuntu, when we come back to a computer two years later it’s in as good a shape as we left it.

Linux requires much less hardware to run than Windows. We have eight- or nine-year-old computers at a lot of our sites that will no longer run or barely run Windows.

John: So saving money on software licenses is a benefit, but not the main consideration.

Rick: Saving money on licenses is important, but it’s not the driving force. We’re a non-profit and we have a contract with Microsoft where we get pretty good prices.

Another reason for moving to Ubuntu is that in some countries it is very difficult to legally obtain licenses. Sometimes it’s next to impossible. You can’t buy legal Microsoft licenses in some places, or if you can, the price is outrageous. So many legalities and so many weird hoops you have to jump through.

As a Christian organization we need to set a good example and make sure all our licenses are legal. We want to be clear and up-front about our software. Ubuntu eliminates that problem.

John: What experience have you had retraining your IT people to support Linux?

Rick: We have IT professionals and we have people who are much less skilled. Most of the IT people who do the support have really bought into it. They’re excited about it and they’re pushing it. Those who do support in the field who have had less exposure, some of them have bought into it, some have not as much. It requires time. It requires dedication. It also required commitment from their management.

Related posts:

Robust, scalable, and the keyboard works
Free Ubuntu Linux book
Geek fatigue
New spin on The Cathedral and the Bazaar

{ 18 comments }

Mac has gotten harder to use, Windows easier

by John on February 5, 2011

CHI Conversations has posted a talk by Jef Raskin, designer of the first Macintosh, entitled Macintosh: Lessons Learned, Lessons Lost. The talk was recorded in 2004, about a year before Raskin’s death. Much of the talk is devoted to Macintosh history and how inaccurately it has been reported.

Toward the end of the talk, around 55 minutes in, Raskin compares Mac and Windows.

The Mac has gotten harder to use over the years. In fact, Windows has gotten easier. Now I can move back and forth, I can hardly notice the difference. Mac is just epsilon easier to use.

Raskin complains that software bloat has outpaced Moore’s Law, a contention that was verified here.

Jef Raskin. Photo by his son Aza.

Jef Raskin. Photo by his son Aza.

Related posts:

Moore’s Law and software bloat

Inside Steve Jobs’ Brain

{ 2 comments }

How long computer operations take

by John on January 12, 2011

The following table is from Peter Norvig’s essay Teach Yourself Programming in Ten Years. All times are in units of nanoseconds.

execute typical instruction 1
fetch from L1 cache memory 0.5
branch misprediction 5
fetch from L2 cache memory 7
Mutex lock/unlock 25
fetch from main memory 100
send 2K bytes over 1Gbps network 20,000
read 1MB sequentially from memory 250,000
fetch from new disk location (seek) 8,000,000
read 1MB sequentially from disk 20,000,000
send packet US to Europe and back 150,000,000

 

{ 4 comments }

The bipolar Internet

by John on December 28, 2010

In a recent Atlantic article, Jaron Lanier discusses the bipolar nature of the Internet.

The Internet …  was influenced in equal degrees by 1960s romanticism and cold war paranoia. It aligned the two poles of the bit to these two archetypal dramas.

Lanier argues that the Internet is polarizing. Just as bits are either on or off, the Internet encourages all-or-nothing options. With regard to privacy in particular, Lanier says that you can be totally anonymous or totally open, but it’s difficult to be anywhere in between.

Douglas Rushkoff makes a similar argument in Chapter 3 of his book Program or Be Programmed. Rushkoff argues that because computers ultimately work with 0’s and 1’s, the Internet inevitably forces people into yes-no decisions.

Lanier and Rushkoff have valid points, but I have a couple reservations.

First, I don’t see why the emergent properties of the Internet should be binary just because the underlying technology is binary. For example, I don’t imagine the Internet would be much different if computers were built on electronic components with three possible states rather than two. But I would concede that binary technology makes a good metaphor for discussing the binary choices one must often make on the Internet.

Second, I’d say that modern life forces us into discrete decisions, but this is much older than the Internet. Mass production requires limited options. If a cobbler is going to make a pair of shoes for me, he can measure my feet. But if I’m going to buy a pair of shoes from a store, I have to pick a size. Also, bureaucracies require information to fit into forms, though that was true of paper forms before the advent of electronic forms. Perhaps the Internet accentuates the need to make discrete decisions, though I’m not convinced.

Related posts:

The buck stops with the programmer
Underwhelmed with progress

{ 7 comments }

Big data is not enough

by John on December 15, 2010

Given enough data, correct answers jump out at you, right?

In some ways I think that scientists have misled themselves into thinking that if you collect enormous amounts of data you are bound to get the right answer. You are not bound to get the right answer unless you are enormously smart. You can narrow down your questions; but enormous data sets often consist of enormous numbers of small sets of data, none of which by themselves are enough to solve the thing you are interested in, and they fit together in some complicated way.

Bradley Efron, quoted in Significance. Emphasis added.

Related posts:

Predicting height from genes
The data may not contain the answer

{ 11 comments }