Slashdot Mirror

Your Mama writes "Hoping to insure that the nation's spies have the latest information technology in the rapidly changing Internet age, the Central Intelligence Agency has established a venture capital company to nurture high-tech companies..." The NY Times has the story. The reference to Major Boothryod alone makes it worthwhile to get your free NYT registration if you don't already have one. Isn't that right, Mr. Bond?

kris writes "The german Telepolis magazine from Heise put up a small article about Kris Pister and Randy Katz creating small laser-driven wireless communicating swarm-computing nano-devices called MEMS. This is right out of a Neal Stevenson novel, The Diamond Age. The article is in english language. " I wish there's was more details to this article-if you find more, please post below. Update: 09/08 12:15 by H :Check out New Scientist for more information too.

Matthew N. Dodd was the first to write with the news that UC-Berkeley has changed the *BSD license. Effective immediatly, the 3rd clause, that which requires acknowledgement of UCB in all advertising is null and void. Click below to read the letter from UCB.

July 22, 1999

To All Licensees, Distributors of Any Version of BSD:

As you know, certain of the Berkeley Software Distribution ("BSD") source code files require that further distributions of products containing all or portions of the software, acknowledge within their advertising materials that such products contain software developed by UC Berkeley and its contributors.

Specifically, the provision reads:

      * 3. All advertising materials mentioning features or use of this software
      *    must display the following acknowledgement:
      *    This product includes software developed by the University of
      *    California, Berkeley and its contributors.

Effective immediately, licensees and distributors are no longer required to include the acknowledgement within advertising materials. Accordingly, the foregoing paragraph of those BSD Unix files containing it is hereby deleted in its entirety.

William Hoskins
Director, Office of Technology Licensing
University of California, Berkeley "

Matt Welsh has written in to talk a bit about the future of a project that he is very familiar with. The LDP ^[?] has been essential to help newbies (and even experts) learn what they need on their quest to become gurus. Hit the link below to read what Matt has to say about where the project ought to head. The following was written by Matt Welsh , co founder of the LDP Thoughts on the Linux Documentation Project In the last few months, the Linux Documentation Project has been in a bit of a rough spot, and it seems that things have not been moving along as smoothly as they were for the last 5 years. I have seen the latest "LDP Proposal" on the Open Source Writer's Group website, and I have a few thoughts on the current state of the LDP and what should be done to fix it.

As the original co-founder and coordinator of the LDP, I did a lot of work to make the project a popular source of Linux documentation. I started the LDP website, moderated the newsgroups, ran the mailing lists, acted as the liason between LDP writers and CD-ROM vendors and paper publishers. So I'd like to share my thoughts about what the LDP needs to get back on track.

In a nutshell, my approach would be minimalistic. I have always found that when organizing a group of volunteers on the Internet, doing less is always better than doing more.

Here's what I mean: The LDP is primarily a vehicle for Linux enthusiasts and developers to share their knowledge about the system with other Linux users. People are motivated to contribute to the LDP because they know that by having their docs on the LDP website, and on many CD-ROM disrtibutions, and even in printed books, that many Linux users are likely to read what they have written. This is much better than burying the docs on a website somewhere and relying on a search engine. The LDP is the de facto standard place for people to go to find out about Linux -- first.

As such, it is *vital* that it is as easy as possible for people to contribute to the LDP. Participation in complex standards processes, voting organizations, or high-traffic mailing lists should never be a requirement. Likewise, the tools used to write LDP docs should be easy to use, widely-available, free, and well-supported.

Ideally, we should allow people to write LDP docs in any format they wish -- but I have found that this makes it quite difficult for the LDP maintainers to publish the docs in a common format. My compromise was to always allow people to contribute docs in plain ASCII, but the preferred tool was Linuxdoc-SGML (now SGML-Tools). SGML-Tools is very easy to use and automatically generates HTML, ASCII, TeX, DVI, PostScript, and texinfo from a single source file. Also, it works with any text editor. Any system which imposes additional responsibilities on authors makes the barrier of entry too high, and people will be less likely to contribute.

