The polling station does not keep any part of your receipt -- they DESTROY half your receipt.
Why? For the exact reason you bring up -- so noone can tell who you voted for. Your votes are encrypted on each layer of the receipt, and they are also visible when the two layers are overlayed on top of each other. The receipt you keep is also recorded as your vote. Once the other half is destroyed, your ballot can only be decrypted during the tally process.
The beauty of the system is that your receipt can be used to verify the entire voting process from beginning to the end, from the voting machine to the final tally. To verify the voting machine and the registration of your vote, anyone can visually compare your receipt with your recorded vote -- if the images match then it hasn't been tempered with. The tally process can be similarly verified by anyone, except that no specific ballots can be traced from beginning to the end. A randomly chosen 50% of the ballots are checked at each step of the decryption and shuffling process, enough to make it impossible to cheat, but not enough that ballots could be traced all the way through.
If they believe TIVO and Zaurus infringes, they must believe every installation of linux does...
I mean, how does embedded linux running on low performace, single cpu, non-intel hardware have anything to do with their IP claims?
Are they saying that these devices perform like SCO UnixWare on high end server hardware thanks to their IP?
Probably they're under the impression that Linux is a Unix derivative thanks to their IP, and therefore they own all rights to it. Regardless of the features that are actually used in any particular installation.
I agree with you on some points, but I think you lack some imagination. (for better or worse:) )
For exampe, the access control system itself is not discussed in the article beyond the suggestion that the access control information itself (attributes, permissions, acl, etc.) could be treated like arbitrary metadata. Obviously, this doesn't mean that access control would be voluntary, or enforced by applications such as "cp"!! Some access control mechanism has to be present, and that system would have to excercise access control over its own metadata files too.
Imagine that the access control system would only allow the superuser to modify access control related metadata files. You'd have a host of setuid utilities, running as root, to manipulate the metadata and enforce access control. For custom access control, you'd write your own setuid utiltiy replacements.
Or imagine a unix-compatible access control system that took on more responsibliy. The old setuid utilties could be replaced by simpler ones that manipulated the metadata, and did nothing else. For custom access control, you'd still write setuid utiltiy replacements.
Or imagine an access control system that was very flexible and configurable. For custom access control, perhaps you would get away with a one-liner in a system config file.... Or you could still write your setuid utiltiy replacements.
Or imagine that the access control system might become totally pluggable, and you could choose whether you wanted windows semantics, unix semantics, or your own access control logic with your own arbitrary meta data.
Having access control information stored as arbitrary metadata in the namespace simply does not imply that you would loose access control, nor that setuid and setgid programs would *have* to go away. It simply opens other possibilities under the assumption that more and more of the access control logic would be moved into some central system. I guess it is arguable whether this is good or bad. The system still has to evolve and mature, and some of the solutions you call short sighed have yet to be considered seriously. Take what they have for inspiration, not as a blue print. It just isn't there yet. Reshape it using your own experience; try to find plausible solutions to the problems you see. Its refreshing to think outside the box, once in a while.
Calculating the correct change is not only more awkward using coins with weird denominations like 18cents, but the simple methods will no longer guarantee optimal change either. Even the article notes this:
Despite its apparent inefficiency, the current U.S. system of coin denominations has a striking advantage over many other possible systems. When most people make change, they give the coins with the largest possible value first, then the next largest, and so on. Computer scientists call such a scheme the "greedy algorithm."
"The nice thing about the current system is that the greedy algorithm always gives the smallest number of coins possible within the system," Shallit says. "So it's easy to make change."
For other sets of denominations, the greedy algorithm doesn't always give the minimum number of coins. For example, if coins had the values 1, 7, and 10, the greedy algorithm would represent 14 as 10 + 1 + 1 + 1 + 1, whereas the combination 7 + 7 uses fewer coins.
what about the real world?
on
Making Change
·
· Score: 1
In finding coin denominations that minimize the average cost of making change, Shallit assumed that every amount of change between 0 and 99 cents is equally likely.
Is this a valid assumption? Most of my change comes from small purchases, and the vast majority of small cost items have similar prices (i.e. 0.99, 1.29, 1.50, 4.95, etc). The amount of change from each of many small purchases will tend to fall into a few discreet values, and would not follow a uniform random distribution.
Room temperature supercondition would open up so many possibilities -- it may start a new era for technology. If diamonds are the key, would future generations call it the diamond age?
No connection to Neal Stephenson's book called the Diamond age, as that refered to something quite different...
One of the reasons consumers are supposed to care about Palladium is the protection it can offer against running untrusted code such as viruses. Seems that a good number of the effective viruses are not standalone executables, but Outlook scripts, Word macros and the like.
Is Palladium supposed to offer any protection against these? (If not, then skip the rest of the arguments...)
How would Palladium help? Presumably MicroSoft applications would be "trusted", yet these applications are the executables that are doing the damage (while executing the macros or scripts).
Are scripts and macros going to be considered distinct executables, that must be independently certified and signed? What about very common scripts like javascript for HTML Image rollovers, layers, form validations, etc.?
If not every script has to be signed, then how does Palladium make a practical distinction between what does need to be signed and what doesn't?
If every scrip has to be signed, then how would a new Palladium enabled system keep compatibility with the existing web, existing microsoft documents, and microsoft's application design philosophy?
One thing no-one mentioned on slashdot yet is how nice repetitive gestures are on this keyboard.
Did you ever think about how (in)convenient moving the mouse pointer would be using keypresses? click-click-click; you'd only want to do it if you were truly desperate, it is so cumbersome.
That is what many text other keyboard operations will feel like once you get used to this keyboard.
Moving the text cursor has a very similar feel to moving the mouse. The faster you perform the gesture (which is two fingers sliding on the left side -- the mirror of the mouse gesture), the faster the cursor moves. The further you move your fingers, the further the cursor goes.
Try the same with moving by words, selecting text, searching, undo/redo, cycling through your emacs yank buffer, etc.
The time savings of these gestures (rather than cut/paste and file open/close gestures that have been mentioned so far) is what makes up for the loss in typing speed.
And let me also second how great FingerWorks support has been. They have been sensitive to my problems and very speedy in resolving them.
They were also very receptive for suggestions in improving their gesture sets. I provided some feedback for their Emacs mode, we passed some ideas back and forth, and they implemented just about all of them! I guess now you know who to blame, if you don't like their emacs mode, or find any bugs with the support macros.:-)
Anyway, these keyboards are fun and very rewarding, if you can commit the time and effort to learn to type on them.
Slashdot Mirror
Correction...
The polling station does not keep any part of your receipt -- they DESTROY half your receipt.
Why? For the exact reason you bring up -- so noone can tell who you voted for. Your votes are encrypted on each layer of the receipt, and they are also visible when the two layers are overlayed on top of each other. The receipt you keep is also recorded as your vote. Once the other half is destroyed, your ballot can only be decrypted during the tally process.
The beauty of the system is that your receipt can be used to verify the entire voting process from beginning to the end, from the voting machine to the final tally. To verify the voting machine and the registration of your vote, anyone can visually compare your receipt with your recorded vote -- if the images match then it hasn't been tempered with. The tally process can be similarly verified by anyone, except that no specific ballots can be traced from beginning to the end. A randomly chosen 50% of the ballots are checked at each step of the decryption and shuffling process, enough to make it impossible to cheat, but not enough that ballots could be traced all the way through.
If they believe TIVO and Zaurus infringes, they must believe every installation of linux does...
I mean, how does embedded linux running on low performace, single cpu, non-intel hardware have anything to do with their IP claims?
Are they saying that these devices perform like SCO UnixWare on high end server hardware thanks to their IP?
Probably they're under the impression that Linux is a Unix derivative thanks to their IP, and therefore they own all rights to it. Regardless of the features that are actually used in any particular installation.
I agree with you on some points, but I think you lack some imagination. (for better or worse :) )
... Or you could still write your setuid utiltiy replacements.
For exampe, the access control system itself is not discussed in the article beyond the suggestion that the access control information itself (attributes, permissions, acl, etc.) could be treated like arbitrary metadata. Obviously, this doesn't mean that access control would be voluntary, or enforced by applications such as "cp"!! Some access control mechanism has to be present, and that system would have to excercise access control over its own metadata files too.
Imagine that the access control system would only allow the superuser to modify access control related metadata files. You'd have a host of setuid utilities, running as root, to manipulate the metadata and enforce access control. For custom access control, you'd write your own setuid utiltiy replacements.
Or imagine a unix-compatible access control system that took on more responsibliy. The old setuid utilties could be replaced by simpler ones that manipulated the metadata, and did nothing else. For custom access control, you'd still write setuid utiltiy replacements.
Or imagine an access control system that was very flexible and configurable. For custom access control, perhaps you would get away with a one-liner in a system config file.
Or imagine that the access control system might become totally pluggable, and you could choose whether you wanted windows semantics, unix semantics, or your own access control logic with your own arbitrary meta data.
Having access control information stored as arbitrary metadata in the namespace simply does not imply that you would loose access control, nor that setuid and setgid programs would *have* to go away. It simply opens other possibilities under the assumption that more and more of the access control logic would be moved into some central system. I guess it is arguable whether this is good or bad. The system still has to evolve and mature, and some of the solutions you call short sighed have yet to be considered seriously. Take what they have for inspiration, not as a blue print. It just isn't there yet. Reshape it using your own experience; try to find plausible solutions to the problems you see. Its refreshing to think outside the box, once in a while.
Commercials are typically played with higher volume than the program they're interrupting...
Is this a valid assumption? Most of my change comes from small purchases, and the vast majority of small cost items have similar prices (i.e. 0.99, 1.29, 1.50, 4.95, etc). The amount of change from each of many small purchases will tend to fall into a few discreet values, and would not follow a uniform random distribution.
Room temperature supercondition would open up so many possibilities -- it may start a new era for technology. If diamonds are the key, would future generations call it the diamond age?
No connection to Neal Stephenson's book called the Diamond age, as that refered to something quite different...
One of the reasons consumers are supposed to care about Palladium is the protection it can offer against running untrusted code such as viruses. Seems that a good number of the effective viruses are not standalone executables, but Outlook scripts, Word macros and the like.
Is Palladium supposed to offer any protection against these? (If not, then skip the rest of the arguments...)
How would Palladium help? Presumably MicroSoft applications would be "trusted", yet these applications are the executables that are doing the damage (while executing the macros or scripts).
Are scripts and macros going to be considered distinct executables, that must be independently certified and signed? What about very common scripts like javascript for HTML Image rollovers, layers, form validations, etc.?
If not every script has to be signed, then how does Palladium make a practical distinction between what does need to be signed and what doesn't?
If every scrip has to be signed, then how would a new Palladium enabled system keep compatibility with the existing web, existing microsoft documents, and microsoft's application design philosophy?
One thing no-one mentioned on slashdot yet is how nice repetitive gestures are on this keyboard. Did you ever think about how (in)convenient moving the mouse pointer would be using keypresses? click-click-click; you'd only want to do it if you were truly desperate, it is so cumbersome. That is what many text other keyboard operations will feel like once you get used to this keyboard. Moving the text cursor has a very similar feel to moving the mouse. The faster you perform the gesture (which is two fingers sliding on the left side -- the mirror of the mouse gesture), the faster the cursor moves. The further you move your fingers, the further the cursor goes. Try the same with moving by words, selecting text, searching, undo/redo, cycling through your emacs yank buffer, etc. The time savings of these gestures (rather than cut/paste and file open/close gestures that have been mentioned so far) is what makes up for the loss in typing speed. And let me also second how great FingerWorks support has been. They have been sensitive to my problems and very speedy in resolving them. They were also very receptive for suggestions in improving their gesture sets. I provided some feedback for their Emacs mode, we passed some ideas back and forth, and they implemented just about all of them! I guess now you know who to blame, if you don't like their emacs mode, or find any bugs with the support macros. :-)
Anyway, these keyboards are fun and very rewarding, if you can commit the time and effort to learn to type on them.