Slashdot Mirror

For those of you who remember one of our most famous stories, the culmination of said event has happened. The team, plus other friends gathered in scenic Las Vegas this past weekend. The wedding happened on Sunday, 4:11 local time (would have been 4 sharp, 'cept the cabbie bringing the bride got lost). For those of you are nice, you can send congrats to Rob at wedding@malda.org or be a big meanie, like me, and send it to his regular address, like he has done to me. More detail below for other ways - and you can tell Kathleen what a mistake she's made *grin*. And pictures are found online, along with some video.

Wedding was held at the Excalibur Hotel, which was nice. If you want to send postal congrats/bundt cake/fondue pots/yet more place mats, I've included the postal address.

Rob and Kathleen Malda
PO Box 192
Dexter MI 48130-0192

For those of you who remember one of our most famous stories, the culmination of said event has happened. The team, plus other friends gathered in scenic Las Vegas this past weekend. The wedding happened on Sunday, 4:11 local time (would have been 4 sharp, 'cept the cabbie bringing the bride got lost). For those of you are nice, you can send congrats to Rob at wedding@malda.org or be a big meanie, like me, and send it to his regular address, like he has done to me. More detail below for other ways - and you can tell Kathleen what a mistake she's made *grin*. And pictures are found online, along with some video.

Wedding was held at the Excalibur Hotel, which was nice. If you want to send postal congrats/bundt cake/fondue pots/yet more place mats, I've included the postal address.

Rob and Kathleen Malda
PO Box 192
Dexter MI 48130-0192

Jonas Acres writes: "Lowtax of the [in]famous Something Awful has posted a commentary on the future of Internet advertising. It's a pretty interesting read. He's bounced from dying ad network to dying ad network, so he has a decent platform to preach from." I've also had to deal with a number of ad networks over the years - both for Slashdot prior to the Andover acquisition and a couple of other projects. It definitely sucks. Companies that break contracts, don't pay you, and never getting any return phone calls or anything is the norm that I dealt with.

So Hemos decided he should stop back in Holland to visit some family, pick up some comic books, and eventually visit the Blockstackers office. We felt that was reason enough to record a new episode. We talk about TiVo hacks, the Napster/BMG agreement, and I ask everyone for Bloody Mary recipes.

suix was the first person to write about Salon's new section. They are calling it the "The Free Software Project", which apparently is also the title of Andrew Leonard ^[?] 's new book. From what I can tell the section is simply a collection of the Free Software articles published on Salon, most of which are by Leonard, with a couple other people thrown in there. I dunno - it just like it's an archive to me, but hey, it does get its own section name now. *grin*Update: 03/06 03:39 by H :Thanks to Salon for pointing the new sections that are online - I sit corrected.

spudwiser writes: "AMD has a press release on their Web page concerning shipment of the 900, 950, and 1000MHz Athlon processors. Also included are times for the live satellite interview with the CEO and VP of AMD." Check out some of the benchmarking info about the new chips as well. I wonder how Andy Grove ^[?] is feeling today.

linuxguru wrote to us with the news that some wacky folks have ported OpenGL 1.1 to PalmOS. Current version is .2, and it's released under the LGPL ^[?] .

SlashNET is hosting a forum with Jamie Zawinski of Netscape, Mozilla, and XEmacs fame. It will take place at 5:00 PM EST (22:00 GMT) on Feb. 26, which is this Saturday, in #forum. If you'd like to submit a question for jwz ^[?] early, you can do so at the questions page. With all the projects that he has touched, this looks to be an interesting and informative time.

jon_eaves submitted a thought provoking question on the worth of stock options. One only has to look at the recent IPOs of Red Hat ^[?] and VA Linux ^[?] to see why this might be desirable to someone in the market. Jon is looking for some discussion on the advantages, restrictions and risks involved in such dealings. Anyone out there with some good information or first hand experience into the things you need to watch for? Click below for the full submission.

"Hi all,

I'm in the process of looking for further employment, and one of the companies that I've been talking to is a start-up, and they have raised the option of taking shares instead of salary (or at least a portion of it).

I'm not super $$$$ focussed (or I'd be in SAP rather than Java), but to evaluate the offer against other companies, I'd be interested in hearing from other people who have taken share options, and what they have ended up being worth and what restrictions are "normal".

The sorts of things I'm interested in are;

1. How long did you have to keep them ?
2. What was the increase (or decrease) in value ?
3. Do you think it's a good idea ?
4. What are the "gotchas" ?

It's highly unlikely that I'll be making a choice based solely on $$$$, but it's important to understand the economics of it all.

Comments? "

jon_eaves submitted a thought provoking question on the worth of stock options. One only has to look at the recent IPOs of Red Hat ^[?] and VA Linux ^[?] to see why this might be desirable to someone in the market. Jon is looking for some discussion on the advantages, restrictions and risks involved in such dealings. Anyone out there with some good information or first hand experience into the things you need to watch for? Click below for the full submission.

"Hi all,

I'm in the process of looking for further employment, and one of the companies that I've been talking to is a start-up, and they have raised the option of taking shares instead of salary (or at least a portion of it).

I'm not super $$$$ focussed (or I'd be in SAP rather than Java), but to evaluate the offer against other companies, I'd be interested in hearing from other people who have taken share options, and what they have ended up being worth and what restrictions are "normal".

The sorts of things I'm interested in are;

1. How long did you have to keep them ?
2. What was the increase (or decrease) in value ?
3. Do you think it's a good idea ?
4. What are the "gotchas" ?

It's highly unlikely that I'll be making a choice based solely on $$$$, but it's important to understand the economics of it all.

Comments? "

You think your community is conservative? Holland, Michigan, home of the Slashdot Geek Compound, is a conservative community. "Y2K," according to yard signs on my way to last night's library meeting, stands for "Yes 2 King Jesus." Supposedly the city has gone to every Republican presidential candidate but one (Abraham Lincoln). Now the American Family Association has brought mandatory library censorware to a vote on Feb.22, and the measure's opponents have a tough six weeks ahead of them. This is the first time the battle over library filters has come near my community, and my first close look at the grass roots of a First Amendment struggle. Click for more.

The conservative community isn't the only reason that the AFA has chosen the Holland area, in my home state, to be one of its important fronts in the library blocking-software war.

There is an unusual law in the city of Holland that allows any measure to be brought to a ballot vote by petition. This is good in that it brings democracy directly to the people. Unfortunately, if a couple thousand people signed a petition demanding that the mayor must part Lake Michigan or forfeit his salary, that issue would go on the ballot. Democracy doesn't always make sense.

You may have seen press about the Republication presidential candidates campaigning in our fair state. This is because our governor pushed the primary ahead this year, so that we are now one of the first states to cast a ballot for the nominees. Registered Republicans will be going to the polls on Feb.22 to decide which candidate they like best.

Registered Democrats don't get to vote on GOP candidates and largely don't care. But in the city of Holland, thanks to a last-minute petition drive spearheaded by the AFA, there will be one additional issue on the ballot: mandatory blocking software in the city library.

Ironically, the surrounding townships help pay for the same library, but because the petition-to-ballot law applies only in the city, they won't be voting on how their money will be spent.

Holland Republicans, already at the polls to nominate a candidate, will merely have to check one more box. Holland Democrats, assuming for the sake of argument that they exist, will first have to learn that they can vote on Feb.22, and then take the trouble to drive down to the polls for the sole purpose of, as the AFA will surely characterize it, forcing children to look at pornography.

Not that it's quite that simple - the issue surely doesn't break precisely across party lines - but: Ouch! Putting the issue on the ballot on the same day as the Republican primary was a brilliant strategic move. If this is what local politics are all about, maybe I'm glad I haven't gotten involved before.

But if last night's meeting at the library is any indicator, it's not over yet.

The meeting was sponsored by Families for Internet Access, a small Holland group working to oppose library blocking software. Roughly 200 people showed up in the basement of the library to discuss the issue, including at least three Slashdot readers. The large majority were clearly opposed to filters. Luckily, the minority was vocal enough that at least some of their views could be heard, so it wasn't too one-sided.

Don Wildmon, president of the Tupelo, Mississippi-based AFA, says "a community's taxpayers own the local library," and it's going to be interesting to see if that's true. The Holland library has had few problems with inappropriate material to date. The computers in the children's section are not on the net. The internet terminals in the adult section are clustered closely in a well-lit area; patron sessions are limited to 30minutes once per day, and library staff walk through the area frequently to enforce this rule. Even with access restricted to brief sessions, there is almost always a line waiting to use the next computer.

In the four years they've offered internet access, there have been a total of six incidents where a patron had to be removed for causing a disturbance. Of these, only one involved viewing of inappropriate material (it was unclear whether or not this was pornography). To put this in perspective, there were 26,000 patrons who used the internet last year alone.

It seems a bustling, crowded public area in a public library, in front of a big window facing a busy street, is not an environment where people commonly go to look at porn. Imagine that. As one of last night's presenters said, "there is an effective filter in place already, and that is the good people of Holland." It seems clear that censorware is a solution in search of a problem - at least in this community.

But the AFA knows how to look for a problem. The pamphlet that they circulate on library "safety" suggests some ways to determine whether a library has "come under the influence of the American Library Association." The "citizen activist" is urged to "use these helps to learn if your library is a community friend or foe":

"Inquire if your library ... celebrates ALA's 'Banned Books Week.'"

"Search for classic scholarly books. A healthy selection should be available. Suggested titles... Principia Mathematica by Sir Issac Newton." [sic]

"On your library's computer, go to www.yahoo.com or any of the popular Internet search engines. In the search field enter the following: XXX,hardcore,nude"

Are those really the best ways to determine whether a library has a problem with pornography?

Incidentally, I've not gotten confirmation, but the rumor is that the local AFA will be recommending SurfWatch as their filter of choice. In which case, that last suggestion is an interesting one. I purchased and installed SurfWatch on my home computer this weekend, and it blocks me from accessing Yahoo. I still can't figure that out, considering the company that sells it partners with Yahoo.

The AFA has also been claiming support from Sen. John McCain (R-Ariz.). But at Monday night's meeting, he said he can't specifically support the local initiative because he doesn't know what it's all about. In fact, when the AFA's position was described to him, he interrupted to ask what "AFA" stood for.

In the end, it may not matter whether the problem of inappropriate library material exists or is manufactured. The AFA also recommends that its activists "take [their] concerns through the library chain of command," but in Holland, they refused to meet with the library and went straight to the ballot instead. The voters will decide whether censorware gets installed, and the public's chance to learn about the issues may be limited at best.

In the next six weeks I hope to get a "view from the trenches" of Holland's First Amendment struggle, and to bring it to Slashdot. I'll make no bones about the position I take on the issue. I'll try to focus less on why blocking software is a bad idea in libraries - I'll leave it to other websites to explain that - and more on how the memeticwarfare ^[*] is being conducted. I'll be reading all your comments. Check the YRO section, too, for updates not quite important enough for the Slashdot homepage.

Because this month, mandatory library censorware is a hot topic in Holland. Next month, it may be in my home town. And the month after that - yours.

Time for an etoy.com news roundup. The Etoy artists are still operating under a ridiculous injunction that bars them from operating a website at their domain. NSI caved to what they perceived as a court order and put the entire domain on hold, so email is blocked too. And Monday's meeting with the judge turned out to be merely a status conference which, according to Etoy's lawyer, "took all of 45 seconds." Nothing was decided, and the injunction remains in effect. But there's good news about the trademark. Click to read more.

The status conference was scheduled for 8:30 AM on the Monday after Christmas weekend, and Etoy's lawyer wasn't able to attend. Essentially it was the judge checking in with eToys' lawyers; the next meeting is scheduled for Jan.10, but that will probably also be just a status conference.

Here's the good news. According to Etoy's lawyer, one of eToys' major claims to trademarked ownership of "etoy" has been shot down.

