I can generally appreciate art, especially sculpture. It genearlly takes quite a bit of skill to produce a large outdoor installation like this even if I don't like it.
But this? This is shit. It's not so much that it's made of shopping carts, but it's more that it looks like a jungle gym and the baskets are just going to fill up with leaves and trash. I can hardly believe that such a work was actually *commissioned* without seomeone thinking of this.
It's kind of like how the city I live in has recently taken to painting all of the new highway overpasses an earthy red color. I can appreciate that lots of people think that it looks nicer than bare concrete, but for what it costs, the only thing it really buys you is the need to repaint it again in 5-10 years at an equivalent (or greater) cost. If they really wanted red overpasses, they should have done it properly and dyed the concrete red to begin with.
With phrases like "triggers cell suicide" used, you have to wonder what could possibly go wrong here?!?!? Fen-Phen, anybody?
Not that it's not neat, but this would be a highly useful application for destroying the blood supply to cancer cells. Cancer typcially coaxes the body to grow a whole bunch of new blood vessles to feed itself, so if those could be targeted instead, then we'd have something actually useful instead of just an excuse to pound down those big gulps and triple cheeseburgers.
Unfortunately on the games that DID need them, having to push button combos to get the desired effect was horrible. I don't know how people even play that 007 game!
Of course, they also have the option to make something else other than X86 the base architecture upon which they support virtualized X86 (and maybe if we're lucky other cores also). It would make a lot more sense to do this kind of thing on top of something new than to stuff it all in some kind of messy architecture extension as you suggested.
Of course, this still adds to the mess either way, but it does make some sense.
Don't forget to add that the multithreading was also added to support easier/quicker/better data sharing among request handlers. Stuff like mod_perl is *really* taking advantage of this now. It also facilitates management of virtual hosts from both a resource and a security standpoint. You can have a seperate process for each vhost running in its own security context and resource limited (cpu, bandwidth, etc.) easily and then configure per-process thread/request limits for each virtual host.
Debian (testing/unstable) support for 2.0 is as good as any distro's IMO, but of course there is little to no support for it 'out of the box' on woody, and unless you go for backports.org stuff, it's kind of hard to trust some of the 3rd party deb repositories for this kind of thing.. So still it's a problem with Debian, but nothing other than what has plagued debian for all time -- releases that are actually too infrequent.
There are two big caveats here -- While there is a high end frequency cutoff for CDDA (about 22,050Hz), there technically is not a 'low end'. However, this is not to say that CD's do not have somewhat of a problem in the low, low end. In most cases, this is either the fault of the person doing the mastering not picking up on the lower end or the machine playing the cd not bothering to reproduce it (usually the latter).
It's very difficult to argue that buying newly released vinyl is in some way 'better' than buying a digital copy. Consider that even the new vinyl you buy was probably recorded and mastered digitally. Although this process was probably done with a higher resolution than CDDA gives you, it doesn't rule out other higher resolution digital formats (DAT, HDCD, DVD-Audio, etc.) being 'closer to the original' thn buying an analog reproduction. The analog record might still sound better than the CD to you simplay because you have better reproduction capabilities on your turntable than your cd player.
There is also the very valid argument that you can scratch with vinyl if this is your thing and any digital recreation of that process is pretty much crap.. But it isn't an argument you mentioned:)
I have no experience with either brand of CF card specifically, so I can't speak to whether or not one card is faster than the other, but regardless, there is a bottleneck in the PCMCIA. Your CF cards might not be coming up against it (yet) but they probably will at some point..
I have a PC-Card carrier that came with a microdrive that looks to be cardbus (but i haven't ever actually used it, so I dunno) and I have an el-cheapo "Mr. Flash" carrier also. Maybe I should try to do some benchmarks between them with the same CF card(s) and see if it makes any difference (if the microdrive carrier really is cardbus...)
If you were actually using a PCMCIA 16 bit adaptor then it's likely that you couldn't reach near 9MB/s anyway. PIO 16 bit with no buffering (there probably isn't any in your CF PCMCIA adaptor) is going to be slow as heck. The connection you get is akin to pre-UDMA hard drives. The maximum theoretical speed on 16 bit PCMCIA is 33MB/s (the same as ISA) and using PIO (since you don't get DMA using this for IDE) there is only going to be half of that (16.5MB/s) available to transfer data. Without any ram to buffer the IO you are likely going to drop your performance below what the card is even capable of.
Try your benchmark again with an IDECF adaptor plugged directly into a drive controller (or IDE/Firewire bridge if you are limited to the laptop) and see if it makes a difference. It ought to!
I kind of get a feeling that buying up the account names might be a pretty moot point when the service is actually launched... Google could always add new domain names for people to use and open the entire set of usernames on each domain. Since the only advertisement for gmail that goes out with the emails is (presumably) the @gmail.com address they could even just do subdomains or other tld's ie @gmail.net or @red.gmail.com
I doubt they'd wipe out all the existing accounts. This would seriously peeve anyone who had (in theory) actually helped them beta test the service and established the @gmail.com address as their own. Worse, if you had registered for some online banking service or similar using your gmail address, someone snatching your account out from under you on 'launch day' might be able to get into your accounts via 'request password' or similar features...
I guess you haven't seen a concrete nailer then... It's a gun that uses.22 caliber blanks to drive nails into concrete slabs. Makes a hell of a noise but it gets the job done.
They also have pneumatic ones, but they are a fortune in initial cost vs explosive ones due to the very high air pressures needed (tons more than a regular air nailer).
If they are getting that kind of speed out of an FPGA, they would be a bunch of complete stupid idiots not to develop it on into silicon. The speed advantage alone would probably put them on top of the market instantly. Heck, they could probably even offer realtime rendering at broadcast tv resolutions. Also keep in mind that FPGA's with enough gates to actually do this kind of thing cost a heck of a lot more than 12K.
Not that this kind of thing isn't coming.. I would assume that realtime raycasting is going to be the 'next big thing' in consumer graphics -- We'll probably be seeing that kind of power in the next 15 years easily...
Is this a genuine question or are you operating trolling under the assumption that this is a problem that hardware designers didn't think about?
Of course they can! Data access to disk is never necessarily serialized at any point in the process. Even the drive firmware itself tries to read requested blocks in the most optimized order possible.
On a SCSI, this feature is called command queueing. It's present in the SATA specification also, but is not a part of IDE or ATA. It's kind of a 'fire and forget' thing where you ask for the controller to do a bunch of stuff (and this can be either in arbitrary or sequential order) and it gets back to you whenever it's done with something.
You will notice that drivers for these 'hardware assisted' RAID controllers from promise and the like are implemented as SCSI devices for this precise reason, although the command queueing is still taking place inside the software driver. SATA controllers appear as SCSI devices in windows for similar reasons also. The IDE subsystems of Windows is not equipped to deal with some of these things but the SCSI subsystem always has been...
Re:You can find it googling, but here it is anyway
on
Is DOS Gaming Dead?
·
· Score: 1
Sometimes, with DOS games, that is exactly what you need to do!
Anyway, vmware/vpc/plex86 hardly introduce any more overhead than the context switching required of any other 'normal' process on the host OS. It would be more fair to say that they slow down IO while the CPU runs pretty close to normal speed.
The IO overhead will (should, at least) be the same whether it's hardware RAID or software RAID.
On a real hardware raid controller this overhead exists only on the controller CPU (normally an i960 or somesuch) and is further alleviated by the cache ram on the card.
Compared to what, though ? OS-level software RAID is going to have to do precisely the same thing and IMHO the processing involved, taken in the context of modern, fast CPUs, is insignificant.
Well, I wasn't trying to compare promise/hpt/et al. to software raid, but if the overhead of any kind of host-cpu based raid were really actually insignificant as you claim, then I guess we are all real suckers for plunking down hundreds or thousands of dollars for RAID cards.
The point is that any extra overhead whatsoever on the CPU dealing with the disk is very often unacceptable. The disk subsystem is pretty well the slowest component in any system, and having the host CPU wait around on it all the time can be a real performance killer. Take an example of building a workstation to edit HD video. This will normally use RAID 0 if it is a capturing machine or sometimes RAID 1. Build one -- or better yet build three - one using software raid, one using 'hardware-assisted' raid, and one using a genuine hardware controller.
The kind of thinking you are doing is the kind of thinking that leads to bloated software. The idea that the CPU is "fast enough" that efficency doesn't matter might be fine for the desktop in most cases, but on a server could mean the difference between supporting 3000 and 6000 users.
Well, I downloaded and installed slash sometime just after the 2.0 release to try out a few ideas I had. While the install was actually suprisingly straightforward (at least to someone familiar with mod_perl and someone who is a fairly decent perl hacker), the amount of work that would be required to extend the code was very high. HTML is output willy-nilly from all over the place. Changing the look of one page might involve editing not only a template or two (fine) but also several source files.
The more changes to the core source that happen, the harder it is to stay in sync with the rest of the codebase. After a while, nearly all of the time spent maintaining a slash site would be juggling diffs.
Notice that I did not say it was hard to ADD FEATURES to slash. The templating system could be recycled to do something like a photo gallery without a lot of trouble, but then trying to make slash accept comments on individual photos in that gallery would be a TON of work and require a lot of changes internal to the comment scripts...
Actually, they do provide one particularly useful feature and that is to present the RAIDed disks to the OS (and the BIOS) as a single device.
The int13 firmware does this for the code before the OS loads and the driver is responsible for doing this job afterwords. Don't let this software trickery fool you. Behind the veil of the driver, the system software is reading and writing to the two disks individually. The int13 stuff is a nice trick, but it's only necessary due to the inability to replace the OS's bootloader, otherwise they probably wouldn't bother with the difficult task of writing such firmware.
The software overhead for RAID1 should be, for all intents and purposes, insignificant. It just doesn't *do* anything that requires much CPU work.
Well, it does at least twice the disk IO, plus it's (hopefully) doing consistency checking by comparing the two data streams for discrepencies. The overhead of the IO is small because it's being done via DMA, but the overhead of the host cpu comparing the data during reads is quite a bit more involved. A quick glance at the linux driver for these cards will show you that there's not even any cpu offloading for this extremely simple operation -- ie how hard would it be to have the controller "read x bytes off of both of these disks and compare them and put them in this memory location or else raise an error if they don't match" -- but they can't. they have to be asked to read the data individually from each disk and then the CPU has to do the comparison. This, comparitively, is a lot of overhead.
I'm not trying to bash these products. I have used them from time to time as appropriate... but I'm sick of people putting them into situations where they don't belong. There is a reason they are so damn cheap.. they do pretty much nothing!
Re:You can find it googling, but here it is anyway
on
Is DOS Gaming Dead?
·
· Score: 1
With your soundcard there, it's most likely all the PCI bridges getting in the way of the IRQ routing. DOS has no real support for a modern APIC and the bios support for this kind of thing is falling behind because it's really unnecessary for doing anything but running a legacy OS like DOS...
You are not the first person I have seen asking about 'adapting slashcode' or 'using slash's comments engine' or something like that.
Just FYI, slashcode is damn near impossible to adapt to anything except a site that does exactly what is done here at slashdot. It's not extensible, and it's not flexible. That's not to say it is bad or is bad code. It's just special purpose. Scoop is the same way. Other site engines that did not grow out of a specific site are generally more adaptable.
There is a very important thing that you have not realized...
Those are not really true hardware RAID controllers. They are regular hacked up IDE controllers with a bit of BIOS firmware on them that handles software RAID via INT13 until the OS loads and the software RAID in the "driver" can take over.
They offer nothing that a legitimate hardware raid setup should give you such as cache RAM or CPU offloading. Mirrored setups on these types of pseudo-hardware RAID controllers HURTS PERFORMANCE. Don't believe me? Benchmark it yourself versus software raid and hardware raid on a real controller such as Adaptec AAA or 3ware...
Re:You can find it googling, but here it is anyway
on
Is DOS Gaming Dead?
·
· Score: 2, Insightful
Yeah it's that 386 protected mode that is really the problem with dosbox or dosemu... They are coming along though. The NTVDM should be able to deal with dos4gw when running in fullscreen, so perhpas VDMSound would be all you need. Short of that, it'd be VMware or VirtualPC (as another reply suggested has better video support than VMWare for DOS) which should definately run it.
You can find it googling, but here it is anyway...
on
Is DOS Gaming Dead?
·
· Score: 4, Informative
A few ways I know of that work pretty well:
1) DOSBox is a really good dos environment. I have no idea how old the article submitters "really old" games are, exactly, but they'd have to be pretty new to have a problem on DOSBox. It can even run Windows 3.1. I'm betting pretty hard on a misconfiguration here. It has Linux compatiblity, too! (And OS/X using bochs cores for the diehard folks out there)
2) VDMSound can be used to emulate legacy sound hardware in the NT (2000,XP) VDM. A lot of games too new to really run well in DOSBox but require legacy sound support that is not provided while in windows may find it helpful.
3) Dual boot DOS! Scary, yes, and it usually requires a REAL legacy (or compatible) soundblaster to make work, but obviously it yields very nice results with more recent DOS titles.
4) DOS in VMWare. VMWare will emulate legacy soundblaster 16 hardware, so a lot of dos games will work great here. It's more heavyweight than DOSBox, but it also costs some money.. So it might not really be worth it just to play a game or two...
Anyway, that's about it... If you are really dedicated, just go to a comptuer swap meet and build yourself a DOS game rig out of some old 486 or something. It probably wouldn't cost you more than $50 for a decent setup (P66 - P100) machine and you could maybe even swing a PCI bus!
Not that it is any validation for this survey, but I thought I'd mention an interesting thing -- I finally got my grandfather to switch to broadband a couple of years ago since he was always complaining about getting dropped off of dialup and the extra cost of a second dedicated phone line for the computer.
Get this, though -- he has 64Kbit/s (asymetric) cable modem service. I am astounded that they even continue to support this service level. He signed up under some 'same price as dialup' promotion and never upgraded to the 1 (now 3) megabit service level. While it is faster than a modem, it's still pretty eery how it creeps along. I'm suprised the virus problems haven't slowed the throttled connection down to unusable speeds. He's happy with it, even though, so what can I say?
Some of these programs create certain files and registry keys when they are installed; but many applications create MORE files and registry keys when they are first run or possibly even each time they are started... This is particularly true of spyware-containing applications that check to make sure the spyware is there and active each time they start up. Monitoring the installer is only half the battle.
Re:Viruses on Linux? Yeah, right.
on
Linux in Canada
·
· Score: 1
It pretty well takes user stupidity to infect yourself on windows these days, too, though. It's not that there aren't any security holes in the OS or Outlook/Outlook Express that virus writers have exploited, but most of the problem is still technically the 'trojan-horses' that people run unknowingly.
The other solution for a home-type charger would be to keep a large device like an ultracapacitor or big lead acid battery at the ready to deliver the juice when you need to charge a few batteries. This device could be charged at leisure. Getting enough energy out of a car battery, for instance, to charge a whole bunch of D cells is a pretty moderate cycle. They can deliver a lot of amps and they hold a lot more energy. It would last a long time. In an industrial application such as tool batteries at construction sites etc could be run with bigger, beefier chargers that draw directly from the grid.
Slashdot Mirror
I can generally appreciate art, especially sculpture. It genearlly takes quite a bit of skill to produce a large outdoor installation like this even if I don't like it.
But this? This is shit. It's not so much that it's made of shopping carts, but it's more that it looks like a jungle gym and the baskets are just going to fill up with leaves and trash. I can hardly believe that such a work was actually *commissioned* without seomeone thinking of this.
It's kind of like how the city I live in has recently taken to painting all of the new highway overpasses an earthy red color. I can appreciate that lots of people think that it looks nicer than bare concrete, but for what it costs, the only thing it really buys you is the need to repaint it again in 5-10 years at an equivalent (or greater) cost. If they really wanted red overpasses, they should have done it properly and dyed the concrete red to begin with.
With phrases like "triggers cell suicide" used, you have to wonder what could possibly go wrong here?!?!? Fen-Phen, anybody?
Not that it's not neat, but this would be a highly useful application for destroying the blood supply to cancer cells. Cancer typcially coaxes the body to grow a whole bunch of new blood vessles to feed itself, so if those could be targeted instead, then we'd have something actually useful instead of just an excuse to pound down those big gulps and triple cheeseburgers.
Unfortunately on the games that DID need them, having to push button combos to get the desired effect was horrible. I don't know how people even play that 007 game!
Of course, they also have the option to make something else other than X86 the base architecture upon which they support virtualized X86 (and maybe if we're lucky other cores also). It would make a lot more sense to do this kind of thing on top of something new than to stuff it all in some kind of messy architecture extension as you suggested.
Of course, this still adds to the mess either way, but it does make some sense.
Maybe that's why Transmeta did it.
Don't forget to add that the multithreading was also added to support easier/quicker/better data sharing among request handlers. Stuff like mod_perl is *really* taking advantage of this now. It also facilitates management of virtual hosts from both a resource and a security standpoint. You can have a seperate process for each vhost running in its own security context and resource limited (cpu, bandwidth, etc.) easily and then configure per-process thread/request limits for each virtual host.
Debian (testing/unstable) support for 2.0 is as good as any distro's IMO, but of course there is little to no support for it 'out of the box' on woody, and unless you go for backports.org stuff, it's kind of hard to trust some of the 3rd party deb repositories for this kind of thing.. So still it's a problem with Debian, but nothing other than what has plagued debian for all time -- releases that are actually too infrequent.
There are two big caveats here -- While there is a high end frequency cutoff for CDDA (about 22,050Hz), there technically is not a 'low end'. However, this is not to say that CD's do not have somewhat of a problem in the low, low end. In most cases, this is either the fault of the person doing the mastering not picking up on the lower end or the machine playing the cd not bothering to reproduce it (usually the latter).
:)
It's very difficult to argue that buying newly released vinyl is in some way 'better' than buying a digital copy. Consider that even the new vinyl you buy was probably recorded and mastered digitally. Although this process was probably done with a higher resolution than CDDA gives you, it doesn't rule out other higher resolution digital formats (DAT, HDCD, DVD-Audio, etc.) being 'closer to the original' thn buying an analog reproduction. The analog record might still sound better than the CD to you simplay because you have better reproduction capabilities on your turntable than your cd player.
There is also the very valid argument that you can scratch with vinyl if this is your thing and any digital recreation of that process is pretty much crap.. But it isn't an argument you mentioned
I have no experience with either brand of CF card specifically, so I can't speak to whether or not one card is faster than the other, but regardless, there is a bottleneck in the PCMCIA. Your CF cards might not be coming up against it (yet) but they probably will at some point..
I have a PC-Card carrier that came with a microdrive that looks to be cardbus (but i haven't ever actually used it, so I dunno) and I have an el-cheapo "Mr. Flash" carrier also. Maybe I should try to do some benchmarks between them with the same CF card(s) and see if it makes any difference (if the microdrive carrier really is cardbus...)
If you were actually using a PCMCIA 16 bit adaptor then it's likely that you couldn't reach near 9MB/s anyway. PIO 16 bit with no buffering (there probably isn't any in your CF PCMCIA adaptor) is going to be slow as heck. The connection you get is akin to pre-UDMA hard drives. The maximum theoretical speed on 16 bit PCMCIA is 33MB/s (the same as ISA) and using PIO (since you don't get DMA using this for IDE) there is only going to be half of that (16.5MB/s) available to transfer data. Without any ram to buffer the IO you are likely going to drop your performance below what the card is even capable of.
Try your benchmark again with an IDECF adaptor plugged directly into a drive controller (or IDE/Firewire bridge if you are limited to the laptop) and see if it makes a difference. It ought to!
I kind of get a feeling that buying up the account names might be a pretty moot point when the service is actually launched... Google could always add new domain names for people to use and open the entire set of usernames on each domain. Since the only advertisement for gmail that goes out with the emails is (presumably) the @gmail.com address they could even just do subdomains or other tld's ie @gmail.net or @red.gmail.com
I doubt they'd wipe out all the existing accounts. This would seriously peeve anyone who had (in theory) actually helped them beta test the service and established the @gmail.com address as their own. Worse, if you had registered for some online banking service or similar using your gmail address, someone snatching your account out from under you on 'launch day' might be able to get into your accounts via 'request password' or similar features...
I guess you haven't seen a concrete nailer then... It's a gun that uses .22 caliber blanks to drive nails into concrete slabs. Makes a hell of a noise but it gets the job done.
They also have pneumatic ones, but they are a fortune in initial cost vs explosive ones due to the very high air pressures needed (tons more than a regular air nailer).
A logic argument --
If they are getting that kind of speed out of an FPGA, they would be a bunch of complete stupid idiots not to develop it on into silicon. The speed advantage alone would probably put them on top of the market instantly. Heck, they could probably even offer realtime rendering at broadcast tv resolutions. Also keep in mind that FPGA's with enough gates to actually do this kind of thing cost a heck of a lot more than 12K.
Not that this kind of thing isn't coming.. I would assume that realtime raycasting is going to be the 'next big thing' in consumer graphics -- We'll probably be seeing that kind of power in the next 15 years easily...
Is this a genuine question or are you operating trolling under the assumption that this is a problem that hardware designers didn't think about?
Of course they can! Data access to disk is never necessarily serialized at any point in the process. Even the drive firmware itself tries to read requested blocks in the most optimized order possible.
On a SCSI, this feature is called command queueing. It's present in the SATA specification also, but is not a part of IDE or ATA. It's kind of a 'fire and forget' thing where you ask for the controller to do a bunch of stuff (and this can be either in arbitrary or sequential order) and it gets back to you whenever it's done with something.
You will notice that drivers for these 'hardware assisted' RAID controllers from promise and the like are implemented as SCSI devices for this precise reason, although the command queueing is still taking place inside the software driver. SATA controllers appear as SCSI devices in windows for similar reasons also. The IDE subsystems of Windows is not equipped to deal with some of these things but the SCSI subsystem always has been...
Sometimes, with DOS games, that is exactly what you need to do!
Anyway, vmware/vpc/plex86 hardly introduce any more overhead than the context switching required of any other 'normal' process on the host OS. It would be more fair to say that they slow down IO while the CPU runs pretty close to normal speed.
The IO overhead will (should, at least) be the same whether it's hardware RAID or software RAID.
On a real hardware raid controller this overhead exists only on the controller CPU (normally an i960 or somesuch) and is further alleviated by the cache ram on the card.
Compared to what, though ? OS-level software RAID is going to have to do precisely the same thing and IMHO the processing involved, taken in the context of modern, fast CPUs, is insignificant.
Well, I wasn't trying to compare promise/hpt/et al. to software raid, but if the overhead of any kind of host-cpu based raid were really actually insignificant as you claim, then I guess we are all real suckers for plunking down hundreds or thousands of dollars for RAID cards.
The point is that any extra overhead whatsoever on the CPU dealing with the disk is very often unacceptable. The disk subsystem is pretty well the slowest component in any system, and having the host CPU wait around on it all the time can be a real performance killer. Take an example of building a workstation to edit HD video. This will normally use RAID 0 if it is a capturing machine or sometimes RAID 1. Build one -- or better yet build three - one using software raid, one using 'hardware-assisted' raid, and one using a genuine hardware controller.
The kind of thinking you are doing is the kind of thinking that leads to bloated software. The idea that the CPU is "fast enough" that efficency doesn't matter might be fine for the desktop in most cases, but on a server could mean the difference between supporting 3000 and 6000 users.
Well, I downloaded and installed slash sometime just after the 2.0 release to try out a few ideas I had. While the install was actually suprisingly straightforward (at least to someone familiar with mod_perl and someone who is a fairly decent perl hacker), the amount of work that would be required to extend the code was very high. HTML is output willy-nilly from all over the place. Changing the look of one page might involve editing not only a template or two (fine) but also several source files.
The more changes to the core source that happen, the harder it is to stay in sync with the rest of the codebase. After a while, nearly all of the time spent maintaining a slash site would be juggling diffs.
Notice that I did not say it was hard to ADD FEATURES to slash. The templating system could be recycled to do something like a photo gallery without a lot of trouble, but then trying to make slash accept comments on individual photos in that gallery would be a TON of work and require a lot of changes internal to the comment scripts...
Actually, they do provide one particularly useful feature and that is to present the RAIDed disks to the OS (and the BIOS) as a single device.
The int13 firmware does this for the code before the OS loads and the driver is responsible for doing this job afterwords. Don't let this software trickery fool you. Behind the veil of the driver, the system software is reading and writing to the two disks individually. The int13 stuff is a nice trick, but it's only necessary due to the inability to replace the OS's bootloader, otherwise they probably wouldn't bother with the difficult task of writing such firmware.
The software overhead for RAID1 should be, for all intents and purposes, insignificant. It just doesn't *do* anything that requires much CPU work.
Well, it does at least twice the disk IO, plus it's (hopefully) doing consistency checking by comparing the two data streams for discrepencies. The overhead of the IO is small because it's being done via DMA, but the overhead of the host cpu comparing the data during reads is quite a bit more involved. A quick glance at the linux driver for these cards will show you that there's not even any cpu offloading for this extremely simple operation -- ie how hard would it be to have the controller "read x bytes off of both of these disks and compare them and put them in this memory location or else raise an error if they don't match" -- but they can't. they have to be asked to read the data individually from each disk and then the CPU has to do the comparison. This, comparitively, is a lot of overhead.
I'm not trying to bash these products. I have used them from time to time as appropriate... but I'm sick of people putting them into situations where they don't belong. There is a reason they are so damn cheap.. they do pretty much nothing!
With your soundcard there, it's most likely all the PCI bridges getting in the way of the IRQ routing. DOS has no real support for a modern APIC and the bios support for this kind of thing is falling behind because it's really unnecessary for doing anything but running a legacy OS like DOS...
You are not the first person I have seen asking about 'adapting slashcode' or 'using slash's comments engine' or something like that.
Just FYI, slashcode is damn near impossible to adapt to anything except a site that does exactly what is done here at slashdot. It's not extensible, and it's not flexible. That's not to say it is bad or is bad code. It's just special purpose. Scoop is the same way. Other site engines that did not grow out of a specific site are generally more adaptable.
There is a very important thing that you have not realized...
Those are not really true hardware RAID controllers. They are regular hacked up IDE controllers with a bit of BIOS firmware on them that handles software RAID via INT13 until the OS loads and the software RAID in the "driver" can take over.
They offer nothing that a legitimate hardware raid setup should give you such as cache RAM or CPU offloading. Mirrored setups on these types of pseudo-hardware RAID controllers HURTS PERFORMANCE. Don't believe me? Benchmark it yourself versus software raid and hardware raid on a real controller such as Adaptec AAA or 3ware...
Yeah it's that 386 protected mode that is really the problem with dosbox or dosemu... They are coming along though. The NTVDM should be able to deal with dos4gw when running in fullscreen, so perhpas VDMSound would be all you need. Short of that, it'd be VMware or VirtualPC (as another reply suggested has better video support than VMWare for DOS) which should definately run it.
A few ways I know of that work pretty well:
1) DOSBox is a really good dos environment. I have no idea how old the article submitters "really old" games are, exactly, but they'd have to be pretty new to have a problem on DOSBox. It can even run Windows 3.1. I'm betting pretty hard on a misconfiguration here. It has Linux compatiblity, too! (And OS/X using bochs cores for the diehard folks out there)
2) VDMSound can be used to emulate legacy sound hardware in the NT (2000,XP) VDM. A lot of games too new to really run well in DOSBox but require legacy sound support that is not provided while in windows may find it helpful.
3) Dual boot DOS! Scary, yes, and it usually requires a REAL legacy (or compatible) soundblaster to make work, but obviously it yields very nice results with more recent DOS titles.
4) DOS in VMWare. VMWare will emulate legacy soundblaster 16 hardware, so a lot of dos games will work great here. It's more heavyweight than DOSBox, but it also costs some money.. So it might not really be worth it just to play a game or two...
Anyway, that's about it... If you are really dedicated, just go to a comptuer swap meet and build yourself a DOS game rig out of some old 486 or something. It probably wouldn't cost you more than $50 for a decent setup (P66 - P100) machine and you could maybe even swing a PCI bus!
~GoRK
Not that it is any validation for this survey, but I thought I'd mention an interesting thing -- I finally got my grandfather to switch to broadband a couple of years ago since he was always complaining about getting dropped off of dialup and the extra cost of a second dedicated phone line for the computer.
Get this, though -- he has 64Kbit/s (asymetric) cable modem service. I am astounded that they even continue to support this service level. He signed up under some 'same price as dialup' promotion and never upgraded to the 1 (now 3) megabit service level. While it is faster than a modem, it's still pretty eery how it creeps along. I'm suprised the virus problems haven't slowed the throttled connection down to unusable speeds. He's happy with it, even though, so what can I say?
Some of these programs create certain files and registry keys when they are installed; but many applications create MORE files and registry keys when they are first run or possibly even each time they are started... This is particularly true of spyware-containing applications that check to make sure the spyware is there and active each time they start up. Monitoring the installer is only half the battle.
It pretty well takes user stupidity to infect yourself on windows these days, too, though. It's not that there aren't any security holes in the OS or Outlook/Outlook Express that virus writers have exploited, but most of the problem is still technically the 'trojan-horses' that people run unknowingly.
The other solution for a home-type charger would be to keep a large device like an ultracapacitor or big lead acid battery at the ready to deliver the juice when you need to charge a few batteries. This device could be charged at leisure. Getting enough energy out of a car battery, for instance, to charge a whole bunch of D cells is a pretty moderate cycle. They can deliver a lot of amps and they hold a lot more energy. It would last a long time. In an industrial application such as tool batteries at construction sites etc could be run with bigger, beefier chargers that draw directly from the grid.