Slashdot Mirror

To expand on batkiwi's comment above, here's the Gang of Four entry in the Jargon File:

Gang of Four n.

(also abbreviated `GOF') [prob. a play on the `Gang Of Four' who briefly ran Communist China after the death of Mao] Describes either the authors or the book "Design Patterns: Elements of Reusable Object-Oriented Software" published in 1995 by Addison-Wesley (ISBN 0-201-63361-2). The authors forming the Gang Of Four are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. They are also sometimes referred to as `Gamma et. al.' The authors state at http://www.hillside.net/patterns/DPBook/GOF.html "Why are we ... called this? Who knows. Somehow the name just stuck." The term is also used to describe any of the design patterns that are used in the book, referring to the patterns within it as `Gang Of Four Patterns.'

Well, designing an algorithm for true randomness is impossible. An algorithm, by definition, must be deterministic, which means that if it doesn't take external input, it's not truly random (because either it will generate the same numbers over and over again or a series of pseudo-random numbers). If it takes external input, on the other hand, this must come from somewhere. You can't take another algorithm (see recursion), so it has to be something mechanical. QED.

Godwin's Law, Brin loses.

Reasons why your argument sucks:

1. It tends to rely on blocklists, many of which have demonstrated unfair practices in the past.

Weight the scores for each of the blocklist tests to 0. (SpamAssassin works out of the box for most people, obviously not for you; this is why we allow for local configs)

2. The more SpamAssassin is used, the more spammers will specifically avoid doing things SpamAssassin checks for.

Agreed. You can't really get around that. The spammers can use the same tools as us and customize their marketing to defeat our tools; so we write more tools, they defeat them, etc. We just need to be effective most of the time to make spam protection worthwhile... oh and minimize those false positives too ;)

3. It's a gigantic heap of perl, the Write-Only (tm) language. I hate the fact that every perl program demands I mess up the package manager on my system by blindly downloading a half-dozen new modules. And it's slow!

k, don't give me the ``perl is a slow language'' argument because I flat out don't buy it. Your package manager not being able to deal with perl modules is the fault of your package manager; hrm... I need Time::HiRes, so I apt-get install libtime-hires-perl. Seems to work for me.

4. Bogofilter [sourceforge.net] is better. duh.

And the only reason that I'm not arguing with you here is that (a) I haven't used Bogofilter and (b) it was written by ESR who freaking rocks my world :)

If SpamAssassin doesn't do it for you then don't use it. It seems to do a good job for most of us though.

Are you sure you're not confused about the meaning of a honeypot?

But sure, I'd use it, why not? But I'd probably try to block the ads.

always mount a scratch monkey

http://www.tuxedo.org/~esr/jargon/html/entry/Godwi n's-Law.html

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

I think that distinction goes to B1FF.

He's obviously a hacker (using the ESR definition of "hacker".) Overgeneralizing portions of the English language into "new" words like this is a longstanding hacker tradition.

See the "Overgeneralization" node in the Jargon File: http://tuxedo.org/~esr/jargon/jargon.html#Overgene ralization (The link works, but I don't know why Slashdot is inserting that extra space in the text.)

They need to get a PIV at 4.77Ghz and an 8088 at 4.77Mhz side by side. It'd make a neat statement.

Windows XP would still take about as long to boot on the 4.77 GHz machine as MS-DOS 2 would on the 8088.

Gates's law: The time taken to perform simple operations in mass-market software, measured in microprocessor clock cycles, will increase in subsequent versions of a software product at a rate roughly proportional to the increase in clocks per second of newer microprocessors. Thus, given a lack of funding for increasing hardware speed and a requirement to "keep up with the Joneses" dictated by changing proprietary file formats, the speed of software halves every 18 months.

It's spelled "jargon". As in the Jargon File.

I think its crazy, but there you have it. This is pretty much a plutocracy (you need money to have your voice heard a la "lobbiest", "analyst", etc), so I'm not sure what methods we can use to oppose these things.

Steve said that "Apple is the number one supplier of Unix worldwide. Bigger than Sun, bigger than Linux..." If Steve said it, it must be true. Other than the fact that Linux is NOT Unix, but merely a clone. And since when was Linux a ,uhm, company supplying UNIX??