eToys had purchased the trademark "ETOYS" from Etna Toys, a New York importer which had secured the mark for itself in 1990. In this way, the company which hadn't formed a website until 1997 could claim that it owned a trademark older than the art group which had been operating on the web since 1995.

Fortunately for Etoy, the Trademark Office decided that "ETOYS" was too generic to be trademarked, and invalidated it. According to this decision, prefixing "e" to the generic term "toys" is not enough to make it trademarkable. This decision may yet be overturned, but it's looking more promising by the day.

Meanwhile, Wired reports that John Perry Barlow and Douglas Rushkoff have joined the etoy crisis advisory board. Barlow calls this domain name dispute "the battle of Bull Run." He's got a point - NSI has taken a highly unusual action based solely on the bullying of a legal firm and a single clueless judge. If that matters more than the time-tested rules of the internet, we're all in trouble. Barlow says that Jon Postel, who worked so hard to establish those rules, would be in tears.

TBTF points out that eToys' stock has been plummeting since Dec.1 and asks why. Since that story, it has continued to fall. Some think this has something to do with their bullying Etoy; others disagree; there are some good comments in the Take It Offline forum that TBTF started.

Etoy's supporters' website at toywar.com promises "TOYWAR.com 1.0 will leave the etoy.BETA-LABS in a few days" but it's been saying that for weeks.

Finally, Etoy's friends at RTMark have taken it upon themselves to wage a game against eToys. The point is apparently to drive their stock price to zero. To me, this sounds about as fun as Quake over a 1200 baud modem, but maybe I'm just too bourgeois.

EmilEifrem writes "A JavaLobby member asked RMS ^[?] about his opinion on Java and GPL. Interesting, as always." I think my favorite quote is the intro: "It is strange to argue for ensuring compatibility in Java by keeping implementations non-free. Even if you accept the choice of values (compatibility above freedom) this idea is based on, which I don't, it simply won't do the job."

WarSpite was the first of many to write with the news that id has open-sourced the Quake 1 Source Code. This includes WinQuake, GLQuake, QuakeWorld, and GLQuakeWorld. Yes, it's been released under the GPL ^[?] . id's ftp site got the goods.

TGmentor wrote to let us know that Wired has an article about Richard Stallman's boycott of Amazon.com for its patent policies. The patent question is the recent victory that Amazon won over B&N for its 'one-click' shopping patent. Good work on the part of RMS ^[?] - we need to show companies that just because they can patent something, they don't need to.

Jacob Javits Convention Center, Manhattan,NY Tonight the Free Software Foundation gave out its Second Annual Award for the Advancement of Free Software. The nominees were introduced by our own CmdrTaco, fetchingly clad in a light blue plaid shirt. The awards themseleves were presentd by Richard M. Stallman, who wore a wonderfully fuzzy, warm-looking red, white, grey, and blue sweater. (More below)

The awards were given out in conjunction with theBazar, a gathering of Open Source experts, boosters, and devotees featuring a number of tutorials on assorted Open Source and GNU/Linux-related topics.

Last year's Award for the Advancement of Free Software went to PERL-meister Larry Wall. This year the three finalists were Donald Knuth, John Gilmore, and Miguel de Icaza.

And the winner was (drum roll please) Miguel de Icaza!

Miguel lent the proceedings a moment of extra drama by arriving - literally - at the second his name was announced, right after RMS said he was not there and could not, therefore, be expected to make a speech. But there he was, and the speech was both brief and charming.

A surprise award was also given to Blockstackers, which has donated a significant amount of money to the Free Software Foundation. This award was accepted by a shocked - and literally blushing - Rob Malda.

We join the Free Software Foundation in congratulating Miguel de Icaza.

See pictures of the award ceromony and participants here.

Kevlar sent us an article running in the Boston Globe regarding RMS ^[?] 's position on ESR ^[?] 's new-found wealth. There's also a good interview with Linus about the various IPOs that have occured recently. Hint: He's happy, and he likes Larry Augustin.

Kevlar sent us an article running in the Boston Globe regarding RMS ^[?] 's position on ESR ^[?] 's new-found wealth. There's also a good interview with Linus about the various IPOs that have occured recently. Hint: He's happy, and he likes Larry Augustin.

Everyone at this point has heard and seen about VA Linux Systems succesful IPO. Lesser known is the fact that ESR ^[?] is on the Board of VA. Yesterday seems to have been a time of personal reflection on the his new situation. Click below to read ERSR's musings on sudden wealth.

A few hours ago, I learned that I am now (at least in theory) absurdly rich.

I was at my machine, hacking, when I got email congratulating me on the success of the VA Linux Systems IPO. I was working on my latest small project -- a compiler for a special-purpose language I've designed called Scriptable Network Graphics, or SNG. SNG is an editable representation of the chunk data in a PNG. What I'm writing is a compiler/decompiler pair, so you can dump PNGs in SNG, edit the SNG, then recompile to a PNG image.

"Congratulations? That's interesting," said I to myself. "I didn't think we were going out till tomorrow." And I oughtta know; I'm on VA's Board of Directors, recruited by Larry Augustin himself to be VA's official corporate conscience, and it's a matter of public record that I hold a substantial share in the company. I tooled on over to Linux Today, chased a link -- and discovered that Larry Augustin had taken the fast option we discussed during the last Board conference call. VA had indeed gone out on NASDAQ -- and I had become worth approximately forty-one million dollars while I wasn't looking.

Well, that didn't last long. In the next two hours, VA dropped from $274 a share to close at $239, leaving me with a stake of only thirty-six million dollars. Which is still a preposterously large amount of money.

You may wonder why I am talking about this in public. The first piece of advice your friends and family will give you, if it looks like you're about to become really wealthy, is: keep it quiet. It's nobody else's business -- you don't want to look like you're gloating, and you don't want to be deluged with an endless succession of charity appeals, business propositions, long-lost best friends, and plain bald-faced mooching.

Trouble with the "keep it quiet" theory is that I've made my bucks in a very public way. When you're already a media figure, and your name is on the S-1 of a hot IPO, and email from friends and journalists starts coming in like crazy as the stock breaks first-day-gainplaying it coy swiftly ceases to look like a viable option.

Besides, it wouldn't be fair to dissemble. I serve a community. I'm wealthy today because my efforts to spread the idea of open source on behalf of that community helped galvanize the business world, and earned the respect and the trust of a lot of hackers. Larry thought that respect was an asset worth shelling out 150,000 shares of VA for. Fairness to the hackers who made me bankable demands that I publicly acknowledge this result -- and publicly face the question of how it's going to affect my life and what I'll do with the money.

This is a question that a lot of us will be facing as open source sweeps the technology landscape. Money follows where value leads, and the mainstream business and finance world is seeing increasing value in our tribe of scruffy hackers. Red Hat and VA have created a precedent now, with their directed-shares programs designed to reward as many individual contributors as they can identify; future players aiming for community backing and a seat at the high table will have to follow suit. In this and other ways (including, for example, task markets) the wealth is going to be shared.

So while there aren't likely to be a lot more multimillion-dollar bonanzas like mine, lots of hackers are going to have to evolve answers to this question for smaller amounts that will nevertheless make a big difference to individuals; tens or hundreds of thousands of dollars, enough to change your life -- or wreck it.

(Gee. Remember when the big question was "How do we make money at this?")

The first part of my answer is "I'll do nothing, until next June". Because I'm a VA board member, under SEC regulations there's a six-month lockout on the shares (a regulation designed to keep people from floating bogus offerings, cashing out, and skipping to Argentina before the share price crashes). So it's not strictly true that I'm wealthy right now. I will be wealthy in six months, unless VA or the U.S. economy craters before then. I'll bet on VA; I'm not so sure about the U.S. economy :-).

Assuming the economy does not in fact crater, how is wealth going to affect my life in six months? Honestly, I think the answer is "not much". I haven't spent the last fifteen years doing the open-sourcefor the money. I'm already living pretty much exactly the way I want to, doing the work that matters to me. The biggest difference the money will make to me personally is that now I should be able to keep doing what I love for the rest of my life without worrying about money ever again.

So I expect I'll just keep on as I've been doing. Hacking code. Thinking and spreading subversive thoughts. Traveling and giving talks. Writing papers. Poking various evil empires a good one in the eye whenever I get a chance. Working for freedom.

I expect most other hackers confronted with sudden wealth will make similar choices. Reporters often ask me these days if I think the open-source community will be corrupted by the influx of big money. I tell them what I believe, which is this: commercial demand for programmers has been so intense for so long that anyone who can be seriously distracted by money is already gone. Our community has been self-selected for caring about other things -- accomplishment, pride, artistic passion, and each other.

OK, so maybe I'll break down and finally get a cell phone. And cable broadband so I can surf at smokin' speed. And a new flute. And maybe a nice hotrodded match-grade .45 semi for tactical shooting. But really, I don't want or need a lot of stuff. I'm kind of Buddhist that way; I like to minimize my material attachments. (My family gripes that this makes me hell to buy Christmas presents for.)

I'm not going to minimize my attachments by giving it all away, though, so you evangelists for a zillion worthy causes can just calm down out there and forget about hitting me up for megabucks. I am *not* going to be a soft touch, and will rudely refuse all importunities.

I'm not copping this harsh attitude to protect my money, but rather to protect the far more precious asset of my time. Because I don't want to have to become a full-time specialist in deciding whose urgent pitch to buy, I'm going to turn everybody down flat in advance. Anyone who bugs me for a handout, no matter how noble the cause and how much I agree with it, will go on my permanent shit list. If I want to give or lend or invest money, *I'll* call *you*. (Sigh...)And yes, there are causes I'll give money to. Worthy hacker projects. Free-speech activism. Firearms-rights campaigns. Tibet, maybe. I might buy a hunk of rainforest for conservation somewhere. Megabucks are power, and with power comes an obligation to use it wisely. I'll give carefully, and in my own time, and only after doing my homework -- too much charity often kills what it means to nurture. And enough about that.

Ironically enough, one result of my getting rich is that I will probably start charging for speaking appearances, now that nobody can plausibly accuse me of doing it for the money. I won't charge open-source user groups or schools, but I will cheerfully extract a per diem from all the business conferences that keep wanting me to to boost their box office. Charging a price for my time will separate the expensive conferences that attract powerful people from the marginal events where the hacker community would get less leverage from my presence.

For the same reason, I'm still going to insist that anybody who wants me to give a talk has to cover my expenses and eliminate hassles. But I also expect I'll still carry my own luggage. And I'll never get too proud to crash on somebody's daybed when the local user group is too broke to cover a hotel.

But enough trivialities; I'm going to get back to work. I've got the SNG compiler stage almost done. Next up, I need to refactor the pngcheck code so I can give it a report-format option that generates SNG syntax. Then, I need to think about supporting MNG...
--
Eric S. Raymond

Sarge_97 wrote to us with the latest from Alan Cox ^[?] 's diary. With Red Hat's movement into Europe, and the creation of Red Hat UK, he'll be closing Building Number 3 and going to work for Red Hat UK. This is, of course, no change in what was actually going on anyway.

disclaimer:Hemos owns shares in red hat

Jason R was the first to write with legal battle news that the RIAA ^[?] has filed a lawsuit against the company that makes the Napster. They are seeking damages of up to $100,000 per pirated song - Napster says that their software exchanges no files, and that they are not legally responsible for any pirating done.

mr wrote to us to point out an article on IBM in today's SF Chronicle. IBM, starting on Monday at the Internation Electron Device Meeting, will be disclosing eighteen new inventions coming out of their labs. IBM goes to so far to say that it will keep Moore's Law ^[?] around for at least another decade. The article also talks about some of IBM's recent advancements as well as describing some of the new stuff to be unveiled.

This week Bruce Perens ^[?] learned the hard way that Open Source development has become a popular spectator sport. Or, as I described it a few days earlier, a performing art. Like it or not, things are changing with Open Source development, with the Internet, with the way online news is gathered and spread, and with Slashdot. More ->