Another important aspect of the LDP is that it is vendor-neutral and run by volunteers. For the LDP to be a mouthpiece of a large (or small) Linux distributor or other company would defeat its purpose. I am not suggesting that for The Puffin Group to "take over" the management of the LDP would be a bad thing -- but it is important to make it clear that the LDP is open to contribution by anyone, and is not a closed, privately-run organization motivated by corporate profit concerns. Otherwise, the LDP loses its identity as an open organization which exists to serve the Linux community as a whole.

My strong conviction is that the LDP exists for only two purposes: First, to provide widely-distributed, online publication of Linux documentation (through the website, USENET, and other means). This frees authors from having to concern themselves with making docs available: they simply send the materials to the LDP maintainer and the rest is taken care of. The second purpose is to act as liason between authors and organizations which wish to publish LDP materials on CD-ROM or in print. It is important that LDP authors are represented to publishers in this way -- publishers rarely want to deal with authors individually, but would rather deal with the LDP "as a whole".

There are some pitfalls which I think the LDP needs to be careful of when moving forward:

1. Too much bureaucracy. Turning the LDP into a complex organization with offices, roles, voting procedures, and standards does nothing to further the goal of Linux documentation; all it really does is feed the egoes of the people involved. No other successful Linux project requires this level of bueaucratic organization. Keeping things informal makes it easier to move forward and to be flexible in light of change. I have seen too many Linux projects die (or take too long to get any useful work done) because of political infighting based on organizational procedures rather than meaningful technical details.
2. Changing tools. Unless there is a compelling, immediate, and inevitable reason why some new documentation format is required, don't waste your time trying to convert all of the docs and educate all of the authors about how to use the new tools. Adopting Linuxdoc-SGML was hard enough in the beginning; it only happened because it was so easy to use and we provided a lot of examples and documentation for the tools themselves. I haven't seen any compelling reasons why DocBook (or any other tool) will make Linux documentation any better. At the very least, accept LDP docs in *both* Linuxdoc-SGML and DocBook indefinitely. Forcing authors to adopt a new tool is the best way to scare people off. The LDP isn't about tools; it's about documentation. Don't let the tools weenies take over.
3. Too much -- or too little -- leadership. Leadership in the LDP is really an oxymoron, because the group doesn't need any real leadership. All it needs is someone to work hard maintaining the documentation archives, running mailing lists, posting to USENET, and working with the various paper and electronic publishers who want to redistribute LDP materials. What it also needs is someone who is communicative, open-minded, and clear-headed enough to direct the group's energy towards productive means, rather than endless political discussions. What the LDP doesn't mean is a group of people to overlay a complex organizational structure over something which is essentially a loose-knit collection of enthusiastic writers.
4. Using the wrong copyright. My feeling is that the LDP should adopt a *class* a copyright licenses which it will accept for LDP docs, similar to the Open Source Definition. This will allow individuals to select their own preferred copyright license for LDP materials, within a certain range of allowable licenses. Forcing authors to adopt a single license simply means you will have fewer contributors. Some people distrust the GPL, others distrust the BSD license, and still others prefer to craft their own. You need to be flexible enough to accept a range of copyrights from authors.
5. Too much planning. Setting out a roadmap for a collection of documents that need to be written is the best way to ensure that nobody will ever write them. Writing docs gets done in bits and spurts, and can look like a pretty big job if someone draws up a big outline for a mega-tome which the LDP plans to work on. The HOWTO project was so successful because people could write as much -- or as little -- as they wanted to on a topic of particular interest to them. So what if it's not organized into a coherent whole? With the aid of indices and search engines, people will eventually find what they're looking for. Also remember that ownership of LDP documents is a lease: if someone fails to maintain or update their document over time, it's perfectly acceptable for someone else to revise it or rewrite it altogether. This happened several times with documents that I originally authored.

