If you are using Netplan (the default in 18.04), check out this example:
https://netplan.io/examples#co...

It was withdrawn because proposal F came later and replaced it.

I don't have one, but when I looked at them before, Amazon said it won't place a second order until the first order is delivered. Also, you get a notification of the order, so you also have the option to cancel it.

I can see the point of locking social accounts so nothing new can be posted, but why go to all this work to try to erase all mentions of the person?

The only case the article really mentions is "spent convictions". Surely the mention of a conviction is more harmful to a person while they're living than once they're dead, so if they didn't try to get it removed while alive, what's the point?

In terms of the exception to the "outing" rule, I was assuming that the person being outed was the vulnerable person. I see my error now, and this makes sense.

I agree 100% that it's improper and mean to continue to refer to Samantha as Tom.

I was just pointing out an exception around citations. Imagine Jane Johnson gets married and changes her name to Jane Doe. If I'm writing a paper in APA style, where last names are used in citations, my choices are, "Johnson (2000) found that..." or "Doe found that ... (Johnson, 2000)." or something like "Doe (née Johnson) found that ... (Johnson, 2000)." In no event can I not use "Johnson", because that's the name on the paper. I'm clearly using it deliberately (which runs afoul of the rule), but not maliciously. For more on this, see: http://blog.apastyle.org/apast...

For my case of replying to an old email, I actually struggled with this for several minutes before ultimately deciding to just drop the "On DATE, NAME" bit. I ultimately determined the answer to my own question, so I dropped the email before sending it.

The "claims" rule includes "Knowingly", "harmful", and "false" as conditions. You seemed to have focused primarily on "false". I had proposed dropping "harmful", so that "Knowingly making false claims" was prohibited, regardless of whether they were "harmful". If someone is knowingly making false claims about me, why should I have to show they are harmful? If someone is making false claims knowingly, they by definition have malicious intent. Or, from a different angle, one might argue that a false claim is always harmful, simply because it's false.

Having just read the Code of Conduct, it seem generally fine. Some of my concerns are that the rules are too broad, and some are that they are too narrow.

The "Comments that reinforce systemic oppression related to" wording seems super vague. This portion has the highest potential for abusive use. To be clear, I'm fine with all the protected criteria that come in that rule. I'd much prefer replacing that with "Harassing comments related to"

The "unwelcome comments" thing is pretty broad. If someone says to me on IRC, "I'm tired all the time." and I say, "You should stop eating so much junk food and get some exercise.", I'm now in trouble if they feel that comment is unwelcome. With this rule, the only option for me is to never engage in such a conversation. Is that helpful or harmful to building relationships and living fulfilling lives? I think it's more harmful than helpful. Now, I agree that continually nagging that person to eat healthy is inappropriate. If this was limited to "repeated", "after being asked to stop", or similar, it would be better.

I have some concerns about the "dead" names thing. I get and agree with the point: use the names people pick for themselves. As long as this isn't enforced robotically, it should be fine. There are some legitimate reasons to use names that were in use in times in the past. For example, I think citations to publications should use the name of the author at the time it was published, because the point of the citation is to help you find the publication. For another example, yesterday I was considering replying to a years-old mailing list comment, and quoting some text. The author of the quoted text is trans and has changed names. Am I required to edit the "On DATE, NAME wrote:" line? To be clear, in new text, I would address this person using their new name (and have actually done so).

I personally don't see a problem with person A saying "*hugs*" to person B without (advance) consent. Though, this is situational. If someone says, "Sorry for the delay on this bug, I've been distracted. My dog died.", I see no problem with "Sorry to hear about your dog. *hugs*". On the other hand, something like "You're such a special snowflake. *hugs*" is an improper ad hominem attack. Even in the first example, I do have a problem if they keep doing it after being told by person B to stop, so that rule is fine. On the other hand, saying "*backrub*" out of the blue does seem across the line. I'm struggling to think of an example where that would be unambiguously appropriate.

I'm not sure why the "as necessary to protect vulnerable people from intentional abuse" exception exists to the "outing" rule. Why would it be necessary or acceptable to out someone to protect them?

"Publication of non-harassing private communication without consent." is problematic as a blanket rule. If someone says something important publicly which is materially contradicted by private statements, that might be necessary (albeit tacky) to share, even if those private statements are non-harrassing.

"Knowingly making harmful false claims about a person." I would strike harmful. Why is it necessary that the false claims be harmful?

