Eric Raymond's The Cathedral and the Bazaar (reviewed by Peter Salus in the January issue) is a fascinating book; I could hardly put it down. Some thirty years ago when I suggested at Boeing that software should be distributed in source-code form, the idea was hooted down and rejected out of hand. Eric's book documents the fundamental validity of that idea and records for us how it took root, and now provides the very direction of software development.
Much as I like Eric's book, it has side tones that could use a filter. A clue to the source is revealed, I think, on page 39 where Eric tells us that in 1992, his attempt to get some code merged into the Emacs Lisp library was rebuffed by the Free Software Foundation (FSF). So Eric has kind of a sour-grapes attitude toward the FSF, and I think it has caused him to miss-read (sic) the real relationship of Richard Stallman's cathedral approach to Linus Torvalds' bazaar approach to software development. Eric tells us Linus' approach is “much healthier” and “the very opposite of cathedral-building”. But Eric is comparing an apple to an orange.
Linus released his kernel sources into a world brimming with youngsters who were absolute UNIX experts. Some of them probably knew more about UNIX bedrock than Linus did. Linus lifted them over a formidable obstacle. Intel's 386 was equipped with precisely the hardware UNIX requires, but it was kludged up to be backward-compatible all the way to day one, so the hoops you jump through to get it started are just a bit hairy. These UNIX experts created quite a different situation for Linus from what Richard Stallman had when he developed his C compiler or the Emacs editor. The UNIX world was not brimming with text editor experts, let alone compiler experts. It doesn't work to share development with people who know little about what you are trying to accomplish.
When Eric comments that “FSF was not the only game in town”, I think he unnecessarily gives short shrift to the work Stallman has contributed to the free software movement. The reality is, without Stallman's compiler and make director, not to mention Emacs and gdb, there might not be any game in town.
Software tools do come first, just as Bob Canup pointed out in these pages a few issues back. Toolmakers, such as Dennis Ritchie and Richard Stallman, have been awarded special status in the programming community, and rightly so. The real relationship of the cathedral to the bazaar is not antagonistic at all, but complementary. As the work of Dennis Ritchie stands in relation to that of Ken Thompson, so the work of Richard Stallman stands in relation to the work of Linus Torvalds. As a poet long ago summarized, they are “...useless each, without the other”. We need both the cathedral and the bazaar.
—Jack Dennon firstname.lastname@example.org
I look forward to Linux Journal every month. It is one of the few publications I take time to read completely. Please keep up the good work.
I have been following the thread of KDE vs. GNOME, Red Hat vs. others, etc. for the last few months. My personal opinion is that many of the advocates of particular desktops or distributions are to some degree missing the point. I do have my personal preferences, but I believe what is really needed is standardized file formats. That is, if I generate a “document” in Applixware or StarOffice or whatever, it must be readable by the other office suites. Also, enough design has to go into the file formats so that I do not have to purchase an updated version of the software every two years. This rationale applies to spreadsheets, presentation software, etc. It would greatly enhance the portability of documents between the various office suites and/or distributions (even other operating systems). The actual desktop (KDE, GNOME, etc.) would then be the preference of the individual using the system.
I know this may have the short-term effect of limiting some creativity, but it would be a solution to one of the problems created by the other popular OS. Just my two cents worth.
—Dave Underland email@example.com
Loved the January cover! I watched the “Wallace and Gromit” special on the tube, and cracked up when I saw Feathers McGraw. A bit Tux-like, isn't he? I have also spied a very Tux-like fellow during reruns of “Reboot” on the Cartoon Network. This character pops up from time to time and casually strolls by. I wonder if the folks at Mainframe Entertainment are sending out a subliminal message?
—Patrick Murman firstname.lastname@example.org
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)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- 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
- SourceClear Open
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