xmotd: Writing Free Software
Lucy: “What happens if you practice the piano for 20 years and then end up not being rich and famous?”
Schroeder: “The joy is in the playing.”
xmotd is a message-of-the-day browser that runs under the X Window System. It was written to ease the burden of the local systems administrator in making day-to-day announcements of general interest to students and faculty using the computer network in the Electrical and Computer Engineering Department at Ryerson Polytechnic University, Toronto, Canada. This is a chronicle of my experiences developing a program that started as a trivial, single purpose tool and evolved into one with numerous features suggested by its users.
It was a late August afternoon in 1993 when Nick Colonello, the department's system administrator, and I were discussing the past school year and how it would have been nice to be able to let students logging in to the system know important information. With the following school year less than a month away, I boasted that I could write a simple message browser in about 10 minutes that could be run automatically by xdm (the X display manager) when students logged in. He agreed that it was a good idea and I proceeded to complete version 0.1 in under 30 minutes; it was called xbanner.(1) Visually, it consisted of a text widget where the message would be displayed, and a “dismiss” button, in the top-left corner of the window, used to close the window. For a brief moment, it looked supremely functional. But I was not satisfied—it looked utilitarian and ugly. (See Figure 1.)
In another half hour, version 0.2 was completed with an aesthetic re-fit consisting of a label widget that displayed a title, a separator widget (purely decorative) to separate the title from the text and another label widget to display a bitmap (a logo of our computer network). This was the version that was first installed on our system.
A few weeks later, Luis Lopes, the systems administrator in the Computer Science department dropped by for a visit and expressed interest in installing xbanner on his system. I was duly impressed that someone I knew would actually find something I wrote useful.
In March of the following year I read a post in comp.windows.x asking how a message of the day could be displayed when running X and xdm. Not knowing where it would be taking me, I innocently followed up saying that I had hacked together such a program and was willing to share it. Within a few hours I received two e-mail messages, and the next morning had another asking for a copy of xbanner. Now I was truly impressed.
Its popularity was never anticipated. It was as if no one had thought the world needed such a program. Indeed, a cursory investigation, prior to beginning work on xbanner, would have revealed the existence of a similar tool that, with minor modifications, could easily fit whatever new specifications were demanded. However, at this time the Web was in its infancy and archie was the de facto, parochially-minded, search tool of choice. Obscurity and ignorance condemned useful software to languish on ftp sites around the world.
I first learned of xmessage's existence when Vivek Khera e-mailed me a shell-script that used xmessage, in conjunction with other Unix programs, as a message-of-the-day browser. xmessage, written by Stephen Glidea of the eX Consortium (2), is a generic tool that can be used to browse a text file or display a message. It consists of a widget in which the text is displayed and an “okay” button in the bottom left corner of the window. (See Figure 2.)
Notice the remarkable aesthetic similarities between xmotd 0.1 and xmessage. In a market with several similar, feature-rich tools, aesthetics are often the deciding factor for a user. In a recent interview, the late Seymour Cray noted the importance of aesthetics: “I've enjoyed the aesthetics part of building computers because it's any extra little thing you add that is clearly your own personality being projected in the product.”
In addition to aesthetics, flexibility also plays a major role in selection. Experience has shown that users have a preference for application software that allows them to solve their problems, rather than overpowers by solving the programmer's problems. Usually, a programmer writes a program to solve a particular problem, then gives it away with the hope that others will benefit from it. Typical end-users do not find much use for this kind of software because it was written “by programmers, for programmers”. It performs a single job—nothing more, nothing less. Common shortcomings of this type of software include:
idiosyncratic interfaces, with little thought put into design (the principle of least astonishment does not apply)
poorly chosen default configurations giving the software an ugly appearance
a lack of customization (an aspect that emphasizes the idiosyncrasies even further because the user cannot replace the settings with something more suitable)
Software that allows infinite customization (3) endears itself to users dedicated enough to read the documentation because it gives them complete power—the same sense of creative power the developer felt when designing the software.
For example, xmotd's customizable bitmap was a relatively minor coding burden (an additional 10 lines of code to read in and validate a bitmap file) that affords the end-user a personal touch to what would otherwise be very bland software. The EE department's logo was originally hard-coded as the default image in the internal version of xmotd (now suitably renamed). When I uploaded xmotd to the eX Consortium's archive, I hard-coded in the X logo. One of the first requests I received was for the ability to change the logo. A less-than -optimal (and therefore temporary) solution I implemented was to amend the README with instructions on modifying the source code so a different bitmap could be compiled in. However, I found that people were very reluctant to modify code; they preferred something simpler. It then occurred to me to use the X logo as the default image and add a -bitmap option to allow the user to override the logo with one of his choice.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- I once had a better way I
2 hours 57 min ago
- Not only you I too assumed
3 hours 14 min ago
- another very interesting
5 hours 8 min ago
- Reply to comment | Linux Journal
7 hours 1 min ago
- Reply to comment | Linux Journal
13 hours 55 min ago
- Reply to comment | Linux Journal
14 hours 11 min ago
- Favorite (and easily brute-forced) pw's
16 hours 2 min ago
- Have you tried Boxen? It's a
21 hours 54 min ago
- seo services in india
1 day 2 hours ago
- For KDE install kio-mtp
1 day 2 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?