If you didn't read (or don't feel like going to) the story linked to above about Bruce's little foot-in-mouth moment, I'll summarize it for you: After getting (IMO justifiably) frustrated over some terms in the license for Corel's new Debian-based Linux distribution and Corel's refusal to change them, Bruce posted a little note on the debian-legal discussion list that said, in part, "It's time for us to bring suit against Corel for this 'can't download unless you're 18' stuff. That's not in our license and they know it."

Almost immediately, a Slashdot reader submitted Bruce's comment to us, and Hemos ran it as a story as soon as he checked to make sure that yes, Bruce had really written that comment. The Slashdot story got over 300 remarks added to it within two hours of its initial appearance, many of which said that Bruce had over-reacted to Corel's licensing intransigence, and many more which lambasted Slashdot generally, and Hemos personally, for having posted a "private" message on Slashdot without getting Bruce's permission in advance.

Bruce was an active participant in the Slashdot discussion that followed Hemos's post and, in the end, backed down his original "we oughta sue" statement. Hemos apologized for the post. And the comments kept on coming, because that's the nature of Slashdot.

There was also some e-mail exchanged between Bruce, CmdrTaco, Hemos, and myself. It was not vituperative. We all like and respect each other. Bruce has my home phone number, and I have his (somewhere). But that e-mail exchange led to this article, because this entire incident, and the way it got blown out of proportion, is a prime example of changes in the nature of online discussion, Open Source development, and Slashdot's role in it all.

Coincidentally - it had been scheduled to run for over a week - yesterday we had an Ask Slashdot piece about the demise of old-fashioned, local dialup Bulletin Boards. There was a lot of nostalgia expressed for the days when your "online community" was 20 or 30 people who all lived near you, and you could all get together now and then for a soda or a beer or whatever. There were no Anonymous Cowards in that kind of environment. Sure, people used screen names like "BBBopper," but if you were a member of the community, you knew that BBBopper's real name was "Bernard," where he lived, and where he worked.

I miss those days, and I'm sure Bruce does too. You could say damn near anything on your freewheeling local BBS, and if you *really* put your foot in your mouth you could either delete your comment or ask your friendly sysop to delete it for you. But it didn't really matter. The chances of a vituperative neighbor or a reporter for the local newspaper reading your post were virtually nil, and even if they were reading, so what? Back then, hardly anyone paid attention to the few weirdos who spent their nights dialing into each others computers.

Fast-forward to now: there are days when Slashdot does well over one million pageviews. Reporters from The Wall Street Journal (Hi Lee!), CNN (Hi, Ian!) and even Al Gore campaign staffers (Hi, Ben!), read Slashdot regularly. Stories that break here are often picked up by general-interest media or serve as inspiration (we say politely) for their own reporting. And Slashdot readers obviously subscribe to discussions like debian-legal, so the distance between a hasty mailing list post and the front page of a national newspaper can be as little as two clicks.

Calling your favorite mailing list "private" or "obscure" does not make it so. If any idiot who has a valid e-mail address can subscribe to it, it is not private. As for obscurity, that depends on the poster. An offhand comment made by Al Average is unlikely to make it into either Slashdot or the Wall Street Journal no matter where it originally appears. A comment by Bruce Perens or Richard M. Stallman or Steve Ballmer or Linus Torvalds or Larry Ellison or anyone else perceived to have "weight" in software development matters is another story. These people are celebrities, at least to Slashdot readers, so their words are going to be taken seriously, analyzed, and quoted, requoted, and even possibly misquoted as heavily as news of Cher's latest love affair will be discussed in the movie gossip tabloids.

In this "celebrity" context, there are two main differences between Bruce Perens and Cher:

• 1 - At least one billion people have heard of Cher, while only a few million (at most) have ever heard of Bruce Perens.
• 2 - Bruce Perens is more important than Cher, especially to Slashdot readers.

Despite her greater popularity, in the overall scheme of things Cher's "boy toy" adventures are inconsequential. But when Bruce advocates a lawsuit against Corel for violating the GPL, even if he rapidly recants, he's effectively putting any investment Corel has in Linux at risk. Just the thought of a threat of a suit can make investors leery of putting money into Linux-based ventures, because all this GPL and Open Source stuff is still alien territory to most "mainstream" stock market and other investment players. Whether or not a suit is justified or even possible, the idea that one could be brought is sure to be discussed by bigwigs at IBM, Red Hat, Oracle, Sun, and many other companies that have staked all or part of their future on Linux.

A better comparison than Bruce:Cher is Bruce:Alan Greenspan. If Alan Greenspan goes out to eat and tips a waiter 20% and makes a lame (but overheard) joke about waiters demanding higher tips because of the booming economy, two dozen financial pundits will immediately try to figure out if Greenspan is planning to raise interest rates, and the stock market is sure to blip one way or another in response to the "news" of Greenspan's "statement."

Like it or not, if Alan Greenspan makes his remark in a public place it is fair media game. As long as he is quoted accurately, there is nothing he can do about the appearance of his offhand sentence in newspapers and as discussion fodder on talking-head TV shows. Bruce Perens is nowhere near as influential as Alan Greenspan, but within the confines of the Open Source/free software community, his words may have more impact on investment behavior and are, therefore, more important to Slashdot readers who hold shares in Red Hat and other companies that live and die by Open Source software.

I growled a little at Hemos for later adding a "Maybe I shouldn't have posted it" apology to his piece about Bruce's comment. It was an amicable growl; we work together as a tight team around here, and we all accept the fact that each Slashdot author and editor is an individual with his own point of view. But I don't (personally) believe we should ever apologize for running legitimate news, including speculations made in public forums by Open Source celebrities. And Bruce Perens is not only a legitimate public figure in the Open Source context, but is one largely because of his own actions. Bruce is not a reticent person. He has requested Slashdot coverage of his pet projects many times, and often as not he's gotten it. This time, he got coverage when he neither requested nor desired it, and was unhappy at the kind of attention focused on him.

I called this little essay "The Spotlight is a Harsh Mistress" because (RAH reference aside) this statement sums up my main point here: that once you open a press floodgate everything passes through it, not just what you want. And the piece I wrote earlier this week about Open Source and free software developers becoming more like stage performers than reclusive poets was as much of a cautionary tale as anything else. Yes, there are adoring Open Source fans out there, but those fans are as fickle -- and demanding -- as any other kind of fans, and when you have the combination of celebrities and devout fans, paparazzi lurking in the bushes are almost inevitable.

Slashdot is not exactly in the paparazzi category (I like to think) but we are certainly a prime source not only of Open Source and free software development news, but also of community gossip. What "we" post officially is far less than 10% of the site's total content. The rest is uncensored remarks by readers. While you can choose to only read posts other readers (moderators) decide are worthwhile, you always have the option of reading Slashdot in all of its fierce, chaotic glory simply by setting your threshold to -1. (Our boss, CmdrTaco, absolutely insists on this "no censorship ever" policy and we all back him up fiercely on this one!)

Even if you are not logged in as a registered member, you can set the moderation threshold on each individual article as you read it. My personal Slashdot reading preference is a setting of -1, with comments nested instead of threaded. And, believe it or not, I read almost every comment attached to almost every Slashdot article almost every day. There are suprising gems (and some great humor) buried in the mass if you take the trouble to look for them.

Is Slashdot going downhill? Probably, in some ways. It's not the cozy little Web site I discovered several years ago, when it was new and crude and 30 comments on an article was big-time. But by that same standard both the Internet and Usenet have been going downhill almost since day one. First the original Unix heavies grumbled about letting the non-CS (but still research) people in. Then all the researchers grumbled about letting the students in, and how they polluted discussion groups with trivial conversation and dirty jokes and filled up mail servers with stupid chain letters. Then the unwashed mass of Prodigy people hit, over one million strong, and irritated everyone who was already on the Internet, and then they complained about all the "clueless AOLers" who followed them.

But newbies don't stay newbies forever, either on the Internet in general or here on Slashdot. Two or three years from now, I assure you, some of the same AC kiddies who are now going "Whoo! First Post!" will become settled members of "the community" and will grumble about the next Slashdot newbie generation's silly games, whatever they turn out to be.

And two or three years from now Bruce Perens will be a dignified Elder Statesman of the burgeoning, ever-growing Open Source and free software community, and he will be aghast at some of the things that less media-worn people say in forums they considered private but really weren't, and the whole circle will continue to grow, with new, fresh faces always coming on board -- and some of the old ones departing for one reason or another.

Perhaps, too, we'll see the advent of more "members only" forums with strict privacy restrictions, somewhat like the old private BBS operations, and those will be where "online celebrities" hang out and let down their hair with one another, just as some film celebs only feel comfortable at private parties guarded by thuglike doormen who keep out anyone who isn't on a tightly-controlled guest list.

But I would personally rather see total openness, here on Slashdot and in as many other places as possible. Sure, mistakes will be made. You'll make some, Bruce Perens will make some, and I'm sure I'll make (more than) my fair share as well. To me, this is the point of Slashdot; to level the playing field and treat all comers exactly the same, on both their good days and their bad days; to provide a well-lit, well-known "space" where both silly and serious debates can take place, opinions can be aired and debunked, and even (once in a while) a mind or two can be changed.

ac writes "It seems that Corel has made one mistake too many. Bruce Perens ^[?] is calling for a lawsuit against Corel on the behalf of Debian. The text of his message follows and should appear here soon. " Wow - check out the recent story regarding the 18 and older EULA. Update by RM: Bruce later backed off on the lawsuit threat. He reads Slashdot comments and takes them seriously, and he's a good dude at heart, okay?Update: 11/26 08:53 by H :And for all the people e-mailing me, mea culpa. Shoulda checked.

To: debian-legal@lists.debian.org
Subject: Corel Lawsuit
Date: Fri, 26 Nov 1999 10:09:00 -0800 (PST)
From: bruce@perens.com (Bruce Perens)
Message-Id:

It's time for us to bring suit against Corel for this "can't download unless you're 18" stuff. That's not in our license and they know it. I've tried to help them several times, and they continue to be 100% clueless. I think at this point they are not representing Debian well, and should not distribute it. I'm not going to help them any longer.

Bruce Perens

fRy hooked us up with a cool story on MSNBC (originally on Feed) about what we can anticipate coming in the future. Covering everything from nanotechnology ^[?] to toys, genetics to espionage, it's a fun read with loads of interviews with smart people.

A reader writes "The brand new and yet unreleased STOA report (European Union Technical Committee) recommends an inquiry of the possible roles of the NSA ^[?] and the FBI ^[?] in the creation of Pentium III serial number. Possible consequences could be an European Union ^[?] -wide embargo against Pentium III-powered equipment. Read the scoop here. The article is in German, use our beloved BabelFish. " Just a note: this potential embargo not in place - it's just a possibility. But given recent Echelon fears, this is interesting news.

A reader writes "The brand new and yet unreleased STOA report (European Union Technical Committee) recommends an inquiry of the possible roles of the NSA ^[?] and the FBI ^[?] in the creation of Pentium III serial number. Possible consequences could be an European Union ^[?] -wide embargo against Pentium III-powered equipment. Read the scoop here. The article is in German, use our beloved BabelFish. " Just a note: this potential embargo not in place - it's just a possibility. But given recent Echelon fears, this is interesting news.

A reader writes "The brand new and yet unreleased STOA report (European Union Technical Committee) recommends an inquiry of the possible roles of the NSA ^[?] and the FBI ^[?] in the creation of Pentium III serial number. Possible consequences could be an European Union ^[?] -wide embargo against Pentium III-powered equipment. Read the scoop here. The article is in German, use our beloved BabelFish. " Just a note: this potential embargo not in place - it's just a possibility. But given recent Echelon fears, this is interesting news.

