Wandering Thoughts archives

Link: Eric Rescorla's "DNS Security, Part II: DNSSEC"

Eric Rescorla's DNS Security, Part II: DNSSEC (via) is a pretty even handed overview of DNSSEC. Rescorla is respected by Thomas Ptacek, even if they disagree (I think) about DNSSEC.

(Rescorla also has a Part I: Basic DNS for people who need that.)

Related to this is Ptacek's fascinating A Brief, Inaccurate History of DNSSEC (via). This goes with Ptacek's Against DNSSEC (from 2015; this debate has been going on for a while).

Link: Examining btrfs, Linux’s perpetually half-finished filesystem

Ars Technica's Examining btrfs, Linux’s perpetually half-finished filesystem (via) is not very positive, as you might expect from the title. I found it a useful current summary of the practical state of btrfs, which is by all accounts still not really ready for use even in its redundancy modes that are considered "ready for production". There's probably nothing new for people who are actively keeping track of btrfs, but now I have something to point to if people ask why we're not and won't be.

Link: "a2d<C-V>3gE: Vim normal mode grammar

"a2d<C-V>3gE: Vim normal mode grammar (via) presents an interesting way of thinking about how Vim normal mode commands are structured. It gave me some things to think about and also taught me a few Vim things I didn't know.

Link: Taking This Serially

j. b. crawford's Taking This Serially (via) is about the history of serial connections and RS-232, including the various connectors used and the complications that ensued with actually connecting things serially. I have a certain amount of history with serial connections, so I found this interesting.

(Also, looking at the article's pinouts for DE9/DB9 serial connectors made me realize something, but that's another blog entry.)

Link: What was the original reason for the design of AT&T assembly syntax?

This quite informative answer to a Stackoverflow question (via) answers the question, or at least provides a great deal of context that I didn't know. It turns out that the reason AT&T syntax puts the destination register second (instead of first, the way Intel syntax does) almost certainly stretches all the way back to how PDP-11s encoded instructions.

(The AT&T assembly syntax, commonly used on Unix systems but not uncommonly disliked (via), is a cross-platform general syntax that AT&T and Unix mostly used on a range of platforms. The specific x86 version of AT&T syntax is yet another adaptation of this general syntax. More information on the difference between AT&T and Intel syntax for x86 can be found on, eg, Wikipedia.)

Link: ARM support in Linux distributions demystified

ARM support in Linux distributions demystified (via) is just what it says in the title. Since I only just recently learned about things like 'Aarch64' in the process of writing this entry, all of this was timely and useful. It definitely taught me things about ARM floating point and architectures that I didn't already know.

(The discussion on lobste.rs has some useful additional information about stuff.)