GPS gets jammed all the time, is not 100% reliable and no critical transportation application ever uses it as it's sole navigation system. When it is used, it reports any problems immediately, allowing its users to fall back to other, perhaps less convenient systems. Even a system designed in a way that can't be jammed can suffer unplanned outages for other reasons. Because operations are structured with this in mind, the potential for negative economic impact is elminated regradless of the reason for the outage.
You could say that long term jamming could have some economic impact such as decreased traffic density, though nothing like that theoretical missile hitting its target.
Are you going to re-compile the voting software, verify the that its hash matches the open-source code you inspected earlier, start the program yourself, and verify that it is infact connecting to the right tallying server? I'm afraid that you're going to have to trust the people hired by the county to do that.
Sure, all of the above can be observed and verified by qualified individuals, but by who are they? What precentage of the population do the make up, versus the precentage capable of "observing" a paper election?
Ceratainly e-voting is useful, because it can speed the process, and can help eliminate some user error, but it must be 100% auditable by ordinary citizens.
If we strive to make voting easier, more accessible and more efficient, we must not do it at the expense of the ability for oridanary citizens to verify the process.
In my experience SCSI drives usually make a machine faster. Here are several reasons why:
As others have pointed out SCSI supports TCQ.
Most SCSI controllers have dedicated circuits and processor(s) while IDE motherboard based chipsets utilize the main CPU; most people use their on-board controllers.
In browsing the Microsoft DDK documentation, I think I remember reading something along the lines of the following: File System drivers are written to produce SCSI commands. If the target drive is SCSI the command get sent to controller driver. If the target drive is IDE, the commands get routed to the IDE driver which translates the commands to IDE and then routes them to IDE chipset driver. The extra layer requires more CPU. I suspect Linux FS drivers are similar.
If your system is only moving data between disks, not much of a difference between SCSI and IDE. If you're trying to run something else at the same time (more likely on a server) you'll notice.
Slashdot Mirror
I don't know, but to me that comment sounded an awful lot like bleating....
Perhaps a slightly different species of sheep though....
GPS gets jammed all the time, is not 100% reliable and no critical transportation application ever uses it as it's sole navigation system. When it is used, it reports any problems immediately, allowing its users to fall back to other, perhaps less convenient systems. Even a system designed in a way that can't be jammed can suffer unplanned outages for other reasons. Because operations are structured with this in mind, the potential for negative economic impact is elminated regradless of the reason for the outage.
You could say that long term jamming could have some economic impact such as decreased traffic density, though nothing like that theoretical missile hitting its target.
And if you think thats complicated try voter registration...
Sure, all of the above can be observed and verified by qualified individuals, but by who are they? What precentage of the population do the make up, versus the precentage capable of "observing" a paper election?
Ceratainly e-voting is useful, because it can speed the process, and can help eliminate some user error, but it must be 100% auditable by ordinary citizens.
If we strive to make voting easier, more accessible and more efficient, we must not do it at the expense of the ability for oridanary citizens to verify the process.
In my experience SCSI drives usually make a machine faster. Here are several reasons why:
As others have pointed out SCSI supports TCQ.
Most SCSI controllers have dedicated circuits and processor(s) while IDE motherboard based chipsets utilize the main CPU; most people use their on-board controllers.
In browsing the Microsoft DDK documentation, I think I remember reading something along the lines of the following: File System drivers are written to produce SCSI commands. If the target drive is SCSI the command get sent to controller driver. If the target drive is IDE, the commands get routed to the IDE driver which translates the commands to IDE and then routes them to IDE chipset driver. The extra layer requires more CPU. I suspect Linux FS drivers are similar.
If your system is only moving data between disks, not much of a difference between SCSI and IDE. If you're trying to run something else at the same time (more likely on a server) you'll notice.