Thanks to Jeremy Chatfield for poking me about Xig ^[?] 's recent press release regarding them being the first to market a commercial hardware-accelerated 3D X server. They will be showing at Comdex, next week, and shipping in December. Support for cards looks nice as well, with over 30 cards supported,from companies like 3Dlabs, ATI, Evans & Sutherland, Diamond, S3 and Matrox.

LazLong wrote to let us know that Samba ^[?] 2.06 has been released. A whole slew of bug fixes, as well as some new features. The technical documentation is available, or just go all out and grab the tarball.

IBM, Sun and others are helping the Apache Group create Open Source XML ^[?] tools for use with Apache. Some companies including Lotus are giving away their XSL ^[?] technology to the project.

IBM, Sun and others are helping the Apache Group create Open Source XML ^[?] tools for use with Apache. Some companies including Lotus are giving away their XSL ^[?] technology to the project.

Kurt The Pope, most notable for his recent reviews of CodeWarrior and Code Fusion has taken time to play in a slightly different IDE ^[?] - Railroad Tycoon II Gold, by Loki. Click below for the skinny.

Rating 10/10
Buy from Lokisoft.

When I survey my life and contemplate which computer games have sucked my time away from being an otherwise productive citizen, Railroad Tycoon stands out high on the list. I spent many a summer afternoon with my friend Nate and his 286 building railroad empires while our peers were out living healthy and energetic lives. Now, Loki has released a new version of Railroad Tycoon, Railroad Tycoon Gold Edition 2, for Linux. RT2 is very similar to its predecessor, but has improved graphics, more scenarios, campaigns, multi-player support, a terrain editor and an improved and more complex financial model.

At the game's core, as the name implies, you build railroads. You ship passengers, mail, and a wide variety of other raw materials, goods and products from one location to another. If you send raw materials to a city with the appropriate industry, it will create a finished product for you to ship to another city. You have the option to select how difficult of an industrial model you wish to use. If you chose the basic, option, you can ship anything to any city and they will buy it. This obviously makes it much easier to find a buyer for your goods. Think it will be fun to ship every carload of coal in the United States to Alpena, MI? That's fine, because they'll happily pay for it. For those looking for a little more challenge or a more realistic game, you can choose an advanced model which only pays a fraction of the price for goods not demanded, or the expert level where you basically get nothing for undemanded goods.

But if you are only playing to build a railroad, you are missing the real fun of the game. If you play your cards right, it will be no time before you are making money faster than you can spend it. It is time to become a true robber baron and create monopolies that would make Microsoft drool. If you have a couple hundred thousand spare dollars, you can begin to buy up all of the industries around your railroad-though you have to be playing the most difficult industrial model to do this. While you do need to be careful to buy and hold only profitable industries, this is an easy way to earn a little money.

The real monopoly building fun, and frankly the most fun part of the game, is playing a ruthless corporate raider. RT2 has added features such as buying or selling on the margin give you that extra edge when playing the market. Thanks to the designer's decision to separate corporate funds from company funds, you can now first personally buy up a bunch of a competitors stock and thereby guarantee some votes when your company attempts to merge (or more accurately, take over) the company.

While the game concept and design are excellent, there are a couple of minor issues with the game. First, the scrolling is very slow which makes is a little bit difficult to get around the map. Second, if you choose to start a new game on a large map, it can take a little while for the computer to create the game. Both of these items, while they can be corrected with a getting a faster machine, the performance was somewhat slow for a fairly well loaded Pentium II.

Overall, this is wonderfully addictive game. There are a wide variety of difficulty levels, depending on how complex of an economy you want to play. If you are they type who would rather control the world's economy than run around through caverns shooting thiings, this game is a must buy.

Note: Railroad Tycoon II Gold, which this game is, is different from Railroad Tycoon II. As Gold implies, it comes equipped with more scenarios, and more playability.

quadra writes "New Musical Express has a strange article based on a report by the British Phonographic Industry. According to them, sites are using MP3s in order to 'force' users to watch porn. " For those who aren't familar, the BPI is the British-equivalent of the RIAA ^[?] . Wow. I can't even imagine the thought process that leads people to say things like that.

Isaac-Lew wrote to us pointing out that Opendesk.com has gone into public beta. From the looks of it, they are trying to implement an Office-like suite of features on the Web. Word Processor and such are still forthcoming, but they have got calendering tools, web mail and other "applications" in place. One of the most interesting aspects is that they claim to be open sourcing the project. I can't quite tell if it's a Sun-style commuity source licensem, or a GPL ^[?] style license.

cluke writes "The Amiga Dealer's Association are suing Gateway and Amiga Inc. over breach of promise. It seems they're not too happy about being strung along for so long by Gateway. " Suing to the tune of somewhere around three million dollars US, but the web page points out something - the ADA is suing Amiga, Inc. Amiga, Inc has no money, and GW2k ^[?] is protected from damages legally. The full text of the filing, with commentary is online for the reading.

srl writes "Fast Company, a magazine that talks a lot about the "new world of work" and how the Net is changing business, has a long interview with ESR in this month's issue. The interview talks about how open-source is changing people's ideas about *why* we should work. " If you've been looking for a magazine to further educate your PHB ^[?] , grab this issue. They can read on dead trees about open-source and believe you, because it's in Fast Company, and everyone know dead trees don't lie. *sarcastic grin*

A. J. Rimmer writes "Just ran across this review of Caldera 2.3 from Nick Petreley ^[?] of LinuxWorld. " Saint Nick likes it - says that "not only continues to leapfrog over all other Linux distributions for ease of installation; it also proves, beyond the shadow of a doubt, that Linux can be easier to install than Windows. " Pretty strong words - what do you folks like best?

So just as proof that life doens't stop when you go to a conference, Hemos got email this morning from nate informing him that his house burned down ^[?] last night. Now some rooms are missing and there is extensive smoke and water damage. Now the geek compound is 25% smaller. On the plus side, both Nate and hemos are safe and insured. Update: 10/16 11:05 by H : And to make matters worse, Chris DiBona threw my cell phone in a bucket of water. On accident. But it's pretty ironic.

So just as proof that life doens't stop when you go to a conference, Hemos got email this morning from nate informing him that his house burned down ^[?] last night. Now some rooms are missing and there is extensive smoke and water damage. Now the geek compound is 25% smaller. On the plus side, both Nate and hemos are safe and insured. Update: 10/16 11:05 by H : And to make matters worse, Chris DiBona threw my cell phone in a bucket of water. On accident. But it's pretty ironic.

Kurt has returned, continuing his reviews of Linux IDE ^[?] environments. After reviewing Code Fusion, he's reviewed Metrowerks CodeWarrior (for Suse). The full text of the review is below. CodeWarrior For SuSE
CodeWarrior for RedHat

• Company:Metrowerks
• Rating:9/10
• Summary:Inexpensive solution for those looking for an IDE solution.

It is difficult to have worked in the tech industry without having come into contact with Metrowerks. Metrowerks CodeWarrior is the dominant compiler for MacOS, with ports to Windows, Solaris, a wide variety of microprocessors, and fairly recently, Linux. The current version of CodeWarrior for Linux, version 4.0, supports C and C++, with plans for Java support in late 1999. CodeWarrior is targeted at the beginning or hobbyist programmer. While CodeWarrior lacks some of the features of its more expensive competitors, it provides a basic, low cost solution.

CodeWarrior is by far the easiest installation I have ever performed on a Linux box. I threw in the CD, answered a couple of questions, and it installed it without a problem. While I already had EGCS installed on my machine, it is a prerequisite for installation. For those who do not have EGCS installed, the CD contains a copy and the installation guide includes instructions for setting it up.

Anyone who has used CodeWarrior on any other platform will be able to easily dive straight into CodeWarrior for Linux. The interface is exactly the same. For those without previous experience, the interface is logically laid out and very usable without depending on documentation. For those who have been weaned on Microsoft Visual Studio, the interface may feel a little MacOS-like, but overall everything is well designed and very easy to use.

In addition to the standard IDE features like integrated debugging, color coded source, and simplified project management, CodeWarrior has an important advantage in that its projects are cross platform compatible. Of course, it is still up to the programmer to develop cross platform code, it at least simplified the process of migrating code between plaforms.

In spite of all of its wonderful design elements, it is not without a few annoying elements. First, whenever you create a new project, it is always named "Hello." It doesn't matter if you create a project named "foo." You still need to go under the project settings and change the Target Name manually. While this may be simply picking nits, it is a rather annoying oversight.

While CodeWarrior is targeting to individuals and relatively small projects, even some of these people have learned the wonders of using a version control system to roll back a few idiotic changes. Unfortunately, the Linux port has very poor version control abilities. Straight out of the box, there is no source control functionality. Furthermore, Metrowerks does not provide any of the necessary plug-ins to add source control to the Linux version. According to a representative from Metrowerks, they have plans to provide the necessary interfaces, but no resources have yet been allocated to the project. The specification, however, is open so that anyone desiring could create the necessary plug-in. Anyone interested in developing the necessary plug-ins should go to http://www.metrowerks.com/pdf/Plugin_API_Ref.pdf.

CodeWarrior is a low cost solution ideal for Linux developers who absolutely have to have an IDE. For users who need a lot of the extra features that make the switch from vi to an IDE worth while, CodeWarrior is somewhat lacking. These developers may wish to look to Code Fusion or other similar products with a more complete set of tools.

For the small scale individual or hobbies programmer, CodeWarrior provides a friendly environment to develop programs in. While it lacks some of the more advanced features found in other IDEs, it is a well designed program with an excellent balance of features. For a mere fraction of the cost of many competitors' products, it also is well within the range of people who are on a tight budget.

A few days past, we solicited questions from you folks to ask QuakeLaird John Carmack ^[?] . We sent the questions over to him, and he answered. A lot. It's definitely one of the best interviews we've had yet - click below to read more.

1. Inazuma asks:
I know that you and id are doing simultaneous development of Q3 for Windows, Mac and Linux. Which of those is your favorite OS to use, and which to program for?

John Carmack Answers:
I use WinNT, Win98, MacOS 8.x, and linux on a regular basis. I also spend some time with MacOS X and irix.

There are individual pros and cons to each system, but if I had to choose only a single platform in its currently shipping state to work on for the next year, I would choose WinNT.

I'm going to risk my neck here and actually defend microsoft a bit:

There are plenty of reasons to have issues with MS, but to just make a blanket statement like "everything that comes from microsoft is crap" is just not rational. There are a lot of smart people at microsoft, and they sometimes produce some nice things. There are some damn useful features of MSDEV that I have not seen on any other platform - all the intellisense pop up information and edit-and-continue, for instance.

I chose NT as our development environment because, after evaluating all available platforms, I decided it was the best tool for the job. NT had the added advantage of running the native executables of our largest target market, but the important point is that it would have won on its own merits even without it.

It offered quality 3D acceleration on intergraph hardware, a stable platform, a good user environment, apps for basics like mail and document editing as well as high end media creation tools, and a good development environment.

I made that decision over three years ago, and I think it has proven to be the correct one. NT is definitely going to be the primary development platform for our next project, but I will be evaluating alternatives for a possible transition after that. The contenders will be linux and MacOS X. None of the other unix workstations would be competitive for our purposes, and I don't think BeOS will offer anything compelling enough (they can always prove me wrong?).

I haven't really been using Win2K, but from a cursory glance, it looks like a reasonable evolution over NT 4.0. The only real downsides to NT 4.0 for me are the bad sound latency and poor input fidelity, and these should be fixed in Win2K.

The current MacOS X server is a bit of a disappointment. I really enjoyed NEXTSTEP on a lot of levels, and if it had workstation quality 3D acceleration, I probably would have stayed there. Unfortunately, much of the development effort spent on it during its transformation to MacOS X seems to be steps sideways instead of forward. Macifying the user interface, porting to PPC, deprecating ObjC for java and C++, etc. They probably all had to be done, but it just hasn't brought anything new to the table. As a user environment, it still feels sluggish, and it still doesn't have 3D graphics.

