You're nuts. Good CF cards are an order of magnitude (maybe even close to two orders when reading) faster than USB 1 (1.1). Of course, they aren't when you use it with a USB card reader.
Actually, more than that, I wonder if he's running the client on both the SH4 core cpu AND the ARM sound cpu:) He'd definately get a nice increase running on both CPU's!
Actually, remapping the keys for use in the normal calculator modes is not a very simple thing to do on the TI calcs. You'd have to register an interrupt handler, and I think the only free memory the calc won't shuffle around is the memory used for the graphics screen. So, while you had the buttons remapped, you couldn't graph.
Note: I am sure that is correct for the TI-82 and 85. I don't know if the Asm handlers for the TI-83 or 86 have better facilities for interrupt handlers or not. I'm willing to bet they do not.
Licopodium powder (especially) or even flour works a lot better for the fireball trick. Another handy tip for lab fireballs is to attach a funnel to the end of the hose that contains the powder. You can pack a lot more in there that way, plus it will shield your hand if you wish to hold it near the end.
The SMT equipment vendor says that it's unnecessary, and I would tend to agree.
Do you really expect the vendor to tell you to do something that will reduce the amount of product that you purchase?
That's like a lightbulb manufacturer including a pamphlet within each box of lightbulbs explaining that you can make incandescent lightbulbs last a lot longer if you slowly dim them on and off rather than flipping the switch to instant full voltage.
Try a Soekris Engineering Net4501. It's an AMD Elan 133MHz processor based SBC with a slot for a CompactFlash card (up to 1GB microdrive), 3 10/100 ethernet interfaces, a serial port (console), a MiniPCI slot, and a 3.3v PCI slot. Best of all, it's inexpensive.
http://www.soekris.com/
It works great as my router. I know you said you didn't want an SBC, but I think that you probably just don't know that you really do want one:)
Generally, if you want to upgrade to a different type of memory, you want to upgrade to a different type of motherboard, and probably a different type of CPU. I don't think it's such a bad thing. "This motherboard is designed for DDR memory and a DDR compatible CPU!"
It amazes me that you know all about the instruction sets of your CPU's, but have zero clue when it comes to some basic logic. The mac has a better CDRW drive. It can probably is a CAV drive (guess) and can read CDDA consistantly at 16-32X. Rip the CD's to wav files or something uncompressed and test the speed of that, then test the speed of comrpession. Read results, compare, evaluate.
Coming soon to a subway near you, ANIMATED GRAFFITI!
Apparently, the hoodlums spray paint a bunch of individual pictures right next to each other so that passengers on a train speeding by are greeted with a pleasant short film about pimping and whoring. The effect has been likened to a giant "flip book."
Very cool! I built this hack in like 1993, and it was hard to find a power glove even then. Now, it must be rather impossible.
A tip for hax0rs: The power glove is very SMALL (even the large one). I completely dispensed with the original glove that came with it to make mine. I took the control pad off and put a simple belt clip on it. Next, i extended the hand part and the ultrasonic sounders away from the controller with some 15 conductor cable. Finally, I sewed the finger bend sensors onto the fingers of a golf glove that went on the right hand and had the fingertips cut out (the original power glove is a lefty device.) Anyway, the idea was to get rid of the bulky garbage of the powerglove in order to make a little dataglove that i could still type while wearing.
I still have it here. Heck, I still have the monitor with the velcro on it! I'm very excited to break it out again and fiddle with this.
~GoRK
Re:Never going to happen!
on
Wireless PS/2?
·
· Score: 2
I was not aware of that. That's cool.
In any case, since a wireless device generally requires extensive configuration to be able to attach to the network above and beyond the usual simplicity of plugging in the cable required of a normal nic, it may be likely that no games ever support such a device directly.
However, a very keen third party product would be to create a clone of the sony ethernet adaptor (it's probably mostly standard parts anyway) that has a built in wireless bridge. A little eeprom on the adaptor would let you boot a configuration cd to set up your WLAN settings and save them to the card. Then the regular TCP/IP stuff in the game would work just fine.
~GoRK
Never going to happen!
on
Wireless PS/2?
·
· Score: 3, Insightful
I wouldn't expect any old USB ethernet adaptor to work with the Playstation2, particularly a wireless one. Since they are selling/distributing their own network adapter, I'm guessing that unless Sony releases a compatible wireless adaptor (doubtful), you'll have to use their ethernet adaptor no matter what.
Remember, since each game CD/DVD contains the operating software, that same CD will have to include the software (drivers) to operate the network device. Having only a single piece of hardware means that you'll be insured compatibility for every ethernet-using game.
So, that means you'll have to use a wireless ethernet tranciever of some sort.
For instance: http://www.linksys.com/products/product.asp?grid=2 2&prid=432
PS 2 Linux or something is a different story. You likely could get a usb wireless adaptor working with that -- but it wouldn't work on any games.
Go fuck yourself. It was not worth my time or effort to reply to your first comment, but I give enough of a shit to at least give you some pointers and counter your misinformation. I don't want someone else to read your comment and think "Oh the SB Live doesnt work in Linux" and be discouraged from trying something new just because you are ignorant and impatient.
If you successfully installed the driver and tools, then you had to have opened the same readme file that tells you how to edit the configuration. It's the one that starts "Installation Instruction for emu-tools-0.9.4 " and then right after that there is a section titled "GETTING STARTED". Did you actually RUN the X mixer? Did you RUN the init script or set it to auto run in the modules.conf? Did you open up the setup window in xine and check the "Enable AC3 Passthrough" or "Enable 5 speaker output"?
Just a heads up... You will get a hell of a lot farther posting a polite question to the emu10k1 mailing list than just complaining on/. about your inability to think for yourself.
It's amazine to me how you can gripe gripe gripe about shitty drivers for a soundcard that over the last two years has become one of the best supported (as far as features vs a windows driver) soundcards in linux!
http://sourceforge.net/projects/emu10k1
Your stereo sound comes from your failure to install any of the supporting tools that you need to do full output. [Ie you are a dipshit.] It's kind of like installing windows 2000 onto the same card. It will work (stereo only) - but none of the fancy stuff until you install the creative software.
With the SB Live! 5.1 in linux you can:
- Access all of the inputs and outputs on the back of the card, on the internal headers, and on the livedrive, and even some extra audio channels accessible to you if you are handy with a soldering iron.
- Indepently route, fade, and mix said audio channels around however you want - CD analog internal header plays to rear, PCM plays to front, center, sub, etc. The windows driver does NOT allow you to get this much control of things. With this mixer, you can bypass an effects channel on one source and leave it active on another, etc. You can set up routes so that you can cue music on your headphones plugged into the livedrive while you play other music from the speakers.
- 5.1 analog output using the digital out as the center/sub analog (analogous to the windows drivers, but the application must support it - xine does)
- 4.1 output - upmixed from stereo PCM (note that you cambridge speakers will also do this from a regular stereo stream. When you hear sound from the sub/4 speakers in windows, this is what you are hearing. It's just stereo upmixed by the card. The cambridge speakers actually do a better job of this than the card anyway. I'd suggest you try setting your speakers to something like the movie setting and see how it works when you are just playing stereo.
- Raw digital passthrough of Dolby AC3 and DTS for decoding by your speakers. (Again the applicaton must support it - xine does)
- OpeaAL 3D positioning with 2, 2.1, 4, 4.1, 5.1 speaker setups (The game must support OpenAL - Admittedly, not a lot do, but such is life)
- Infrared support with the LiveDrive IR. The interface is funky (The messages come in as MIDI system messages on/dev/midi), so apps like LIRC don't yet support it, but there are a number of launchers, etc. that can use the IR functions of the LiveDrive)
- full support of external MIDI devices and fm synthesis. Admittedly absent in the OSS driver is the support for wavetable synthesis. This is provided by the ALSA driver if you need it
- direct access to the emu10k1 DSP and management of patches so you can write your own effects or control your sound in some really cool ways. (The tools contain the as10k1 assembler).. You could put a codec on the card, for instance -- make the emu10k1 itself encode/decode mp3, ac3, or something similar, write a crazy distortion filter, whatever. (The AC3 passthrough uses a custom patch to accomplish it) The possibilities here are really quite endless and something you will never be able to do with the windows driver.
Incedentally, the driver at http://sourceforge.net/projects/emu10k1 is really just a newer version of the driver in the kernel. The kernel driver (with the tools provided at the above mentioned site) can do all of the things listed above. The main reason to get the driver tarball or CVS version from the emu10k1 folks is if you need good audigy support.
There is no support for any PCMCIA sound card in Linux. You would have to write quite a lot of kernel glue before you could even begin to write a driver. Sorry:(
I would suggest using a USB sound device of some sort if this is for a notebook computer. If that is not an option, then use a USB PCMCIA card and run the USB sound dongle off of that. This will be your best bet.
Some pc BIOS can boot off of an ATAPI device hooked to USB, such as an Iomega Zip drive or a compact flash card or somesuch; however, the implementations vary WILDLY on how this is accomplished. Booting from said devices involves much fakery in what is usually presented to a bootloader as either a virtual floppy drive or a virtual hard disk. The fakery involved in booting from USB is even more complicated than booting from a CD-ROM, for which there is (at least) a standard that most bioses somewhat support.
Your bootloader (lilo, grub, etc.) can indeed bootstrap the kernel from a USB connected boot media; however, you will have to configure it differently based on which kind of device (floppy or HDD) your bios simulates for a USB boot. IE if your bios simulates a floppy drive, you'll have to tell lilo/grub/etc to load the kernel from the bios's floppy drive (here, bios calls to the floppy drive are rerouted to the usb device). Incedentally, this is the way CD-ROM booting works, but CD-ROM booting is MUCH simpler since an image file in a special area of the CD-ROM sits in for the virtual drive.
Anyway, most USB booting bioses are going to be simulating hard drives anyway due to the size of most usb media, so all you have to do is set up lilo to boot from the first bios hdd (ie 0x80) and you're set there.
Now on the subject of actually bringing the OS up - well that is the fun part. You can not (as the parent post said) just have "usb support compiled in" to make linux boot. USB doesnt exactly work that way in Linux. You can indeed have your usb controller driver, the usb mass storage driver, etc. all compiled statically with the kernel (not modules), but you're still going to have to start the hotplug daemon to get the setup functional to where you can use the connected device, and that's not going to happen without a root filesystem.
So, you need an initrd. No problem provided you can get lilo or grub or whateverelse to find and load it. All your initrd needs to do is to load up your USB modules, mount your root fs off of usb mass storage (/dev/sda1 or whatever weird devfs name you use) and then pivot_root over to it. This is mostly equivalent to an initrd setup for something like a network booting system that uses NFS root or fibre channel or something like that. Any initrd HOWTO will cover setting up an initrd that loads modules and performs configuration to mount the root device that the kernel cannot do on its own.
Sorry for the long ramble. Booting linux from USB is possible; however, it is not for the faint of heart. If you get it to work, it will probably not work for every motherboard that claims to allow usb booting. Any modern version of Windows will most not boot this way. (Well, technically you could load windows 3.11 or earlier in real mode like this, and maybe even windows 95/98 in safe mode)
FYI, a good place to start looking is the HOWTO's that involve installing linux onto subnotebooks without internal CDROM or Floppy. A lot of these sites provide floppy images that can boostrap an installation system (ie linux) from a USB connected floppy or cdrom drive. The USB booting on these laptops is probably quite a bit more solid than the equivalent on any desktop motherboard.
A big clarification I would like to make here is that most cheap "hardware raid" controllers are NOT hardware raid controllers. They are clever hacks to implement RAID using a combination of a bios handler for software RAID and an OS driver implementing software RAID at the driver level. That is why linux md running raid5 is often faster - the implementation is better than the device driver provides.
Now, when comparing performance to a real live IDE RAID controller (Adaptec AAA or 3Ware, etc.), it is not as fast. These controllers have an on chip implementation of RAID 5 (ie hardware XOR etc. usually implemented on an intel i960 or somesuch) and perhaps some cache memory, and they interface with the OS using the standard SCSI drive api.
Now software raid 0 or raid 1 is often just as fast as hardware raid 0 or 1 because the implementation is so simple and the drive r/w speeds are the limiting factor.
BTW: does anyone know exactly what to call things like the promise and Highpoint "Raid" controllers that rely on BIOS hooks and software drivers to do the RAID dirty work? -- "Hardware" doesnt work and "Software" doesnt work -- is there a word for it?!?
So tunnel subversion over ssh. Do your key auth and port 80 redirection with ssh, then use subversion just like the server was running on your local machine.
Slashdot Mirror
You're nuts. Good CF cards are an order of magnitude (maybe even close to two orders when reading) faster than USB 1 (1.1). Of course, they aren't when you use it with a USB card reader.
Did you buy it just to sell it on ebay for a few bucks profit?
Well, wasnt AoTC shot "all digital" ... seems they would not need to remaster a bunch of 35mm film for this one.
~GoRK
Well, the difference between a laser turntable and a laserdisc player is substantial, but I won't get into that.
OTOH, why don't you take a look at Vinyl Video and then you can get deeper into thought.
Actually, more than that, I wonder if he's running the client on both the SH4 core cpu AND the ARM sound cpu :) He'd definately get a nice increase running on both CPU's!
Actually, remapping the keys for use in the normal calculator modes is not a very simple thing to do on the TI calcs. You'd have to register an interrupt handler, and I think the only free memory the calc won't shuffle around is the memory used for the graphics screen. So, while you had the buttons remapped, you couldn't graph.
Note: I am sure that is correct for the TI-82 and 85. I don't know if the Asm handlers for the TI-83 or 86 have better facilities for interrupt handlers or not. I'm willing to bet they do not.
~GoRK
Licopodium powder (especially) or even flour works a lot better for the fireball trick. Another handy tip for lab fireballs is to attach a funnel to the end of the hose that contains the powder. You can pack a lot more in there that way, plus it will shield your hand if you wish to hold it near the end.
~GoRK
Yep! I used it, tried some development with it, and filed bug reports. I was dissapointed that they did not make another public release available.
I have no doubt that they have most of OS/X and it's components running on X86 internally.
The SMT equipment vendor says that it's unnecessary, and I would tend to agree.
Do you really expect the vendor to tell you to do something that will reduce the amount of product that you purchase?
That's like a lightbulb manufacturer including a pamphlet within each box of lightbulbs explaining that you can make incandescent lightbulbs last a lot longer if you slowly dim them on and off rather than flipping the switch to instant full voltage.
Try a Soekris Engineering Net4501. It's an AMD Elan 133MHz processor based SBC with a slot for a CompactFlash card (up to 1GB microdrive), 3 10/100 ethernet interfaces, a serial port (console), a MiniPCI slot, and a 3.3v PCI slot. Best of all, it's inexpensive.
:)
http://www.soekris.com/
It works great as my router. I know you said you didn't want an SBC, but I think that you probably just don't know that you really do want one
~GoKR
Generally, if you want to upgrade to a different type of memory, you want to upgrade to a different type of motherboard, and probably a different type of CPU. I don't think it's such a bad thing. "This motherboard is designed for DDR memory and a DDR compatible CPU!"
It amazes me that you know all about the instruction sets of your CPU's, but have zero clue when it comes to some basic logic. The mac has a better CDRW drive. It can probably is a CAV drive (guess) and can read CDDA consistantly at 16-32X. Rip the CD's to wav files or something uncompressed and test the speed of that, then test the speed of comrpession. Read results, compare, evaluate.
Coming soon to a subway near you, ANIMATED GRAFFITI!
Apparently, the hoodlums spray paint a bunch of individual pictures right next to each other so that passengers on a train speeding by are greeted with a pleasant short film about pimping and whoring. The effect has been likened to a giant "flip book."
~GoRK
Very cool! I built this hack in like 1993, and it was hard to find a power glove even then. Now, it must be rather impossible.
A tip for hax0rs: The power glove is very SMALL (even the large one). I completely dispensed with the original glove that came with it to make mine. I took the control pad off and put a simple belt clip on it. Next, i extended the hand part and the ultrasonic sounders away from the controller with some 15 conductor cable. Finally, I sewed the finger bend sensors onto the fingers of a golf glove that went on the right hand and had the fingertips cut out (the original power glove is a lefty device.) Anyway, the idea was to get rid of the bulky garbage of the powerglove in order to make a little dataglove that i could still type while wearing.
I still have it here. Heck, I still have the monitor with the velcro on it! I'm very excited to break it out again and fiddle with this.
~GoRK
I was not aware of that. That's cool.
In any case, since a wireless device generally requires extensive configuration to be able to attach to the network above and beyond the usual simplicity of plugging in the cable required of a normal nic, it may be likely that no games ever support such a device directly.
However, a very keen third party product would be to create a clone of the sony ethernet adaptor (it's probably mostly standard parts anyway) that has a built in wireless bridge. A little eeprom on the adaptor would let you boot a configuration cd to set up your WLAN settings and save them to the card. Then the regular TCP/IP stuff in the game would work just fine.
~GoRK
I wouldn't expect any old USB ethernet adaptor to work with the Playstation2, particularly a wireless one. Since they are selling/distributing their own network adapter, I'm guessing that unless Sony releases a compatible wireless adaptor (doubtful), you'll have to use their ethernet adaptor no matter what.
2 2&prid=432
Remember, since each game CD/DVD contains the operating software, that same CD will have to include the software (drivers) to operate the network device. Having only a single piece of hardware means that you'll be insured compatibility for every ethernet-using game.
So, that means you'll have to use a wireless ethernet tranciever of some sort.
For instance: http://www.linksys.com/products/product.asp?grid=
PS 2 Linux or something is a different story. You likely could get a usb wireless adaptor working with that -- but it wouldn't work on any games.
~GoRK
Go fuck yourself. It was not worth my time or effort to reply to your first comment, but I give enough of a shit to at least give you some pointers and counter your misinformation. I don't want someone else to read your comment and think "Oh the SB Live doesnt work in Linux" and be discouraged from trying something new just because you are ignorant and impatient.
/. about your inability to think for yourself.
If you successfully installed the driver and tools, then you had to have opened the same readme file that tells you how to edit the configuration. It's the one that starts "Installation Instruction for emu-tools-0.9.4 " and then right after that there is a section titled "GETTING STARTED". Did you actually RUN the X mixer? Did you RUN the init script or set it to auto run in the modules.conf? Did you open up the setup window in xine and check the "Enable AC3 Passthrough" or "Enable 5 speaker output"?
Just a heads up... You will get a hell of a lot farther posting a polite question to the emu10k1 mailing list than just complaining on
~GoRK
It's amazine to me how you can gripe gripe gripe about shitty drivers for a soundcard that over the last two years has become one of the best supported (as far as features vs a windows driver) soundcards in linux!
/dev/midi), so apps like LIRC don't yet support it, but there are a number of launchers, etc. that can use the IR functions of the LiveDrive)
http://sourceforge.net/projects/emu10k1
Your stereo sound comes from your failure to install any of the supporting tools that you need to do full output. [Ie you are a dipshit.] It's kind of like installing windows 2000 onto the same card. It will work (stereo only) - but none of the fancy stuff until you install the creative software.
With the SB Live! 5.1 in linux you can:
- Access all of the inputs and outputs on the back of the card, on the internal headers, and on the livedrive, and even some extra audio channels accessible to you if you are handy with a soldering iron.
- Indepently route, fade, and mix said audio channels around however you want - CD analog internal header plays to rear, PCM plays to front, center, sub, etc. The windows driver does NOT allow you to get this much control of things. With this mixer, you can bypass an effects channel on one source and leave it active on another, etc. You can set up routes so that you can cue music on your headphones plugged into the livedrive while you play other music from the speakers.
- 5.1 analog output using the digital out as the center/sub analog (analogous to the windows drivers, but the application must support it - xine does)
- 4.1 output - upmixed from stereo PCM (note that you cambridge speakers will also do this from a regular stereo stream. When you hear sound from the sub/4 speakers in windows, this is what you are hearing. It's just stereo upmixed by the card. The cambridge speakers actually do a better job of this than the card anyway. I'd suggest you try setting your speakers to something like the movie setting and see how it works when you are just playing stereo.
- Raw digital passthrough of Dolby AC3 and DTS for decoding by your speakers. (Again the applicaton must support it - xine does)
- OpeaAL 3D positioning with 2, 2.1, 4, 4.1, 5.1 speaker setups (The game must support OpenAL - Admittedly, not a lot do, but such is life)
- Infrared support with the LiveDrive IR. The interface is funky (The messages come in as MIDI system messages on
- full support of external MIDI devices and fm synthesis. Admittedly absent in the OSS driver is the support for wavetable synthesis. This is provided by the ALSA driver if you need it
- direct access to the emu10k1 DSP and management of patches so you can write your own effects or control your sound in some really cool ways. (The tools contain the as10k1 assembler).. You could put a codec on the card, for instance -- make the emu10k1 itself encode/decode mp3, ac3, or something similar, write a crazy distortion filter, whatever. (The AC3 passthrough uses a custom patch to accomplish it) The possibilities here are really quite endless and something you will never be able to do with the windows driver.
Incedentally, the driver at http://sourceforge.net/projects/emu10k1 is really just a newer version of the driver in the kernel. The kernel driver (with the tools provided at the above mentioned site) can do all of the things listed above. The main reason to get the driver tarball or CVS version from the emu10k1 folks is if you need good audigy support.
Happy hacking, dumbass.
~GoRK
There is no support for any PCMCIA sound card in Linux. You would have to write quite a lot of kernel glue before you could even begin to write a driver. Sorry :(
I would suggest using a USB sound device of some sort if this is for a notebook computer. If that is not an option, then use a USB PCMCIA card and run the USB sound dongle off of that. This will be your best bet.
~GoRK
Ehrm, no.
OK, here is the real answer.
Some pc BIOS can boot off of an ATAPI device hooked to USB, such as an Iomega Zip drive or a compact flash card or somesuch; however, the implementations vary WILDLY on how this is accomplished. Booting from said devices involves much fakery in what is usually presented to a bootloader as either a virtual floppy drive or a virtual hard disk. The fakery involved in booting from USB is even more complicated than booting from a CD-ROM, for which there is (at least) a standard that most bioses somewhat support.
Your bootloader (lilo, grub, etc.) can indeed bootstrap the kernel from a USB connected boot media; however, you will have to configure it differently based on which kind of device (floppy or HDD) your bios simulates for a USB boot. IE if your bios simulates a floppy drive, you'll have to tell lilo/grub/etc to load the kernel from the bios's floppy drive (here, bios calls to the floppy drive are rerouted to the usb device). Incedentally, this is the way CD-ROM booting works, but CD-ROM booting is MUCH simpler since an image file in a special area of the CD-ROM sits in for the virtual drive.
Anyway, most USB booting bioses are going to be simulating hard drives anyway due to the size of most usb media, so all you have to do is set up lilo to boot from the first bios hdd (ie 0x80) and you're set there.
Now on the subject of actually bringing the OS up - well that is the fun part. You can not (as the parent post said) just have "usb support compiled in" to make linux boot. USB doesnt exactly work that way in Linux. You can indeed have your usb controller driver, the usb mass storage driver, etc. all compiled statically with the kernel (not modules), but you're still going to have to start the hotplug daemon to get the setup functional to where you can use the connected device, and that's not going to happen without a root filesystem.
So, you need an initrd. No problem provided you can get lilo or grub or whateverelse to find and load it. All your initrd needs to do is to load up your USB modules, mount your root fs off of usb mass storage (/dev/sda1 or whatever weird devfs name you use) and then pivot_root over to it. This is mostly equivalent to an initrd setup for something like a network booting system that uses NFS root or fibre channel or something like that. Any initrd HOWTO will cover setting up an initrd that loads modules and performs configuration to mount the root device that the kernel cannot do on its own.
Sorry for the long ramble. Booting linux from USB is possible; however, it is not for the faint of heart. If you get it to work, it will probably not work for every motherboard that claims to allow usb booting. Any modern version of Windows will most not boot this way. (Well, technically you could load windows 3.11 or earlier in real mode like this, and maybe even windows 95/98 in safe mode)
FYI, a good place to start looking is the HOWTO's that involve installing linux onto subnotebooks without internal CDROM or Floppy. A lot of these sites provide floppy images that can boostrap an installation system (ie linux) from a USB connected floppy or cdrom drive. The USB booting on these laptops is probably quite a bit more solid than the equivalent on any desktop motherboard.
~GoRK
Yes. And writing apps for QT/E is very similar to writing apps for KDE. Same widgets, same languages, etc.
~GoRK
PXE boot works better! Too bad your computron doesnt have it!
Frank sez hi.
Windows NT used to be available for Alpha and PowerPC
A big clarification I would like to make here is that most cheap "hardware raid" controllers are NOT hardware raid controllers. They are clever hacks to implement RAID using a combination of a bios handler for software RAID and an OS driver implementing software RAID at the driver level. That is why linux md running raid5 is often faster - the implementation is better than the device driver provides.
Now, when comparing performance to a real live IDE RAID controller (Adaptec AAA or 3Ware, etc.), it is not as fast. These controllers have an on chip implementation of RAID 5 (ie hardware XOR etc. usually implemented on an intel i960 or somesuch) and perhaps some cache memory, and they interface with the OS using the standard SCSI drive api.
Now software raid 0 or raid 1 is often just as fast as hardware raid 0 or 1 because the implementation is so simple and the drive r/w speeds are the limiting factor.
BTW: does anyone know exactly what to call things like the promise and Highpoint "Raid" controllers that rely on BIOS hooks and software drivers to do the RAID dirty work? -- "Hardware" doesnt work and "Software" doesnt work -- is there a word for it?!?
~GoRK
So tunnel subversion over ssh. Do your key auth and port 80 redirection with ssh, then use subversion just like the server was running on your local machine.