The problems are because the software on these voting machine is cobbled together in a "make do" fashion (I mean, using MS ACCESS for a storage medium in a critical, widespread system?) to produce minimum functionality, with no security and no oversight, along with little-to-no hardware security. Paper ballots are easy to lose, difficult to handle in large number, and incredibly time-consuming to count.
And the debacle that was the 2000 election of GWB really showed the very best of Paper voting. And it's much easier to "lose" a boxful of voting slips.
A public monolithic and government-controlled repository for the code, so everyone can see it.
Patches to the tree accepted only after review by government-appointed programmer/team. So, rather like Firefox, for example, or the Linux kernel.
Voting machines then use the government-approved code only.
Voting machines are sealed boxes, with all external ports secured with lock and key.
Machines are connected to the central tallying machine at each location by hard-wired ethernet (behind said lock-and-key port).
A single "monitoring station" is with the adjudicator, which shows votes being cast successfully (but anonymously, so it shows "a vote has been placed in this booth", but not what that vote was), to ensure that people's votes are accepted successfully, that only one vote per person is accepted, and no votes are cast when there is nobody in the booth.
Every voter gets a printed record of their vote, each machine keeps a printed receipt for itself, as well as a digital copy of all the votes it has received, as well as submitting those votes to the central tallying machine in real-time, which also keeps a paper record, along with passing it's results to the central system in real-time over a secured link (SSL or something similar).
Each update is sent with a cryptographic signature, which is accepted if the signature matches correctly (and re-requested if they do not). The response is a count of all the votes received through that link thus far - If the amounts differ, there's fraud somewhere, and the system creates an alert.
Vote counts are displayed in real-time on a/several government-run public website(s) with feeds publicly available for news networks and the like.
Given that, in the parent's location, a "Pound" refers to the symbol £ (Pounds sterling), the symbol # is referred to as a "Hash" or "Hash mark" (possibly derived from the word "Hatch", as in "Crosshatch" or "hatchmark").
Blinkenlights did it first, and at higher resolution, and once they'd finished doing it in black and white, they went to Paris and did it again, in colour. Both systems had Tetris that was playable by phone, and would also display messages sent via SMS to the display. Oh, and both those projects were also open-source. The only interesting part of this is the wireless connectivity in the MIT system.
Yes, they could. But adding in those extra hops would delay packets sent through, making connections via the malicious route slower and thus less preferable. If the router in question is your only option then you're screwed, but if you're multi-homed, this will give you some way of verifying that differing available routes lead to the same range. If it's a malicious spoofing then you won't be able to get a response from the real site from the malicious router.
Okay, so you run dumbfucktown.net, and you have connections through comcast and vzw.
vzw starts advertising that they can get to thisnet.com faster with an announcement.
Your router:
Sends a traceroute to thisnet.com through vzw
Sends a traceroute to thisnet.com through comcast
Compares the two results, to see which completes, and which is faster.
Pings thisnet.com through vzw, with a comcast return route
Pings thisnet.com through comcast, with a vzw return route
If any of these fail, the new route is rejected completely. If they succeed, the route is classified and entered into the preference list based on it's performance.
If a route starts failing/returning errors, the requests are retried on the next available route in the list, continuing down the list until it is exhausted.
All dumbfucktown.net cares about is if the packets get there, and how fast. It doesn't care who owns the route, how new or old it is, or anything else.
This isn't foolproof, but it would work, I believe.
Wouldn't an easier way be to attempt a trace to the advertised destination through the router that advertised it? Then if Router A says "You can get to 192.x through me!", and probes sent to the 192.x range through that router fail, it's obvious that Router A is sending false/misleading advertisements. Then it doesn't matter at all who owns the group, just that packets go through correctly. It will also let the network self-manage optimal routes, as it can measure the return speed for the (newly discovered) route, and compare it with it's existing route - If the newer route is faster, it becomes the preferred route, if not it gets filed in a list in order of speed, with fastest first. When the current route fails, the router can go back through it's list to get the "next fastest route" and try that instead. To verify that it really is the correct route, and that it leads to the same servers, the router gets it's packets to return though it's existing route, thus verifying that the packet travelled to the same machines on the same range, even if they did go through the new route.
I know this, and I agree entirely. But, as mentioned, there are some situations where two totally different developers, who have never met or communicated in any way, were to write a function according to a specification, they will end up writing similar (if not virtually identical) functions.
The problem with your statement is that they are implementing an SDK, so the code they produce has to have the same behaviour as the original. For instance, making a sandwich - without having the original recipe and reverse-engineering it, it'll end up being (virtually) identical, as you're trying to produce the same output. And even if this wasn't the case, there are some functions that need to be the same - if they're not, breakage happens.
Why is this such big news? Did you know you can replace the entire firmware inside your TV too? There's already a group working on getting something usable onto Samsung TVs like these: http://www.samygo.tv/
Not yet, but as the TVs run Linux underneath (and have published their sourcecode, as they required to by the GPL) they're working on it: http://www.samygo.tv/
One of my two is in my parent's loft. Working Commodore +4, and Commodore 64. And a 1541 and MPS-801 to go with them. There's also a boxed up (tower-modded) Amiga 1200 with '040 expansion card there too. Unfortunately that loft is in the UK and I'm in Canada.
It's just trying to be too damned much at the moment. Here's how I see what's needed:
An iPod Service to hold the various "libraries"
A Music library manager and player (Think Foobar 2000, for instance)
A Video library manager and player
A downloader (for putting things from the web-based stores into the libraries)
3 web-based stores (Music, Video, Apps).
The USB connection provides an internet connection to the iDevice, so if the iDevice is connected to your computer, it's connected to the 'net. Thus if your iDevice has an unlimited internet connection (WiFi or USB Tethered), it downloads apps directly on the device like the "Google Play" store. If the iDevice isn't connected to the net (or is on a metered connection, 3G/4G etc.) then the web-based store (Which can't connect to the iDevice in question) downloads a "token" (like a.torrent file or a magnet link) on the desktop, which is handled by the "Downloader" app, which (quietly, in the background) downloads the content and hands it to the service running in the background, ready to squirt the app to the iDevice over the USB tether as soon as it's connected.
Music and video are downloaded in the same way, but are downloaded by the "Downloader" app even if the iDevice is connected, to keep the libraries in sync, and allow playback of the purchased content on the desktop as well as the iDevice.
The service remains running to enable tethered devices like the AppleTV/iTV/whatever to continue working, even when the frontend applications are closed. When a disconnected iDevice (iPod Touch without WiFi connection, for instance) is connected, it's library is bi-directionally synced with the version held by the service, keeping the two copies in sync at all times. So, for instance, music you have grabbed from your friends' band while at his house is added to your desktop's library, rather than being wiped out, and music that was synced to your iDevice that you didn't like (The Bonzo Dog Doo-Dah Band? WTF?) and removed from your iDevice, is removed from the "remote" library (but kept on the desktop, 'cause you never know when "I'm the urban spaceman" will be appropriate again).
It was much more successful than it's competitor: http://en.wikipedia.org/wiki/LS120 - The very fact that you've heard of it makes it MUCH more successful than that boondoggle ever was.
If you read more carefully, it seems that this is just their way of protecting these high-capacity blu-ray discs. Much in the same way we used to do with CDs: http://en.wikipedia.org/wiki/Caddy_(hardware)
Essentially, it's a caddy for high-capacity bd-rom discs.
I... I didn't know that. I guess you DO learn something every day. Thanks for teaching me something new. Someone with mod points, please mod parent +5 insightful.
When we finally get settled into a place of our own, up here in the windy prairie of Saskatchewan, we're intending to get an acreage or more just outside the city and put wind and solar on it. A pair of 14KW turbines and a 10KW solar array would be easily attainable, and overkill, but would ensure that on even the most dreary and becalmed day we still have power (When it's not windy, it's sunny here, though we'll probably also invest in a diesel/WVO generator, just in case those long cold winter nights leave us with a little shortfall). This would also mean we don't need natural gas for heat/cooling (Geothermal and electric under-floor heating, electric "instant heat" water). Then our municipal requirements drop to phone/internet. And the "NIMBY" price reduction for having a turbine or two on our land will be more than paid for by the self-sufficient nature, without having to sacrifice any modern luxuries. We'd even have enough excess power to put power back onto the grid for a profit (Well, we would if SaskPower had that option), and/or to run an EV.
Because oil is currently MASSIVELY subsidised. The tax breaks and benefits the oil industry get are huge, and if a tiny proportion of those subsidies were also available to so-called "Green" energy solutions then solar and wind power would be free, paid for entirely by the subsidy.
The only reason there would be a compatibility problem is if programs/scripts/modules/whatever are using user-agent identification to determine what features are available. This is (and always has been) a very bad practice - You check to see if the functions (or alternatives) are available, rather than checking against UA. That way you don't have to continually update scripts to maintain compatibility with the latest versions. When when browsers start supporting new functions coded in, those functions just work. When deprecated functionality is removed, the check for that particular function fails and the code moves on to another branch.
For example, rather than the following:
function getXMLHTTP() {
if (navigator.appName == 'Microsoft Internet Explorer')
{
var ua = navigator.userAgent;
var re = new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})");
if (re.exec(ua) != null)
rv = parseFloat( RegExp.$1 );
if (rv
try { return new ActiveXObject("Msxml2.XMLHTTP.6.0"); }
catch (e) {}
try { return new ActiveXObject("Msxml2.XMLHTTP.3.0"); }
catch (e) {}
try { return new ActiveXObject("Microsoft.XMLHTTP"); }
catch (e) {}
} else
return XMLHTTPRequest;
} else
return XMLHTTPRequest;
}
Which uses nasty browser detection to try and cope with IE 8 and below, you should use:
function getXMLHTTP() {
if (XMLHTTPRequest) return XMLHTTPRequest;
if (ActiveXObject) {
try { return new ActiveXObject("Msxml2.XMLHTTP.6.0"); }
catch (e) {}
try { return new ActiveXObject("Msxml2.XMLHTTP.3.0"); }
catch (e) {}
try { return new ActiveXObject("Microsoft.XMLHTTP"); }
catch (e) {}
}
throw new Error("This browser does not support XMLHttpRequest.");
}
Which nicely checks to see both if the newer/proper XMLHTTPRequest Javascript object exists, and if not, tries to use the latest ActiveX object (Necessary for IE 8 and below), while only using the "ActiveXObject" function if it is available. It also means that if MS put out a version of IE that falls back to the ActiveX Object route, this code will still work with it, whereas the first will not. It's a minor example, true, but it's an example nonetheless.
Of course. Given that 1GiB of data (When held in RAM) weighs approximately 391 femtograms (given an 50% distribution of 1s and 0s), an average African Elephant would weigh the same as be ~ 8,177.6 Yobibytes.
Don't fall into the trap of switching to SSDs to try and escape the velocidensity issues, either. What with electron drift, bit rot, transistor breakdown and silicon-isolator tunneling issues, you can get up to 12kbps loss, depending on NAND structure and refresh frequency of your SSD. And heaven forbid you place your SSD in anything but an isolated Faraday cage - solar ejection events can cause havoc with silicon-based storage systems!
Slashdot Mirror
The problems are because the software on these voting machine is cobbled together in a "make do" fashion (I mean, using MS ACCESS for a storage medium in a critical, widespread system?) to produce minimum functionality, with no security and no oversight, along with little-to-no hardware security. Paper ballots are easy to lose, difficult to handle in large number, and incredibly time-consuming to count.
And the debacle that was the 2000 election of GWB really showed the very best of Paper voting. And it's much easier to "lose" a boxful of voting slips.
Here's how you do it.
Of course, it'll never happen, but one can dream.
I believe you're thinking of IdrA
Given that, in the parent's location, a "Pound" refers to the symbol £ (Pounds sterling), the symbol # is referred to as a "Hash" or "Hash mark" (possibly derived from the word "Hatch", as in "Crosshatch" or "hatchmark").
Blinkenlights did it first, and at higher resolution, and once they'd finished doing it in black and white, they went to Paris and did it again, in colour. Both systems had Tetris that was playable by phone, and would also display messages sent via SMS to the display. Oh, and both those projects were also open-source. The only interesting part of this is the wireless connectivity in the MIT system.
Yes, they could. But adding in those extra hops would delay packets sent through, making connections via the malicious route slower and thus less preferable. If the router in question is your only option then you're screwed, but if you're multi-homed, this will give you some way of verifying that differing available routes lead to the same range. If it's a malicious spoofing then you won't be able to get a response from the real site from the malicious router.
Okay, so you run dumbfucktown.net, and you have connections through comcast and vzw.
vzw starts advertising that they can get to thisnet.com faster with an announcement.
Your router:
If any of these fail, the new route is rejected completely. If they succeed, the route is classified and entered into the preference list based on it's performance.
If a route starts failing/returning errors, the requests are retried on the next available route in the list, continuing down the list until it is exhausted.
All dumbfucktown.net cares about is if the packets get there, and how fast. It doesn't care who owns the route, how new or old it is, or anything else.
This isn't foolproof, but it would work, I believe.
Disclaimer: IANANE
Wouldn't an easier way be to attempt a trace to the advertised destination through the router that advertised it? Then if Router A says "You can get to 192.x through me!", and probes sent to the 192.x range through that router fail, it's obvious that Router A is sending false/misleading advertisements. Then it doesn't matter at all who owns the group, just that packets go through correctly. It will also let the network self-manage optimal routes, as it can measure the return speed for the (newly discovered) route, and compare it with it's existing route - If the newer route is faster, it becomes the preferred route, if not it gets filed in a list in order of speed, with fastest first. When the current route fails, the router can go back through it's list to get the "next fastest route" and try that instead. To verify that it really is the correct route, and that it leads to the same servers, the router gets it's packets to return though it's existing route, thus verifying that the packet travelled to the same machines on the same range, even if they did go through the new route.
I know this, and I agree entirely. But, as mentioned, there are some situations where two totally different developers, who have never met or communicated in any way, were to write a function according to a specification, they will end up writing similar (if not virtually identical) functions.
The problem with your statement is that they are implementing an SDK, so the code they produce has to have the same behaviour as the original. For instance, making a sandwich - without having the original recipe and reverse-engineering it, it'll end up being (virtually) identical, as you're trying to produce the same output. And even if this wasn't the case, there are some functions that need to be the same - if they're not, breakage happens.
Why is this such big news? Did you know you can replace the entire firmware inside your TV too? There's already a group working on getting something usable onto Samsung TVs like these: http://www.samygo.tv/
Not really, considering the TVs run Linux: http://www.samygo.tv/
Not yet, but as the TVs run Linux underneath (and have published their sourcecode, as they required to by the GPL) they're working on it: http://www.samygo.tv/
One of my two is in my parent's loft. Working Commodore +4, and Commodore 64. And a 1541 and MPS-801 to go with them. There's also a boxed up (tower-modded) Amiga 1200 with '040 expansion card there too. Unfortunately that loft is in the UK and I'm in Canada.
It's just trying to be too damned much at the moment. Here's how I see what's needed:
The USB connection provides an internet connection to the iDevice, so if the iDevice is connected to your computer, it's connected to the 'net. Thus if your iDevice has an unlimited internet connection (WiFi or USB Tethered), it downloads apps directly on the device like the "Google Play" store. If the iDevice isn't connected to the net (or is on a metered connection, 3G/4G etc.) then the web-based store (Which can't connect to the iDevice in question) downloads a "token" (like a .torrent file or a magnet link) on the desktop, which is handled by the "Downloader" app, which (quietly, in the background) downloads the content and hands it to the service running in the background, ready to squirt the app to the iDevice over the USB tether as soon as it's connected.
Music and video are downloaded in the same way, but are downloaded by the "Downloader" app even if the iDevice is connected, to keep the libraries in sync, and allow playback of the purchased content on the desktop as well as the iDevice.
The service remains running to enable tethered devices like the AppleTV/iTV/whatever to continue working, even when the frontend applications are closed. When a disconnected iDevice (iPod Touch without WiFi connection, for instance) is connected, it's library is bi-directionally synced with the version held by the service, keeping the two copies in sync at all times. So, for instance, music you have grabbed from your friends' band while at his house is added to your desktop's library, rather than being wiped out, and music that was synced to your iDevice that you didn't like (The Bonzo Dog Doo-Dah Band? WTF?) and removed from your iDevice, is removed from the "remote" library (but kept on the desktop, 'cause you never know when "I'm the urban spaceman" will be appropriate again).
That's how I would do it, anyway.
It was much more successful than it's competitor: http://en.wikipedia.org/wiki/LS120 - The very fact that you've heard of it makes it MUCH more successful than that boondoggle ever was.
If you read more carefully, it seems that this is just their way of protecting these high-capacity blu-ray discs. Much in the same way we used to do with CDs: http://en.wikipedia.org/wiki/Caddy_(hardware) Essentially, it's a caddy for high-capacity bd-rom discs.
I... I didn't know that. I guess you DO learn something every day. Thanks for teaching me something new. Someone with mod points, please mod parent +5 insightful.
Provincial tree? I wasn't aware there was such a thing, or if there was, it was the "Lesser Spotted Radio Mast" (Genus: Steelanwire Blinkenlights)
When we finally get settled into a place of our own, up here in the windy prairie of Saskatchewan, we're intending to get an acreage or more just outside the city and put wind and solar on it. A pair of 14KW turbines and a 10KW solar array would be easily attainable, and overkill, but would ensure that on even the most dreary and becalmed day we still have power (When it's not windy, it's sunny here, though we'll probably also invest in a diesel/WVO generator, just in case those long cold winter nights leave us with a little shortfall). This would also mean we don't need natural gas for heat/cooling (Geothermal and electric under-floor heating, electric "instant heat" water). Then our municipal requirements drop to phone/internet. And the "NIMBY" price reduction for having a turbine or two on our land will be more than paid for by the self-sufficient nature, without having to sacrifice any modern luxuries. We'd even have enough excess power to put power back onto the grid for a profit (Well, we would if SaskPower had that option), and/or to run an EV.
Because oil is currently MASSIVELY subsidised. The tax breaks and benefits the oil industry get are huge, and if a tiny proportion of those subsidies were also available to so-called "Green" energy solutions then solar and wind power would be free, paid for entirely by the subsidy.
The only reason there would be a compatibility problem is if programs/scripts/modules/whatever are using user-agent identification to determine what features are available. This is (and always has been) a very bad practice - You check to see if the functions (or alternatives) are available, rather than checking against UA. That way you don't have to continually update scripts to maintain compatibility with the latest versions. When when browsers start supporting new functions coded in, those functions just work. When deprecated functionality is removed, the check for that particular function fails and the code moves on to another branch.
For example, rather than the following:
function getXMLHTTP() {
if (navigator.appName == 'Microsoft Internet Explorer')
{
var ua = navigator.userAgent;
var re = new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})");
if (re.exec(ua) != null)
rv = parseFloat( RegExp.$1 );
if (rv try { return new ActiveXObject("Msxml2.XMLHTTP.6.0"); }
catch (e) {}
try { return new ActiveXObject("Msxml2.XMLHTTP.3.0"); }
catch (e) {}
try { return new ActiveXObject("Microsoft.XMLHTTP"); }
catch (e) {}
} else
return XMLHTTPRequest;
} else
return XMLHTTPRequest;
}
Which uses nasty browser detection to try and cope with IE 8 and below, you should use:
function getXMLHTTP() {
if (XMLHTTPRequest) return XMLHTTPRequest;
if (ActiveXObject) {
try { return new ActiveXObject("Msxml2.XMLHTTP.6.0"); }
catch (e) {}
try { return new ActiveXObject("Msxml2.XMLHTTP.3.0"); }
catch (e) {}
try { return new ActiveXObject("Microsoft.XMLHTTP"); }
catch (e) {}
}
throw new Error("This browser does not support XMLHttpRequest.");
}
Which nicely checks to see both if the newer/proper XMLHTTPRequest Javascript object exists, and if not, tries to use the latest ActiveX object (Necessary for IE 8 and below), while only using the "ActiveXObject" function if it is available. It also means that if MS put out a version of IE that falls back to the ActiveX Object route, this code will still work with it, whereas the first will not. It's a minor example, true, but it's an example nonetheless.
Of course. Given that 1GiB of data (When held in RAM) weighs approximately 391 femtograms (given an 50% distribution of 1s and 0s), an average African Elephant would weigh the same as be ~ 8,177.6 Yobibytes.
Do please check my math, if you so desire. - Electron mass being 9.10938215 × 10^-31kg, 10^5 electrons in a bit, And an average African Elephant weighing 3.6 tonnes.
Don't fall into the trap of switching to SSDs to try and escape the velocidensity issues, either. What with electron drift, bit rot, transistor breakdown and silicon-isolator tunneling issues, you can get up to 12kbps loss, depending on NAND structure and refresh frequency of your SSD. And heaven forbid you place your SSD in anything but an isolated Faraday cage - solar ejection events can cause havoc with silicon-based storage systems!