Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:What does your ballot look like? (Score 1) 171

I think I know what you're getting at. Consider this:

  • - There are 10 votes. 4 for party A, 3 for party B, and 3 for null. That means neither A nor B get a majority. In many cases this would trigger a runoff.
  • - The three in the previous case who voted null just stay home. 4 for party A and 3 for party B means ~57% for A, who then gets a majority.

You could imagine more values which would represent "other", "invalid choice", "explicitly undecided", etc.

To be fair, not pushing a button on that part of the machine isn't strictly equivalent to an explicit "none of the above" (more equivalent to just staying home). Perhaps leaving it blank whether you go to the polls or not ought to count as a choice - it might get some politicians to stop using low turnout as a campaign strategy.

Comment Re:Arbitrary major version jumps (Score 1) 172

Since you clearly didn't look up Rice's Theorem, here it is:

Any non-trivial property of a Turing machine is undecidable.

In other words, there is no methodical way to guarantee anything interesting about a piece of software, and that includes whether it works properly under every input. You can verify that it works with "typical" inputs, but there will always be some set of boundary conditions that you couldn't possibly have known to check on day one.

Comment Re:Arbitrary major version jumps (Score 1) 172

Look up Rice's Theorem. Or work on a major software project. It goes way beyond unfair to expect a complex software system to "just work as it should" - it's mathematically impossible to make sure it does.

Beyond that, supporting every single ancient version just because one guy somewhere might be using it would take man-hours away from supporting the versions most people use. It sucks for that one guy, but it'd suck for everyone else if a gaping security hole in a more common version were to stay unpatched for too long.

Furthermore, the older a version of a program gets, the more of its devs switch jobs, retire, etc. You can bring on new devs and make them learn the old code base (current job market notwithstanding), but once again, that takes man-hours, especially if the old code base was written before everyone started thinking about maintainability. You could instead put them to work adding a feature to the next version that a larger segment of the market has been wanting. And you need to keep releasing software - the competitors are, and the devs' salaries don't appear out of thin air.

Slashdot Top Deals

"There is no statute of limitations on stupidity." -- Randomly produced by a computer program called Markov3.