I own a Mac too, (G4, 640 Megs memory 2x 18G SCSI, Radeon 8500) but let's face it, Mac OS X is nothing more than FreeBSD 4.4 (pretty outdated by my standards) running Aqua as a window manager. Oh and by the way, it has a crap-load of Open Source goodies rebranded to sound like they came straight from Cupertino.

I'll give Apple one thing: If you think Apple hardware is fscking expensive, try buying a new Sun workstation! I could put a good down payment on a car for that much!

So, the question I have for Apple is: If you want the "average" Windows user to switch platforms, how are you going to convince them to pony up 3x more than a PC with less than a third of the available software? Keep in mind that the average computer user likes to swap out hardware quite a bit instead of buying a new machine every 9 months.

Steve said himself that there are "over 1500 Mac OS X apps". Most of these are haxies or simply Linux software such as GCC or Samba that have been ported over. Or maybe the iApps that are so amazing. Obviously Photoshop wasn't the "killer app" that makes everbody want OS X... So, how about something useful that doesn't cost a kidney to own (Office X, cough, cough)

With all this in mind, I'm not the least bit surprised that Linux is outdoing the Mac. I am surprised that the margin between the two is so close. For one, I can build a box that outperforms even the newest dual 1.2 Gig G4s (Uh, people use more than just Photoshop, Apple. You also haven't benchmarked the Athlons, which beat the shit out of all but the fastest P4s...) and has the latest and greatest hardware for well under $1K. Also keep in mind that the average PC user doesn't throw his entire box away after seeing new product announcements just to have the latest and greatest. If it's that hard to get Motorola to build faster G4s, then you should look elsewhere. Add to that the fact that your typical Linux distro (I also ripped into Macslash.org for calling Mac OS X a "distro")has many thousands of apps and goodies and no DRM, spyware, or product activation bullshit like Windows, and I just plain fail to see why anybody would want to bother with Mac or Windows.

Steve, it's time to break out of the Reality Distortion Field(TM) and offer cheaper hardware to get better penetration in the Windows camp.

Bill, you can take your "Trusted Computing", DRM, WMP9, .NET, buying the U.S. government, BSA, incompatibilities, daily security "patches", Big Brother EULAs and shove them up your fat, money grubbing ass.

In the words of Chandler Bing: "Could I BE more sick of corporate bullshit?"

Ken's back door program is most definitely the most interesting hack ever devised, IMO. Read about it here.

At the bottom, ESR claims that he "has heard two separate reports that suggest that the crocked login did make it out of Bell Labs, notably to BBN, and that it enabled at least one late-night login across the network by someone using the login name `kt'."

With these considerations in mind, clearly simulating an old computer is a very backwards idea. bug-for-bug compatibility is not a positive effect.

Same as bug-compatible, with the additional implication that much tedious effort went into ensuring that each (known) bug was replicated.

Any file with the hide extension flag set and a known extension has that extension hidden in the Finder. When users edit the name of such a file, they edit only the user-visible portion. If they explicitly type in a known file name extension for the file, either the Finder warns them that what they're doing may change the type of the file (if they enter a different file name extension), or the Finder changes the state of the hide extension flag to show the extension (if they enter a new file name with the proper, currently hidden extension for the file). In all cases, the Finder allows users to make the changes if they wish. What users see in the Finder is what they typed when renaming the file, whether or not they included an extension.

Any file with the hide extension flag set and a known extension has that extension hidden in the Finder. When users edit the name of such a file, they edit only the user-visible portion. If they explicitly type in a known file name extension for the file, either the Finder warns them that what they're doing may change the type of the file (if they enter a different file name extension), or the Finder changes the state of the hide extension flag to show the extension (if they enter a new file name with the proper, currently hidden extension for the file). In all cases, the Finder allows users to make the changes if they wish. What users see in the Finder is what they typed when renaming the file, whether or not they included an extension.

Dude, it's already worse than you know.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

If I have time I'll write a formal HOWTO and maybe submit it to /. In the meantime, here's a synopsis:

You need a Linux machine with a static IP address. If you can't have a static IP I suppose you can play games with dynamic IP addresses to access the server. Get a DNS entry to make it easier to access.