Linux has progressed a lot in usability in the time since I made the last platform decision. Sure, the guts have always been good, but the user environments were very weak compared to windows or the mac. Some people may think six xterms and a few athena apps are all the UI that anyone should need, but I disagree. The Linux user environment still isn't as good as windows, but going from redhat 5.2 to redhat 6.0 was a whole lot more impressive than going from win95 to win98, or MacOS 7 to MacOS 8. If there is another jump like that, I wouldn't feel too bad inflicting another non-windows platform on everyone else in the company.

2. DanJose52 asks:
How'd you start, personally (I mean on the inside, like emotionally and morally), and how has Id software changed you? for better or worse?

John Carmack Answers:
I knew I wanted to work with computers from a very early age, but there were also a lot of other stereotypical geek aspects to my life growing up - phreaking, hacking (nobody called it "cracking" back then), rockets, bombs, and thermite (sometimes in not-so-smart combinations), sci-fi, comic books, D&D, arcades, etc.

I was sort of an amoral little jerk when I was young. I was arrogant about being smarter than other people, but unhappy that I wasn't able to spend all my time doing what I wanted. I spent a year in a juvenile home for a first offence after an evaluation by a psychologist went very badly.

I went to a couple semesters of classes at the University of Missouri (UMKC), taking nothing but CS classes, but it just didn't seem all that worthwhile. In hindsight, I could have gotten more out of it than I did, but I hadn't acquired a really good attitude towards learning from all possible sources yet.

I dropped-out of college to start programming full time, but trying to do contract programming for the Apple II/IIGS post 1990 was not a good way to make money, and I only wound up with between $1k and $2k a month. Not having enough money is stressful, and I did some things I didn't want to. I wrote a numerology program for a couple hundred bucks one time...

Softdisk publishing finally convinced me to come down to Shreveport for an interview. I had been doing contract work for Jay Wilbur and Tom Hall, so I knew there were some pretty cool people there, but meeting John Romero and Lane Roath was what convinced me to take the job. Finally meeting a couple sharp programmers that did impressive things and had more experience than I did was great.

After I took the job at Softdisk, I was happy. I was programming, or reading about programming, or talking about programming, almost every waking hour. It turned out that a $27k salary was enough that I could buy all the books and pizza that I wanted, and I had nice enough computers at work that I didn't feel the need to own more myself (4mb 386-20!).

I learned a huge amount in a short period of time, and that was probably a turning point for my personality. I could still clearly remember my state of mind when I viewed other people as being ignorant about various things, but after basically doubling my programming skills in the space of six months, I realized how relative it all was. That has been reinforced several additional times over the seven years since then.

All the time from working at Softdisk, to founding Id and making the products we are know for has been pretty seamless for me. I have been learning as much as I can, working hard, and doing my best.

I know that most people won't believe it, but a 100x increase in income really didn't have that big of an impact on me as a person. It is certainly nice to be in a position where people can't exert any leverage on you, but it's definitely not the primary focus of my life. I get to drive a ferrari in to work, but my day to day life is almost exactly the same as it was eight years ago. I get up, go in to work, hopefully do some good stuff, then go home. I'm still happy.

3. by moonboy asks:
I once read, in Wired, an article that said you have an incredible headstart on everyone else for making "virtual worlds" on the Internet using your engine from the Quake games. Do you have any intention of doing this? Has anyone approached you about it? It would seem like a fantastic use of the technology with online gaming being so popular. Entire worlds online could be created virtually and very life-like with many different purposes.

John Carmack Answers:
Making Snow Crash into a reality feels like a sort of moral imperative to a lot of programmers, but the efforts that have been made so far leave a lot to be desired.

It is almost painful for me to watch some of the VRML initiatives. It just seems so obviously the wrong way to do something. All of this debating, committee forming, and spec writing, and in the end, there isn't anything to show for it. Make something really cool first, and worry about the spec after you are sure it's worth it!

I do think it is finally the right time for this to start happening for real. While a lot of people could envision the possibilities after seeing DOOM or Quake, it is really only now that we have general purpose hardware acceleration that things are actually flexible enough to be used as a creative medium without constantly being conscious of the technical limitations.

Two weeks ago, I pitched a proposal to develop some technology along these lines to the rest of the company. I may wind up working on some things like that in parallel with the next game project.

4. justin_saunders asks:
Many people consider you to be one of the best programmers in the game/graphics scene, based on your ability to keep pushing the limits of current PC hardware.

I was wondering what measures you use to gauge the skill of a programmer, and who, if anyone, you look up to and consider to be a "great" programmer.

John Carmack Answers:
Like most things, it is difficult to come up with a single weighted sum of the value of a programmer. I prefer to evaluate multiple axis independently.

Programming is really just the mundane aspect of expressing a solution to a problem. There are talents that are specifically related to actually coding, but the real issue is being able to grasp problems and devise solutions that are detailed enough to actually be coded.

Being able to clearly keep a lot of aspects of a complex system visualized is valuable.

Having a good feel for time and storage that is flexible enough to work over a range of ten orders of magnitude is valuable.

Experience is valuable.

Knowing the literature is valuable.

Being able to integrate methods and knowledge from different fields is valuable.

Being consistent is valuable.

Being creative is valuable.

