Slashdot Mirror

Win4Lin is dead

What the hell are you talking about??? What's wrong with the BUY link on this page? It's $89 bucks, you can't even get the educational version of VMWare for that price. Beisdes, they're rolling out support for W2K this fall without resorting to CPU intensive hardware emulation.

Anyhow, Bochs is your only "free" option to get W98 running. I don't know what the performance will be like, I've never used it.

Just curious as to why Bochs wasn't even mentioned? I understand it's Beta quality, but it CAN run a significant subset of hardware.

-theGreater.

If you're going at the programming by yourself, I would strongly recommend you use a library to save you from having to write your own low-level access routines (unless you just want to learn about how all these whiz-bang effects are done, but that may distract you from the goal of getting a game finished). Unless you have commerical backing, or are absolutely sure you have the willpower to stick to the project (by "absolutely sure", I mean you've done it before right to the bitter end and want to do it again), I would recommend using as hing-a-level library as possible.

There are several out there with their advantages and dis-advantages. Some of them are Microsoft DirectX., OpenGL, Allegro and SDL. High-level libraries are good for beginners and are useful for rapidly developping games. You can accomplish a lot with a few lines of code, but they can make the executable size bloat, and sometimes, you may want more control over the system. Low-level libraries are useful for control-freaks who want more control of what's going on.They let you access the system with little overhead, but require a lot of work to get to work. DirectX and OpenGL are low-level libraries, Allegro is a high-level library, and SDL is somewhere in the middle.

Also, check to see which platforms the library is available for. DirectX is only available for Microsoft, whereas OpenGL, SDL and Allegro let you write programs that can be ported to a multitude of systems and OS's.

Personally, I use Allegro, but other people may have different requirements or desires to dig down deep into the hardware.

I'm certainly knee deep in RDF and OWL; I develop a GPL'd RDF engine called 3store which is moving OWL-wards in the near future.

I've been a low-level DB wrangler for some years, and FWIW I now find semantic-web structures much easier to deal with than SQL. The simple fact that you dont /need/ a schema to assert data and make queries is hugely useful, not to mention the inference RDFS can do, which is pretty lame my AI stnadards, but is very fast,and still quite powerful.

... one of the authors of PearPC was hit by a train and killed.

More on their site

I recently started playing around with Jena, a Java API for writing Semantic Web applications. W3C's Resource Desciption Framework (RDF) page has RDF specs, a means for storing semantic information.

Incidentally, Paul Ford is a regular writer on these sorts of topics. He has a collection of writings on the web and semantics.

Tim

I am still working hard on an open source project (CEP) that is unrelated to my 9-5 programming. A lot of purely personal stuff doesn't get done, but I stay motivated to work on CEP.

The problem for me is that if I touch a computer at home, my wife sees it as m work. So she can be lounging on the couch watching TV, but if I lounge on the couch and surf the web (or even pay bills online) she assumes I am working at home.

To her defense, I used to have a shitty job that I did have to do work at home. The moral of the story is that if you want to keep programming as a hobby and a profession, don't blur the lines. Don't work on personal projects at your job, and don't do work stuff at home.

-Jackson

True AI is always 10 years away. The hard truth is that it will more than likely be 100 years or more. Even the youngest slashdotters will not live to see it.

AI will likely only move forward along with advances in robotics and bio-connectionist systems. Traditional programming doesn't lend itself well to the task.

"Expert systems" is an unfortunate term. I prefer "knowledge based", but even those programs have proven impractical. The most ambitious attempt has been Doug Lenat's CYC project.

Faster processors certainly won't hurt AI, but the answers do not lie there. Of that much we can be sure. As with space travel, we are all waiting for some kind of fundamental breakthrough.

Maybe it will be some combination of robotics, human and experiential trained (maybe wetware) connectionism, along with some CYC-like rules.

I've been using ClamAV now for a while, and it does a good job.

For my mail server, I use Qmail-Scanner, which does a very good job. Older versions had some issues with funky/broken MIME messages, but they seem to have been mostly resolved.

Thought of this almost two years ago. Run OpenVPN over UDP port 53. I figure a fair number of firewalls may not analyse UDP DNS traffic to see if it actually is UDP DNS traffic. Haven't had a chance to try it out though.

Thinking big picture, you realise that once opportunistic IPsec becomes available, and with IPv6 it will be, any device in the network trying to interpret traffic, such as firewalls and proxy servers, will become just about useless.