Set up fetchmail . Fetchmail is a simple program (written by ESR) which downloads mail via POP or IMAP. You configure it with your mail server, username, and password, and it downloads mail to the local machine. Actually, it re-delivers your mail locally. Your remote email might be chris2912@earthlink.net, and your username on your Linux server might be ces; fetchmail delivers the mail it downloads to ces@localhost.

At this point, you can use pine or mutt to read your mail. By default, they read mail from your local spool. Note that your "inbox" is /var/spool/mail/username, but other mail folders are usually under your home directory. Configure pine or mutt to put your mail folders in ~/mail.

Install procmail. Procmail allows you to set up filters for handling mail. It will let you move mail to a folder based on sender (something like various mail client's rules) and more importantly, it will let you run SpamAssassin (or junkfilter, but I recommend SpamAssassin). Set up procmail to run SpamAssassin on each email, and then either delete the spam or move it to a certain folder. The SpamAssassin documentation is pretty clear on how to do this. Make sure procmail is configured to use the folders in ~/mail.

Install an IMAP server. I use the standard UW server; there are others. The UW server runs via [x]inetd. I recommend setting up the SSL support (imaps).

What IMAP does is allow you to access your email remotely, without downloading it like POP. Mail is kept on the server, in folders. Through an IMAP client, you "subscribe" to a certain set of folders; these are the only folders IMAP clients will see. You want to configure your IMAP clients to use ~/mail as your root folder; otherwise you will see any other folders in your home directory (IMAP isn't limited to email).

When you set up an IMAP client (Outlook will work, though Outlook 2000 has an annoying bug, always reporting "server dropped connection", I use Mozilla mail) you provide the IP address of your server, and your username and password on that server.

IMAP is strange about deleting. Many IMAP clients by default want to move deleted messages into a folder. That's okay if you want to do that, I prefer to actually delete them. Even if you actually delete a message, it is only marked as deleted; it's still there until you purge it. Pine asks if you want to purge messages when you leave a folder; other clients do similar things.

Finally, install a web email package. IMP is the best, but it can be very hard to set up. I resorted to another package called squirrelmail before I finally got IMP set up. Squirrelmail is perfectly fine. Configure the package to use IMAP, using localhost as the server.

That's the basic points. Email me at ceswiedler@mindspring.com if you want any further help.

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

The bogo-sort is such an algorithm.

I also have hung onto my ~1988 scientific calculator for dear life. The picture looked very familiar, but by chance I have it here at work, and it is a Radio Shack EC-4014. Unlike the poster's, it does have a few more extras: trig, fraction conversion, degree conversion, degree/rad/grad, statistics. During my years in college and grad school for chemistry, I have found all of the functions quite useful at one time or another, except maybe the random number generator (I can live with any mental bias when making up a number). The keys are pretty grimy and it has a chemical etch on the display, but I still prefer it over any other calculator. Besides the functionality, another nit I have against the newer calculators is that the solar panel is so weak! I always need to put them next to a light source just to turn it on and keep running.

When I was a TA for chemistry, I got a kick out of all the freshmen coming in with their enormous graphing calculators, who never were able to figure out basic stoichiometry or dilution problems. Ooooh, but they could punch in a mean parabola! Really, it's the same bloat problem that's commonplace in software (Cf. Zawinski's Law). The manufacturer can charge a higher price for the added features, and the users will still buy it because they never know when it may come in handy someday.

We'll no doubt here from the slide rule users at some point. And those worked in the dark!

Good. Ha Ha Only Serious is fine, but if you don't even mean it don't waste our time saying it.

Eric Raymond is running a project to create a bayesian spam filter written in C. I've been experimenting with it today and it looks pretty good. It's written as a client-server daemon that makes it *very* quick compared with a perl or other scripted approach. It's also pretty easy to integrate into any unix mail system.

Find out about it http://tuxedo.org/~esr/bogofilter/

The program, bogofilter, is stores its word lists using HP Judy dynamic arrays. Pretty interesting way of storing stuff and new to me anyway: http://sf.net/projects/judy

Any other Bayesian spam filters?

It is an odd situation when a flamer accuses another (non-flamer) of being what he himself (or, she herself, for the gender police), most demonstrably is. Does that make you a troll?

I will contradict your entire argument by quoting from Adam Smith, whom you apparently admire. This is from An Inquiry into the Nature and Causes of the Wealth of Nations:

It is not from the benevolence of the butcher the brewer, or the baker that we expect our dinner, but from their regard to their own interest. We address ourselves, not to their humanity, but to their self-love, and never talk to them of our own necessities, but of their advantages.

Substitute the words producer, director, and stakeholder for butcher, brewer, and baker, and it has the same weight. If you are really a stakeholder in New Line Cinema, you will already be paying close attention to this simple fact.

As for your distributiom model (A), remember that fencing stolen good is also a distribution model. Are you arguing that fencing stolen goods shouldn't be a crime?

The distribution under model (A)... appeal[s] to a select group of high bandwith, tech savy fans who have the money and will to partake in models (B) and (C) anyway.

I agree with you. However, I would argue that stealing when one has the ability to pay is far less excusable than stealing based on need. Is this tech savy crowd really so infested with geek fanboys and fangirls that waiting a few months is, for them, unbearable?

I don't believe that people like you exist. I know that this contradicts all of the best evidence, but I choose to believe (for sanity's sake) that you are a carefully constructed on-line persona whose purpose, though it presently eludes me, I will one day discover.

I am waiting for that day, though not with bated breath.

Perhaps they should rename themselves "Packard Dell."

Neil Gaiman won this year's Hugo for his novel American Gods. A much better choice than last year.

Atomic

If you're going to waste the bandwidth by being pedantic, please make sure that you're correcting an actual error.

YBHT. YHL. HAND.

What? No INTERCAL??

Heathens.

From The Jargon File...

grep /grep/ vi.

[from the qed/ed editor idiom g/re/p, where re stands for a regular expression, to Globally search for the Regular Expression and Print the lines containing matches to it, via Unix grep(1)] To rapidly scan a file or set of files looking for a particular string or pattern (when browsing through a large set of files, one may speak of `grepping around'). By extension, to look for something by pattern. "Grep the bulletin board for the system backup schedule, would you?" See also vgrep .

[It has been alleged that the source is from the title of a paper "A General Regular Expression Parser", but dmr confirms the g/re/p etymology -ESR]

From The Jargon File...

grep /grep/ vi.

[from the qed/ed editor idiom g/re/p, where re stands for a regular expression, to Globally search for the Regular Expression and Print the lines containing matches to it, via Unix grep(1)] To rapidly scan a file or set of files looking for a particular string or pattern (when browsing through a large set of files, one may speak of `grepping around'). By extension, to look for something by pattern. "Grep the bulletin board for the system backup schedule, would you?" See also vgrep .

[It has been alleged that the source is from the title of a paper "A General Regular Expression Parser", but dmr confirms the g/re/p etymology -ESR]

From The Jargon File...

grep /grep/ vi.

[from the qed/ed editor idiom g/re/p, where re stands for a regular expression, to Globally search for the Regular Expression and Print the lines containing matches to it, via Unix grep(1)] To rapidly scan a file or set of files looking for a particular string or pattern (when browsing through a large set of files, one may speak of `grepping around'). By extension, to look for something by pattern. "Grep the bulletin board for the system backup schedule, would you?" See also vgrep .

[It has been alleged that the source is from the title of a paper "A General Regular Expression Parser", but dmr confirms the g/re/p etymology -ESR]

. . . .the Slashdot Effect is just a virtual Flash Crowd. . .

Name (RedHat Package Manager)?

Name (RedHat Package Manager)?

"It is written in a language of which no other example is known to exist. It is an alphabetic script, but of an alphabet variously reckoned to have from nineteen to twenty-eight letters, none of which bear any relationship to any English or European letter system."

The alphabet looks rather obviously European-based. First off, much of what I can make out, looks vaguely reminiscent of letters like g, d, m, n, w, and a.

Secondly, that 3-like character near the end of the first line that sticks out like a sore thumb. Around the time this book was written, that character was a part of many northern European languages, including old English. I believe it stood for a /th/ sound, although I may be confusing that with the eth and thorn characters (other archaic northern European characters which still survive in Icelandic and a few other places).

The very first character (which you can see in several places throughout) also caught my eye. It looks like a slightly-modified version of the "feature key" you see on Apple keyboards, which is a symbol of Viking origin.

(doing my own research, imagine that!)

moore's law indeed slows as time marches forward. when he originally came up with it in the mid-1960's, it was speed doubles every 12 months. Today, it's roughly 18. Maybe this getting to 3.0 GHz from 2.0 in 18 months is evidence of Moore's law stretching itself to something longer than 18 months.

From the Jargon File (version 4.3.1) entry for sneakernet:

"Never underestimate the bandwidth of a station wagon filled with magtape, or a 747 filled with CD-ROMs."

From the Jargon File (version 4.3.1) entry for sneakernet:

"Never underestimate the bandwidth of a station wagon filled with magtape, or a 747 filled with CD-ROMs."

Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.

Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.

These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.

As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.

Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.

The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.

> > A = A XOR B
> > B = A XOR B
> > A = A XOR B
> > My data structures professor showed us that on
> > the first day of class. That got my respect.
>
> No wonder he's a teacher; only a teacher would
> gloat at a "clever" stupid trick like that; in a
> production environment, he'd be the first one to
> be shot, 'cause such kind of "clever" code is
> exactly why there are so many bugs in software
> nowadays, 'cause not all programmers will "get
> it".

Oh, malarky. The myth that teachers are those who cannot do will be dispelled the next time you try to teach something. It turns out to be quite a bit more difficult to explain a task you can do than to just do it, and you cannot explain something you cannot do.

However, I feel it important to note two things:

1) Nobody said that the teacher gloated. In fact, what the poster said was that *he* was impressed.

2) That's not particularly clever code. It's a neat idea, but the programmer which doesn't understand what that does on sight is not worth their paycheck.

That really reads like you read the comment from TPOP or a Scott Meyers book (actually, it matches my vague recollection of a Kernighan quote almost verbatim; there's a reason Ad Verecundiam is a fallacy, as it recalls the user's lack of comprehension; see Appendix A, first Koan, as regards Knight and the Lisp Machine.)

Whereas I am in agreement with the general sentiment that solid code which lacks the 5% performance boost for total obfuscation is a Good Thing, there is no question in my mind that the above is a simple, obvious, useful thing. Logic operations are usually the fastest operations on a chip, and I've yet to see a CPU that would complete three copies any faster than three logic ops; moreover, this saves on temporary variable space, which in turn saves time on allocation, etc.

The idea that the above is the source of bugs, rather than the failure to properly utilize the defense mechanisms of choice (things like data hiding, interfaces, and so forth), failure to sufficiently plan, test, and isolate code, and so forth is rankling to me. That's an ideal candidate for an inline swap function, and if you can't tell what a swap function with that code inside does, you really just shouldn't be a programmer.

And if you're not making that an inline function, you probably shouldn't be a C programmer. :)

Why would anyone dig around in the trashcans of a tech company? It's not like they'd find anything worthwhile.

There's a fine line between doing what you like and liking what you do.

How many professional sports players do you think don't enjoy playing a friendly game at the park with their friends when they're not "at work"? Some people love the game, some people just play the game. The same principle applies just about everywhere.

To a real hacker, programming isn't about writing code, it's about solving problems. And when solving problems is your passion, chances are you probably do it at home too.

When my day's work is done, I work on my car, I build R/C airplanes, I tweak my wirless networks I solder things on to my computer, and yes, I write programs. And somewhere in there I have an exciting social life too.

I like building things, and I love learning. Writing code, reading manuals; It's all a means to an end.

If you come across someone who enjoys writing code when he's not getting paid for it, chances are you're dealing with more than just a technician. This is the stuff that hackers are made of.

Now the question is, do you want a hacker working for you? Hackers can be tough to work with if you don't provide challenging projects, and absolutely impossible if you give them secretary-style assignments. But if you have difficult problems to solve, they can be invaluable.

Use bogofilter - it uses Beyesian statistics to filter spam it's it very good. See also A plan for SPAM by Paul Graham.

in the article, it says they're also gonna set up a bunch of honeypots that act as P2P nodes and appear to be hosting Billboard 100 mp3 files. In reality, those mp3 files are spoofed, and are not the actual songs.

They're gonna use that pot to see who's accessing their network, and if the RIAA should cross the line with that pot, the accessing IP gets blacklisted.

Unfortunately, the loophole is that the RIAA can keep generating IP's out the wazoo, creating a whack-a-mole type of situation.

Leto