Focus is extremely important. Being able to maintain focus for the length of a project gets harder and harder as schedules grow longer, but it is critical to doing great work. (Side note - every time "focus" is mentioned now, I think of Vernor Vinge's "A Deepness in the Sky", currently my favorite SF novel)

I certainly respect the abilities of my primary competitors. Back in the DOOM days, Ken Silverman was extremely impressive, and today Tim Sweeny is producing much of value.

5. ajs asks:
I read a sort-of-analysis that you wrote way back comparing DirectX 3D handling to Open GL (with Open GL being far preferable to you). Do you feel that the tools that you and others will need to create the next generation of games exist now under Linux or other Open Source operating systems, or is that still a long way off? What would you recommend that we developers and developer wannabes dedicate our time to?

John Carmack Answers:
To develop a game, you need coding tools, pixel art tools, modeling and texturing tools, sound tools, and usually music tools.

Coding tools are basically fine under linux, and there is already plenty of force behind their improvement.

Gimp looks serviceable for pixel editing, but I don't know of any professional game developers using it.

I assume there are some basic sound tools available, but I would be surprised if they are equal to the best windows or mac tools. That is probably the most approachable sector to work on improving.

Modeling and texturing tools are the biggest lack, but it is also the hardest to address. They really need to be built on top of solid 3D infrastructure, and that is still in its infancy right now. It would probably be possible to build a simple, focused modeling and texturing program that could get the job done, but full featured programs like MAX and maya have an immense amount of work invested in them. Maybe SGI will get maya ported to linux...

We are going to try to build our next level editor cross-platform, which will probably sort out a bunch of 3D content creation issues. I will be improving the matrox GLX driver as necessary to support the effort.

6. thebrit asks:
Is it possible ID may join Ion Storm for a future project together , or are the 'artistic' differences between you too great ?

John Carmack Answers:
Future technology licensing is certainly possible, but as for actually working together, there is very little chance of that for a project that we considered important.

If I decided to spend a little discretionary time whipping up, say, a color gameboy port of Commander Keen (an idea I have sort of been toying with), then I might ask Tom and John if they wanted to make some levels for it.

7. Scott Francis[Mecham asks:
Recently someone posted about their experience in determining the file structure of the Doom WADfile. How did you feel when people were discovering how to modify Doom, from building new levels, to changing the executable itself(dhacked) originally without any information from id? In your opinion, is the modding community a valuable place for creating future game developers?

John Carmack Answers:
The hacking that went on in wolfenstein was unexpected, but based on that, DOOM was designed from the beginning to be modified by the user community.

The hacking that went on with the leaked alpha version was obviously not approved of, but after the official release I did start getting some specs and code out. I had sent some things out early on to a couple of the people that had done tools for wolfenstein, but in the end it was pretty much a completely different set of people that did the major work with DOOM.

The original source I released for the bsp tool was in objective-C, which wasn't the most helpful thing in the world, but it didn't take long for people to produce different tools.

Dhacked was a bit of a surprise to me, and I always looked at it as something that maybe shouldn't have been done. I'm not very fond of binary editing an executable. It clearly showed that people were interested in more control, so it probably argued for the greater freedom given with quake.

I still remember the first time I saw the original Star Wars DOOM mod. Seeing how someone had put the death star into our game felt so amazingly cool. I was so proud of what had been made possible, and I was completely sure that making games that could serve as a canvas for other people to work on was a valid direction.

A doom/quake add-on has become almost an industry standard resume component, which I think is a Very Good Thing. The best way to sell yourself is to show what you have produced, rather than tell people what you know, what you want to do, or what degrees you have.

In the modern gaming era, it is very difficult for a single person to produce a complete looking demonstration game from scratch. It does happen, but a much more reasonable scenario is to do an add-on that showcases your particular talents, whether they are in coding, design, or media. You want to be able to go to your prospective employer and say "There is a community of ten thousand people actively playing a mod that I wrote in my spare time. Give me a job and I will be able to devote all of my energy to gaming, and produce something vastly superior."

8. jflynn asks:
Many people think that the extreme sucessfulness and longevity of DOOM and Quake was partly due to the internet communities that sprung up around them, to discuss playing them and write new levels for them.

How important do you feel a viable gaming community is to the success of a new game today?

John Carmack Answers:
I have always been a strong proponent of supporting the gaming community, but arguments can be made that it isn't that important for success.

Most entertainment media is designed to be throw-away, where people buy something, have a good time with it, and move on. Myst, the most successful computer game of all time, has no community.

A lot of companies would prefer to look at their games like movie releases. Every couple years, you go see the latest by a director you like, then don't think about it too much until the next one.

The game-as-a-lifestyle type of community that has sprung up around a few games is an interesting phenomenon. The plus side is that there is a lot of wonderfully creative things going on, and it does attract more attention over the years than any single media blitz.

The downside is that it breeds a lot of zealotry, which can be a bit ugly. I get some fairly hateful email from people that are too wrapped up in it and disagree with some direction I am taking.

At this point, I think it is clear that the community has been a positive thing. I was very pleased when, earlier this year, Kevin Cloud came around and agreed that the community has indeed been good for us. For years, it felt like I was just being humored by the other owners at id when I pushed for all the code releases.

9. mpav asks:
This is a break from the usual questions from this group, but I thought it would be interesting to know.. You have a couple of exotic sports cars, one being a 1000 horsepower/750 ft-lbs of torque (insane!) ferrari, and I was wondering which one you generally drive to work?

John Carmack Answers:
I drive my twin-turbo F50 almost all of the time. It took a while to get all the bugs sorted out, but it is almost a perfect combination right now. It is light, nimble, and responsive, and 600 hp at the rear wheels is just about perfect for a street car of that configuration.

I only drive my testarossa now when I am low on gas in the F50 or if I need to drive someplace where I think the extra inch or two of ground clearance is important. It is heavy and ponderous, but every time I do drive it, I am impressed again with the power. 1000 hp at the rear wheels is excessive. It takes a while to spin the turbos up to the full 24 psi of boost, but when it has a full head of steam going, it moves like nothing else on the road. It runs away from superbikes on the highway. However, when exercising it, you have a very clear sense that you are taking your life into your hands.

I will probably be getting rid of my TR when my next project car is completed. It is a custom carbon fiber bodied ferrari GTO with a one-of-a-kind billet aluminum twin turbo V12. It is going to make a bit more power than the TR, but only weigh about 2400 lbs. I have a suspicion that we will wind up detuning the engine, because 1 hp / 2 lbs is probably quite a bit past excessive and into the just-plain-stupid realm.

It was supposed to be done two years ago -- mechanics are worse than programmers.

I also have a little MGB that I am theoretically working on myself, but I haven't had time to touch it in six months?

10. Hobbex asks:
Though it unlikely that games will ever be free (ala beer), since so much effort goes into them from all angles (not just code, but also art, music, design etc), but that does not necessarily preclude open source game engines.

Admittedly (and I don't mean this as a slam against you) game engines today do suffer from many of the same problems that Open Source activists attack in Operative systems and other software: bugs, instability and sometimes even bloat and vaporware.

Do you think that Open Source will play a part in the future of game development?

John Carmack Answers:
I have spent a lot of time thinking about that.

I was trying hard to get an article together about game code licensing to go out with the interview questions, but I just didn't make it in time. I had written three pages of article and four pages of other stuff that I had ripped out because it was going off on various tangents.

First, it is interesting to examine how coding is similar or dissimilar to art, music, design, etc. Most GPL works don't have to face the issue, because the work is clearly dominated by code. A few little icons aren't enough to make people really think about it. The argument is significant for games, because coding is only about a third or less of the work in most cases. The arguments that RMS puts forth for the ethical rightness of free software also seem to apply to all digital media. If you take them seriously, the spirit of the GPL seems to want to say that all digital media should be free. That isn't a pragmatic battle to try and fight.

If you just focus on the code, I think there is indeed a viable business model for a line of titles based on open source code with proprietary data. It will take either a very small company, or a very gutsy big company to take the first step. The payoff won't be until the second product.

I think open source is at its best with games (and probably most other things) in a post-alpha model. Fixing, improving, and building upon an existing core is obviously extremely fruitful in an open source model.

Going open-source from development day one with a game probably doesn't make much sense. Design by committee doesn't work particularly well, and for something with as much popular appeal as games, the signal to noise ratio would probably be very low.

I tagged along at the beginning of a from-scratch open source gaming project (OGRE), and it more or less went how I feared it would - lots of discussion, no code.

While the mod communities may not be exactly OpenSource?, I think they work very well. There is some value in having focused areas to work in, rather than just having the entire thing dumped in your lap.

I am going to be releasing the majority of the code for Q3 soon, but there will still be proprietary bits that we reserve all rights to. We make a fairly good chunk of income from technology licensing, so it would take some damn good arguments to convince everyone that giving it all away would be a good idea.

Something that is often overlooked about Id is that Kevin and Adrian together own 60% of the company. They are artists, and most definitely do not "get" free software.

John Carmack

XenonOfArcticus writes "INMD is a recently-submitted proposal for an open collaborative profile-based ratings system for Internet Web/Usenet content. Based on a system partially inspired by Slashdot itself, it seeks to facilitate content rating that does not force censorship. The purpose behind INMD is to allow the user to choose what criteria to use when filtering/sorting content, and whose opinions should impact their browsing.Don't want the RIAA or MPAA to influence your Internet? Exclude them. Want your opinions controlled by the NRA? Submit your browsing to their discretion. You remain in control. " Looks still quite beta, but it's a cool idea - something like everything, in terms of rating knowledge/content.

Rene S. Hollan has sent an insightful piece regarding the use of a non-GPL license that is still fair to the free software community, and might even win the approval of RMS ^[?] . Toward a Better Open Source License

With the success of GNU/ ^[?] Linux in the hacker community, and it's subsequent notice by the mainstream, there has been a rapid attempt by many businesses to "cash in" on the free (as in beer :() software phenomenon. This has led to the euphemization of free as "open source", and a plethora of so-called open source software licenses, that are almost, but not quite, as free as the GPL. With business being what it is, this should come as no surprise.

The trouble with many of these open source licenses is that they tend to be received with less than abundant enthusiasm by hackers -- the very people that business is counting on to debug, extend, and support, some latest software venture, all for free, while someone else makes a profit. If that isn't enough to discredit any semblance of inherent fairness, many of these licenses have been denounced as unfair by Richard Stallman, architect of the GPL. Many heed what he has to say.

The definition of fair in an exchange depends on both parties believing themselves better off with the exchange than without it. In theory, at least it is possible that while the above situation might be viewed as "fair" by somebody, it isn't very likely. So, the hacker community loses the opportunity to work with more software, and business loses in not having the support of this community. There must be a better way.

If the NPL were modified so that some limit was placed on what could be folded back with Netscape's proprietary code, this would be a start. But, who should decide what that limit is?

Clearly, anyone who comes up with an open source license can establish such a limit, even if only to say there is none. However, this does not make the license popular. Business will always want to "have it's cake and eat it too" and it should come as no surprise that present open source licenses suggest that the "cake" be pretty big. We can either wait for some company to come up with a fairer open source license, or we can respond with an alternative of our own, that need not be equal, but that many of us think is fair. To gain rapid acceptance, it would probably have to have Richard Stallman's approval (or at least be free of his disaproval), because of the respect he commands.

Here is one proposal, to put the ball back in the court of business, as it were:
the Transitional General Public Licens (TGPL).

The TGPL is the same as the GPL, with two important exceptions:

1. The originator may combine distributed derived works produced by others and released under TGPL with the originator's proprietary code and redistribute the result.
2. The producer of a derived work may elect to distribute it under the TGPL, or the GPL, at their discretion.

Basically, this is the NPL in spirit, except the "in perpetuity" bit is cut off at a point decided by members of the community at large, in effect letting the originator have his pound of flesh, but not one drop of blood.

Obviously, an entire class of open source licenses can be thought of, that permit release of derived works either under the existing licence, or the GPL. The fairer the license, and the greater the value of the work released, the more likely it is that the originator will be granted his "edge" by grateful people who produce derived works. Furthermore, such community support encourages even more code to be released this way. That can only be a good thing.

Opinions are welcome, and openly solicited. Send them to rhollan@flashmail.com.

Rene S. Hollan has sent an insightful piece regarding the use of a non-GPL license that is still fair to the free software community, and might even win the approval of RMS ^[?] . Toward a Better Open Source License

With the success of GNU/ ^[?] Linux in the hacker community, and it's subsequent notice by the mainstream, there has been a rapid attempt by many businesses to "cash in" on the free (as in beer :() software phenomenon. This has led to the euphemization of free as "open source", and a plethora of so-called open source software licenses, that are almost, but not quite, as free as the GPL. With business being what it is, this should come as no surprise.

The trouble with many of these open source licenses is that they tend to be received with less than abundant enthusiasm by hackers -- the very people that business is counting on to debug, extend, and support, some latest software venture, all for free, while someone else makes a profit. If that isn't enough to discredit any semblance of inherent fairness, many of these licenses have been denounced as unfair by Richard Stallman, architect of the GPL. Many heed what he has to say.

The definition of fair in an exchange depends on both parties believing themselves better off with the exchange than without it. In theory, at least it is possible that while the above situation might be viewed as "fair" by somebody, it isn't very likely. So, the hacker community loses the opportunity to work with more software, and business loses in not having the support of this community. There must be a better way.

If the NPL were modified so that some limit was placed on what could be folded back with Netscape's proprietary code, this would be a start. But, who should decide what that limit is?

Clearly, anyone who comes up with an open source license can establish such a limit, even if only to say there is none. However, this does not make the license popular. Business will always want to "have it's cake and eat it too" and it should come as no surprise that present open source licenses suggest that the "cake" be pretty big. We can either wait for some company to come up with a fairer open source license, or we can respond with an alternative of our own, that need not be equal, but that many of us think is fair. To gain rapid acceptance, it would probably have to have Richard Stallman's approval (or at least be free of his disaproval), because of the respect he commands.

Here is one proposal, to put the ball back in the court of business, as it were:
the Transitional General Public Licens (TGPL).

The TGPL is the same as the GPL, with two important exceptions:

1. The originator may combine distributed derived works produced by others and released under TGPL with the originator's proprietary code and redistribute the result.
2. The producer of a derived work may elect to distribute it under the TGPL, or the GPL, at their discretion.

Basically, this is the NPL in spirit, except the "in perpetuity" bit is cut off at a point decided by members of the community at large, in effect letting the originator have his pound of flesh, but not one drop of blood.

Obviously, an entire class of open source licenses can be thought of, that permit release of derived works either under the existing licence, or the GPL. The fairer the license, and the greater the value of the work released, the more likely it is that the originator will be granted his "edge" by grateful people who produce derived works. Furthermore, such community support encourages even more code to be released this way. That can only be a good thing.

Opinions are welcome, and openly solicited. Send them to rhollan@flashmail.com.

Zach Frey writes "Nicholas Petreley ^[?] 's latest column has an interesting side-by-side comparison of Linux installs vs. Windows installs. It's a data point in the "Linux is too hard to install!" war. The upshot? Current Linux distros installed in around 15 minutes and had no trouble autodetecting his hardware, Win98 took 40 minutes and failed to recognize his network cards. W2K took ... much longer. " The more interesting comments, IMHO, were the comments on Softway Systems, but the Linux install article is timely, in light of the CNN install nightmare story.Update: 09/30 10:27 by H :Check out an update from Nick posted in the comments regarding the version of Win2k.

Thanks to darrn chamberlain for an excellent review of the Lincoln Stein and Doug MacEachern book Writing Apache Modules with Perl and C. This is an excellent book for those considering working with Apache and mod_perl, and helpful for C programmers. Click below for more details. Writing Apache Modules with Perl and C author Li pages 724 publisher O'Reilly, ISBN: 156592567X rating 9.5/10 reviewer darren chamberlain ISBN summary Absolutely essential for anyone who is considering using Apache and mod_perl. C programmers may need more. The Scenario

If you're like me, your first introduction to Perl ^[?] was in the form of CGI ^[?] scripts. A few years ago, I inherited a few dozen ancient CGI scripts (Perl and otherwise) that required Immediate Attention. CGI led to Perl, and to Apache ^[?] ; Perl and Apache led, naturally enough, to mod_perl ^[?] , once I started hitting the performance bottlenecks inherenent in CGI programming. After researching mod_perl, building a mod_perl-enalbed Apache, and reading all the available online documentation, I got it up and running--and I was suitably impressed.

So, when O'Reilly ^[?] announced a book devoted to programming Apache with Perl, I was extremely excited. The book starts with an introduction and history of web programming, introduces CGI and other types of web programming (server API ^[?] 's, such as ISAPI and NSAPI; embedded processors, such as mod_perl, mod_dtcl, and mod_pyapache; FastCGI; Java ^[?] servlets ^[?] ; ActiveX ^[?] ; and client-side scripting languages, such as VBScript ^[?] and JavaScript ^[?] ), and then describes the Apache module architecture, using some simple examples ("Hello, World" in Perl and in C). Then it gets good, covering dynamically generated content; the hobgoblin of HTTP, state; and all the other stuff that gives CGI programmer nightmares (like authentication and authorization).

What's Bad?

Although the title reads '... with Perl and C', the emphasis is very obviously on Perl. The C API reference chapters (chapters 10 and 11, pages 505 through 631) are very thorough, but almost all the examples are in Perl only. In fact, the authors go so far as to recommend that almost all Apache modules be written in Perl, and not C, except for very small modules or modules that need that extra speed boost or small memory footprint of being compiled into the server (page 13: "Anything you can do with the C API you can do with mod_perl with less fuss and bother."). Their reasoning is sound: mod_perl modules and scripts require a server restart at most, and often not even that, while for C modules, Apache itself must be recompiled; but I was expecting more in this area, perhaps a larger section on using DSO. After the book was published, however, several of the Perl-only examples were ported to the C API, and are available for download.

A few of these examples have already been published, and in these cases the book is mostly redundant. Notably, the Apache::NavBar module (which Lincoln uses on the server in his lab) and the Apache::AdBlocker module (chapters 4 and 7), appeared in The Perl Journal last year (issues 12 and 11). This is not that big a deal, since both of these modules are incredibly useful and probably deserve to be published in a few more places, but two brand new modules would have been most welcome, especially since the book's target audience probably also reads The Perl Journal.

What's Good?

There's a lot to like here. Since I'm a Perl programmer by trade and disposition, I personally liked the fact that 99.9% of the examples were written in Perl. With only a few exceptions, the modules could be copied into the right locations and run immediately; the exceptions were the modules that made use of either other programs (Chapter 5's Hangman program which uses a relational database to store state information) or specialized Apache features (Chapter 7's Apache::AdBlocker module, which requires proxy functionality).

Much of the text and all of the source code is available on the web at www.modperl.com. Chapters 6, 7, 8, and 9 can be found on the web site for the book, as can all the Perl modules and some of the examples in functional form (Apache::Magic and hangman).

Chapter 9 is the key chapter, and the heart of the book. It describes in great detail all the Apache:: modules. If you use mod_perl at all, download and print this chapter. Memorize it. Use your favorite indexing script to make it searchable. Everything you need to know about mod_perl is here in this chapter.

The appendices are also excellent, although, because it is an Apache book, I would have figured that several of the sections would be regular chapters, and not relegated to the end. The appendices are divided pretty evenly between concentrating on Perl and on C, unlike most of the rest of the book.

So What's In It For Me?

Fortunately for people like me, there is a lot of information about mod_perl on the web; The Perl Journal has had several articles on it, WebMonkey has had an article or two, and so on. There is a comprehensive mod_perl developer's guide on the offical Apache/Perl site. Lincoln Stein uses it a lot on his site and in his software. And, of course, we have the man pages and perldocs. So why do we need a book?

A few reasons. First and foremost, few of those sources go into the kind of detail that this book does, while still being approachable. Second, the book focuses on Apache, programming Apache, and (to a lesser extent) programming applications on the web; Perl and C are the means here, not the end. The in-depth technical discussions are about Apache: how it translates URI's to filenames, how it handles subrequests and internal redirects, how it maps files to MIME types. It then presents techniques for usurping these functions, customizing each phase of the reponse process, and explains when and why you would want to do this, instead of letting Apache do it's own thing. Creating checksums on the fly, compressing and decompressing data, creating extremely flexible HTML preprocessors, and modifying outgoing and incoming headers are some just some of the given examples.

The reference chapters are probably the single most valuable thing about the book. If you are a Perl programmer on a budget, you can download chapter 9 from the web site, but the C programmers out there have to buy the book to get the C API refernce. The C reference is 2 chapters (126 pages) long, and covers all the functions in precise detail.

For those among you who are using Microsoft operating systems, the book pays special attention to building, installing, and configuring mod_perl and Apache on Win32 systems, where it is different from Unix and Unix-like systems. Most of the actual modules are very similar (except for the obvious ones, such as scripts that call sendmail and the scripts that access MySQL), but the installation and building of mod_perl (or ApacheModulePerl.dll) are very different. The process is described in enough detail to make it possible, without boring those readers to whom it is irrelevant.

Conclusion

Programming Apache/mod_perl without this book is like writing Perl without the camel book. It can be done, but it is much easier and more enjoyable with the book. The writing is clear, informative, straight-forward, and, at times, amusing. The authors are the definitive sources for information on mod_perl and CGI programming, and this is reflected in every aspect of the book. While not as definitive for C programmers, it is still the best Apache API reference out there, other than the actual source code itself.

Purchase this book at Amazon.

Errata Table of Contents

1. Server-Side Programming with Apache
2. A First Module
3. The Apache Module Architecture and API
4. Content Handlers
5. Maintaining State
6. Authentication and Authorization
7. Other Request Phases
8. Customizing the Apache Configuration Process
9. Perl API Reference Guide
10. C API Reference Guide, Part I
11. API Reference Guide, Part II

1. Standard Noncore Modules
2. Building and Installing mod_perl
3. Building Multifile C API Modules
4. Apache:: Modules Available on CPAN
5. Third-Party C Modules
6. HTML::Embperl--Embedding Perl Code in HTML

Thanks to darrn chamberlain for an excellent review of the Lincoln Stein and Doug MacEachern book Writing Apache Modules with Perl and C. This is an excellent book for those considering working with Apache and mod_perl, and helpful for C programmers. Click below for more details. Writing Apache Modules with Perl and C author Li pages 724 publisher O'Reilly, ISBN: 156592567X rating 9.5/10 reviewer darren chamberlain ISBN summary Absolutely essential for anyone who is considering using Apache and mod_perl. C programmers may need more. The Scenario

If you're like me, your first introduction to Perl ^[?] was in the form of CGI ^[?] scripts. A few years ago, I inherited a few dozen ancient CGI scripts (Perl and otherwise) that required Immediate Attention. CGI led to Perl, and to Apache ^[?] ; Perl and Apache led, naturally enough, to mod_perl ^[?] , once I started hitting the performance bottlenecks inherenent in CGI programming. After researching mod_perl, building a mod_perl-enalbed Apache, and reading all the available online documentation, I got it up and running--and I was suitably impressed.

So, when O'Reilly ^[?] announced a book devoted to programming Apache with Perl, I was extremely excited. The book starts with an introduction and history of web programming, introduces CGI and other types of web programming (server API ^[?] 's, such as ISAPI and NSAPI; embedded processors, such as mod_perl, mod_dtcl, and mod_pyapache; FastCGI; Java ^[?] servlets ^[?] ; ActiveX ^[?] ; and client-side scripting languages, such as VBScript ^[?] and JavaScript ^[?] ), and then describes the Apache module architecture, using some simple examples ("Hello, World" in Perl and in C). Then it gets good, covering dynamically generated content; the hobgoblin of HTTP, state; and all the other stuff that gives CGI programmer nightmares (like authentication and authorization).

What's Bad?

Although the title reads '... with Perl and C', the emphasis is very obviously on Perl. The C API reference chapters (chapters 10 and 11, pages 505 through 631) are very thorough, but almost all the examples are in Perl only. In fact, the authors go so far as to recommend that almost all Apache modules be written in Perl, and not C, except for very small modules or modules that need that extra speed boost or small memory footprint of being compiled into the server (page 13: "Anything you can do with the C API you can do with mod_perl with less fuss and bother."). Their reasoning is sound: mod_perl modules and scripts require a server restart at most, and often not even that, while for C modules, Apache itself must be recompiled; but I was expecting more in this area, perhaps a larger section on using DSO. After the book was published, however, several of the Perl-only examples were ported to the C API, and are available for download.

A few of these examples have already been published, and in these cases the book is mostly redundant. Notably, the Apache::NavBar module (which Lincoln uses on the server in his lab) and the Apache::AdBlocker module (chapters 4 and 7), appeared in The Perl Journal last year (issues 12 and 11). This is not that big a deal, since both of these modules are incredibly useful and probably deserve to be published in a few more places, but two brand new modules would have been most welcome, especially since the book's target audience probably also reads The Perl Journal.

What's Good?

There's a lot to like here. Since I'm a Perl programmer by trade and disposition, I personally liked the fact that 99.9% of the examples were written in Perl. With only a few exceptions, the modules could be copied into the right locations and run immediately; the exceptions were the modules that made use of either other programs (Chapter 5's Hangman program which uses a relational database to store state information) or specialized Apache features (Chapter 7's Apache::AdBlocker module, which requires proxy functionality).

Much of the text and all of the source code is available on the web at www.modperl.com. Chapters 6, 7, 8, and 9 can be found on the web site for the book, as can all the Perl modules and some of the examples in functional form (Apache::Magic and hangman).

Chapter 9 is the key chapter, and the heart of the book. It describes in great detail all the Apache:: modules. If you use mod_perl at all, download and print this chapter. Memorize it. Use your favorite indexing script to make it searchable. Everything you need to know about mod_perl is here in this chapter.

The appendices are also excellent, although, because it is an Apache book, I would have figured that several of the sections would be regular chapters, and not relegated to the end. The appendices are divided pretty evenly between concentrating on Perl and on C, unlike most of the rest of the book.

So What's In It For Me?

Fortunately for people like me, there is a lot of information about mod_perl on the web; The Perl Journal has had several articles on it, WebMonkey has had an article or two, and so on. There is a comprehensive mod_perl developer's guide on the offical Apache/Perl site. Lincoln Stein uses it a lot on his site and in his software. And, of course, we have the man pages and perldocs. So why do we need a book?

A few reasons. First and foremost, few of those sources go into the kind of detail that this book does, while still being approachable. Second, the book focuses on Apache, programming Apache, and (to a lesser extent) programming applications on the web; Perl and C are the means here, not the end. The in-depth technical discussions are about Apache: how it translates URI's to filenames, how it handles subrequests and internal redirects, how it maps files to MIME types. It then presents techniques for usurping these functions, customizing each phase of the reponse process, and explains when and why you would want to do this, instead of letting Apache do it's own thing. Creating checksums on the fly, compressing and decompressing data, creating extremely flexible HTML preprocessors, and modifying outgoing and incoming headers are some just some of the given examples.

The reference chapters are probably the single most valuable thing about the book. If you are a Perl programmer on a budget, you can download chapter 9 from the web site, but the C programmers out there have to buy the book to get the C API refernce. The C reference is 2 chapters (126 pages) long, and covers all the functions in precise detail.

For those among you who are using Microsoft operating systems, the book pays special attention to building, installing, and configuring mod_perl and Apache on Win32 systems, where it is different from Unix and Unix-like systems. Most of the actual modules are very similar (except for the obvious ones, such as scripts that call sendmail and the scripts that access MySQL), but the installation and building of mod_perl (or ApacheModulePerl.dll) are very different. The process is described in enough detail to make it possible, without boring those readers to whom it is irrelevant.

Conclusion

Programming Apache/mod_perl without this book is like writing Perl without the camel book. It can be done, but it is much easier and more enjoyable with the book. The writing is clear, informative, straight-forward, and, at times, amusing. The authors are the definitive sources for information on mod_perl and CGI programming, and this is reflected in every aspect of the book. While not as definitive for C programmers, it is still the best Apache API reference out there, other than the actual source code itself.

Purchase this book at Amazon.

Errata Table of Contents

1. Server-Side Programming with Apache
2. A First Module
3. The Apache Module Architecture and API
4. Content Handlers
5. Maintaining State
6. Authentication and Authorization
7. Other Request Phases
8. Customizing the Apache Configuration Process
9. Perl API Reference Guide
10. C API Reference Guide, Part I
11. API Reference Guide, Part II

1. Standard Noncore Modules
2. Building and Installing mod_perl
3. Building Multifile C API Modules
4. Apache:: Modules Available on CPAN
5. Third-Party C Modules
6. HTML::Embperl--Embedding Perl Code in HTML

Thanks to darrn chamberlain for an excellent review of the Lincoln Stein and Doug MacEachern book Writing Apache Modules with Perl and C. This is an excellent book for those considering working with Apache and mod_perl, and helpful for C programmers. Click below for more details. Writing Apache Modules with Perl and C author Li pages 724 publisher O'Reilly, ISBN: 156592567X rating 9.5/10 reviewer darren chamberlain ISBN summary Absolutely essential for anyone who is considering using Apache and mod_perl. C programmers may need more. The Scenario

If you're like me, your first introduction to Perl ^[?] was in the form of CGI ^[?] scripts. A few years ago, I inherited a few dozen ancient CGI scripts (Perl and otherwise) that required Immediate Attention. CGI led to Perl, and to Apache ^[?] ; Perl and Apache led, naturally enough, to mod_perl ^[?] , once I started hitting the performance bottlenecks inherenent in CGI programming. After researching mod_perl, building a mod_perl-enalbed Apache, and reading all the available online documentation, I got it up and running--and I was suitably impressed.

So, when O'Reilly ^[?] announced a book devoted to programming Apache with Perl, I was extremely excited. The book starts with an introduction and history of web programming, introduces CGI and other types of web programming (server API ^[?] 's, such as ISAPI and NSAPI; embedded processors, such as mod_perl, mod_dtcl, and mod_pyapache; FastCGI; Java ^[?] servlets ^[?] ; ActiveX ^[?] ; and client-side scripting languages, such as VBScript ^[?] and JavaScript ^[?] ), and then describes the Apache module architecture, using some simple examples ("Hello, World" in Perl and in C). Then it gets good, covering dynamically generated content; the hobgoblin of HTTP, state; and all the other stuff that gives CGI programmer nightmares (like authentication and authorization).

