If you don't know how it works, here you go: An approval voting ballot has all of the candidates listed. You mark all of those that are acceptable to you. The candidate with the most marks wins.
A good idea, but the problems are deeper than Approval Voting can fix. There has not ever been a candidate I felt I could approve of in the last 3 decades.
Because parties have no incentive to put up broadly-appealing candidates.
I guess what I am saying is the process for getting candidates needs to be reformed more than the actual voting in elections. Approval Voting only takes care of part of the problem.
Obviously. The solution to the rest of the problem is to get involved. You should attend local caucus meetings (for some party) and attempt to shape the selection of state and national convention representatives. Our democracy is and will be as good as we're willing to invest the time and effort to make it.
The decisions about party platforms and candidates are ultimately made by only a few tens of thousands of people, in many cases fewer, because they're the only ones who show up.
Interesting approach, but I doubt that it has been tested in the real world.
https://en.wikipedia.org/wiki/Approval_voting#Usage. I was tempted to reply with a lmgtfy link, since it's kind of silly to doubt something like that without doing the trivial search to find out.
I think it would become a name recognition game, as long as the name wasn't recognized for something horribly negative.
This is the case among less-educated voters in every system. This isn't an argument against approval voting, it's an argument against universal, requirement-free suffrage.
I think #PresidentTweety could have won in such a system because he had YUGE name recognition and almost no relevant track record (as regards politics).
Considering that his approval rating on election day was 40%, I strongly doubt it.
Just explain that you must put a "1" next to your preferred candidate, a "2" next to your second choice, and so on. Or program the ballot counting computer to accept a check mark as a "1" and an empty box as a "2" and then it becomes approval voting.
Explaining the notion of ranking isn't the hard part. Explaining how those ballots are *counted* that's the hard part -- because counting them is complicated!
Ok, that we can agree on. Have computers count the paper slips. Fine. But every single vote has to be able to be counted manually. And I mean that literally to mean "by hand".
That's fine. But mathematics and computers can also be used to provide integrity guarantees that are actually stronger than the best hand recount (while retaining the possibility of doing the hand recount as desired). Scantegrity II.
You should look into Scantegrity II. It applies computers before and after the balloting to actually increase the integrity of the vote -- irrespective of what voting system is used.
I used to be a fan of Condorcet methods. I've come around to thinking approval voting is better even though it's slightly inferior mathematically. See my https://politics.slashdot.org/... for why.
I used to be big fan of ranked voting, especially with Condorcet evaluation with Schwarz Sequential Dropping. Then I tried to explain it to a few people and changed my mind. Instant-runoff is a little simpler, but still pretty complicated -- and actually a bit tricky to execute correctly since it's inherently multi-pass (Condorcet is simpler to execute). Simplicity matters because what's just as important as having a fair election, is having a fair election that voters can understand and trust.
I think the best scheme overall is approval voting. The mathematical properties of approval voting are almost as good as the best ranked voting schemes. It's a little more vulnerable to strategic voting (which is when voters might have reason to vote other than their true preferences, as is the norm in plurality-rules schemes), but really not very much. In theory it also doesn't capture quite as much nuance of voter intent since it doesn't allow one to express a preference between two acceptable candidates. But it does allow voters to express another important element of intent which ranked ballots don't allow: acceptability. And it's brain-dead simple to understand.
If you don't know how it works, here you go: An approval voting ballot has all of the candidates listed. You mark all of those that are acceptable to you. The candidate with the most marks wins.
Such a system eliminates the strong two-party bias that plurality-rules systems have (Duverger's Law, that bias is called). In very few cases does it ever make sense to vote other than your true preferences. And it encourages parties to field broadly-acceptable candidates.
Tallying is a single-pass process and counts can be provided by sub-regions for totalling (unlike IRV, where the runoff phases require reinterpretation of the ballots at each runoff). If it's desired, you can even specify a minimum win threshold -- if no candidate gets, say, 50% approval then no one wins and you re-run the election with a new slate of candidates. There's an obvious risk of never getting a winner here, so such a system should probably progressively lower the required approval level to be sure that someone eventually wins, but the flip side is that such a system would mean that the 2016 US presidential election would never have put either Hillary Clinton or Donald Trump on the ballot; both (all) parties would be looking for someone with broader appeal.
However, approval voting can be done with or without computers, so it's not really relevant here. IRV can also be done without computers, though it's kind of tedious without them.
Arguably, a hybrid system (as is common these days) of paper ballots counted electronically could be better than a pure paper system -- then you can use computer techniques to look for problems, and paper hand counts to check afterwards.
Even better than that. You can apply techniques from cryptography to enable mathematically-provable election results, providing any voter with a receipt they can use to verify that their ballot was counted correctly -- but which they cannot use to prove to any third party who they voted for, and enabling anyone to download the set of files representing the final tally and verify the totals themselves, and trace every ballot back to those printed and verified pre-election.
In that system, computers are used both before and after the balloting. Before to generate all of the codes printed on all of the ballots and to enable integrity-checking of the printed ballots, and after to electronically scan all of the ballots and perform various post-election verification processes. And of course the paper ballots remain if there's a need to check them as well, though honestly the mathematical guarantees are tighter than any recount.
This system exists, has gone through several iterations of improvements to make it more and more practical and cost-effective, and has been tested in real-world elections. It's the brainchild of Ronald Rivest (the "R" in "RSA") and David Chaum (inventor of the first practical digital cash system, which long predated Bitcoin), among other top academic cryptographers and it's called Scantegrity II
Who, as a person or corporation, is liable for damages if the driverless vehicle broke the law in does damage to something/someone?
The only sensible answer to this question is "the company that made the self-driving system". Google has stated that it plans to accept that liability, as have Volvo and several others.
Imagine some kid discovering he can make an entire line of self-driving cars stop suddenly just by spinning around on the curb. You just KNOW he's going to abuse his newfound powers!
The only way they put these things on the road is with blanket complete liability protects from the GOV saying they are not responsible for anything bad that happens.
Cite?
Google has stated that it will take liability for cars using its self-driving systems. Several other companies working on them have said the same.
Insurance companies will say "use driverless, or you pay X times more"
There's no reason for insurance on manually-driven cars to go up. In fact, as the number of driverless cars on the road rises, and the roads become safer overall, it will go down.
However, liability insurance on manually-operated cars will be infinitely higher than insurance on driverless cars, because the latter will be zero. More precisely, it will be paid by the manufacturer of the self-driving system, not the owner/driver of the car, because how can you be liable for accidents caused by the self-driving system?
Of course, many governments will still require the owner to carry uninsured/underinsured motorist coverage of course (and it's a good idea even if not required), and if you borrow money to buy the driverless car the bank will require you to carry comprehensive insurance to cover their risk in case a tree falls on the car or something.
First, Google's management may just push back hard on anyone rocking the boat in any direction.
I think it's mostly a variation on this: Google's management pushes back hard when employees are spending their time arguing about stuff that gets in the way of getting any work done.
The Google's of the world love to pretend that they want a "discussion" or a "dialog", but in reality if one should break out, they lower the boom.
You mean "if employees spend their time in heated discussion rather than getting work done, they lower the boom." And "the boom" in this case was a request to please stop sparking flame wars.
If you RTFA what Google execs did was shut down contentious discussions about diversity. Altheide posted pro-diversity comments which apparently tended to spark big flamewars, and he was told to stop.
The fact is that this is a contentious topic in the tech industry, inside Google just as much as everywhere else (including slashdot, obviously). Google employees have lots of internal communications fora which are unpoliced and heavily used, and the employees are not closely monitored, which creates a risk that when contentious topics arise on these internal fora people get sucked in, wasting a lot of time and generating a lot of bad blood, both of which have significant negative impacts on productivity.
One of the core tenets of Google culture is that one should always assume good faith and competence on the part of their colleagues (unless proven otherwise, obviously), but that's a tenet that works much better in a small company that is highly selective in its hires. In most situations it works reasonably well in a big company that is highly selective in its hires... but as you grow the law of averages catches up with you and assholes and incompetents sneak in. This is particularly true around areas that won't come up in an interview, like attitudes about diversity.
As a Google employee, my takeaway is "This is why we can't have nice things." Open discussion fora with light oversight, and a culture of internal transparency and openness are really awesome, but they appear to be incompatible with being a large multinational corporation. Sigh.
OTOH, any light that is neither reflected nor converted to electricity will heat the panel, and efficiency decreases as panel temperature increases. So ideally it's best to reflect all light that isn't converted.
Here's a hint: A bricked device might as well be a brick. It is unusable for its original purpose, forever.
In fairness, I think the usage of the term has shifted a bit, because we're more careful to design things so that permanently destroying them is impossible, or at least a lot harder. I've taken to using the term "perma-bricking" when I mean it's dead forever. A "bricked" device might be recoverable through extraordinary means. I brick a device in that way every few months or so, and recovery normally requires shipping it to another state where someone with the magic super low-level firmware signing key can fix it.
Since the bikes are only to be used by environmentally friendly employees, can't those employees simply just have their own bike?
Hauling my personal bike from home (in Utah) to the Google campus every time I go there for a couple days' worth of meetings would be... impractical... shall we say. Even for local employees, most don't live close enough to bike to the office, so they come to work in their car or via mass transit, which would also make it infeasible to bring their own bike.
And the purpose isn't to enable employees to be "environmentally friendly", it's to enable employees to get from building to building in a reasonable amount of time. Without the bikes, I guess the company would have to run shuttles all the time between buildings. That would be more expensive than buying 50 cheap bikes every month. Walking is certainly possible (and fairly common) but the campus is large enough that it would become a significant time sink.
Apparently they're valuable enough to install GPS trackers on them.
On a fraction of them, at least. Putting trackers on a third of them costs 1/3 as much as putting trackers on all of them, and is probably roughly as effective as putting trackers on all of them.
f employees are using smartphones for work purposes, they should be controlled via MDM. Create and push an app that auto-registers a bike via NFC/WiFi/Bluetooth, which is probably less expensive than a GPS tracker. Hell, use the GPS in the smartphone to track riders real-time.
That would only work if the person who took the bike was an employee.
My company gave it serious thought. But browsing through it is like poison to the soul as you find too much fighting over social justice issues instead of focus on the technology. So we went with a significantly less polarizing language and community.
Really? I've spent a fair amount of time in the community forums and found almost none of this. I see a lot of focused, technical discussion, with a friendly and helpful tone. I see whining over social justice issues every time Rust comes up on slashdot, but that hardly seems relevant to a technical decision about language choice.
Are speculative gadgets a problem here? If so, Google's clever patch is going to need a sump pump bolted on the side.
Sure, speculative gadgets are a problem... which is why the Retpoline solution has to be applied to every binary in the system. And it has to be implemented in the code generation back-end. The back-end has to scan for potential gadgets and retpoline them.
And then you get into the whole problem of deterministic compilation [wikipedia.org] in order to be certain that the executable you build contains the necessary mitigations (or some tricky post-compile analysis I sure don't wish to develop myself).
That's an easy problem for Google and, I expect, other big cloud systems. Google builds everything itself, including compilers. If you're big enough and have the engineering resources, that makes sense for lots of other reasons anyway.
For everyone else, it's a problem, but it's an existing problem -- how do you trust any binary? And if someone is going to compromise your binary inserting such gadgets would be a bad way to do it because you could scan for them.
Slashdot Mirror
If you don't know how it works, here you go: An approval voting ballot has all of the candidates listed. You mark all of those that are acceptable to you. The candidate with the most marks wins.
A good idea, but the problems are deeper than Approval Voting can fix. There has not ever been a candidate I felt I could approve of in the last 3 decades.
Because parties have no incentive to put up broadly-appealing candidates.
I guess what I am saying is the process for getting candidates needs to be reformed more than the actual voting in elections. Approval Voting only takes care of part of the problem.
Obviously. The solution to the rest of the problem is to get involved. You should attend local caucus meetings (for some party) and attempt to shape the selection of state and national convention representatives. Our democracy is and will be as good as we're willing to invest the time and effort to make it.
The decisions about party platforms and candidates are ultimately made by only a few tens of thousands of people, in many cases fewer, because they're the only ones who show up.
Interesting approach, but I doubt that it has been tested in the real world.
https://en.wikipedia.org/wiki/Approval_voting#Usage. I was tempted to reply with a lmgtfy link, since it's kind of silly to doubt something like that without doing the trivial search to find out.
I think it would become a name recognition game, as long as the name wasn't recognized for something horribly negative.
This is the case among less-educated voters in every system. This isn't an argument against approval voting, it's an argument against universal, requirement-free suffrage.
I think #PresidentTweety could have won in such a system because he had YUGE name recognition and almost no relevant track record (as regards politics).
Considering that his approval rating on election day was 40%, I strongly doubt it.
Just explain that you must put a "1" next to your preferred candidate, a "2" next to your second choice, and so on. Or program the ballot counting computer to accept a check mark as a "1" and an empty box as a "2" and then it becomes approval voting.
Explaining the notion of ranking isn't the hard part. Explaining how those ballots are *counted* that's the hard part -- because counting them is complicated!
Ok, that we can agree on. Have computers count the paper slips. Fine. But every single vote has to be able to be counted manually. And I mean that literally to mean "by hand".
That's fine. But mathematics and computers can also be used to provide integrity guarantees that are actually stronger than the best hand recount (while retaining the possibility of doing the hand recount as desired). Scantegrity II.
You should look into Scantegrity II. It applies computers before and after the balloting to actually increase the integrity of the vote -- irrespective of what voting system is used.
I used to be a fan of Condorcet methods. I've come around to thinking approval voting is better even though it's slightly inferior mathematically. See my https://politics.slashdot.org/... for why.
Computers would make this easier but are not required.
https://en.wikipedia.org/wiki/Ranked_voting http://www.fairvote.org/rcv
I used to be big fan of ranked voting, especially with Condorcet evaluation with Schwarz Sequential Dropping. Then I tried to explain it to a few people and changed my mind. Instant-runoff is a little simpler, but still pretty complicated -- and actually a bit tricky to execute correctly since it's inherently multi-pass (Condorcet is simpler to execute). Simplicity matters because what's just as important as having a fair election, is having a fair election that voters can understand and trust.
I think the best scheme overall is approval voting. The mathematical properties of approval voting are almost as good as the best ranked voting schemes. It's a little more vulnerable to strategic voting (which is when voters might have reason to vote other than their true preferences, as is the norm in plurality-rules schemes), but really not very much. In theory it also doesn't capture quite as much nuance of voter intent since it doesn't allow one to express a preference between two acceptable candidates. But it does allow voters to express another important element of intent which ranked ballots don't allow: acceptability. And it's brain-dead simple to understand.
If you don't know how it works, here you go: An approval voting ballot has all of the candidates listed. You mark all of those that are acceptable to you. The candidate with the most marks wins.
Such a system eliminates the strong two-party bias that plurality-rules systems have (Duverger's Law, that bias is called). In very few cases does it ever make sense to vote other than your true preferences. And it encourages parties to field broadly-acceptable candidates.
Tallying is a single-pass process and counts can be provided by sub-regions for totalling (unlike IRV, where the runoff phases require reinterpretation of the ballots at each runoff). If it's desired, you can even specify a minimum win threshold -- if no candidate gets, say, 50% approval then no one wins and you re-run the election with a new slate of candidates. There's an obvious risk of never getting a winner here, so such a system should probably progressively lower the required approval level to be sure that someone eventually wins, but the flip side is that such a system would mean that the 2016 US presidential election would never have put either Hillary Clinton or Donald Trump on the ballot; both (all) parties would be looking for someone with broader appeal.
However, approval voting can be done with or without computers, so it's not really relevant here. IRV can also be done without computers, though it's kind of tedious without them.
Arguably, a hybrid system (as is common these days) of paper ballots counted electronically could be better than a pure paper system -- then you can use computer techniques to look for problems, and paper hand counts to check afterwards.
Even better than that. You can apply techniques from cryptography to enable mathematically-provable election results, providing any voter with a receipt they can use to verify that their ballot was counted correctly -- but which they cannot use to prove to any third party who they voted for, and enabling anyone to download the set of files representing the final tally and verify the totals themselves, and trace every ballot back to those printed and verified pre-election.
In that system, computers are used both before and after the balloting. Before to generate all of the codes printed on all of the ballots and to enable integrity-checking of the printed ballots, and after to electronically scan all of the ballots and perform various post-election verification processes. And of course the paper ballots remain if there's a need to check them as well, though honestly the mathematical guarantees are tighter than any recount.
This system exists, has gone through several iterations of improvements to make it more and more practical and cost-effective, and has been tested in real-world elections. It's the brainchild of Ronald Rivest (the "R" in "RSA") and David Chaum (inventor of the first practical digital cash system, which long predated Bitcoin), among other top academic cryptographers and it's called Scantegrity II
I have seen the GOV giving them exceptions to speed the development.
Liability exceptions? Cite? I've seen some states moving rapidly on allowing them on the roads, but that's all.
Who, as a person or corporation, is liable for damages if the driverless vehicle broke the law in does damage to something/someone?
The only sensible answer to this question is "the company that made the self-driving system". Google has stated that it plans to accept that liability, as have Volvo and several others.
Imagine some kid discovering he can make an entire line of self-driving cars stop suddenly just by spinning around on the curb. You just KNOW he's going to abuse his newfound powers!
And the software will be adjusted.
The only way they put these things on the road is with blanket complete liability protects from the GOV saying they are not responsible for anything bad that happens.
Cite?
Google has stated that it will take liability for cars using its self-driving systems. Several other companies working on them have said the same.
Insurance companies will say "use driverless, or you pay X times more"
There's no reason for insurance on manually-driven cars to go up. In fact, as the number of driverless cars on the road rises, and the roads become safer overall, it will go down.
However, liability insurance on manually-operated cars will be infinitely higher than insurance on driverless cars, because the latter will be zero. More precisely, it will be paid by the manufacturer of the self-driving system, not the owner/driver of the car, because how can you be liable for accidents caused by the self-driving system?
Of course, many governments will still require the owner to carry uninsured/underinsured motorist coverage of course (and it's a good idea even if not required), and if you borrow money to buy the driverless car the bank will require you to carry comprehensive insurance to cover their risk in case a tree falls on the car or something.
First, Google's management may just push back hard on anyone rocking the boat in any direction.
I think it's mostly a variation on this: Google's management pushes back hard when employees are spending their time arguing about stuff that gets in the way of getting any work done.
The Google's of the world love to pretend that they want a "discussion" or a "dialog", but in reality if one should break out, they lower the boom.
You mean "if employees spend their time in heated discussion rather than getting work done, they lower the boom." And "the boom" in this case was a request to please stop sparking flame wars.
If you RTFA what Google execs did was shut down contentious discussions about diversity. Altheide posted pro-diversity comments which apparently tended to spark big flamewars, and he was told to stop.
The fact is that this is a contentious topic in the tech industry, inside Google just as much as everywhere else (including slashdot, obviously). Google employees have lots of internal communications fora which are unpoliced and heavily used, and the employees are not closely monitored, which creates a risk that when contentious topics arise on these internal fora people get sucked in, wasting a lot of time and generating a lot of bad blood, both of which have significant negative impacts on productivity.
One of the core tenets of Google culture is that one should always assume good faith and competence on the part of their colleagues (unless proven otherwise, obviously), but that's a tenet that works much better in a small company that is highly selective in its hires. In most situations it works reasonably well in a big company that is highly selective in its hires... but as you grow the law of averages catches up with you and assholes and incompetents sneak in. This is particularly true around areas that won't come up in an interview, like attitudes about diversity.
As a Google employee, my takeaway is "This is why we can't have nice things." Open discussion fora with light oversight, and a culture of internal transparency and openness are really awesome, but they appear to be incompatible with being a large multinational corporation. Sigh.
No, they just buy their own politicians. They do not need to vote when they own both candidates.
And yet they can still be sued. Why is that?
OTOH, any light that is neither reflected nor converted to electricity will heat the panel, and efficiency decreases as panel temperature increases. So ideally it's best to reflect all light that isn't converted.
Here's a hint: A bricked device might as well be a brick. It is unusable for its original purpose, forever.
In fairness, I think the usage of the term has shifted a bit, because we're more careful to design things so that permanently destroying them is impossible, or at least a lot harder. I've taken to using the term "perma-bricking" when I mean it's dead forever. A "bricked" device might be recoverable through extraordinary means. I brick a device in that way every few months or so, and recovery normally requires shipping it to another state where someone with the magic super low-level firmware signing key can fix it.
They actually are not going up, if you look at costs relative to GDP
Cost relative to GDP is roughly as skewed a measure as absolute costs. Perhaps the best measure would be inflation-adjusted cost per capita.
Since the bikes are only to be used by environmentally friendly employees, can't those employees simply just have their own bike?
Hauling my personal bike from home (in Utah) to the Google campus every time I go there for a couple days' worth of meetings would be... impractical... shall we say. Even for local employees, most don't live close enough to bike to the office, so they come to work in their car or via mass transit, which would also make it infeasible to bring their own bike.
And the purpose isn't to enable employees to be "environmentally friendly", it's to enable employees to get from building to building in a reasonable amount of time. Without the bikes, I guess the company would have to run shuttles all the time between buildings. That would be more expensive than buying 50 cheap bikes every month. Walking is certainly possible (and fairly common) but the campus is large enough that it would become a significant time sink.
Apparently they're valuable enough to install GPS trackers on them.
On a fraction of them, at least. Putting trackers on a third of them costs 1/3 as much as putting trackers on all of them, and is probably roughly as effective as putting trackers on all of them.
f employees are using smartphones for work purposes, they should be controlled via MDM. Create and push an app that auto-registers a bike via NFC/WiFi/Bluetooth, which is probably less expensive than a GPS tracker. Hell, use the GPS in the smartphone to track riders real-time.
That would only work if the person who took the bike was an employee.
I'm curious, how does one file a counternotice to Googletube? I'll go to court all day. Fuck it I'm bored.
Same as anywhere else. Registered letter from your attorney.
My company gave it serious thought. But browsing through it is like poison to the soul as you find too much fighting over social justice issues instead of focus on the technology. So we went with a significantly less polarizing language and community.
Really? I've spent a fair amount of time in the community forums and found almost none of this. I see a lot of focused, technical discussion, with a friendly and helpful tone. I see whining over social justice issues every time Rust comes up on slashdot, but that hardly seems relevant to a technical decision about language choice.
Are speculative gadgets a problem here? If so, Google's clever patch is going to need a sump pump bolted on the side.
Sure, speculative gadgets are a problem... which is why the Retpoline solution has to be applied to every binary in the system. And it has to be implemented in the code generation back-end. The back-end has to scan for potential gadgets and retpoline them.
And then you get into the whole problem of deterministic compilation [wikipedia.org] in order to be certain that the executable you build contains the necessary mitigations (or some tricky post-compile analysis I sure don't wish to develop myself).
That's an easy problem for Google and, I expect, other big cloud systems. Google builds everything itself, including compilers. If you're big enough and have the engineering resources, that makes sense for lots of other reasons anyway.
For everyone else, it's a problem, but it's an existing problem -- how do you trust any binary? And if someone is going to compromise your binary inserting such gadgets would be a bad way to do it because you could scan for them.