They were sending pop-up ads using the Messenger function enabled on many Windows operating systems
Yup yahoo messenger is annoying simply use zinc http://zinc.sourceforge.net/ or curphoo http://savannah.nongnu.org/projects/curphoo/ for Linux/FreeBSD/OpenBSD etc all. They just not block the advts; but also got facility to ignore users, stop booters and other features :))

There is also a man porting the original Zelda for the NES to the dreamcast. Of course, all sprites and such had to be changed, because Nintendo found out about it (back when it was for PC only) and used the DMCA to force the creators to either drop it, or stop using their art. The link for today's project, Openlynks, is located here.

http://sourceforge.net/projects/qtcomponents/

It allows iTunes to play OV format, but I'm not sure if that carries over to the iPod. Since the software appears to be a QT component as opposed to an iTunes add-on, I would say the chances are better than not that it will allow OV to play on an iPod. If it doesn't, at least it gives you a bridge to move some OV files to an iPod-compatible format. I know--pain in the butt if you're looking to convert an entire collection, but workable if you just want to move over select files.

I've been in QA for a number of companies and have found one consistent problem... re-invention of the wheel...
I attribute this to two things

1) Commercial tools are over complicated and not very good
2) There's no tool that exists to do X Y Z
3) Our software can't be automatically tested !
4) A lot of time is taken up with reporting !

1).. Totally agree... have you ever seen Test Director ? It's a nightmare to use, takes ages to import testcases, and it's automation interface sucks... plus it costs a FORTUNE.
Consequently people end up storing testcases in excel sheets, word docs or spreadsheets...

2) In some cases thats true, but in most its not.. I've seen companies write there own test environments that address problems that have been addressed (often much better) millions of times before... I'm talking automating starting / stop processes and test scripts, reporting, logging, seeding with test data etc... ALL COMMON problems...
The answer to this is SIMPLE
Take a look at STAF (Software Test Automation Framework) by IBM. It's free and GPL. It gives a common framework for witing tests scripts and applications in java/perl/python/c and a few other languages. It consists of a STAF process running and a set of APIs and a command line interface. Services exist to start / stop processes on remote boxes, transfer files, global variables, semaphores, logging.... in fact EVERYTHING you would want to do in automation.
Take a look at
http://staf.sourceforge.net/
This tool saves many man-months of coding in a test environment and gives a consistent way of doing things. No more tester X has this cool script, tester Y has this, dept Z does this....
If you are a tester you need to look at this !

3) This argument normally doesn't hold water anymore... most things can be automatically tested. The question is IS IT PRACTICAL ? If you are only going to test a product once (think end customer doing acceptance testing on your product) then often it's not.
However if you are a software house, then there is no excuse for not doing automated testing, especially when you've got access to source code. You can also buy lots of expensive analysers and script generators for stimulating systems under test.

4) Reporting... yes management wants to know how you are getting on.... A lot of companies do this by email... Each QA person has to send an email every day detailing what they've tested, problems they've had, progress etc . etc.
This is UNNECESSARY. This is the perfect excuse for automation.
An analysts' time should not be taken up with this crap. They should enter this info into a centralised test management system and management should be able to query and manage the test cycle using this tool. Again Test Director tries to do this, but it's TOO complicated.

Now for the shameless Plug....
I have writen a GPL testcase management system called Testmaster which does most of the above and integrates with STAF, allowing test scripts access to the testcase database via STAF.
It provides web front end which holds all testcases and proceedures for multiple projects and departments, imports testcases from word docs, CSV files or directly into the DB and is the primary interface for everyone involved in the QA process.
So now you have your testscripts running, automatically marking tests as passed/failed etc, automated emails going off to management on progress, a web based system for testers and managers to use and the ability with STAF to stop/start/pause testing at the click of a button on multiple remote systems.
It's easy to use, free, under the GPL, eerything is held in a database and runs on almost any Unix system...

Take a look at
http://testmaster.sourceforge.net/

and see if it will make your job easier.
End shameless plug

I've been in QA for a number of companies and have found one consistent problem... re-invention of the wheel...
I attribute this to two things

1) Commercial tools are over complicated and not very good
2) There's no tool that exists to do X Y Z
3) Our software can't be automatically tested !
4) A lot of time is taken up with reporting !

