A naive reader of M$'s "correction" could be fooled into a rather negative view of GPL'd software, especially if it's used by the government. They make it sound as if you are obliged to GPL any software you developed if you used any GPL'd software to develop it. Say, for example, I work for the government and used emacs to edit a C program, and gcc to compile it. A naive reader of the M$ blurb might conclude that you have to release the C program that you developed under the GPL.
This spin might succeed at getting a lot of people turned off on open source software. Why, they ask, should programmers in business or government be required to share all of their work, no matter what it is? It might be nice to do so, but shouldn't they have the choice not to?
Of course that's not what the GPL requires -- you only have to share any changes you make on the GPL'd products themselves, not on anything you create using them; and the government is unlikely to get involved in projects like emacs, gcc or the Linux kernel, so the issue probably won't come up at all.
It's a clever bit of FUD on M$'s part, because this impression will have to be answered by open source advocates with another "correction", and the distinction is complex enough that the broad public may never get it.
I go to all that trouble installing SuSE on my laptop, and now he tells me! Dagnubbit, Miller, why didn't you say so a couple of weeks ago? Would have saved me an awful lot of trouble.
The article closes out with a musing about whether pioniers of the Internet like Tomlinson will go down in history with inventors like Morse, Marconi and Bell.
Now I frankly think that Tomlinson is not destined for many history books, and moreover that many of the ARPANET engineers will never become known as heroes the way Morse & co. are, but I think it was quite appropriate when the death of Jon Postel two years ago precipitated a wave of mourning throughout the Internet. To be sure, most Internet users never heard of him, not to mention the general public, but if you have any familiarity at all with the Internet's ascendancy, you'll know that Postel's contributions were crucial to its current success. Domain names, IP addressing, many of the basic TCP services such as chargen and echo, the Telnet protocol, FTP reply codes, the MIME standard -- Postel had a hand in developing numerous basic building blocks that now make up our everyday networking life.
Try searching for the author name Postel among the RFC's -- you get 232 hits. And I daresay that RFC authorship is a good deal more significant than authorship of a program like SENDMSG, since it's the open standards that made the Internet's success possible.
"... and do that because we must make the impossible deadline, come hell or high water."
This is precisely the instruction that we recently received from a client. So in October and November, we pulled graveyard shifts and rattled up a gazillion lines of code to just get the features in, one way or another, buggy or not. More likely the former.
So now we have a bug list that runs to about five or six hundred bugs. Not too surprising, if you ask me, considering the size of the project and the insane rush to get all the coding done, but now all of a sudden they're hugely worried about quality, and have frozen all features until the bug list is significantly reduced. So they had to put off the deadline after all!
The cause of all these problems is the huge pressure to reduce time to market. You've got to get an edge on the other guy, and everybody's rushing ahead so frantically that you can only keep up by letting QA fall by the wayside. And the squeeze just keeps getting tigher and tighter, as if there's no limit that will ever be reached. But we've already reached it -- software quality has simply come up too short in too many products.
There is another way, you know, but too few vendors are willing to take the chance -- be a little later than the competition, but aggressively market your product as superior in quality. It might work, but who has enough confidence to try it?
Sure, I remember Gopher, and it was swell. I also pine for the days of HTML 2.0 -- bullet lists on gray backgrounds, you could download them in reasonable time on your 14.4k modem. A return to minimalism would be welcome in this age of high-bandwidth schlock.
But look, anytime someone publishes a "manifesto" to preserve or resurrect some technology, particularly an Internet technology, you know that their time is almost over for good. If you want to see Gopher come back, then bring it back by publishing information on Gopher that readers will want to see. These things stand or fall on the choices of all those Internet users out there, and if your beloved technology is really as good as you say, they'll come and get it. Just imploring everyone to use it will never be good enough. It's usually a sign that you're losing the argument.
Floating point divide didn't even make the list?!?
Leaving this off the list is so extraordinary that I wonder if the author is, say, twenty years old, and has no perspective on history. ("History" meaning four years ago.)
The FDIV bug was front-page news, and had almost all of Usenet captivated for weeks. In fact, back in the bad old days of 1996, this was one of the first indications that the Internet could create enough public pressure to change the attitudes of a large corporation. Intel wanted to play down the whole thing, but hundreds of posters were exchanging information every day, analyzing the error, posting the inevitable jokes, expressing general outrage at Intel and discussing ways to bring them around.
Math professors posted scholarly analyses of the error, and provided links to Web pages with Mathematica graphs to illustrate where the calculations went wrong.
And even the non-technical newsgroups got into the act. talk.bizarre had a field day. Everywhere you looked, someone found a way to fit an Intel joke into their post, no matter what it was about.
Eventually, Andy Grove had to post a message of apology to the Intel newsgroups, announcing that Intel would reverse field and let buyers exchange their processors, no questions asked (originally, you had to justify your need for a new chip).
Man, those were the days. Usenet is dead, long live Usenet!
Re:I'm on the march right this minute
on
Death March
·
· Score: 1
If the project is so sh*tty, why wait till the project is over to resign ?
You're tempting me. Oh, you are tempting me...
I'm on the march right this minute
on
Death March
·
· Score: 1
Here I am in the deepest pit of hell, slaving away on an impossible project that will drive my company to bankruptcy. We're on the verge of missing the next drop-dead milestone, and the customer is already talking to the legal department. When was the last day that I worked less than 16 hours? When did I last see my family? I hardly remember any more. All of my colleagues have assured me that they will resign as soon as it's over, and so will I.
As discretely as possible (because my boss might see me), I surf on over to Slashdot to give my tortured brain a moment of rest. Death March, it says! No kidding.
As an American posting from Germany, let me just contribute two bits of information. The assumption is that Anglo-Saxons are conducting industrial espionage. This assumption is widely held (it's not just Ilka Schröder), and it's deeply resented.
I worked for a year at the Airbus airplane plant in Hamburg, and there are elaborate security mechanisms in place there. They said that they had already caught a couple of spies. Their only opponent, obviously, is Boeing.
I know that many of my fellow Yanks will resent this assumption, but let me gently remind you that our nation's espionage activities over the past decades have so thoroughly ruined our moral reputation that this reaction can hardly be surprising. Wake up, floks. When you send the CIA out to assassinate, topple governments and support thugs as often as we have, it's certainly not difficult to imagine our spooks stealing business secrets.
Also, many of you are getting a kick out of this "unknown" business, but this is just what they about an investigation when wrongdoing is suspected but nobody's certain who's doing it. When some of my stuff was stolen a few years ago, I reported it to the poilce and they initiated an investigation against "unknown". You can do the same thing in civil procedures. The purpose is simply to get a formal investigation going, so that you maybe find out who "unknown" is.
Think about it: a day is 86400 seconds. So that means that at worst, they're handling one hit every four seconds, and at best one hit about every.86 seconds.
That's assuming that the hit rate is uniform across the whole day. That's an unlikely state of affairs, even for a site that is of worldwide interest and is getting hits from every time zone. There are always slower hours of the day, and there are always spikes in the request rate.
But you're point is well taken if we narrow the time frame. If we assume that all the visits come in an 8 hour time window, then the best performance (at 100k hits/day) is a mean of about 3.5 hits per second. If they all come within 12 hours, then the best mean performance is 2.3 hits per second.
Now, I've gotten Apache servers to serve up hundreeds of pages per second on fast Pentium machines! If you're averaging less then 10 hits per second over a whole day, then you have severely misconfigured your server.
I submit that the Dell figures are completely worthless without more details about the benchmark. Were they serving static pages, CGIs, servlets, PHP scripts, mod_perl scripts, FastCGIs, what? Were backend applications and/or DB queries involved? How did they tune the server? Did they tune it at all? Did they use a caching proxy like Squid? Without this information, the benchmark results are little better than random numbers.
It's going to be very, very hard to wrench the Mac away from the culture of designers who are committed to it -- and I certainly don't see anything about Gnome or Linux that will make them move.
Graphic designers, Photoshop jocks, HTML developers, and so forth -- these are the people who have kept Apple alive through some of its worst periods. I work with a company full of them, and I can't see how a herd of wild horses or stampeding elephants could drag them away from their Macs.
As much as Linux, and Gnome in particular, have been progressing on the desktop, the Linux user interfaces are far and away too technical and unintuitive to get this crowd to switch. If they find themselves having to drop to a shell and command line just once, they'll run away screaming. User interfaces and high-quality graphics, not technical arcana, are what's essential to designers' daily work and user experience, and I think MacOS will have Linux beat in those fields for a long time to come.
This niche market may not be enough to keep the Mac's market share ahead of Linux, but it will continue to be enough to keep Apple from going under altogether.
Look at them yo-yo's, that's the way you do it
You be an exec in the industry
That ain't workin', that's the way you do it
Money for nothing, and checks for free
That ain't workin', that's the way you do it
Let me tell you, them guys ain't dumb
Maybe get a band wrapped around your finger
Maybe get a band trapped under your thumb
We got to exploit popular artists
Keep the rights and delay the release
We got to sign more indentured servants
We got to lower their royalties
That little maggot with the lawyers and the contracts
Yeah buddy, his deals are fair
That little maggot's got his own jet airplane
That little maggot he's a billionaire
We got to exploit popular artists
Keep the rights and delay the release
We got to sign more indentured servants
We got to lower their royalties
No need to learn to play the guitar
No need to learn to play them drums
Let the bands do it, then we'll take all their money
Man, what could be more fun?
Look at that, what's that? MP3 downloads?
We'll sue 'em and we'll squawk like we're chimpanzees
That ain't workin', that's the way you do it
Money for nothing, and checks for free
We got to exploit popular artists
Keep the rights and delay the release
We got to sign more indentured servants
We got to lower their royalties
That ain't workin', that's the way you do it
You be an exec in the industry
That ain't workin', that's the way you do it
Money for nothing, and checks for free
Gene Spafford's argument seems to proceed simply as a tautology from his definition of "trusted", if I've understood the summary correctly. By this definition, a system is "trusted" if and only if a formal specification and testing process exists, and the system satisfies the spec and passes the tests. Thus it's trivially true (if we accept the definition) that a system that doesn't satisfy these criteria isn't "trusted".
It is *not* true, however, that an Open Source system could never satisfy this definition. Set your formal specification and get your Open Source coders to work on fulfilling the spec. When they're done, then voila! A "trusted" Open Source system.
Alternatively, one could reject Spafford's definition of "trusted", as not matching the intuitive notion of trust. One could reasonably argue that "trust", in the common and intuitive sense, can only be realistically achieved by extensive peer review. I would furthermore argue that satisfying a formal spec is not enough for trust, because a spec might fail define a system that most of us would intuitively view as trustworthy.
If all he's saying is that all we need is a spec in order for a system to be "trusted", without saying what such a spec has to be like, then I say he's wrong; because a spec can specify any kind of untrustworthy foolhardiness you imagine.
To demonstrate this, I hereby give a formal specification of "trust": A system is "trusted" if and only if it crashes at least once for every six hours of operation. The formal test is: Run the system for sixty hours; if it crashes ten times or more, then it's "trusted". There you are, a formal spec and testing process. But hardly anyone could describe such a system as "trusted".
BTW, although I'm disagreeing with him, I remember Gene Spafford with great respect as a major driving force in the early days of Usenet, and the author of an O'Reilly book on security. I'm a bit dismayed that so many Slashdotters don't recognize him.
I have to comment once again on the deliberately poor use of grammar on Slashdot.
In view of your evidently limited, in particular US-centric knowledge of grammar, you have made a poor decision.
Why...why do so many people insist on mismatching plural verbs with singular nouns?
Probably because by doing so, they are speaking proper English within the dialect of their culture, and hence there is no "mismatch" at all. This is indeed ungrammatical in the US dialect, but not in the dialects of English spoken in most places in the world, including the UK, Australia, New Zealand and in Africa.
In these dialects, nouns denoting collectives, such as corporations, sports teams, committees, nations, rock bands, what have you, are paired with plural verbs, even if the nouns themselves exhibit a singular form. Thus they will say things like:
Holland have defeated Denmark.
Microsoft have lost the case.
The committee have approved the bill.
These sentences are ungrammatical in North America, where the verb would have to be singular ("has"). But they are grammatically correct almost everywhere else English is spoken.
The differences between "American" and "British" English are really not that extensive -- the pronunciation and spelling are famously different, and there are some idiosyncratic (albeit entertaining) differences in the vocabulary, such as in expressions for toilets or women's underwear. But there are very, very few genuine differences in the grammar. This one -- the number agreement of collective-denoting nouns -- is one of those very few differences, and by far the most noticeable.
I, too, have many pet peeves about language -- I recently complained on Slashdot about people writing "loose" when they mean "lose". But what I find much worse are people who make an overbearing post about something while getting the facts embarassingly wrong. The post to which I'm replying was an example of just that.
Many people here are assuming that the appeals process will last years and years. But the appeals don't have to last long at all, perhaps not more than another year -- it might even be all over by Christmas. Certainly, the government should do everything in its power to make that happen.
Remember that in a Sherman case, the government can ask to bypass the Court of Appeals and go straight to the Supreme Court. The idea is that breaking up a monopoly requires fast action without all of the delays of appeals, because the economy changes so quickly. Neither Microsoft nor the Court of Appeals can prevent the government from asking for this -- if the DOJ wants it, then it's up to the Supremes to decide whether to accept the task. They could say no and send the case back to the Court of Appeals, but in that case the government loses nothing for having asked.
Now IANAL, but here's how I figure it. The DOJ has a good case for asking for the fast track to the Supremes, because the software industry does indeed move very quickly, and the Feds can whip out dozens, maybe hundreds of M$ quotations in the court record saying exactly that. They've been emphasizing the fast-changing industry as a part of their defense, and now the DOJ can use their own words to get the fast track. So if they do ask, I'd be very surprised if the Supremes refuse.
The Court of Appeals has already indicated in earlier rulings that it may be more sympathetic to M$ than Judge Jackson, having overruled him on some key issues. Certainly M$ wants to head there; but the DOJ doesn't have to go there at all if it doesn't want to.
The current Supreme Court is relatively conservative and hence maybe sympathetic to big business, so the Feds may worry that they won't prevail there. But on the other hand, if the case is destined to end up in the Supreme Court some day anyway, then they might as well face that music now rather than later. Perhaps some justices will die or something if the case doesn't get there for a few years, but who knows if the replacements will be any more or less on M$'s side than the current justices are? No point in betting on that now; might as well just take your chances.
And after all, the current Court, despite its conservatism, does not appear especially beholden to industry in anti-trust cases. This Court is most passionate about matters of federalism and respecting the decisions of lower courts. They certainly won't overrule any of Judge Jackson's findings of fact, and these are particularly harsh for M$ (which is precisely why the Judge made his findings of fact so emphatic). Moreover, they are not likely IMO to overrule any of his findings of law unless there is a major, controversial and unclarified matter of the constitution or judicial procedure at stake. I don't know of any such issue in this case. For these reasons, I believe that the DOJ can win in the present Supreme Court.
M$ wants to delay and postpone as much as they can, since they'd rather have the Court of Appeals, who may be on their side, and they want to fight off a breakup for as long as they possibly can. But most of all, they want to wait out this November's elections. If George W. is elected, then they might get a sympathetic Attorney General who will stop the suit, or at least scale it back, for example by accepting M$'s proposed remedies rather than a breakup.
All the more reason for the DOJ to push ahead to the Supreme Court right away, before the election. The Court takes a break in the summer and begins its term in October. The DOJ should see to it that they have the M$ case on their docket when the term begins. If they do that and the Supremes accept the case, then the case cannot be stopped no matter who wins the presidential election. George W. Bush himself may end up with the job of presiding over M$'s breakup on orders from the Supreme Court, whether he likes it or not.
In fact, I can imagine that one of the reasons for Judge Jackson to press ahead with his decision so quickly is so that the DOJ has the time to do all of this. I can't imagine why the DOJ wouldn't try it. No wonder the M$ lawyers are pissed off.
So rather than years, we may very well have the final appeal before the Supreme Court in about three months; and after that, the Supremes can reach their decision any time they want to. They could rule in favor of the government within weeks, if they so desire. The Micro$oft monopoly may not survive to see the year 2001.
Wow, just the headline I posted after the Findings of Fact were published. %^)
This judge is a smart cookie and understands Microsoft all too well. It's absolutely great to see how clearly he understands the situation in spite of the massive confusion, FUD and propaganda everywhere (even on Slashdot o_O )
Right on. I am simply astonished at how clueful Judge Jackson has turned out to be. I had assumed the worst, and now I'm forced to entirely re-evaluate my expectations of judges when it comes to technology cases. It is possible for a judge to "get it", and Thomas Penfield Jackson is living proof.
It may never be possible, but I would just love it if Slashdot could get the Judge to answer questions in an "Ask the Judge anything" article. Come on, Taco, find a way to get him on.
This is really a side issue to much more important topic, but I've always felt very strongly about this: Sending any kind of legal communication over an insecure medium such as email is intolerable, and there is no reason at all for the receiver to acknowledge its existence. If you send an email, it may or may not arrive on the other end; how can you ever know that it hasn't fallen into the bit bucket? Only if the recipient sends a reply (and even then, you can't be sure if it was really from the recipient).
Moreover, how can you know that an email is really from somebody in someone's legal department? Just because they say so? How many Slashdotter's know how to forge an email so that it looks like it came from a M$ lawyer?
My advice is: Set up your email client so that it does not honor requests for receipts, at least not automatically; and if you receive a legal threat by email, delete it securely, using something like the PGP wipe feature, and forget about it. Of course, you might be tempted to save a copy, but if you're ever asked about that under oath, you'll have to admit you have it and produce it, or risk an obstruction charge. Proceed at your own risk.
(I suppose you are obstructing if you claim never to have received the mail, but if you're really careful about secure deletion, such a charge can never be proved.)
If your antagonists really want to sue you that badly, they'll get around to certified snail mail soon enough. But let 'em sweat it out waiting for a reply and wondering what the hell's taking so long.
To be sure, Slashdot's confrontation with M$ would have proceeded on the dead tree medium sooner or later, and the exchange of paper wouldn't have changed very much about the essential issues. But Roblimo could have bought himself a couple days to cool heads at Slashdot and talk to the lawyers, while the M$ lawyers would have been essentially idle, sitting expectantly in front of their Outlook clients and gradually losing their patience.
Loose as a goose (-1 Offtopic, -5 Spelling flame)
on
Laptop Lojack?
·
· Score: 2
>from the never-loose-it-again dept.
ARRRRGH!
From the pet peeve department:
"Loose" rhymes with "goose" and "noose" and means the opposite of "tight".
What we want here is "lose", which rhymes with "booze", "news" and "schmooze" and means the opposite of "find" or "win".
Sorry, but I see this accursed mistake all over the Internet and I ABSOLUTELY CAN'T STAND IT!
Re:"New"? It's been out since at least 1993!
on
The Mind of God
·
· Score: 2
The first sentence in the article has now been changed to read, "In the new paperback edition of his book,...", but from what I can tell from the ThinkGeek site, this still isn't right. The book is apparently still in the first edition from 1993, and the picture of the cover looks exactly like the book I've had all this time.
Forgive me, but I even checked the Boycotted Patent Abuser to confirm this. It appears to me that there has only ever been one edition, in paperback, published in 1993.
I hate to beat a dead horse, but why is Jon insisting on calling this book new?
"New"? It's been out since at least 1993!
on
The Mind of God
·
· Score: 5
In his new book,...
I've had this in paperback on my shelf for years now! The publication information says copyright 1992, first Touchstone edition 1993.
It's a fine book, and I really have nothing against a review that appears seven years after publication. But Jon, this is a too important detail to get so badly wrong.
She'll have to wear that "primitive bikini" outfit through the whole film, and won't have to say a word! Nova can't say anything, except maybe something like "bleeeggggghhh!", so I'm sure Britney can handle it.
This getting a bit off-topic, but I would like to comment on jamie's remarks about the German government and the way it deals with Holocaust denial and other forms of Nazi sympathy.
Actually, I tend to agree with jamie's point that censorship is not the way to deal with something like this. However, as an American who has lived in Germany for over ten years now, I've also come to understand Germans who are exasperated at Americans and others for the contradictory messages that they send about dealing with latter-day Nazis and other right-wing extremists in Germany.
For every rallying cry for freedom of speech such as jamie's, even in the face of the worst kind of speech, there is someone else in the world darkly warning that the Germans are a congenitally dangerous people who are constantly in danger of turning into Nazis again, and so they damn well better do anything, no matter how ruthless, to make sure it never happens again.
This message was communicated very strongly by the Allies after the war, and they institutionalized it in the German constitution and in their efforts at "de-Nazification". It's constitutional in Germany to ban political parties, strip citizens of their civil rights in certain very extreme cases, and possibly even censor Holocaust denial (I think the courts are still unsure about that), specifically because the Allies wanted Germans to do all those things to drive the Nazi mindset out of the culture. To this day, there are many people around the world who fully expect the Germans to keep on doing all of these things.
Americans often get frustrated at the feeling that Europeans will criticize us no matter what we do -- it seems like it's damned if you do, damned if you don't all the time. Many Germans' reaction to criticism such as jamie's is very similar. To be sure, one can't expect everybody in the world to have the same opinion about what to do, but I often wonder if someone like jamie realizes how controversial his suggested solution is around the world.
The Germans are very sensitive about their image in the rest of the world and are trying to the right thing. But they're just as uncertain as everyone else about what the right thing is.
Indiana nearly set Pi = 3.2 in 1897
on
Happy Pi Day!
·
· Score: 3
In 1897, the state of Indiana nearly passed a bill decreeing that Pi is equal to 3.2 (it also said that sqrt(2) = 10/7). The bill unanimously passed the state House of Representatives (on a vote of 67-0), and went from there to the Senate. First it was referred to the Committee on Temperance, apparently as a joke, and the committee recommended approval. Then there was a floor debate in the Senate, full of puns and ridicule, in which all of the Senators who spoke admitted their ignorance on the merits of the bill. Importantly, they didn't kill it because it was a mathematical falsehood, but because the Senators thought they shouldn't be writing a law about something like that.
There's a story about it on the urban legends site. Evidently, a crank mathematician named Dr. Edwin J. Goodwin M.D. "discovered" this new fact about Pi, and offered to let Indiana use it in their school textbooks without royalties if they passed the law. His state Representative bought into it and introduced the bill.
I wonder if Kansas has any plans these days concerning Pi?:-)
... the problems you describe with mod_perl have a pretty simple solution. You just use mod_perl as an application server and put a reverse proxy (like Squid or Apache + mod_proxy) in front of it to serve static requests.
Sure, that's the standard solution to the problem of oversized mod_perl-ified processes eating up memory, but it comes at a high price in mod_perl's performance. I've found that mod_perl with a proxy in front of it can be about 20% as fast (in terms of requests/second) as direct access to mod_perl.
"Naked" mod_perl, i.e. mod_perl without a proxy in front of it, is one of the fastest solutions around; but proxied mod_perl is so much slower that you might as well go to something like FastCGI and save all the administration effort that mod_perl requires.
The fashionable technologies for persistent server-side programming for the Apache server these days are mod_perl, PHP and Java servlets, but I've had very good experience with another one that doesn't seem to be so "hip": FastCGI. FastCGI is not the fastest of them all (for that, you need to program your own Apache module), but its robustness and maintainability, in addition to very good speed, make it one of the best choices of the lot.
Here are some of the advantages I've seen:
Low impact on the server. FastCGI processes run independently of the server; they communicate with the server via a protocol, although if you use one of the programmer's interfaces you never really have to worry about that. To the programmer, a FastCGI program looks very similar to a CGI program; except that it has all the advantages of persistence.
Since FastCGI processes are independent of the server, they are less likely to weigh the server down with a heavy processing load, and buggy FastCGI's are less likely to slow down or crash the server. If a FastCGI is going haywire, the problem can be diagnosed with the usual tools for analyzing the process behavior (like ps, top, Sun's proctool, etc). And FastCGI can be configured to adjust the number of running processes to fit the load.
In contrast, technologies like mod_perl or PHP, which are embedded in the server, place an extra load on the server itself. It increases their memory footprint (especially in the case of mod_perl), which can be very problematic when Apache forks extra servers to handle request spikes -- you run the risk of running out of memory. They can make the web servers start up more slowly, and if one of your programs has gone on the blink, it can adversely impact the servers themselves. And embedded programs are not as easy to debug as independent processes.
In the case of servlets, since they all run as threads within a JVM, then if one of them is buggy or slow, it's not easy to find out which one is causing the problem. Usually you just notice that your JVM has slowed down, deteriorating everything else; then you have to go about finding out which thread is responsible.
No commitment to a particular programming language. This takes away one of the most contentious debating points concerning mod_perl, PHP, Java servlets, and other technologies like mod_pyapache and the Apache API. Each of them requires a specific language, and hence a discussion of the various approaches often deteriorates into a language flamewar. More to the point, many programmers simply cannot use one paradigm or the other becuase they don't know its "proprietary" language very well. And once you've started, you're locked in; you may have to think twice about a hiring a perfectly good new programmer, because your candidate doesn't happen to be fluent in the language you've chosen.
None of these problems come up with FastCGI. You can write FastCGI processes in whatever language you like, as long as you honor the protocol. And there are re-usable FCGI interfaces for C, C++, Java, Perl, Python and TCL.
With Perl's CGI::Fast, the FCGI program can also run as conventional CGI or from the command line. Having just praised FCGI's language independence, I do have to mention this advantage of the Perl interface. It makes FastCGI processes much easier to debug than, say, a mod_perl handler.
I personally happen to like Perl a lot, and I very much like the idea of mod_perl. Programming to the Apache API with Perl is way cool, and so many Perl programmers fall all over themselves praising it as a panacea. But because of the memory impact on the server, I have found very difficult to implement mod_perl so that the server is stable and doesn't eat up all my RAM. It can be done, with a lot of effort on the part of the web server administrators, but it's certainly a lot harder than it is with FastCGI.
And for the record, I do recognize the strengths of the various other techniques that I've mentioned as well. They all deserve their status as highly respected technologies for server-side programming, but FastCGI ranks up there with them in quality and deserves more attention than it's been getting.
A naive reader of M$'s "correction" could be fooled into a rather negative view of GPL'd software, especially if it's used by the government. They make it sound as if you are obliged to GPL any software you developed if you used any GPL'd software to develop it. Say, for example, I work for the government and used emacs to edit a C program, and gcc to compile it. A naive reader of the M$ blurb might conclude that you have to release the C program that you developed under the GPL.
This spin might succeed at getting a lot of people turned off on open source software. Why, they ask, should programmers in business or government be required to share all of their work, no matter what it is? It might be nice to do so, but shouldn't they have the choice not to?
Of course that's not what the GPL requires -- you only have to share any changes you make on the GPL'd products themselves, not on anything you create using them; and the government is unlikely to get involved in projects like emacs, gcc or the Linux kernel, so the issue probably won't come up at all.
It's a clever bit of FUD on M$'s part, because this impression will have to be answered by open source advocates with another "correction", and the distinction is complex enough that the broad public may never get it.
I go to all that trouble installing SuSE on my laptop, and now he tells me! Dagnubbit, Miller, why didn't you say so a couple of weeks ago? Would have saved me an awful lot of trouble.
The article closes out with a musing about whether pioniers of the Internet like Tomlinson will go down in history with inventors like Morse, Marconi and Bell.
Now I frankly think that Tomlinson is not destined for many history books, and moreover that many of the ARPANET engineers will never become known as heroes the way Morse & co. are, but I think it was quite appropriate when the death of Jon Postel two years ago precipitated a wave of mourning throughout the Internet. To be sure, most Internet users never heard of him, not to mention the general public, but if you have any familiarity at all with the Internet's ascendancy, you'll know that Postel's contributions were crucial to its current success. Domain names, IP addressing, many of the basic TCP services such as chargen and echo, the Telnet protocol, FTP reply codes, the MIME standard -- Postel had a hand in developing numerous basic building blocks that now make up our everyday networking life.
Try searching for the author name Postel among the RFC's -- you get 232 hits. And I daresay that RFC authorship is a good deal more significant than authorship of a program like SENDMSG, since it's the open standards that made the Internet's success possible.
The Internet society has a page about him here.
"... and do that because we must make the impossible deadline, come hell or high water."
This is precisely the instruction that we recently received from a client. So in October and November, we pulled graveyard shifts and rattled up a gazillion lines of code to just get the features in, one way or another, buggy or not. More likely the former.
So now we have a bug list that runs to about five or six hundred bugs. Not too surprising, if you ask me, considering the size of the project and the insane rush to get all the coding done, but now all of a sudden they're hugely worried about quality, and have frozen all features until the bug list is significantly reduced. So they had to put off the deadline after all!
The cause of all these problems is the huge pressure to reduce time to market. You've got to get an edge on the other guy, and everybody's rushing ahead so frantically that you can only keep up by letting QA fall by the wayside. And the squeeze just keeps getting tigher and tighter, as if there's no limit that will ever be reached. But we've already reached it -- software quality has simply come up too short in too many products.
There is another way, you know, but too few vendors are willing to take the chance -- be a little later than the competition, but aggressively market your product as superior in quality. It might work, but who has enough confidence to try it?
Sure, I remember Gopher, and it was swell. I also pine for the days of HTML 2.0 -- bullet lists on gray backgrounds, you could download them in reasonable time on your 14.4k modem. A return to minimalism would be welcome in this age of high-bandwidth schlock.
But look, anytime someone publishes a "manifesto" to preserve or resurrect some technology, particularly an Internet technology, you know that their time is almost over for good. If you want to see Gopher come back, then bring it back by publishing information on Gopher that readers will want to see. These things stand or fall on the choices of all those Internet users out there, and if your beloved technology is really as good as you say, they'll come and get it. Just imploring everyone to use it will never be good enough. It's usually a sign that you're losing the argument.
Leaving this off the list is so extraordinary that I wonder if the author is, say, twenty years old, and has no perspective on history. ("History" meaning four years ago.)
The FDIV bug was front-page news, and had almost all of Usenet captivated for weeks. In fact, back in the bad old days of 1996, this was one of the first indications that the Internet could create enough public pressure to change the attitudes of a large corporation. Intel wanted to play down the whole thing, but hundreds of posters were exchanging information every day, analyzing the error, posting the inevitable jokes, expressing general outrage at Intel and discussing ways to bring them around.
Math professors posted scholarly analyses of the error, and provided links to Web pages with Mathematica graphs to illustrate where the calculations went wrong.
And even the non-technical newsgroups got into the act. talk.bizarre had a field day. Everywhere you looked, someone found a way to fit an Intel joke into their post, no matter what it was about.
Eventually, Andy Grove had to post a message of apology to the Intel newsgroups, announcing that Intel would reverse field and let buyers exchange their processors, no questions asked (originally, you had to justify your need for a new chip).
Man, those were the days. Usenet is dead, long live Usenet!
You're tempting me. Oh, you are tempting me
Here I am in the deepest pit of hell, slaving away on an impossible project that will drive my company to bankruptcy. We're on the verge of missing the next drop-dead milestone, and the customer is already talking to the legal department. When was the last day that I worked less than 16 hours? When did I last see my family? I hardly remember any more. All of my colleagues have assured me that they will resign as soon as it's over, and so will I.
As discretely as possible (because my boss might see me), I surf on over to Slashdot to give my tortured brain a moment of rest. Death March, it says! No kidding.
I'd write more, but THERE JUST ISN'T ANY TIME!
YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH!!!
As an American posting from Germany, let me just contribute two bits of information. The assumption is that Anglo-Saxons are conducting industrial espionage. This assumption is widely held (it's not just Ilka Schröder), and it's deeply resented.
I worked for a year at the Airbus airplane plant in Hamburg, and there are elaborate security mechanisms in place there. They said that they had already caught a couple of spies. Their only opponent, obviously, is Boeing.
I know that many of my fellow Yanks will resent this assumption, but let me gently remind you that our nation's espionage activities over the past decades have so thoroughly ruined our moral reputation that this reaction can hardly be surprising. Wake up, floks. When you send the CIA out to assassinate, topple governments and support thugs as often as we have, it's certainly not difficult to imagine our spooks stealing business secrets.
Also, many of you are getting a kick out of this "unknown" business, but this is just what they about an investigation when wrongdoing is suspected but nobody's certain who's doing it. When some of my stuff was stolen a few years ago, I reported it to the poilce and they initiated an investigation against "unknown". You can do the same thing in civil procedures. The purpose is simply to get a formal investigation going, so that you maybe find out who "unknown" is.
That's assuming that the hit rate is uniform across the whole day. That's an unlikely state of affairs, even for a site that is of worldwide interest and is getting hits from every time zone. There are always slower hours of the day, and there are always spikes in the request rate.
But you're point is well taken if we narrow the time frame. If we assume that all the visits come in an 8 hour time window, then the best performance (at 100k hits/day) is a mean of about 3.5 hits per second. If they all come within 12 hours, then the best mean performance is 2.3 hits per second.
Now, I've gotten Apache servers to serve up hundreeds of pages per second on fast Pentium machines! If you're averaging less then 10 hits per second over a whole day, then you have severely misconfigured your server.
I submit that the Dell figures are completely worthless without more details about the benchmark. Were they serving static pages, CGIs, servlets, PHP scripts, mod_perl scripts, FastCGIs, what? Were backend applications and/or DB queries involved? How did they tune the server? Did they tune it at all? Did they use a caching proxy like Squid? Without this information, the benchmark results are little better than random numbers.
It's going to be very, very hard to wrench the Mac away from the culture of designers who are committed to it -- and I certainly don't see anything about Gnome or Linux that will make them move.
Graphic designers, Photoshop jocks, HTML developers, and so forth -- these are the people who have kept Apple alive through some of its worst periods. I work with a company full of them, and I can't see how a herd of wild horses or stampeding elephants could drag them away from their Macs.
As much as Linux, and Gnome in particular, have been progressing on the desktop, the Linux user interfaces are far and away too technical and unintuitive to get this crowd to switch. If they find themselves having to drop to a shell and command line just once, they'll run away screaming. User interfaces and high-quality graphics, not technical arcana, are what's essential to designers' daily work and user experience, and I think MacOS will have Linux beat in those fields for a long time to come.
This niche market may not be enough to keep the Mac's market share ahead of Linux, but it will continue to be enough to keep Apple from going under altogether.
With apologies to Mark Knopfler ...
...
Look at them yo-yo's, that's the way you do it
You be an exec in the industry
That ain't workin', that's the way you do it
Money for nothing, and checks for free
That ain't workin', that's the way you do it
Let me tell you, them guys ain't dumb
Maybe get a band wrapped around your finger
Maybe get a band trapped under your thumb
We got to exploit popular artists
Keep the rights and delay the release
We got to sign more indentured servants
We got to lower their royalties
That little maggot with the lawyers and the contracts
Yeah buddy, his deals are fair
That little maggot's got his own jet airplane
That little maggot he's a billionaire
We got to exploit popular artists
Keep the rights and delay the release
We got to sign more indentured servants
We got to lower their royalties
No need to learn to play the guitar
No need to learn to play them drums
Let the bands do it, then we'll take all their money
Man, what could be more fun?
Look at that, what's that? MP3 downloads?
We'll sue 'em and we'll squawk like we're chimpanzees
That ain't workin', that's the way you do it
Money for nothing, and checks for free
We got to exploit popular artists
Keep the rights and delay the release
We got to sign more indentured servants
We got to lower their royalties
That ain't workin', that's the way you do it
You be an exec in the industry
That ain't workin', that's the way you do it
Money for nothing, and checks for free
I want my, I want my, I want my SUV
Gene Spafford's argument seems to proceed simply as a tautology from his definition of "trusted", if I've understood the summary correctly. By this definition, a system is "trusted" if and only if a formal specification and testing process exists, and the system satisfies the spec and passes the tests. Thus it's trivially true (if we accept the definition) that a system that doesn't satisfy these criteria isn't "trusted".
It is *not* true, however, that an Open Source system could never satisfy this definition. Set your formal specification and get your Open Source coders to work on fulfilling the spec. When they're done, then voila! A "trusted" Open Source system.
Alternatively, one could reject Spafford's definition of "trusted", as not matching the intuitive notion of trust. One could reasonably argue that "trust", in the common and intuitive sense, can only be realistically achieved by extensive peer review. I would furthermore argue that satisfying a formal spec is not enough for trust, because a spec might fail define a system that most of us would intuitively view as trustworthy.
If all he's saying is that all we need is a spec in order for a system to be "trusted", without saying what such a spec has to be like, then I say he's wrong; because a spec can specify any kind of untrustworthy foolhardiness you imagine.
To demonstrate this, I hereby give a formal specification of "trust": A system is "trusted" if and only if it crashes at least once for every six hours of operation. The formal test is: Run the system for sixty hours; if it crashes ten times or more, then it's "trusted". There you are, a formal spec and testing process. But hardly anyone could describe such a system as "trusted".
BTW, although I'm disagreeing with him, I remember Gene Spafford with great respect as a major driving force in the early days of Usenet, and the author of an O'Reilly book on security. I'm a bit dismayed that so many Slashdotters don't recognize him.
In view of your evidently limited, in particular US-centric knowledge of grammar, you have made a poor decision.
Why...why do so many people insist on mismatching plural verbs with singular nouns?
Probably because by doing so, they are speaking proper English within the dialect of their culture, and hence there is no "mismatch" at all. This is indeed ungrammatical in the US dialect, but not in the dialects of English spoken in most places in the world, including the UK, Australia, New Zealand and in Africa.
In these dialects, nouns denoting collectives, such as corporations, sports teams, committees, nations, rock bands, what have you, are paired with plural verbs, even if the nouns themselves exhibit a singular form. Thus they will say things like:
These sentences are ungrammatical in North America, where the verb would have to be singular ("has"). But they are grammatically correct almost everywhere else English is spoken.
The differences between "American" and "British" English are really not that extensive -- the pronunciation and spelling are famously different, and there are some idiosyncratic (albeit entertaining) differences in the vocabulary, such as in expressions for toilets or women's underwear. But there are very, very few genuine differences in the grammar. This one -- the number agreement of collective-denoting nouns -- is one of those very few differences, and by far the most noticeable.
I, too, have many pet peeves about language -- I recently complained on Slashdot about people writing "loose" when they mean "lose". But what I find much worse are people who make an overbearing post about something while getting the facts embarassingly wrong. The post to which I'm replying was an example of just that.
Many people here are assuming that the appeals process will last years and years. But the appeals don't have to last long at all, perhaps not more than another year -- it might even be all over by Christmas. Certainly, the government should do everything in its power to make that happen.
Remember that in a Sherman case, the government can ask to bypass the Court of Appeals and go straight to the Supreme Court. The idea is that breaking up a monopoly requires fast action without all of the delays of appeals, because the economy changes so quickly. Neither Microsoft nor the Court of Appeals can prevent the government from asking for this -- if the DOJ wants it, then it's up to the Supremes to decide whether to accept the task. They could say no and send the case back to the Court of Appeals, but in that case the government loses nothing for having asked.
Now IANAL, but here's how I figure it. The DOJ has a good case for asking for the fast track to the Supremes, because the software industry does indeed move very quickly, and the Feds can whip out dozens, maybe hundreds of M$ quotations in the court record saying exactly that. They've been emphasizing the fast-changing industry as a part of their defense, and now the DOJ can use their own words to get the fast track. So if they do ask, I'd be very surprised if the Supremes refuse.
The Court of Appeals has already indicated in earlier rulings that it may be more sympathetic to M$ than Judge Jackson, having overruled him on some key issues. Certainly M$ wants to head there; but the DOJ doesn't have to go there at all if it doesn't want to.
The current Supreme Court is relatively conservative and hence maybe sympathetic to big business, so the Feds may worry that they won't prevail there. But on the other hand, if the case is destined to end up in the Supreme Court some day anyway, then they might as well face that music now rather than later. Perhaps some justices will die or something if the case doesn't get there for a few years, but who knows if the replacements will be any more or less on M$'s side than the current justices are? No point in betting on that now; might as well just take your chances.
And after all, the current Court, despite its conservatism, does not appear especially beholden to industry in anti-trust cases. This Court is most passionate about matters of federalism and respecting the decisions of lower courts. They certainly won't overrule any of Judge Jackson's findings of fact, and these are particularly harsh for M$ (which is precisely why the Judge made his findings of fact so emphatic). Moreover, they are not likely IMO to overrule any of his findings of law unless there is a major, controversial and unclarified matter of the constitution or judicial procedure at stake. I don't know of any such issue in this case. For these reasons, I believe that the DOJ can win in the present Supreme Court.
M$ wants to delay and postpone as much as they can, since they'd rather have the Court of Appeals, who may be on their side, and they want to fight off a breakup for as long as they possibly can. But most of all, they want to wait out this November's elections. If George W. is elected, then they might get a sympathetic Attorney General who will stop the suit, or at least scale it back, for example by accepting M$'s proposed remedies rather than a breakup.
All the more reason for the DOJ to push ahead to the Supreme Court right away, before the election. The Court takes a break in the summer and begins its term in October. The DOJ should see to it that they have the M$ case on their docket when the term begins. If they do that and the Supremes accept the case, then the case cannot be stopped no matter who wins the presidential election. George W. Bush himself may end up with the job of presiding over M$'s breakup on orders from the Supreme Court, whether he likes it or not.
In fact, I can imagine that one of the reasons for Judge Jackson to press ahead with his decision so quickly is so that the DOJ has the time to do all of this. I can't imagine why the DOJ wouldn't try it. No wonder the M$ lawyers are pissed off.
So rather than years, we may very well have the final appeal before the Supreme Court in about three months; and after that, the Supremes can reach their decision any time they want to. They could rule in favor of the government within weeks, if they so desire. The Micro$oft monopoly may not survive to see the year 2001.
Jackson for President!
Wow, just the headline I posted after the Findings of Fact were published. %^)
This judge is a smart cookie and understands Microsoft all too well. It's absolutely great to see how clearly he understands the situation in spite of the massive confusion, FUD and propaganda everywhere (even on Slashdot o_O )
Right on. I am simply astonished at how clueful Judge Jackson has turned out to be. I had assumed the worst, and now I'm forced to entirely re-evaluate my expectations of judges when it comes to technology cases. It is possible for a judge to "get it", and Thomas Penfield Jackson is living proof.
It may never be possible, but I would just love it if Slashdot could get the Judge to answer questions in an "Ask the Judge anything" article. Come on, Taco, find a way to get him on.
This is really a side issue to much more important topic, but I've always felt very strongly about this: Sending any kind of legal communication over an insecure medium such as email is intolerable, and there is no reason at all for the receiver to acknowledge its existence. If you send an email, it may or may not arrive on the other end; how can you ever know that it hasn't fallen into the bit bucket? Only if the recipient sends a reply (and even then, you can't be sure if it was really from the recipient).
Moreover, how can you know that an email is really from somebody in someone's legal department? Just because they say so? How many Slashdotter's know how to forge an email so that it looks like it came from a M$ lawyer?
My advice is: Set up your email client so that it does not honor requests for receipts, at least not automatically; and if you receive a legal threat by email, delete it securely, using something like the PGP wipe feature, and forget about it. Of course, you might be tempted to save a copy, but if you're ever asked about that under oath, you'll have to admit you have it and produce it, or risk an obstruction charge. Proceed at your own risk.
(I suppose you are obstructing if you claim never to have received the mail, but if you're really careful about secure deletion, such a charge can never be proved.)
If your antagonists really want to sue you that badly, they'll get around to certified snail mail soon enough. But let 'em sweat it out waiting for a reply and wondering what the hell's taking so long.
To be sure, Slashdot's confrontation with M$ would have proceeded on the dead tree medium sooner or later, and the exchange of paper wouldn't have changed very much about the essential issues. But Roblimo could have bought himself a couple days to cool heads at Slashdot and talk to the lawyers, while the M$ lawyers would have been essentially idle, sitting expectantly in front of their Outlook clients and gradually losing their patience.
>from the never-loose-it-again dept.
ARRRRGH!
From the pet peeve department:
"Loose" rhymes with "goose" and "noose" and means the opposite of "tight".
What we want here is "lose", which rhymes with "booze", "news" and "schmooze" and means the opposite of "find" or "win".
Sorry, but I see this accursed mistake all over the Internet and I ABSOLUTELY CAN'T STAND IT!
The first sentence in the article has now been changed to read, "In the new paperback edition of his book, ...", but from what I can tell from the ThinkGeek site, this still isn't right. The book is apparently still in the first edition from 1993, and the picture of the cover looks exactly like the book I've had all this time.
Forgive me, but I even checked the Boycotted Patent Abuser to confirm this. It appears to me that there has only ever been one edition, in paperback, published in 1993.
I hate to beat a dead horse, but why is Jon insisting on calling this book new?
I've had this in paperback on my shelf for years now! The publication information says copyright 1992, first Touchstone edition 1993.
It's a fine book, and I really have nothing against a review that appears seven years after publication. But Jon, this is a too important detail to get so badly wrong.
She'll have to wear that "primitive bikini" outfit through the whole film, and won't have to say a word! Nova can't say anything, except maybe something like "bleeeggggghhh!", so I'm sure Britney can handle it.
This getting a bit off-topic, but I would like to comment on jamie's remarks about the German government and the way it deals with Holocaust denial and other forms of Nazi sympathy.
Actually, I tend to agree with jamie's point that censorship is not the way to deal with something like this. However, as an American who has lived in Germany for over ten years now, I've also come to understand Germans who are exasperated at Americans and others for the contradictory messages that they send about dealing with latter-day Nazis and other right-wing extremists in Germany.
For every rallying cry for freedom of speech such as jamie's, even in the face of the worst kind of speech, there is someone else in the world darkly warning that the Germans are a congenitally dangerous people who are constantly in danger of turning into Nazis again, and so they damn well better do anything, no matter how ruthless, to make sure it never happens again.
This message was communicated very strongly by the Allies after the war, and they institutionalized it in the German constitution and in their efforts at "de-Nazification". It's constitutional in Germany to ban political parties, strip citizens of their civil rights in certain very extreme cases, and possibly even censor Holocaust denial (I think the courts are still unsure about that), specifically because the Allies wanted Germans to do all those things to drive the Nazi mindset out of the culture. To this day, there are many people around the world who fully expect the Germans to keep on doing all of these things.
Americans often get frustrated at the feeling that Europeans will criticize us no matter what we do -- it seems like it's damned if you do, damned if you don't all the time. Many Germans' reaction to criticism such as jamie's is very similar. To be sure, one can't expect everybody in the world to have the same opinion about what to do, but I often wonder if someone like jamie realizes how controversial his suggested solution is around the world.
The Germans are very sensitive about their image in the rest of the world and are trying to the right thing. But they're just as uncertain as everyone else about what the right thing is.
In 1897, the state of Indiana nearly passed a bill decreeing that Pi is equal to 3.2 (it also said that sqrt(2) = 10/7). The bill unanimously passed the state House of Representatives (on a vote of 67-0), and went from there to the Senate. First it was referred to the Committee on Temperance, apparently as a joke, and the committee recommended approval. Then there was a floor debate in the Senate, full of puns and ridicule, in which all of the Senators who spoke admitted their ignorance on the merits of the bill. Importantly, they didn't kill it because it was a mathematical falsehood, but because the Senators thought they shouldn't be writing a law about something like that.
:-)
There's a story about it on the urban legends site. Evidently, a crank mathematician named Dr. Edwin J. Goodwin M.D. "discovered" this new fact about Pi, and offered to let Indiana use it in their school textbooks without royalties if they passed the law. His state Representative bought into it and introduced the bill.
I wonder if Kansas has any plans these days concerning Pi?
... the problems you describe with mod_perl have a pretty simple solution. You just use mod_perl as an application server and put a reverse proxy (like Squid or Apache + mod_proxy) in front of it to serve static requests.
Sure, that's the standard solution to the problem of oversized mod_perl-ified processes eating up memory, but it comes at a high price in mod_perl's performance. I've found that mod_perl with a proxy in front of it can be about 20% as fast (in terms of requests/second) as direct access to mod_perl.
"Naked" mod_perl, i.e. mod_perl without a proxy in front of it, is one of the fastest solutions around; but proxied mod_perl is so much slower that you might as well go to something like FastCGI and save all the administration effort that mod_perl requires.
Here are some of the advantages I've seen:
Since FastCGI processes are independent of the server, they are less likely to weigh the server down with a heavy processing load, and buggy FastCGI's are less likely to slow down or crash the server. If a FastCGI is going haywire, the problem can be diagnosed with the usual tools for analyzing the process behavior (like ps, top, Sun's proctool, etc). And FastCGI can be configured to adjust the number of running processes to fit the load.
In contrast, technologies like mod_perl or PHP, which are embedded in the server, place an extra load on the server itself. It increases their memory footprint (especially in the case of mod_perl), which can be very problematic when Apache forks extra servers to handle request spikes -- you run the risk of running out of memory. They can make the web servers start up more slowly, and if one of your programs has gone on the blink, it can adversely impact the servers themselves. And embedded programs are not as easy to debug as independent processes.
In the case of servlets, since they all run as threads within a JVM, then if one of them is buggy or slow, it's not easy to find out which one is causing the problem. Usually you just notice that your JVM has slowed down, deteriorating everything else; then you have to go about finding out which thread is responsible.
None of these problems come up with FastCGI. You can write FastCGI processes in whatever language you like, as long as you honor the protocol. And there are re-usable FCGI interfaces for C, C++, Java, Perl, Python and TCL.
I personally happen to like Perl a lot, and I very much like the idea of mod_perl. Programming to the Apache API with Perl is way cool, and so many Perl programmers fall all over themselves praising it as a panacea. But because of the memory impact on the server, I have found very difficult to implement mod_perl so that the server is stable and doesn't eat up all my RAM. It can be done, with a lot of effort on the part of the web server administrators, but it's certainly a lot harder than it is with FastCGI.
And for the record, I do recognize the strengths of the various other techniques that I've mentioned as well. They all deserve their status as highly respected technologies for server-side programming, but FastCGI ranks up there with them in quality and deserves more attention than it's been getting.