Explain to a non-geek how that means his/her vote is being counted properly.
Due to their cost, they may not be practical for a voting machine.
That's what I keep saying. And even if that cost was expended, you still couldn't achieve the same level of confidence that you could with a paper vote.
For a voting machine, I would start with a list of every major component, list the failure modes, and then describe the consequences of each failure.
Immediately afterward, you would likely conduct a feasibility study and reject the idea in favour of a paper ballot.
The point of an electronic system with paper ballots is to provide very quick results in most cases while still allowing for recounts and audits in special cases
This is a question I've asked before, but I'll ask it again. Define "special case" in a discussion about an electronic vote. Sure, smoke pouring out of the back of the e-voting machine is one. But otherwise, how can you identify that the voting machine has not malfunctioned ? How can you look at the result and say for sure that it's correct ? You can't simply glibly state "it works well". How do you know ?
So yes, an electronic vote delivers quick results, but you can't be sure that it's delivering the right results.
I agree with your last point about paper ballots. Getting a quick result is less important than getting the right result surely ?
Personally I think it is better to put the resources into ensuring that the electoral roll is correct, and is kept up to date well in advance of the poll. This is the way it is done in the UK; if you're not on the register on polling day you can't vote. If you're denied a vote, you can of course complain to one of your local politicians and get them to raise a stink about it (if it's an opposition politician they'll be only to happy to criticise the government over electoral procedures).
Polling stations are very busy on polling day (obviously) and you want to keep things moving as quickly as possible. It's ridiculous that you have electoral officials sitting there phoning round trying to see if someone is legitimately permitted to vote or not.
Most ridiculous of all is the idea that you sift through the votes afterward searching for votes by people who weren't entitled to vote and remove them from the count - after the initial result is known. Aside from the fact that this severely damages the concept of a secret ballot, this means that those doing the "sifting" will know whether the result is close to the wire or not, and therefore will know whether or not their work is likely to result in the vote being swung. The possibilities for corruption are endless. If the electoral roll is compiled independently in advance there is no possibility for this kind of intervention in the result.
I don't mean to sound like a conspiracy theory nut, nut the reason why there is no resistance to electronic voting is probably for the same reasons why there is no resistance to (for example) the electoral college - those people either support it knowing that they may at one point benefit from the problems, or they simply don't understand. It's the same way during the 1950s and 1960s the UK government told us that nuclear fission power was going to be too cheap to meter. Everyone just believed them and there was no resistance.
E-voting can have advantages over hand-counting paper ballots, in both speed and accuracy.
"accuracy", what do you mean - the voting machines are not a HAL9000 "incapable of error" behemoth. An "accuracy" claim in these circumstances is either dishonest or ignorant of how voting works in practice, with a huge number of non technically savvy people using the system. On top of that, automated vote counting (particularly electronic voting) introduces a whole stack of new points of failure that do not exist with a pen and paper (programmer error; programmer maliciousness; several different kinds of voter error; several different kinds of electoral official error; electrical power failure; insufficient storage capacity for votes; the list of things that can go wrong or which can be done wrong is stupendous. How anybody can claim on the basis of a few tests that the result will be "more accurate" is frankly ridiculous.
Secondly no metric is available to determine the accuracy of a given electronic vote. To do that you would have to back up every electronic vote with a paper vote and compare the two, and you'd have to make assumptions about people's honesty over whether the paper vote matches what they really did put into the machine. By the time you do that the costs of running the whole exercise have ballooned so much the whole thing would be a complete waste of time.
It is probably for the best to try to forget about it, and make sure that these stuff is fixed for the next election
Huh ? This debacle happened in Florida 2000 and basically nothing was done. I can't believe Americans would argue that they can blindly trust the government to make sure that the means by which it acquires power is fair and balanced.
Right. Just look at what happened this year. Nearly all of the losing politicians demanded recounts. Oh wait, no they didn't. So your argument is simply wrong.
The reasons why the losing politicians (I assume this means the Democrats) aren't demanding electoral change is a matter for themselves. However the media are certainly reporting instances of severe problems with the count in some areas; and many people I know in the US are unhappy (anecdotal I admit). With that in mind, how many other areas could have had problems which were not severe enough to appear on the radar but still serious enough to swing the result ?
This is a matter of the government endorsing a black box voting method and people going along with it without stopping to question it or the interests who are pushing it; I can't think of anything more obvious which completely flies in the face of American values.
I don't see what the contribution is. If the requirement is to have X counts to achieve a confident result, you can just get X sets of people to count it. No need to bother with the computer.
In the UK and Canada where hand counts are the norm, debates like the one we're having about the accuracy of the count itself never arise, because none of the candidates or the electorate including the losers see the need to challenge the vote. That situation would change quite rapidly if automated vote counting was brought in.
There's no need for me to read up on the details of this. There are simple questions here that simply can't be addressed, or the answers to which are unsatisfactory given the subject matter.
Random audits are not acceptable; they are unnecessary with a paper vote. Why compromise ?
Challenges with electronic voting cannot happen, as (unless there's smoke pouring out of the back of the machine) you can't say whether the electronic machine is counting the votes properly or not.
There is no way metrics regarding accuracy can be obtained, without using a paper vote and recording it centrally alongside the electronic vote. Having a paper vote as a "backup" implies right from the start that the electronic vote is redundant as well as fundamentally flawed, and therefore unnecessary to begin with.
How does the judge know whether to order a recount or not ?
With the mechanical machines in Florida they could at least see what the problem was, so they at least had some basis upon which to argue that a hand count was required. How do you achieve that with an electronic machine ?
What do you mean paper failed in Florida ? I think the combination of the machines and people's non-understanding of how they can be appropriately used had a lot more to do with it. If people can't do that how do you expect them to operate an electronic machine correctly ?
When I say "paper" voting I mean a piece of paper which the voter marks using a pencil in some discernable way next to the candidate of his/her choice. You can't get any simpler than that. Obviously votes are rejected if the mark hasn't been made properly, but you're not going to get too far in life if you can't use a pencil...
We may not be designing a plane, but it is much more imperative that this work properly, especially in situations where a could of doubt has been cast on the whole process.
You can't satisfactorily eliminate doubt using electronic counting. You are proving that in your own words, by conceding that a paper trail is required to achieve confidence. Yes - the design is critical and must work properly at all times - which the paper/pencil solution does completely.
What can this redundancy possibly contribute ? If there is an electronic vote which can be challenged, with the paper vote being held as the "reliable" result, what's the point in bothering with the electronic vote to begin with ?
Thus, afterwards, if a hacker/act of god changes the electronic vote, one can verify them with the paper ones.
Respectfully, what I'm trying to say doesn't seem to be getting through, but I can't see how I can make it clearer. Think out of the box. This is not about test cases or paper trails.
Given an electronically recorded vote, how can anyone say that a hacker or act of god changed the vote ? Presumably what you have in mind is a panel (we'll assume for the sake of argument that it is independent and bias-free). What criteria does that panel look at to decide whether the paper ballots should be checked or not ?
The electronic vote machine spits out a number at the end of the vote declaring the results. On what basis do you look at those results and say "hmm, we need a recount" or "I'm happy with that, we don't need a recount" ?
The loser says "I'm not happy with that result, let's recount based on the paper trail". On what basis can this argument be reasonably rejected ?
No piece of non-trivial software can ever be considered bug free, and therefore, no software ever deserves complete confidence.
100% correct, and that is why I am arguing that software (or any kind of machine) should not be used to count votes.
For that matter, hand-counting shouldn't have your complete confidence either. People make mistakes; shit happens. That's the whole reason for QC.
Hand counting is not infallible, but at least a layman can go and watch the people doing the counting. How do you determine whether your voting machine is working or not ? You have to employ an engineer ($$$), and then you have to trust that he's not lying to you or incompetent when he tells you it's working just fine. Why bother ?
You should have no basis upon which to reject a recount. The paper ballots are the masters. If there is a serious challenge, then they should be recounted.
Define "serious challenge". I double-dare you.
But in any case: you should verify a selected sample of the machines' votes in every polling station to make sure that they are giving reasonable numbers.
Who gets to decide which sample gets tested, and how can we be sure that they don't tip off any would-be vote riggers ? And what if your sample finds problems. What do you do then ? Stop the election ?
This is just the application of industry-standard quality control procedures to voting machines. It boggles my mind that electronic voting was ever considered without them.
I don't want industry standard QC procedures applied to my voting. I don't want any automatic machines used to count my votes at all. I want a transparent, public count process easily understood by the layman with as near as possible to zero potential for any candidate or interest to interfere with the vote. No automated vote counting system can provide this.
I respect that problem, but at the end of the day there's not much point in having a voting system in the first place if people can't be confident that their vote will actually be counted, or that the vote won't be swung by corrupt interference in the electoral process. Bits of paper with lots of questions on can still be counted - it just takes longer and is laborious (you'd just count each result one at a time and declare each one in sequence), but I still think that the extra day or two taken to get everything counted right is going to work out cheaper than buying, maintaining and troubleshooting fancy electronic voting machines that joe public isn't sure about at all.
[As an aside, there is the question of whether so many questions should be asked directly of the electorate, which is a distantly related matter. Yes, it is a purer form of democracy, but if there are ballots every six months for all kinds of things people will just stop turning up, and you end up with things getting swung by minorities... ]
We're not designing a plane or a nuclear power plant. We're trying to come up with a reliable method to count votes. Your argument simply doesn't apply; redundancy is simply completely unnecessary.
If everyone insists on having a manual recount afterwards, given that the existence of the paper trail confirms that the electronic vote cannot be inherently relied upon in all reasonable circumstances, why bother with the electronic count to begin with ? What purpose is the electronic count serving ?
We're talking about politicians here. You're saying you believe they're basically honest ? Respectfully, I think you need to see a bit more of the real world. Why do you think governments and laws exist in the first place ?
The reality is that a lot of people - not all or most, but a lot - are basically dishonest, and checks and balances need to exist in order to keep them at bay. That means you need to have an electoral system which as far as possible reduces the number of possible loopholes that can be exploitable people.
The best way to do this is exactly as you suggested - paper ballots, marked and counted by hand at a public count. If the candidates are paranoid about the state trying to swing the result, they can visit the polling stations and can put their own seals on the ballot boxes, and can confirm that the seals are present when they visit the count room before the counting starts. Tell me how you do that with any kind of counting machine, electronic or otherwise, paper trail or not.
[Sure the officials counting can be corrupt, but they'll have to be in a risky mood to try anything while the candidates and their legal advisers are observing the progress of the count... ]
You can't trust the government to properly ensure that all of these procedures are followed correctly, all of the time. It's just impossible, at least not without huge expense.
What problem is being solved by the use of electronic voting ? All it does is get you the result between a few hours and a day earlier than counting by hand. Is it really worth risking the damage to democracy, the extent, the voter confusion and the possibility of corruption just to achieve that ?
I keep hearing this argument that electronic voting machines should have a paper trail. Apart from the fact that it is meaningless (any programmer knows that the printout doesn't have to match the vote that was recorded internally) there is a more fundamental problem.
By adding a printer, you're conceding that the electronic voting machine may not innately be able to provide complete confidence in the result.
By conceding that the electronic voting machine's results cannot be trusted, you're saying that you have no basis upon which to reject a request for a recount of the paper receipts. In other words, you're back to hand-counting paper votes each time.
The belief that electronic voting (or indeed automated vote counting of any kind) can work or deliver any kind of benefit is a serious mistake. A huge amount of cash need to be spent to test it, get it working and provide some degree of confidence that the result isn't wrong, and even then you can never be 100% sure. What's wrong with a pencil, a piece of paper, and a count process to which the candidates (and their lawyers) can be invited to ?
The default compiler for VxWorks these days is Diab, I think that has been the case for the past two years. I might add that it was GCC 2.95. Most of the modern Linux distros are shipping GCC 3.x.
The current commercial Linux distros just can't generate compiled code that's as small as that when you use a purpose-built RTOS. The reasons for this are obvious; Linux and the GCC compiler set aren't designed for RTOS use. These problems may become less relevant as RAM and flash storage prices fall.
Linux on embedded devices isn't 100% there yet. The kernel itself is absolutely fine, I've never had any problems with it, but it's the tools, libraries and APIs that surround it that are the issue. The large embedded Linux providers still use the standard GNU C libraries, which are huge (uClibc is out there, but the big players don't seem to be running with it yet). GCC is an incredible tool but it is designed for cross-platform portability first, rather than small code size. Threading on Linux isn't the best their is on all architectures - LinuxThreads is a nasty hack and has several significant drawbacks (NPTL should improve this but how long will it take to make that stable across the board? Other OSs have it today). The GNU debugger is a bit of a joke really at the best of times - again on x86 it's fine but on other architectures it's very unstable, very easy to make it dump core. The debugging data required by GDB and the data produced by GCC during compilation are in a constant state of flux. On embedded we don't want new whiz-bang features, we just need it to work.
With VxWorks or other RTOSs such as Integrity or ThreadX, your RAM and flash (persistent) storage usage is much smaller as you've got way smaller binaries and a designed-in commitment to speed and small code size on small boxen. True, I much prefer developing on Linux, it's easier to port existing code to it, and your UNIX programmers can get to work straight away, but on VxWorks the basic OS stuff always behaves predictably and reliably.
Horses for courses folks. Using GNU/Linux on embedded gives good results, and in some circumstances may get you to market faster, but with compromises on stability and code size.
I don't see how the problem is anything to do with GCC. If you compile a file in a given directory, the debugger will go looking for it in that directory.
Clearcase doesn't have the same problem, because of the way it works with views, rather than everybody taking copies of the source tree and having their own work area. For each user, working on the same VOB, the path to a given source file is always the same, even though their view of the tree is still unique. For example two users will always be able to work on/vobs/sourcecode/foo.c in different views, and the debugger will always go looking for it there. If you've got your CVS tree in/home/joesoap/sourcecode/ and you compile foo.c, anyone else who picks up that object will try to pull the source from your copy of the tree. Delete your tree and everyone reading that source file via something like ccache is screwed.
I'm sure SCons ships in distros, the thing is that I've never seen anyone ship code that builds using it. I agree though, I'd not like to try to get those mad GNU build tools, good as they may be, working everywhere.
The ability to compute dependencies automatically in Clearcase is worth it's weight in gold (I believe Rational have patented it ? Can't say for sure though). It saves a huge amount of hassle because it "just works". Sure, if you have the time you can hang around and mess around with strace and gcc -M, but if your time is invaluable having something that works out of the box is a great boost. Clearmake can even work out when you've changed the makefile itself or other included makefiles; that's very hard to do under regular make.
I've been trying to get my place to move away from Clearcase (slow; dodgy cross-platform support; hard to use away from the office; no real process flow model without extra cost) and the one hard part to tear people away from is the clearmake capability.
Some folks have had some ideas about how to do this on Linux, the best idea being to patch glibc to track file accesses, ie this idea.
ccache is a great little piece of software, but I'm afraid it doesn't match up to Clearcase's build avoidance capabilities. There are several gotchas if you share the cache among several developers. Furthermore, if your developers are working in different directories but have the same source files (as will be true 99% of the time) you get trouble with debuggers trying to load symbols from object files.
Thanks for the tip on SCons, I'll have to take a look at it; it looks very impressive. The trouble is that it's a make replacement and therefore it's out of the question for a lot of people. Most shops aren't willing to adopt non-standard tools in this way. Clearmake is transparently compatible with GNU, Sun, HP and various other make variants. Do any major open source distributions use it ? I don't believe so. The one thing you can say about make is that it'll be right there on an type of UNIX-ish box you'll find out there.
Agreed about Clearcase's dismal showing on Linux though (now that Rational are IBM, something might get done about this).
Slashdot Mirror
They are error-prone and subject to a range of problems and vulnerabilities.
What problems and vulnerabilities ?
If people want to steal an election, they will find a way.
Why hand it to them on a plate ?
If someone wants to break into your house they will find a way. So why bother with locks on the doors ?
ECC can be used for memory and busses.
Explain to a non-geek how that means his/her vote is being counted properly.
Due to their cost, they may not be practical for a voting machine.
That's what I keep saying. And even if that cost was expended, you still couldn't achieve the same level of confidence that you could with a paper vote.
For a voting machine, I would start with a list of every major component, list the failure modes, and then describe the consequences of each failure.
Immediately afterward, you would likely conduct a feasibility study and reject the idea in favour of a paper ballot.
The point of an electronic system with paper ballots is to provide very quick results in most cases while still allowing for recounts and audits in special cases
This is a question I've asked before, but I'll ask it again. Define "special case" in a discussion about an electronic vote. Sure, smoke pouring out of the back of the e-voting machine is one. But otherwise, how can you identify that the voting machine has not malfunctioned ? How can you look at the result and say for sure that it's correct ? You can't simply glibly state "it works well". How do you know ?
So yes, an electronic vote delivers quick results, but you can't be sure that it's delivering the right results.
I agree with your last point about paper ballots. Getting a quick result is less important than getting the right result surely ?
Personally I think it is better to put the resources into ensuring that the electoral roll is correct, and is kept up to date well in advance of the poll. This is the way it is done in the UK; if you're not on the register on polling day you can't vote. If you're denied a vote, you can of course complain to one of your local politicians and get them to raise a stink about it (if it's an opposition politician they'll be only to happy to criticise the government over electoral procedures).
Polling stations are very busy on polling day (obviously) and you want to keep things moving as quickly as possible. It's ridiculous that you have electoral officials sitting there phoning round trying to see if someone is legitimately permitted to vote or not.
Most ridiculous of all is the idea that you sift through the votes afterward searching for votes by people who weren't entitled to vote and remove them from the count - after the initial result is known. Aside from the fact that this severely damages the concept of a secret ballot, this means that those doing the "sifting" will know whether the result is close to the wire or not, and therefore will know whether or not their work is likely to result in the vote being swung. The possibilities for corruption are endless. If the electoral roll is compiled independently in advance there is no possibility for this kind of intervention in the result.
I don't mean to sound like a conspiracy theory nut, nut the reason why there is no resistance to electronic voting is probably for the same reasons why there is no resistance to (for example) the electoral college - those people either support it knowing that they may at one point benefit from the problems, or they simply don't understand. It's the same way during the 1950s and 1960s the UK government told us that nuclear fission power was going to be too cheap to meter. Everyone just believed them and there was no resistance.
E-voting can have advantages over hand-counting paper ballots, in both speed and accuracy.
"accuracy", what do you mean - the voting machines are not a HAL9000 "incapable of error" behemoth. An "accuracy" claim in these circumstances is either dishonest or ignorant of how voting works in practice, with a huge number of non technically savvy people using the system. On top of that, automated vote counting (particularly electronic voting) introduces a whole stack of new points of failure that do not exist with a pen and paper (programmer error; programmer maliciousness; several different kinds of voter error; several different kinds of electoral official error; electrical power failure; insufficient storage capacity for votes; the list of things that can go wrong or which can be done wrong is stupendous. How anybody can claim on the basis of a few tests that the result will be "more accurate" is frankly ridiculous.
Secondly no metric is available to determine the accuracy of a given electronic vote. To do that you would have to back up every electronic vote with a paper vote and compare the two, and you'd have to make assumptions about people's honesty over whether the paper vote matches what they really did put into the machine. By the time you do that the costs of running the whole exercise have ballooned so much the whole thing would be a complete waste of time.
It is probably for the best to try to forget about it, and make sure that these stuff is fixed for the next election
Huh ? This debacle happened in Florida 2000 and basically nothing was done. I can't believe Americans would argue that they can blindly trust the government to make sure that the means by which it acquires power is fair and balanced.
Right. Just look at what happened this year. Nearly all of the losing politicians demanded recounts. Oh wait, no they didn't. So your argument is simply wrong.
The reasons why the losing politicians (I assume this means the Democrats) aren't demanding electoral change is a matter for themselves. However the media are certainly reporting instances of severe problems with the count in some areas; and many people I know in the US are unhappy (anecdotal I admit). With that in mind, how many other areas could have had problems which were not severe enough to appear on the radar but still serious enough to swing the result ?
This is a matter of the government endorsing a black box voting method and people going along with it without stopping to question it or the interests who are pushing it; I can't think of anything more obvious which completely flies in the face of American values.
I don't see what the contribution is. If the requirement is to have X counts to achieve a confident result, you can just get X sets of people to count it. No need to bother with the computer.
In the UK and Canada where hand counts are the norm, debates like the one we're having about the accuracy of the count itself never arise, because none of the candidates or the electorate including the losers see the need to challenge the vote. That situation would change quite rapidly if automated vote counting was brought in.
There's no need for me to read up on the details of this. There are simple questions here that simply can't be addressed, or the answers to which are unsatisfactory given the subject matter.
Random audits are not acceptable; they are unnecessary with a paper vote. Why compromise ?
Challenges with electronic voting cannot happen, as (unless there's smoke pouring out of the back of the machine) you can't say whether the electronic machine is counting the votes properly or not.
There is no way metrics regarding accuracy can be obtained, without using a paper vote and recording it centrally alongside the electronic vote. Having a paper vote as a "backup" implies right from the start that the electronic vote is redundant as well as fundamentally flawed, and therefore unnecessary to begin with.
How does the judge know whether to order a recount or not ?
With the mechanical machines in Florida they could at least see what the problem was, so they at least had some basis upon which to argue that a hand count was required. How do you achieve that with an electronic machine ?
What do you mean paper failed in Florida ? I think the combination of the machines and people's non-understanding of how they can be appropriately used had a lot more to do with it. If people can't do that how do you expect them to operate an electronic machine correctly ?
When I say "paper" voting I mean a piece of paper which the voter marks using a pencil in some discernable way next to the candidate of his/her choice. You can't get any simpler than that. Obviously votes are rejected if the mark hasn't been made properly, but you're not going to get too far in life if you can't use a pencil...
We may not be designing a plane, but it is much more imperative that this work properly, especially in situations where a could of doubt has been cast on the whole process.
You can't satisfactorily eliminate doubt using electronic counting. You are proving that in your own words, by conceding that a paper trail is required to achieve confidence. Yes - the design is critical and must work properly at all times - which the paper/pencil solution does completely.
What can this redundancy possibly contribute ? If there is an electronic vote which can be challenged, with the paper vote being held as the "reliable" result, what's the point in bothering with the electronic vote to begin with ?
Thus, afterwards, if a hacker/act of god changes the electronic vote, one can verify them with the paper ones.
Respectfully, what I'm trying to say doesn't seem to be getting through, but I can't see how I can make it clearer. Think out of the box. This is not about test cases or paper trails.
Given an electronically recorded vote, how can anyone say that a hacker or act of god changed the vote ? Presumably what you have in mind is a panel (we'll assume for the sake of argument that it is independent and bias-free). What criteria does that panel look at to decide whether the paper ballots should be checked or not ?
The electronic vote machine spits out a number at the end of the vote declaring the results. On what basis do you look at those results and say "hmm, we need a recount" or "I'm happy with that, we don't need a recount" ?
The loser says "I'm not happy with that result, let's recount based on the paper trail". On what basis can this argument be reasonably rejected ?
No piece of non-trivial software can ever be considered bug free, and therefore, no software ever deserves complete confidence.
100% correct, and that is why I am arguing that software (or any kind of machine) should not be used to count votes.
For that matter, hand-counting shouldn't have your complete confidence either. People make mistakes; shit happens. That's the whole reason for QC.
Hand counting is not infallible, but at least a layman can go and watch the people doing the counting. How do you determine whether your voting machine is working or not ? You have to employ an engineer ($$$), and then you have to trust that he's not lying to you or incompetent when he tells you it's working just fine. Why bother ?
You should have no basis upon which to reject a recount. The paper ballots are the masters. If there is a serious challenge, then they should be recounted.
Define "serious challenge". I double-dare you.
But in any case: you should verify a selected sample of the machines' votes in every polling station to make sure that they are giving reasonable numbers.
Who gets to decide which sample gets tested, and how can we be sure that they don't tip off any would-be vote riggers ? And what if your sample finds problems. What do you do then ? Stop the election ?
This is just the application of industry-standard quality control procedures to voting machines. It boggles my mind that electronic voting was ever considered without them.
I don't want industry standard QC procedures applied to my voting. I don't want any automatic machines used to count my votes at all. I want a transparent, public count process easily understood by the layman with as near as possible to zero potential for any candidate or interest to interfere with the vote. No automated vote counting system can provide this.
I respect that problem, but at the end of the day there's not much point in having a voting system in the first place if people can't be confident that their vote will actually be counted, or that the vote won't be swung by corrupt interference in the electoral process. Bits of paper with lots of questions on can still be counted - it just takes longer and is laborious (you'd just count each result one at a time and declare each one in sequence), but I still think that the extra day or two taken to get everything counted right is going to work out cheaper than buying, maintaining and troubleshooting fancy electronic voting machines that joe public isn't sure about at all.
[As an aside, there is the question of whether so many questions should be asked directly of the electorate, which is a distantly related matter. Yes, it is a purer form of democracy, but if there are ballots every six months for all kinds of things people will just stop turning up, and you end up with things getting swung by minorities... ]
We're not designing a plane or a nuclear power plant. We're trying to come up with a reliable method to count votes. Your argument simply doesn't apply; redundancy is simply completely unnecessary.
If everyone insists on having a manual recount afterwards, given that the existence of the paper trail confirms that the electronic vote cannot be inherently relied upon in all reasonable circumstances, why bother with the electronic count to begin with ? What purpose is the electronic count serving ?
We're talking about politicians here. You're saying you believe they're basically honest ? Respectfully, I think you need to see a bit more of the real world. Why do you think governments and laws exist in the first place ?
The reality is that a lot of people - not all or most, but a lot - are basically dishonest, and checks and balances need to exist in order to keep them at bay. That means you need to have an electoral system which as far as possible reduces the number of possible loopholes that can be exploitable people.
The best way to do this is exactly as you suggested - paper ballots, marked and counted by hand at a public count. If the candidates are paranoid about the state trying to swing the result, they can visit the polling stations and can put their own seals on the ballot boxes, and can confirm that the seals are present when they visit the count room before the counting starts. Tell me how you do that with any kind of counting machine, electronic or otherwise, paper trail or not.
[Sure the officials counting can be corrupt, but they'll have to be in a risky mood to try anything while the candidates and their legal advisers are observing the progress of the count... ]
How does a paper trail help ?
You can't trust the government to properly ensure that all of these procedures are followed correctly, all of the time. It's just impossible, at least not without huge expense.
What problem is being solved by the use of electronic voting ? All it does is get you the result between a few hours and a day earlier than counting by hand. Is it really worth risking the damage to democracy, the extent, the voter confusion and the possibility of corruption just to achieve that ?
I keep hearing this argument that electronic voting machines should have a paper trail. Apart from the fact that it is meaningless (any programmer knows that the printout doesn't have to match the vote that was recorded internally) there is a more fundamental problem.
By adding a printer, you're conceding that the electronic voting machine may not innately be able to provide complete confidence in the result.
By conceding that the electronic voting machine's results cannot be trusted, you're saying that you have no basis upon which to reject a request for a recount of the paper receipts. In other words, you're back to hand-counting paper votes each time.
The belief that electronic voting (or indeed automated vote counting of any kind) can work or deliver any kind of benefit is a serious mistake. A huge amount of cash need to be spent to test it, get it working and provide some degree of confidence that the result isn't wrong, and even then you can never be 100% sure. What's wrong with a pencil, a piece of paper, and a count process to which the candidates (and their lawyers) can be invited to ?
The default compiler for VxWorks these days is Diab, I think that has been the case for the past two years. I might add that it was GCC 2.95. Most of the modern Linux distros are shipping GCC 3.x.
The current commercial Linux distros just can't generate compiled code that's as small as that when you use a purpose-built RTOS. The reasons for this are obvious; Linux and the GCC compiler set aren't designed for RTOS use. These problems may become less relevant as RAM and flash storage prices fall.
I'd not call time on Windriver yet.
Linux on embedded devices isn't 100% there yet. The kernel itself is absolutely fine, I've never had any problems with it, but it's the tools, libraries and APIs that surround it that are the issue. The large embedded Linux providers still use the standard GNU C libraries, which are huge (uClibc is out there, but the big players don't seem to be running with it yet). GCC is an incredible tool but it is designed for cross-platform portability first, rather than small code size. Threading on Linux isn't the best their is on all architectures - LinuxThreads is a nasty hack and has several significant drawbacks (NPTL should improve this but how long will it take to make that stable across the board? Other OSs have it today). The GNU debugger is a bit of a joke really at the best of times - again on x86 it's fine but on other architectures it's very unstable, very easy to make it dump core. The debugging data required by GDB and the data produced by GCC during compilation are in a constant state of flux. On embedded we don't want new whiz-bang features, we just need it to work.
With VxWorks or other RTOSs such as Integrity or ThreadX, your RAM and flash (persistent) storage usage is much smaller as you've got way smaller binaries and a designed-in commitment to speed and small code size on small boxen. True, I much prefer developing on Linux, it's easier to port existing code to it, and your UNIX programmers can get to work straight away, but on VxWorks the basic OS stuff always behaves predictably and reliably.
Horses for courses folks. Using GNU/Linux on embedded gives good results, and in some circumstances may get you to market faster, but with compromises on stability and code size.
I don't see how the problem is anything to do with GCC. If you compile a file in a given directory, the debugger will go looking for it in that directory.
/vobs/sourcecode/foo.c in different views, and the debugger will always go looking for it there. If you've got your CVS tree in /home/joesoap/sourcecode/ and you compile foo.c, anyone else who picks up that object will try to pull the source from your copy of the tree. Delete your tree and everyone reading that source file via something like ccache is screwed.
Clearcase doesn't have the same problem, because of the way it works with views, rather than everybody taking copies of the source tree and having their own work area. For each user, working on the same VOB, the path to a given source file is always the same, even though their view of the tree is still unique. For example two users will always be able to work on
I'm sure SCons ships in distros, the thing is that I've never seen anyone ship code that builds using it. I agree though, I'd not like to try to get those mad GNU build tools, good as they may be, working everywhere.
The ability to compute dependencies automatically in Clearcase is worth it's weight in gold (I believe Rational have patented it ? Can't say for sure though). It saves a huge amount of hassle because it "just works". Sure, if you have the time you can hang around and mess around with strace and gcc -M, but if your time is invaluable having something that works out of the box is a great boost. Clearmake can even work out when you've changed the makefile itself or other included makefiles; that's very hard to do under regular make.
I've been trying to get my place to move away from Clearcase (slow; dodgy cross-platform support; hard to use away from the office; no real process flow model without extra cost) and the one hard part to tear people away from is the clearmake capability.
Some folks have had some ideas about how to do this on Linux, the best idea being to patch glibc to track file accesses, ie this idea.
ccache is a great little piece of software, but I'm afraid it doesn't match up to Clearcase's build avoidance capabilities. There are several gotchas if you share the cache among several developers. Furthermore, if your developers are working in different directories but have the same source files (as will be true 99% of the time) you get trouble with debuggers trying to load symbols from object files.
Thanks for the tip on SCons, I'll have to take a look at it; it looks very impressive. The trouble is that it's a make replacement and therefore it's out of the question for a lot of people. Most shops aren't willing to adopt non-standard tools in this way. Clearmake is transparently compatible with GNU, Sun, HP and various other make variants. Do any major open source distributions use it ? I don't believe so. The one thing you can say about make is that it'll be right there on an type of UNIX-ish box you'll find out there.
Agreed about Clearcase's dismal showing on Linux though (now that Rational are IBM, something might get done about this).