1).. Totally agree... have you ever seen Test Director ? It's a nightmare to use, takes ages to import testcases, and it's automation interface sucks... plus it costs a FORTUNE.
Consequently people end up storing testcases in excel sheets, word docs or spreadsheets...

2) In some cases thats true, but in most its not.. I've seen companies write there own test environments that address problems that have been addressed (often much better) millions of times before... I'm talking automating starting / stop processes and test scripts, reporting, logging, seeding with test data etc... ALL COMMON problems...
The answer to this is SIMPLE
Take a look at STAF (Software Test Automation Framework) by IBM. It's free and GPL. It gives a common framework for witing tests scripts and applications in java/perl/python/c and a few other languages. It consists of a STAF process running and a set of APIs and a command line interface. Services exist to start / stop processes on remote boxes, transfer files, global variables, semaphores, logging.... in fact EVERYTHING you would want to do in automation.
Take a look at
http://staf.sourceforge.net/
This tool saves many man-months of coding in a test environment and gives a consistent way of doing things. No more tester X has this cool script, tester Y has this, dept Z does this....
If you are a tester you need to look at this !

3) This argument normally doesn't hold water anymore... most things can be automatically tested. The question is IS IT PRACTICAL ? If you are only going to test a product once (think end customer doing acceptance testing on your product) then often it's not.
However if you are a software house, then there is no excuse for not doing automated testing, especially when you've got access to source code. You can also buy lots of expensive analysers and script generators for stimulating systems under test.

4) Reporting... yes management wants to know how you are getting on.... A lot of companies do this by email... Each QA person has to send an email every day detailing what they've tested, problems they've had, progress etc . etc.
This is UNNECESSARY. This is the perfect excuse for automation.
An analysts' time should not be taken up with this crap. They should enter this info into a centralised test management system and management should be able to query and manage the test cycle using this tool. Again Test Director tries to do this, but it's TOO complicated.

Now for the shameless Plug....
I have writen a GPL testcase management system called Testmaster which does most of the above and integrates with STAF, allowing test scripts access to the testcase database via STAF.
It provides web front end which holds all testcases and proceedures for multiple projects and departments, imports testcases from word docs, CSV files or directly into the DB and is the primary interface for everyone involved in the QA process.
So now you have your testscripts running, automatically marking tests as passed/failed etc, automated emails going off to management on progress, a web based system for testers and managers to use and the ability with STAF to stop/start/pause testing at the click of a button on multiple remote systems.
It's easy to use, free, under the GPL, eerything is held in a database and runs on almost any Unix system...

Take a look at
http://testmaster.sourceforge.net/

and see if it will make your job easier.
End shameless plug

Umm... links appears to be younger, less developed version of the old standby lynx.

In terms of sites, I recommend a local css file to block things like banners, large images, and other bandwidth intesive content. You may even try a css file that strips out everything but text, links, and layout info (e.g., no images, no animations, etc).

You're only partially correct about the iPod. It does show up as a standard storage device, but the music files are stored in some weird directory structure and the metadata and playlists are indexed in a proprietary database format. You can't just copy some music onto it and expect to be able to play it. You need a program that understands the iPod database. I've personally never used anything to talk to my iPod other than iTunes, but I understand there are a few alternatives now. The two I've heard of are EphPod and gtkpod.

1. Strict adherence to the test first methodology (JUnit). It isn't enough to just write test cases, without nightly (or frequent) builds JUnits loose a lot of their effectiveness - especially in large groups. In addition, having regular code reviews to make sure people aren't just blowing smoke is essential.

2. Early and often QA cycles. Not only will the development team love this, so will your product owners. Here's a good starter for the http://www.extremeprogramming.org/rules/releaseoft en.html release often concept. Doing this will make your QA cycles much more effective and manageable.

3. Don't over automate. Automation can be a very effective tool; however, there must balance.

As for tools (sorry pretty Java centric here), I'd suggest starting with:
- http://htmlunit.sourceforge.net/
- http://jakarta.apache.org/cactus
- http://httpunit.sourceforge.net/

1. Strict adherence to the test first methodology (JUnit). It isn't enough to just write test cases, without nightly (or frequent) builds JUnits loose a lot of their effectiveness - especially in large groups. In addition, having regular code reviews to make sure people aren't just blowing smoke is essential.

2. Early and often QA cycles. Not only will the development team love this, so will your product owners. Here's a good starter for the http://www.extremeprogramming.org/rules/releaseoft en.html release often concept. Doing this will make your QA cycles much more effective and manageable.