In short, I think that the only thing the LDP needs to do to get on track is to retain the essential structure it has had for the last five years. Making things any more complicated will only raise the barrier of entry to new authors, which will eventually cause the project to die out. The LDP worked so well because it took almost no effort for someone to contribute: all they had to do was e-mail me the source for a new HOWTO. As soon as you become embroiled in discussions about new tools and bureaucracies, the LDP stops getting useful work done and starts becoming "yet another overburdened Linux project". My advice is to keep it simple.

I appreciate any comments.
Thanks,
Matt Welsh, mdw@cs.berkeley.edu

Matt Welsh has written in to talk a bit about the future of a project that he is very familiar with. The LDP ^[?] has been essential to help newbies (and even experts) learn what they need on their quest to become gurus. Hit the link below to read what Matt has to say about where the project ought to head. The following was written by Matt Welsh , co founder of the LDP Thoughts on the Linux Documentation Project In the last few months, the Linux Documentation Project has been in a bit of a rough spot, and it seems that things have not been moving along as smoothly as they were for the last 5 years. I have seen the latest "LDP Proposal" on the Open Source Writer's Group website, and I have a few thoughts on the current state of the LDP and what should be done to fix it.

As the original co-founder and coordinator of the LDP, I did a lot of work to make the project a popular source of Linux documentation. I started the LDP website, moderated the newsgroups, ran the mailing lists, acted as the liason between LDP writers and CD-ROM vendors and paper publishers. So I'd like to share my thoughts about what the LDP needs to get back on track.

In a nutshell, my approach would be minimalistic. I have always found that when organizing a group of volunteers on the Internet, doing less is always better than doing more.

Here's what I mean: The LDP is primarily a vehicle for Linux enthusiasts and developers to share their knowledge about the system with other Linux users. People are motivated to contribute to the LDP because they know that by having their docs on the LDP website, and on many CD-ROM disrtibutions, and even in printed books, that many Linux users are likely to read what they have written. This is much better than burying the docs on a website somewhere and relying on a search engine. The LDP is the de facto standard place for people to go to find out about Linux -- first.

As such, it is *vital* that it is as easy as possible for people to contribute to the LDP. Participation in complex standards processes, voting organizations, or high-traffic mailing lists should never be a requirement. Likewise, the tools used to write LDP docs should be easy to use, widely-available, free, and well-supported.

Ideally, we should allow people to write LDP docs in any format they wish -- but I have found that this makes it quite difficult for the LDP maintainers to publish the docs in a common format. My compromise was to always allow people to contribute docs in plain ASCII, but the preferred tool was Linuxdoc-SGML (now SGML-Tools). SGML-Tools is very easy to use and automatically generates HTML, ASCII, TeX, DVI, PostScript, and texinfo from a single source file. Also, it works with any text editor. Any system which imposes additional responsibilities on authors makes the barrier of entry too high, and people will be less likely to contribute.

Another important aspect of the LDP is that it is vendor-neutral and run by volunteers. For the LDP to be a mouthpiece of a large (or small) Linux distributor or other company would defeat its purpose. I am not suggesting that for The Puffin Group to "take over" the management of the LDP would be a bad thing -- but it is important to make it clear that the LDP is open to contribution by anyone, and is not a closed, privately-run organization motivated by corporate profit concerns. Otherwise, the LDP loses its identity as an open organization which exists to serve the Linux community as a whole.

My strong conviction is that the LDP exists for only two purposes: First, to provide widely-distributed, online publication of Linux documentation (through the website, USENET, and other means). This frees authors from having to concern themselves with making docs available: they simply send the materials to the LDP maintainer and the rest is taken care of. The second purpose is to act as liason between authors and organizations which wish to publish LDP materials on CD-ROM or in print. It is important that LDP authors are represented to publishers in this way -- publishers rarely want to deal with authors individually, but would rather deal with the LDP "as a whole".

There are some pitfalls which I think the LDP needs to be careful of when moving forward:

