Interesting criticisms, but I don't agree with your conclusions.
There's no way for a TV show like SG-1 to go on for 10 years, have the characters actually make progress (i.e. allying with the Asgard, defeating the Goa'uld) without the setting changing as a result.
You're comments sound a lot like you watched a lot of the early episodes of SG-1, missed a couple seasons, and then wondered why things were different when you started watching again. Most likely you missed major plot points.
Now, I agree that the show could have been even better if they hadn't changed the galactic standard language to English in the second episode - but the 9 seasons + 20 episodes that followed that decision more than made up for it.
The compromise, though, is that you are mainly episodic for the first two or three seasons, and become more serialized as your viewer base establishes itself. When you're a new show, you don't want episode 1 to be required viewing for episodes 2 and 3, nor should you leave major plotlines from episode 1 dangling until episodes 4 and 5. "Galactica" did both.
You don't always have to compromise. When done well, a good serial is strictly better than the same show would have been if the writers screwed with the story to try to make it episodic. My best example at the moment where that approach was blatantly successful is Prison Break.
Then we can have a wonderfully interesting discussion about it when that happens.
Talking about it now is a waste of time, because the chances of Mark forcing a perfectly functional application to be pulled from Universe for marketing reasons are damn small.
And I'd rather the show end nicely than fade into irrelevance by over-staying its welcome (as per Star Gate).
Wait, what?
Stargate SG1 was legitimately good for ten seasons straight. It's true that it wasn't exactly the same all ten seasons, nor did it even keep exactly the same cast for all ten seasons, but every single season was higher quality than most television.
My guess is that you either a.) never really watched the show or b.) watched the show until you decided that something minor was lame and prematurely decided that the show had jumped the shark.
The show was too serialized (episodes were chapters of a larger story, not stories in themselves).
There's a tradeoff here, and I'm glad that more TV writers are getting it right. You can either make a very good show with long plot arcs that has time to tell an interesting story, or you can make a crappy episodic show that strings together a bunch of poor quality rushed stories.
if independent developers would test their stuff under WINE and label the retail boxes with "Runs under WINE"
If they want to go that far, they can just compile the app with winelib and have a Linux binary. That way they don't need to worry about a new version of wine changing out from under them at all.
(Remember that many of these machines store the paper ballot internally like a receipt spool, visible through a glass plate, and thus it does not have to be "handed in".)
That's not acceptable, because it prevents an election observer from detecting fraud.
This particular type of legislation actually is helpful. First, it protects people from fraud - one of the a government can obviously legitimately do. Second, it patches a hole in a previous set of laws, which allowed lenders to collect on loans that they gave to third parties in your name.
Machine counting of votes is also sketchy. The big controversies in the 2004 election weren't about direct-recording machines, they were about the automated ballot counting machines. Unless you have a policy in place to require that the paper ballots be retained after scanning (rather than being destroyed) and a way to force a manual recount if *anyone* suspects machine tampering, you really haven't gained anything.
Someone on Slashdot once suggested separating ballot sorting from ballot counting. Put the ballots in a sorting machine and then use a dumb counting machine to count the sorted stacks. That's a much better plan (as long as the counter checks the stack to verify that it's sorted).
They prevent you from accidentally submitting an invalid ballot.
We spend enough time teaching every US citizen to fill out standardized tests in school that we should be able to expect them to handle a multiple choice ballot. One thing that might help the "multiple mark" problem would be moving to Approval Voting, which also has other advantages.
They can be updated with a correct ballot much easier than actually printing ballots.
They can randomly display the list of candidates, eliminating the 'first ballot position' advantage.
Laser printers are cheap. You could print the ballots in real-time at the polling station.
They can more easily accommodate voting by the disabled.
In that case, perhaps every polling station should have one in case a blind person shows up. Or perhaps blind people can bring a person they trust to help them cast their vote. Sure, blind people should have the same voting rights as everyone else - but using blind people as an excuse to require taxpayers to pay out millions of dollars to a specific private corporation is universally bullshit.
But again, as I've been saying, the source code issue is just a distraction. The real issue is voting machine security, and source code has nothing to do with that.
Voting machines are irrelevant. The real issue is voting protocol security, and the presence or absence of a voting machine shouldn't matter if the protocol is secure. The best protocol I know of for use by non-mathematicians involves a directly visually verifiable physical ballot and a physical ballot box - how the ballot is produced is irrelevant.
Ever heard of a root kit? You can't trust anything displayed on a computer screen.
That's not strictly true. If you built the whole computer system from the transistors up through the software by hand then you, personally, can trust the computer - as long as you've never let it out of your sight.
What if they are blind or without hands? Are such voters to be reliant on helpers?
Sure. It's far better to force a small percentage of the population to rely on a person of their choice that they trust than it is to require everyone to rely on machines that are inherently untrustworthy.
You may not understand how to put marks on a ballot so it can be unambigously counted, but you can vote.
If people are that incompetent, why would you expect them to be able to operate a computerized voting machine? Not that they're a legitmate problem for paper ballots; - they can be treated just like any other handicapped person who needs an assistant to vote.
The fact is it is just as easy to stuff paper ballots as to change digital votes
False, It's possible to see that a ballot box is empty, and someone watching the ballot box can tell if it's being stuffed. You can't observe digital votes directly at all, so there's no way to know what they are.
and it is just as easy (or easier) to "loose" and "miscount" paper ballots.
False, an observer can easily spot these attacks.
an open system using strong cryptographic principals to ensure auditability an vote verification.
This stuff is utterly worthless unless every voter is a cryptography and computer security expert. With paper ballots and a ballot box, any voter can understand why the system is secure. Anyone can volunteer to observe the election, and they can easily recognize the attacks that would compromise the security of the system.
With cryptographic voting methods, 99.99% of the population has no idea why the system is secure. They are forced to completely trust a tiny minority of the population - the same minority of the population who designed and built the systems. I'm sorry - that's not even democracy anymore.
Then if there is any worry about the electronic results, they can always fall back to adding the results from the boxes.
There's absolutely no reason to trust any direct-recorded electronic voting results. They're just invisible bits a memory device - they could be anything and they could have been set the way they are in any way at any time. I consider them significantly less reliable as a results metric than exit polls or even the pre-election betting odds.
Once the source had been approved once, wouldnt they simply be able to generate a hash out of the entire set of source, AND of the binaries themselves, and simply compare the machines hashes to the evaluated ones periodically?
How? Is the hash-generation functionality built into the software? If so, the tampered version can just always return the expected hash.
The general problem here is that these "voting machines" are general purpose computers, and so you get into the same "can't ever truly know if the machine is compromised" dilemma that you get with any computer. It could have a memory-resident virtualizing rootkit running that is completely undetectable until it binary patches the voting software in RAM as it runs. The hardware itself could be compromised. The rootkit could delete itself before the detailed post-election analysis, leaving only tampered votes in its wake.
Electronic voting can be secured as much as modern paper ballots - it's not inherently impossible.
Actually, it is inherently impossible for the security properties that matter most for a voting system. Specifically, every voter needs to be able to understand the security of voting process well enough that they can recognize attempts at voting fraud. That's a property that paper ballots that go in ballot boxes can easily have, but is strictly impossible for software installed on a computer.
Consider a 62 year old florist named Mary who has decided to volunteer as an election observer. As the polling station is set up, she verifies that the ballot box is empty. As each voter votes, she makes sure they vote privately in the booth. She can watch as exactly one ballot is added to the ballot box per voter, and no one messes with it otherwise. When the election day is over, she walks/rides with the ballot box to where the votes will be counted. After observing the counting, Mary *knows* that the election was run securely.
Now consider Mary trying to observe an election run with direct-recording electronic voting machines. She can't even accomplish the "verify that the ballot box is empty" step, much less witness that each voter votes only once and doesn't tamper with the vote counts. Hell, I'm in the third year of my Computer Science degree and I couldn't observe a polling station and determine if fraud had occurred there with machines like that. There's just no way to see that what's happening in the machine is what is supposed to be happening.
Sure, we could come up with some mathematically / cryptographically correct secure voting protocol. We could build hardware from scratch that can be visually authenticated somehow. We can publicly publish software source code that has been thoroughly audited for bugs and security holes. We can come up with a mechanism to allow voters to verify that the correct software is running on the machines. With all that, someone with a masters degree in computer security would be able to observer a polling station and personally know that the election there had been run correctly.
Today's direct recording systems are impossible to trust. With years of engineering effort, we could build systems that experts could trust. Or... we could maintain the basic principle of democratic equality and use a system that *everyone* can understand well enough to personally trust.
Besides, if anyone bitches you can just throw open source back in their face and say "This IS the way you wanted it isn't it? I mean you COULD have gone to work for a proprietary software company but you CHOSE to code for free instead. So what exactly is your problem with this, genius?"
You really don't want to be shitting on the apparently minor developers, because every one of the people who will be the "new major developers" next year is one of those "minor" developers right now. If you drive them away, you kill the project.
You'd almost be better paying a "random" independent minor developer to so some larger project than they had before. That way you might get them hooked on the project in the future.
That's a bit too strong a statement about patents. It's quite plausible that if they didn't exist some other mechanism would need to be found to encourage various development efforts that require a lot of up-front costs.
My guess is that you'd find that strict government development subsidies would be far less harmful to the economy than patents are. That, and no poor children would die because they couldn't afford life saving drugs.
You completely missed my argument. Copyright on a work starts from the day *that work* is first published. So if I release a Beta of AwesomeSoft in 2007 and release the Final (with bug fixes) in 2009, with five year copyright AwesomeSoft Final wouldn't become public domain until 2014. Sure, the beta would become public domain two years earlier, but who would go to the trouble of reverse engineering the beta and fixing the bugs themselves if the full version will be legally free in 2 years?
Well for starters, when texture resolution approaches TV resolution, you're done.
This generation just jumped from 480p to 1080p - that's a factor of six more pixels than before. If multi-DVD games were shipping with last generation consoles, that implies that we will see multi dual layer BD-ROM games in this generation, since a dual layer BD-ROM is only 5x as big as a dual layer DVD.
Remember how copyright interacts with public domain material - the whole work is still considered copyrighted even if parts of it are available in the public domain. That means that even though old versions of software could be redistributed, etc- new versions of software would still be copyrighted for five years after they were publicly released. Patches would still have copyright for five years, and CD images for point releases would be copyrighted from the release date.
Major software companies make releases more frequently then every five years, so a five year copyright would hardly effect their business model at all - except that they would have to compete not only with their own releases from five years ago, they would also have to compete with improved zero cost versions of their product from five years ago. More competition in the software market can only be a good thing.
Slashdot Mirror
Interesting criticisms, but I don't agree with your conclusions.
There's no way for a TV show like SG-1 to go on for 10 years, have the characters actually make progress (i.e. allying with the Asgard, defeating the Goa'uld) without the setting changing as a result.
You're comments sound a lot like you watched a lot of the early episodes of SG-1, missed a couple seasons, and then wondered why things were different when you started watching again. Most likely you missed major plot points.
Now, I agree that the show could have been even better if they hadn't changed the galactic standard language to English in the second episode - but the 9 seasons + 20 episodes that followed that decision more than made up for it.
You don't always have to compromise. When done well, a good serial is strictly better than the same show would have been if the writers screwed with the story to try to make it episodic. My best example at the moment where that approach was blatantly successful is Prison Break.
Then we can have a wonderfully interesting discussion about it when that happens.
Talking about it now is a waste of time, because the chances of Mark forcing a perfectly functional application to be pulled from Universe for marketing reasons are damn small.
Wait, what?
Stargate SG1 was legitimately good for ten seasons straight. It's true that it wasn't exactly the same all ten seasons, nor did it even keep exactly the same cast for all ten seasons, but every single season was higher quality than most television.
My guess is that you either a.) never really watched the show or b.) watched the show until you decided that something minor was lame and prematurely decided that the show had jumped the shark.
There's a tradeoff here, and I'm glad that more TV writers are getting it right. You can either make a very good show with long plot arcs that has time to tell an interesting story, or you can make a crappy episodic show that strings together a bunch of poor quality rushed stories.
If they want to go that far, they can just compile the app with winelib and have a Linux binary. That way they don't need to worry about a new version of wine changing out from under them at all.
That's not acceptable, because it prevents an election observer from detecting fraud.
This particular type of legislation actually is helpful. First, it protects people from fraud - one of the a government can obviously legitimately do. Second, it patches a hole in a previous set of laws, which allowed lenders to collect on loans that they gave to third parties in your name.
Machine counting of votes is also sketchy. The big controversies in the 2004 election weren't about direct-recording machines, they were about the automated ballot counting machines. Unless you have a policy in place to require that the paper ballots be retained after scanning (rather than being destroyed) and a way to force a manual recount if *anyone* suspects machine tampering, you really haven't gained anything.
Someone on Slashdot once suggested separating ballot sorting from ballot counting. Put the ballots in a sorting machine and then use a dumb counting machine to count the sorted stacks. That's a much better plan (as long as the counter checks the stack to verify that it's sorted).
We spend enough time teaching every US citizen to fill out standardized tests in school that we should be able to expect them to handle a multiple choice ballot. One thing that might help the "multiple mark" problem would be moving to Approval Voting, which also has other advantages.
Laser printers are cheap. You could print the ballots in real-time at the polling station.
In that case, perhaps every polling station should have one in case a blind person shows up. Or perhaps blind people can bring a person they trust to help them cast their vote. Sure, blind people should have the same voting rights as everyone else - but using blind people as an excuse to require taxpayers to pay out millions of dollars to a specific private corporation is universally bullshit.
Voting machines are irrelevant. The real issue is voting protocol security, and the presence or absence of a voting machine shouldn't matter if the protocol is secure. The best protocol I know of for use by non-mathematicians involves a directly visually verifiable physical ballot and a physical ballot box - how the ballot is produced is irrelevant.
That's not strictly true. If you built the whole computer system from the transistors up through the software by hand then you, personally, can trust the computer - as long as you've never let it out of your sight.
If the machine is outputting a paper ballot, how it produces that ballot is completely irrelevant.
Talking about source code is just a distraction from the important thing: the voter can visually see what vote they're casting.
Sure. It's far better to force a small percentage of the population to rely on a person of their choice that they trust than it is to require everyone to rely on machines that are inherently untrustworthy.
If people are that incompetent, why would you expect them to be able to operate a computerized voting machine? Not that they're a legitmate problem for paper ballots; - they can be treated just like any other handicapped person who needs an assistant to vote.
False, It's possible to see that a ballot box is empty, and someone watching the ballot box can tell if it's being stuffed. You can't observe digital votes directly at all, so there's no way to know what they are.
False, an observer can easily spot these attacks.
This stuff is utterly worthless unless every voter is a cryptography and computer security expert. With paper ballots and a ballot box, any voter can understand why the system is secure. Anyone can volunteer to observe the election, and they can easily recognize the attacks that would compromise the security of the system.
With cryptographic voting methods, 99.99% of the population has no idea why the system is secure. They are forced to completely trust a tiny minority of the population - the same minority of the population who designed and built the systems. I'm sorry - that's not even democracy anymore.
There's absolutely no reason to trust any direct-recorded electronic voting results. They're just invisible bits a memory device - they could be anything and they could have been set the way they are in any way at any time. I consider them significantly less reliable as a results metric than exit polls or even the pre-election betting odds.
How? Is the hash-generation functionality built into the software? If so, the tampered version can just always return the expected hash.
The general problem here is that these "voting machines" are general purpose computers, and so you get into the same "can't ever truly know if the machine is compromised" dilemma that you get with any computer. It could have a memory-resident virtualizing rootkit running that is completely undetectable until it binary patches the voting software in RAM as it runs. The hardware itself could be compromised. The rootkit could delete itself before the detailed post-election analysis, leaving only tampered votes in its wake.
Actually, it is inherently impossible for the security properties that matter most for a voting system. Specifically, every voter needs to be able to understand the security of voting process well enough that they can recognize attempts at voting fraud. That's a property that paper ballots that go in ballot boxes can easily have, but is strictly impossible for software installed on a computer.
Consider a 62 year old florist named Mary who has decided to volunteer as an election observer. As the polling station is set up, she verifies that the ballot box is empty. As each voter votes, she makes sure they vote privately in the booth. She can watch as exactly one ballot is added to the ballot box per voter, and no one messes with it otherwise. When the election day is over, she walks/rides with the ballot box to where the votes will be counted. After observing the counting, Mary *knows* that the election was run securely.
Now consider Mary trying to observe an election run with direct-recording electronic voting machines. She can't even accomplish the "verify that the ballot box is empty" step, much less witness that each voter votes only once and doesn't tamper with the vote counts. Hell, I'm in the third year of my Computer Science degree and I couldn't observe a polling station and determine if fraud had occurred there with machines like that. There's just no way to see that what's happening in the machine is what is supposed to be happening.
Sure, we could come up with some mathematically / cryptographically correct secure voting protocol. We could build hardware from scratch that can be visually authenticated somehow. We can publicly publish software source code that has been thoroughly audited for bugs and security holes. We can come up with a mechanism to allow voters to verify that the correct software is running on the machines. With all that, someone with a masters degree in computer security would be able to observer a polling station and personally know that the election there had been run correctly.
Today's direct recording systems are impossible to trust. With years of engineering effort, we could build systems that experts could trust. Or... we could maintain the basic principle of democratic equality and use a system that *everyone* can understand well enough to personally trust.
With Java being open sourced, I have an odd feeling that applets may have been resurrected as a Flash/Silverlight competitor.
You really don't want to be shitting on the apparently minor developers, because every one of the people who will be the "new major developers" next year is one of those "minor" developers right now. If you drive them away, you kill the project.
You'd almost be better paying a "random" independent minor developer to so some larger project than they had before. That way you might get them hooked on the project in the future.
My guess is that you'd find that strict government development subsidies would be far less harmful to the economy than patents are. That, and no poor children would die because they couldn't afford life saving drugs.
You completely missed my argument. Copyright on a work starts from the day *that work* is first published. So if I release a Beta of AwesomeSoft in 2007 and release the Final (with bug fixes) in 2009, with five year copyright AwesomeSoft Final wouldn't become public domain until 2014. Sure, the beta would become public domain two years earlier, but who would go to the trouble of reverse engineering the beta and fixing the bugs themselves if the full version will be legally free in 2 years?
This generation just jumped from 480p to 1080p - that's a factor of six more pixels than before. If multi-DVD games were shipping with last generation consoles, that implies that we will see multi dual layer BD-ROM games in this generation, since a dual layer BD-ROM is only 5x as big as a dual layer DVD.
Or... get this... formatted it at the new disk size and pass on the tech advantage to their customers.
Remember how copyright interacts with public domain material - the whole work is still considered copyrighted even if parts of it are available in the public domain. That means that even though old versions of software could be redistributed, etc- new versions of software would still be copyrighted for five years after they were publicly released. Patches would still have copyright for five years, and CD images for point releases would be copyrighted from the release date.
Major software companies make releases more frequently then every five years, so a five year copyright would hardly effect their business model at all - except that they would have to compete not only with their own releases from five years ago, they would also have to compete with improved zero cost versions of their product from five years ago. More competition in the software market can only be a good thing.