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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide