Re:Why a paper trail is really needed
on
Cringley on E-voting
·
· Score: 2, Interesting
You cannot provide a paper record to the voter, because it would undermine the ability to vote anonymously. An employer/union/church/spouse/etc. could demand it be provided as proof that you voted correctly, not just that you voted.
The way to work around this is to split the paper ballot into two parts. One, the main ballot, has a large high-quality random number on it as well as the vote indication. It does not hold the identity of the person who voted, and it is delivered into the ballot box. The other part contains the name of the person who voted and that magic random number, but not an indication of how the person voted; that indication is the only record kept of the association between name and number. Maybe the machines produce a tally themselves, but it is always possible to get the ballots from the boxes and count them by hand in front of witnesses from all the parties on the ballot.
If any voter has any reason to suspect that a machine has miscounted, they can demand a hand count and also see that their ballot was correctly in the box.
The mechanism isn't perfect (assault voter in secret after they leave, steal their receipt, and then demand a hand count so you can match the receipt) but I seriously doubt that you can get closer given that you need both auditing and security. (There's other tricks you can add like writing a cryptographic signature of the ballot on each main ballot, signed with the identity of the election officer(s) running the polling station, but that's countering against different kinds of problems.)
So's factoring prime numbers. What's a bit harder is determining whether a piece of software that is believed to be secure is in fact really secure. That takes a lot of work by very smart, experienced and creative people. It doesn't help that the threat-model that software has to deal with is not constant; its much easier to determine that a particular piece of software is secure against a particular class of attack than it is to determine that there is no possible attack at all.
Systems are secure when they exactly zero defects. Do you want to pay and wait for those to come along? It might take a few decades...
if John Q. Terrorist uploads a model for generating anthrax yields, are all the other people liable for assisting in the production of biological weapons?
No, since as part of the Grid, everyone will have proof of who authorized the calculation; you'll be able to say to the Feds "I can prove it was John Q. Terrorist, Kabul."
Of course, the Feds will ask you why you were selling any compute time to JQT given that the Grid doesn't mean that you have to sell to all-comers (no more than you have to give Unix shell accounts to anyone who asks), but that's another matter...
Sure, but why do they still have those wiring looms? Wouldn't they be better off putting in an on-plane network with a suitable protocol? Easier to shield, lower currents (i.e. fewer heating problems), and cheaper too. Or am I way off-base?
You'll just end up having to explain it, and--as the Heisenberg Principle attests--an explained joke ceases to be funny.
That only applies to Heisenjokes. (OTOH, I'd much rather deal with those than Heisenbugs. For the uninitiated, they are where a bug goes away when you attach any bug hunting machinery to a program...)
Someone else compared it to 127.0.0.1 on a *nix box, but there's already a loopback interface in Windows. The RPC service was originally intended for remote administration. A better analogy would be SSH, but I don't have to run SSH under *nix, do I?
That's a really duff analogy since SSH is mainly targetted at providing an equivalent to rsh (but secure, of course.) Better to compare it to CORBA or SunRPC (used for things like NFS and NIS+) as those are doing remote access to objects/services.
You're absolutely right that you don't have to run any of them though. No networking at all is required for a perfectly usable Unix system; I used to use Linux a lot for pay-work in that sort of configuration. (I did so miss USENET though.:^)
What they should do is [...] have the humans do what they need to do to the payload once it is in space (such as [...]
activation).
Surely they could type the numbers in from the front of the printed manual before they launch the equipment into space? It's not exactly rocket science...
Given the sort of spam that ends up in my mailbox, hooking the teletype up to print out the subjects of incoming mail messages would require upgrading the teletype to have UNICODE printing characters.
Heh. The Grid as the solution to everyone's problems? The Grid would work better if it had occurred to people that not everyone wants to configure their machines the same way. But oh, some people have thought of that. Just not anyone doing design of systems based on Globus. That's what comes of only using one application area though...
I'm no fan of the kludge that C is, but for an app of this size I would say that a compiled language would be nice.
You might think this, but you'd be wrong. Working with a higher level language (such as Perl, Tcl, Python or Scheme) would let you abstract much more rapidly away from the low level details (like memory management or types) and focus instead on the stuff that makes the application meaningful (like tax rules!) And that would save developer time, which in turn would mean that more gets done with the same amount of effort, which would be A Good Thing.
And there are some extremely clever pieces of code about to do compilation of high-level code down to stuff that goes faster. C should normally only be used for low-level stuff or where there is a measured bottleneck that C can squelch; wheeling it out to squeeze 1% more speed for 100% more effort is dumb in an ongoing project.
I agree it's a great package, and I love it- but there are several things which REALLY irk me.
[...]
Don't get me wrong- I DO love the program, but sometimes(mostly when reconciling), I want to scream after modifying 100+ entries into various categories...arrrrg:-)
Often times packages like these develop cool little "better than the commercial package" features. Gnucash, unfortunately, don't really surpass(or even come close) to quicken's functionality set.
Now, what I DO like:
So, when exactly are you going to volunteer something (time, effort, money towards hiring someone, etc.) towards GnuCash? If you like it so much, surely you're willing to help somehow?
With anything that is Free or Open software, it is contributions from the community that makes it what it can be. Sitting on your backside, freeloading, is wrong. Get out there. Help! Yes, that means YOU.
The patenting of the idea of plug-ins and applets is less ridiculous when you consider when the patent was applied for (1994, and yes, I've read the patent) but is still really a trivial extension to the online world of software practice at the time (such as dynamic loading of libraries, which is the real foundational technology) IIRC.
(throwing an exception 1 million times took 10 seconds, reusing took 0.5 seconds on a 650 Mhz Intel- and frankly, a million is a heck of a lot of exceptions!)
Mind you, if you've got code that throws a million exceptions in a day (I'd start worrying if it happened that often in a month), you've probably got a good reason to try to use some other error handling mechanism. Exceptions should be for when the shit hits the fan, not for dropping out of a loop where the programmer was too lazy to provide a normal exit mechanism.
The only real problem with UTF-8 is that it is expensive (i.e. O(n) instead of O(1), making many algorithms go from linear to quadratic, which is very noticeable on longer input texts!) to index into the string by character position (as opposed to byte pointer). It's a bit of a shame that that's actually a fairly commonly desired thing in text processing applications...
UTF-8 is also frequently used any time you want to start combining, say, English, Russian, Chinese and Korean (plus math, of course) into the same document. The alternative is that you have some way of switching encodings part way through, and that's a much suckier (i.e. more bug-prone) way of doing things.
Also, the poster above is WRONG about the regular expressions in Perl 6. We NEED a new regex syntax desperately. I'm tired of writing '(?:foo|bar)' when something like '[foo|bar]' or '(foo|bar)' would be clearer. Unfortunately all the other languages picked up this crap as "perl-style regexps".
The problem is that REs do so many things that a normal US keyboard doesn't have enough printable characters on it to describe them all simply. (Your example replacements are already used for other things - character sets and capturing sub-REs respectively.) OK, there are other matching bracket pairs in the UNICODE character sets, but people'd scream blue murder if they had to type them into their scripts in most locales...
Hmm. That's set me thinking. What's the bandwidth of a large cargo ship (filled with the high-density mass-storage devices of your choice, of course) going across the Atlantic, compared with the trans-Pond pipes?
Oh grief! Knowing the govt, they'd find a way to charge you for every text message received as well (an architecture which is already there and in heavy use by mobile service providers.) So not only would your rights be controlled by an oscillator, but you'd get hit in the wallet for every state change...
Configuring a print server over telnet? Urk! Couldn't they use OpenSSH or something like that instead so that the use of a fascist firewall isn't mandated?
Re:Kiss and say goodbye to Java language!!
on
PHP 5 Beta 1
·
· Score: 1
As a final point, you might suggest that the teams I've worked with do not understand Java or how to run it well. [...]
Hmm, experience says that for server-side stuff this probably indicates that someone hasn't told these programmers about the difference between String and StringBuffer. It's amazing how many Java programmers (including many who ought to know better) just don't get it.
Comes of hiring monkeys for peanuts instead of Real Programmers (for caffeine and something disgusting from a vending machine!:^)
Java is a good all around best choice for most programing tasks, unless you can understand LISP. It excels in daemon work, but never really gets used there. Consider that you will never have buffer overflows, you will usually not have to restart daemons, and Java has a framework for single threaded TCP/IP IO.
I'd agree that it is on the server-side that Java's strengths really start to show. The lack of buffer-overruns is rather good, the built-in support for security is rather good, the speed is rather good too. The I/O... well, at least doesn't suck as much as it used to though it is nowhere near as usable as it ought to be...
I won't defend the speed (or, for that matter, the usability) of Java2D/Swing though. Client code is not Java's strength IMHO.
Sure, but since you've no real idea when GC's going to happen, you'd better close things anyway because otherwise you'll hit your per-process limit on the number of FD's. (You do have process accounting turned on, yes?) It's always been good style to use close() with I/O in Java, and the NIO mods just push this a tiny bit further. (Thank goodness for try{...}finally{...}!)
If you need jni to make something usable (in the common case), then the language isn't practical.. jni is for porting or special cases.
However it is possible to do an awful lot without any native methods. I'm working here on a Grid system written in Java, and no JNI code is required in it (except for some experimental low-level platform stuff where it is used to get access to the setuid() syscall. But that code is not normally used; we prefer a little bit of Perl instead, as that's marginally easier to port to some of the more bizarre supercomputer architectures.)
The big advantage of Java (over C++ especially) is that it is far easier to trust the security of Java. And I don't want to think about porting C#.NET to the places we're using Java!
Slashdot Mirror
The way to work around this is to split the paper ballot into two parts. One, the main ballot, has a large high-quality random number on it as well as the vote indication. It does not hold the identity of the person who voted, and it is delivered into the ballot box. The other part contains the name of the person who voted and that magic random number, but not an indication of how the person voted; that indication is the only record kept of the association between name and number. Maybe the machines produce a tally themselves, but it is always possible to get the ballots from the boxes and count them by hand in front of witnesses from all the parties on the ballot.
If any voter has any reason to suspect that a machine has miscounted, they can demand a hand count and also see that their ballot was correctly in the box.
The mechanism isn't perfect (assault voter in secret after they leave, steal their receipt, and then demand a hand count so you can match the receipt) but I seriously doubt that you can get closer given that you need both auditing and security. (There's other tricks you can add like writing a cryptographic signature of the ballot on each main ballot, signed with the identity of the election officer(s) running the polling station, but that's countering against different kinds of problems.)
Systems are secure when they exactly zero defects. Do you want to pay and wait for those to come along? It might take a few decades...
Of course, the Feds will ask you why you were selling any compute time to JQT given that the Grid doesn't mean that you have to sell to all-comers (no more than you have to give Unix shell accounts to anyone who asks), but that's another matter...
Sure, but why do they still have those wiring looms? Wouldn't they be better off putting in an on-plane network with a suitable protocol? Easier to shield, lower currents (i.e. fewer heating problems), and cheaper too. Or am I way off-base?
You're absolutely right that you don't have to run any of them though. No networking at all is required for a perfectly usable Unix system; I used to use Linux a lot for pay-work in that sort of configuration. (I did so miss USENET though. :^)
Given the sort of spam that ends up in my mailbox, hooking the teletype up to print out the subjects of incoming mail messages would require upgrading the teletype to have UNICODE printing characters.
Heh. The Grid as the solution to everyone's problems? The Grid would work better if it had occurred to people that not everyone wants to configure their machines the same way. But oh, some people have thought of that. Just not anyone doing design of systems based on Globus. That's what comes of only using one application area though...
Bah. Might as well ask for the mean flight speed of an unladen swallow...
And there are some extremely clever pieces of code about to do compilation of high-level code down to stuff that goes faster. C should normally only be used for low-level stuff or where there is a measured bottleneck that C can squelch; wheeling it out to squeeze 1% more speed for 100% more effort is dumb in an ongoing project.
With anything that is Free or Open software, it is contributions from the community that makes it what it can be. Sitting on your backside, freeloading, is wrong. Get out there. Help! Yes, that means YOU.
The patenting of the idea of plug-ins and applets is less ridiculous when you consider when the patent was applied for (1994, and yes, I've read the patent) but is still really a trivial extension to the online world of software practice at the time (such as dynamic loading of libraries, which is the real foundational technology) IIRC.
The only real problem with UTF-8 is that it is expensive (i.e. O(n) instead of O(1), making many algorithms go from linear to quadratic, which is very noticeable on longer input texts!) to index into the string by character position (as opposed to byte pointer). It's a bit of a shame that that's actually a fairly commonly desired thing in text processing applications...
UTF-8 is also frequently used any time you want to start combining, say, English, Russian, Chinese and Korean (plus math, of course) into the same document. The alternative is that you have some way of switching encodings part way through, and that's a much suckier (i.e. more bug-prone) way of doing things.
Of course, I don't favour Perl, Python or Ruby...
Hmm. That's set me thinking. What's the bandwidth of a large cargo ship (filled with the high-density mass-storage devices of your choice, of course) going across the Atlantic, compared with the trans-Pond pipes?
Oh grief! Knowing the govt, they'd find a way to charge you for every text message received as well (an architecture which is already there and in heavy use by mobile service providers.) So not only would your rights be controlled by an oscillator, but you'd get hit in the wallet for every state change...
Configuring a print server over telnet? Urk! Couldn't they use OpenSSH or something like that instead so that the use of a fascist firewall isn't mandated?
Hmm, experience says that for server-side stuff this probably indicates that someone hasn't told these programmers about the difference between String and StringBuffer. It's amazing how many Java programmers (including many who ought to know better) just don't get it.
Comes of hiring monkeys for peanuts instead of Real Programmers (for caffeine and something disgusting from a vending machine!
I'd agree that it is on the server-side that Java's strengths really start to show. The lack of buffer-overruns is rather good, the built-in support for security is rather good, the speed is rather good too. The I/O... well, at least doesn't suck as much as it used to though it is nowhere near as usable as it ought to be...
I won't defend the speed (or, for that matter, the usability) of Java2D/Swing though. Client code is not Java's strength IMHO.
Sure, but since you've no real idea when GC's going to happen, you'd better close things anyway because otherwise you'll hit your per-process limit on the number of FD's. (You do have process accounting turned on, yes?) It's always been good style to use close() with I/O in Java, and the NIO mods just push this a tiny bit further. (Thank goodness for try{...}finally{...}!)
The big advantage of Java (over C++ especially) is that it is far easier to trust the security of Java. And I don't want to think about porting C#.NET to the places we're using Java!