One more thing: first, consider NASA's budget which is 0.6% of the federal budget. Now consider the Department of Defense's budget, which is 19%. (Both of these numbers are straight from Wikipedia for 2010.) I can't justify spending 32 times as much on wars that will only serve to kill people and create a worldwide hatred of America as we spend on our space program. It doesn't make any sense to me.
To equate all DOD spending with only war, killing, and hatred of America is ludicrous. Yes, the US military is actively engaged in hostile actions. However it is usually among the first to respond when humanitarian relief is required- such as recent efforts in "Japan." Furthermore military technology finds it's way to civilian "non-lethal uses."Also, kind of funny slamming DOD budget as all war and killing while posting to a site that is accessible thanks in large part to DARPA funded core technology. Granted probably a tiny piece of that defense war and killing budget, but part of it nonetheless. Arguably some of the same tech could have made it's way to civilian use without DOD, but to deny that DOD funding accelerated those moves is naive beyond belief.
Back on topic -- the recent experiences with Messenger as pointed out in the article only reinforce the need to understand, detect and frankly plan for a major terrestrial disruption due to CME or other type bursts. I'm confident we'll experience a major outage in my lifetime, and as electronics become more and more interconnected the disruptions caused by that outage will have a larger and unpredictable impact on ordinary folks. Time to get our heads out of the sand.
Unfortunately the first line of your initial response with the unnecessary barb against armchair quarterbacking
the largest computer company in the world, and the second largest US based corporation
undermined the rest or your points. Face it, market cap is a rather arbitrary measure - certainly other US companies are larger in terms of revenue (IBM, HP, Dell, MSFT), number of employees, and overall contributions and achievements in the tech world. Sure Apple is sitting high now, but it wasn't that long ago that Cisco had a market cap of $500billion and where are they now?
Market cap to my mind has little bearing on whether killing XServe is or is not a brain dead move. The tech sector is littered with companies who flew high, could do no wrong, and then collapsed. That said I did agree with most of the rest of your points and even the final point on how Apple is now branding and targeting their servers (or rather "server enough") offerings. Yet I'm left wondering from an earlier post on the wisdom of Apple abandoning the enterprise sector or even niches...
Content providers for apple MUST provide video files in Apple ProRes fileformat which is ONLY able to be encoded using apple's tools which only run in OSX. I don't know how apple expects large content producers to encode high-volumes of videos for them without the xserves. MacPros are not an option as they are not enterprise ready (single PSU, no management port, they're HUGE and must be de-"racked" in order to swap drives, etc). MacMinis are not suitable for this as they don't have enough CPU/RAM. The xserves weren't even that great, but they were the right form factor.
With no real enterprise offerings what's the migration path for that space, or is there even one? Leaving even a niche market hanging can be the type of move that spreads discontent amongst the user base. Not saying that this will necessarily happen or that if it does it means Apple falls from the top of the market cap food chain. Still we could be easily sitting here in 5 years and agree that it was the tipping point in Apple's demise - or conversely that it was the brilliant move that freed them to focus on other areas and grow exponentially larger.
Not sure either... wasn't trying to be snarky in my reply. I was confused, because I originally read the information week article about offline editing being dropped. Read your reply and went digging for more info -- not to "prove anything" but to see why the conflict with the Information Week article. Found the later post and supplied it...thought that's how things worked here.:-)
Thanks for backing me up.
I think you're understimating the ecology of the Gulf region. We're not talking A-bombs underground in the desert. The biodiversity in the gulf waters and surrounding marshlands should be a serious concern. While the oil leak very definitely threatens the food chain in that and surrounding areas, using nukes to plug the leak seems like something that should be approached with at leasat some skepticism. A 20% chance of failure + chance of radiation impacting some portion of the undersea area is nothing to get dismissive over. I don't mean to be alarmist and I am open to hearing more. Maybe the 20% failure rate + N% chance of radiation impact in an area of X square miles is the better option of Z days of oil continuing to spill at a rate of Y gallons/day. I don't know.
As I originally said I'm torn between admiration and shock over this approach....though admittedly less shocked the more reading I do.
By the way, where are you getting your info on the 1972 blast? I keep getting blogs citing the kp.ru article.
So a 20% chance of mysterious mushroom clouds in the Gulf don't give you pause for concern? Guess glow in the dark crawfish could be a boon to the local economy.
Translated from http://www.kp.ru/daily/24482/640124/
by Google
And only once failed. In 1972 in Kharkov region failed to block the emergency gas blowout. The explosion was mysteriously left on the surface, forming a mushroom cloud. Although the charge was minimal - just a 4 kiloton. And laid deep - for more than two kilometers.
What?!
Seriously, I'm not sure which is stronger...
1) My admiration for the pure guts of such an approach (talk about outside the box thinking)
2) My shock that a 20% failure rate using nukes to treat petrocalamities is seen as acceptable.
From the parent article...
Happily, with a track record like that, “the chances of failure in the Gulf of Mexico are 20%,” KP writes. “The Americans could certainly risk it.”
Please note, these new editors are not compatible with Gears (the technology that powers offline access), so they do not have offline support today. However, we plan to bring back offline support in the future, taking advantage of new technologies like HTML5 and advancements in modern browsers.
So you're telling me that you know for sure I won't be able to bring up Google Docs and access my Google docs when I have no internet connection? Because right now I can do that in the Chrome Browser with Google Gears and they are working on HTML5 which is supposed to natively support this "offline" functionality. But what you're telling me is that they plan on dropping this paradigm?
Google's other big bet is on the all-cloud environment; it's dropping for now the ability to use Docs when not connected to the Internet. Google thinks most employees don't care about offline mode, but the company knows that C-level execs--the ones who need to approve Google apps--do. They're often on airplanes without Internet connectivity, so not having offline access could be a big strike against the rewritten Docs.
Maybe your intent was to prevent loopholes for the vote tallying/tracking code being classified with the OS as non-disclosed, but you certainly didn't need to require disclosure of ALL software running on the voting machines.
For a voting machine, yes, we most certainly do need disclosure of all software.
Thanks for responding, but I respectfully disagree. Use of a known OS on a closed system such as a voting kiosk is no more or less risky whether or not you have disclosure of all the source code.
As for the sections you quoted that presumably limit the scope to the OS level, why? That seems like a gapping loophole. Why couldn't someone just write an overly simplistic OS and app and hide a bunch of vote tampering code in the BIOS? On the surface, what's turned over looks legit and clean, but behind the scenes is the undisclosed "election correction" code you're so bent on preventing.
Furthermore, what about manual counting and recounting methods? Are these held to the same level of disclosure? By this, I mean what if the hand tallies are recorded or communicated electronically....you want to have the source for all systems used to record, transmit or communicate those results also available for disclosure? If not, then why not? Aren't these another avenue for tampering?
Call me cynical, but if someone really wants to muck with the system they'll find a way....voting machines or no voting machines, there are ample opportunities for vote tampering before, during and after an election. Don't kid yourselves into thinking you've really reduced the odds of vote tampering by requiring source code disclosure for the systems used to record votes.
In my mind the best bet to increase odds for a fair election is an educated and well informed citizenry. Good luck finding that in the US anymore.:-/
No offense, but if this was really the intent of the statute, this provision seems rather absurd. Seems that a "simple" home brewed OS (even fully disclosed) could present more of an opportunity for some clever tricks or whatnot for vote tampering. From that standpoint an open or widely used OS (*nix or Win*) seem at least as safe.
Maybe your intent was to prevent loopholes for the vote tallying/tracking code being classified with the OS as non-disclosed, but you certainly didn't need to require disclosure of ALL software running on the voting machines.
BTW are you really requiring the source to all software running on the voting machines? So you get application code and OS code. What about all the source and authors for embedded code on the machines such as the BIOS used at bootup? How about the drivers and APIs for all display and input devices? Even if you did, do you really have the resources to review it for potential hidden problems? I doubt it.
Seems you efforts would have been better spent crafting more specific requirements for the application source code, and leaving room for vendors to leverage existing OS, BIOS, device drivers, etc. without worrying over whether it was possible to disclose all source and authors. Maybe an embedded OS would best fit the bill. Maybe not. Did you consider that maybe your overarching requirements prevented a local startup from bidding on a viable solution...with Red Hat based in NC, seems some local company might have been itching to build a voting machine leveraging RHEL or Fedora that met your TRUE needs. Who knows their solution might have toppled traditional vendors such as Diebold, even leading to creation of new jobs in your state.
Also, what lawsuit did you work with the GA on? The articles referenced by the parent implied that no one has been accused of breaking the law yet.
Not sure the 500,000 number is releavant if you change the rules. Had the system been based on popular votes, the actual turnout in FL and elsewhere might have been dramatically different. Changing the rules in how votes are counted is a variable that could impact the motivation of a voter to actually cast his/her vote.
Given a choice between pure pluarality and the current electoral college system, I tend to lean toward the EC. My preference would be to see more states adopt practices such as Maine where electoral votes are assigned to Congressional districts. This might help with the "all or nothing" approach the probably alienates voters. Of course there are studies that said this type of approach would not have changed the 2000 outcome
http://www.usatoday.com/news/vote2000/bush25.htm#r eadmore
Which returns to my original point that by changing the rules you alter a key variable in the original equation...so that study is nothing more than an interesting intellectual exercise.
If I know my state may lean Republican, but I live in a decidely Democratic (or Liberterian?) district, then I personally would be less likely to stay home and concede my vote in a system where electoral votes were assigned per district.
Slashdot Mirror
It is workable now and has been for a few years... See the walking timberjack harvester - http://gizmodo.com/036148/plustech-walking-machine Of course they needed 6 legs, not 4.
One more thing: first, consider NASA's budget which is 0.6% of the federal budget. Now consider the Department of Defense's budget, which is 19%. (Both of these numbers are straight from Wikipedia for 2010.) I can't justify spending 32 times as much on wars that will only serve to kill people and create a worldwide hatred of America as we spend on our space program. It doesn't make any sense to me.
To equate all DOD spending with only war, killing, and hatred of America is ludicrous. Yes, the US military is actively engaged in hostile actions. However it is usually among the first to respond when humanitarian relief is required- such as recent efforts in "Japan." Furthermore military technology finds it's way to civilian "non-lethal uses."Also, kind of funny slamming DOD budget as all war and killing while posting to a site that is accessible thanks in large part to DARPA funded core technology. Granted probably a tiny piece of that defense war and killing budget, but part of it nonetheless. Arguably some of the same tech could have made it's way to civilian use without DOD, but to deny that DOD funding accelerated those moves is naive beyond belief.
Back on topic -- the recent experiences with Messenger as pointed out in the article only reinforce the need to understand, detect and frankly plan for a major terrestrial disruption due to CME or other type bursts. I'm confident we'll experience a major outage in my lifetime, and as electronics become more and more interconnected the disruptions caused by that outage will have a larger and unpredictable impact on ordinary folks. Time to get our heads out of the sand.
the largest computer company in the world, and the second largest US based corporation
undermined the rest or your points. Face it, market cap is a rather arbitrary measure - certainly other US companies are larger in terms of revenue (IBM, HP, Dell, MSFT), number of employees, and overall contributions and achievements in the tech world. Sure Apple is sitting high now, but it wasn't that long ago that Cisco had a market cap of $500billion and where are they now? Market cap to my mind has little bearing on whether killing XServe is or is not a brain dead move. The tech sector is littered with companies who flew high, could do no wrong, and then collapsed. That said I did agree with most of the rest of your points and even the final point on how Apple is now branding and targeting their servers (or rather "server enough") offerings. Yet I'm left wondering from an earlier post on the wisdom of Apple abandoning the enterprise sector or even niches...
Content providers for apple MUST provide video files in Apple ProRes fileformat which is ONLY able to be encoded using apple's tools which only run in OSX. I don't know how apple expects large content producers to encode high-volumes of videos for them without the xserves. MacPros are not an option as they are not enterprise ready (single PSU, no management port, they're HUGE and must be de-"racked" in order to swap drives, etc). MacMinis are not suitable for this as they don't have enough CPU/RAM. The xserves weren't even that great, but they were the right form factor.
With no real enterprise offerings what's the migration path for that space, or is there even one? Leaving even a niche market hanging can be the type of move that spreads discontent amongst the user base. Not saying that this will necessarily happen or that if it does it means Apple falls from the top of the market cap food chain. Still we could be easily sitting here in 5 years and agree that it was the tipping point in Apple's demise - or conversely that it was the brilliant move that freed them to focus on other areas and grow exponentially larger.
Settle's back in to armchair
Not sure either... wasn't trying to be snarky in my reply. I was confused, because I originally read the information week article about offline editing being dropped. Read your reply and went digging for more info -- not to "prove anything" but to see why the conflict with the Information Week article. Found the later post and supplied it...thought that's how things worked here. :-)
Thanks for backing me up.
I think you're understimating the ecology of the Gulf region. We're not talking A-bombs underground in the desert. The biodiversity in the gulf waters and surrounding marshlands should be a serious concern. While the oil leak very definitely threatens the food chain in that and surrounding areas, using nukes to plug the leak seems like something that should be approached with at leasat some skepticism. A 20% chance of failure + chance of radiation impacting some portion of the undersea area is nothing to get dismissive over. I don't mean to be alarmist and I am open to hearing more. Maybe the 20% failure rate + N% chance of radiation impact in an area of X square miles is the better option of Z days of oil continuing to spill at a rate of Y gallons/day. I don't know.
As I originally said I'm torn between admiration and shock over this approach....though admittedly less shocked the more reading I do.
By the way, where are you getting your info on the 1972 blast? I keep getting blogs citing the kp.ru article.
Translated from http://www.kp.ru/daily/24482/640124/ by Google
And only once failed. In 1972 in Kharkov region failed to block the emergency gas blowout. The explosion was mysteriously left on the surface, forming a mushroom cloud. Although the charge was minimal - just a 4 kiloton. And laid deep - for more than two kilometers.
1) My admiration for the pure guts of such an approach (talk about outside the box thinking)
2) My shock that a 20% failure rate using nukes to treat petrocalamities is seen as acceptable.
From the parent article...
Happily, with a track record like that, “the chances of failure in the Gulf of Mexico are 20%,” KP writes. “The Americans could certainly risk it.”
After what dolphin and whale did to Hiroshima, it's about time!!
Please note, these new editors are not compatible with Gears (the technology that powers offline access), so they do not have offline support today. However, we plan to bring back offline support in the future, taking advantage of new technologies like HTML5 and advancements in modern browsers.
So you're telling me that you know for sure I won't be able to bring up Google Docs and access my Google docs when I have no internet connection? Because right now I can do that in the Chrome Browser with Google Gears and they are working on HTML5 which is supposed to natively support this "offline" functionality. But what you're telling me is that they plan on dropping this paradigm?
Yep -- at least last I heard Gears/offline editing is temporarily going bye-bye. Questionable choice at best -- why not get HTML5 working first unless they really don't care about being a viable option to traditional MS Office type editors? http://www.informationweek.com/news/storage/reviews/showArticle.jhtml?articleID=224202374
Google's other big bet is on the all-cloud environment; it's dropping for now the ability to use Docs when not connected to the Internet. Google thinks most employees don't care about offline mode, but the company knows that C-level execs--the ones who need to approve Google apps--do. They're often on airplanes without Internet connectivity, so not having offline access could be a big strike against the rewritten Docs.
Thanks for responding, but I respectfully disagree. Use of a known OS on a closed system such as a voting kiosk is no more or less risky whether or not you have disclosure of all the source code.
As for the sections you quoted that presumably limit the scope to the OS level, why? That seems like a gapping loophole. Why couldn't someone just write an overly simplistic OS and app and hide a bunch of vote tampering code in the BIOS? On the surface, what's turned over looks legit and clean, but behind the scenes is the undisclosed "election correction" code you're so bent on preventing.
Furthermore, what about manual counting and recounting methods? Are these held to the same level of disclosure? By this, I mean what if the hand tallies are recorded or communicated electronically....you want to have the source for all systems used to record, transmit or communicate those results also available for disclosure? If not, then why not? Aren't these another avenue for tampering?
Call me cynical, but if someone really wants to muck with the system they'll find a way....voting machines or no voting machines, there are ample opportunities for vote tampering before, during and after an election. Don't kid yourselves into thinking you've really reduced the odds of vote tampering by requiring source code disclosure for the systems used to record votes.
In my mind the best bet to increase odds for a fair election is an educated and well informed citizenry. Good luck finding that in the US anymore. :-/
No offense, but if this was really the intent of the statute, this provision seems rather absurd. Seems that a "simple" home brewed OS (even fully disclosed) could present more of an opportunity for some clever tricks or whatnot for vote tampering. From that standpoint an open or widely used OS (*nix or Win*) seem at least as safe.
Maybe your intent was to prevent loopholes for the vote tallying/tracking code being classified with the OS as non-disclosed, but you certainly didn't need to require disclosure of ALL software running on the voting machines.
BTW are you really requiring the source to all software running on the voting machines? So you get application code and OS code. What about all the source and authors for embedded code on the machines such as the BIOS used at bootup? How about the drivers and APIs for all display and input devices? Even if you did, do you really have the resources to review it for potential hidden problems? I doubt it.
Seems you efforts would have been better spent crafting more specific requirements for the application source code, and leaving room for vendors to leverage existing OS, BIOS, device drivers, etc. without worrying over whether it was possible to disclose all source and authors. Maybe an embedded OS would best fit the bill. Maybe not. Did you consider that maybe your overarching requirements prevented a local startup from bidding on a viable solution...with Red Hat based in NC, seems some local company might have been itching to build a voting machine leveraging RHEL or Fedora that met your TRUE needs. Who knows their solution might have toppled traditional vendors such as Diebold, even leading to creation of new jobs in your state.
Also, what lawsuit did you work with the GA on? The articles referenced by the parent implied that no one has been accused of breaking the law yet.
Not sure the 500,000 number is releavant if you change the rules. Had the system been based on popular votes, the actual turnout in FL and elsewhere might have been dramatically different. Changing the rules in how votes are counted is a variable that could impact the motivation of a voter to actually cast his/her vote.r eadmore
Which returns to my original point that by changing the rules you alter a key variable in the original equation...so that study is nothing more than an interesting intellectual exercise.
Given a choice between pure pluarality and the current electoral college system, I tend to lean toward the EC. My preference would be to see more states adopt practices such as Maine where electoral votes are assigned to Congressional districts. This might help with the "all or nothing" approach the probably alienates voters. Of course there are studies that said this type of approach would not have changed the 2000 outcome http://www.usatoday.com/news/vote2000/bush25.htm#
If I know my state may lean Republican, but I live in a decidely Democratic (or Liberterian?) district, then I personally would be less likely to stay home and concede my vote in a system where electoral votes were assigned per district.