3. Don't over automate. Automation can be a very effective tool; however, there must balance.

As for tools (sorry pretty Java centric here), I'd suggest starting with:
- http://htmlunit.sourceforge.net/
- http://jakarta.apache.org/cactus
- http://httpunit.sourceforge.net/

1. A dedicated QA staff. You should have as many testers as you have developers.
2. Tools for the QA staff to create their own automation. They don't like doing manual testing much, either, so they'll have incentive to use the tools. :-) I'll talk about the tools we use in a bit.
3. Training for the QA staff on the tools. Hire QA people capable of at least a little shell programming. And the tools they use should be not much harder than writing shell scripts.
4. A good SCM (source code management) system that provides atomic commits, so that when you fix a bug, you can tell your testers exactly what revision number it's fixed in, and they can get exactly that revision verify it in the same system you had when you fixed it.
5. A bug tracker. It doesn't have to integrate with the SCM, but if it doesn't, you should make it a hard policy that your commit log messages should say what bug number they are a fix for, and when you resolve a bug, you must say what revision the fix went into. I can't even estimate how much time this policy saves.
6. Automated rebuilds of every revision of the software. Spend a lot of time on this, it's key. It lets your testers test things the minute you fix them. That means, if you failed to fix it correctly, you'll find out SOON while the fix is still fresh in your mind, and you'll save even more time by not having to get back into the mindset of that bug. You will need special software to do it, so read on.

1. For us, our project has had 1-2 developers working full time (me, plus one additional deveoper at various times). We've also had 1-2 testers working full time. That sounds like a small project, but after two years of dev it is a lot of code, and all that code needs testing. The fulltime test staff available right from the start was absolutely not money wasted.
2. The development is done in Python, with Twisted, and so we used a combination of unit tests written by the developers and black box tests written by the testers. Because our app is primarily web, I developed my own web test system (having found no others that were suitable for use by non-programmers). This system is PBP, which is a shell-like scriptable web browser.
3. Our main tester had a little bit of C in school (she actually had forgotten most of it ;-) and a little bit of unix command line experience. This was more than enough to be able to design and build tests with PBP. Then I spent about one full day showing her how to use it and brainstorming testmaking strategies with her.
4. Subversion.
5. We've been successful with Bugzilla. If I had to start over, I probably would have used Trac, with which I've had good experiences on other projects.
6. I built a completely automatic build system using Buildbot to trigger the builds after each commit and A-A-P to script the build process.

We've had good luck with Jameleon. We use JUnit for the low level stuff and Jameleon to test the web front end. Of course, it's probably a good idea to use human testers before you go to production, but automated testing can cut down on the bugs that make it to the human testers.

It's designed to stress test web pages, and analyse the load on web servers, database servers and operating systems.

There is also a new company - Cyrano that has risen from the ashes of the old one, and provides many other testing tools, including regression testing.

At our company the developers use TextTest for automatic regression testing. TextTest is developed in house by 2 of our developers, but opensource. More info at http://www.carmen.se/research_development/programm ing.htm and http://sourceforge.net/projects/texttest.

Incidently, FWIW, the Slashdot editors have chosen to disallow ed2k links. I've posted about it before on Slashdot, and there have even been filed bugs on it.

Jamie has a point -- that ed2k URLs launch external programs, and that he doesn't want to help trolls -- but man, I wish that we were able to use them, even if we lost the ability to use gopher, mailto, etc. Every time Slashdot links to a large file, we end up with some random reader having to set up a bittorrent entry (which is great for the immediate link, and keeps the server from being killed). However, inevitably that user kills the link after a couple of days, and then all the links to large files in old stories are dead. If we could just embed ed2k links, we could maintain links that would be useful months later. Adding ed2k wouldn't mean having to add any other protocols -- Gnutella and most P2P networks lack an URL format, and the only competitor, Kazaa, has a broken non-unique URL format that shouldn't be included.

It'd be especially nice if users that wanted to allow ed2k links could enable them in their preferences, and then see them (though I guess that wouldn't work well with the pre-generation approach of Slashcode -- sigh).

And just to clarify, it's between 43 and 44 seconds in, when the id logo flashes (right after the line "Welcome to the worst assignment you'll ever have").

I love Media Player Classic's frame step option.

