No, there is a qualitative difference. In the case of targetted killings of people who do things you don't like, the message is "don't do that"; in the case of random acts, the message is "listen to us, we'll do anything to be heard"
Wow - you must have a really inflated sense of yourself. The 'terrorists' aren't targetting you. Or really anyone else in particular. They kill, in the US, fewer people than traffic accidents. Probably fewer people than accidental firearm discharges, although the spike around 2001 makes this assertion more suspect.
Frankly, if you're going to make that argument, then argue that the government should be monitoring every bar in the nation looking for drunk drivers - you'll save more lives.
Let me mildly rephrase the analogy: Once the roads go in, a toll is set up where only Fords need to pay the toll. The analogy holds.
Show me a tollway where particular brands of cars are penalized. That, however, is the vision held up by these ISPs.
Sadly, in the case of the voting machine the voter *by design* has no receipt indicating what his transaction purported to be. Such a receipt should not be provided because it could be used for other fraudulent uses: verification of vote-buying, for instance.
A futher difference is that voting machine agregate results - that makes individual voter challenges very difficult. Hence the need to use a system that is substantially more secure than ATMs.
The lever machine sounds nice. If only it marked a paper ballot that I could read to verify, and that was counted by a small, local committee on-site. Then you could be reasonably assured that your initially reported unofficial results (read off the machine, perhaps), match the official result from the count
The machines could still be tampered with before deployment (you only have to bribe the representative from your opposite party at the machine deployment center) -- these deployment centers are an example of centralizing a process, which allows fraud to affect more ballots than a distributed system. I can trust a clear paper ballot (and there are important design decisions involved here, many of which can reduce the number of disputed ballots)
If you are counting ballot boxes locally, you will only have a small number of disputed ballots; the system doesn't fall apart that way.
The question this begs is why complicate the system? The electronic system adds little compared to the vastly increased chance of fraud.
You can have a machine mark the ballot, but the ballot must be the record, which must be the thing counted. It *must* be counted on a small scale in a distributed way to dillute the effects of any engineered fraud. Machine marking may be advantageous for reducing the number of debatable ballots, but the process should be doable without a machine: I might choose not to trust it.
What is impractical about counting 500 to 1000 ballots? It's important to keep the ballot boxes small enough that a single committee being corrupted will have little effect. Any serious party should be able to find one observer/counter per 1000 voters.
The multi-lateral committee is important - you should be able to find at least one Republican and one Democrat (plus as many independants as care) to observe/do the count. Each box should have a small enough number of ballots to count in less than an hour. Then you wind up having to buy off a *lot* of people to steal an election. Sure you can buy the count at a couple of boxes, but that's way less than you can now.
I don't know the lever machines in NY. Does every voter get to check that his vote recorded what he claimed? With paper I see my ballot, and I put it in the box: I know it says what I said. With a lever, I can imaging the machine being rigged - I now have to trust the machine provider instead of a multi-partisan counting committee. With paper if I really care I can even sign up to watch the ballot counting (in advance, I should hope, to make enough space available).
ATMs do not need to be particularly secure - customers make complaints and banks do audits. If the cost of dealing with the complaints and audits is less than the cost of the extra security, we'll continue to have
insecure ATMs.
Votes are different - no one winds up able to complain or to really even audit because of the secrecy. Instead we have to make sure that the system is as imprevious to corruption as possible. In practical terms that means low-tech and decentralized.
You can't do it by computer and have any assurance of correctness.
Vote on paper. Assign one (multi-partisan) counting committee per ballot box and count that box there, in the hour following the closing of the polls. DO NOT CENTRALIZE the counting or the counting technology. Doing so makes corruption much easier than coopting a large distributed system.
If a party can't pony up one counter per ballot box, then they have deeper problems than verifying the count for that ballot box.
I don't understand why the US continues to insist on using easily corruptible systems in their voting. (OK, I do understand, but I'm trying to be generous)
Lobby your congrescritter for *real* electoral reform and make your vote count again.
I'll say it again. Vote on paper. Count your votes at each polling place with a multi-lateral committee. Then the damage of one biassed committee is limited to that ballot box.
Centralized vote counting is the root of the corruption in the US voting system. Moving ballot boxes to "counting centers" is wrong - it allows focused corruption. Computer counting is wrong - it allows focused corruption. Distributed counting is *much* harder to coopt.
You're right - you don't design around a new processor.
But you should design around the changes in architecture that have been coming at us for the last 5-10 years: the bus is the bottleneck, and the Cell makes this explicit. It goes so far as to deal with the clock-rate limits we've reached by taking the basic "bus is the limit" and exposing it in a way that lets you stack a bunch of processors without excessive interconnect hardware (and associated heat) into a more power-efficient chip.
I've been working on Cell for nearly a year now, and it's been really nice being forced to pay attention to the techniques that will be required to get performance on all multi-core machines, which in essence means all new processors coming out. Our bus/clockrate/heat problems are all inter-dependent, and Cell is the first project I've seen that gets serious about letting programmers know they need to change to adapt to this new space.
I disagree that that the cell architectures is "inherently less useful than a shared-memory multiprocessor".
Shared memory is the cause of 80% of the nasty little race conditions programmers leave peppered through their code on parallel machines - it's just too easy to break discipline, particularly considering the crap programming languages support we have - C and C++ are just not up to the task because of their assumption that you may touch anything in the address space.
Cell-like architectures have one other advantage, particularly in performance-sensitive applications: the explicit DMA to local stores *makes* you look at how the busses work on that machine, and they do not really differ from the busses on non-Cell-like modern machines; the structure of your Cell code will be bus-friendly on pretty much any architecture you port it to. And in our modern world, the bus is the bottleneck.
I claim it is useful: it points you to the paper, and then labels the sections in ways that are consistent with the presentation in the paper. You can't expect to read all arbitrary code without some outside explanation of some of the tricky (or less naive) bits. I much prefer a clean external reference to a bunch of goop inline that in many cases makes no sense.
It's thoroughly documented: mind you you need to start with the reference given in the first comment. Variable names and comments relate to that paper.
The SIMD in question here is the Altivec/SSD style also called SWAR (SIMD Within A Register); the instruction set has many ops for applying the same operation over each of the 4 (or 8, or 16) elements within a 128 bit register. It's not the streaming type of SIMD.
You are wrong. These SIMD processors do loops just fine. There's a hefty hit for a mis-predicted branch, but the branch hint instruction works wonders for loops.
The reason you want to unroll loops is because of various other delays. If it takes 7 cycles to load from the local store to a register, you want to throw a few more operations in there to fill the stall slots. Unrolling can provide those operations, as well as reduce the relative importance of branch overheads.
It's more than just length checking. Anywhere where an offset is generated that will be added to a pointer the offset must be tested for being in range of the target data. That becomes onerous very quickly.
But all the managed code's libraries weren't necessarily written in managed code. It's easy to see how "trusted" formats can have various pointer-arithmetic unchecked. Consider an image format that includes an offset to the start of some of its data: intercept the image, change the offset, and off you go at least feeding bad data to the application. Few loaders check that all these kinds of binary data are in range, programmers are lazy and just add the offset to their pointer:-( I guess more and more loaders will be checking more carefully now...
You mean 8 hours behind, right? Sure there's a date line, but in practical terms 16 hours of jetlag is no worse than 8. The question is which days of the week they keep as work days and days off.
Slashdot Mirror
No, there is a qualitative difference. In the case of targetted killings of people who do things you don't like, the message is "don't do that"; in the case of random acts, the message is "listen to us, we'll do anything to be heard"
Just being a bad person doing awful things doesn't make you a terrorist.
Now, if PETA was randomly blowing up busses, then perhaps the word terrorist would fit.
Frankly, if you're going to make that argument, then argue that the government should be monitoring every bar in the nation looking for drunk drivers - you'll save more lives.
Let me mildly rephrase the analogy: Once the roads go in, a toll is set up where only Fords need to pay the toll. The analogy holds. Show me a tollway where particular brands of cars are penalized. That, however, is the vision held up by these ISPs.
Of course, getting an NC-17 is going to give this film much more press than it would have otherwise garnered.
A futher difference is that voting machine agregate results - that makes individual voter challenges very difficult. Hence the need to use a system that is substantially more secure than ATMs.
The machines could still be tampered with before deployment (you only have to bribe the representative from your opposite party at the machine deployment center) -- these deployment centers are an example of centralizing a process, which allows fraud to affect more ballots than a distributed system. I can trust a clear paper ballot (and there are important design decisions involved here, many of which can reduce the number of disputed ballots)
If you are counting ballot boxes locally, you will only have a small number of disputed ballots; the system doesn't fall apart that way.
You can have a machine mark the ballot, but the ballot must be the record, which must be the thing counted. It *must* be counted on a small scale in a distributed way to dillute the effects of any engineered fraud. Machine marking may be advantageous for reducing the number of debatable ballots, but the process should be doable without a machine: I might choose not to trust it.
What is impractical about counting 500 to 1000 ballots? It's important to keep the ballot boxes small enough that a single committee being corrupted will have little effect. Any serious party should be able to find one observer/counter per 1000 voters.
I don't know the lever machines in NY. Does every voter get to check that his vote recorded what he claimed? With paper I see my ballot, and I put it in the box: I know it says what I said. With a lever, I can imaging the machine being rigged - I now have to trust the machine provider instead of a multi-partisan counting committee. With paper if I really care I can even sign up to watch the ballot counting (in advance, I should hope, to make enough space available).
Votes are different - no one winds up able to complain or to really even audit because of the secrecy. Instead we have to make sure that the system is as imprevious to corruption as possible. In practical terms that means low-tech and decentralized.
These machines are classic cases where a small embeded system is sufficient.
But just say no to voting machines. Vote on paper. In smallish ballot boxes. Counted individually by separate multi-partisan committees.
Anything else allows centralization of election corruption.
Vote on paper. Assign one (multi-partisan) counting committee per ballot box and count that box there, in the hour following the closing of the polls. DO NOT CENTRALIZE the counting or the counting technology. Doing so makes corruption much easier than coopting a large distributed system.
If a party can't pony up one counter per ballot box, then they have deeper problems than verifying the count for that ballot box.
I don't understand why the US continues to insist on using easily corruptible systems in their voting. (OK, I do understand, but I'm trying to be generous)
Lobby your congrescritter for *real* electoral reform and make your vote count again.
Centralized vote counting is the root of the corruption in the US voting system. Moving ballot boxes to "counting centers" is wrong - it allows focused corruption. Computer counting is wrong - it allows focused corruption. Distributed counting is *much* harder to coopt.
But you should design around the changes in architecture that have been coming at us for the last 5-10 years: the bus is the bottleneck, and the Cell makes this explicit. It goes so far as to deal with the clock-rate limits we've reached by taking the basic "bus is the limit" and exposing it in a way that lets you stack a bunch of processors without excessive interconnect hardware (and associated heat) into a more power-efficient chip.
I've been working on Cell for nearly a year now, and it's been really nice being forced to pay attention to the techniques that will be required to get performance on all multi-core machines, which in essence means all new processors coming out. Our bus/clockrate/heat problems are all inter-dependent, and Cell is the first project I've seen that gets serious about letting programmers know they need to change to adapt to this new space.
Shared memory is the cause of 80% of the nasty little race conditions programmers leave peppered through their code on parallel machines - it's just too easy to break discipline, particularly considering the crap programming languages support we have - C and C++ are just not up to the task because of their assumption that you may touch anything in the address space.
Cell-like architectures have one other advantage, particularly in performance-sensitive applications: the explicit DMA to local stores *makes* you look at how the busses work on that machine, and they do not really differ from the busses on non-Cell-like modern machines; the structure of your Cell code will be bus-friendly on pretty much any architecture you port it to. And in our modern world, the bus is the bottleneck.
The rootkit method? Of course not; it's just a trivial variant of the "disdain your customer" business method.
I claim it is useful: it points you to the paper, and then labels the sections in ways that are consistent with the presentation in the paper. You can't expect to read all arbitrary code without some outside explanation of some of the tricky (or less naive) bits. I much prefer a clean external reference to a bunch of goop inline that in many cases makes no sense.
Not all code documentation lives in the source.
The SIMD in question here is the Altivec/SSD style also called SWAR (SIMD Within A Register); the instruction set has many ops for applying the same operation over each of the 4 (or 8, or 16) elements within a 128 bit register. It's not the streaming type of SIMD.
The reason you want to unroll loops is because of various other delays. If it takes 7 cycles to load from the local store to a register, you want to throw a few more operations in there to fill the stall slots. Unrolling can provide those operations, as well as reduce the relative importance of branch overheads.
It's more than just length checking. Anywhere where an offset is generated that will be added to a pointer the offset must be tested for being in range of the target data. That becomes onerous very quickly.
But all the managed code's libraries weren't necessarily written in managed code. It's easy to see how "trusted" formats can have various pointer-arithmetic unchecked. Consider an image format that includes an offset to the start of some of its data: intercept the image, change the offset, and off you go at least feeding bad data to the application. Few loaders check that all these kinds of binary data are in range, programmers are lazy and just add the offset to their pointer :-( I guess more and more loaders will be checking more carefully now...
You mean 8 hours behind, right? Sure there's a date line, but in practical terms 16 hours of jetlag is no worse than 8. The question is which days of the week they keep as work days and days off.