xmotd: Writing Free Software
“Every program in development at MIT expands until it can read mail.” --Unknown
Users invariably suggest enhancements, because the developer cannot anticipate all the uses for the software. A good rule of thumb is that for each person who asks for an enhancement, assume ten do not. My decision to implement the suggested enhancements was based on coding time versus how many users I thought would benefit from the feature. For example, I would guess that the -usedomainnames (4) option is rarely used other than at the site of the user who suggested it. I added it only because the overhead was one extra line of code in the function that generated the timestamp.
Another example: the -wakeup option initially specified an hourly period using an integer argument. When someone requested finer granularity (15 minutes sleep time) the argument was changed to a floating-point number with the fractional portion used to represent minutes.
The change was simple and didn't break backwards compatibility with -wakeup operation in the previous version. Users tend to be frustrated (to the point of not bothering to upgrade) when successive versions introduce incompatibilities with previous versions.
If a particular feature is implemented, it is wise to add an option to disable that feature because it is very likely that someone else may not like it. I added -timestamp to allow the default timestamp name “.xmotd” to be overridden after a user request. Put simply—provide lots of options.
There is a certain amount of personal gratification in writing software, but developers are happier when people actually use the software. Many features now incorporated into xmotd were suggested by users (systems administrators) at other sites. Unsolicited e-mail from users is a good indicator of popularity and is very inspiring to developers. If you enjoyed using some software (regardless of whether it's free) and know the author's address, I would urge you to write him a brief note. The euphoria from reading a note of thanks is ineffable. As a benchmark, I have received 107 e-mail messages regarding xmotd, versus 10 messages for xabacus and xsecure combined (a pair of X applications I had authored prior to xmotd).
The e-mail I have received about xmotd can be categorized as follows (ordered from least encouraging to most encouraging; too many from the beginning of the list may make you want to give up writing free software):
Your program didn't compile. Do you know why?
I didn't read the README file, how do I install your software?
I'm too lazy to read the documentation, how do I use this feature?
The documentation for using this feature is unclear.
Can you add this feature?
Your program doesn't work.
Thanks for writing this cool software.
The documentation for using this feature is unclear, here is a fix.
There's a bug in your cool software, and here's the patch.
Here's some code that implements a new feature and makes your software even cooler.
Wasteful duplication is common in the free software world. Given that Unix has been around for more than a quarter century, it is very likely that a solution to a problem has already been developed and you need to find it. On the other hand, commercial software has a colossal advertising budget and therefore mediocre software is often guaranteed commercial success. The ubiquitous and global nature of the Web is altering the balance. (When digital cash becomes a common transaction medium, it will become easy to charge for software.)
The Web allows software to have its own home page, providing inexpensive, world-wide advertising that precludes a marketing department. (5) New versions can be announced with varying amounts of fanfare. In some cases, major undertakings like the GIMP paint program or the Gnus newsreader for Emacs evolve around a mailing list subscribed to by a dedicated following interested in discussing and implementing enhancements. A catalog of free software would be a great benefit to both the developers and the users of free software. [The Linux Software Map on Sunsite is easily searched and functions as a catalog; however, it is not always up to date—Editor]
The rewards for commercial software are money and, often, fame. The rewards for writing famous, free software are recognition, a reputation and, at best, fanatic adoration. Many developers of free software share the sentiment illustrated in the opening epigraph. We write software because it's fun; it's more fun when people actually use it. Making it freely available guarantees that the greatest number of people will use it. Very often, free tools are the only alternative for those administrators who administer vast networks with minimal resources.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
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