Can you point to where he suggested "separate but equal"?

It seems to me that he was advocating for equal treatment. Specifically, that the jobs should be changed for everyone. He talked about "pair programming and more collaboration", being less competitive and "allow[ing] those exhibiting cooperative behavior to thrive", etc. None of those suggestions said anything about creating separate roles for women.

He also talked about opening up the gender/race restricted programs to everyone. Assuming such programs exist (and nobody has said they don't), Google currently doesn't even have "separate but equal", but simply "separate".

At that point, it is effectively a ban on sharing. I assume that is what you want. It is what I want, and I am a manager at a small ISP (not in California). We should just enact an outright ban.

This sort of thing was not allowed in telephone, as far as I know. I see no reason it should be different for Internet.

There actually is a way to tell the other side you want TLS. It's called DANE (RFC 7672). It's new and not widely used yet.

Here's a presentation on the topic:
https://www.ietf.org/proceedin...

> allowing operators to reduce cooling and power requirements significantly

This is no joke. We replaced our DMS-10 switches with C15s. In some locations, we had to add heat to buildings that never before needed it.

How about we just use fiber instead?

The problem is: how does the hospital know what you wanted? You're dead, so they have to ask your family.

I believe Minnesota (where I live) recently changed this to make the election on your driver's license (or ID) binding.

Ubuntu separates non-free stuff into restricted and multiverse (as opposed to main and universe).

Main and restricted are the supported packages. Universe and multiverse are unsupported packages. Here, "support" means paid technical support from Canonical and a security update promise (as opposed to best effort) from the Ubuntu developers.

Serious question: Windows has an X server? I have successfully setup third-party Windows X servers with Ubuntu-on-Windows, but there is a first party one?

I do network engineering at an ISP. We are small, though I have discussed these things with my peers at larger networks.

Once you scale above a very small network (like your home connection), allowing congestion isn't really okay in practice, even with QoS. When I say it's not "okay" here, I'm speaking purely technically.

It might be possible to let networks congest somewhat if you had a large amount of elastic traffic that you could reliably identify. Netflix, for example, could meet these criteria. But that's not okay politically; that's an example of why net neutrality is good!

QoS in carrier networks is only useful for priority (de-)queuing of traffic to reduce latency and jitter. For example, real-time voice or video traffic could benefit. This is where it'd be nice to actually be able to honor user traffic markings.

It's not (currently at least) practical to make the decisions on a flow-by-flow basis in the core of the network (which is what your proposal would require). This is a hardware scaling issue. To be clear, tracking flows statistically is okay at scale. ISPs do plenty with NetFlow/sFlow. But taking an incoming packet, assigning it to a flow, and marking it appropriately, for every packet, in real time is the scaling challenge.

The following approach would scale perfectly in trusted CPE (ONT/cable modem) or reasonably well in a DSLAM (for DSL). Give each user (for example) two queues. Honor the incoming DSCP markings. Put a small, but reasonable, limit on the size of the priority queue; overflowing traffic gets remarked and placed into the non-priority queue. Then, honor markings through the rest of the network.

There are a few problems with even this approach. First off, there are going to be users who legitimately create more high priority traffic than any limit that's acceptable across the board. Is it okay to charge them for a higher limit? If not, how do you avoid gaming the system? If yes, won't that incentivize ISPs to set the limit to zero and charging for all priority? Is that okay? If so, what fraction of people will request and pay for priority in that world? Will that be enough to encourage application developers to mark traffic appropriately? Or does this just degrade into our current zero-priority Internet?

Second, this only gets you one direction (upload). To handle the download direction, you'd need to honor priority bits on your upstream and peering links. But there, you can't trust the markings (unless it's a 1:1 peering link and you are guaranteed your peer implements a compatible policy at their incoming edge), at least without policing. Policing the queues there is easy, but gives you terrible results in real life. If the limit is exceeded with traffic that "should not have been" marked priority, it will destroy the prioritization of "legitimate" priority flows by forcing some fraction of their packets into the non-priority queue. If you accept all (or just a high enough fraction of) incoming traffic as priority traffic, then you have destroyed the prioritization yourself. If you try to mark flows per IP/customer, we're back to that scaling problem.

It might be possible to do something that involves tracking flows at the customer edge and using the incoming markings for the downstream direction. But this is only prioritizing in the last mile. At best, this is a lot of work for very little benefit.