So you don't so much disagree with "sustained disruption of discussion" being forbidden, you just don't like that there's an overarching committee deciding what constitutes "sustained disruption of discussion" instead of individual technical leads?
Seems like it would be helpful to have an authoritative body so as to enforce the rules evenly across teams. Guards against there being a rogue technical lead who allows "sustained disruption of discussion" by his favored subordinates but not others. If there's no body one can appeal to with authority over the technical leads, what would one's recourse be in that situation?
A second person says, "*hugs*" as an expression of sympathy in response. That second person is now on warning for violating community standards.
I suspect that would not be the case. That portion of the policy was badly written. The fact that it includes "or after a request to stop" is instructive. If the first part of that sentence were intended to mean that any "hugs" without prior express consent was a violation, then the "or after a request to stop" would be completely unnecessary. One "hugs" probably doesn't get you in trouble. Doing it after someone asks you to stop almost surely does, and probably should. I agree they should rewrite that sentence to be more precise.
Problem with "Don't be a dick" is in the details. How to decide if someone is a dick? Through a vote? What triggers a vote? Who gets to vote? What % need to agree for someone to be labeled a dick? Is there a system of appeals? Does being a dick result in immediate expulsion, or do you get put on probation? Etc.
If we're using a vote, I can imagine some communities that would label people "dicks" for things one might not think should warrant that label. For instance, imagine someone whose email signature is "Make America Great Again". It's not hard to imagine a community that would regard that as a priori evidence of "being a dick". That's why there's some incentive on the part of organizations to enumerate exactly which behaviors qualify one as a dick.
I've found that workplaces without codes of conduct quickly become toxic. Or, if not an explicit code, the understanding that certain behavior is unacceptable. What the code does is spell it out so that there's no confusion. It also protects the organization when they need to dismiss someone for inappropriate behavior. They can point to the specific part of the code that was violated. Without a code in place, the person could argue he was wrongfully dismissed.
...which one of the things it bans do you think should be allowed?
Reading through it, it seems pretty reasonable. If I were leading a team, I would not want someone on that team who would treat other team members in any of the ways this policy bans. Seems like it could be summed up as "Don't be a creep or an asshole."
How am I ignoring the facts? The numbers you cited for Dallas County indicate white residents voted exactly as I described: "somewhat red" or "purple, leaning toward red". White people, in general, skew red. The ones that live in cities less so, but "red" still outweighs "blue" most places, even if only slightly. The reason you get cities like Dallas, Houston, and Austin going blue in deeply red Texas is a combination of 1. brown people, who are overwhelmingly blue, and 2. white people being only 60/40 red/blue instead of 80/20 like they are in rural settings.
For example, Dallas county is 67% white [census.gov] and went for Clinton 61/35 - obviously the 33% of the population that is non-white was not enough to get 67% of the vote.
Granted. Urban white populations in Texas (and presumably other red states) are not "deeply red". Replace that with "somewhat red" or possibly "purple, leaning towards red".
No doubt the set of white people willing to live and work in an urban environment where there are brown people is self-selected to skew blue. But having a much higher concentration of non-white voters who skew blue doesn't hurt either. I can't vouch for the accuracy of this map, but, if accurate, then the only city in Texas where the whites voted Blue was Austin. Dallas and Houston, then, which went to Clinton, must have done so because of the brown vote.
Your taxes will go up to bring in Amazon, and that gets you... what?
They may not go up as much as you think. Will have to build new schools and roads, but Amazon employees and their housing arrangements will broaden the tax base. Will also increase demand for housing, which will drive up appraised values, which further mitigates the need to raise rates. Now, you're still paying more when your appraisal goes up, but usually that reflects an increase in the actual market value. So Amazon arriving means my house is suddenly worth more. It also means the market for tech workers will tighten up, which will increase salaries disproportionately in that one industry. Since I work in tech, that's good for me.
Cities are blue, even in Texas. Mainly because that's where the brown people live. Suburbs are red. Slightly less red than the hinterlands because the populace is generally more educated, but still deeply red.
Seems like anyone who owned property pre-Amazon would benefit. You pay more in property tax as the value goes up, but it's also worth more. Also anyone working in tech or engineering prior to Amazon's arrival.
By your logic, Seattle would benefit if every employer left town whose "product" is not directly tied to Seattle residents and whose workforce is disproportionately high-income. So, like, Detroit.
With all of the geniuses on Slashdot, it's hard to understand why they aren't the most wealthy people in the world, and pikers like Buffet need to be schooled by them.
Yeah, you would think with all that financial savvy they wouldn't be concerned about age discrimination and Indians taking their IT jobs.
For one, in the system I proposed the committee would only be able to choose from a small number of algorithmically drawn maps that should, in theory, be non-partisan. So, their ability to form "agreements" like the one alleged in California would be somewhat limited. With respect to "non-partisan" vs. "50/50" my underlying assumption is that nobody is truly non-partisan and the best you can do is a committee where partisans on each side are equally represented.
The ideal situation is one in which none of the algorithmically generated maps is obviously preferable to one party or the other. Allow me to change the voting process to this instead:
1. Committee members are chosen in such a way that each member's partisan bias is well known.
2. Each partisan bloc has an odd number of members.
3. A first vote is taken in which each set of partisans, independently, votes on the map they'd like to see stricken from contention. Each group's winning map is stricken from contention. If there is only one map remaining, then that map is chosen as the official map. If there is more than one map remaining, then repeat step #3. If there are two maps remaining and both are slated to be stricken from contention, choose one at random from those two and it becomes the official map.
If it were automated we'd still be arguing over the algorithm to use, what inputs it should have, etc.
I'd like to see a system that features some small number of competing algorithms, each of which must draw districts without using partisan voting patterns as an input, or any other trait that correlates strongly with partisan voting patterns (e.g. race). Maybe three different algorithms. During redistricting, each algorithm is applied to produce a map. Then a 50/50 bipartisan committee of human beings votes on which one to use. I would have the committee using the following process to select map:
1. Each committee member voters for the map they prefer. If the vote is not a tie, then that map is selected.
2. If the vote in #1 is a tie, then there is another vote where each committee member votes for the map he or she least prefers. If this vote is not a tie, then that map is eliminated from contention and the process is repeated from #1 above.
3. If the vote in #2 is a tie, then a map is chosen at random from the set of maps that are still in contention.
Might kill Amazon's business model, but start charging a small, flat fee per order regardless of order size. Including for Prime customers. I know my wife will order something on Monday and something else on Tuesday when she could theoretically have combined those two purchases into a single order. Charging a per-order fee might encourage people to time-shift some of their purchases to consolidate them into a single order.
Strange that the two benchmarks mentioned are "enterprise performance" and "boot speed". If you care about the former you probably don't care about the latter, and vice versa.
I'm going through this at work, where we've deployed a product by Vormetric to provide at-rest encryption for a large production PostgreSQL database. IMO it's very security-as-theater. Essentially we're spending all this money and effort so we can say "yes" when larger customers (and auditors) ask if we encrypt at rest. All this does is prevent non-authorized system users from accessing the Postgres data files on the server where it lives. File permissions largely accomplish that already, since the files aren't world-readable and are owned by the postgres user. So an attacker with shell access to the database server would still need to promote himself to root. If he can do that, then Vormetric doesn't help, since at that point he can just become postgres and access the files.
Moreover, the individual pushing Vormetric hasn't made much effort to secure the credentials used by our application (and developers) to access Postgres. For instance, the application accesses it using a role that has super-admin rights (i.e. "drop database"). The few engineers that have access to the production database also use this same role, so they also have super-admin rights. The password for this role is deployed various places in configuration files though, thankfully, not in source control. But suffice it to say it's more widely distributed than it ought to be. And if you have that password it doesn't matter whether the data is encrypted at rest because you can connect to Postgres and just dump a copy of the database that way.
Slashdot Mirror
So you don't so much disagree with "sustained disruption of discussion" being forbidden, you just don't like that there's an overarching committee deciding what constitutes "sustained disruption of discussion" instead of individual technical leads?
Seems like it would be helpful to have an authoritative body so as to enforce the rules evenly across teams. Guards against there being a rogue technical lead who allows "sustained disruption of discussion" by his favored subordinates but not others. If there's no body one can appeal to with authority over the technical leads, what would one's recourse be in that situation?
I suspect that would not be the case. That portion of the policy was badly written. The fact that it includes "or after a request to stop" is instructive. If the first part of that sentence were intended to mean that any "hugs" without prior express consent was a violation, then the "or after a request to stop" would be completely unnecessary. One "hugs" probably doesn't get you in trouble. Doing it after someone asks you to stop almost surely does, and probably should. I agree they should rewrite that sentence to be more precise.
Problem with "Don't be a dick" is in the details. How to decide if someone is a dick? Through a vote? What triggers a vote? Who gets to vote? What % need to agree for someone to be labeled a dick? Is there a system of appeals? Does being a dick result in immediate expulsion, or do you get put on probation? Etc.
If we're using a vote, I can imagine some communities that would label people "dicks" for things one might not think should warrant that label. For instance, imagine someone whose email signature is "Make America Great Again". It's not hard to imagine a community that would regard that as a priori evidence of "being a dick". That's why there's some incentive on the part of organizations to enumerate exactly which behaviors qualify one as a dick.
I've found that workplaces without codes of conduct quickly become toxic. Or, if not an explicit code, the understanding that certain behavior is unacceptable. What the code does is spell it out so that there's no confusion. It also protects the organization when they need to dismiss someone for inappropriate behavior. They can point to the specific part of the code that was violated. Without a code in place, the person could argue he was wrongfully dismissed.
...which one of the things it bans do you think should be allowed?
Reading through it, it seems pretty reasonable. If I were leading a team, I would not want someone on that team who would treat other team members in any of the ways this policy bans. Seems like it could be summed up as "Don't be a creep or an asshole."
She plays Learned League, and is a damn sight better at it than I am.
How am I ignoring the facts? The numbers you cited for Dallas County indicate white residents voted exactly as I described: "somewhat red" or "purple, leaning toward red". White people, in general, skew red. The ones that live in cities less so, but "red" still outweighs "blue" most places, even if only slightly. The reason you get cities like Dallas, Houston, and Austin going blue in deeply red Texas is a combination of 1. brown people, who are overwhelmingly blue, and 2. white people being only 60/40 red/blue instead of 80/20 like they are in rural settings.
Granted. Urban white populations in Texas (and presumably other red states) are not "deeply red". Replace that with "somewhat red" or possibly "purple, leaning towards red".
Leave town. If enough do, they'll have to pay more.
No doubt the set of white people willing to live and work in an urban environment where there are brown people is self-selected to skew blue. But having a much higher concentration of non-white voters who skew blue doesn't hurt either. I can't vouch for the accuracy of this map, but, if accurate, then the only city in Texas where the whites voted Blue was Austin. Dallas and Houston, then, which went to Clinton, must have done so because of the brown vote.
They may not go up as much as you think. Will have to build new schools and roads, but Amazon employees and their housing arrangements will broaden the tax base. Will also increase demand for housing, which will drive up appraised values, which further mitigates the need to raise rates. Now, you're still paying more when your appraisal goes up, but usually that reflects an increase in the actual market value. So Amazon arriving means my house is suddenly worth more. It also means the market for tech workers will tighten up, which will increase salaries disproportionately in that one industry. Since I work in tech, that's good for me.
Cities are blue, even in Texas. Mainly because that's where the brown people live. Suburbs are red. Slightly less red than the hinterlands because the populace is generally more educated, but still deeply red.
Seems like anyone who owned property pre-Amazon would benefit. You pay more in property tax as the value goes up, but it's also worth more. Also anyone working in tech or engineering prior to Amazon's arrival.
By your logic, Seattle would benefit if every employer left town whose "product" is not directly tied to Seattle residents and whose workforce is disproportionately high-income. So, like, Detroit.
My money's on one of these: Austin, Boston, Denver, New York City, Northern Virginia, Toronto, Washington D.C.
Yeah, you would think with all that financial savvy they wouldn't be concerned about age discrimination and Indians taking their IT jobs.
For one, in the system I proposed the committee would only be able to choose from a small number of algorithmically drawn maps that should, in theory, be non-partisan. So, their ability to form "agreements" like the one alleged in California would be somewhat limited. With respect to "non-partisan" vs. "50/50" my underlying assumption is that nobody is truly non-partisan and the best you can do is a committee where partisans on each side are equally represented.
The ideal situation is one in which none of the algorithmically generated maps is obviously preferable to one party or the other. Allow me to change the voting process to this instead:
1. Committee members are chosen in such a way that each member's partisan bias is well known.
2. Each partisan bloc has an odd number of members.
3. A first vote is taken in which each set of partisans, independently, votes on the map they'd like to see stricken from contention. Each group's winning map is stricken from contention. If there is only one map remaining, then that map is chosen as the official map. If there is more than one map remaining, then repeat step #3. If there are two maps remaining and both are slated to be stricken from contention, choose one at random from those two and it becomes the official map.
Each district is electing its own representative.
If it were automated we'd still be arguing over the algorithm to use, what inputs it should have, etc.
I'd like to see a system that features some small number of competing algorithms, each of which must draw districts without using partisan voting patterns as an input, or any other trait that correlates strongly with partisan voting patterns (e.g. race). Maybe three different algorithms. During redistricting, each algorithm is applied to produce a map. Then a 50/50 bipartisan committee of human beings votes on which one to use. I would have the committee using the following process to select map:
1. Each committee member voters for the map they prefer. If the vote is not a tie, then that map is selected.
2. If the vote in #1 is a tie, then there is another vote where each committee member votes for the map he or she least prefers. If this vote is not a tie, then that map is eliminated from contention and the process is repeated from #1 above.
3. If the vote in #2 is a tie, then a map is chosen at random from the set of maps that are still in contention.
Should we expect a corresponding performance hit?
Might kill Amazon's business model, but start charging a small, flat fee per order regardless of order size. Including for Prime customers. I know my wife will order something on Monday and something else on Tuesday when she could theoretically have combined those two purchases into a single order. Charging a per-order fee might encourage people to time-shift some of their purchases to consolidate them into a single order.
Strange that the two benchmarks mentioned are "enterprise performance" and "boot speed". If you care about the former you probably don't care about the latter, and vice versa.
Seems pretty easy to thwart facial recognition. More concerning is the fact that most of us carry around a homing beacon in our front pocket.
I'm going through this at work, where we've deployed a product by Vormetric to provide at-rest encryption for a large production PostgreSQL database. IMO it's very security-as-theater. Essentially we're spending all this money and effort so we can say "yes" when larger customers (and auditors) ask if we encrypt at rest. All this does is prevent non-authorized system users from accessing the Postgres data files on the server where it lives. File permissions largely accomplish that already, since the files aren't world-readable and are owned by the postgres user. So an attacker with shell access to the database server would still need to promote himself to root. If he can do that, then Vormetric doesn't help, since at that point he can just become postgres and access the files.
Moreover, the individual pushing Vormetric hasn't made much effort to secure the credentials used by our application (and developers) to access Postgres. For instance, the application accesses it using a role that has super-admin rights (i.e. "drop database"). The few engineers that have access to the production database also use this same role, so they also have super-admin rights. The password for this role is deployed various places in configuration files though, thankfully, not in source control. But suffice it to say it's more widely distributed than it ought to be. And if you have that password it doesn't matter whether the data is encrypted at rest because you can connect to Postgres and just dump a copy of the database that way.
Expose it in plain text, that is.
Doesn't so much matter if it's encrypted at rest if you expose it publicly via an insecure website or API, right?