Inside and outside ballparks and arenas, there are always people vending programs. Most of the computing we do is the result of other folks' programs and of programs we tweak or rewrite. That's fairly obvious.
However, as I've written before, writing good, useful programs that aren't excessively verbose and flabby isn't easy. Despite a number of really splendid books (Fred Brooks', Knuth's three volumes, Kernighan and Plauger, Kernighan and Pike, Bentley), looking at code shows a lot of untidy, repetitious slovenly work.
I admit to taking old code, snipping a few lines, typing something in, and voil<\#224>--a new driver. Fast and sloppy.
Looking at the 40 million lines of Office 2000, I realize just where the difference between open source and Windows lies—perhaps where the chasm is.
I've pointed out that if you go to the BSD manuals, you can count the number of contributors to the CSRG's (Computer Systems Research Group) efforts over 15 years. It comes to about 600 individuals. In 1998, I heard Bill Gates refer to 2000 programmers in Redmond, WA. There are most likely far more now.
Good programs are written by individuals or small groups. Brian Kernighan told me that AWK was the most difficult thing he'd ever worked on, “because there were three of us.”
Take a bunch of bright programmers, assign them to teams, assign a product to each team, and put them to work. The results will be slightly inferior to what the most feeble-minded member of each team would have produced.
I was surprised when I read The Pragmatic Programmer by Hunt and Thomas (Addison-Wesley, 2000). It's a nicely done volume which is intended to take the programmer from a “requirement” to a real “product”. I must admit I'd always thought of this kind of thing as somewhat comic, but it may be that Hunt and Thomas have good ideas. The book is certainly worth reading.
With all this in mind, I started thinking about the tools I use every day: shells, sed, awk, grep, sort, pipe, etc.
There are several decent books on shell programming, but none covers even most of the available shells (sh, bash, csh, ksh, tcsh and zsh come to mind, and I know there are many more). Robbins' AWK volume is excellent and there was a book on sed a few years ago, but I know of none on grep (nor egrep, which searches using regular expressions). In fact, I know of nothing on zsh. In these cases, we are actually driven to read the on-line man pages.
Just how we get to tools in everyday use is, I think, instructive. I still use troff, for example.
In 1967, L.P. Deutsch and B.W. Lampson took the TECO (an editor) that was running on the PDP-1 at MIT and implemented it on the SDS 940 as QED (= Quick Editor). Ken Thompson took QED and rewrote it for CTSS (compatible time sharing system) on the IBM 7094. He and Dennis Ritchie wrote a version of it for the GE 635 at Bell Labs. Thompson then took that version to create ed in August 1969.
That allowed for editing, but what about printing? J.E. Saltzer had written runoff for CTSS. Bob Morris moved it to the 635, and called it roff. Ritchie rewrote that as rf for the PDP-7, before there was UNIX (it was an evolutionary dead end). At the same time, the summer of 1969, Doug McIlroy rewrote roff in BCPL (Basic Combined Programming Language by Martin Richards, 1966), extending and simplifying it at the same time. It was McIlroy's version that first Joe Ossanna and, after his death, Brian Kernighan turned into the troff we still use.
(By the way, TECO is also the ancestor of Emacs.)
Nearly a decade later, Ted Dolotta created the memorandum (-mm) macros, with a lot of input from John Mashey. Thereafter, Eric Allman wrote the BSD -me macros. I still use them.
No teams. No large groups. Just a lot of good programmers trying to make code into something truly useful. And the open way does that.
Peter H. Salus , the author of A Quarter Century of UNIX and Casting the Net, is an LJ contributing editor. He can be reached at email@example.com.
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!
- Stunnel Security for Oracle
- SourceClear Open
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- 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