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
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Profiles and RC Files
- Astronomy for KDE
- Maru OS Brings Debian to Your Phone
- Understanding Ceph and Its Place in the Market
- Snappy Moves to New Platforms
- Git 2.9 Released
- What's Our Next Fight?
- OpenSwitch Finds a New Home
- The Giant Zero, Part 0.x
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