Good, finally ARM manufacturers will stop having a monopoly where they can charge whatever they want. I've seen hints at OEM chip prices and they're ridiculous compared to even desktop chips.
It's probably actually higher grade. The massive power output of a 50-200W processor is due to leakage--that is, it's due to poor efficiency. The Intel Atom for example was designed to leak less, and Intel's tighter packaging and lower TPD CPUs are based on new fabrication process that allows greater electrical efficiency. Bloated, poorly thought out designs bleed power as standing static field and heat--standing static field prevents smaller process, i.e. an imprecisely made junction will work on a 90nm process but at 32nm will bleed signal into all adjacent junctions and cause errors. Improving fidelity reduces bleed, allowing for a smaller process.
Somebody will clean up the stuff I glossed over for lack of understanding. The above's all just basics.
It doesn't matter really. ARM uses some 0.1-1.0W, MIPS uses 10-20W for slower clock speeds. ARM has fixed-width single-decode instructions; MIPS has three types of instructions of variable width. ARM does damn near everything in one clock, including evaluate-and-execute prefixed instructions ( { if ( n ) m = 5; } is 2 insns: 'cmp n' and a prefixed 'movnz m, 5'. If n == 0, movnz means 'nop'; otherwise it means 'mov'. Instead of 'cmp n; jnz @@a; mov m,5; @@a:' where jnz and mov have to be evaluated in separate stages. Yes it's been 11 years since I did assembly, it was 286 and 6502, and I'm unfamiliar with ARM by far). MIPS is slow. You may as well put an Intel CELERON in there if you go MIPS.
OEM chip prices like the Tegra 3 at $35 for a quad core 1.4GHz with a fifth extremely-low-power core bounded to 500MHz in single processor mode? With a full system-on-chip including system bridges, memory controllers, and full nVidia graphics, $35 is ridiculous. Why a quad core Sandy Bridge processor doesn't cost half that!
This isn't a matter of privacy. He can have privacy when he chats with his mistress about stopping by for a blow job on the way home; I don't give a rat's ass about the dalliances of our stately nobles. When he's talking to other administrative perfunctories, however, that shit goes on public record.
He's obviously hiding something. Only crazy conspiracy theorists think every time something happens off the record they're hiding something; perceptive people notice when someone deliberately and intently shuffles things off the record.
Actually, you're wrong. On IA-32, a non-executable bit is implemented by using the segmentation features of X86. Data is set to be the whole address space above the lowest data page. Code is set to be everything below the highest code page. In this way, basically, the stack is marked non-executable for no performance impact.
The rest of the address space is both data and code, and can be executed or altered. Memory protections are used to make executable pages non-writable; while non-executable data pages are marked as Supervisor. A TLB fault occurs upon access, in which case the kernel has to assist the TLB load due to lack of permissions in the USER context. The kernel examines the type of fault (Read, Write, Execute) and page permissions; if it's an Execute fault, it throws a General Protection Fault and terminates the program. If it's Read/Write, it instructs the CPU to perform a DTLB load and continue. Once the page is in the DTLB, its context is ignored unless an ITLB fault (on attempt to execute the page) is thrown (in which case the kernel kills the program). Until the DTLB is filled and the page is pushed out, or the DTLB is cleared by a context switch, the program can read/write the data page as normal.
The APIs are loaded in the procedure linkage table, referenced at an offset. Basically a PLT call is done by jumping to %epc+OFFSET, where OFFSET is the distance between the current position in the library and the position of the entry in the PLT to make a particular call. At that position a call is actually made, though it may be unresolved; if it's the first time that function has been called, the PLT executes a small piece of code to link that function, resolving and caching its load address. Then or otherwise, it makes the actual call.
Information is stored in the Global Offset Table (data) and the PLT in each library. This includes information about where in memory other shit is. If you randomize the bases, a piece of code still knows it's 379264 bytes to its PLT from a particular instruction; of course that's somewhere random in memory, but no matter since we know where we are now.
On 32-bit systems, ASLR can make success rates 1 in 65k, or.0015%, because library calls have to be precise and more than 256MB of randomness is unreasonable. The stack can move aligned to 16 bytes, but you can nullify that with a NOP slide--a non-executable stack makes the stack pure data, and thus can supply a good 1 in a million shot if you need to use it to store something (like a new executable file to write out to disk?).
When you have a 1 in 65k chance of success, you cause on average 32 THOUSAND failures to get ONE success out of a fork()ing program that keeps the same address space for each request. If the process re-initializes between attacks, you'll average 65 THOUSAND attacks per 1 success. It's easy to spot that kind of assault; some security tools even recognize repeated crashing and slow the processes down or send alerts. If we look at the connections to a process that crashes, we can surmise the common one(s) are the attackers if there's a single staging point. At the least you lose stealth.
The "Right to Privacy" is more a government thing, Amendment IV of the Constitution of the United States. The Government isn't allowed to perform search or seizure without due cause as acknowledged by judiciary approved warrant. Wire tapping laws were added later, of course; but these days it's fashionable to claim that since information moves on wires we should be allowed to record it. Nixon and Watergate all because of some recorded phone conversations, but in modern times the government wants to record everything that's not their business.
Privacy is a bigger factor in a voting system. People lie. Imagine how many negros may have voted for Bush while claiming to be powerful Obama supporters because all their negro friends are powerful Obama supporters. Imagine how many gays vote Republican (yes, they do) while all other gays are busy viciously demonizing Republicans because gay rights are the only thing that matters. Imagine how many folks in Georgia only voted for Obama or Al Gore because they knew their neighbors wouldn't find out and string 'em up. All these people vote the way they want, and lie to their friends about how they voted; it's impossible to pressure someone into voting, emotionally or physically. That's what a secret ballot is: a right to vote your mind without repercussions beyond voting some moron into power. In Alaska they made a cat mayor.
The statement that anything that X is good is half a fallacy. The Politician's Soliloquy is: Something must be done; This is something; Therefor, this must be done. In this case, you suggest something be done because we want to diminish our rep's powers, but a few holes exist.
The first is the obvious: identifying information. An effort like this could lead to a storage of identifying information--it would lead to a situation where you couldn't tell from the outside. Of course voting machines and identification and sign-in sheets lead to this kind of thing already: you sign in on the voting sheet, we roughly know the five minute span you were in the building and we know which votes were cast during that time since the votes can be timestamped (chad punch ballots don't have the exact time written on them!).
The second is less obvious: printed paper trail means someone has physical, snoopable record of their vote. When I leave the voting booth, I want to leave my vote behind; it exists in my head, it's cast, and you have no evidence against me. That's why votes are secret. To solidify that secret makes it discoverable; you cannot discover my vote in a ballot box among thousands of other votes. Such a paper trail is required to avoid false positives on vote changing (from buyer's remorse, conspiracy yahoos who create trouble intentionally, and plain idiots).
Every step forward costs money and creates a system that becomes somebody's pet. Removing bad ideas is ridiculously hard; we have to move conservatively because people are too stupid to rip out things that just don't work. Really we should fire these people and throw their pet projects in the trash, I know.
Ah, that's your problem then. You seek to count the votes properly, but counting the votes stopped being an issue when we eliminated paper ballots: votes are always counted properly.
Paper ballots are recorded by the voting individual; but electronic ballots are recorded by machine. If you want to mess with electronic votes, you alter the vote when it's cast instead of storing a proper vote and doing odd flipping.
Banking is different than voting. Votes don't have to come from anywhere; but money does. All bank transactions are double entry: money leaves one place and enters another. When you walk into a bank and deposit $100, this system finds its weakness: $100 shows up in your account from the ether. Of course, we know that a given branch produced $10,000 of cash-from-ether on a given day, and started with an amount of cash in it, and so we can count the cash boxes at each desk and figure out if a transaction magicked up the wrong amount of cash (not which, but we can determine there is an error). Checks are easier to trace--in fact banks routinely mis-account checks, mine even gave me $50 extra once and a week later during a weekly audit they caught the check and its matching transaction and took $50 from me. Cash is double and triple counted by hand, then counted by machine, then counted by hand again; checks are just deposited, and later electronically read, then audited (by hand and software comparison).
When votes come in, we can kind of say that 10,000 people came to the polling station. We can't say that 3000 votes for Bush and 7000 votes for Kerry came in; if we could, why the hell would we poll people? So these votes appear out of nowhere, with no verification. So we can say your vote was cast nice and proper, and log a vote for the other guy in the database nice and proper instead. Verification as a whole is impossible; verification by individuals of "their vote" is prone to ridiculous claims and buyer's remorse ("my vote was changed!" more like you want to change your vote...), hence why you need proof of vote cast (i.e. a paper print-out of your vote) or your complaints are invalid.
It's a big problem, really. Reliably counting votes is hard. Though you're right, keeping a verification chain for the voter makes it risky to flip votes; yet, again, it also requires storing identifying information, which is considered a bad thing.
Hey, sounds good to me! But where does the buck stop? Theoretically it goes all the way to the Chief Executive, especially if a cabinet agency refuses to comply with a court order. Is Obama going to throw himself in jail? And who's responsible for doing the arresting?
The Chief Executive of a government agency is the Secretary or Commissioner. That's why the DEA, DOJ, FBI, etc exist: the President doesn't have time for all this shit. If the President sends an order to not comply with the law, that's on him; otherwise it's the responsibility of his surrogate. If you're the Chief Executive Power for the TSA, you have two options: Prove that you reasonably couldn't have known about the actions of your agency or accept responsibility. In the event of a court order, somebody needs to get that order to you; if it gets to you, you are responsible. If it doesn't, you need to have a good case for it not being very widely known information in your agency and show that people went out of their way to keep it from you.
So in this case, the President of the United States is not responsible, but rather the Commissioner of the Transit Security Agency. Unless the President ordered the Commissioner to not comply, the Commissioner should go to prison. Not for an extremely long time perhaps, but long enough to think about what he's done.
When you rely on open source, you rely on source code. But when you rely on a machine controlled by someone else, that someone else may run binaries not compiled from the source code they gave you. Debian sends their own packages for i.e. Firefox, but they patch a lot of stuff; they tell you about the one-line changes made here or there, though, but you'd never know if they just said, "Here is firefox.deb".
You can analyze a binary compiled module. It's harder than source code, but it can be done. You can't analyze the contents of a hardware machine, though. If someone at Diebold put voting-software-with-diebold.patch.deb on the voting machines, but gave you voting-software.tar.gz and voting-software.deb sans Diebold patch, you'd never know What are you going to do? Commandeer the machines randomly mid-vote-day?
Why are we discussing SSL? The guy who develops Varnish has said that SSL is a mess, OpenSSL is a confusing and terrifying mess, and SSL is bad because he doesn't understand the code.
First, I have yet to see a SSL library where the source code is not a nightmare.
As I am writing this, the varnish source-code tree contains 82.595 lines of.c and.h files, including JEmalloc (12.236 lines) and Zlib (12.344 lines).
OpenSSL, as imported into FreeBSD, is 340.722 lines of code, nine times larger than the Varnish source code, 27 times larger than each of Zlib or JEmalloc.
This should give you some indication of how insanely complex the canonical implementation of SSL is.
Second, it is not exactly the best source-code in the world. Even if I have no idea what it does, there are many aspect of it that scares me.
Translation: SSL libraries are big and scary, SSL is big and confusing and I have no idea what the hell it does so it's bad.
The problem is you can't confirm your vote hasn't been tampered with unless there's identifying information downstream. Votes are supposed to leave the voting house with nobody's name attached: your votes are truly anonymous, cast on a paper without your Citizen ID or even your casual name thereupon. If you're keeping identifying information downstream, then you can satisfy all this cryptographically, and there's no need for access to the source code because math.
I didn't say "THE TSA" has to go to prison. I said somebody has to go to prison. You walk in, you find the guy that authorized body scanners, you ask who instructed him to authorize the body scanners. You find that guy, same question. You keep going up the line until it stops. Then you arrest that guy. Then you find the guy who has primary control over the policy, and arrest him too. You put both of them in prison and give their underlings promotion.
My question is why aren't people going to prison? The Supreme Court gave a legally binding order and nobody complied, that means somebody's got to go to prison.
No, it wouldn't. Where are you going to get the data set? In a centralized voting system, the data comes from thousands of terminals. If those terminals are state-controlled, you can't examine the actual binary software running on them, and don't know if they're mucking with the data. If they're home PCs, you can't collect data off every terminal individually, and have to rely on a central server to give you the consolidated report to verify--which it may be mucking with.
Votes aren't supposed to have an identity tied to them, either, which makes the system difficult in any implementation, vulnerable to all sorts of fraud--and also vetos the suggestion that we let individuals generate and register an RSA key and digitally sign their votes. An individual could bring a card loaded with their own RSA key generated at home, which is anonymous, and then later verify theirs and only theirs out of the data set, which creates risk; of course in that case the verification is in the key rather than the system, and thus whether it's open source or shifty backroom magic doesn't really matter. A separate, signed file and printed paper record could be placed on the card (for removal later, so you can guarantee the information isn't used during verification) that records your actual vote. The paper record is verifiable by the end user, the signed file is verifiable by computers but its accuracy can't be verified immediately (all the tools at the voting station are of unknown integrity, unless your cell phone has NFR and a verified app to check the file).
In either case, open source doesn't matter. Either you can't trace and can't verify the vote because the system can invisibly muck with data before it gives you the data set to verify; or you can trace and the system can't muck with data.
Finger training versus mental expectation. The Dvorak keyboard is not the image you expect, so your visual hunt and peck with your thumbs isn't going to work so well. There's no tactile orientation. In other words, your brain is using the image of a keyboard to do cell phone typing--and that's a QWERTY image. If Dvorak was the familiar and Qwerty was strange, your brain would visually orient based on Dvorak, and it'd be easier.
No kidding. Dextr is just alphabetic with the vowels in a column. It's stupid. A Qwerty style keyboard in a Dvorak layout (slide-out wide keyboard) would actually work great on a phone--because your thumbs would alternate, just like you alternate hands on Dvorak. Of course that's biased to English, but the principle stands: give me a reason to use a different layout, don't just throw something stupid but pretty in front of me and claim the old thing is outdated and the new hotness is new. We know it's new. Getting herpes would also be a refreshing change, but I think I'm better off with the mundane life of being STD free.
But you pushed "Ron Paul 2012" and the ticket spit back "Ron Paul 2012" and internally it decided that you're one of the lucky 11% that gets to vote for Obama instead. I download the data and run the open source verifier and it says yep all good.
No, it would be a terrible world to live in, because network operators would demand a "secure" phone from vendors so they could rid themselves of built-in e-mail applications and then charge $10/month for them (Verizon did this with the RAZR, for example) without pesky end users replacing the OS. Thus we'd all have Symbian or maybe Windows Phone 7 phones instead of Android.
Slashdot Mirror
The cheapest thing there is $320USD and the cheapest RepRap thing there is $499USD.
Good, finally ARM manufacturers will stop having a monopoly where they can charge whatever they want. I've seen hints at OEM chip prices and they're ridiculous compared to even desktop chips.
It's probably actually higher grade. The massive power output of a 50-200W processor is due to leakage--that is, it's due to poor efficiency. The Intel Atom for example was designed to leak less, and Intel's tighter packaging and lower TPD CPUs are based on new fabrication process that allows greater electrical efficiency. Bloated, poorly thought out designs bleed power as standing static field and heat--standing static field prevents smaller process, i.e. an imprecisely made junction will work on a 90nm process but at 32nm will bleed signal into all adjacent junctions and cause errors. Improving fidelity reduces bleed, allowing for a smaller process.
Somebody will clean up the stuff I glossed over for lack of understanding. The above's all just basics.
It doesn't matter really. ARM uses some 0.1-1.0W, MIPS uses 10-20W for slower clock speeds. ARM has fixed-width single-decode instructions; MIPS has three types of instructions of variable width. ARM does damn near everything in one clock, including evaluate-and-execute prefixed instructions ( { if ( n ) m = 5; } is 2 insns: 'cmp n' and a prefixed 'movnz m, 5'. If n == 0, movnz means 'nop'; otherwise it means 'mov'. Instead of 'cmp n; jnz @@a; mov m,5; @@a:' where jnz and mov have to be evaluated in separate stages. Yes it's been 11 years since I did assembly, it was 286 and 6502, and I'm unfamiliar with ARM by far). MIPS is slow. You may as well put an Intel CELERON in there if you go MIPS.
OEM chip prices like the Tegra 3 at $35 for a quad core 1.4GHz with a fifth extremely-low-power core bounded to 500MHz in single processor mode? With a full system-on-chip including system bridges, memory controllers, and full nVidia graphics, $35 is ridiculous. Why a quad core Sandy Bridge processor doesn't cost half that!
This isn't a matter of privacy. He can have privacy when he chats with his mistress about stopping by for a blow job on the way home; I don't give a rat's ass about the dalliances of our stately nobles. When he's talking to other administrative perfunctories, however, that shit goes on public record.
Can you find the made-up words?
He's obviously hiding something. Only crazy conspiracy theorists think every time something happens off the record they're hiding something; perceptive people notice when someone deliberately and intently shuffles things off the record.
eg reading from file all the time if you're virus checking everything
I keep forgetting I was writing a library to track and cache this because all vendor AV is shitty. It's ridicuolously easy to get right.
Actually, you're wrong. On IA-32, a non-executable bit is implemented by using the segmentation features of X86. Data is set to be the whole address space above the lowest data page. Code is set to be everything below the highest code page. In this way, basically, the stack is marked non-executable for no performance impact.
The rest of the address space is both data and code, and can be executed or altered. Memory protections are used to make executable pages non-writable; while non-executable data pages are marked as Supervisor. A TLB fault occurs upon access, in which case the kernel has to assist the TLB load due to lack of permissions in the USER context. The kernel examines the type of fault (Read, Write, Execute) and page permissions; if it's an Execute fault, it throws a General Protection Fault and terminates the program. If it's Read/Write, it instructs the CPU to perform a DTLB load and continue. Once the page is in the DTLB, its context is ignored unless an ITLB fault (on attempt to execute the page) is thrown (in which case the kernel kills the program). Until the DTLB is filled and the page is pushed out, or the DTLB is cleared by a context switch, the program can read/write the data page as normal.
Simple, yes?
The APIs are loaded in the procedure linkage table, referenced at an offset. Basically a PLT call is done by jumping to %epc+OFFSET, where OFFSET is the distance between the current position in the library and the position of the entry in the PLT to make a particular call. At that position a call is actually made, though it may be unresolved; if it's the first time that function has been called, the PLT executes a small piece of code to link that function, resolving and caching its load address. Then or otherwise, it makes the actual call.
Information is stored in the Global Offset Table (data) and the PLT in each library. This includes information about where in memory other shit is. If you randomize the bases, a piece of code still knows it's 379264 bytes to its PLT from a particular instruction; of course that's somewhere random in memory, but no matter since we know where we are now.
On 32-bit systems, ASLR can make success rates 1 in 65k, or .0015%, because library calls have to be precise and more than 256MB of randomness is unreasonable. The stack can move aligned to 16 bytes, but you can nullify that with a NOP slide--a non-executable stack makes the stack pure data, and thus can supply a good 1 in a million shot if you need to use it to store something (like a new executable file to write out to disk?).
When you have a 1 in 65k chance of success, you cause on average 32 THOUSAND failures to get ONE success out of a fork()ing program that keeps the same address space for each request. If the process re-initializes between attacks, you'll average 65 THOUSAND attacks per 1 success. It's easy to spot that kind of assault; some security tools even recognize repeated crashing and slow the processes down or send alerts. If we look at the connections to a process that crashes, we can surmise the common one(s) are the attackers if there's a single staging point. At the least you lose stealth.
The "Right to Privacy" is more a government thing, Amendment IV of the Constitution of the United States. The Government isn't allowed to perform search or seizure without due cause as acknowledged by judiciary approved warrant. Wire tapping laws were added later, of course; but these days it's fashionable to claim that since information moves on wires we should be allowed to record it. Nixon and Watergate all because of some recorded phone conversations, but in modern times the government wants to record everything that's not their business.
Privacy is a bigger factor in a voting system. People lie. Imagine how many negros may have voted for Bush while claiming to be powerful Obama supporters because all their negro friends are powerful Obama supporters. Imagine how many gays vote Republican (yes, they do) while all other gays are busy viciously demonizing Republicans because gay rights are the only thing that matters. Imagine how many folks in Georgia only voted for Obama or Al Gore because they knew their neighbors wouldn't find out and string 'em up. All these people vote the way they want, and lie to their friends about how they voted; it's impossible to pressure someone into voting, emotionally or physically. That's what a secret ballot is: a right to vote your mind without repercussions beyond voting some moron into power. In Alaska they made a cat mayor.
The statement that anything that X is good is half a fallacy. The Politician's Soliloquy is: Something must be done; This is something; Therefor, this must be done. In this case, you suggest something be done because we want to diminish our rep's powers, but a few holes exist.
The first is the obvious: identifying information. An effort like this could lead to a storage of identifying information--it would lead to a situation where you couldn't tell from the outside. Of course voting machines and identification and sign-in sheets lead to this kind of thing already: you sign in on the voting sheet, we roughly know the five minute span you were in the building and we know which votes were cast during that time since the votes can be timestamped (chad punch ballots don't have the exact time written on them!).
The second is less obvious: printed paper trail means someone has physical, snoopable record of their vote. When I leave the voting booth, I want to leave my vote behind; it exists in my head, it's cast, and you have no evidence against me. That's why votes are secret. To solidify that secret makes it discoverable; you cannot discover my vote in a ballot box among thousands of other votes. Such a paper trail is required to avoid false positives on vote changing (from buyer's remorse, conspiracy yahoos who create trouble intentionally, and plain idiots).
Every step forward costs money and creates a system that becomes somebody's pet. Removing bad ideas is ridiculously hard; we have to move conservatively because people are too stupid to rip out things that just don't work. Really we should fire these people and throw their pet projects in the trash, I know.
Ah, that's your problem then. You seek to count the votes properly, but counting the votes stopped being an issue when we eliminated paper ballots: votes are always counted properly.
Paper ballots are recorded by the voting individual; but electronic ballots are recorded by machine. If you want to mess with electronic votes, you alter the vote when it's cast instead of storing a proper vote and doing odd flipping.
Banking is different than voting. Votes don't have to come from anywhere; but money does. All bank transactions are double entry: money leaves one place and enters another. When you walk into a bank and deposit $100, this system finds its weakness: $100 shows up in your account from the ether. Of course, we know that a given branch produced $10,000 of cash-from-ether on a given day, and started with an amount of cash in it, and so we can count the cash boxes at each desk and figure out if a transaction magicked up the wrong amount of cash (not which, but we can determine there is an error). Checks are easier to trace--in fact banks routinely mis-account checks, mine even gave me $50 extra once and a week later during a weekly audit they caught the check and its matching transaction and took $50 from me. Cash is double and triple counted by hand, then counted by machine, then counted by hand again; checks are just deposited, and later electronically read, then audited (by hand and software comparison).
When votes come in, we can kind of say that 10,000 people came to the polling station. We can't say that 3000 votes for Bush and 7000 votes for Kerry came in; if we could, why the hell would we poll people? So these votes appear out of nowhere, with no verification. So we can say your vote was cast nice and proper, and log a vote for the other guy in the database nice and proper instead. Verification as a whole is impossible; verification by individuals of "their vote" is prone to ridiculous claims and buyer's remorse ("my vote was changed!" more like you want to change your vote...), hence why you need proof of vote cast (i.e. a paper print-out of your vote) or your complaints are invalid.
It's a big problem, really. Reliably counting votes is hard. Though you're right, keeping a verification chain for the voter makes it risky to flip votes; yet, again, it also requires storing identifying information, which is considered a bad thing.
Hey, sounds good to me! But where does the buck stop? Theoretically it goes all the way to the Chief Executive, especially if a cabinet agency refuses to comply with a court order. Is Obama going to throw himself in jail? And who's responsible for doing the arresting?
The Chief Executive of a government agency is the Secretary or Commissioner. That's why the DEA, DOJ, FBI, etc exist: the President doesn't have time for all this shit. If the President sends an order to not comply with the law, that's on him; otherwise it's the responsibility of his surrogate. If you're the Chief Executive Power for the TSA, you have two options: Prove that you reasonably couldn't have known about the actions of your agency or accept responsibility. In the event of a court order, somebody needs to get that order to you; if it gets to you, you are responsible. If it doesn't, you need to have a good case for it not being very widely known information in your agency and show that people went out of their way to keep it from you.
So in this case, the President of the United States is not responsible, but rather the Commissioner of the Transit Security Agency. Unless the President ordered the Commissioner to not comply, the Commissioner should go to prison. Not for an extremely long time perhaps, but long enough to think about what he's done.
When you rely on open source, you rely on source code. But when you rely on a machine controlled by someone else, that someone else may run binaries not compiled from the source code they gave you. Debian sends their own packages for i.e. Firefox, but they patch a lot of stuff; they tell you about the one-line changes made here or there, though, but you'd never know if they just said, "Here is firefox.deb".
You can analyze a binary compiled module. It's harder than source code, but it can be done. You can't analyze the contents of a hardware machine, though. If someone at Diebold put voting-software-with-diebold.patch.deb on the voting machines, but gave you voting-software.tar.gz and voting-software.deb sans Diebold patch, you'd never know What are you going to do? Commandeer the machines randomly mid-vote-day?
Why are we discussing SSL? The guy who develops Varnish has said that SSL is a mess, OpenSSL is a confusing and terrifying mess, and SSL is bad because he doesn't understand the code.
https://www.varnish-cache.org/docs/trunk/phk/ssl.html
First, I have yet to see a SSL library where the source code is not a nightmare.
As I am writing this, the varnish source-code tree contains 82.595 lines of .c and .h files, including JEmalloc (12.236 lines) and Zlib (12.344 lines).
OpenSSL, as imported into FreeBSD, is 340.722 lines of code, nine times larger than the Varnish source code, 27 times larger than each of Zlib or JEmalloc.
This should give you some indication of how insanely complex the canonical implementation of SSL is.
Second, it is not exactly the best source-code in the world. Even if I have no idea what it does, there are many aspect of it that scares me.
Translation: SSL libraries are big and scary, SSL is big and confusing and I have no idea what the hell it does so it's bad.
The problem is you can't confirm your vote hasn't been tampered with unless there's identifying information downstream. Votes are supposed to leave the voting house with nobody's name attached: your votes are truly anonymous, cast on a paper without your Citizen ID or even your casual name thereupon. If you're keeping identifying information downstream, then you can satisfy all this cryptographically, and there's no need for access to the source code because math.
I didn't say "THE TSA" has to go to prison. I said somebody has to go to prison. You walk in, you find the guy that authorized body scanners, you ask who instructed him to authorize the body scanners. You find that guy, same question. You keep going up the line until it stops. Then you arrest that guy. Then you find the guy who has primary control over the policy, and arrest him too. You put both of them in prison and give their underlings promotion.
My question is why aren't people going to prison? The Supreme Court gave a legally binding order and nobody complied, that means somebody's got to go to prison.
No, it wouldn't. Where are you going to get the data set? In a centralized voting system, the data comes from thousands of terminals. If those terminals are state-controlled, you can't examine the actual binary software running on them, and don't know if they're mucking with the data. If they're home PCs, you can't collect data off every terminal individually, and have to rely on a central server to give you the consolidated report to verify--which it may be mucking with.
Votes aren't supposed to have an identity tied to them, either, which makes the system difficult in any implementation, vulnerable to all sorts of fraud--and also vetos the suggestion that we let individuals generate and register an RSA key and digitally sign their votes. An individual could bring a card loaded with their own RSA key generated at home, which is anonymous, and then later verify theirs and only theirs out of the data set, which creates risk; of course in that case the verification is in the key rather than the system, and thus whether it's open source or shifty backroom magic doesn't really matter. A separate, signed file and printed paper record could be placed on the card (for removal later, so you can guarantee the information isn't used during verification) that records your actual vote. The paper record is verifiable by the end user, the signed file is verifiable by computers but its accuracy can't be verified immediately (all the tools at the voting station are of unknown integrity, unless your cell phone has NFR and a verified app to check the file).
In either case, open source doesn't matter. Either you can't trace and can't verify the vote because the system can invisibly muck with data before it gives you the data set to verify; or you can trace and the system can't muck with data.
Finger training versus mental expectation. The Dvorak keyboard is not the image you expect, so your visual hunt and peck with your thumbs isn't going to work so well. There's no tactile orientation. In other words, your brain is using the image of a keyboard to do cell phone typing--and that's a QWERTY image. If Dvorak was the familiar and Qwerty was strange, your brain would visually orient based on Dvorak, and it'd be easier.
But what guarantees that the source you get is the source code of the compiled object running on someone else's server?
No kidding. Dextr is just alphabetic with the vowels in a column. It's stupid. A Qwerty style keyboard in a Dvorak layout (slide-out wide keyboard) would actually work great on a phone--because your thumbs would alternate, just like you alternate hands on Dvorak. Of course that's biased to English, but the principle stands: give me a reason to use a different layout, don't just throw something stupid but pretty in front of me and claim the old thing is outdated and the new hotness is new. We know it's new. Getting herpes would also be a refreshing change, but I think I'm better off with the mundane life of being STD free.
But you pushed "Ron Paul 2012" and the ticket spit back "Ron Paul 2012" and internally it decided that you're one of the lucky 11% that gets to vote for Obama instead. I download the data and run the open source verifier and it says yep all good.
No, it would be a terrible world to live in, because network operators would demand a "secure" phone from vendors so they could rid themselves of built-in e-mail applications and then charge $10/month for them (Verizon did this with the RAZR, for example) without pesky end users replacing the OS. Thus we'd all have Symbian or maybe Windows Phone 7 phones instead of Android.