Slashdot Mirror

"There is a kind of programming trap I occasionally fall into that is so damn irritating that it needs a name," writes Eric S. Raymond, in a new blog post: The task is easy to specify and apparently easy to write tests for. The code can be instrumented so that you can see exactly what is going on during every run. You think you have a complete grasp on the theory. It's the kind of thing you think you're normally good at, and ought to be able to polish off in 20 LOC and 45 minutes.

And yet, success eludes you for an insanely long time. Edge cases spring up out of nowhere to mug you. Every fix you try drags you further off into the weeds. You stare at dumps from the instrumentation until you're dizzy and numb, and no enlightenment occurs. Even as you are bashing your head against a wall of incomprehension, consciousness grows that when you find the solution, it will be damningly simple and you will feel utterly moronic, like you should have gotten there days ago.

Welcome to programmer hell. This is your shtoopid problem.... If you ever find yourself staring at your instrumentation results and thinking "It...can't...possibly...be...doing...that", welcome to shtoopidland. Here's your mallet, have fun pounding your own head. (Cue cartoon sound effects.)
Raymond's latest experience in shtoopidland came while working on a Python-translating tool, and left him analyzing why there's some programming conundrums that repel solutions. "You're not defeated by what you don't know so much as by what you think you do know," he concludes. So how do you escape?

"[I]nstrument everything. I mean EVERYTHING, especially the places where you think you are sure what is going on. Your assumptions are your enemy; printf-equivalents are your friend. If you track every state change in the your code down to a sufficient level of detail, you will eventually have that forehead-slapping moment of why didn't-I-see-this-sooner that is the terminal characteristic of a shtoopid problem."

Share your own stories in the comments. Are there any programmers on Slashdot who've experienced their own shtoopid problems?

An anonymous reader quotes Motherboard: Less than 24 hours after a software developer revoked access to Lerna, a popular open-source software management program, for any organization that contracted with U.S. immigrations and Customs Enforcement, access has been restored for any organization that wishes to use it and the developer has been removed from the project... The modified version specifically banned 16 organizations, including Microsoft, Palantir, Amazon, Northeastern University, Johns Hopkins University, Dell, Xerox, LinkedIn, and UPS... Although open-source developer Jamie Kyle acknowledged that it's "part of the deal" that anyone "can use open source for evil," he told me he couldn't stand to see the software he helped develop get used by companies contracting with ICE.

Kyle's modification of Lerna's license was originally assented to by other lead developers on the project, but the decision polarized the open-source community. Some applauded his principled stand against ICE's human rights violations, while others condemned his violation of the spirit of open-source software. Eric Raymond, the founder of the Open Source Initiative and one of the authors of the standard-bearing Open Source Definition, said Kyle's decision violated the fifth clause of the definition, which prohibits discrimination against people or groups. "Lerna has defected from the open-source community and should be shunned by anyone who values the health of that community," Raymond wrote in a blog post on his website.
The core contributor who eventually removed Kyle also apologized for Kyle's licensing change, calling it a "rash decision" (which was also "unenforceable.")

Eric Raymond had called the decision "destructive of one of the deep norms that keeps the open source community functional -- keeping politics separated from our work."

An anonymous reader writes: Last month Eric S. Raymond complained about his choices for a UPS (Uninterruptible Power Supply), adding that "This whole category begs to be disrupted by an open-hardware [and open-source] design that could be assembled cheaply in a makerspace from off-the-shelf components, an Arduino-class microcontroller, and a PROM...because it's possible, and otherwise the incentives on the vendors won't change." It could be designed to work with longer-lasting and more environmentally friendly batteries, using "EV-style intelligent battery-current sensors to enable accurate projection of battery performance" (along with a text-based alert system and a USB monitoring port).

Calling the response "astonishing," Raymond noted the emergence within a week of "the outlines of a coherent design," and in an update on GitLab reported that "The response on my blog and G+ was intense, almost overwhelming. It seems many UPS users are unhappy with what the vendors are pushing" -- and thus, the UPSide project was launched. "We welcome contributors: people with interest in UPSes who have expertise in battery technology, power-switching electronics, writing device-control firmware, relevant standards such as USB and the DMTF battery-management profile. We also welcome participation from established UPS and electronics vendors. We know that consumer electronics is a cutthroat low-margin business in which it's tough to support a real R&D team or make possibly-risky product bets. Help us, and then let us help you!"

There's already a Wiki with design documents -- plus a process document -- and Raymond says the project now even has a hardware lead with 30 years experience as a power and signals engineer, plus "a really sharp dev group. Half a dozen experts have shown up to help spec this thing, critique the design docs, and explain EE things to ignorant me." And he's already touting "industry participation! We have a friendly observer who's the lead software architect for one of the major UPS vendors." Earlier Raymond identified his role as "basically, product manager -- keeper of the requirements list and recruiter of talent" -- though he admits on his blog that he's already used a "cute hack" to create a state/action diagram for the system, "by writing a DSL to generate code in another DSL and provably correct equivalent C application logic."

He adds to readers of the blog that if that seems weird to you, "you must be new here."

An anonymous reader writes: Last month Eric S. Raymond complained about his choices for a UPS (Uninterruptible Power Supply), adding that "This whole category begs to be disrupted by an open-hardware [and open-source] design that could be assembled cheaply in a makerspace from off-the-shelf components, an Arduino-class microcontroller, and a PROM...because it's possible, and otherwise the incentives on the vendors won't change." It could be designed to work with longer-lasting and more environmentally friendly batteries, using "EV-style intelligent battery-current sensors to enable accurate projection of battery performance" (along with a text-based alert system and a USB monitoring port).

Calling the response "astonishing," Raymond noted the emergence within a week of "the outlines of a coherent design," and in an update on GitLab reported that "The response on my blog and G+ was intense, almost overwhelming. It seems many UPS users are unhappy with what the vendors are pushing" -- and thus, the UPSide project was launched. "We welcome contributors: people with interest in UPSes who have expertise in battery technology, power-switching electronics, writing device-control firmware, relevant standards such as USB and the DMTF battery-management profile. We also welcome participation from established UPS and electronics vendors. We know that consumer electronics is a cutthroat low-margin business in which it's tough to support a real R&D team or make possibly-risky product bets. Help us, and then let us help you!"

There's already a Wiki with design documents -- plus a process document -- and Raymond says the project now even has a hardware lead with 30 years experience as a power and signals engineer, plus "a really sharp dev group. Half a dozen experts have shown up to help spec this thing, critique the design docs, and explain EE things to ignorant me." And he's already touting "industry participation! We have a friendly observer who's the lead software architect for one of the major UPS vendors." Earlier Raymond identified his role as "basically, product manager -- keeper of the requirements list and recruiter of talent" -- though he admits on his blog that he's already used a "cute hack" to create a state/action diagram for the system, "by writing a DSL to generate code in another DSL and provably correct equivalent C application logic."

He adds to readers of the blog that if that seems weird to you, "you must be new here."

An anonymous reader writes: Last month Eric S. Raymond complained about his choices for a UPS (Uninterruptible Power Supply), adding that "This whole category begs to be disrupted by an open-hardware [and open-source] design that could be assembled cheaply in a makerspace from off-the-shelf components, an Arduino-class microcontroller, and a PROM...because it's possible, and otherwise the incentives on the vendors won't change." It could be designed to work with longer-lasting and more environmentally friendly batteries, using "EV-style intelligent battery-current sensors to enable accurate projection of battery performance" (along with a text-based alert system and a USB monitoring port).

Calling the response "astonishing," Raymond noted the emergence within a week of "the outlines of a coherent design," and in an update on GitLab reported that "The response on my blog and G+ was intense, almost overwhelming. It seems many UPS users are unhappy with what the vendors are pushing" -- and thus, the UPSide project was launched. "We welcome contributors: people with interest in UPSes who have expertise in battery technology, power-switching electronics, writing device-control firmware, relevant standards such as USB and the DMTF battery-management profile. We also welcome participation from established UPS and electronics vendors. We know that consumer electronics is a cutthroat low-margin business in which it's tough to support a real R&D team or make possibly-risky product bets. Help us, and then let us help you!"

There's already a Wiki with design documents -- plus a process document -- and Raymond says the project now even has a hardware lead with 30 years experience as a power and signals engineer, plus "a really sharp dev group. Half a dozen experts have shown up to help spec this thing, critique the design docs, and explain EE things to ignorant me." And he's already touting "industry participation! We have a friendly observer who's the lead software architect for one of the major UPS vendors." Earlier Raymond identified his role as "basically, product manager -- keeper of the requirements list and recruiter of talent" -- though he admits on his blog that he's already used a "cute hack" to create a state/action diagram for the system, "by writing a DSL to generate code in another DSL and provably correct equivalent C application logic."

He adds to readers of the blog that if that seems weird to you, "you must be new here."

An anonymous reader writes: Last month Eric S. Raymond complained about his choices for a UPS (Uninterruptible Power Supply), adding that "This whole category begs to be disrupted by an open-hardware [and open-source] design that could be assembled cheaply in a makerspace from off-the-shelf components, an Arduino-class microcontroller, and a PROM...because it's possible, and otherwise the incentives on the vendors won't change." It could be designed to work with longer-lasting and more environmentally friendly batteries, using "EV-style intelligent battery-current sensors to enable accurate projection of battery performance" (along with a text-based alert system and a USB monitoring port).

Calling the response "astonishing," Raymond noted the emergence within a week of "the outlines of a coherent design," and in an update on GitLab reported that "The response on my blog and G+ was intense, almost overwhelming. It seems many UPS users are unhappy with what the vendors are pushing" -- and thus, the UPSide project was launched. "We welcome contributors: people with interest in UPSes who have expertise in battery technology, power-switching electronics, writing device-control firmware, relevant standards such as USB and the DMTF battery-management profile. We also welcome participation from established UPS and electronics vendors. We know that consumer electronics is a cutthroat low-margin business in which it's tough to support a real R&D team or make possibly-risky product bets. Help us, and then let us help you!"

