Large tech companies -- including Google -- have exited countries before over repressive laws; The "someone will build it" argument therefore rings hollow.
You think Samsung, LG, HTC, etc. would refuse to sell devices in the UK if Google didn't provide what was required? I think you're forgetting that Android is open source.
There are dozens of suggestions in response to your first post, but the most common suggestion is the one that I think is the most obvious: don't participate in adding backdoors to encryption software.
The rationalization that somebody else will inevitably do some "bad thing" (and maybe do a poor job of it) doesn't make it ethical for you to do that "bad thing".
So, option 1.
Honestly, my response is *not* a convenient rationalization. Perhaps it would be for an iOS engineer, but Android is open source.
Let's suppose that Google simply refused. What would happen? Would Samsung, HTC, LG, etc. simply say "Oh, okay, well, I guess we can't sell our devices in the UK. Darn." Absolutely not. They'd add a backdoor and sell lots of devices, and there isn't a thing Google could do about it. How well would they do at keeping the backdoor as absolutely narrow as possible? Recall that one of the major vendors was found to be storing fingerprints in cleartext, world-readable. That's not atypical.
Given that, what would Google's refusal accomplish? I suppose I personally could feel better about myself for having refused, but not much better, since it would actually have made the world worse.
You are responsible for your own actions and not the assumed actions of others.
Bullshit. If you know that your decision to do (or not do) X will result in some bad outcome Y, it's nothing but a cop out to say that because you didn't yourself do Y that you are not responsible for it. If you could have prevented it, or at least made it less bad, and you didn't, then you are responsible. This means that if the actions of others are clearly and easily predictable then it's unethical to ignore them in your calculation of what action you yourself should take.
Upload rates to my Google Drive on the same computer can saturate my local upstream, 30 times faster than OneDrive.
Heh. The common complaint about Google Drive used to be the opposite. Whatever your connection was, Drive would saturate it to the point that nothing else worked. You can now set rate limits.
What microsoft doesnt understand is that Google does not operate in the traditional weasle-word sense of "enterprise grade." while youre purchasing shiny new netapps, theyre using off the shelf commodity hard drives modelled by their own statisticians to predict failure. they dont repair arrays or disks, they dont have to worry about memory failures. anything that dies gets chucked, replaced, reprovisioned, and brought back into the fold as if nothing ever happened.
Do you really think MS isn't using the same commodity hardware approach? That seems very ulikely to me. Beyond a certain scale it's the only reasonable way to approach the problem. You can't rely on even the most "enterprisey" of enterprise hardware to be sufficiently reliable because even with MTBF measured in millions of hours, when you have hundreds of thousands of drives they're going to be failing left and right. So you have to architect systems with plenty of redundancy and completely automatic failover and recovery. And once you have that infrastructure in place, there's no point in paying the enterprise prices. Instead, you buy commodity drives by the truckload.
Someone earlier said that the original contracts were for up to four years. If changing terms like that within the span of the contract *isn't* illegal, then it should be.
Unilaterally changing the terms of a contract is illegal, unless the contract contains language allowing the change, and maybe not even then. The more likely case is that the "someone" who said the contracts were for four years was wrong, or that only some contracts were that long, in which case MS will undoubtedly honor the terms of the long contracts until they expires.
Really, the odds that MS is trying to illegally modify a contract are vanishingly small. They aren't that dumb.
Ethics is about choices between alternatives, it's not unethical to do a bad thing if all of the other alternatives are worse.
You've artificially narrowed the alternatives so that you can rationalize choosing an unethical one. Even choice #1, refusing to do the bad thing, was artificially constrained so that it could be dismissed out of hand.
Okay, what are the other effective alternatives? Note that I'm assuming effective enforcement, so sneaking in a non-backdoored system isn't feasible.
Besides the option to withdraw from the UK market in protest (coordinating this with Apple would be highly effective, I think)
Assuming the UK government doesn't cave, that's equivalent to options 1 and/or 3. Because someone will build devices for that market that do comply... and may not do nearly as good a job of limiting the risk of the backdoor.
you could also make your security protocols modular, so users can freely download stronger FOSS versions.
Sure, but you still have the problem that hardly anyone would do it.
Not in the scenario you described. Take as a given that laws mandating crypto backdoors are unethical. Then Google would be unethical for adhering to those laws
As opposed to building systems without any security, or as opposed to not building systems at all? Ethics is about choices between alternatives, it's not unethical to do a bad thing if all of the other alternatives are worse.
I work for Google. I build strong encryption in Android. The possibility of laws mandating back doors creates an interesting dilemma for me. Supposing such a law were to exist, and were effectively enforced so there's no possibility of sneaking in a non-backdoored system, what would I do?
I see three options.
1. I could run away from the problem, changing jobs to let someone else deal with it.
2. I could accede, trying to build the tightest, narrowest, best-controlled backdoor possible, doing my best to ensure that only authorized government agencies could use it.
3. I could refuse to build strong security systems at all, making it clear to everyone that their data is unprotected.
What's the right thing to do? #1 is out, unless I have some reason to believe that someone else could make better decisions. #3 has some nose-thumbing appeal, but it means that everyone's data is accessible not only to government agencies, but to thieves, family members, spouses, etc. Also, this may be equivalent to #1, in that I'll be shuffled to another job and replaced by someone willing to build back doors.
So, frankly, it's actually not much of a dilemma at all. I would do #2 (choice of number was not accidental). Well, and I'd probably also contribute to open source, possibly underground strong crypto implementations in my free time, because I strongly believe that the ability of people to keep secrets is critical to individual freedom and to societal progress. But such systems would only be used by a handful, seriously reducing their value.
It's really, really important that we fight this sort of thing in the public, though. I've never been asked to build in back doors, and I never want to be.
Oh, and by the way: Those of you out there who complain that you don't want full device encryption because it's slow? The slowness may be annoying, but it's well worth it. Not so much to you, now, but to everyone, in the future. Have a little patience with it. It will get faster over time as hardware gets faster and perhaps dedicated encryption hardware is added, but if we don't get it in now, setting the precedent that it's normal to encrypt everything, all the time, with the strongest crypto we can find and no back doors, there's a much greater risk that we may not be allowed to do it later.
Untrue. Encryption may be "Information-Theoretically secure". These cannot be broken with just enough computing power. For example, for ordinary text, this is even true for the venerable Enigma if less than 4000 Bits (if I remember things correctly) of ciphertext are available and the key was chosen at random.
This notion is what Shannon called "unicity distance". Assuming arbitrary computing power, so that brute force search of the entire keyspace is perfectly feasibly, unicity distance is the amount of ciphertext required to uniquely determine the key in a ciphertext-only attack. The unicity distance of a cipher is dependent on the details of the cipher and of the plaintext, though there's a notion of minimum unicity distance for a cipher given known plaintext.
I'm not sure what the unicity distances of the various versions of the Enigma machine were. Given that they were improved Hagelin machines, which I've found references claiming had unicity distance of 1000-2000 characters (~5000-10000 bits), I'm pretty sure that 4000 bits is too low, but it's certainly within an order of magnitude.
And, yes, the one-time pad, assuming the pad is unpredictable and uniformly distributed, and is never reused, has no unicity distance (or an infinite unicity distance, depending on how you want to look at it).
Those that just can't behave, you ask to leave, because whatever their technical ability may be, there are others who are better and know how to act like grownups, at least most of the time.
So, you have another Linus Torwalds hidden away that is better at making kernels _and_ is always unfailingly polite? Impressive!
I work with many people who are of the same caliber as Linus, or better. They just didn't happen to start an open source project which was in the right place at the right time. There's no arguing that Linus isn't good... if he weren't, his project would have been taken away from him long ago (and he wouldn't have repeated his success, though git's popularity largely leveraged Linus' and Linux' prior popularity), but that's not because he's some uniquely amazing programmer or technical manager (which is a better description of his role today).
In point of fact, I suspect that Jeff Dean is a significantly better engineer than Linus, and he is unfailingly polite. Further, there are many key kernel maintainers who are very nice people. Yes, Linus did famously call Greg Kroah-Hartman a "doormat for patches"... but Linus also keeps tagging him in critical roles, operating completely unsupervised by Linus, so apparently he doesn't really believe that.
Also, I think Linus' bombastic style is overstated. It's actually not at all common that he violates the rules defined by the Go code of conduct. He very rarely attacks people personally. Take the other article regarding his complaints about a particularly nasty bit of integer overflow testing code... he ranted about the code itself, but never called the author of the code any names. I have little doubt that if a young, unknown Linus Torvalds were to join the Go community today, he might get pulled aside a time or two, but he'd adapt just fine and be just as productive as he is in his unchecked Linux dictator persona.
the houses are too far apart, the driveways are too long, and rich people tend to be stingy, because, hey, thats how they got to be rich
When I was a kid I wanted to go to the rich houses, because they gave the best stuff. Many of them gave full-sized candy bars, rather than the miniatures (except for the dentists; they handed out toothbrushes). However, there was the time factor. The best solution was to go to the rich neighborhood and ride your bike. Doing that, I was generally able to fill a pillow case every Halloween.
His reasoning: the compiler could have a bug and this way you would catch that bug.
Well, I'll give him one thing: Any compiler that accepts this code without at least giving a warning about dead code does have a bug (unless p is volatile). So it does detect buggy compilers.
There is no need for a friggin' policy just because.5 % of people in coding MLs get childish and unprofessional in a post or two every odd year!!
No, but there is a need because 0.01% are childish and unprofessional all the time. Any sufficiently-large community will eventually attract some jerks. You can shout them down, sometimes, but it's a distraction and doesn't always work. Better just to correct them quietly. Those that just can't behave, you ask to leave, because whatever their technical ability may be, there are others who are better and know how to act like grownups, at least most of the time.
Yep... Up to "a permanent or temporary ban from some or all Go spaces". Thanks for your five years of contributions, but you made the wrong person look bad without even realizing it - See ya, better luck next career!
Do you have any evidence of this sort of abuse? Any? At all?
Didn't think so.
Your argument is essentially a slippery slope fallacy. If we don't allow absolutely anything, then we'll end up allowing nothing of substance. There are many, many productive well-moderated communities in the world that beg to differ. In fact, most real-life communities, because people generally don't act like jerks in real life like they do on line. I think it's the ever-present sub-rosa threat of a punch in the face, myself, but whatever the reason people are much better at behaving face to face. However, it is completely possible to apply rules of decent social behavior in online communities. It just requires a little effort, and a willingness to eject those who can't behave.
I have worked with a few prima donna assholes who couldn't behave in real life, note, and I have absolutely zero problem with ejecting them from the workplace, either. I don't care how good they are, there's no way they're good enough to justify everyone else putting up with their crap. And if that means they have a hard time finding a job, well, maybe they should rethink their attitude.
If you want pablum, stick to Farmville. If you want to join us in the coding trenches, wear asbestos underwear.
Bullshit. It's perfectly possible to have aggressive, heated disagreements without calling people names. In fact, they tend to be more productive.
"t Adults can say that's stupid or you're a moron as part of normal healthy discourse it's intent that matters. Healthy razzing friendly banter etc etc is part of normal adult communication."
Among friends yes it can be. In a working group of developers without any face to face social interaction no. At that point it is just harassment.
+1
I don't see anything wrong with the code of conduct, regardless of the extremely slanted summary.
It may come as a shock to some here, but it is actually possible to have a discussion, even a heated disagreement, without calling people names. And, you know what? It's actually both more pleasant and more effective! Rather than saying that a person who tossed out a dumb idea is a moron, you just call the dumb idea a dumb idea. It's not hard at all, just focus your criticism on the ideas, or code, or whatever, rather than on the people. This still means that people need to be able to take criticism, because when you say someone's code is shit, they may struggle not to take it as a personal affront... but when you call someone a moron it's impossible not to take it as a personal affront. Because it is!
It's certainly true that among groups of friends it's possible, and even fun, to use personal attacks. Everyone knows there's nothing in it, that we're all friends. But that's not the case on a public mailing list, with a random group of semi-strangers.
Look, I often defend Linus Torvalds' occasional aggressive outbursts. I think it's fine that he's blunt and outspoken. I also think he could be equally blunt and outspoken without calling people names. But it's his community, and he can run it the way he wants to. If people don't like it, they can create their own Linux kernel community, and fork.
The Go community is apparently trying to be a friendlier place from the outset and that is also perfectly fine, in fact I think it's better. Okay, so the banhammer could be used to exclude valuable contributors, rather than trolls, but is there any evidence it is or has been used that way? There is not. Go look. The rules are applied sensibly, and enforcement almost never has to go beyond a private message.
Yeah, long-term this is gonna be required. As automation takes over more and more jobs eventually it'll be nearly impossible to keep employment up.
Maybe.
The same was said during the industrial revolution, and again in the mid-20th century. It's possible that this time really is different, but it's also possible that yet again we'll discover a lot of new things that need to be done, a large number of new jobs that had never previously existed. One thing certainly is different this time, though, and that's the rate of change. Change is much faster, but people don't adapt that much more quickly. I think they do adapt faster than in prior centuries, but not enough.
We have been instructed not to create a record of our communication with you. We realize that this record could be used against in court or in public. Phone calls are less likely to be used against us in court or in public.
Except that most customer service calls are recorded "for quality assurance". Which means the recordings could be compelled during discovery anyway. I suppose it's more work to find them.
The problem isn't the system, it is the software and databases that require millisecond accuracy.
Many systems can be implemented without time synchronization, and many systems that rely on it don't need to. But there are classes of distributed problems that cannot be solved, or cannot be solved as efficiently, without a sufficiently-accurate shared reference time.
Google has an interesting solution to this problem, first implemented in 2008, called the "leap smear". Over a 20-hour window centered on the leap second addition, the servers' clocks are skewed slightly slower so that for each second of real time that passes the clocks advance by 14 microseconds less than a full second. So time remains monotonically-increasing, with no jumps. It's just slightly out of agreement with the rest of the world for 20 hours. It's furthest out of agreement at the moment the leap second is inserted, when it goes from 500 ms slow to 500 ms fast, then it drifts back into alignment.
My understanding is that presently Google cars won't self drive outside of specially mapped areas.
Presently, this is true. But it's not crucial to the system design. It's not part of the approach, just part of the current testing plan.
Also, as another commenter pointed out, mapping the whole world isn't as unreasonable as all that. Cars would still have to be able to deal with it when stuff changes (as they do now; even in the limited test areas changes happen faster than updates, and the cars do fine anyway), but that could be the exception-handling case, in which case the car would simply become a little more cautious to deal with the fact that it has less information.
Finally, consider that an army of self-driving cars uploading details of the regions they cover is an awesome street-mapping system.
So: your assumption isn't correct, and it wouldn't be an insuperable challenge even if it were.
Slashdot Mirror
Large tech companies -- including Google -- have exited countries before over repressive laws; The "someone will build it" argument therefore rings hollow.
You think Samsung, LG, HTC, etc. would refuse to sell devices in the UK if Google didn't provide what was required? I think you're forgetting that Android is open source.
There are dozens of suggestions in response to your first post, but the most common suggestion is the one that I think is the most obvious: don't participate in adding backdoors to encryption software.
The rationalization that somebody else will inevitably do some "bad thing" (and maybe do a poor job of it) doesn't make it ethical for you to do that "bad thing".
So, option 1.
Honestly, my response is *not* a convenient rationalization. Perhaps it would be for an iOS engineer, but Android is open source.
Let's suppose that Google simply refused. What would happen? Would Samsung, HTC, LG, etc. simply say "Oh, okay, well, I guess we can't sell our devices in the UK. Darn." Absolutely not. They'd add a backdoor and sell lots of devices, and there isn't a thing Google could do about it. How well would they do at keeping the backdoor as absolutely narrow as possible? Recall that one of the major vendors was found to be storing fingerprints in cleartext, world-readable. That's not atypical.
Given that, what would Google's refusal accomplish? I suppose I personally could feel better about myself for having refused, but not much better, since it would actually have made the world worse.
You are responsible for your own actions and not the assumed actions of others.
Bullshit. If you know that your decision to do (or not do) X will result in some bad outcome Y, it's nothing but a cop out to say that because you didn't yourself do Y that you are not responsible for it. If you could have prevented it, or at least made it less bad, and you didn't, then you are responsible. This means that if the actions of others are clearly and easily predictable then it's unethical to ignore them in your calculation of what action you yourself should take.
Upload rates to my Google Drive on the same computer can saturate my local upstream, 30 times faster than OneDrive.
Heh. The common complaint about Google Drive used to be the opposite. Whatever your connection was, Drive would saturate it to the point that nothing else worked. You can now set rate limits.
What microsoft doesnt understand is that Google does not operate in the traditional weasle-word sense of "enterprise grade." while youre purchasing shiny new netapps, theyre using off the shelf commodity hard drives modelled by their own statisticians to predict failure. they dont repair arrays or disks, they dont have to worry about memory failures. anything that dies gets chucked, replaced, reprovisioned, and brought back into the fold as if nothing ever happened.
Do you really think MS isn't using the same commodity hardware approach? That seems very ulikely to me. Beyond a certain scale it's the only reasonable way to approach the problem. You can't rely on even the most "enterprisey" of enterprise hardware to be sufficiently reliable because even with MTBF measured in millions of hours, when you have hundreds of thousands of drives they're going to be failing left and right. So you have to architect systems with plenty of redundancy and completely automatic failover and recovery. And once you have that infrastructure in place, there's no point in paying the enterprise prices. Instead, you buy commodity drives by the truckload.
Someone earlier said that the original contracts were for up to four years. If changing terms like that within the span of the contract *isn't* illegal, then it should be.
Unilaterally changing the terms of a contract is illegal, unless the contract contains language allowing the change, and maybe not even then. The more likely case is that the "someone" who said the contracts were for four years was wrong, or that only some contracts were that long, in which case MS will undoubtedly honor the terms of the long contracts until they expires.
Really, the odds that MS is trying to illegally modify a contract are vanishingly small. They aren't that dumb.
Ethics is about choices between alternatives, it's not unethical to do a bad thing if all of the other alternatives are worse.
You've artificially narrowed the alternatives so that you can rationalize choosing an unethical one. Even choice #1, refusing to do the bad thing, was artificially constrained so that it could be dismissed out of hand.
Okay, what are the other effective alternatives? Note that I'm assuming effective enforcement, so sneaking in a non-backdoored system isn't feasible.
Nice Godwinning.
Besides the option to withdraw from the UK market in protest (coordinating this with Apple would be highly effective, I think)
Assuming the UK government doesn't cave, that's equivalent to options 1 and/or 3. Because someone will build devices for that market that do comply... and may not do nearly as good a job of limiting the risk of the backdoor.
you could also make your security protocols modular, so users can freely download stronger FOSS versions.
Sure, but you still have the problem that hardly anyone would do it.
Not in the scenario you described. Take as a given that laws mandating crypto backdoors are unethical. Then Google would be unethical for adhering to those laws
As opposed to building systems without any security, or as opposed to not building systems at all? Ethics is about choices between alternatives, it's not unethical to do a bad thing if all of the other alternatives are worse.
Yeah, Kahn's Codebreakers covers this in some detail. The allies actually did a lot of things to generate cribs (bits of known plaintext). Cool stuff.
Don't forget option 4 - refuse to work for such an unethical organization and find more honest work.
Mu.
Google is a highly ethical organization. That you don't think so is due to your own ignorance, not the organization.
I work for Google. I build strong encryption in Android. The possibility of laws mandating back doors creates an interesting dilemma for me. Supposing such a law were to exist, and were effectively enforced so there's no possibility of sneaking in a non-backdoored system, what would I do?
I see three options.
1. I could run away from the problem, changing jobs to let someone else deal with it.
2. I could accede, trying to build the tightest, narrowest, best-controlled backdoor possible, doing my best to ensure that only authorized government agencies could use it.
3. I could refuse to build strong security systems at all, making it clear to everyone that their data is unprotected.
What's the right thing to do? #1 is out, unless I have some reason to believe that someone else could make better decisions. #3 has some nose-thumbing appeal, but it means that everyone's data is accessible not only to government agencies, but to thieves, family members, spouses, etc. Also, this may be equivalent to #1, in that I'll be shuffled to another job and replaced by someone willing to build back doors.
So, frankly, it's actually not much of a dilemma at all. I would do #2 (choice of number was not accidental). Well, and I'd probably also contribute to open source, possibly underground strong crypto implementations in my free time, because I strongly believe that the ability of people to keep secrets is critical to individual freedom and to societal progress. But such systems would only be used by a handful, seriously reducing their value.
It's really, really important that we fight this sort of thing in the public, though. I've never been asked to build in back doors, and I never want to be.
Oh, and by the way: Those of you out there who complain that you don't want full device encryption because it's slow? The slowness may be annoying, but it's well worth it. Not so much to you, now, but to everyone, in the future. Have a little patience with it. It will get faster over time as hardware gets faster and perhaps dedicated encryption hardware is added, but if we don't get it in now, setting the precedent that it's normal to encrypt everything, all the time, with the strongest crypto we can find and no back doors, there's a much greater risk that we may not be allowed to do it later.
Untrue. Encryption may be "Information-Theoretically secure". These cannot be broken with just enough computing power. For example, for ordinary text, this is even true for the venerable Enigma if less than 4000 Bits (if I remember things correctly) of ciphertext are available and the key was chosen at random.
This notion is what Shannon called "unicity distance". Assuming arbitrary computing power, so that brute force search of the entire keyspace is perfectly feasibly, unicity distance is the amount of ciphertext required to uniquely determine the key in a ciphertext-only attack. The unicity distance of a cipher is dependent on the details of the cipher and of the plaintext, though there's a notion of minimum unicity distance for a cipher given known plaintext.
I'm not sure what the unicity distances of the various versions of the Enigma machine were. Given that they were improved Hagelin machines, which I've found references claiming had unicity distance of 1000-2000 characters (~5000-10000 bits), I'm pretty sure that 4000 bits is too low, but it's certainly within an order of magnitude.
And, yes, the one-time pad, assuming the pad is unpredictable and uniformly distributed, and is never reused, has no unicity distance (or an infinite unicity distance, depending on how you want to look at it).
Those that just can't behave, you ask to leave, because whatever their technical ability may be, there are others who are better and know how to act like grownups, at least most of the time.
So, you have another Linus Torwalds hidden away that is better at making kernels _and_ is always unfailingly polite? Impressive!
I work with many people who are of the same caliber as Linus, or better. They just didn't happen to start an open source project which was in the right place at the right time. There's no arguing that Linus isn't good... if he weren't, his project would have been taken away from him long ago (and he wouldn't have repeated his success, though git's popularity largely leveraged Linus' and Linux' prior popularity), but that's not because he's some uniquely amazing programmer or technical manager (which is a better description of his role today).
In point of fact, I suspect that Jeff Dean is a significantly better engineer than Linus, and he is unfailingly polite. Further, there are many key kernel maintainers who are very nice people. Yes, Linus did famously call Greg Kroah-Hartman a "doormat for patches"... but Linus also keeps tagging him in critical roles, operating completely unsupervised by Linus, so apparently he doesn't really believe that.
Also, I think Linus' bombastic style is overstated. It's actually not at all common that he violates the rules defined by the Go code of conduct. He very rarely attacks people personally. Take the other article regarding his complaints about a particularly nasty bit of integer overflow testing code... he ranted about the code itself, but never called the author of the code any names. I have little doubt that if a young, unknown Linus Torvalds were to join the Go community today, he might get pulled aside a time or two, but he'd adapt just fine and be just as productive as he is in his unchecked Linux dictator persona.
p doesn't have to be volatile here, only the possibility of it changing in the first block!
No, if the first block is executed, neither of the others will be, regardless of what happens in that block.
the houses are too far apart, the driveways are too long, and rich people tend to be stingy, because, hey, thats how they got to be rich
When I was a kid I wanted to go to the rich houses, because they gave the best stuff. Many of them gave full-sized candy bars, rather than the miniatures (except for the dentists; they handed out toothbrushes). However, there was the time factor. The best solution was to go to the rich neighborhood and ride your bike. Doing that, I was generally able to fill a pillow case every Halloween.
His reasoning: the compiler could have a bug and this way you would catch that bug.
Well, I'll give him one thing: Any compiler that accepts this code without at least giving a warning about dead code does have a bug (unless p is volatile). So it does detect buggy compilers.
There is no need for a friggin' policy just because .5 % of people in coding MLs get childish and unprofessional in a post or two every odd year!!
No, but there is a need because 0.01% are childish and unprofessional all the time. Any sufficiently-large community will eventually attract some jerks. You can shout them down, sometimes, but it's a distraction and doesn't always work. Better just to correct them quietly. Those that just can't behave, you ask to leave, because whatever their technical ability may be, there are others who are better and know how to act like grownups, at least most of the time.
Yep... Up to "a permanent or temporary ban from some or all Go spaces". Thanks for your five years of contributions, but you made the wrong person look bad without even realizing it - See ya, better luck next career!
Do you have any evidence of this sort of abuse? Any? At all?
Didn't think so.
Your argument is essentially a slippery slope fallacy. If we don't allow absolutely anything, then we'll end up allowing nothing of substance. There are many, many productive well-moderated communities in the world that beg to differ. In fact, most real-life communities, because people generally don't act like jerks in real life like they do on line. I think it's the ever-present sub-rosa threat of a punch in the face, myself, but whatever the reason people are much better at behaving face to face. However, it is completely possible to apply rules of decent social behavior in online communities. It just requires a little effort, and a willingness to eject those who can't behave.
I have worked with a few prima donna assholes who couldn't behave in real life, note, and I have absolutely zero problem with ejecting them from the workplace, either. I don't care how good they are, there's no way they're good enough to justify everyone else putting up with their crap. And if that means they have a hard time finding a job, well, maybe they should rethink their attitude.
If you want pablum, stick to Farmville. If you want to join us in the coding trenches, wear asbestos underwear.
Bullshit. It's perfectly possible to have aggressive, heated disagreements without calling people names. In fact, they tend to be more productive.
"t Adults can say that's stupid or you're a moron as part of normal healthy discourse it's intent that matters. Healthy razzing friendly banter etc etc is part of normal adult communication." Among friends yes it can be. In a working group of developers without any face to face social interaction no. At that point it is just harassment.
+1
I don't see anything wrong with the code of conduct, regardless of the extremely slanted summary.
It may come as a shock to some here, but it is actually possible to have a discussion, even a heated disagreement, without calling people names. And, you know what? It's actually both more pleasant and more effective! Rather than saying that a person who tossed out a dumb idea is a moron, you just call the dumb idea a dumb idea. It's not hard at all, just focus your criticism on the ideas, or code, or whatever, rather than on the people. This still means that people need to be able to take criticism, because when you say someone's code is shit, they may struggle not to take it as a personal affront... but when you call someone a moron it's impossible not to take it as a personal affront. Because it is!
It's certainly true that among groups of friends it's possible, and even fun, to use personal attacks. Everyone knows there's nothing in it, that we're all friends. But that's not the case on a public mailing list, with a random group of semi-strangers.
Look, I often defend Linus Torvalds' occasional aggressive outbursts. I think it's fine that he's blunt and outspoken. I also think he could be equally blunt and outspoken without calling people names. But it's his community, and he can run it the way he wants to. If people don't like it, they can create their own Linux kernel community, and fork.
The Go community is apparently trying to be a friendlier place from the outset and that is also perfectly fine, in fact I think it's better. Okay, so the banhammer could be used to exclude valuable contributors, rather than trolls, but is there any evidence it is or has been used that way? There is not. Go look. The rules are applied sensibly, and enforcement almost never has to go beyond a private message.
This is a good thing.
Yeah, long-term this is gonna be required. As automation takes over more and more jobs eventually it'll be nearly impossible to keep employment up.
Maybe.
The same was said during the industrial revolution, and again in the mid-20th century. It's possible that this time really is different, but it's also possible that yet again we'll discover a lot of new things that need to be done, a large number of new jobs that had never previously existed. One thing certainly is different this time, though, and that's the rate of change. Change is much faster, but people don't adapt that much more quickly. I think they do adapt faster than in prior centuries, but not enough.
We have been instructed not to create a record of our communication with you. We realize that this record could be used against in court or in public. Phone calls are less likely to be used against us in court or in public.
Except that most customer service calls are recorded "for quality assurance". Which means the recordings could be compelled during discovery anyway. I suppose it's more work to find them.
http://www.theguardian.com/tec...
The problem isn't the system, it is the software and databases that require millisecond accuracy.
Many systems can be implemented without time synchronization, and many systems that rely on it don't need to. But there are classes of distributed problems that cannot be solved, or cannot be solved as efficiently, without a sufficiently-accurate shared reference time.
Google has an interesting solution to this problem, first implemented in 2008, called the "leap smear". Over a 20-hour window centered on the leap second addition, the servers' clocks are skewed slightly slower so that for each second of real time that passes the clocks advance by 14 microseconds less than a full second. So time remains monotonically-increasing, with no jumps. It's just slightly out of agreement with the rest of the world for 20 hours. It's furthest out of agreement at the moment the leap second is inserted, when it goes from 500 ms slow to 500 ms fast, then it drifts back into alignment.
My understanding is that presently Google cars won't self drive outside of specially mapped areas.
Presently, this is true. But it's not crucial to the system design. It's not part of the approach, just part of the current testing plan.
Also, as another commenter pointed out, mapping the whole world isn't as unreasonable as all that. Cars would still have to be able to deal with it when stuff changes (as they do now; even in the limited test areas changes happen faster than updates, and the cars do fine anyway), but that could be the exception-handling case, in which case the car would simply become a little more cautious to deal with the fact that it has less information.
Finally, consider that an army of self-driving cars uploading details of the regions they cover is an awesome street-mapping system.
So: your assumption isn't correct, and it wouldn't be an insuperable challenge even if it were.