1. Too much bureaucracy. Turning the LDP into a complex organization with offices, roles, voting procedures, and standards does nothing to further the goal of Linux documentation; all it really does is feed the egoes of the people involved. No other successful Linux project requires this level of bueaucratic organization. Keeping things informal makes it easier to move forward and to be flexible in light of change. I have seen too many Linux projects die (or take too long to get any useful work done) because of political infighting based on organizational procedures rather than meaningful technical details.
2. Changing tools. Unless there is a compelling, immediate, and inevitable reason why some new documentation format is required, don't waste your time trying to convert all of the docs and educate all of the authors about how to use the new tools. Adopting Linuxdoc-SGML was hard enough in the beginning; it only happened because it was so easy to use and we provided a lot of examples and documentation for the tools themselves. I haven't seen any compelling reasons why DocBook (or any other tool) will make Linux documentation any better. At the very least, accept LDP docs in *both* Linuxdoc-SGML and DocBook indefinitely. Forcing authors to adopt a new tool is the best way to scare people off. The LDP isn't about tools; it's about documentation. Don't let the tools weenies take over.
3. Too much -- or too little -- leadership. Leadership in the LDP is really an oxymoron, because the group doesn't need any real leadership. All it needs is someone to work hard maintaining the documentation archives, running mailing lists, posting to USENET, and working with the various paper and electronic publishers who want to redistribute LDP materials. What it also needs is someone who is communicative, open-minded, and clear-headed enough to direct the group's energy towards productive means, rather than endless political discussions. What the LDP doesn't mean is a group of people to overlay a complex organizational structure over something which is essentially a loose-knit collection of enthusiastic writers.
4. Using the wrong copyright. My feeling is that the LDP should adopt a *class* a copyright licenses which it will accept for LDP docs, similar to the Open Source Definition. This will allow individuals to select their own preferred copyright license for LDP materials, within a certain range of allowable licenses. Forcing authors to adopt a single license simply means you will have fewer contributors. Some people distrust the GPL, others distrust the BSD license, and still others prefer to craft their own. You need to be flexible enough to accept a range of copyrights from authors.
5. Too much planning. Setting out a roadmap for a collection of documents that need to be written is the best way to ensure that nobody will ever write them. Writing docs gets done in bits and spurts, and can look like a pretty big job if someone draws up a big outline for a mega-tome which the LDP plans to work on. The HOWTO project was so successful because people could write as much -- or as little -- as they wanted to on a topic of particular interest to them. So what if it's not organized into a coherent whole? With the aid of indices and search engines, people will eventually find what they're looking for. Also remember that ownership of LDP documents is a lease: if someone fails to maintain or update their document over time, it's perfectly acceptable for someone else to revise it or rewrite it altogether. This happened several times with documents that I originally authored.

In short, I think that the only thing the LDP needs to do to get on track is to retain the essential structure it has had for the last five years. Making things any more complicated will only raise the barrier of entry to new authors, which will eventually cause the project to die out. The LDP worked so well because it took almost no effort for someone to contribute: all they had to do was e-mail me the source for a new HOWTO. As soon as you become embroiled in discussions about new tools and bureaucracies, the LDP stops getting useful work done and starts becoming "yet another overburdened Linux project". My advice is to keep it simple.

I appreciate any comments.
Thanks,
Matt Welsh, mdw@cs.berkeley.edu

Chris L. Mason writes "The Seti@HOME website appears to have been cracked. The front page has been replaced by a picture of ALF (from the really bad comedy.) However, the perpetrators have been somewhat polite about it. A comment in the new html tells where the original page has been backed up. " Might be fixed by the time you read this, but it really happened. The story was submitted by a number of slashdot readers almost immediately. Thanks.

John Lazzaro writes "Found this linked from Dave Winers site, an analysis that puts numbers behind the oft quoted "Linux + Apache will saturate any reasonable Internet link given static pages" It basically assumes the mindcraft tests are accurate, and then tells you what it means. Most interesting is the comments about MSs online tech support, the hardware they use, the results of the benchmarks, and the fact that static content is practically irrelevant.

Derek Pomery writes "ABCnews has done a nice special report on the SETI project, the Drake equation, and the recent successes of Seti@home. Will this mean another spike in Seti@home downloads? "

abh writes "The SETI@home project is now sending new (fresh) work units, after having spent a few weeks in a rut sending the same 2 days worth of observations repeatedly. Read the announcement " As well, we were sent word from a reader that we've lost the #1 position at RC5. Head over and sign up!

