Keynote for the GUUG FFG 2015, Stuttgart (Video: FrosCON, deutsche Sprache)

Be authoritative. Tell your readers what they need to know, not what you might ideally like them to know. Tell them also what they need to think about it.

Save your readers time. If you are summarising a file of documents for them, you do not need to give them the experience of reading it themselves. Don’t use a piece of writing as a dumping ground for evidence; use the evidence sparingly to illustrate your argument.

Pick your battles. You may need to prove some points laboriously, especially if the ground is controversial. But you can’t do this across the board. Work out where a blow-by-blow account is necessary and where a simple allusion will suffice.

Don’t include details just because they are fun or interesting. If they don’t serve your argument or your story, they should go.

Observe the 5% rule. Any text, whether it’s a 1,000-page novel or a tweet, can be reduced by 5% without serious sacrifice of meaning. In fact, the true percentage is probably higher …

That’s fundamentally all that the STUN protocol is: your machine sends a “what’s my endpoint from your point of view?” request to a STUN server, and the server replies with “here’s the ip:port that I saw your UDP packet coming from.”

For example, we’ve observed that the UC Berkeley guest WiFi blocks all outbound UDP except for DNS traffic. No amount of clever NAT tricks is going to get around the firewall eating your packets. So, we need some kind of reliable fallback no matter what.

You could implement relays in a variety of ways. The classic way is a protocol called TURN (Traversal Using Relays around NAT). We’ll skip the protocol details, but the idea is that you authenticate yourself to a TURN server on the internet, and it tells you “okay, I’ve allocated ip:port, and will relay packets for you.” You tell your peer the TURN ip:port, and we’re back to a completely trivial client/server communication scenario.

Interactive Connectivity Establishment (ICE) protocol. Like STUN and TURN, ICE has its roots in the telephony world, and so the RFC is full of SIP and SDP and signalling sessions and dialing and so forth. However, if you push past that, it also specifies a stunningly elegant algorithm for figuring out the best way to get a connection.

Ready? The algorithm is: try everything at once, and pick the best thing that works. That’s it. Isn’t that amazing?

Let’s look at this algorithm in a bit more detail. We’re going to deviate from the ICE spec here and there, so if you’re trying to implement an interoperable ICE client, you should go read RFC 8445 and implement that.

Several DNS-related programs want to automatically manage the DNS name server and resolution configuration file at /etc/resolv.conf. In some situations, you may want to manage this file yourself. Here is how you identify which programs are automatically managing this file on your Linux distribution, and how you can take back manual control of the file.

There are quite a few different tools that fight to control a Linux system’s DNS resolution configuration file /etc/resolv.conf including netconfig, NetworkManager, resolvconf, rdnssd, and systemd-resolved.