Beachhead - The Outer Banks
Many programs often are written that work great 99.999% of the time that people use them. Or, they work great for 95% of the people who want to use them. But, for those features or those people on the “Outer Banks”, there is just not enough attention paid nor documentation written to satisfy their needs.
In sea lore, the Outer Banks always have held a bit of mystery and adventure. Usually the farthest piece of land or fishing area, they are the ones hardest to achieve and offer the most challenges, but they often have the greatest payback. A definition I like from the Internet calls the Outer Banks “ever-changing”, “subject to the whims of the seas” and a “demanding environment”.
Sometimes it feels like software is that way.
A business proposition I am involved with is based on using a distribution that is different from the one I had been using for the past four years, so I decided to switch to the new (for me) distribution. I have a philosophy that mandates if you cannot use your own products, you should not coerce others to use them.
I had to do a bit of due diligence in the effort of migration. I ran the new distribution as a live CD on my notebook, and all of the devices were found and configured correctly. Unlike my other distribution, I did not have to go find the wireless network card driver, and various other aspects of it were set up more or less the way I wanted them. Initially, I was very impressed.
Also unlike my former distribution, this one had taken a philosophy of presenting a smaller number of applications to end users in its menus. The distribution's developers had done analysis and made decisions based on what they used and what they thought their customers might use. Understanding this philosophy, I made a decision to use their default mail interface, which was more integrated and Windows-like than the one I had been using for 15 years. I should say that nothing was wrong with the other program I had been using, but it was not as mainstream as the one I moved to, so therefore, it did not integrate in with the other applications as nicely. I also wanted to honor the above-mentioned philosophy of “as ye sow, so shall ye reap”.
For the most part, I like the new mail interface. It does things differently in comparison to my old one, but it does have various nice features. It is well organized, responsive and supports a lot of nested folders—something I needed due to my habit of keeping all of my e-mail history on my notebook so I can work off-line at any time. (Yes, I do backups frequently.)
Fortunately for me, the new e-mail interface had the capability of migrating my old e-mail storage into the new format. I had seen this in the e-mail installation documentation, and I was very happy that my e-mail could be “converted over” to the new format easily. Unfortunately, when the time came to do this crucial step, the conversion program did not work. This brings me to the theme of this month's article.
I have relatively simple needs when it comes to writing an e-mail message, and I am sure this new interface will satisfy most of those needs when I become used to it. But, the thing I really needed from the very beginning was for the import mechanism actually to work. And, not only did this mechanism not work, but it also did not work in a spectacular way—in a way that made me wonder if the programmers had tried it out even one time before listing it proudly as a “feature”. Or, perhaps they tried it out so long ago that over time (when it stopped working), they didn't notice it had stopped working.
Of course, importing old e-mail is typically something users (unless they are system administrators) do one time. After users have incorporated their e-mail, they go on and “just use it”. For programmers to do regression testing of incorporating old e-mail takes time and effort in setting up a test bed or a methodology for testing those older systems to make sure the system still works in the future. Or, they continually have to find people willing to test the incorporation of their e-mail into the new system. Or, they have to wait until it fails for someone, and then try to get it working.
Unfortunately, this last strategy often gives the software overall a bad name. People who should be using the software never use it, because the very first thing that should have worked did not work. Most people would not be as stubborn as I am in getting something to work. They just stop using it.
Fortunately, I am not “Mom & Pop”. I could look beyond the fact that the e-mail incorporation did not work properly and quickly formed a workaround for the problem. Now, I am using the new e-mail interface and will continue using it, and I will turn in a bug report about the incorporation problem.
I purposely have not mentioned either the old or the new interfaces that I am using in this article. The people who know me are aware of the e-mail interface I have been using for about 15 years. And, those people who see me using my computer will guess at the new one. But, enough projects and software exist that work 95% of the time to make this article applicable to many of them, and it is not fair to make examples of only these two.
The new interface still has some issues, and I miss some things from the old one. I intend on working with the developers of the integrated interface to incorporate the items that make sense in the “Mom & Pop” world and document how to do those things that do not make sense for the majority of the people, but that might be handy in the Outer Banks. I know I will see some of you in the “ever-changing and demanding environment”.
Jon “maddog” Hall is the Executive Director of Linux International (www.li.org), a nonprofit association of end users who wish to support and promote the Linux operating system. During his career in commercial computing, which started in 1969, Mr Hall has been a programmer, systems designer, systems administrator, product manager, technical marketing manager and educator. He has worked for such companies as Western Electric Corporation, Aetna Life and Casualty, Bell Laboratories, Digital Equipment Corporation, VA Linux Systems and SGI. He is now an independent consultant in Free and Open Source Software (FOSS) Business and Technical issues.
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader 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