If you have Windows, use Media Player Classic. It's a GPL'ed media player with a lightweight interface (think old-school Windows Media Player) and interfaces to QT, WM, and Real codecs, as well as playing CDs, DVDs (with excellent subtitling) and pretty much any streaming video format.

You'll need to install QT/Real/WM codecs for it to work completely, but it's nagware free and updated often.

The several emacs forks would benifit from being in the same CVS, and possibly even some of the scheme versions of emacs like guile emacs http://gemacs.sourceforge.net/ would benifit from this. (whereas texmacs http://www.texmacs.org/tmweb/home/welcome.en.html would probably not.

If your wondering why i've thought about this so much, It's cause I went through the issue pretty comprehensively a long time ago with the dosemu project, and my again with my (bad) idea for a kernel fork.

The release is not of Enlightenment the Window Manager. It is a release of EFL, the libraries that they wrote to underpin Enlightenment. Here are some screenshots of E components that will depend upon the EFL: Evidence, Entrance. and Emotion.

Some other details:

Edje provides a revolutionary method of absstacting every aspect of your interface from the application itself. By passing signals between the interface and the application all communication is done in an interface neutral way. No longer are "themes" simple changes of pixmaps over a fixed area. Using Embryo we can provide scripting ability to the interface componant itself to harness even more power and flexability. [sic]

So, no, this is not just a brushed metal window manager theme (of course, E 0.16 was always more than that, too). I've been watching E, and making the same jokes on April 1st, but I must say that I'm looking forward to trying what they're coming up with once they've got a semi-stable release; and since the EFL seems to be close to a freeze, I think we can hope to see E 0.17 soon.

There have been widget libraries built on top of OpenGL for years. See GLOW, for example. It's straightforward to do, and works reasonably well. Works on any OS that will run OpenGL.

Ok, POSIX is all about the system calls and C library functions. C89 is about compiler support. They are seperate and don't go hand-in-hand.

About POSIX and Unix compatibility. There are a handful of Unixes that remain important and widely deployed. They are:

Solaris
HP-UX
AIX
Linux
*BSD
MacOSX

