dyff is inspired by the way the old BOSH v1 deployment output reported changes from one version to another by only showing the parts of a YAML file that change.

Each difference is referenced by its location in the YAML document by using either the Spruce or go-patch path syntax. The output report aims to be as compact as possible to give a clear and simple overview of the change.

Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can’t search for how to get yourself out of a mess, unless you already know the name of the thing you need to know about in order to fix your problem.

So here are some bad situations I’ve gotten myself into, and how I eventually got myself out of them in plain english.

Maybe you know how to solder a bit, but you suck at it. Or it’s frustrating and never comes out nice and you hate it.

Here’s how to make it enjoyable, and get good results as a side effect.

Welcome to the London Sound Survey, a web project which collected over 2,000 recordings of everyday life in London between 2008 and 2020. It also has a wide and unique range of historical resources on the theme of urban sound.

It’s one thing turning your basement into a wine cellar, but some people are building replica streets, theme parks and even trains beneath their homes

A paper revolution is coming! From both my interest in sustainability and fascination for tools and techniques grew the idea of a 3D printer to recycle paper.

The next thing I wondered was, “How difficult would it be to write that program?” Not a program that actually cracks PIN numbers from debit cards, I don’t think you can actually do that with a serial cable and some aluminum foil wrapped around a debit card, but a program that can simulate the output of the palmtop in that scene.
Let’s gather some product requirements!

Google can’t read your mind, of course. But it can read your search history. It tracks a lot of your web browsing, too. Google has an enormous amount of data about its users, and it uses that data to make an unimaginable amount of money from advertising: over $120 billion a year. The company runs a vast profiling machine, fitting people into categories that say who they are, what they’re worth, and how they’re expected to act. Google isn’t just organizing the world’s information; it’s sorting the world’s populations.

Hugh Padgham is one of the world’s top producers, on par music industry legends like Phil Spector, George Martin, Quincy Jones, Phil Ramone, Brian Eno, and Rick Rubin, to name but a few. The reason why Padgham enjoys, perhaps, not quite the same name recognition is because he prefers to remain behind the scenes, or, in his case, the desk. He likes to call himself “an invisible catalyst,” someone who gets the best out of the artists he works with, without taking any of the limelight.

Over the course of a career spanning five decades, Padgham has been the “invisible catalyst” behind dozens of best-selling, multi-platinum albums, many of them genuinely ground-breaking. Among them are recordings by XTC, Peter Gabriel, The Police, Yes, Phil Collins, Genesis, Kate Bush, David Bowie, Howard Jones, Paul McCartney, Sting, Roger Waters, Suzanne Vega, Sheryl Crow, The Bee Gees, Peter Frampton, McFly, and many more. Altogether it earned him four Grammy Awards.

True words

In Bash, the history command is capable of much more than what’s been covered here, but this is a good start for getting used to using your history instead of just treating it as a reference. Use the history command often, and see how much you can do without having to type commands. You might surprise yourself!

I recently noticed that zsh and fish will instead show a character indicating a missing linefeed, and still start the prompt where you’d expect to find it:

vidarholen-vm2% echo -n "hello zsh"
hello zsh%
vidarholen-vm2%

If you’re disappointed that this is what there’s an entire blog post about, you probably haven’t tried to write a shell. This is one of those problems where the more you know, the harder it seems

[…] the signal name stands for "Segmentation Violation".
So it’s essentially: SIGnal SEGmentation Violation.

But there’s more!

Originally the signal was called SIGSEG. It was subsequently renamed SIGSEGV
in the userspace and a bit later - around 1980 - to SIGSEGV on the kernel
side.

Maersk is the world’s largest integrated shipping and container logistics company. I was massively privileged (no pun intended) to be their Identity & Access Management (IAM) Subject Matter Expert (SME), and later IAM Service Owner. Along with tens (if not hundreds) of others, I played a role in the recovery and cybersecurity response to the events of the well-publicised notPetya malware attack in 2017. I left Maersk in March 2019, and as is customary I wrote the obligatory thank you and goodbye note. But there was always a lot more to add. A story to tell.

In order to contribute to historical awareness in our field, we have compiled a list of interaction design classics. Our aim was to include examples that we find inspiring and insightful — which led to our greatest challenge, keeping in mind that we wanted to create a concise list — leaving things out. So, we decided to focus on productivity software — in a very broad sense — and to order the projects chronologically. We didn’t address user interfaces from games, websites or artistic projects; that really would have been too much.

Notice the line makepdf & makedoc & openapp. Here I am are running the 3 functions in parallel. The wait command does exactly that, waiting for the previous things to finish. When everything is done, the pdf file opens. Let’s look at the timing now:

real 0m24.677s
user 0m21.669s
sys 0m1.746s

It is running ~27% faster. Only by wrapping the code in different functions.

As an extra, in bash the code is not evaluated all at once. If you edit a script while it is being executed, the script behaves differently. Wrapping it in functions solves that problem too.

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.

In the 8-bit age, data screeched slowly off tape decks. In the 16-bit era, floppy drives whirred, clinked and chunked according to the peculiarities of the system’s disk controller. For the BBC’s "Boring Talks"—podcasts about things most people would find boring—journalist Keith Stuart remembers.