Mr. Feely asks: "As an author of free software for the Palm Pilot, I've found it helpful to look at the other free Pilot software out there for ideas and code. However, I've found most that free software just by browsing around; as far as I can tell there doesn't seem to be any central index of free software (and free software resources) for the Pilot. Does such a thing exist? If not, is there sufficient interest to create it?"

Rowag writes "Team Slashdot leads all the groups in SETI@Home data evaluation, with over 500 members and more than 6000 result packets chewed up so far. If it helps your team spirit, that's more than 2x the amount from 'Microsoft'. Those of you already signed up, let's keep those packets coming! For those that missed it before, if you've got clock cycles to spare, check it out! " I hear there is is still a split and a redundant Slashdot.org team- I suggest we just make this one official so we can get more of a lead...

Rowag writes "Team Slashdot leads all the groups in SETI@Home data evaluation, with over 500 members and more than 6000 result packets chewed up so far. If it helps your team spirit, that's more than 2x the amount from 'Microsoft'. Those of you already signed up, let's keep those packets coming! For those that missed it before, if you've got clock cycles to spare, check it out! " I hear there is is still a split and a redundant Slashdot.org team- I suggest we just make this one official so we can get more of a lead...

Rowag writes "Team Slashdot leads all the groups in SETI@Home data evaluation, with over 500 members and more than 6000 result packets chewed up so far. If it helps your team spirit, that's more than 2x the amount from 'Microsoft'. Those of you already signed up, let's keep those packets coming! For those that missed it before, if you've got clock cycles to spare, check it out! " I hear there is is still a split and a redundant Slashdot.org team- I suggest we just make this one official so we can get more of a lead...

Madoc writes "Was just over at Seti@Home's site, and saw that they've introduced teams now! There are 2 Slashdot teams, we should probably standardize on one: Slashdot.org and Team Slashdot " I vote for Team Slashdot. Go seek out new intelligence if this rocks your boat better than cracking DES keys.

Madoc writes "Was just over at Seti@Home's site, and saw that they've introduced teams now! There are 2 Slashdot teams, we should probably standardize on one: Slashdot.org and Team Slashdot " I vote for Team Slashdot. Go seek out new intelligence if this rocks your boat better than cracking DES keys.

Madoc writes "Was just over at Seti@Home's site, and saw that they've introduced teams now! There are 2 Slashdot teams, we should probably standardize on one: Slashdot.org and Team Slashdot " I vote for Team Slashdot. Go seek out new intelligence if this rocks your boat better than cracking DES keys.

Everyone, their brother, mother and dog wrote to point us over to SETI@Home v1.0. Taking a note from the distributed playback, they are giving clients to use the spare cycles on your machine - check out more information, if you like.

Lazzaro writes "Red Herring has an interview with the VC Firm that's funding Cygnus, the last paragraph quotes the VC as listing Cygnus along with a few other companies in their portfolio, and saying "most of these companies will go public in the next six months"." There definitely will be a wave of open source IPOs in the next year. The questions are who? (Red Hat and Cygnus are prime candidates despite the fact that neither is saying anything) and others like VA who are up front that going public is their future. And the other question is when.

Lazzaro wrote in with the most exciting thing I've seen all day: A TechWeb article about VA (Research) buying Linux Hardware Solutions and mandrake's company, Enlightened Solutions. It goes on to say VA will regroup into three separate groups: an apparently RHAD-like development division, a web unit for Linux.com, and a systems group.

