So, if all electronic voting systems were required to use Open Source software, the voters' right to vote would be returned. The U.S. would have electronic voting systems that enabled public scrutiny, and the ability to detect all but the most sophisticated undetectable manipulation of the vote count.
No. The problem will not go away just because you are using Open Source software, because you are not going nearly far enough.
At the end of the day, there are still only a minority of people who are in a position to scrutinise the process {and anyway, they don't know for certain that the software they scrutinised is the software that is loaded into the machines}.
Pencil and paper and manual counting are universally comprehensible. There's nothing scientific involved; every single voter can understand the system and its failure modes. And without that universal comprehensibility, democracy dies; because ultimately you cannot trust what you do not understand.
Allowing voters to "look up" how "their vote" was counted is a perfect smokescreen for a vote-rigging system. Besides which, it misses a point:
It's not how your vote was counted that makes the difference. It's how everyone else's vote was counted that makes the difference. Since you cannot know how everyone else voted, you cannot be sure that the result is correct. Most people's social networks are smaller than the margin for error; so even if you checked up your friends' and families' votes, they could all be shown "correctly" and the final result could still be wrong because all the votes that you don't get to see are more than enough to swamp the ones that you do get to see.
Also, any attempt to show people how they voted after the election opens up possibilities for voter coercion.
Stop right there: your failure mode originates in the fact that one device marks the ballot paper, and another device counts the votes -- but only if the ballot papers were properly marked in the first place. You could introduce an intermediate device to check that the ballot paper is correctly marked, but then you have introduced another failure mode whereby the pre-checker falsely indicates that a ballot paper which will be rejected by the counter is OK. Do you see where this is going? Please tell me how any of this is better than the manual counting practised in much of the world.
As for disabled people, the simplest method is just to allow them to take in a carer of their own choosing (so, presumably whom they trust) to help them cast their vote.
Count the fucking ballots by fucking hand in the fucking polling station in the fucking presence of the fucking candidates.
There is no machinery, therefore no systemic failure modes that are not universally comprehensible. By definition, none of the candidates trust each other; so they'll all be watching extra-hard in case anyone else makes a mistake. There are more than one person there, so disputes can be resolved easily: if a majority cannot agree that a ballot is correctly filled, it is rejected. No ballots can get lost because they stayed in the polling station the whole time. The process can be parallelised in each polling station, so the final result is available as soon as the slowest count is completed.
This sort of thing has been going on for ages. You check on a domain name, it turns out to be available, then next day it's mysteriously gone. After all, why would someone check up on the availability of a domain name unless they were interested in buying it? And if they're interested in buying it, maybe they wouldn't object to paying a bit more for it?
If you can afford a Nominet membership, two static IP addresses and a Linux box with Apache, Perl, GPG and BIND, you too can become a domain scammer! Sell domain names "from" some riduculously low figure, which -- it transpires, after reading the small print, which is so small you have to press ctrl + "+" several times just to be able to see it -- only applies to long, unpronounceable strings, with actual words coming at a higher rate. Set yourself up a dodgy affiliate programme {is that a tautology?} where people can put a little form on their pages querying your WHOIS service. A little drive-by download which diverts other domain queries to your own server wouldn't go amiss {best to do this from one of your affiliates' pages, though}. Now you know what domains people are looking up and, being a Nominet member, you are in a position to register the most interesting ones straight away {you can even do this fully-automatically, since all you have to do to buy a domain is send a GPG-encrypted email}.
Registering a domain is so cheap, if you're a member of Nominet, that it's worth a few failures for the successes you will achieve. (You can also register easy mistypings of the name, and post content there which might help persuade the owner of the correctly-spelt domain to purchase those domains from you.)
The "x86 everywhere" dream is coming to an abrupt halt anytime soon.
There'll be a new open RISC architecture along soon enough. It's a matter of time before the early-generation ARM patents expire, thus removing one of the barriers preventing wider adoption (it's a nice enough architecture, ARM just got greedy with their licencing). Every instruction being 32 bits long won't matter now memory is so cheap.
It's good that they've fixed the licence at last. The old PINE licence was a problem for distributions; getting it to work the way a particular distro wanted required modifying it, which -- for.rpm /.deb based distributions with pre-compiled packages -- was against the strictest interpretation of the terms. UW always tended to turn a blind eye to this (even hosting modified RPMs), but this isn't something you should ever rely on.
The problem is not that people "think or act differently from me in a way I disapprove". The problem is that people "think or act differently from me" in a way that can be actually harmful to me.
No, the poster is absolutely right! You can download an ISO image of the latest build of Duke Nukem Forever (beta) here. Burn this to a CD-R, then boot from it. At the prompt which will appear, type "autonuke" to automatically start the game of Duke Nukem Forever.
You are getting confused by people putting commas in thousands -- the sure mark of the innumerate.
Our Continental cousins -- who still like to use fountain pens, which are not good for making dots -- write the fraction delimiter as something resembling a comma, and used to use dots to mark thousands. It's been standard practice since about 50 years ago to delimit thousands with non-breaking spaces, and only use a mark -- a dot or a comma, depending upon which side of the Channel you are -- between the integer and the fraction.
It should have been "4 568 million years ago within a range of 2 080 000 years". But even that would have been better written as "4 568 000 000 years ago within a range of 2 080 000 years" or "4 568 million years ago within a range of 2.08 million years". That's about one part in 2200, so not actually bad going.
(C++ is a terrible, terrible language for doing anything in)A bad workman always blames his tools.
C++ makes the assumption that if you ask for potentially-dangerous toys, you know how to play safely with them. Just because you could easily hang yourself with that much rope, doesn't mean you might not have a legitimate reason to want it.
Still, it's a bit of an irrelevance. Nobody writes big projects in machine code (certainly the most "dangerous" language) anymore; we've gone from the age of the assembler to the age of the compiler. Give it another 25 years or so, and the compiler will give way to the interpreter. Look at the OLPC; pretty much everything on it is written in Python. The second-generation OLPC machines, to be built in new factories which will bring jobs to developing countries, probably won't even be using an 80x86 processor -- but they'll be source-compatible with the earlier ones.
For chuff's sake, you're solving the wrong problem already!
First, accept that there are always going to be some athletes who take drugs. Only then can you deal with it properly.
I suggest splitting the competition. Create an athlete's championship and a pharmacist's championship (as in Formula One, where there are separate prizes for the drivers and constructors). Then either do some sort of handicapping, or simply have separate drugged and non-drugged events.
If I'm adding an undefined value to a defined value I want to get the result and flag a warning, not get a compile or run time error and halt execution.
Then don't use strict; and your program won't die. Or wrap the code in an eval and test the result for definedness (hey, you might even get to use the spiffy new//= operator). If you omit the -w in the first line (usually #!/usr/bin/perl -w), then you won't even get a warning.
And personally, I think print (2).("3"); should print "11".
Ah, I get this..... you want to evaluate two single-element lists as scalars (so returning the count of elements in the list), concatenate the results and print that. Unfortunately, Perl has different ideas about operator precedence. Lists evaluated in a scalar context do normally return the count of items in the list, but single-element lists evaluated in a scalar context -- which look remarkably similar to simple scalar expressions in round brackets -- magickally return the only member instead. You'd have to do an assignment in a list context to coerce such an expression to be a real single-element list, then evaluate the list as a scalar.
No. The === sign is a PHPism for equal in value and of the same type, and is necessary to override some of PHP's magick. PHP differentiates internally between strings, floating-point numbers, integers and booleans. So "5", 5 and 5.0 are different types even though they have equal values. The <, <=, ==, >=, > and != operators are being overloaded and this is potentially creating a problem when comparing different types; for instance, "5" "10". Note also that true and false are coerced to integers 1 and 0 respectively, if you try to evaluate them in any non-Boolean context (including printing); and that PHP4's typecasting would actually support the use of + as a string concatenation operator, if the . concatenation operator hadn't already been introduced in PHP3.
Perl uses altogether different magick. It doesn't distinguish at all between strings and numbers, at least not at any level that is exposed to the programmer; they're all just scalars as far as Perl is concerned. Instead, you have to use different equality operators depending on whether you want to treat the things being compared as strings or numbers. Using <, <=, ==, >=, > or != causes the arguments to be compared as though they were numeric (possibly generating warnings if they aren't). If you want scalars to be compared as strings, you use Fortran-style lt, le, eq, ge, gt and ne operators (note this is the opposite way round from how sh does it). Then "5" == 5 and "5" == 5.0. And "5" eq 5, but 5 ne 5.0.
The point is: either way works, but you can't have it both ways at once, because you'd be pitting operator-overloading magick against type-munging magick. 5 evaluated numerically is less than 10 but "5" evaluated as a string sorts later than "10", and you have to be able to specify which you mean. Either by using typecasting to bypass operator overloading, or by using non-overloaded operators in the first place.
Oh, and I forgot: There are no integers or floating-point numbers, just numbers. I don't want to have to call a function to convert "3" into "3", and I definitely don't want to have to call a function to convert 3 into 3.0. That's another matter for the computer to think about. Back in the days of BASIC on 8-bit micros, it might have mattered; integer arithmetic was appreciably faster than software floating-point and saved a byte (if you had 32-bit integers, or three if you had 16-bit integers) in your symbol table.
Casting from string to number should always be done explicitly, with precise definition of the data type you cast to, and ideally with an error catching block in case something goes wrong. Letting it be done implicitly is a recipe for headache.
Let me guess: You like Pascal. The language that, if it was a car, would have only one pedal and two forward gears.
I program in high-level languages precisely because I don't want to have to think about whether something is a string or a number. I have bought and paid for, with my own money, earned by effort of hand or brain, enough RAM, disk space and CPU cycles to afford myself that little luxury. I grew up with 1980s 8-bit machines, learned to use instructions as numeric constants, when to bit-pack and when not to (the extra unpacking code can negate the saving), and all the other ways you can shave a byte off here or there (even putting code in the framebuffer and hiding it by palette-switching mid-frame). Now the computer is smart enough to take care of all that trivial crap, leaving me to sweat the big stuff.
$ perl -e 'print 2 . "3", "\n"'
returns 23 on my system (perl, v5.8.8 built for x86_64-linux-gnu-thread-multi). Note you need a space before the dot, otherwise Perl gets its knickers in a twist because a dot looks like the fraction delimiter; but that's OK, because we don't have to strip out unnecessary spaces to make our code fit into the remaining 6KB of RAM (after allowing 20K for the framebuffer and 6K reserved for the system) anymore. And Python throws an error for "2" + 3. That's correct, strictly, but it goes against the Principle of Least Surprise (Perl gives you 5, which is both correct and Least Surprising. JavaScript gives you "23", which is neither correct nor in accordance with the Principle of Least Surprise).
Anyway, my point is that where there is an addition sign, there should be addition (and if a string has to be converted to a number, so be it; don't throw an error unless it's NaN. And provide a mechanism whereby NaN values can be silently treated as zero).
True; but Python {which is otherwise a high-level language} insists for you to call a function just to convert between a string and a number, all so it can recycle an operator. Perl treats numbers and strings interchangeably {and, be brutally honest, isn't the whole point of using a high-level language so you don't have to think about stuff like that?}, but uses distinct operators for distinct operations. JavaScript manages to balls it up both ways, treating things as being the same one minute and different another. Fortunately, you can just pretend that there is no addition operator in JS, and subtract negative numbers instead.
At least Perl knows that adding numbers and concatenating string are different operations.
2 + 3 == 5 (Perl isn't that weird)
2 + "3" == 5 (not a TypeError as in Python)
"2" + 3 == 5 (not "23" as in JavaScript)
"2" + "3" == 5 (not "23" as in both JavaScript and Python)
So how long will it be before somebody manufactures an industrial-grade inkjet printer with durable metal parts, which takes bulk ink (by flexible hoses, from litre bottles which can be hot-swapped) and incorporates PostScript Level 3 in hardware so absolutely no driver issues?
There's definitely a market for such a machine. I've been using a HP Business Inkjet, which is certainly semi-industrial and although not PS, uses a common driver; but it still takes ink cartridges (double-sized black cartridge, though) and a new set adds up to a hefty amount. A bulk-fed, metal-built printer would easily outlast the number of cartridges you could have bought for the same price.
Slashdot Mirror
At the end of the day, there are still only a minority of people who are in a position to scrutinise the process {and anyway, they don't know for certain that the software they scrutinised is the software that is loaded into the machines}.
Pencil and paper and manual counting are universally comprehensible. There's nothing scientific involved; every single voter can understand the system and its failure modes. And without that universal comprehensibility, democracy dies; because ultimately you cannot trust what you do not understand.
Allowing voters to "look up" how "their vote" was counted is a perfect smokescreen for a vote-rigging system. Besides which, it misses a point:
It's not how your vote was counted that makes the difference. It's how everyone else's vote was counted that makes the difference. Since you cannot know how everyone else voted, you cannot be sure that the result is correct. Most people's social networks are smaller than the margin for error; so even if you checked up your friends' and families' votes, they could all be shown "correctly" and the final result could still be wrong because all the votes that you don't get to see are more than enough to swamp the ones that you do get to see.
Also, any attempt to show people how they voted after the election opens up possibilities for voter coercion.
Stop right there: your failure mode originates in the fact that one device marks the ballot paper, and another device counts the votes -- but only if the ballot papers were properly marked in the first place. You could introduce an intermediate device to check that the ballot paper is correctly marked, but then you have introduced another failure mode whereby the pre-checker falsely indicates that a ballot paper which will be rejected by the counter is OK. Do you see where this is going? Please tell me how any of this is better than the manual counting practised in much of the world.
As for disabled people, the simplest method is just to allow them to take in a carer of their own choosing (so, presumably whom they trust) to help them cast their vote.
Simple solution:
Count the fucking ballots by fucking hand in the fucking polling station in the fucking presence of the fucking candidates.
There is no machinery, therefore no systemic failure modes that are not universally comprehensible. By definition, none of the candidates trust each other; so they'll all be watching extra-hard in case anyone else makes a mistake. There are more than one person there, so disputes can be resolved easily: if a majority cannot agree that a ballot is correctly filled, it is rejected. No ballots can get lost because they stayed in the polling station the whole time. The process can be parallelised in each polling station, so the final result is available as soon as the slowest count is completed.
This sort of thing has been going on for ages. You check on a domain name, it turns out to be available, then next day it's mysteriously gone. After all, why would someone check up on the availability of a domain name unless they were interested in buying it? And if they're interested in buying it, maybe they wouldn't object to paying a bit more for it?
If you can afford a Nominet membership, two static IP addresses and a Linux box with Apache, Perl, GPG and BIND, you too can become a domain scammer! Sell domain names "from" some riduculously low figure, which -- it transpires, after reading the small print, which is so small you have to press ctrl + "+" several times just to be able to see it -- only applies to long, unpronounceable strings, with actual words coming at a higher rate. Set yourself up a dodgy affiliate programme {is that a tautology?} where people can put a little form on their pages querying your WHOIS service. A little drive-by download which diverts other domain queries to your own server wouldn't go amiss {best to do this from one of your affiliates' pages, though}. Now you know what domains people are looking up and, being a Nominet member, you are in a position to register the most interesting ones straight away {you can even do this fully-automatically, since all you have to do to buy a domain is send a GPG-encrypted email}.
Registering a domain is so cheap, if you're a member of Nominet, that it's worth a few failures for the successes you will achieve. (You can also register easy mistypings of the name, and post content there which might help persuade the owner of the correctly-spelt domain to purchase those domains from you.)
The "x86 everywhere" dream is coming to an abrupt halt anytime soon.
There'll be a new open RISC architecture along soon enough. It's a matter of time before the early-generation ARM patents expire, thus removing one of the barriers preventing wider adoption (it's a nice enough architecture, ARM just got greedy with their licencing). Every instruction being 32 bits long won't matter now memory is so cheap.
It's good that they've fixed the licence at last. The old PINE licence was a problem for distributions; getting it to work the way a particular distro wanted required modifying it, which -- for .rpm / .deb based distributions with pre-compiled packages -- was against the strictest interpretation of the terms. UW always tended to turn a blind eye to this (even hosting modified RPMs), but this isn't something you should ever rely on.
The problem is not that people "think or act differently from me in a way I disapprove". The problem is that people "think or act differently from me" in a way that can be actually harmful to me.
No, the poster is absolutely right! You can download an ISO image of the latest build of Duke Nukem Forever (beta) here. Burn this to a CD-R, then boot from it. At the prompt which will appear, type "autonuke" to automatically start the game of Duke Nukem Forever.
You mean, "qui donne une merde concernant ces culs muets", surely?
You are getting confused by people putting commas in thousands -- the sure mark of the innumerate.
Our Continental cousins -- who still like to use fountain pens, which are not good for making dots -- write the fraction delimiter as something resembling a comma, and used to use dots to mark thousands. It's been standard practice since about 50 years ago to delimit thousands with non-breaking spaces, and only use a mark -- a dot or a comma, depending upon which side of the Channel you are -- between the integer and the fraction.
It should have been "4 568 million years ago within a range of 2 080 000 years". But even that would have been better written as "4 568 000 000 years ago within a range of 2 080 000 years" or "4 568 million years ago within a range of 2.08 million years". That's about one part in 2200, so not actually bad going.
It was pissed, on its birthday. It's probably sobered up now, though.
(C++ is a terrible, terrible language for doing anything in)A bad workman always blames his tools.
C++ makes the assumption that if you ask for potentially-dangerous toys, you know how to play safely with them. Just because you could easily hang yourself with that much rope, doesn't mean you might not have a legitimate reason to want it.
Still, it's a bit of an irrelevance. Nobody writes big projects in machine code (certainly the most "dangerous" language) anymore; we've gone from the age of the assembler to the age of the compiler. Give it another 25 years or so, and the compiler will give way to the interpreter. Look at the OLPC; pretty much everything on it is written in Python. The second-generation OLPC machines, to be built in new factories which will bring jobs to developing countries, probably won't even be using an 80x86 processor -- but they'll be source-compatible with the earlier ones.
For chuff's sake, you're solving the wrong problem already!
First, accept that there are always going to be some athletes who take drugs. Only then can you deal with it properly.
I suggest splitting the competition. Create an athlete's championship and a pharmacist's championship (as in Formula One, where there are separate prizes for the drivers and constructors). Then either do some sort of handicapping, or simply have separate drugged and non-drugged events.
No. The === sign is a PHPism for equal in value and of the same type, and is necessary to override some of PHP's magick. PHP differentiates internally between strings, floating-point numbers, integers and booleans. So "5", 5 and 5.0 are different types even though they have equal values. The <, <=, ==, >=, > and != operators are being overloaded and this is potentially creating a problem when comparing different types; for instance, "5" "10". Note also that true and false are coerced to integers 1 and 0 respectively, if you try to evaluate them in any non-Boolean context (including printing); and that PHP4's typecasting would actually support the use of + as a string concatenation operator, if the . concatenation operator hadn't already been introduced in PHP3.
Perl uses altogether different magick. It doesn't distinguish at all between strings and numbers, at least not at any level that is exposed to the programmer; they're all just scalars as far as Perl is concerned. Instead, you have to use different equality operators depending on whether you want to treat the things being compared as strings or numbers. Using <, <=, ==, >=, > or != causes the arguments to be compared as though they were numeric (possibly generating warnings if they aren't). If you want scalars to be compared as strings, you use Fortran-style lt, le, eq, ge, gt and ne operators (note this is the opposite way round from how sh does it). Then "5" == 5 and "5" == 5.0. And "5" eq 5, but 5 ne 5.0.
The point is: either way works, but you can't have it both ways at once, because you'd be pitting operator-overloading magick against type-munging magick. 5 evaluated numerically is less than 10 but "5" evaluated as a string sorts later than "10", and you have to be able to specify which you mean. Either by using typecasting to bypass operator overloading, or by using non-overloaded operators in the first place.
Oh, and I forgot: There are no integers or floating-point numbers, just numbers. I don't want to have to call a function to convert "3" into "3", and I definitely don't want to have to call a function to convert 3 into 3.0. That's another matter for the computer to think about. Back in the days of BASIC on 8-bit micros, it might have mattered; integer arithmetic was appreciably faster than software floating-point and saved a byte (if you had 32-bit integers, or three if you had 16-bit integers) in your symbol table.
I program in high-level languages precisely because I don't want to have to think about whether something is a string or a number. I have bought and paid for, with my own money, earned by effort of hand or brain, enough RAM, disk space and CPU cycles to afford myself that little luxury. I grew up with 1980s 8-bit machines, learned to use instructions as numeric constants, when to bit-pack and when not to (the extra unpacking code can negate the saving), and all the other ways you can shave a byte off here or there (even putting code in the framebuffer and hiding it by palette-switching mid-frame). Now the computer is smart enough to take care of all that trivial crap, leaving me to sweat the big stuff.
$ perl -e 'print 2 . "3", "\n"'
returns 23 on my system (perl, v5.8.8 built for x86_64-linux-gnu-thread-multi). Note you need a space before the dot, otherwise Perl gets its knickers in a twist because a dot looks like the fraction delimiter; but that's OK, because we don't have to strip out unnecessary spaces to make our code fit into the remaining 6KB of RAM (after allowing 20K for the framebuffer and 6K reserved for the system) anymore. And Python throws an error for "2" + 3. That's correct, strictly, but it goes against the Principle of Least Surprise (Perl gives you 5, which is both correct and Least Surprising. JavaScript gives you "23", which is neither correct nor in accordance with the Principle of Least Surprise).
Anyway, my point is that where there is an addition sign, there should be addition (and if a string has to be converted to a number, so be it; don't throw an error unless it's NaN. And provide a mechanism whereby NaN values can be silently treated as zero).
True; but Python {which is otherwise a high-level language} insists for you to call a function just to convert between a string and a number, all so it can recycle an operator. Perl treats numbers and strings interchangeably {and, be brutally honest, isn't the whole point of using a high-level language so you don't have to think about stuff like that?}, but uses distinct operators for distinct operations. JavaScript manages to balls it up both ways, treating things as being the same one minute and different another. Fortunately, you can just pretend that there is no addition operator in JS, and subtract negative numbers instead.
At least Perl knows that adding numbers and concatenating string are different operations.
2 + 3 == 5 (Perl isn't that weird)
2 + "3" == 5 (not a TypeError as in Python)
"2" + 3 == 5 (not "23" as in JavaScript)
"2" + "3" == 5 (not "23" as in both JavaScript and Python)
So how long will it be before somebody manufactures an industrial-grade inkjet printer with durable metal parts, which takes bulk ink (by flexible hoses, from litre bottles which can be hot-swapped) and incorporates PostScript Level 3 in hardware so absolutely no driver issues?
There's definitely a market for such a machine. I've been using a HP Business Inkjet, which is certainly semi-industrial and although not PS, uses a common driver; but it still takes ink cartridges (double-sized black cartridge, though) and a new set adds up to a hefty amount. A bulk-fed, metal-built printer would easily outlast the number of cartridges you could have bought for the same price.
No, no, no.
A slut is a woman who will have sex with anyone.
A woman who will have sex with anyone except you is a bitch.
Cf. "..... but I'm not going to tell you whether I shagged her or not, just in case you think she's a slut."