Speaking as one of the people you will (temporarily) be supplanting, sounds like you have a tough spot to get through.
I also admin life sciences clusters for a major university on the east coast. I'm going to assume that our workloads are going to be fairly similar (R, matlab, blast, HMMER, IDEA, maybe some mutual information codes, sequence alignment, etc.). If that's not the case, some of this advice may be off.
So, a couple of things:
- I think CentOS is a good idea for a cluster platform. I do not think Rocks will scale like you want it to to that size, and it's really not terribly flexible either. Let's put it this way, I often find that I could have just built from scratch by the time I get Rocks to do all the customization I need. We run Rocks on small clusters, but big ones we spin ourselves (e.g. CentOS, or sometimes Fedora + Kickstart + some utility scripts and a scheduler... we use SGE, now OGS). Finally, stay away from more fringe distributions. You'll find that commercial software vendors are pretty quick to let you know they just don't support running their software on XX distribution. There are other reasons too. I posted a bit of a rant on this a while ago at: http://slashdot.org/comments.pl?sid=2188634&cid=36255670 - Infiniband vs. 10 Gbps. Well, InfiniBand is cool, and I've spent a lot of time working with it. I once had a project that involved writing some early stage block level storage protocols for InfiniBand... really, I like InfiniBand. That said, unless you plan to run a lot of MPI enabled MD simulations like Desmond, skip the IB and get 10 Gbps. There are a couple of exceptions to that rule, but most life sciences applications do not use MPI, and most of your traffic is going to be storage I/O. Depending on your storage solution, it's probably not InfiniBand enabled (in the front-end anyway, and you really don't want to be running IP over IB if you can help it). To say more I'd have to know a bit more about what you're going to be running. - GPUs. One thing sticks out to me a lot here. If you don't know which GPUs to get, that probably means no one has ported anything to GPU yet. If someone has done some porting, you should ask them what they ported to. If they ported to CUDA, you should probably be looking at 2050s or 2070s. If they haven't ported anything, and they don't have (good!) GPU ported applications... don't waste money on too many GPUs. We've run a couple of pilots where we tried to get people using GPUs, and here are a couple of observations: 1. most researchers can't/won't do the porting; 2. most pre-built applications, such as matlab and R _still_ require you to port the matlab, R, etc. code, which researchers will probably also not do; 3. some life sciences algorithms just don't work well on GPUs (e.g. they are branch-heavy or memory I/O heavy algorithms); 4. many of the pre-built GPU applications for life science are terrible (I know a particular sequence alignment tool, for instance, that is proud of it's 4x speedup over a single CPU... do the math... which costs more, a quad core CPU or a tesla?). GPUs can be great, but buy them sparingly at the beginning and integrate them as they are actually being used. If you're buying now you should be buying CUDA (i.e. NVidia). It's the only actual mature development kit (though I don't like that it doesn't let you control the scheduling on the card... but I digress). - Chargeback: So the bottom line is nothing is going to give you chargeback without some effort. You're going to have to manage that on your own. The best way to do it is to setup some basic accounting scripts that will dig your cluster logs (or database, depending on your configuration) and generate accounting reports. Note that it's the resource manager/policy manager (e.g. OGS, Torque/Maui, etc.) logs that you're going to do this with. You _could_ do it with Rocks as well as anything else (but again, I don't suggest Rocks for this project).
Sounds like you have a fun project ahead of you... good luck!
A primary component of my job is the design and maintenance of high performance compute clusters, previously in computational physics, presently in biomedical computing. Over the last few years I have had the privilege of working with multiple Top500 clusters. Almost every cluster I have ever touched has run some RHEL-like platform, and every cluster I deploy does as well (usually CentOS).
Why? Unfortunately, the real reasons are not terribly exciting. While it's entirely true that many distro's will give you a lot more up-to-date software with many more bells and whistles, at the end of the day what you really want is a stable system that works. Now, I'm not going to jump into a holy war by claiming RedHat is more stable than much of anything, but what it is is tried and true in the HPC sector. The vast majority of compute clusters in existence run some RHEL variant. Chances are, if any distro is going to have hit and resolved a bug that surfaces when you have thousands of compute cores talking to each other, or manipulating large amounts of data, or running CPU/RAM intensive jobs, or making zillions of NFS (or whatever you choose) network filesystem calls at once, or using that latest QDR InfiniBand fabric with OpenMPI version 1.5.whatever, it's going to be RHEL. That kind of exposure tends to pay off.
Additionally, you're probably going to be running some software on this cluster, and there's a good chance that software is going to be supplied by someone else. That kind of software tends to fall into one of two camps: 1) commercial (and commercially supported) software, and; 2) open source, small community research software. Both of these benefit from the prevalence of RHEL (though, #1 more than #2). If you're going to be running a lot of #1, you probably just don't have an option. There's a very good chance that the vendor is just not going to support anything other than RHEL, and when it comes down to it, if your analysis isn't getting run and you call the vendor for support the last thing you want to hear is "sorry, we don't support that platform." If you run a lot of #2, you'll generally benefit from the fact that there's a very high probability that the systems that the open community software have primarily been tested on are RHEL-like systems.
Finally, since so many compute clusters have been deployed with RHEL-like distros, there is oodles of documentation out there on how to do it. This can be a pretty big help, especially if you're not used to the process. Chances are your deployment will be complicated enough without trying to reinvent the wheel.
"But since I am not an expert in the subject, I would be interested in how you all feel the question should be presented."
Let me get this right, you are condemning some one else for having illogical opinions, yet you don't have the information to back up your own? That sounds a bit more like zealotry than informed opinion. If you would like to curb the illogical beliefs of others with "incontrovertible fact," perhaps you should begin by having knowing the facts rather than asserting a belief based on the that-smart-guy-over-there-told-me-so syndrome.
Now, I realize that this smells a bit like a flame, but I believe there's a real point to be had here. Until you are informed, are you really any better than they are? Until you are arguing with evidence, you're just blathering. Further, seeking the evidence to argue a point because you believe it is true, rather than arguing a point because you have found it to be true is hardly "scientific." Just a thought. People arguing without evidence leads to flame wars, which we have far too much of already on this particular issue.
One last thought, assuming the other guy is stupid is only likely to make a fool of you. Despite some of the assertions on this thread (this is more directed at certain commentors than the main poster) there are extremely intelligent people who hold the view that evolution is in some way flawed. I can't claim to know the particular intelligence of the candidates in question, but you can rest assured that they've heard the cookie cutter arguments before, they've seen the evidence, and they have made a conclusion that is not necessarily stupid (though, not necessarily right). If you would like to find some resolution in the evolution debate, I think the most important question anyone on either side can ask is more along the lines of: "what would cause that intelligent guy over there to make this conclusion that seems so wrong to me?" Until you actually understand their viewpoint you cannot intelligently counter it (I can hear the rebuttals already: "but religion, RELIGION." 1. Not all people who oppose evolution as a theory are religious. 2. What would cause an intelligent person to believe that religion might be worth maintaining, even against evidence?). Just calling the other guy "stupid" or "illogical" relegates us to elementary school squabbles.
To sum up, if you want a question to ask, try "Why do you oppose evolution?" And, (now I realize this may be a difficult thing to swallow) _listen_ to what he says. If his opinion is stupid, he should manage to make that obvious himself.
Granted, these titles are in public domain. That is, their original source is public domain; however, most of these works have been translated, and most of penguin's translations are current enough that they are not public domain.
Now, you might say "who cares about the translation?" but, speaking from someone who has dabled in translating and has paid attention to different translators, it can make all the difference in the world. Some translations are simply innacurate (e.g. the Jowett translation of Plato's Republic, in which there are many insertions by the translator that he must have felt Plato just, you know, left out by accedent). Some do not even follow the form of their source (e.g. the Rouse translations of the Iliad and Odyssey in which he chooses to translate the epic peoms as prose instead).
That said, this is exactly why I would *not* buy this shelf of books: penguin is hit-or-miss at best when it comes to who they have translate. Some are good, granted, and some were, of course, written in english to begin with, so translation is irrelevent. I won't attempt to throw a number out there, but a very large percentage of these books were written in Greek, Latin, French, German, etc. Further, a very large number of those, Penguin has not bothered to pay for decent translations of.
I, for one, will not be dropping $8k on a bunch of poorly translated, poorly bound books.
A disgustingly large amount of our medical expenses goes to malpractice insurance, and mostly to protect from one of the millions of malpractice cases that never should have been that occur each year. Granted, the ability to sue for malpratice *is* a good thing. However, it is grossly misused, and results in higher medical bills for all.
Not to say that's the only factor... but that's one of them.
Completely different system here. MIDI transmits performance data; when you hit a note it sends no audio but rather a digital signal that says "hit C3" for instance. This is actually sending digital audio.
There are more options in this area than I can even begin to fully explain. I will tell you that you won't be happy with your SBLive for very long. It certainly didn't keep my happy for more than a month.
The question is, how involved do you want to get? You can get into the computer/music arena for anywhere from $100 to... really as much as you want to pay. If MIDI-based music is the way you would like to go, you may be able to get away with simple stereo audio i/o. However, you'll probubly eventually want more than one pair of MIDI ports, and you'll want MIDI ports with lower latency than what you'd find on your SB card.
The first choice you need to make is what platform you will run on. The only two real competitors are Mac and PC/Windows. As much as I like Linux, it's just not in the audio arena yet. Of those two, Mac is almost undisputedly more stable/powerful when it comes to audio processing. Unfortunately, Mac's are quite costly. I personally use a PC simply for the cost factor.
Once you've chosen your platform, you need to get the most powerful system you can afford. It really matters here. You get a weak system you'll be very limited. That said, I do quite well on a 1.2Ghz Athlon (overclocked to 1.4) and 768MB PC133 SDRAM. Hard drives are also of concern when it comes to recording (which I assume you'll get into). Basically you want to make sure you have plenty of space and at least 7200rpm. Uncompressed audio can really take up a lot of space. Also of note, unfortunately most PC software is moving towards being 2k/XP only. In the Mac arena things are just starting to shift to OS X. Within the next year all major packages should be available for it, but for now you have some that are, some that aren't.
After the platform and computer are chosen, you need to figure out which software you want. Your key audio package will be your sequencer. This is the program you'll use to make everything happen. You'll record with it, layout with it, and generally even just play through it. There are several that exist: Cubase, Nuendo, Logic Audio (recently bought by Mac, now Mac only), Digital Performer (always has been, always will be Mac only), Cakewalke, and Sonar, to name a few. I personally recommend Cubase (Cubasis, the stripped down version, may be a good way to get a start into things). Also, if you're wanting to go with computer based instruments (aka virtual instruments) you'll need some plugins. As far as synths go, Native Instruments makes arguably the best to be found anywhere. I'm particularly fond of their FM7, and for raw power (though a lot more work) Reaktor is amazing. Also of note is Rebirth by Propellerheads, which is particularly handy for breakbeats if that's you're thing. It models two classic analog synths, and two classic drum synths. Finally, if you want to make serious MIDI based music, there is nothing that compares to Gigastudio by Tascam. It is by far the most expensive of them all, but well worth it. Technically Gigastudio is a sampler, not a synth. It is capable of playing back complete, believable, symphonies of sound (literally). It also takes massive amounts of CPU/RAM and only runs on PC.
The final aspect to go for is the audio/MIDI hardware itself. The reason this comes last is quite simply because certain hardware works best with certain software. With that in mind it's hard to give recommendations. You will need two pieces of hardware: the audio interface, and the MIDI interface. Audio hardware is a bit less proprietary than MIDI hardware, and you'll probubly be fine if you choose something that has ASIO drivers. I use a MOTU 896 Firewire interface that has 8in/8out, 8 mic preamps, and operates at up to 24bit/96kHz. That's probubly a bit overkill for what you want to do. I've also had very good success with Echo cards. The Echo Mia may well be the way to go. It's a simple stereo in/out, but will do 24bit/96kHz and has balanced TRS connectors. The Mia usually runs just under $200. Other manufacturers of note are: DigiDesign (expensive, very proprietary, but good), RME, Aardvark, and M-Audio.
The MIDI interface gets a bit touchier. I had to try a couple before I got one that really worked for me. They tend to also be more proprietary towards your sequencing software. I use a Stienberg Midex 8, which works beautifully with Nuendo and Cubase because they're both made by Steinberg, however, I wouldn't recommend it if you're not running Nuendo, Cubase or one of the other Steinberg software packages. Basically everyone uses there own protocol for MIDI, and uses a protocol called LTC for a fallback. Almost everything can use LTC, but LTC doesn't perform nearly as well as whatever proprietary protocol your software might use. Most companies that make sequencers also sell MIDI interfaces, and generally you want the one that matches your software. If you simply want one that will kindof work for everything, but not work great with anything, Midiman of Maudio makes the Midisport series that are fairly decent all around, but only use the LTC protocol. Of course, there are all shapes and sizes of MIDI interfaces, I would recommend getting one that has at least 2 in/out ports. It may be worth it to even go up to 8. On a side note, STAY AWAY from Edirol MIDI interfaces. I've had three of them go through my hands, and none of them worked.
Ok, now we have our computer, our software, and our audio/midi hardware... time to get a MIDI controler of some sort. This is where you just need to go to a few music stores and find what you want. There are a few things you want to make sure you have, but beyond that it's just all about what you like. You want to make sure you have pitch/mod control of some sort. You also want to make sure that you have a velocity sensitive controller (i.e. It sends out MIDI signals saying how hard the keys were hit/let off). You also probubly want something that works as a sustain pedal (especially if you intend to do anything that is to sound like a piano). I personally recommend getting something that has a small subset of built-in sounds. Even though they're a bit more expensive, it just augments your possibilities that much more. Everything else in the MIDI controller is more or less up to what feels good to you.
I know this ran on a bit, and is kindof haphazardly thrown together, but hopefully it can give some starting points. If you'd like to see what I have, it can be found here, but it probubly won't stand up to too awfully many hits. As a final note, a great resource for information on audio in general (including computer audio) is Harmony Central.
As far as I know, the best such drivers come from the ALSA project. In truth, there are very few multi-io cards listed as supported yet, but MOTU, Echo Audio, Yamaha and Midiman (as well as a few others) are all listed at least as being under developement. The one exception to this 'in the works' rule seems to be RME which appears to be quite well supported. Unfortunately, I see no mention of DigiDesign.
Actually multi-tracking software is in about the same state as the drivers. The most promising package I've seen is Ardour. Their package seems to be very much modeled after ProTools, at least as far as the interface goes. It supports LADSPA open-source plugins (no VST, RTAS, or DX unfortunately... mostly due to license restrictions). It already supports multi-io and many of your standard features, but lacks some things I consider necesities such as MIDI support (especially the ability to send MIDI clock and operate as a metronome... something I almost always use). None the less, there is a future for Linux and recording. It just, more or less, remains in the future for now.
Ever take a look at what Leia is wearing in RTOJ? It's nothing new.
Ever compare styles of the period when SW Ep. IV,V&VI were released to the movies? I think you'd find they're not far off. Styles of the present day apeal to the audience. They can relate to them.
As for girls showing skin. It's sexy, it's sci-fi, and it's also nothing new (and yes, it does sell). If showing skin is selling out, that happened for Lucas a long time ago.
Slashdot Mirror
Speaking as one of the people you will (temporarily) be supplanting, sounds like you have a tough spot to get through.
I also admin life sciences clusters for a major university on the east coast. I'm going to assume that our workloads are going to be fairly similar (R, matlab, blast, HMMER, IDEA, maybe some mutual information codes, sequence alignment, etc.). If that's not the case, some of this advice may be off.
So, a couple of things:
- I think CentOS is a good idea for a cluster platform. I do not think Rocks will scale like you want it to to that size, and it's really not terribly flexible either. Let's put it this way, I often find that I could have just built from scratch by the time I get Rocks to do all the customization I need. We run Rocks on small clusters, but big ones we spin ourselves (e.g. CentOS, or sometimes Fedora + Kickstart + some utility scripts and a scheduler... we use SGE, now OGS). Finally, stay away from more fringe distributions. You'll find that commercial software vendors are pretty quick to let you know they just don't support running their software on XX distribution. There are other reasons too. I posted a bit of a rant on this a while ago at: http://slashdot.org/comments.pl?sid=2188634&cid=36255670
- Infiniband vs. 10 Gbps. Well, InfiniBand is cool, and I've spent a lot of time working with it. I once had a project that involved writing some early stage block level storage protocols for InfiniBand... really, I like InfiniBand. That said, unless you plan to run a lot of MPI enabled MD simulations like Desmond, skip the IB and get 10 Gbps. There are a couple of exceptions to that rule, but most life sciences applications do not use MPI, and most of your traffic is going to be storage I/O. Depending on your storage solution, it's probably not InfiniBand enabled (in the front-end anyway, and you really don't want to be running IP over IB if you can help it). To say more I'd have to know a bit more about what you're going to be running.
- GPUs. One thing sticks out to me a lot here. If you don't know which GPUs to get, that probably means no one has ported anything to GPU yet. If someone has done some porting, you should ask them what they ported to. If they ported to CUDA, you should probably be looking at 2050s or 2070s. If they haven't ported anything, and they don't have (good!) GPU ported applications... don't waste money on too many GPUs. We've run a couple of pilots where we tried to get people using GPUs, and here are a couple of observations: 1. most researchers can't/won't do the porting; 2. most pre-built applications, such as matlab and R _still_ require you to port the matlab, R, etc. code, which researchers will probably also not do; 3. some life sciences algorithms just don't work well on GPUs (e.g. they are branch-heavy or memory I/O heavy algorithms); 4. many of the pre-built GPU applications for life science are terrible (I know a particular sequence alignment tool, for instance, that is proud of it's 4x speedup over a single CPU... do the math... which costs more, a quad core CPU or a tesla?). GPUs can be great, but buy them sparingly at the beginning and integrate them as they are actually being used. If you're buying now you should be buying CUDA (i.e. NVidia). It's the only actual mature development kit (though I don't like that it doesn't let you control the scheduling on the card... but I digress).
- Chargeback: So the bottom line is nothing is going to give you chargeback without some effort. You're going to have to manage that on your own. The best way to do it is to setup some basic accounting scripts that will dig your cluster logs (or database, depending on your configuration) and generate accounting reports. Note that it's the resource manager/policy manager (e.g. OGS, Torque/Maui, etc.) logs that you're going to do this with. You _could_ do it with Rocks as well as anything else (but again, I don't suggest Rocks for this project).
Sounds like you have a fun project ahead of you... good luck!
Agreed.
A primary component of my job is the design and maintenance of high performance compute clusters, previously in computational physics, presently in biomedical computing. Over the last few years I have had the privilege of working with multiple Top500 clusters. Almost every cluster I have ever touched has run some RHEL-like platform, and every cluster I deploy does as well (usually CentOS).
Why? Unfortunately, the real reasons are not terribly exciting. While it's entirely true that many distro's will give you a lot more up-to-date software with many more bells and whistles, at the end of the day what you really want is a stable system that works. Now, I'm not going to jump into a holy war by claiming RedHat is more stable than much of anything, but what it is is tried and true in the HPC sector. The vast majority of compute clusters in existence run some RHEL variant. Chances are, if any distro is going to have hit and resolved a bug that surfaces when you have thousands of compute cores talking to each other, or manipulating large amounts of data, or running CPU/RAM intensive jobs, or making zillions of NFS (or whatever you choose) network filesystem calls at once, or using that latest QDR InfiniBand fabric with OpenMPI version 1.5.whatever, it's going to be RHEL. That kind of exposure tends to pay off.
Additionally, you're probably going to be running some software on this cluster, and there's a good chance that software is going to be supplied by someone else. That kind of software tends to fall into one of two camps: 1) commercial (and commercially supported) software, and; 2) open source, small community research software. Both of these benefit from the prevalence of RHEL (though, #1 more than #2). If you're going to be running a lot of #1, you probably just don't have an option. There's a very good chance that the vendor is just not going to support anything other than RHEL, and when it comes down to it, if your analysis isn't getting run and you call the vendor for support the last thing you want to hear is "sorry, we don't support that platform ." If you run a lot of #2, you'll generally benefit from the fact that there's a very high probability that the systems that the open community software have primarily been tested on are RHEL-like systems.
Finally, since so many compute clusters have been deployed with RHEL-like distros, there is oodles of documentation out there on how to do it. This can be a pretty big help, especially if you're not used to the process. Chances are your deployment will be complicated enough without trying to reinvent the wheel.
"But since I am not an expert in the subject, I would be interested in how you all feel the question should be presented."
Let me get this right, you are condemning some one else for having illogical opinions, yet you don't have the information to back up your own? That sounds a bit more like zealotry than informed opinion. If you would like to curb the illogical beliefs of others with "incontrovertible fact," perhaps you should begin by having knowing the facts rather than asserting a belief based on the that-smart-guy-over-there-told-me-so syndrome.
Now, I realize that this smells a bit like a flame, but I believe there's a real point to be had here. Until you are informed, are you really any better than they are? Until you are arguing with evidence, you're just blathering. Further, seeking the evidence to argue a point because you believe it is true, rather than arguing a point because you have found it to be true is hardly "scientific." Just a thought. People arguing without evidence leads to flame wars, which we have far too much of already on this particular issue.
One last thought, assuming the other guy is stupid is only likely to make a fool of you. Despite some of the assertions on this thread (this is more directed at certain commentors than the main poster) there are extremely intelligent people who hold the view that evolution is in some way flawed. I can't claim to know the particular intelligence of the candidates in question, but you can rest assured that they've heard the cookie cutter arguments before, they've seen the evidence, and they have made a conclusion that is not necessarily stupid (though, not necessarily right). If you would like to find some resolution in the evolution debate, I think the most important question anyone on either side can ask is more along the lines of: "what would cause that intelligent guy over there to make this conclusion that seems so wrong to me?" Until you actually understand their viewpoint you cannot intelligently counter it (I can hear the rebuttals already: "but religion, RELIGION." 1. Not all people who oppose evolution as a theory are religious. 2. What would cause an intelligent person to believe that religion might be worth maintaining, even against evidence?). Just calling the other guy "stupid" or "illogical" relegates us to elementary school squabbles.
To sum up, if you want a question to ask, try "Why do you oppose evolution?" And, (now I realize this may be a difficult thing to swallow) _listen_ to what he says. If his opinion is stupid, he should manage to make that obvious himself.
Granted, these titles are in public domain. That is, their original source is public domain; however, most of these works have been translated, and most of penguin's translations are current enough that they are not public domain.
Now, you might say "who cares about the translation?" but, speaking from someone who has dabled in translating and has paid attention to different translators, it can make all the difference in the world. Some translations are simply innacurate (e.g. the Jowett translation of Plato's Republic, in which there are many insertions by the translator that he must have felt Plato just, you know, left out by accedent). Some do not even follow the form of their source (e.g. the Rouse translations of the Iliad and Odyssey in which he chooses to translate the epic peoms as prose instead).
That said, this is exactly why I would *not* buy this shelf of books: penguin is hit-or-miss at best when it comes to who they have translate. Some are good, granted, and some were, of course, written in english to begin with, so translation is irrelevent. I won't attempt to throw a number out there, but a very large percentage of these books were written in Greek, Latin, French, German, etc. Further, a very large number of those, Penguin has not bothered to pay for decent translations of.
I, for one, will not be dropping $8k on a bunch of poorly translated, poorly bound books.
A disgustingly large amount of our medical expenses goes to malpractice insurance, and mostly to protect from one of the millions of malpractice cases that never should have been that occur each year. Granted, the ability to sue for malpratice *is* a good thing. However, it is grossly misused, and results in higher medical bills for all.
Not to say that's the only factor... but that's one of them.
Completely different system here. MIDI transmits performance data; when you hit a note it sends no audio but rather a digital signal that says "hit C3" for instance. This is actually sending digital audio.
ok, so I seem to have hosed all of my links, sorry about that.
There are more options in this area than I can even begin to fully explain. I will tell you that you won't be happy with your SBLive for very long. It certainly didn't keep my happy for more than a month.
The question is, how involved do you want to get? You can get into the computer/music arena for anywhere from $100 to... really as much as you want to pay. If MIDI-based music is the way you would like to go, you may be able to get away with simple stereo audio i/o. However, you'll probubly eventually want more than one pair of MIDI ports, and you'll want MIDI ports with lower latency than what you'd find on your SB card.
The first choice you need to make is what platform you will run on. The only two real competitors are Mac and PC/Windows. As much as I like Linux, it's just not in the audio arena yet. Of those two, Mac is almost undisputedly more stable/powerful when it comes to audio processing. Unfortunately, Mac's are quite costly. I personally use a PC simply for the cost factor.
Once you've chosen your platform, you need to get the most powerful system you can afford. It really matters here. You get a weak system you'll be very limited. That said, I do quite well on a 1.2Ghz Athlon (overclocked to 1.4) and 768MB PC133 SDRAM. Hard drives are also of concern when it comes to recording (which I assume you'll get into). Basically you want to make sure you have plenty of space and at least 7200rpm. Uncompressed audio can really take up a lot of space. Also of note, unfortunately most PC software is moving towards being 2k/XP only. In the Mac arena things are just starting to shift to OS X. Within the next year all major packages should be available for it, but for now you have some that are, some that aren't.
After the platform and computer are chosen, you need to figure out which software you want. Your key audio package will be your sequencer. This is the program you'll use to make everything happen. You'll record with it, layout with it, and generally even just play through it. There are several that exist: Cubase, Nuendo, Logic Audio (recently bought by Mac, now Mac only), Digital Performer (always has been, always will be Mac only), Cakewalke, and Sonar, to name a few. I personally recommend Cubase (Cubasis, the stripped down version, may be a good way to get a start into things). Also, if you're wanting to go with computer based instruments (aka virtual instruments) you'll need some plugins. As far as synths go, Native Instruments makes arguably the best to be found anywhere. I'm particularly fond of their FM7, and for raw power (though a lot more work) Reaktor is amazing. Also of note is Rebirth by Propellerheads, which is particularly handy for breakbeats if that's you're thing. It models two classic analog synths, and two classic drum synths. Finally, if you want to make serious MIDI based music, there is nothing that compares to Gigastudio by Tascam. It is by far the most expensive of them all, but well worth it. Technically Gigastudio is a sampler, not a synth. It is capable of playing back complete, believable, symphonies of sound (literally). It also takes massive amounts of CPU/RAM and only runs on PC.
The final aspect to go for is the audio/MIDI hardware itself. The reason this comes last is quite simply because certain hardware works best with certain software. With that in mind it's hard to give recommendations. You will need two pieces of hardware: the audio interface, and the MIDI interface. Audio hardware is a bit less proprietary than MIDI hardware, and you'll probubly be fine if you choose something that has ASIO drivers. I use a MOTU 896 Firewire interface that has 8in/8out, 8 mic preamps, and operates at up to 24bit/96kHz. That's probubly a bit overkill for what you want to do. I've also had very good success with Echo cards. The Echo Mia may well be the way to go. It's a simple stereo in/out, but will do 24bit/96kHz and has balanced TRS connectors. The Mia usually runs just under $200. Other manufacturers of note are: DigiDesign (expensive, very proprietary, but good), RME, Aardvark, and M-Audio.
The MIDI interface gets a bit touchier. I had to try a couple before I got one that really worked for me. They tend to also be more proprietary towards your sequencing software. I use a Stienberg Midex 8, which works beautifully with Nuendo and Cubase because they're both made by Steinberg, however, I wouldn't recommend it if you're not running Nuendo, Cubase or one of the other Steinberg software packages. Basically everyone uses there own protocol for MIDI, and uses a protocol called LTC for a fallback. Almost everything can use LTC, but LTC doesn't perform nearly as well as whatever proprietary protocol your software might use. Most companies that make sequencers also sell MIDI interfaces, and generally you want the one that matches your software. If you simply want one that will kindof work for everything, but not work great with anything, Midiman of Maudio makes the Midisport series that are fairly decent all around, but only use the LTC protocol. Of course, there are all shapes and sizes of MIDI interfaces, I would recommend getting one that has at least 2 in/out ports. It may be worth it to even go up to 8. On a side note, STAY AWAY from Edirol MIDI interfaces. I've had three of them go through my hands, and none of them worked.
Ok, now we have our computer, our software, and our audio/midi hardware... time to get a MIDI controler of some sort. This is where you just need to go to a few music stores and find what you want. There are a few things you want to make sure you have, but beyond that it's just all about what you like. You want to make sure you have pitch/mod control of some sort. You also want to make sure that you have a velocity sensitive controller (i.e. It sends out MIDI signals saying how hard the keys were hit/let off). You also probubly want something that works as a sustain pedal (especially if you intend to do anything that is to sound like a piano). I personally recommend getting something that has a small subset of built-in sounds. Even though they're a bit more expensive, it just augments your possibilities that much more. Everything else in the MIDI controller is more or less up to what feels good to you.
I know this ran on a bit, and is kindof haphazardly thrown together, but hopefully it can give some starting points. If you'd like to see what I have, it can be found here, but it probubly won't stand up to too awfully many hits. As a final note, a great resource for information on audio in general (including computer audio) is Harmony Central.
A million thanks to that last link you gave. I've been looking for an ASIO solution for a Live! Platinum for ages. Didn't know such a thing existed.
As far as I know, the best such drivers come from the ALSA project. In truth, there are very few multi-io cards listed as supported yet, but MOTU, Echo Audio, Yamaha and Midiman (as well as a few others) are all listed at least as being under developement. The one exception to this 'in the works' rule seems to be RME which appears to be quite well supported. Unfortunately, I see no mention of DigiDesign.
Actually multi-tracking software is in about the same state as the drivers. The most promising package I've seen is Ardour. Their package seems to be very much modeled after ProTools, at least as far as the interface goes. It supports LADSPA open-source plugins (no VST, RTAS, or DX unfortunately... mostly due to license restrictions). It already supports multi-io and many of your standard features, but lacks some things I consider necesities such as MIDI support (especially the ability to send MIDI clock and operate as a metronome... something I almost always use). None the less, there is a future for Linux and recording. It just, more or less, remains in the future for now.
Ever take a look at what Leia is wearing in RTOJ? It's nothing new.
Ever compare styles of the period when SW Ep. IV,V&VI were released to the movies? I think you'd find they're not far off. Styles of the present day apeal to the audience. They can relate to them.
As for girls showing skin. It's sexy, it's sci-fi, and it's also nothing new (and yes, it does sell). If showing skin is selling out, that happened for Lucas a long time ago.