Matt Welsh sent us a link to a Salon story on Why Linux Needs Help. It features a lot of truth, and poses the simple question, can free software geeks write software for dumb users? Has a spiffy penguin graphic and a lot of good points (most of which aren't new to us, but they are well written).

jsparkes asks: "I haven't been able to find definitive information on mounting FAT32 filesystems in linux. It seems like it was implemented by Gordon Chaffee, who has this Fat32 homepage. It seems that it was added in 2.0.34 and should also be in 2.2.X. Does it work? Is just like an ext2 fs, or are there limitations? I'd like to dual boot linux and win98, but if I can't use my large FAT32 partitions, it would be pointless. (I have a 10G win98 drive, and will use a 1.2G for linux..)"

Benny_Eggs writes "It's not the pretty screensaver version, but a SETI@HOME client for Linux is now available." For those of you unfamiliar with the project, Seti@Home is like Distributed.net, except instead of brute force encryption cracking, it searches radio signal noise looking for signs of intelligence.

nickm writes "Seth David Schoen of CalLUG fame has written an essay entitled The APSL and Export Controls. This goes beyond patent craziness and nit-picking about legal details but rather shows a direct violation of the OSD in that the APSL adds a bit of US law to the license (adding additional burdens for those outside the US). "

Matt Welsh (who is probably not coincidentally program chair...) wrote in with a call for papers for the upcoming O'Reilly Linux Conference. It looks like a cool conference, almost a Linux Expo of the west (in August): two days of tutorials, followed by two days of a multi-track conference. They also will have evening "breakaway sessions" for special interest groups (sorta like BOFs, it seems). I actually may submit a paper...

Greg Roelofs writes "Graphics developers (yo, GIMP folks!) will be mildly amused to know that the PNG Development Group has released version 1.1 of the Portable Network Graphics specification. It includes a significantly rewritten section on gamma correction, a couple of new chunks for color correction, and some little stuff relating to suggested palettes, alpha-channel processing, etc. A complete pseudo-context-diff is available. Note also that ISO/IEC standardization is underway, and the PNG home page has even been spiffed up a tiny bit. Whoa. "

Bob Fisher writes "Bob Cringely's (PBS Online column briefly summarizes the contents of the Microsoft Halloween document, and critiques the Linux community for its response to it. His message (borrowing from the Nemsis air racing team) -- "Chase the dream, not the competition." "

Russ Magee was the first of many of you to write in about Robert Cringely's analysis of the Halloween I document. He thinks the OpenSource community has no cause for concern, and he reminds us to stay focussed on Linux, not Microsoft. Karsten M. Self wrote "The article Art of War by Varian and Carl Shapiro is a good introduction to the basic strategies involved in a standards war. The book Rules by the same authors is a very good read with a lot ideas pertinent to the current debate.". However Ben Woodard writes "I was talking to the Access tech support people here at Cisco about Halloween and how MS is planning to use embrace and extend, Em&Ex, to capture the market. They told me how Microsoft has a broken version of CHAP negotiation in the PPP protocol and if you want CHAP to really work you must use Microsoft's proprietary version of CHAP. It got me wondering if other people know about places where Microsoft has used Em&Ex but it is burried so deep in the protocols that most people don't know it exists. It would be interesting to try to compile a list of these little known incidents of Em&Ex. " Obviously it is impossible to know whether Ben's example is an example of flawed testing or real intent to break CHAP, but were serious evaluations of OS's to include standards-compliance tests, an interesting picture might emerge. Not only are standards an issue, but so are patents. So far, Linux has been lucky: many Unix patents have elapsed. Patents are something to mull over, while hacking.

David Holloway writes in with this question: "What's the word on XFree86 regarding pthreads? I have read that is possible to compile XFree86 so that X apps can use pthreads, but... why isn't it compiled that way by default?" Good question! So what are the issues surrounding X and threading?

Jason writes "In light of all the questions about the different forms of BSD and why it took so long for them to catch on, here is an article that describes the differences and the legal battle for the source. A good read for any non-BSD person.

The Redherring is carrying an explosive article about Microsoft's secret memos which discuss how to kill DR-DOS, and in general how to leverage the Windows monopoly. Funily enough, that's the sort of behaviour the Sherman Act prohibits. In related news, a group of people who just don't get it have banded together into the TAAC, an organisation of VARs that claims the DOJ is stiffling innovation. ("s/Innovation/bug count/" ????) David Hart and El contributed the second link, while Adam Radulovic, John Lazzaro, Sunil Gupta, David Price, Matt Francis, David Hart, Phillip Brown, toebee, and I found the first link.

How Big is 64 Bits? is just one of the interesting entries in the VOX archive. There is tons to read ranging over many many years. I've just been scrolling around and skimming it, and ran into skads of interesting things. We've got chain letters, those forwards that never die, comments about porn, taxes, lawyers and more. Definately worth spending some time. Probably worth spending a lot of time. Thanks to Disconnect for sending this in, and #Slashdot for whining that I haven't been posting enough geeky silly stuff lately. This should be enough crazy stuff to keep everyone busy for a few weeks *grin*

How Big is 64 Bits? is just one of the interesting entries in the VOX archive. There is tons to read ranging over many many years. I've just been scrolling around and skimming it, and ran into skads of interesting things. We've got chain letters, those forwards that never die, comments about porn, taxes, lawyers and more. Definately worth spending some time. Probably worth spending a lot of time. Thanks to Disconnect for sending this in, and #Slashdot for whining that I haven't been posting enough geeky silly stuff lately. This should be enough crazy stuff to keep everyone busy for a few weeks *grin*

Raymond Fellers writes "Oracle announced that they will release a Linux version of Oracle 8. Article from InfoWorld Electric "

Tobias Löfgren writes "Seems like the SETI@home project mentioned on slashdot a couple of months ago finally decided that the best way to get the show on the road was to release the source for the distributed network clients and they've been looking for geeks worldwide to help since June 8th. Now we all can join in the hunt for aliens!" Interested programmers should look here, or you can snag the code.

Tobias Löfgren writes "Seems like the SETI@home project mentioned on slashdot a couple of months ago finally decided that the best way to get the show on the road was to release the source for the distributed network clients and they've been looking for geeks worldwide to help since June 8th. Now we all can join in the hunt for aliens!" Interested programmers should look here, or you can snag the code.

Tobias Löfgren writes "Seems like the SETI@home project mentioned on slashdot a couple of months ago finally decided that the best way to get the show on the road was to release the source for the distributed network clients and they've been looking for geeks worldwide to help since June 8th. Now we all can join in the hunt for aliens!" Interested programmers should look here, or you can snag the code.

Dave Doolin wrote in to send us a link to the ABC News Answer Geek. I think this is a bit old, but I figured I'd run it because it just seems nice that a more mainstream news source is trying to clarify the age old [H|Cr]acker ambiguity. I hope for a future where we can refer to ourselves as "Hackers" in public without getting dirty stares from cluless folks *grin*.

John Lazzaro sent us a link to This Techweb Article about reverse engineering future Intel CPUs. Brian Dial sent us a link to a A Security Site that some of you might like. Anthony David sent us A piece he wrote discussing software development and the like. René Fichter wants to know if there is any demand for an Open Source Graphical MUD. He's been working on one called Daenor that he's considerring opening the source to. Henrik Abelsson sent us a link to Denounce, a hilarious site that runs fake Press Releases. Very cool. An anonymous read submitted Realaroma. Its moderately entertaining. Finally Darren Ginter sent us an article about Signing Bonus's and the computer industry for those of us who thought that only Sports stars get such things.

frank drewett wrote in with what may be the coolest geek appeal thing of the week. The uber cool VNC (you know, PC Anywhere, but free and works on Windows or X?) now has a viewer available for the Pilot. Man that's cool. Check it out Here.

Yaron Minsky wrote in to remind us about The Seti Project and to give everyone this link where you can read about the Distributed SETI project. I haven't mentioned this in several months, so the executive summary is that a distributed network of computers run screen savers that process noise sampled from space, and search for signs of extraterrestrials(sp?) Its like Distributed.net for Carl Sagen fans.

Raymond Fellers writes "A few months ago, Intel released the Math Kernel Library which provide level 1,2,&3 BLAS (Basic Linear Algebra Subroutines) and FFTs tuned for Pentium Pros and IIs. Unfortunately, the MKL was only available for Windows. Recently, a group of Intel employees working on the ASCI Red supercomputer released a Linux version of the MKL. " You can read more here.