What's Bad?

Although the title reads '... with Perl and C', the emphasis is very obviously on Perl. The C API reference chapters (chapters 10 and 11, pages 505 through 631) are very thorough, but almost all the examples are in Perl only. In fact, the authors go so far as to recommend that almost all Apache modules be written in Perl, and not C, except for very small modules or modules that need that extra speed boost or small memory footprint of being compiled into the server (page 13: "Anything you can do with the C API you can do with mod_perl with less fuss and bother."). Their reasoning is sound: mod_perl modules and scripts require a server restart at most, and often not even that, while for C modules, Apache itself must be recompiled; but I was expecting more in this area, perhaps a larger section on using DSO. After the book was published, however, several of the Perl-only examples were ported to the C API, and are available for download.

A few of these examples have already been published, and in these cases the book is mostly redundant. Notably, the Apache::NavBar module (which Lincoln uses on the server in his lab) and the Apache::AdBlocker module (chapters 4 and 7), appeared in The Perl Journal last year (issues 12 and 11). This is not that big a deal, since both of these modules are incredibly useful and probably deserve to be published in a few more places, but two brand new modules would have been most welcome, especially since the book's target audience probably also reads The Perl Journal.

What's Good?

There's a lot to like here. Since I'm a Perl programmer by trade and disposition, I personally liked the fact that 99.9% of the examples were written in Perl. With only a few exceptions, the modules could be copied into the right locations and run immediately; the exceptions were the modules that made use of either other programs (Chapter 5's Hangman program which uses a relational database to store state information) or specialized Apache features (Chapter 7's Apache::AdBlocker module, which requires proxy functionality).