There's already a Wiki with design documents -- plus a process document -- and Raymond says the project now even has a hardware lead with 30 years experience as a power and signals engineer, plus "a really sharp dev group. Half a dozen experts have shown up to help spec this thing, critique the design docs, and explain EE things to ignorant me." And he's already touting "industry participation! We have a friendly observer who's the lead software architect for one of the major UPS vendors." Earlier Raymond identified his role as "basically, product manager -- keeper of the requirements list and recruiter of talent" -- though he admits on his blog that he's already used a "cute hack" to create a state/action diagram for the system, "by writing a DSL to generate code in another DSL and provably correct equivalent C application logic."

He adds to readers of the blog that if that seems weird to you, "you must be new here."

Open source guru Eric S. Raymond followed up his post on alternatives to C by explaining why he won't touch C++ any more, calling the story "a launch point for a disquisition on the economics of computer-language design, why some truly unfortunate choices got made and baked into our infrastructure, and how we're probably going to fix them." My problem with [C++] is that it piles complexity on complexity upon chrome upon gingerbread in an attempt to address problems that cannot actually be solved because the foundational abstractions are leaky. It's all very well to say "well, don't do that" about things like bare pointers, and for small-scale single-developer projects (like my eqn upgrade) it is realistic to expect the discipline can be enforced. Not so on projects with larger scale or multiple devs at varying skill levels (the case I normally deal with)... C is flawed, but it does have one immensely valuable property that C++ didn't keep -- if you can mentally model the hardware it's running on, you can easily see all the way down. If C++ had actually eliminated C's flaws (that is, been type-safe and memory-safe) giving away that transparency might be a trade worth making. As it is, nope.
He calls Java a better attempt at fixing C's leaky abstractions, but believes it "left a huge hole in the options for systems programming that wouldn't be properly addressed for another 15 years, until Rust and Go." He delves into a history of programming languages, touching on Lisp, Python, and programmer-centric languages (versus machine-centric languages), identifying one of the biggest differentiators as "the presence or absence of automatic memory management." Falling machine-resource costs led to the rise of scripting languages and Node.js, but Raymond still sees Rust and Go as a response to the increasing scale of projects.
Eventually we will have garbage collection techniques with low enough latency overhead to be usable in kernels and low-level firmware, and those will ship in language implementations. Those are the languages that will truly end C's long reign. There are broad hints in the working papers from the Go development group that they're headed in this direction... Sorry, Rustaceans -- you've got a plausible future in kernels and deep firmware, but too many strikes against you to beat Go over most of C's range. No garbage collection, plus Rust is a harder transition from C because of the borrow checker, plus the standardized part of the API is still seriously incomplete (where's my select(2), again?).

The only consolation you get, if it is one, is that the C++ fans are screwed worse than you are. At least Rust has a real prospect of dramatically lowering downstream defect rates relative to C anywhere it's not crowded out by Go; C++ doesn't have that.

An anonymous reader writes: After 35 years of programming in C, Eric S. Raymond believes that we're finally seeing viable alternatives to the language. "We went thirty years -- most of my time in the field -- without any plausible C successor, nor any real vision of what a post-C technology platform for systems programming might look like. Now we have two such visions...and there is another."

"I have a friend working on a language he calls 'Cx' which is C with minimal changes for type safety; the goal of his project is explicitly to produce a code lifter that, with minimal human assistance, can pull up legacy C codebases. I won't name him so he doesn't get stuck in a situation where he might be overpromising, but the approach looks sound to me and I'm trying to get him more funding. So, now I can see three plausible paths out of C. Two years ago I couldn't see any. I repeat: this is huge... Go, or Rust, or Cx -- any way you slice it, C's hold is slipping."
Raymond's essay also includes a fascinating look back at the history of programming languages after 1982, when the major complied languages (FORTRAN, Pascal, and COBOL) "were either confined to legacy code, retreated to single-platform fortresses, or simply ran on inertia under increasing pressure from C around the edges of their domains.

"Then it stayed that way for nearly thirty years."

An anonymous reader quotes OpenSource.com: A unique trait of open source is that it's never truly EOL (End of Life). The disc images mostly remain online, and their licenses don't expire, so going back and installing an old version of Linux in a virtual machine and getting a precise picture of what progress Linux has made over the years is relatively simple... Whether you're new to Linux, or whether you're such an old hand that most of these screenshots have been more biographical than historical, it's good to be able to look back at how one of the largest open source projects in the world has developed. More importantly, it's exciting to think of where Linux is headed and how we can all be a part of that, starting now, and for years to come.
The article looks at seven distros -- Slackware 1.01 (1993), Debian 0.91 (1994), Jurix/S.u.S.E. (1996), SUSE 5.1 (1998), Red Hat 6.0 (1999), Mandrake 8.0 (2001), and Fedora 1 (2003). Click through for some of the highlights.

• Slackware 1.01 (1993). "The best part about trying Slackware 1.01 is that there's a pre-made image in Qemu's 2014 series of free images, so you don't have to perform the install manually... In more ways than I'd expected, the system feels surprisingly modern. What's missing is any notion of package management. All installs and uninstalls are entirely manual, with no tracking."

• Debian 0.91 (1994). "To try Debian 0.91, I used the floppy disk images available on the Ibiblio digital archive... The install process is surprisingly smooth... The dpkg command exists, but it's an interactive menu-based system... Even so, you can sense the convenience factor in the design concept... I sincerely see why Debian made a splash."

• Jurix/S.u.S.E. (1996). "Because I wasn't specifically looking for the earliest instance, Jurix was the first Linux distribution I found that really 'felt' like it intended the user to use a GUI environment. XFree86 is installed by default, so if you didn't intend to use it, you had to opt out."

• SUSE 5.1 (1998). "I installed SUSE 5.1 from a InfoMagic CD-ROM purchased from a software store in Maryland in 1998. The install process was convoluted compared to those that came before... Included desktops were fvwm, fvwm2, and ctwm. I used fvwm, and it worked as expected. I even discovered tkDesk, a dock and file manager combo pack that is surprisingly similar to Ubuntu's Unity launcher bar."

• Red Hat 6.0 (1999). "The disc I used was purchased in June 1999. The installation was fully guided and remarkably fast... The desktop bundled with Red Hat 6 was, as it still is, GNOME, but the window manager was an early Enlightenment, which also provided the main sound daemon... Unlike later implementations of GNOME, this early version featured a panel at the bottom of the screen, with an application menu and launcher icons and virtual desktop control in a central location."

• Mandrake 8.0 (2001). "Mandrake 8.0 was released in 2001, so it would have been compared to, for instance, Apple OS 9.2 and Windows ME... I'd thought the Red Hat installation process had been nice, but Mandrake's was amazing. It was friendly, it gave the user a chance to test configurations before continuing, it was easy and fast, and it worked almost like magic..."

• Fedora 1 (2003). "The Fedora Core experience is largely indistinguishable from Red Hat 6 or 7. The GNOME desktop is polished, there are all the signature configuration helper applications, and the presentation is clean and professional... A red hat icon marks the applications menu, and the lower GNOME panel holds all the latest Linux application launchers, including the OpenOffice office suite and the Mozilla browser."

Eric S. Raymond recently documented one of the first public calls for free software, which happened immediately after AT&T's fateful decision commercialize Unix: [I]n October 1984 I was in a crowd of people watching a presentation by a woman from Bell Labs describing the then-new getopt(3) library, written by AT&T as a way to regularize the processing of command-line arguments in C programs... Everybody thought this was a fine idea, and several people asked questions probing whether AT&T was going to let anyone else use the getopt code they had written. These questions related to the general anxiety about Unix source code distributions drying up. Frustration mounted as the woman gave evasive answers which seemed to add up to "No, we refuse to commit to allowing general access to this code." Which seemed to confirm everyone's worst fears about what was going to happen to Unix source code access in general. At which point Henry Spencer stands up and says (not in these exact words) "I will write and share a conforming implementation." -- and got a cheer from the assembled.

If you're thinking "That's not a big deal, we do this sort of thing all the time," my actual point is that in October 1984 this was indeed a big deal. It took an actual imaginative leap for Henry Spencer to, in effect, say "Screw AT&T and its legalisms and evasions, if they're going to cut off source access we hackers are gonna do it for ourselves"... [H]e got an actual cheer exactly because he was pushing forward, exposing the possibility of doing not just small projects and demos and quirky little tools but at competing with the likes of AT&T itself at software production.
Raymond also remembers this as an important moment for him. "I was a young, unknown programmer then -- just 27, still figuring out what I wanted. I watched Henry make that promise. I heard the cheer, and felt the change in the air as culturally, we realized what the solution to AT&T fscking us over had to be. And I thought 'I want to be like that guy.'"

An anonymous reader writes: Open source guru Eric S. Raymond added something special to his GitHub page: an open source version of the world's first text adventure. "Colossal Cave Adventure" was first written in 1977, and Raymond remembers it as "the origin of many things; the text adventure game, the dungeon-crawling D&D (computer) game, the MOO, the roguelike genre. Computer gaming as we know it would not exist without ADVENT (as it was known in its original PDP-10 incarnation...because PDP-10 filenames were limited to six characters of uppercase)...

"Though there's a C port of the original 1977 game in the BSD game package, and the original FORTRAN sources could be found if you knew where to dig, Crowther & Woods's final version -- Adventure 2.5 from 1995 -- has never been packaged for modern systems and distributed under an open-source license. Until now, that is. With the approval of its authors, I bring you Open Adventure."
Calling it one of the great artifacts of hacker history, ESR writes about "what it means to be respectful of an important historical artifact when it happens to be software," ultimately concluding version control lets you preserve the original and continue improving it "as a living and functional artifact. We respect our history and the hackers of the past best by carrying on their work and their playfulness."

"Despite all the energy Crowther and Woods had to spend fighting ancient constraints, ADVENT was a tremendous imaginative leap; there had been nothing like it before, and no text adventure that followed it would be innovative to quite the same degree."

An anonymous reader writes: Open source guru Eric S. Raymond has announced public brainstorming on a "gallery of hacker archetypes to help motivate newbies" by defining several different psychologies commonly found among programmers. He's unveiled an initial list developed with a friend, along with some interesting commentary. (Algorithmicists often have poor social skills and "a tendency to fail by excessive cleverness. Never let them manage anyone!")

Raymond cautions that "No hacker is only one of these" -- though apparently most of the hackers he knows appear to be two of them, "an indication that we are, even if imperfectly, zeroing in on real traits." But the blog post ends by asking "What archetypes, if any, are we missing?"
It'll be interesting to see if Slashdot readers if they recognize themselves in any of the archetypes. But the blog post also answers the inevitable question. What archetype is Eric S. Raymond?

"Mostly Architect with a side of Algorithmicist and a touch of Jack-of-All-Trades."

Open source guru Eric Raymond turns 60 this year, prompting this question from an anonymous reader: Eric Raymond's newest writing project is "Things Every Hacker Once Knew," inspired by the day he learned that not every programmer today's knows the bit structure of ASCII. "I didn't write it as a nostalgia trip -- I don't miss underpowered computers, primitive tools, and tiny low-resolution displays... In any kind of craft or profession, I think knowing the way things used to be done, and the issues those who came before you struggled with, is quite properly a source of pride and wisdom. It gives you a useful kind of perspective on today's challenges."

He writes later that it's to "assist retrospective understanding by younger hackers so they can make sense of the fossils and survivals still embedded in current technology." It's focusing on ASCII and "related technologies" like hardware terminals, modems and RS-232. ("This is lore that was at one time near-universal and is no longer.") Sections include "UUCP and BBSes, the forgotten pre-Internets" and "The strange afterlife of the Hayes smartmodem" (which points out some AT commands survived to this day in smartphones). He requests any would-be contributors to remember that "I'm trying to describe common knowledge at the time." This got my thinking -- what are some that every programmer once knew that have since been forgotten by newer generations of programmers?
Eric Raymond is still hard at work today on the NTPsec project -- a secure, hardened, and improved implementation of Network Time Protocol -- and he promises donations to his Patreon page will help fund it. But what things do you remember that were commonplace knowledge "back in the day" that have now become largely forgotten? Leave your best answers in the comments. What are some things that every hacker once knew?

Open source guru Eric Raymond turns 60 this year, prompting this question from an anonymous reader: Eric Raymond's newest writing project is "Things Every Hacker Once Knew," inspired by the day he learned that not every programmer today's knows the bit structure of ASCII. "I didn't write it as a nostalgia trip -- I don't miss underpowered computers, primitive tools, and tiny low-resolution displays... In any kind of craft or profession, I think knowing the way things used to be done, and the issues those who came before you struggled with, is quite properly a source of pride and wisdom. It gives you a useful kind of perspective on today's challenges."

He writes later that it's to "assist retrospective understanding by younger hackers so they can make sense of the fossils and survivals still embedded in current technology." It's focusing on ASCII and "related technologies" like hardware terminals, modems and RS-232. ("This is lore that was at one time near-universal and is no longer.") Sections include "UUCP and BBSes, the forgotten pre-Internets" and "The strange afterlife of the Hayes smartmodem" (which points out some AT commands survived to this day in smartphones). He requests any would-be contributors to remember that "I'm trying to describe common knowledge at the time." This got my thinking -- what are some that every programmer once knew that have since been forgotten by newer generations of programmers?
Eric Raymond is still hard at work today on the NTPsec project -- a secure, hardened, and improved implementation of Network Time Protocol -- and he promises donations to his Patreon page will help fund it. But what things do you remember that were commonplace knowledge "back in the day" that have now become largely forgotten? Leave your best answers in the comments. What are some things that every hacker once knew?

This conversation was generated by a post Eric S. Raymond published on his "Armed and Dangerous" blog that said, "...if you are any kind of open-source leader or senior figure who is male, do not be alone with any female, ever, at a technical conference. Try to avoid even being alone, ever, because there is a chance that a 'women in tech' advocacy group is going to try to collect your scalp." Eric later wrote a post about how Social Justice Warriors may be more of a problem than the problems they complain about.

Whoa! Predatory women in tech trying to entrap people like (and including) Linus Torvalds the way an old-time private eye got the goods on an errant husband as part of a divorce case? Scary! And worrying about thoughtcrime, too? Oh my! But Liz Bennett is an actual software engineer who works at Loggly in San Francisco. She writes for her company's blog when she's not writing Java code, has a (not very active) GitHub account, and plays bassoon. And her attitude is similar to the one espoused by ESR in the second post (above): write great code -- and if you do, they (for any value of they) have no right to be negative about you, period. And, she says, before you take a job you should be sure the company is a good "fit" for you and doesn't harbor people who will work to bring you down -- which is great advice for anyone, in any field of endeavor.

This conversation was generated by a post Eric S. Raymond published on his "Armed and Dangerous" blog that said, "...if you are any kind of open-source leader or senior figure who is male, do not be alone with any female, ever, at a technical conference. Try to avoid even being alone, ever, because there is a chance that a 'women in tech' advocacy group is going to try to collect your scalp." Eric later wrote a post about how Social Justice Warriors may be more of a problem than the problems they complain about.

Whoa! Predatory women in tech trying to entrap people like (and including) Linus Torvalds the way an old-time private eye got the goods on an errant husband as part of a divorce case? Scary! And worrying about thoughtcrime, too? Oh my! But Liz Bennett is an actual software engineer who works at Loggly in San Francisco. She writes for her company's blog when she's not writing Java code, has a (not very active) GitHub account, and plays bassoon. And her attitude is similar to the one espoused by ESR in the second post (above): write great code -- and if you do, they (for any value of they) have no right to be negative about you, period. And, she says, before you take a job you should be sure the company is a good "fit" for you and doesn't harbor people who will work to bring you down -- which is great advice for anyone, in any field of endeavor.

An anonymous reader writes: We've discussed some proposed FCC rules that could restrict modification of wireless routers in such a way that open source firmware would become banned. Eric S. Raymond has published the comment he sent to the FCC about this. He argues, "The present state of router and wireless-access-point firmware is nothing short of a disaster with grave national-security implications. ... The effect of locking down router and WiFi firmware as these rules contemplate would be to lock irreparably in place the bugs and security vulnerabilities we now have. To those like myself who know or can guess the true extent of those vulnerabilities, this is a terrifying possibility. I believe there is only one way to avoid a debacle: mandated device upgradeability and mandated open-source licensing for device firmware so that the security and reliability problems can be swarmed over by all the volunteer hands we can recruit. This is an approach proven to work by the Internet ubiquity and high reliability of the Linux operating system."

mtaht writes ESR is collecting specifications and donations towards getting a new high end machine to be used for massive CVS and SVN repository conversions, after encountering problems with converting the whole of netbsd over to git. What he's doing now sort of reminds me of holding a bake sale to build a bomber, but he's well on his way towards Xeon class or higher for the work. What else can be done to speed up adoption of git and preserve all the computer history kept in source code repositories? ESR says he'll match funds toward the purchase of the needed hardware, so if you want to help drive him into bankruptcy, now's your chance.

mtaht writes ESR is collecting specifications and donations towards getting a new high end machine to be used for massive CVS and SVN repository conversions, after encountering problems with converting the whole of netbsd over to git. What he's doing now sort of reminds me of holding a bake sale to build a bomber, but he's well on his way towards Xeon class or higher for the work. What else can be done to speed up adoption of git and preserve all the computer history kept in source code repositories? ESR says he'll match funds toward the purchase of the needed hardware, so if you want to help drive him into bankruptcy, now's your chance.

mtaht writes ESR is collecting specifications and donations towards getting a new high end machine to be used for massive CVS and SVN repository conversions, after encountering problems with converting the whole of netbsd over to git. What he's doing now sort of reminds me of holding a bake sale to build a bomber, but he's well on his way towards Xeon class or higher for the work. What else can be done to speed up adoption of git and preserve all the computer history kept in source code repositories? ESR says he'll match funds toward the purchase of the needed hardware, so if you want to help drive him into bankruptcy, now's your chance.

alphadogg writes with news on what Open-Xchange has been doing with the OpenOffice.org developers they hired. From the article: "Collaboration software vendor Open-Xchange plans to launch an open-source, browser-based productivity suite called OX Documents. The first application for the suite is OX Text, an in-browser word processing tool with editing capabilities for Microsoft Word .docx files and OpenOffice.org and LibreOffice .odt files, the Nuremberg, Germany, company announced this week. OX Text doesn't mess up the formatting of documents loaded into the application, said Rafael Laguna, CEO of Open-Xchange. XML-based documents can be read, edited and saved back to their original format at a level of quality and fidelity previously unavailable with browser-based text editors, according to the company." The other claim to fame is that it supports collaborative editing similar to Google Docs. Unfortunately for anyone hoping to have a Free/Open replacement for Google Docs, it's not actually fully open source: the backend is (Apache/GPL dual licensed), but the front-end code is Creative Commons BY-SA-NC, which is unequivocally non-free and notoriously difficult to define. "[Open Xchange CEO Rafael Laguna] told The H that his interpretation of Non-Commercial in the licensing was such that companies could use the software in-house, but not sell it as a service to others. Companies that want support will have to purchase the software from Open Xchange."

A while ago you had the chance to ask founder of the GNU Project, and free software advocate, Richard Stallman, about GNU/Linux, free software, and anything else. You can read his answers to a wide range of questions below. As usual, RMS didn't pull any punches. Capitalism and You
by eldavojohn

Your monkish lifestyle would leave most people who work in software screaming for a Lear Jet and you have stated "I've always lived cheaply ... like a student, basically. And I like that, because it means that money is not telling me what to do." Growing up in the United States, I have been served the koolaid of Capitalism several times and I have been taught that the inherent competition and struggle for money in all aspects of our lives make us the greatest country ever. I've read a lot of your comments on intellectual property reform and I can't help but feel that it just isn't compatible with capitalism. Have you ever had problems rectifying your stance on intellectual property with capitalism? Do you see any problems at all with no copyright or patent laws inside a capitalistic society?

RMS: First, I need to correct an apparent misunderstanding. I do not have a "stance on intellectual property", because that would mean using the term "intellectual property" in my thinking. I take pains never to do that, because that term is an obstacle to clear thinking. Every time it is used, it misrepresents the legal reality and spreads confusion.

I judge copyright law by its practical requirements and their practical effects. I judge patent law by its practical requirements and their practical effects -- totally different requirements and totally different effects. These two laws are different on every practical point; all they have in common is a very abstract idea which is of no practical significance.

I want to encourage clear thinking about copyright law. Separately, I want to encourage clear thinking about patent law. The first step in clear thinking about these laws is not to lump them together. In particular, never use the term "intellectual property", since it lumps them together.

I must not respond directly to a question that treats copyright law and patent law as a single issue. If I did, I'd be lumping them together and spreading the confusion I want to clear up.

However, I can split it into two separate questions.

First, copyright. Copyright is a legal restriction on certain kinds of use of works of authorship. The US has always had some sort of copyright law, but it has changed tremendously. The US has always practiced capitalism, but many sorts of works were, at some time in US history, not covered by copyright. Thus, we know it is possible to have capitalism without copyright.

However, I don't advocate simple elimination of copyright as a solution.

Works that are designed for use doing practical jobs must be free; however, simply eliminating copyright on those works would not have this result. In software, it would make things worse, because copyleft is based on copyright. Without copyright, programs could still be made nonfree using EULAs, tivoization, and nonrelease of source code, but we would no longer be able to prevent this using copyleft.

If we wanted to legislate to make all these works-for-use free, we would have to go further than just eliminating copyright on them. In an ideal world, we would do this, but I don't propose doing it now.

As for works of opinion and art, I don't think they must be free. I advocate some reforms of copyright for these works but I see no reason to abolish it.

Patent law is a totally different issue. A patent is an artificial monopoly on using a specified idea. There have been successful capitalist countries that didn't have a patent system. My expertise is in computing, so I campaign to eliminate patents from computing, where I know they are harmful. However, Boldrin and Levine present good arguments that patents do mostly harm in every field and that it would be better to eliminate patents entirely.

With any or all of these changes, we would still have capitalism; only some details would be different.

I feel like you have this admirable and altruistic quality where money isn't the ultimate driving force and when you speak to people who base their entire lives around money, there's a fundamental disconnect that is overlooked.

RMS: Arguments are always based on values. The free software movement is based on values of freedom and community -- that is where it differs from open source. People who don't share those values will simply not get it, no matter what I might say. Since that's inevitable, I don't worry about it. I do my best, and I persuade some, which is better than giving up and persuading none.

Re:Do you like being worshiped ?
by capt.Hij

This brings up a good point. Let me rephrase the question. Mr Stallman, you are regarded as a founding father of the free software movement, and your opinion on free software carries a lot of weight. Because of this you are put under a harsh spot light, and every little thing you do is magnified. For example, your comments about Steve Jobs immediately after his death were broadcast quite widely. To some people the timing showed a lack of taste and were seen as disrespectful.

RMS: Those people evidently were more concerned with forms of politeness that with substantive good and evil. Someone told me I should not criticize Jobs because he could not defend himself -- while thousands were lionizing him with the indirect support of Apple's PR machine. Compared to that, I was David against Goliath.

Because of your status in the free software movement your statement was used by some to smear the larger community. How do you feel about this kind of attention?

RMS: I stand by what I said about Jobs. Apple is your enemy, and if you don't recognize this and fight, you're being a chump.

If someone tried to spin my statement as something to be ashamed of, please fight back by arguing with his spin.

Have you given it much thought, and what kind of insight can you share about the situation you are in when your private and public mannerisms are misconstrued to be part of a larger group's views and outlooks?

RMS: I hope that a lot of the community shares my views of Jobs and Apple. I ask them to stand up and be counted.

Apple's favorable public image, including public admiration of Jobs for side issues, is a crucial asset in its war against our freedom. To tarnish its image, we need to speak loud and clear about Apple's wrongs. When Steve Jobs is praised for the elegant styling of the jails he designed, we must respond that it is wrong to put users in jail. Speak up and spread the word!

Role of the FSF
by ssam

It seems to me that in the early days of the FSF the main role was writing software. A huge chunk of that code is what makes up modern day free operating systems. A lot of it is class leading software (bash, gcc, emacs, etc). In the past few years it seems that the FSF is far more involved in campaigning than coding. Is this an accurate view of the situation? Is this intentional, and if so why? Should the FSF be trying to create a class leading web browser, for example.

RMS: In the first years of developing the GNU system, before Linux completed the system, not many people worked on free software. A few staff hired by the FSF made a big difference to our progress.

Once GNU/Linux caught on, lots more people got involved, so that the few people the FSF could hire were inevitably a tiny fraction of what the community did. Meanwhile, our other jobs became bigger and more important. For instance, once the DMCA made it illegal to release free software to handle common media formats, just writing free software was no longer enough, so we launched the DefectiveByDesign.org campaign. A year ago we launched our campaign against Restricted Boot, which is the way Microsoft perverts Secure Boot into an anti-security feature.

"Success" is not our goal; we're not here to win a race, we are here to win freedom. I didn't write GCC with the idea of making a "better" C compiler. I wrote it so there would be a freedom-respecting C compiler, and while I was at it, I did the best job I knew how. We didn't develop GNU to have a "better" operating system than Unix; we developed it so we could have a freedom-respecting operating system. It's the same today.

Thus, if we could raise money to hire a few software developers, we would spend it on projects that are more than technical improvements. For instance, it would make no sense to try to develop a web browser that is "better" in a merely practical sense. There is no reason to think we could outdo the Firefox developers in what they are good at, and it would be wasteful duplication to try.

Instead we are trying to do something that Firefox does not aim to do: protect the user's privacy from surveillance by web sites, and protect the user's freedom from nonfree Javascript code. A volunteer is working on our variant of Firefox, called IceCat, with changes for these purposes. We don't have funds for this, so would you like volunteer to help?

GNU visibility and factioning
by Digana

GNU is supposed to be a free operating system as well as a group of people working towards building this OS. To a casual observer, however, GNU does not appear very active.

RMS: I've decided to post new package releases in a more visible place in gnu.org.

Development of GNU is done by volunteers, so the level of activity is up to you. If you wish GNU were more active, join in the work on some GNU package that interests you. For instance, it would be useful to have more developers for LibreJS, which detects and blocks nonfree Javascript, and for IceCat.

Some of the most prominent and supposedly GNU packages, such as Gimp, Gnome, GTK+, and R are mostly GNU in name only. The hackers working on these projects have very little interaction with other hackers working on GNU projects and they very frequently espouse views contrary to GNU's philosophical aims. Thus to an outside observer, GNU does not appear to be a cohesive group of people working towards a common goal.

RMS: The GNU project is not as cohesive as I wish it were. To some extent, this is a consequence of an approach that was necessary. The only way to develop something as large as the GNU system through the work mostly of volunteers was to divide it into projects that could be implemented mostly independently by different people. The design of Unix lent itself to this. The fact that the GNU system incorporated programs such as X and TeX, that were developed by other people or groups that regarded the GNU Project as just a user, pushed in the same direction.

There is always a centrifugal tendency when many groups work mostly independently. It is often hard to persuade the developers of one component to do what improves the system as a whole rather than what will make their own component more useful and successful.

By 1990, when we started the HURD kernel, I expected that in a couple of years it would be working and we would integrate the GNU system. However, the HURD didn't work at all until 1996, and in the mean time the community began using GNU with Linux as the kernel. By the time we started using it that way, others had integrated the GNU/Linux combination, making various GNU/Linux distros.

The initial goal of GNU, to have a free operating system, has been achieved; the initial sharp focus on completing a free Unix-like system is no longer applicable. This doesn't mean our work is over; most GNU/Linux distros today contain nonfree software, and there are more things that we expect a system to do. We still need people to seek out and do the development jobs that need doing in order to win freedom for the users of computing.

My first step to make the GNU Project more cohesive was in 1999. In the 1980s and 90s, when I appointed someone as the maintainer for a GNU package, I took for granted that he would understand that his job was to manage a part of a larger project, and what that implied. In 1999 I realized this could not be taken for granted, so I began explaining this relationship to new maintainers and asking new maintainers to agree to it. However, the relationship with a few packages had already become distant.

Many GNU mailing lists being private further the public perception that GNU is not even actively producing software anymore.

RMS: Our main packages have public discussion lists, but that's a choice for the package maintainer to make. Feel free to suggest changes to the maintainer.

What can be done to remedy this situation? How can we strengthen GNU, make it reach out again to the people it's supposed to be freeing?

RMS: For the most part, this is up to you. When you start working on a new free program, do you propose making it a GNU package? Would you like it to be part of a coherent GNU Project? If so, please write to me.

How to reverse the aggregation problem?
by concealment

A problem with software and operating systems is what I call the "aggregation problem," which is that what we have now is an aggregate of past solutions to problems that may no longer exist. The stuff piles up, increasing complexity and decreasing the uniformity and effectiveness of the interface. At what point do software projects call for a top-down redesign? How can free software do this where industry cannot?

RMS: I don't have any solution to offer for this particular problem, other than the slow methods we are using now. Partly that's because I don't think this is the most important issue -- I think our freedom is more important than technical improvement.

However, this is not the only area in which more uniformity is desirable. Around 1990, I designed a protocol for configuring and building packages from source: you type `./configure; make install'. It would be nice if all free software packages supported this uniform interface, but they don't.

To help implement that uniformity, a GNU volunteer recently made it very easy to use Autoconf in Python packages, so that they can build and install using our uniform commands. If you maintain a program in Python, how about adding this support? Every user that isn't a Python programmer will be glad he can install your program without learning a special Python build method.

What project is using the wrong license?
by gQuigs

What free software project is using a license that doesn't actually match with it's mission - or hinders free software in other ways? In other words, if you could *magically* switch the license of one project - which would you choose and why? Examples: Move Mesa to GPLv3, Move Linux from GPLv2 to v3, Make android GPLv3, GCC - from GPLv3 to Apache.

RMS: If I could magically change one program to GPLv3, it would be Linux. One of the improvements of GPLv3 is that it blocks tivoization, and Linux is very frequently tivoized. (Many Android devices contain a tivoized copy of Linux.)

While we're talking about magic, I'd change the license of LLVM also.

Another program that is important to convert is LibreCAD. This is more than a fantasy: the developers of LibreCAD are working on replacing the old GPLv2-only code that they included, so as to switch to GPLv3-or-later. Would you like to help?

What do you think of non-free, non-software works?
by Shlomi Fish

Dear Dr. Stallman, In this Slashdot feature"Stallman is quoted here saying that game engines should be free, but approves of the notion that graphics, music, and stories could all be separate and treated differently (i.e., "Non-Free.")." However, this feature does not give a citation from you for that. To add to the confusion in a post to the Creative Commons Community mailing list, Rob Myers said:

"RMS's views on culture are coherent and consistent with his views on software. But he's treating game assets as a matter of functionality (software) rather than speech (culture). There is an issue with the latter not being free.."

So I'm a little confused. Do you approve of people using non-free licenses for cultural works, including the CC-by-nc, CC-by-nc-sa, CC-by-nd, and CC-by-nc-nd licenses? If so, when?

This is especially important given the fact that in the process for formulating the latest version of the Creative Commons licenses (4.0), there has been some requests to deprecate the non-commercial (nc) and/or no-derivatives (nd) options (which I doubt will happen, but is nonetheless some thing some people feel strongly about).

RMS: After some 12 years of stating my position in all my speeches on Copyright vs Community, and publishing transcripts, I'd expect interested people to have found it. But here it is.

Those works that are made for doing practical jobs must be free. This includes software, educational works, reference works, text fonts, recipes, and 3d-printer models for objects for practical use, as well as some other things.

Works of testimony and opinion, and artistic works, don't have to be free as in the four freedoms, but their users should have more freedom than now. I think people should be free to share them (noncommercial redistribution of exact copies), and to remix them. Putting DRM or EULAs on them should be banned too. I think all the CC licenses do these things, more or less, and I use CC-ND for my statements of my views, including this one.

Two of the nonfree CC licenses, CC-NC and CC-NC-SA, have a peculiar problem: they lead to making works which are orphan before they are born.

I call this a "peculiar problem" because I don't think these licenses are bad in principle. The problem is purely a matter of practical consequences, and it seems they should be avoidable, yet I can't see a way to avoid them. I hope one is found; in the mean time, I urge not using these two licenses.

Favorite hack
by vlm

Give me your best hack. Specifically something YOU did personally not hire / grad student. Hardware, software only (yes yes the GPL is cool but I'm looking for code or schematic or at least a description of something made out of source or solder) I can't put words in your mouth but the ideal answer would be something like "I'm particularly proud of the O(n) memory garbage collection routine in emacs implemented around '89 and how it worked was very roughly ..." or "I really like my homemade fully automatic automotive relay based routing system for my OH scale model railroad sorting yard" or "I built my own legal limit ham radio amplifier" almost certainly a different topic of course, but something of this form of answer.

RMS: I can't remember all the hacks that I was proud of, so I can't pick the best. But here's something I remember fondly. The last piece of Gosmacs code that I replaced was the serial terminal scrolling optimizer, a few pages of Gosling's code which was proceeded by a comment with a skull and crossbones, meaning that it was so hard to understand that it was poison. I had to replace it, but worried that the job would be hard. I found a simpler algorithm and got it to work in a few hours, producing code that was shorter, faster, clearer, and more extensible. Then I made it use the terminal commands to insert or delete multiple lines as a single operation, which made screen updating far more efficient.

Why FDR and Churchill?
by eldavojohn

During a Q&A Session a while back you were asked about people and movements near and dear to your heart and you said "I admire Franklin D. Roosevelt and Winston Churchill, even though I criticize some of the things that they did." I love World War II history and I also find myself in a love-hate situation with Churchill. Could you go into further detail about what specifics lead you to single out these two over leaders like Lincoln, Jefferson, Benjamin Franklin or even historical figures who have enabled information itself like Turing, Shannon, etc?

RMS: I like math, and I respect good mathematicians, but I don't admire them as heroes. The people I admire are those who fight for freedom.

Why did I mention Roosevelt and Churchill in particular? I didn't make a list of all the leaders I admire and then choose the ones I admire most. That would be a big job, and my memory does not lend itself to that, so I didn't try. I mentioned the people that came to mind.

I was thinking of leaders that fought against evil tyranny. Of the five leaders you mentioned, Roosevelt and Churchill had the hardest fight against the greatest evil. King George trampled the colonists' rights, and the Confederacy fought for slavery, but Hitler's genocidal empire was much worse.

If I were judging peacetime political leadership, I would not choose Churchill; perhaps Jefferson.

Stolen bag / laptop in Argentina
by Cigarra

What ever happened with the stolen bag and laptop? Did you get something back? Did you LOSE data (that is, was something not backed up)? Are you mad with the organizers / country that hosted the event?

RMS: My friends never found any sign of what was stolen. I lost some files, those which were outside the directories that I regularly backed up, but nothing really important.

I don't blame the speech organizers or Argentina in general for this theft. The reason I will never go to Argentina again has nothing to do with the theft. I announced it before I arrived in Argentina: I object to the requirement for visitors to give their fingerprints. I refuse to go to any country which has that policy, and I hope you too will refuse to go to any country that would demand your fingerprints.

Revolution OS ...
by i.r.id10t

Interviews with you comprised a big percentage of the documentary Revolution OS. If it were to be remade today, and the financial aspects ignored, what do you think would be different? If you were producing such a documentary today, what would you focus on?

RMS: I didn't make that movie, so how to make it was not my decision, and how to make one today would not be my decision. But I see some things that would have to be different.

Much attention was paid to business leaders of the open source bubble, which popped after the interviews. The movie ended saying how some companies' stock had gone down. If the movie were made today, those people and their commercial claims would probably not be in it. Also, I would not be found at a "Linux" event; shortly after that time, I concluded it was self-defeating to legitimize events that call the GNU system "Linux".

Other advocates
by SirGarlon

Who, other than yourself and the FSF, do you consider to be effective advocates for software freedom? Please name individuals if you can.

RMS: Eben Moglen and SFLC, Bradley Kuhn and the Conservancy, Frederic Couchet and APRIL, Via Libre, Alexandre Oliva, Octavio Rossell, Quiliro Ordoñez, are the ones that occur to me. I have probably forgotten many.

Open Source and Ethics in research?
by tsquar3d

RMS, I am a PhD student in computing and I have run up against an interesting problem. I consider FOSS to be at the core of my personal philosophy.

RMS: I have to point out that there is no "FOSS" philosophy. The term "FOSS" is a way of referring to two different philosophies: free software is one, and open source is the other.

When you want to refer to both philosophies, I recommend "FLOSS" rather than "FOSS". "FLOSS", or "Free/Libre and Open Source Software", gives the two equal visibility, whereas with "FOSS", "Free and Open Source Software", "Open Source" is more prominent. But you can't possibly agree with both of these philosophies, because they disagree at the deepest level. Your views might be one, or the other, or a mixture, or something else, but it can't be both of them at once.

See here for more explanation of the difference between free software and open source. To me it is not just a pragmatic issue, but an ethical one.

RMS: It sounds like your philosophy may be closer to the free software movement. We consider this an ethical issue, whereas the usual open source philosophy presents it as a practical issue alone.

Therefore, in my research, I use all FOSS software. Now, the problem arises when trying to justify my use of FOSS to colleagues and supervisors.

RMS: Why do you need to try to justify your _own_ use of free software? I'd expect you to decide, and follow your own decision, with no need to justify it to anyone else. Is there something I have misunderstood?

The time you need to argue is to convince other teachers and researchers to move to free software.

I have tried to make the case that it is an ethical issue, and have argued the merits of freedom and academia, however, I invariably am told "that's not an academic argument".

RMS: I suggest you respond "I'm a citizen first, and an academic second, so I care about ethical arguments as well as academic arguments."

This is incredibly frustrating and annoying to me as, in academic research, we are constantly being restricted by "research ethics" (e.g. the ethical treatment of subjects, plagiarism, etc.) and I am more than willing to bet that if a researcher objected to a methodology based on "religious principles" they would be excused.

RMS: I don't understand -- "excused" from what? I am not sure now what issue the argument is about. Are they criticizing you for your decision? If so, you don't need to be "excused", you just need to stand firm and proud. Or are you asking them for permission? There, too, standing firm is best, but it is trickier.

Or are you asking them to change their practices? That is good to try, but there is no guaranteed recipe for persuading others. I suggest telling them about the malicious features commonly found in nonfree software, to bring home to them that this is an important issue. Also, raise the issue publicly so as to build consciousness of the issue and search for allies.

The Wiki Weapon Project and its idea of making guns with 3D printers has already been mentioned on Slashdot. It has also been written up on Forbes.com and a lot of other geek and non-geek sites. Note that when some Wiki Weapon proponents talk about making "guns" with 3D printers, they may be talking only about lower receivers or other static parts, not barrels, firing pins or other parts that must be machined to close tolerances and are subjected to a lot of stress when the gun fires. But low-cost 3D printing and low-cost CNC machining technologies are both advancing at a rapid rate, so thinking about the intersection of firearm manufacturing and open source is both worthwhile and timely. There's been a strong debate about this topic on Eric S. Raymond's Armed and Dangerous blog that's worth reading. Also recommended: The Home Gunsmith.com and CNC Gunsmithing. Astute Slashdot readers will, no doubt, recommend many more. Meanwhile, this video is about licensing, distribution, and legal matters, not the actual manufacture of firearms. There's a transcript (we're finally doing transcripts of selected videos) below the video for those who prefer to read instead of watch.

New submitter Drinking Bleach writes "Eric Raymond, coiner of the term 'open source' and co-founder of the Open Source Initiative, writes in detail about how to evaluate the effects of running any particular piece of closed source software and details the possible harms of doing so. Ranking limited firmware as the least kind of harm to full operating systems as potentially the greatest harms, he details his reasoning for all of them. Likewise, Richard Stallman, founder of GNU and the Free Software Foundation, writes about a much more limited scope, Nonfree DRM'd games on GNU/Linux, in which he takes the firm stance that non-free software is unethical in all cases but concedes that running non-free games on a free operating system is much more desirable than running them on a non-free operating system itself (such as Microsoft Windows or Apple Mac OS X)."

An anonymous reader writes "ESR, one of the finest engineers behind the open source movement and much of the software we use everyday, writes an open letter to U.S. Sen. Chris Dodd. ESR points out the concerns of 'the actual engineers who built the Internet and keep it running, who write the software you rely on every day of your life in the 21st century' about politicians attempts to lock down our Internet or our tools. A portion of the letter reads: 'I can best introduce you to our concerns by quoting another of our philosopher/elders, John Gilmore. He said: “The Internet interprets censorship as damage and routes around it.” To understand that, you have to grasp that “the Internet” isn’t just a network of wires and switches, it’s also a sort of reactive social organism composed of the people who keep those wires humming and those switches clicking. John Gilmore is one of them. I’m another. And there are some things we will not stand having done to our network.'"

MrSeb writes with this excerpt from an Extreme Tech article about the latest FreeDOS release and a bit of project history: "Some 17 years after its first release in 1994, and more than five years since 1.0, FreeDOS 1.1 is now available to download. The history of FreeDOS stems back to the summer of 1994 when Microsoft announced that MS-DOS as a separate product would no longer be supported. It would live on as part of Windows 95, 98, and (ugh!) Me, but for Jim Hall that wasn't enough, and so public domain (PD) DOS was born. ... Despite what you might think, FreeDOS isn't an 'old' OS; it's actually quite usable. FreeDOS supports FAT32, UDMA for hard drives and DVD drives, and it even has antivirus and BitTorrent clients." The official release announcement has more details on the improvements, and the FreeDOS website has the release for download.

First time accepted submitter en4bz writes "Representative Lamar Smith, the creator of the Stop Online Piracy Act (SOPA), has been consistently receiving donations averaging $50 000 from the TV/Film/Music industry for each of his re-election campaigns for the past ten years. Smith has received roughly half a million dollars from the TV/Film/Music lobby over the past ten years according to opensecrets.org. Check out the source link for a full breakdown of donors to Smith's campaigns." Speaking of SOPA, new submitter DarkStar1O9 submits this "explanation in simple terms of why this dangerous new bill in congress could result in the extinction of sites that are based on user-generated content like YouTube, Reddit, and StumbleUpon." Update: 12/18 20:42 GMT by T : An anonymous reader writes "Eric S. Raymond weighs in on SOPA and the question of why so many people hate this bill and not the dozens of others just like it that get passed on a regular basis."

As co-designer of TCP/IP (along with Robert E. Kahn), and former chairman of ICANN, it is no exaggeration to say that Vint Cerf is certainly one of the fathers of the internet, and is often referred to as simply the father. His lifetime of network engineering accomplishments — meriting, among many other laurels, the Turing Award — leaves little doubt as to why he's now a full-time internet visionary for Google (and formerly with WorldCom) as well as a Google VP. Now, Cerf has graciously agreed to answer Slashdot readers' inquiries about the past and future of this little thing called the Internet, and his role in it thus far. This short call for questions is inadequate to sum up his contributions to engineering the data flows that entangle and enlighten us in 2011, but read through a few of these capsule descriptions to get a sense of them. In accord with the interview guidelines, please try not to lump together unrelated questions. (You may find that your questions are moderated downward if they aren't concise; if you have several distinct questions, simply submit separately as many as you'd like.)

LinuxScribe tips a piece up at Linux.com with inside details on the design and construction of the Apollo 11 code. There are some analogies to open source development but they are slim. MIT drafted the code — to run on the Apollo Guidance Computer, a device with less grunt than an IBM XT — it had 2K of memory and a 1-MHz clock speed. It was an amazing machine for its time. NASA engineers tested, polished, simulated, and refined the code. "The software was programmed on IBM punch cards. They had 80-columns and were 'assembled' to instruction binary on mainframes... and it took hours. ... During the mission, most of the software code couldn't be changed because it was hard-coded into the hardware, like ROM today... But during pre-launch design simulations, problems that came up in the code could sometimes be finessed by... computer engineers using a small amount of erasable memory that was available for the programs. The software used a low-level assembly language and was controlled using pairs or segments of numbers entered into a square-shaped, numeric-only keyboard called a Display and Keyboard Unit... The two-digit codes stood for 'nouns' or 'verbs,' and were used to enter commands or data, such as spacecraft docking angles or time spans for operations." Reader Smark adds, "The Google Code Blog announced today that the Virtual AGC and AGS project has transcribed the Command Module and Lunar Excursion Module code used during the Apollo 11 moon landing. The code is viewable at the VirtualAGC Google Code Page."

mjasay writes "While the GPL powers as much as 77% of all SourceForge projects, Eric Raymond argues that the GPL is 'a confession of fear and weakness' that 'slows down open-source adoption' because of the fear and uncertainty the GPL provokes. Raymond's argument seems to be that if openness is the winning strategy, an argument Michael Tiemann advocates, wouldn't it make sense to use the most open license? Geir Magnusson of the Apache Software Foundation suggests that there are few 'pure' GPL-only open-source projects, as GPL-prone developers have to 'modify it in some way to get around the enforcement of Freedom(SM) in GPL so people can use the project.' But the real benefit of Apache-style licensing may not be for developers at all, and rather accrue to businesses hoping to drive adoption of their products: Apache licensing may encourage broader, deeper adoption than the GPL. The old GPL vs. BSD/Apache debate may not be about developer preferences so much as new business realities."

g8orade points out two recent articles in The Economist about the rise of cloud computing. The first discusses how software-as-a-service has come to pervade online interactions. "Irving Wladawsky-Berger, a technology visionary at IBM, compares cloud computing to the Cambrian explosion some 500m years ago when the rate of evolution sped up, in part because the cell had been perfected and standardised, allowing evolution to build more complex organisms." The next article examines how the cloud will force a "trade-off between sovereignty and efficiency." Reader pjones contributes news that the Virtual Computer Lab will be supplementing more traditional computer labs at North Carolina State University, and adds, "NCSU's Virtual Computing Lab and IBM are offering the VCL code as a software 'appliance' for use in schools to link to the program. Downloads are available at ibiblio at UNC-Chapel Hill. The VCL also is partnering with Apache.org to make the software available and to allow further community participation in future development."

leoboiko writes "I'm a computer scientist and programmer with no training whatsoever in hardware or electronics. Sure, we designed a simple CPU (at a purely logical level) and learned about binary math and whatnot, and I can build a PC and stuff, but lately I've been wanting to, you know, solder something. Make my own cables, understand multimeters, perhaps assemble a simple robot or two. Play with hobbyist-level electronics. How does one go about educating oneself in this topic? I've been browsing Lessons in Electric Circuits online and it's been helpful, together with Misconceptions About 'Electricity' which went a long way in helping me finally to grok what electric charge and power actually are. I've reached the point where I want an actual dead-tree book, though. Any recommendations?"

grammar fascist writes "After just less than 13 years, the first comic on the World Wide Web, Doctor Fun, has come to an end. Thanks for all the laughs, Dave. From Dave Farley's page at ibiblio: 'Doctor Fun is over. As promised, I somehow managed to finish 520 weeks or ten full years, even if it took a bit longer than ten years to get there. All of the old cartoons will stay right here as long as ibiblio wants to keep hosting them.'"

pjones writes "It's always amazing to see an article in Financial Times that supports webcasters and open source, but James Boyle sticks it to the World Intellectual Property Organization in his latest article, "More rights are wrong for webcasters." Boyle lays it out so that "economists, political scientists and people who simply want to make money" can get what's wrong."

epsalon writes "Eric S. Raymond, the well known Open Source Evangelist, recently received a job offer from Microsoft, that he strongly refused. Is this another attempt to lure Open Source figures or just ignorance?" From his post: "I called [the Microsoft HR rep], who told me my name had been passed to him by his research team. I indicated to him that I thought somebody was probably having a little joke at his expense, and promised him an email reply."

snuvlorgin writes "ibiblio.org has entered the fray, launching an enhanced BitTorrent site. Among the torrent offerings (all legal) are Linux kernels, distros, Project Gutenberg texts, and the ibiblio Speaker Series, which includes videos of talks by Larry Lessig, Robin Miller, and Dan Gillmor. ibiblio developed and open sourced the Osprey and Permaseed software to make BitTorrent seeding reliable, persistent, and suitable for large-scale content providers. Yes, you can find these torrents later."

snuvlorgin writes "ibiblio.org has entered the fray, launching an enhanced BitTorrent site. Among the torrent offerings (all legal) are Linux kernels, distros, Project Gutenberg texts, and the ibiblio Speaker Series, which includes videos of talks by Larry Lessig, Robin Miller, and Dan Gillmor. ibiblio developed and open sourced the Osprey and Permaseed software to make BitTorrent seeding reliable, persistent, and suitable for large-scale content providers. Yes, you can find these torrents later."

snuvlorgin writes "ibiblio.org has entered the fray, launching an enhanced BitTorrent site. Among the torrent offerings (all legal) are Linux kernels, distros, Project Gutenberg texts, and the ibiblio Speaker Series, which includes videos of talks by Larry Lessig, Robin Miller, and Dan Gillmor. ibiblio developed and open sourced the Osprey and Permaseed software to make BitTorrent seeding reliable, persistent, and suitable for large-scale content providers. Yes, you can find these torrents later."

snuvlorgin writes "ibiblio.org has entered the fray, launching an enhanced BitTorrent site. Among the torrent offerings (all legal) are Linux kernels, distros, Project Gutenberg texts, and the ibiblio Speaker Series, which includes videos of talks by Larry Lessig, Robin Miller, and Dan Gillmor. ibiblio developed and open sourced the Osprey and Permaseed software to make BitTorrent seeding reliable, persistent, and suitable for large-scale content providers. Yes, you can find these torrents later."

snuvlorgin writes "ibiblio.org has entered the fray, launching an enhanced BitTorrent site. Among the torrent offerings (all legal) are Linux kernels, distros, Project Gutenberg texts, and the ibiblio Speaker Series, which includes videos of talks by Larry Lessig, Robin Miller, and Dan Gillmor. ibiblio developed and open sourced the Osprey and Permaseed software to make BitTorrent seeding reliable, persistent, and suitable for large-scale content providers. Yes, you can find these torrents later."

snuvlorgin writes "ibiblio.org has entered the fray, launching an enhanced BitTorrent site. Among the torrent offerings (all legal) are Linux kernels, distros, Project Gutenberg texts, and the ibiblio Speaker Series, which includes videos of talks by Larry Lessig, Robin Miller, and Dan Gillmor. ibiblio developed and open sourced the Osprey and Permaseed software to make BitTorrent seeding reliable, persistent, and suitable for large-scale content providers. Yes, you can find these torrents later."

snuvlorgin writes "ibiblio.org has entered the fray, launching an enhanced BitTorrent site. Among the torrent offerings (all legal) are Linux kernels, distros, Project Gutenberg texts, and the ibiblio Speaker Series, which includes videos of talks by Larry Lessig, Robin Miller, and Dan Gillmor. ibiblio developed and open sourced the Osprey and Permaseed software to make BitTorrent seeding reliable, persistent, and suitable for large-scale content providers. Yes, you can find these torrents later."

snuvlorgin writes "ibiblio.org has entered the fray, launching an enhanced BitTorrent site. Among the torrent offerings (all legal) are Linux kernels, distros, Project Gutenberg texts, and the ibiblio Speaker Series, which includes videos of talks by Larry Lessig, Robin Miller, and Dan Gillmor. ibiblio developed and open sourced the Osprey and Permaseed software to make BitTorrent seeding reliable, persistent, and suitable for large-scale content providers. Yes, you can find these torrents later."

snuvlorgin writes "ibiblio.org has entered the fray, launching an enhanced BitTorrent site. Among the torrent offerings (all legal) are Linux kernels, distros, Project Gutenberg texts, and the ibiblio Speaker Series, which includes videos of talks by Larry Lessig, Robin Miller, and Dan Gillmor. ibiblio developed and open sourced the Osprey and Permaseed software to make BitTorrent seeding reliable, persistent, and suitable for large-scale content providers. Yes, you can find these torrents later."

Robert Nagle writes "Over the last year, Zope and Plone have gained mindshare as open source web application servers. In the last few months, two books have come out about how to use, extend and administer Plone. One is Andy McKay's Definitive Guide to Plone (available for free online), and the other is Julie Meloni's Plone Content Management Essentials." Read on for Nagle's review of both books. (See each) author (See each) pages (See each) publisher (See each) rating (See each) reviewer Robert Nagle ISBN (See each) summary McKay's book is indeed definitive; Meloni's book is a good introduction

The Zope/plone combination offers a variety of advantages to the open source developer: robust workflow capabilities, conformity to Web standards, cross-platform support and a sophisticated security model. On the other hand, it has a steep learning curve and deals with objects in an object database (instead of the usual RDBMS/LAMP data model).

First, here's 30 seconds of what Plone is all about (the Slashdot editors can provide the bunnies). Zope is a Python-backed web application server which includes a Zope Management Interface (or ZMI), a web-based interface to modify templates and interact with/administer the Zope Object Database (ZODB). Although Zope can be a standalone webserver, in fact people usually put it behind Apache for reasons of security, performance and caching. Years ago, Zope used a custom scripting language (DTML) to do its business logic, but later switched to an XML-based templating language called ZPT and let users use Python-based scripts to perform actions. Zope is the application server; CMF is the content management framework, and Plone is the standards-compliant front end that lets you manage skins, slots, styles, portlets, forms, actions, content types and installation of products. Then there's archetypes, which make it easier to create new content types and web forms. Oh, have I mentioned that we're dealing with objects here? In other words, we're not just throwing data and text into SQL); we're creating different types of content (documents, events, multimedia objects), storing them as objects (with actions, metadata, etc) and then summoning them (or parts of them) from the object database with ZPT using macros and indices.

From a design perspective, Plone is elegant although so multi-layered that it's often hard to figure out where to make changes. Also, while the Plone front end is snazzy, most users end up having to go to the ZMI to modify the template and edit actions (which, depending on how you look at it, can be an advantage or disadvantage). Finally, although the list of open source products for Plone and Zope is impressive, they don't necessarily play well together, and many products for Zope don't work in Plone and vice versa.

Definitive Guide to Plone author Andy McKay pages 584 publisher Apress rating 5 ISBN 1590593294

That is where Andy McKay's book and Julie Meloni's book come in. Of the two books, Andy's is more comprehensive and geared toward the experienced developer (and typical Slashdot reader); Julie's book does more hand-holding and provides more thorough explanations of introductory concepts.

As a lead plone developer, McKay has intimate knowledge of the good, the bad and the ugly for plone. Although his chapters fly by certain introductory tasks at record speed, he explains things well and offers lots of tips and hints throughout the book. (I can't tell you how many times I've put the book down and exclaimed, 'Aha, so that's how you ...'). The sequence of presentation is generally logical with one exception: in chapter 14 (page 459), the book mentions that you can use Zope Enterprise Objects to debug a live server without having to shut down Plone. That is valuable -- even vital-- information, and belonged in the earlier chapter on installing Zope. Although the chapters don't go into great depth, his code examples and commentary are sufficient to explain what is going on.

It's not the main focus of the book, but the sections on system administration (caching, tuning, scaling) are well done although some things are missing (like Virtual Host Monster). It's assumed that readers will be able to find this information elsewhere.

The best parts about McKay's book are how it relates Python programming to Plone. The deeper you get into Plone, the more important it is to write Python scripts and do basic Python debugging. Even basic sysadmin tasks like product management seems to require an understanding of object-oriented concepts. One initial difficulty comes with the idea of URL paths corresponding not to actual directories but objects being contained within other objects. (So that login_form in http://foobar/login_form doesn't necessarily reside within the foobar directory, but is in any directory or object acquired by the foobar object). This type of URL (called a traversal) is explained well enough in the book, but often makes it difficult to figure out where to find things within the ZMI and the file system. Who would have ever thought that the place to edit the login_form object for http://foobar/login_form is /foobar/portal_skins/plone_forms/login_form within the ZMI (which is actually /zopeinstance/products/CMFPlone/skins/plone_forms/ login_form.pt on the file system)? That's why McKay's skin example (in Chapter 7) accomplishes so many things; it provides a "guided tour" through the layers (i.e., scripts, templates, etc) contained within portal_skins; it also runs through the process of creating custom templates and forms based on existing ones. This, by the way, is one of the niftiest features of Zope/Plone; you push a Customize button in the ZMI, and voila! you've cloned an object for customizing. This is dense stuff, but after reading this chapter, I have a better sense of the beast I'm dealing with.

I particularly liked the book's chapters on archetypes and manipulating content types. If Zope/Plone is about manipulating objects, then it helps to have a variety of objects to manipulate. Archetypes lets you create new content types and new views for content types. By providing Python libraries for fields and widgets, archetypes makes it relatively easy to create web forms for data input. McKay's book covers this topic thoroughly and clearly. I also appreciated the chapter on searches and indexing (and the helpful table of indices and index types); this filled in a lot of gaps in my knowledge. The sections on security and workflow contained good examples, and the book also contained a section on internationalization. The programming chapters are the best parts about the book.

On the negative side, I wish there were more charts and tables in the book (perhaps as appendices). A lot of this is already found within Zope help or the Plone site, but it would have been handy to have these things as reference. Although McKay's book contains a good (though brief) introduction to Zope Page Templates, the explanation of the syntax is scattered throughout the ZPT chapter; it would have been much better to summarize all the tal tags in a single table.

Also, at many points during the ZPT chapter and other chapters, McKay refers to Plone and archetype API classes that are described nowhere else in the book. It took me a while to figure out where these things were coming from (and I would refer you to here for API descriptions). The book would have benefited from a better description of APIs, even a high level view of it (You can find some quick references here).

Because of its focus on development, McKay's book spends almost no time on third-party products or "sanctioned" products available in the plone collective. This is somewhat understandable (given the mercurial nature of product development), but the casual reader might finish the book without realizing that additional additional products even exist. (Here's a fairly comprehensive list of Plone and Zope products).

Also, I would have liked better explanation about change management. Plone has its own product installer, but I always have difficulties upgrading products. How do you test products before actually deploying them? How do you manage upgrades (and how do you upgrade Zope itself?) For such an extensible project as Plone, managing the installation, testing and upgrade of third-party products can be a disaster waiting to happen.

Plone Content Management Essentials author Julie C. Meloni pages 258 publisher SAMS rating 3 ISBN 0672326876

Julie Meloni's book takes a different approach to the subject, one geared less to Python development and more to deploying third-party products and customizing site appearances. I'm tempted to say that the typical Slashdot reader would find this book "shallow," but really that is not fair. Although Meloni's book contains a short appendix on Python, it focuses more on how Plone works out of the box and how to take advantage of core functionality. In fact, Meloni's slender book contains many useful sections probably deemed too elementary for McKay's book: how structured text works, for example.

Rather than trying to cover everything Plone-related, Meloni identifies a small number of typical tasks and explains them in detail. For example, the book documents the Plone style sheets and how to modify them in the ZMI. Too basic, you say? Well, yes, but it's still useful reference material. Rather than trying to teach you how to write your own Plone product or content type from scratch, she walks us through using that nifty Customize button to clone existing templates for customization (although to tell the truth, you still need would need to know a good bit about Python and ZPT syntax to complete the task). Although the book's section on skins focused mainly on how they relate to style sheets, I found the section on customizing slots to be particularly useful.

In contrast to McKay's book, Meloni spends a separate chapter on deploying and using several popular plone products: a discussion board, a weblog and a photo album. Given that several competing products exist for each category, and that better products are likely to come out later, this chapter will probably be the first to go out of date.

Perhaps the book could have spent less time on the products themselves and more on managing products and testing/troubleshooting them.

Of the two books, McKay's book is the more indispensable, even though I still wound up consulting external sources fairly often for clarification. On the other hand, after reading first McKay's book and then Meloni's, I wish I had read Meloni's book first. Meloni's book provides a great introduction to basic plone concepts; McKay's book is great for the power user/developer. (Still another book, recently released, Cameron Cooper's Building Websites with Plone probably goes into more detail on the Python side; read a sample PDF chapter).

Perhaps I sound like a shill for the publishing industry when I say this, but it sometimes make sense to possess two or more books on a topic. The decision-making process for geeks buying books can sometimes differ radically from the general public. Geeks, for example, don't have qualms about paying full price for a new book if the content is up-to-late and relevant to the task at hand. The ordinary reader might make a purchasing decision on the basis of which book constitutes the highest information density (the $20 book with 200 pages vs. the $30 books with 500 pages). Geeks are also more inclined to view the purchasing decision in terms of time saved (i.e., how much time will reading this book save me in the long run?) From the standpoint of saving time, there's a lot to be said for reading an introductory book first and then moving to a book on more advanced topics.

Of course, Andy McKay's book is available already for free on the web (and kudos to Apress Publishing for allowing this).

** Actually, mysql/postgresql DB adaptors make it possible for Zope to fetch/send sql data; and Archetypes has a function, SQLStorage, to allow data from content objects to persist in a sql database (news to me). Other Web Resources:

• Zopezen, Andy McKay's development weblog
• Plone How-to's
• List of Plone Products and Zope Products, Sorted by Category
• Zope & Plone API's. (More here).
• Great Visual Guide to the Zope/Plone Interface
• Handouts from the Plone Conference for 2003 and 2004
• ZopeMag Weekly, an intermittent series of Zope and Plone tips and tricks.
• For general Python introductions, see the Python Tutorial, How To Think Like A Computer Scientist (Python) and Dive Into Python (also published by Apress and free online)

Robert Nagle (aka idiotprogrammer) writes fiction under various pseudonyms. He lives and works in Houston, Texas. In early 2005 he will be launching a plone-backed literary community ezine. You can purchase the Definitive Guide to Plone from bn.com; bn also carries Plone Content Management Essentials . Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.

pjones writes " Monster Zero reports that Toho has taken the God out of Godzilla leaving us with the affectionate if diminished name of 'Zilla.' But only the American Godzilla will become godless. 'Godzilla' is reserved for our suitmation favorite, while his rival, now called 'Zilla,' is the name for the computer generated star (?) of Godzilla 98. And yes we will see the two in mortal combat with 10 other monsters in Godzilla: Final Wars. In the meantime, Godzilla at 50 events are beginning world-wide. Leave it to Kansas to hold an academic conference, 'In the Footsteps of Godzilla'. In San Francisco, the plans are more gala where more films and more Godzilla involved personalities are part of the plans for GodzillaFest which will feature 20 films (not all feature Godzilla). Any other Gojira/Godzilla/Zilla events?"

AccordionGuy writes "If you've ever spent an afternoon in the "Computers" section of a bookstore going through the programming language books, you've probably noticed that most of them seem to exist only to boost a publishing company's fortunes by capitalizing on the hot new programming language of the moment. These books -- essentially glorified bookends -- seem to follow the same format, cover the same subjects and aside from the tiny flourishes that are part of each author's particular writing style, are indistinguishable from each other. Reading them, one gets the feeling that its primary purpose is to allow the author to make some payments on a car or mortgage. I have a few of these books and they're gathering dust on the bookshelf farthest away from my desk." For deVilla's review of Dive Into Python, a book that inhabits a completely different category, read on below. Dive Into Python author Mark Pilgrim pages 432 publisher Apress rating 9 reviewer Joey deVilla ISBN 1590593561 summary The "desert island" Python book

However, from time to time, you can find a programming language book that stands apart. You can tell from the way the author writes, the topics s/he covers, the unique presentation style and insight that s/he brings that the book is a labor of love. These books enjoy placement on the shelf closest to my desk -- that is, if they're not propped open beside my computer. Dive Into Python is such a book.

One thing that sets Dive Into Python apart from many other programming language books is that its author, Mark Pilgrim, didn't originally plan to make any money from it. As we often say in Open Source circles, he simply had an itch and decided to scratch it. Mark explains this in a story on his weblog in the form of a dialog between him and his manager after showing him a rough 20-page draft:

Manager: "This is really good. You could probably make some money off this someday."
Mark: "Maybe, but I'm not going to. I'm giving it away for free."
Manager: "Why would you do that?"
Mark: "Because this is the way I want the world to work."
Manager: "But the world doesn't work that way."
Mark: "Mine does."

First released in late October 2000 and published in online and downloadable forms under the GNU Free Documentation License, Dive Into Python had grown in fits and starts until 2003, when Mark declared the project closed. Even as an unfinished work, it was held in such high regard by the Python community that developers consistently recommended it; it was also included with ActiveState's Python and FreeBSD's ports distributions. When Mark announced that Apress had decided to pay him to finish the book and publish it, it became the most-anticipated book on Python ever. Even better, Apress has been gracious enough to allow Mark's world to work way it always has: Dive Into Python is still available for free download and is still under the GNU FDL.

What's in Dive Into Python

Many programming language books follow what I like to call the "Computer Science 101 Format", with the first few chapters devoted to covering basic concepts that any moderately experienced programmer already knows. Whenever I leaf through such a book and encounter a chapter that tries to reintroduce me to data types, looping or branching, I feel cheated; I'm essentially paying for a big chunk of book that I'll never read. If you've ever been annoyed by such filler, you'll find Dive Into Python a refreshing change. Rather than wasting time and trees devoting whole chapters to rehashing Computer Science 101, Mark chose to build each chapter after the first around a program that illustrates a number of Python features and programming techniques.

The programs upon which Dive Into Python's chapters are based strike a carefully-maintained balance. They are rich enough to illustrate a number of points and be the basis for some "real world" code, yet small enough to be comprehensible tutorials. For example, chapters 2 and 3 are based on "Your First Python Program", which is a mere six lines of code. However, in those six lines, you are introduced to function declarations, documentation strings, objects and their attributes, importing modules, Python's indentation rules, the "if __name__" idiom, dictionaries, lists, tuples, string formatting and list comprehensions. Within the first hundred pages, a point where many books are re-acquainting you with the "else" keyword, Dive Into Python covers the aforementioned topics as well as Python's reflection capabilities, list filtering, the "and-or trick", lambda functions, OOP and exception handling, all with enough thoroughness to be useful. After reading Dive Into Python, you may have trouble reading other programming language books because they'll seem glacially slow and fluff-laden in comparison.

For the first two-thirds of the book, Mark continues with this approach, presenting a program and then analyzing it to see what makes it tick, teaching Python and oftentimes a programming technique along the way. Each program covers useful tasks that you're likely to run into while programming and does so in an interesting way. At the same time, concepts are introduced in a way that makes sense. For instance, chapter 4 covers two topics that mesh together quite well -- exceptions and file handling -- and it does this by exploring an interesting application: a program that displays the ID3 tag information about each file in your MP3 collection. Later chapters explore regular expressions, HTML and XML processing and Web services. By the time you've finished the first two-thirds of Dive Into Python, you'll have been introduced to enough Python to start writing a wide array of "real world" applications. The book might have benefited from having a chapter covering database access, a task that's at least as common or as useful as accessing Web services, but that's a minor complaint.

While the first two-thirds of the book concerns itself with helping the reader become a Python programmer, the final third is about elevating Python programmers above mere competence. It covers useful topics (albeit rarely-covered in language books) such as refactoring and performance optimization as well as ones that may be new to even some experienced programmers: unit testing, functional programming and dynamic functions. Each chapter in this section is still based on an example program, but rather than analyzing a completed program, its evolution is traced. Although you can get by as a Python programmer without ever reading the material in this section, you'll be a much better one for having done so.

In keeping with the spirit of Python, Mark writes the chapters to present the material as completely and clearly as possible without extra clutter. If there's any additional material that doesn't apply directly to what he's trying to explain, he provides references or links to that material rather than attempting to "fatten up" the book.

The book's long gestation period, assisted by years of reader feedback and James Cox's editing has paid off. It doesn't have the rushed feel that many language-of-the-moment books have (especially the ones written by an army of authors, each one taking a chapter). As far as I know, there isn't any of the sloppiness that pervades many programming books these days, save one instance of the popular typo "teh" (and really, what truly 1337 book doesn't have one of these?).

Mark is aware that Python is likely not to be the reader's first programming language; it's more likely to be some descendant of ALGOL (or more precisely, a language that borrows heavily from either C or BASIC). He also knows that many programmers tend to misapply techniques from the languages with which they're familiar to the language they're learning. With these in mind, he's taken great care to introduce Python idioms as soon as possible. If you follow his advice, you'll be writing "real" Python and taking advantage of what the language has to offer rather than just writing Python-flavored version of whatever programming language you're most comfortable with.

Dive Into Python's Audience

The "user level" specified on the back cover of this book says "Beginner - Intermediate", which I feel is a little misleading. As I mentioned earlier, the book takes great care not to rehash topics with which programmers with some experience are already familiar and is written with the assumption that the reader is proficient in at least one object-oriented programming language. I think many programming novices would be overwhelmed with the speed with which Python features are introduced.

Experienced programmers, whether they are new to Python or are fluent with the language will benefit the most from the book. One programmer I know works with Python daily and and even submitted a patch to wxPython; even he said that Dive Into Python showed him things about Python that he never knew. If you're tired of books aimed at "Introduction to Computer Science" students, you're going to love this book. This doesn't mean that people who don't normally program can't benefit from the book: Joi Ito, who is a tech entrepreneur and not a programmer, learned enough from Dive Into Python to put together jibot, a bot for the IRC channel that bears his name. If you're new to programming, you might want to make Dive Into Python your second book or supplement it with an introductory text such as Apress' own Practical Python, O'Reilly's Learning Python or the free online book How To Think Like a Computer Scientist (the Python edition).

Conclusion

Dive Into Python may be one of the thinnest programming language books on my shelf, but it's also one of the best. Whether you're an experienced programmer looking to get into Python or grizzled Python veteran who remembers the days when you had to import the string module, Dive Into Python is your "desert island" Python book. If you're new to programming but have heard all the wonderful things about Python, make sure that this is the second programming book you read. My congratulations to Mark Pilgrim on an excellent book and authorial debut!

(Remember, you don't have to just listen to my effusive praise. Dive Into Python is available for free at diveintopython.org. Read it for yourself and if you like it, vote with your dollar!)

You can purchase Dive Into Python from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cyberscribe writes "Project K++ just released its first alpha version today. The project aims to explore computer-generated abstract art using PHP and Ming. The name of the project is an homage to Wassily Kandinsky, father of abstract art. Caution: the Flash movies can be intensive on your graphics card. Other caution: hitting reload to see the next cool computer-generated abstract 'painting' can be highly addictive."

Jay Maynard writes "When this story on making your own TRON costume was posted two weeks ago, I was deep into making my own for the masquerade at Penguicon 2.0. Its debut at the Masquerade won the Workmanship award. I kept notes and took pictures as I was going along, and the page that resulted is now available for your viewing enjoyment. No, I didn't spend any time with straws up my nose while making it, either. I think the results were quite good, and so has everyone who's said anything to me about it here at the con." CmdrTaco is at Penguicon this weekend - go give him a big Tron hug, and make sure to get a photo...

crem_d_genes writes "The first Millenium Technology Prize to be given by the Finnish Technology Award Foundation has been awarded to Sir Tim Berners-Lee, the 'Father of the Web', for his work in creating the hypertext program that would come to change the way in which scientists, and later the general public would access data over the internet. The rest is history."