They pretty much all have modern APIs in recent versions. The older unixes have recently added a bunch of Linux-like modern APIs to make portability easier. This was the reason behind HPUX 11i (the 'i' denotes "internet ready", but what they really mean is glibc/*BSD apis). This is also the reason behind the AIX 5L name (AKA 5.1, 5.2) (L = linux affinity, same deal, new GNU/*BSD apis). You know that MacOSX uses a BSD-based userland, so you're fine there. Then there's Solaris, of which recent versions (>=2.6) are in good shape. Recent versions of the proprietary unixes even have /dev/[u]random and /proc filesystems. There's a lot of common interfaces, as long as you target relatively recent releases.

Ok, once you figure out what platforms you are targeting, you need to figure out what compilers you will support. All of the proprietary Unixes have their own C compiler (sometimes only available for a fee). Many are not fully ANSI compliant. They are definitely not all C99 compliant. That is the bad news.

The good news is that gcc is available for all of the major platforms. This is what gcc excels at, it is highly portable. You can use this to your advantage to get things working on these platforms. If your users then want to get them working with other compilers, that is worth a shot too (non-gcc compilers often produce better optimizations, etc.).. but it will be hit or miss.

Testing. I highly recommend the HP Testdrive program. They make available a bunch of machines with various HP hardware running various operating systems from Linux on Alpha to HPUX on IA64, including Tru64 (aka OSF/1). http://www.testdrive.compaq.com/

Sourceforge also has a build farm which includes Solaris on sparc and x86 and MacOS X. http://sourceforge.net/docman/display_doc.php?doci d=762&group_id=1#platforms You have to be a developer of a sourceforge project to get access, but its a good deal.

Good luck. Hope this helps.
-molo

HPUX Note: Many people think that 11i is for the Itanium platform. That is not the case. 11i is version 11.11 and higher. 11.11 is for HPPA. 11.20 and higher are for IA64. Both are called 11i.

You forgot to mention CVS (http://www.cvshome.org/). Usually database developers commit their changes to their stored procedures directly into the only database, where they are stored. That is not good, because other Java developers are using the same database at the same time, so they see intermittent bugs.

It is better if all code goes into CVS, even stored procedures. Not to mention that every developer must have a copy of the database in their own machine, usually MySql (http://www.mysql.com/) or HSQL (http://hsqldb.sourceforge.net/) is better for that.

Then from CVS you take out a build (you use CruiseControl to generated builds that are compiled and unit tested using JUnit http://www.junit.org/) so you know all the Java code works with the stored procedures, the database model and the example data. Then you can add your code, with your unit tests, into CVS.

My $0.02 CLP (= $0.0000318238 USD according to http://www.xe.com/ucc/)

Also, bzflag, is easy on the requirements and easy to play.

And the Streambox guys did it by reverse-engineering the protocol.

Do you mean Lookout, that MS recently bought (available here),
Is based on the open source lucent.net

Little Fighter II and Soldat are great games too, but in our local Lan Parties, Armagetron was definitely the most succesful. We found out that Little Fighter II is best when played with less than 4 players, hopefully about the same skill level, as there is a huge learning curve. Soldat used to be more succesful in earlier versions, when it was even faster and crazier :)

The GUI toolkit that I used (Perl/Tk) also seems to have some problems with stability; I spend an awful lot of time tracking down problems reported by users because of some problem with the version of Perl/Tk they've got. Dunno if other Perl GUI toolkits are better in this department. Perl/Tk is nice in many ways (excellent documentation, code that uses it is extremely readable), but now that my project is mature, it's really a drag that 100% of the bug reports are things that I can't do anything about, because they're problems in Perl/Tk (or in the Perl/Tk that comes with a specific Linux distro, especially Gentoo).

That in turn is a large part of the popularity of the GPL. Microsoft can't appropriate GPL'ed code. They can distribute it, just like anyone else can, and they do. But they can't kill the organization that actually produces it. They can't prevent users from extending it.

In the long run, open source can outlive its original owner. The current controversy over X and the FreeS/WAN transition to Openswan both illustrate that.

In which case you probably want to check out RPMPan project, which provides the entirity of CPAN packaged in RPMs and all 'apt-get'-able. See their Source Forge page

You might want to check out faubackup - that's what I'm using. Faubackup is perfectly fine for doing nightly backups and works like this:

It creates a directory hierarchy, with directories named after the backup date and the backed up files below in the directory structure they were originally in. When a file didn't change from one backup to another, just a hard link gets created to the copy in the older backup, if it was changed, it gets created anew.

Expiring old backups is done by rm -rf'ing the corresponding directory - files with no more links get deleted, files that are needed in another generation lose one link. Restore of a file is done via the normal filesystem tools - cd, cp, ...

Faubackup can be found here.

Regards, Ulli

By "real debugger" I mean something that can be used to reliably debug 10,000-line "configure" scripts and debug around control flow, handle sourcing multiple files, show a call stack, debug into or skip over into functions.

Yes indeedy, and it's all made easier by rdiff-backup, a set of python scripts which allows you to very simply backup and restore files. Then you can even put a web front end on it with my very own POS^H^H^HPHP script rdiff-backup-web!

Try heroes (screenshot). The resolution sucks (320x200 - I run it like this: heroes -F -J -2 -i), but it's lots of fun in 2-player.

Instead of only keeping a "yesterday" partition, use rsync to keep EVERY daily backup.

See the documentation at http://bashdb.sourceforge.net/bashref.html#SEC60 I believe though that in contrast to bashdb where this is set by default, Chet had it unset by default, I guess to keep compatible with the old behavior.

But since it was something I felt strongly about, wanted and is relatively easy to do, I added it to my bash debugger project over a year ago. (The ChangeLogs says 2003-05-24). See http://bashdb.sourceforge.net/

The timestamped history was incorporated into bash 3.0 alpha along with my idea of using a user-settable variable to control how to format the time (from strftime()).

Also, most of the debugging support from the above project I think has been encorporated (although I haven't checked it over for a while).

Linkified:

Privoxy

Posadis

Linkified:

Privoxy

Posadis

For those who didn't know: click here

• Find any tall beige-box case. ($150)
• Find 9 good 250g Serial ATA drives. ($100 each = $900)
• Get an 8-port serial ATA hardware RAID controller like these ($300)
• Get a good 400-500W power supply ($200)
• Any motherboard and CPU will do ($200)
• Spend a few extra bucks on gigabit ethernet ($50)

Rip all your CDs as FLAC so that (1) you never have to rip them again (it's lossless), but (2) it's half the size of saving WAV files

At least that's what we've done with our 68,000 CDs we have here.

This project is working on backups to large raids using Rsync. I think his test system has 3tb.

Werdna

http://sourceforge.net/projects/rvm/