Much of the text and all of the source code is available on the web at www.modperl.com. Chapters 6, 7, 8, and 9 can be found on the web site for the book, as can all the Perl modules and some of the examples in functional form (Apache::Magic and hangman).

Chapter 9 is the key chapter, and the heart of the book. It describes in great detail all the Apache:: modules. If you use mod_perl at all, download and print this chapter. Memorize it. Use your favorite indexing script to make it searchable. Everything you need to know about mod_perl is here in this chapter.

The appendices are also excellent, although, because it is an Apache book, I would have figured that several of the sections would be regular chapters, and not relegated to the end. The appendices are divided pretty evenly between concentrating on Perl and on C, unlike most of the rest of the book.

So What's In It For Me?

Fortunately for people like me, there is a lot of information about mod_perl on the web; The Perl Journal has had several articles on it, WebMonkey has had an article or two, and so on. There is a comprehensive mod_perl developer's guide on the offical Apache/Perl site. Lincoln Stein uses it a lot on his site and in his software. And, of course, we have the man pages and perldocs. So why do we need a book?

A few reasons. First and foremost, few of those sources go into the kind of detail that this book does, while still being approachable. Second, the book focuses on Apache, programming Apache, and (to a lesser extent) programming applications on the web; Perl and C are the means here, not the end. The in-depth technical discussions are about Apache: how it translates URI's to filenames, how it handles subrequests and internal redirects, how it maps files to MIME types. It then presents techniques for usurping these functions, customizing each phase of the reponse process, and explains when and why you would want to do this, instead of letting Apache do it's own thing. Creating checksums on the fly, compressing and decompressing data, creating extremely flexible HTML preprocessors, and modifying outgoing and incoming headers are some just some of the given examples.

The reference chapters are probably the single most valuable thing about the book. If you are a Perl programmer on a budget, you can download chapter 9 from the web site, but the C programmers out there have to buy the book to get the C API refernce. The C reference is 2 chapters (126 pages) long, and covers all the functions in precise detail.

For those among you who are using Microsoft operating systems, the book pays special attention to building, installing, and configuring mod_perl and Apache on Win32 systems, where it is different from Unix and Unix-like systems. Most of the actual modules are very similar (except for the obvious ones, such as scripts that call sendmail and the scripts that access MySQL), but the installation and building of mod_perl (or ApacheModulePerl.dll) are very different. The process is described in enough detail to make it possible, without boring those readers to whom it is irrelevant.

Conclusion

Programming Apache/mod_perl without this book is like writing Perl without the camel book. It can be done, but it is much easier and more enjoyable with the book. The writing is clear, informative, straight-forward, and, at times, amusing. The authors are the definitive sources for information on mod_perl and CGI programming, and this is reflected in every aspect of the book. While not as definitive for C programmers, it is still the best Apache API reference out there, other than the actual source code itself.

Purchase this book at Amazon.

Errata Table of Contents

1. Server-Side Programming with Apache
2. A First Module
3. The Apache Module Architecture and API
4. Content Handlers
5. Maintaining State
6. Authentication and Authorization
7. Other Request Phases
8. Customizing the Apache Configuration Process
9. Perl API Reference Guide
10. C API Reference Guide, Part I
11. API Reference Guide, Part II

1. Standard Noncore Modules
2. Building and Installing mod_perl
3. Building Multifile C API Modules
4. Apache:: Modules Available on CPAN
5. Third-Party C Modules
6. HTML::Embperl--Embedding Perl Code in HTML

Thanks to darrn chamberlain for an excellent review of the Lincoln Stein and Doug MacEachern book Writing Apache Modules with Perl and C. This is an excellent book for those considering working with Apache and mod_perl, and helpful for C programmers. Click below for more details. Writing Apache Modules with Perl and C author Li pages 724 publisher O'Reilly, ISBN: 156592567X rating 9.5/10 reviewer darren chamberlain ISBN summary Absolutely essential for anyone who is considering using Apache and mod_perl. C programmers may need more. The Scenario

If you're like me, your first introduction to Perl ^[?] was in the form of CGI ^[?] scripts. A few years ago, I inherited a few dozen ancient CGI scripts (Perl and otherwise) that required Immediate Attention. CGI led to Perl, and to Apache ^[?] ; Perl and Apache led, naturally enough, to mod_perl ^[?] , once I started hitting the performance bottlenecks inherenent in CGI programming. After researching mod_perl, building a mod_perl-enalbed Apache, and reading all the available online documentation, I got it up and running--and I was suitably impressed.

So, when O'Reilly ^[?] announced a book devoted to programming Apache with Perl, I was extremely excited. The book starts with an introduction and history of web programming, introduces CGI and other types of web programming (server API ^[?] 's, such as ISAPI and NSAPI; embedded processors, such as mod_perl, mod_dtcl, and mod_pyapache; FastCGI; Java ^[?] servlets ^[?] ; ActiveX ^[?] ; and client-side scripting languages, such as VBScript ^[?] and JavaScript ^[?] ), and then describes the Apache module architecture, using some simple examples ("Hello, World" in Perl and in C). Then it gets good, covering dynamically generated content; the hobgoblin of HTTP, state; and all the other stuff that gives CGI programmer nightmares (like authentication and authorization).

What's Bad?

Although the title reads '... with Perl and C', the emphasis is very obviously on Perl. The C API reference chapters (chapters 10 and 11, pages 505 through 631) are very thorough, but almost all the examples are in Perl only. In fact, the authors go so far as to recommend that almost all Apache modules be written in Perl, and not C, except for very small modules or modules that need that extra speed boost or small memory footprint of being compiled into the server (page 13: "Anything you can do with the C API you can do with mod_perl with less fuss and bother."). Their reasoning is sound: mod_perl modules and scripts require a server restart at most, and often not even that, while for C modules, Apache itself must be recompiled; but I was expecting more in this area, perhaps a larger section on using DSO. After the book was published, however, several of the Perl-only examples were ported to the C API, and are available for download.

A few of these examples have already been published, and in these cases the book is mostly redundant. Notably, the Apache::NavBar module (which Lincoln uses on the server in his lab) and the Apache::AdBlocker module (chapters 4 and 7), appeared in The Perl Journal last year (issues 12 and 11). This is not that big a deal, since both of these modules are incredibly useful and probably deserve to be published in a few more places, but two brand new modules would have been most welcome, especially since the book's target audience probably also reads The Perl Journal.

What's Good?

There's a lot to like here. Since I'm a Perl programmer by trade and disposition, I personally liked the fact that 99.9% of the examples were written in Perl. With only a few exceptions, the modules could be copied into the right locations and run immediately; the exceptions were the modules that made use of either other programs (Chapter 5's Hangman program which uses a relational database to store state information) or specialized Apache features (Chapter 7's Apache::AdBlocker module, which requires proxy functionality).

Much of the text and all of the source code is available on the web at www.modperl.com. Chapters 6, 7, 8, and 9 can be found on the web site for the book, as can all the Perl modules and some of the examples in functional form (Apache::Magic and hangman).

Chapter 9 is the key chapter, and the heart of the book. It describes in great detail all the Apache:: modules. If you use mod_perl at all, download and print this chapter. Memorize it. Use your favorite indexing script to make it searchable. Everything you need to know about mod_perl is here in this chapter.

The appendices are also excellent, although, because it is an Apache book, I would have figured that several of the sections would be regular chapters, and not relegated to the end. The appendices are divided pretty evenly between concentrating on Perl and on C, unlike most of the rest of the book.

So What's In It For Me?

Fortunately for people like me, there is a lot of information about mod_perl on the web; The Perl Journal has had several articles on it, WebMonkey has had an article or two, and so on. There is a comprehensive mod_perl developer's guide on the offical Apache/Perl site. Lincoln Stein uses it a lot on his site and in his software. And, of course, we have the man pages and perldocs. So why do we need a book?

A few reasons. First and foremost, few of those sources go into the kind of detail that this book does, while still being approachable. Second, the book focuses on Apache, programming Apache, and (to a lesser extent) programming applications on the web; Perl and C are the means here, not the end. The in-depth technical discussions are about Apache: how it translates URI's to filenames, how it handles subrequests and internal redirects, how it maps files to MIME types. It then presents techniques for usurping these functions, customizing each phase of the reponse process, and explains when and why you would want to do this, instead of letting Apache do it's own thing. Creating checksums on the fly, compressing and decompressing data, creating extremely flexible HTML preprocessors, and modifying outgoing and incoming headers are some just some of the given examples.

The reference chapters are probably the single most valuable thing about the book. If you are a Perl programmer on a budget, you can download chapter 9 from the web site, but the C programmers out there have to buy the book to get the C API refernce. The C reference is 2 chapters (126 pages) long, and covers all the functions in precise detail.

For those among you who are using Microsoft operating systems, the book pays special attention to building, installing, and configuring mod_perl and Apache on Win32 systems, where it is different from Unix and Unix-like systems. Most of the actual modules are very similar (except for the obvious ones, such as scripts that call sendmail and the scripts that access MySQL), but the installation and building of mod_perl (or ApacheModulePerl.dll) are very different. The process is described in enough detail to make it possible, without boring those readers to whom it is irrelevant.

Conclusion

Programming Apache/mod_perl without this book is like writing Perl without the camel book. It can be done, but it is much easier and more enjoyable with the book. The writing is clear, informative, straight-forward, and, at times, amusing. The authors are the definitive sources for information on mod_perl and CGI programming, and this is reflected in every aspect of the book. While not as definitive for C programmers, it is still the best Apache API reference out there, other than the actual source code itself.

Purchase this book at Amazon.

Errata Table of Contents

1. Server-Side Programming with Apache
2. A First Module
3. The Apache Module Architecture and API
4. Content Handlers
5. Maintaining State
6. Authentication and Authorization
7. Other Request Phases
8. Customizing the Apache Configuration Process
9. Perl API Reference Guide
10. C API Reference Guide, Part I
11. API Reference Guide, Part II

1. Standard Noncore Modules
2. Building and Installing mod_perl
3. Building Multifile C API Modules
4. Apache:: Modules Available on CPAN
5. Third-Party C Modules
6. HTML::Embperl--Embedding Perl Code in HTML