links: Chronological entries

These are my WanderingThoughts
(About the blog)

Full index of entries
Recent comments

This is part of CSpace, and is written by ChrisSiebenmann.
Mastodon: @cks
Twitter @thatcks

* * *

Categories: links, linux, programming, python, snark, solaris, spam, sysadmin, tech, unix, web
Also: (Sub)topics

This is a DWiki.
GettingAround
(Help)

Link: quoting strings and breaking strings across multiple lines in YAML

This StackOverflow answer (alternate link) is an excellent, readable, all in one place answer to the twin questions of how you quote strings in YAML and how you break them across multiple lines. I learned something new about quoting strings from reading it, and I'm definitely going to want this link for future reference the next time I have something complicated to put in YAML. I'm also probably going to use '...' quoting more now that I know how simple it is to quote any stray 's I want in it.

(Via Laurence Tratt.)

Link: The Difference Between Root Certificate Authorities, Intermediates, and Resellers

Andrew Ayer's The Difference Between Root Certificate Authorities, Intermediates, and Resellers is about exactly that issue in much more detail than what I wrote recently. Although I knew some of the information in this article, other pieces were new to me.

Also very relevant to this area is Ayer's earlier The SSL Certificate Issuer Field is a Lie. This covers what it says in the title and is a fun read; the rabbit hole goes pretty deep.

Link: X Window System Basics

X Window System Basics (via) is an interactive walk through of the basic elements of X, starting with windows themselves and various things to do with them. This is a topic that's very relevant to me since I deal with old X programs and an old X window manager that have things like old fashioned iconification of windows. Fiddling around with the interactive demos (which require Javascript) is a great way to see in a concrete way how the nuts and bolts work.

Link: USB, Thunderbolt, Displayport & docks

USB, Thunderbolt, Displayport & docks (via, also) is a high density 'overview' of the technology of all of these things, or at least the technology of the connectors and connections involved. Since it gets down to the level of the number of lines and lanes (and their speed) involved in USB signaling and so on, it's an overview only from a certain perspective.

Although I read it through once and absorbed some things, I think of it more as a reference work that I can consult for fairly low level details if and when I need to understand some aspect of the entire USB mess (and it is a mess) at some depth. There is certainly a lot there.

Link: The MGR Window System

The MGR Window System (via) is a brief introduction to MGR, an interesting and under-mentioned Unix windowing system, including a screenshot. I once used MGR myself and have reasonably fond memories of it, so it's nice to see more writing about it on the Internet.

(And looking at my old entry I see that I linked to this article there in HTTP version. Still, I encourage you to read about MGR. It's a path not taken in Unix window systems.)

Link: An opinionated list of best practices for textual websites

An opinionated list of best practices for textual websites by Rohan Kumar is what it says in the subject. I'm not sure I agree with everything in it (and I certainly don't do everything there), but I think it has useful information and it's certainly given me things to think about.

(Since this entire blog is a textual website, I have a decided interest in this area and some opinions of my own.)

Link: Histograms in Grafana (a howto)

Histogram evolution: visualize how a distribution of values changes over time (via) has the article URL slug of 'grafana histogram howto', and the slug is quite accurate. It's a step by step walkthrough of how to do this for a native Prometheus counter histogram metric, which most of them are. It includes copious screenshots, which is especially useful since you have to do all of this through Grafana's GUI and describing GUI actions in text is not necessarily ideal. I've slogged through heatmaps and histograms in Prometheus and Grafana, and this article still taught me something quite useful that I hadn't realized (the 'exclude zeros' setting; I agree with the author that this should be the Grafana default).

PS: Contrary to what the article suggests, heatmap legends aren't always useful, at least in current versions of Grafana. I tried putting a legend on some disk IO latency heatmaps that have very small latencies and the result was not all that readable or clear.

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.)

Link: wtfpython

Satwik Kansal's wtfpython is at one level a whole collection of 'what the heck' Python moments, that outsiders might laugh at. At another level it's a valuable collection of Python mistakes that you might make and misunderstandings that you might have. I certainly learned some things from reading all the way through it, and hopefully have avoided some future mistakes.

Link: [Firefox] Navigational Instruments

Mike Hoye's Navigational Instruments (via) is about a bunch of underknown or underappreciated features in Firefox. I learned some really useful tricks from the article, including this one:

  • Holding down Alt while selecting text allows you to select text within a link without triggering the link

(In fact I used the tip to copy the title of the article from the article, because in the article the title is a link to itself.)

You may already know some of these tricks, as I did, and not care about others (I don't make much use of the URL bar, now called the 'Quantumbar'), but there's likely valuable stuff here for every Firefox user.

Link: Old-School Disk Partitions

Warner Losh's Old-School Disk Partitions (via) is a discussion of how disk partitioning worked and evolved in the early days of Unix, up through 4.3 BSD. This has more information than what I wrote about how major and minor device numbers worked in V7, because I missed that various disk device drivers had their own partitioning tables for minor numbers.

Warner Losh's blog has a lot of interesting writing on historical Unix things, so if that's one of your interests (as it is one of mine) it's well worth a look in general.

Link: Why Did Mozilla Remove XUL Add-ons?

David Teller's Why Did Mozilla Remove XUL Add-ons? is the answer to this question, from someone who works on Firefox. Firefox XUL Add-ons are the old and more powerful form of addons, which have now been replaced by WebExtensions as of Firefox Quantum.

I knew a certain amount about this area (and it's an interest of mine, since Firefox WebExtensions still aren't quite as good for my addons), but I didn't know all of the details and the article taught me things. I had never quite wondered what happened to Firefox's Electrolysis stuff, for example; the article answers the question.

(Via, itself via @mhoye.)

Link: The Anatomy of a PromQL Query

The Anatomy of a PromQL Query (via) is a very clear and nice explanation of what goes into a PromQL query. It covers both the elements (metrics, functions, and so on) and the Prometheus data types you use (such instant vectors and range vectors). This is a very useful article because while PromQL is solidly documented, it doesn't have a concept overview that's as clear and straightforward as this.

Link: Mime type associations (on Linux)

Enrico Zini's Mime type associations (via Planet Debian) is about the practical side of fixing MIME type associations so that various types of files open in the right program on your Debian system. This is an area of interest to me, but I've never pulled everything together into one spot (and compactly) the way this article does.

(For my entries, there's how xdg-mime searches for MIME type handlers, how xdg-open picks which web browser to use, the basics of /etc/mailcap, and a cautionary story of mailcap handling.)

Link: Code Only Says What it Does

Marc Booker's Code Only Says What it Does (via) is about what code doesn't say and why all of those things matter. Because I want you to read the article, I'm going to quote all of the first paragraph:

Code says what it does. That's important for the computer, because code is the way that we ask the computer to do something. It's OK for humans, as long as we never have to modify or debug the code. As soon as we do, we have a problem. Fundamentally, debugging is an exercise in changing what a program does to match what it should do. It requires us to know what a program should do, which isn't captured in the code. Sometimes that's easy: What it does is crash, what it should do is not crash. Outside those trivial cases, discovering intent is harder.

This is not an issue that's exclusive to programming, as I've written about in Configuration management is not documentation, at least not of intentions (procedures and checklists and runbooks aren't documentation either). In computing we love to not write documentation, but not writing down our intentions in some form is just piling up future problems.

Link: Stop Using Encrypted Email

Stop Using Encrypted Email is about all of the fundamental reasons that you should do that, from Latacora. See also eg Patrick McKenzie, and the discussion on Hacker News where there are more comments from Latacora people (look for tptacek and lvh).

(Latacora people include Thomas Ptacek, who you may remember from Against DNSSEC.)

Link: Mercurial's Journey to and Reflections on Python 3

Mercurial's Journey to and Reflections on Python 3 is about what it sounds like, by one of the core maintainers of Mercurial. It also contains some interesting notes on why Mercurial is going to have to keep supporting Python 2 for quite some time and what some of the consequences of that are.

Link: The asymmetry of Internet identity

David Crawshaw's The asymmetry of Internet identity is, among other things, a marvelously cynical yet pretty much completely accurate review of people's identity on the modern Internet in practice. I wish it didn't work the way Crawshaw describes it, but it does.

(Via lobste.rs.)

Link: GNOME Terminal Cursor Blinking Saga

Geoff Greer's GNOME Terminal Cursor Blinking Saga is about how to turn off cursor blinking in gnome-terminal, because the Gnome people are still in love with having their cursor blink despite it being a terrible idea and have progressively made it harder and harder to turn off.

Needing to look this up yet again did cause me to check the Gnome bug to expose a preference UI for this, which caused me to discover that you can actually easily turn this off these days, although not globally; you have to do it for each profile, turning off 'Cursor blinking'. If you have a lot of profiles and are the right sort of person, you may want to write a shell script that uses the gsettings approach, which still works.

(Why I needed to know this is that for my own reasons I'm doing a from-scratch Fedora 30 install in a virtual machine, and of course it came up with a gnome-terminal setup where the cursor blinks.)

Link: ASCII table and history (Or, why does Ctrl+i insert a Tab in my terminal?)

This ASCII table page (via) answers the question it poses in its title, and the answer is quite interesting. I have a long standing interest in this area, and this page's table explains things like why Ctrl-@ is a common way to generate a 0 byte. The table also makes it clear that at least one case is handled specially, that of Ctrl-? often being DEL. So now that I look at it, the table is interesting reading, not just the history.

(The straightforward implementation of Ctrl masks off bit 7, or perhaps bits 6 and 7, which turns @, binary 10 00000, into binary 00 00000 and thus gives you NUL. But you cannot go from ?, binary 01 11111, to DEL, binary 11 11111, by masking off bits; you have to turn on a bit instead. And notice that it is common to make Ctrl-_ generate byte 31, so we have binary 10 11111 turning into binary 00 11111 through masking, so this is not a general special treatment when the low five bits are 11111.)

PS: There's also this version of a four column ASCII table, but it doesn't have the history and doesn't look as nice as this new one.

Link: A program to read AMD Ryzen RAPL information on Linux

In my entry illustrating the practical difference between CPU TDP and actual power draw, I used a Mozilla program to read Intel's RAPL (Running Average Power Limit) CPU information. In that entry I regretted that as far as I knew there was no AMD equivalent, so I couldn't get similar measurements on my AMD Ryzen based office machine. Well, it turns out I'm wrong about that. Courtesy of @thurloat@mastodon.club comes this information:

@cks WRT <my entry>

this project might be useful to get some readings, came up in the AUR when I searched for a rapl package to install after reading your post. https://github.com/djselbeck/rapl-read-ryzen

The repository calls it a 'a quick and dirty hack', but in my testing on my office machine, it appears to work (ie, it appears to produce plausible readings, both under no load and under 'mprime -t'). In its current form, it appears to take an instant reading of the current power level, although I'm not sure I completely understand what's going on in the code.

My Mastodon remark about tiling window managers

Over on Mastodon, I said:

Two reasons that I'm unlikely to like tiling window managers are that I like empty space (and lack of clutter) on my desktop and I don't like too-large windows. Filling all the space with windows of some size is thus very much not what I want, and I definitely have preferred sizes and shapes for my common windows.

On the one hand, I've already written an entry on my views on tiling window managers. On the other hand, I don't think I've ever managed to state them so succinctly, and I find myself not wanting to just leave that lost in the depths of Mastodon.

(Looking back at that entry caused me to re-read its comments and realize that they may be where I found out about Cinnamon's keybindings for tiling windows, which would answer a parenthetical mystery.)

Links: A Practitioner's Guide to System Dashboard Design (with a bonus)

A Practitioner's Guide to System Dashboard Design is a four article series on system dashboard design by Cory Watson of One Mo' Gin. The parts are:

  1. Structure and Layout
  2. Presentation and Accessibility
  3. What Charts To Use
  4. Context Improvement

If you like these (and I did), you probably also want to read Cory's The CASE Method: Better Monitoring For Humans, and perhaps peruse the full articles index for additional things to read.

(Via somewhere that I've now forgotten and can't find again. Perhaps it was Twitter or Mastodon.)

Link: What has your microcode done for you lately?

What has your microcode done for you lately? (via) starts out being about the low-level performance of scattered writes on x86 machines but develops into a story where, well, I'll just quote from the summary:

Where the microcode comes in, and what might make this more interesting than usual, is that performance on a purely CPU-bound benchmark can vary dramatically depending on microcode version. In particular, we will show that the most recent Intel microcode version can significantly slow down a store heavy workload when some stores hit in the L1 data cache, and some miss.

I found the whole thing fascinating and I feel it deserves a wider audience. It's a bit challenging to follow if you don't already know some of the details of low-level CPU and memory access operation (it casually throws around terms like RFO), but working to understand it was interesting and taught me things, and I quite enjoyed the coverage of the issues involved in scattered write performance.

(Of course one has to speculate that the slowdown on recent microcode is due to either deliberate changes due to all of the speculative execution issues or side effects from those changes.)

Link: Vim anti-patterns

Tom Ryder's Vim anti-patterns is nominally about anti-patterns but it's really about teaching various better, more advanced ways to do things in vim. For each anti-pattern, Ryder shows a positive pattern (or several of them), and they're worth thinking about and maybe adopting. If nothing else, I learned new bits of vim.

(This is from 2012 and I believe I read it then, but it's worth re-reading every so often. Indeed I sort of think of it as a little reference for Vim things I want to remember.)

PS: I don't necessarily agree with all of Ryder's views here, but then I'm a lightweight vim user. In particular, I've not adopted either avoiding the arrow keys or using ctrl-[ for ESC, and I'm still perfectly willing to move around in insert mode to some degree, because it fits how I edit things.

Link: The IOCCC 2018 "Best of show" program

Christopher Mills' IOCCC 2018 entry (via) is a stunning tour de force that, well, let me quote the author's introduction:

The program delivered here is both a full machine emulation of the original PDP-7 that Ken Thompson used to write the first version of UNIX and a full machine emulation of the PDP-11/40 used by subsequent UNIXes. The Makefile can build versions that can run each of the following:

  1. UNIX v0 for the PDP-7 (circa 1969)
  2. Research UNIX Version 6 (circa 1975)
  3. BSD 2.9 (circa 1983)

This is one of those IOCCC entries where you absolutely do want to read the full author's description of their entry, because it is fascinating all by itself. For instance, until I read this I didn't know that Unix v0 had been reconstructed from original printouts of the assembly, and it's even on Github. That is just one small part of a fascinating journey.

(The IOCCC is the International Obfuscated C Code Contest, and here are the entire 2018 results. Mills' work may be even more impressive once you know that IOCCC entries must be 4096 bytes or less of C code.)

Link: Everything you should know about certificates and PKI but are too afraid to ask

Mike Malone's Everything you should know about certificates and PKI but are too afraid to ask (via, also, also) starts off slow (and with one simplification that irritated me) but very soon gets rolling into things like X.509 and PKCS, and then gets into a thorough and solid discussion of PKI (Public key infrastructure) and the considerations of running your own internal one for (mutual) TLS authentication. I was very pleased to see this recommendation:

In any case, if you run your own internal PKI you should maintain a separate trust store for internal stuff. That is, instead of adding your root certificate(s) to the existing system trust store, configure internal TLS requests to use only your roots. [...]

Separating public 'web PKI' from your own internal PKI is an important measure to keep compromises in your internal PKI from leaking into your use of web PKI (both through browsers and through programs). It also keeps compromises in web PKI from hurting your internal PKI, which I believe is Malone's main focus.

The article isn't perfect, but it's a great introduction and overview with solid practical recommendations that goes into significant depth on some important issues.

(I'm fairly certain that I learned some new things from it, even though I'm pretty well exposed to all of this stuff already.)

Link: HTTPS in the real world

Robert Heaton's article HTTPS in the real world (via) is about the difference between HTTPS in theory, in the cryptographic world of Alice and Bob, and HTTPS in practice, in the messy real world where CAs cannot be fully trusted and people lose their keys and so on. To pick one little bit to quote:

[...] But the real world has still managed to piece together a very serviceable public-key cryptography system by patching over the holes and omissions and naivety of the introductory world with a tartan of secondary systems known collectively as “Public Key Infrastructure” (PKI).

The whole article is a clear, short, amusing, and interesting summary of the whole practical mess of HTTPS and TLS. Even though I'm pretty up on all of the issues it talks about, I still found it well worth reading.

Link: HiDPI on dual 4K monitors with Linux

Vincent Bernat's article HiDPI on dual 4K monitors with Linux (via) is about what you'd expect it to be about and is, as they say, relevant to my interests. Especially relevant to me is the section on HiDPI support on Linux with X11, which runs down a collection of issues and contains a very useful chart about what is supported in what application and toolkit, which added some information that I hadn't known.

Note that Bernat's experience with xterm and rxvt don't match mine, perhaps because we're setting the X-level DPI information in somewhat different ways. My experience, as covered here, is that plain X applications using XFT fonts scale them appropriately once you get the DPI set everywhere (ie, if you tell xterm to use Monospace-12, you will get an actual 12 point size on your HiDPI monitor, not 12 points at 96 DPI and thus tiny fonts). If you use bitmap fonts, though, you're in trouble and unfortunately xterm still uses those by default for some things, like its popup menus.

(It's the nature of these articles to become out of date over time as HiDPI support improves and changes, but it's still a useful snapshot and some of these applications will probably never change.)

Link: Vectorized Emulation [of CPUs and virtual machines]

Vectorized Emulation: Hardware accelerated taint tracking at 2 trillion instructions per second (via) is about, well, let me quote from the introduction rather than try to further summarize it:

In this blog I’m going to introduce you to a concept I’ve been working on for almost 2 years now. Vectorized emulation. The goal is to take standard applications and JIT them to their AVX-512 equivalent such that we can fuzz 16 VMs at a time per thread. The net result of this work allows for high performance fuzzing (approx 40 billion to 120 billion instructions per second [the 2 trillion clickbait number is theoretical maximum]) depending on the target, while gathering differential coverage on code, register, and memory state.

Naturally you need to do all sorts of interesting tricks to make this work. The entry is an overview, and the author is going to write more entries later on the details of various aspects of it, which I'm certainly looking forward to even if I'm not necessarily going to fully follow the details.

I found this interesting both by itself and for giving me some more insight into modern SIMD instructions and what goes into using them. SIMD and GPU computing feel like something that I should understand some day.

(I find SIMD kind of mind bending and I've never really dug into how modern x86 machines do this sort of stuff and what you use it for.)

Link: "The History of a Security Hole" (in various *BSD kernels)

To yank my words from Twitter, Michal Necasek's The History of a Security Hole is a fascinating exploration of both the arcana of the x86 and what C can innocently do to you. Watching the code train barrel down the tracks towards its doom was decidedly compelling. There are also some useful lessons for long term software development that can be extracted here, since many of the mistakes made were entirely natural ones.

I often find this sort of stuff fascinating, so I really liked reading this entry and found I couldn't look away once things got going and mistakes piled up on top of misunderstandings. By the way, don't read this as a slam on the *BSDs; this sort of cascading misunderstanding can happen in any software, and undoubtedly has happened in non-BSD kernels as well in spots. It's simply easy to miss things in large, complex software (see eg).

(My tweet. I'm not sure where I got this from, but see HN, which mentions an interesting additional detail.)

Link: A deep dive into the Go memory allocator

Allocator Wrestling is a summary of Eben Freeman's talk from GopherCon 2018 on the Go memory allocator (via, and see also) and its garbage collection system. The slides are here (via) and have more details and elaborations on various things than the livebloged summary, although you probably want to read both (good talks are rarely entirely captured by their slides).

I love seeing under the hood of a complex system this way, and it's probably helped me move towards understanding some things about how much memory Go programs use (or appear to use).

Link: Where Vim Came From

Where Vim Came From (via) is an interesting and thorough overview of the history of vim, vi, ed, and other predecessors (with copious footnotes). It's nice to see all of the pieces laid out this way, and I learned of some historical links that I hadn't already known.

(I do wonder what vi would have been like if ed had kept QED's multiple buffer support.)

Update, the next day: See also Dennis Ritchie's An incomplete history of the QED Text Editor (via).

Link: A Child’s Garden of Inter-Service Authentication Schemes

A Child’s Garden of Inter-Service Authentication Schemes is an opinionated overview of service to service authentication schemes from Latacora (via, which has comments worth reading for once, including from various Latacora people). As with pretty much everything Latacora writes on their blog, it's not just informative, it's entertaining too. I find it well worth reading.

(Latacora people include Thomas Ptacek, who you may remember from Against DNSSEC.)

Link: About the memory management in the Bourne shell

About the memory management in the Bourne shell (via) is a collection of discussions about the original Bourne shell's creative, interesting, and infamous approach to memory management in the original Unix memory allocation scheme. If you like this kind of thing, it's worth reading through and decoding things.

(It also links to a recording of Stephen Bourne's BSDCan 2015 talk "Early days of Unix and design of sh", which I haven't watched yet but keep seeing links to. Someday.)

Link: Parsing: a timeline

Jeffery Kegler's Parsing: a timeline (via) is what it says on the title; it's an (opinionated) timeline of various developments in computer language parsing. There are a number of fascinating parts to it and many bits of history that I hadn't known and I'm glad to have read about. Among other things, this timeline discusses all of the things that aren't actually really solved problems in parsing, which is informative all by itself.

(I've been exposed to various aspects of parsing and it's a long standing interest of mine, but I don't think I've ever seen the history of the field laid out like this. I had no idea that so many things were relatively late developments, or of all of the twists and turns involved in the path to LALR parsers.)

Link: Closing the Loop: The Importance of External Engagement in Computer Science Research

Professor John Regehr's Closing the Loop: The Importance of External Engagement in Computer Science Research is an excellent article on the general spots where academic computer science can become disconnected with the real world and the engineering problems that are found there. Since I work in academia (and have read Greg Wilson for some time), this is an issue relatively near to my heart and I quite liked how he presents things in the article. It's a new framing of the issues, one that puts things in a clear way.

He's also written a followup post, Paths to External Engagement in Computer Science Research. This one is probably mostly of interest to people inside the sausage factory who want to interact with the outside, as opposed to people on the outside wondering why on earth academic computer science isn't more useful to them.

Link: Some fascinating details of cellular data transmission

Part of Ilya Grigorik’s “High Performance Browser Networking” is a fascinating section on the Radio Resource Controller (RRC):

Both 3G and 4G networks have a unique feature that is not present in tethered and even WiFi networks. The Radio Resource Controller (RRC) mediates all connection management between the device in use and the radio base station. Understanding why it exists, and how it affects the performance of every device on a mobile network, is critical to building high-performance mobile applications. The RRC has direct impact on latency, throughput, and battery life of the device in use.

As someone who just has a smartphone but likes to peek under the covers, I found it compelling reading, even if I'm not directly building anything that is affected by this. If nothing else it gives me a greater appreciation of what my smartphone is doing and what sort of things in applications (and my own usage) may be using up extra battery.

(Via Can You Afford It?: Real-world Web Performance Budgets, itself via lobste.rs.)

Link: The Python decorators they won't tell you about

H. Chase Stevens The decorators they won't tell you about (via Hacker News, repeatedly; it's been posted several times) is another view of Python decorators. I'll give you a quote that shows the flavour:

Decorators are often described as "functions which take functions and return functions", a description which is notable in that, technically speaking, not a single word of it is true.

(H. Chase Stevens is right about this, by the way.)

If you're interested in understanding more about what decorators are and some clever (or crazy) things they can be used for beyond the obvious, this is well worth reading. I certainly enjoyed it, even if some of the tricks it shows are things that I'd probably never use in real code.

(Breaking out of conventional views is always useful, in my opinion.)

By the way, the article is a Python Jupyter notebook and as such, you need to turn on JavaScript in order to view it on Github (and apparently people may have problems on mobile devices). An alternate view that doesn't require this is here (via).

Link: Citation Needed [on array indexing in programming languages]

Mike Hoye's Citation Needed is ostensibly about the origins of zero-based array indexing in programming languages. But that's not really what it's about once Mike Hoye gets going; it's really about our field's attitude towards history, the consequences of that attitude, and the forces that drive it, including inaccessible papers. Even if you're indifferent to where zero-based array indexing comes from, that portion of the article is well worth reading and thinking about.

(I'm not going to quote any of it. Read the whole thing, as they say; it's not that long.)

PS: This is from 2013, so you might have read it already. If you aren't sure and don't remember it, read it again.

Link: Linux Load Averages: Solving the Mystery

Brendan Gregg's Linux Load Averages: Solving the Mystery (via, and) is about both the definition and the history of load average calculations in Linux. Specifically:

Load averages are an industry-critical metric – my company spends millions auto-scaling cloud instances based on them and other metrics – but on Linux there's some mystery around them. Linux load averages track not just runnable tasks, but also tasks in the uninterruptible sleep state. Why? I've never seen an explanation. In this post I'll solve this mystery, and summarize load averages as a reference for everyone trying to interpret them.

In the process of doing this, Brendan Gregg goes back to TENEX (including its source code) for the more or less original load average. Then he chases down the kernel patch from October 1993 that changed Linux's load averages from purely based on the size of the run queue to including processes in disk wait. It goes on from there, including some great examples of how to break down a load average to see what's contributing what (using modern Linux tracing tools, which Gregg is an expert on). The whole thing is really impressive and worth reading.

(Gregg's discussion is focused on Linux alone. For a cross-Unix view, I've written entries on when the load average was added to Unix and the many load averages of different Unix strains. In the latter entry I confidently asserted that Linux's load average included 'disk wait' processes from the start, which Gregg's research has revealed to be wrong.)

Link: How does "the" X11 clipboard work?

X11: How does “the” clipboard work? (via) is a technical walk through the modern X11 selection system, one that winds up discussing things at the level of the X protocol and Xlib, with helpful code examples. I learned some quite useful things in the process, for example how to use xclip to query things to find out what formats a selection is available in.

(Technical details about X selections are relevant to me because I use a program that deals with them and which I'd like to see do so more conveniently.)

Link: NASA DASHlink - Real System Failures

The Observed Failures slide deck from NASA DASHlink (via many places) is an interesting and even alarming collection of observed failures in hardware and software, mostly avionics related. I find it both entertaining and a useful reminder that all of this digital stuff is really analog underneath and that leads to interesting failure modes. Lest you think that all of these were hardware faults and us software people can be smug, well, not really. There are more; read the whole thing, as they say.

Link: ZFS Storage Overhead

ZFS Storage Overhead (via) is not quite about what you might think. It's not about, say, the overhead added by ZFS's RAIDZ storage (where there are surprises); instead it's about some interesting low level issues of where space disappears to even in very simple pools. The bit about metaslabs was especially interesting to me. It goes well with Matthew Ahrens' classic ZFS RAIDZ stripe width, or: How I Learned to Stop Worrying and Love RAIDZ, which is endlessly linked and cited for very good reasons.

Link: Survey of [floating point] Rounding Implementations in Go

Matt Jibson's Survey of Rounding Implementations in Go (via) is sort of what it says, namely a survey of a bunch of floating point rounding implementations:

Rounding in Go is hard to do correctly. That is, given a float64, truncate the fractional part (anything right of the decimal point), and add one to the truncated value if the fractional part was >= 0.5. [...]

But it's a lot more than that, because the article then proceeds to demonstrate just how complicated floating point rounding really is (in any language), how non-obvious this complexity is, and how easy it is to get it wrong. It ends with a walk-through of what will be math.Round in Go 1.10, which is implemented not through floating point operations but through direct knowledge of how floating point values are implemented at the bit level.

Floating point is one of those things in programming that looks like it's reasonably simple but instead is a deep pit of potential complexity once you move beyond doing very simple things. I enjoy articles like this because they are both a good reminder of this and a peek behind the curtain.

Links: Git remote branches and Git's missing terminology (and more)

Mark Jason Dominus's Git remote branches and Git's missing terminology (via) is about what it sounds like. This is an issue of some interest to me, since I flailed around in the same general terminology swamp in a couple of recent entries. Dominus explains all of this nicely, with diagrams, and it helped reinforce things in my mind (and reassure me that I more or less understood what was going on).

He followed this up with Git's rejected push error, which covers a frequent 'git push' issue with the same thoroughness as his first article. I more or less knew this stuff, but again I found it useful to read through his explanation to make sure I actually knew as much as I thought I did.

Link: The evolution of Unix's overall architecture

Diomidis Spinellis has created a set of great resources for looking at Unix's history. He started with the Unix history rep and has then used that to create block diagrams of Unix's structure in V1 and modern FreeBSD. His article Unix Architecture Evolution Diagrams (via) explains the interesting story of how he put these diagrams together. He also has a site on where manpages appear over Unix versions.

Link: Rob Landley's Linux Memory Management Frequently Asked Questions

Rob Landley's Linux Memory Management Frequently Asked Questions is what it says in the title (via). As of writing this pointer to it, the current version of the FAQ appears to be from 2014, but much of its information is relatively timeless.

Landley's FAQ is good for a lot more than Linux specific information. It's a good general overview of a number of hardware MMU concepts and general Unix MMU concepts. Things like page tables, TLBs, and even memory mappings are basically universal, and the FAQ has a nice solid explanation of all of them and much more.

(See also Rob Landley's other writing, and his website in general.)

Link: Introduction to Certificate Transparency for Server Operators

Alex Gaynor's Introduction to Certificate Transparency for Server Operators (via) is what it says in the title, and taught me some things about certificate transparency in practice. Sadly, one of the things it taught me is that once again Lighttpd seems to be coming up short as far as modern TLS goes. I really should switch over my personal site to using Apache, even if it will kind of be a pain because Fedora fumbled good Apache configuration.

(I also hadn't known about Cert Spotter, which has the advantage that you don't need a Facebook login to use it and thus don't have to helpfully (for Facebook) tie one or more domains to your Facebook login. All you need is an email address and on the modern Internet, you already need a source of individualized disposable ones.)

Link: The Unix Heritage Society now has the 8th, 9th, and 10th editions of Research Unix

Today in an email message with the subject of [TUHS] Release of 8th, 9th and 10th Editions Unix, Warren Toomey announced that the Unix Heritage Society has now gained permission to make the source code of Research Unix's 8th, 9th, and 10th editions available for the usual non-commercial purposes. This apparently is the result of a significant lobbying campaign from a variety of Unix luminaries. The actual source trees can be found in TUHS' archive area for Research distributions.

Most people are familiar with Research Unix versions through V7 (the 7th Edition), which was the famous one that really got out into the outside world and started the Unix revolution. The 8th through 10th editions were what happened inside Bell Labs after this (with a trip through BSD for the port to Vaxen, among other things; see the history of Unix), and because Unix was starting to be commercialized around when they were being worked on by Bell Labs, they were never released in the way that the 7th Edition was. Despite that they were the foundation of some significant innovations, such as the original Streams and /proc, and for various reasons they acquired a somewhat legendary status as the last versions of the true original strain of Research Unix. Which you couldn't see or run, which just added to the allure.

You probably still can't actually run these editions, unless you want to engage in extensive hardware archaeology and system (re)construction. But at least the Unix community now has these pieces of history.

Link: Four Column ASCII

Four Column ASCII (via) is a reformatted version of this Hacker News comment that presents the ASCII chart in four columns of 32 characters instead of the usual presentation of eight columns of 16 (as seen eg here). A four column representation makes a number of patterns in ASCII (both bit-wise and otherwise) much clearer, for example why Ctrl-Space, Ctrl-@, and Ctrl-` all generally generate a null byte.

(I suspect that ASCII is traditionally presented in an 8 column by 16 row table because that fits into an 80x24 terminal or terminal window.)

Link: Let's Stop Ascribing Meaning to Code Points

Manish Goregaokar's Let's Stop Ascribing Meaning to Code Points starts out with this:

I've seen misconceptions about Unicode crop up regularly in posts discussing it. One very common misconception I've seen is that code points have cross-language intrinsic meaning.

He goes on to explain the ways that this is dangerous and how tangled this area of Unicode is. I knew little bits of this already, but apparently combining characters are only the tip of the iceberg.

(via, and see also.)

Link: RFC 6919: Further Key Words for Use in RFCs to Indicate Requirement Levels

If you read RFCs, you may know about the standard use of the MUST, SHOULD, and so on key words that come from RFC 2119. RFC 6919, issued April 1st 2013, adds some useful additional key words like "MUST (BUT WE KNOW YOU WON'T)", "REALLY SHOULD NOT", and the like.

By itself this would be amusing and interesting. But what really makes RFC 6919 rewarding to read is that it shows usage examples for each of its new key words that are drawn from existing RFCs. If you have much exposure to how RFCs are actually implemented in the field, this will make you alternate laughter and sad sighs. To quote myself from when I first saw it:

RFC 6919 makes me laugh but it's sad laughter. Such honesty had to be published Monday.

(I was reminded of RFC 6919 by @whitequark's tweet, and was actually surprised to discover that I've never linked to it here on Wandering Thoughts. So now I'm fixing that.)

Link: Twice the bits, twice the trouble: vulnerabilities induced by migrating to 64-bit platforms

Adrian Colyer's Twice the bits, twice the trouble: vulnerabilities induced by migrating to 64-bit platforms (via) is a very readable and very interesting summary of an ultimately depressing academic paper on the security vulnerabilities that get induced in C code simply by migrating from 32-bit platforms to 64-bit platforms.

In theory I sort of knew about all of this, but it's one thing to vaguely have heard about it and another thing to see handy comparison charts and examples and so on of how relatively innocent C code introduces real vulnerabilities simply when you rebuild it on 64-bit machines and then expose it to attackers.

Here's a depressing quote from the academic paper to finish up with and motivate reading at least Colyer's summary of the whole thing:

Finally, we make use of this systematization and the experience thus gained to uncover 6 previously unknown vulnerabilities in popular software projects, such as the Linux kernel, Chromium, the Boost C++ Libraries and the compression libraries libarchive and zlib—all of which have emerged from the migration from 32-bit to 64-bit platforms.

That's, well, unfortunate. But not unexpected, I suppose. Maybe all future languages should not have any limited-range numeric types that can have different sizes on different platforms, even if it's theoretically an attractive idea for 'optimization'.

(I don't know what Rust does here, but Go does have int and uint, which are either 32 or 64 bits depending on the platform.)

Link: Linux containers in 500 lines of code

Lizzie Dixon's Linux Containers in 500 lines of code is exactly what it says in the title, namely an example of setting up a relatively complete Linux container in 500 lines of code or so. The whole thing is interesting, but for me the really useful bits are the code examples and careful discussion of things like dropping capabilities and installing seccomp filters to block system calls.

(I feel I have a broad understanding of how Linux containers work and the general kernel pieces used to set them up, but I haven't really done anything with either capabilities or seccomp.)

Also, it turns out that reading the footnotes here was very useful because it led to me discovering the Ubuntu sysctl kernel.unprivileged_userns_clone, which lets you turn off unprivileged use of user namespaces. I've wanted this for some time so it's great to find out that we can get it on most of our Ubuntu machines.

Link: Actually using ed

Tom Ryder's Actually using ed (via @davecheney) is a nice little walk-through of using the Unix ed editor to, well, edit some text. I've used ed a long time ago, and this inspired me to fire it up again to follow along and play around a bit; it was surprising how much I remembered. It was also nice reading about some advanced ed features that I either didn't know about or never used enough to remember.

(As always, I find it interesting what's considered basic versus advanced in things like this. To me, address ranges like '1,10p' are a basic feature.)

I'm not sure I'll ever use ed for anything real (at least outside of a real emergency), but it's nice to know that I still remember enough to find my way around in it. It's also nice that the modern GNU version of ed has picked up a number of user-friendly features like the -p argument.

(The version of ed that I'm acclimatized to is usually called 'UofT ed', and features a bunch of modifications made here by a number of people, including Henry Spencer. Among other different behaviors from classical ed, it prompts with a '*' instead of nothing and has somewhat more friendly error messages.)

Link: File crash consistency and filesystems are hard

Dan Luu's File crash consistency and filesystems are hard is about what it says it's about, with examples and interesting academic citations (that are kind of depressing) and the whole lot. If you want more reading, it has a whole bunch of links to further papers that you can go through. Most of them are apparently depressing reading, because the capsule summary is 'this stuff is hard and almost no one gets it completely right'; not user programs, not filesystems, and not the actual disk drives.

(Sometimes the 'not getting it right' bit is more accurately called 'cheating in the name of good benchmarks'.)

(I have a long standing interest in this area, as do many sysadmins. People tend to get upset if our systems lose their email during power failures and so on. Sometimes we cheat, but we like to do this with our eyes open.)

Link: Git from the inside out

Mary Rose Cook's Git from the inside out is a highly detailed and thus fascinating recounting of exactly how Git's graph structure and on disk tracking of things works as you evolve a repository. I knew many of the broad strokes just from general git knowledge but the details are illuminating and quite useful, especially the details around what exactly happens and gets recorded where during more advanced operations like merges (especially with conflicts) and pulls.

(I care about git things at this level of detail because they let me understand what's going on and what I can do about it when things don't go the way I expect them to. I'm not left poking futilely at a black box; instead I have the reassuring feeling that I can at least peek inside.)

Link: A Short History Of Removable Media Behind The Iron Curtain

Pete Zaitcev's A Short History Of Removable Media Behind The Iron Curtain is a fascinating look into the history of (re)movable hard drives in the USSR. Apparently these were far more common there than they were in the west, to the point where it was routine to do this with what the west thought of as fixed hard drives. As a bonus it also includes some information on the early history of byte order independence in Linux filesystems, which Pete Zaitcev was there for.

(I know just enough about the history of computing behind the Iron Curtain to know that it was fairly different from the history in the west. My impression is that there was a fair amount of fascinating hacks and improvisations, and presumably some amount of really impressive original work.)

Link: Against DNSSEC by Thomas Ptacek

Against DNSSEC by Thomas Ptacek (@tqbf) is what it says in the title; lucid and to my mind strong reasons against using or supporting DNSSEC. I've heard some of these from @tqbf before in Tweets (and others are ambient knowledge in the right communities), but now that he's written this I don't have to try to dig those tweets out and make a coherent entry out of them.

For what it's worth, from my less informed perspective I agree with all of this. It would be nice if DNSSEC could bootstrap a system to get us out of the TLS CA racket but I've become persuaded (partly by @tqbf) that this is not viable and the cure is at least as bad as the disease. See eg this Twitter conversation.

(You may know of Thomas Ptacek from the days when he was at Matasano Security, where he was the author of such classics as If You're Typing the Letters A-E-S Into Your Code You're Doing It Wrong. See also eg his Hacker News profile.)

Update: there's a Hacker News discussion of this with additional arguments and more commentary from Thomas Ptacek here.

Link: My current dmenu changes

As I've mentioned before, I have a set of changes I've made to dmenu to make it work better for me. I have now put my current patch online as dmenu-4.5-tip.patch in case anyone is interested. I happen to like all of my changes, but then I would. See the start of the patch for a description of what it includes (and then the documentation for the new switches in the revised dmenu.1 manpage).

I expect that I'll update this patch periodically as the main dmenu source itself gets updated, but so far the latter doesn't seem to change very often.

PS: to save the energy of anyone asking: while my patch set contains a bugfix for dmenu's handling of -m (and the manpage), I don't currently feel like breaking it out as a separate patch and then trying to send it upstream. It's too much work for too little chance of success.

Update, August 4th 2015: The patchset linked above is now out of date, per here. My dmenu changes are now in my github repo for my version, split up into multiple commits that you can cherry-pick as desired.

Link: Go at Google: Language Design in the Service of Software Engineering

Go at Google: Language Design in the Service of Software Engineering is an article version of a Rob Pike keynote on, well, let me just quote:

The Go programming language was conceived in late 2007 as an answer to some of the problems we were seeing developing software infrastructure at Google. [...]

Go was designed and developed to make working in this environment more productive. [...]

The article then discusses what this means and how various aspects of Go's design were consciously shaped by a number of pragmatic software engineering issues in building large software across large(r) teams. I find it really interesting reading (and I keep referring to it and having to re-find it, so it's clearly time to put this somewhere more obvious).

Link: Getting Real About Distributed System Reliability

Jay Kreps' Getting Real About Distributed System Reliability is a very interesting discussion of the reliability of distributed systems in the real world. He patiently explains that a number of assumptions normally made to reason about this are in fact wrong in practice, especially the assumption that failures are independent. I'm not going to try to summarize his entry beyond that; go read it instead.

(I suspect that his logic extends to all real systems, not just distributed ones, and in any case he has given me a lot to think about.)

By the way, several of the links in his entry are themselves worth following and reading carefully.

(I believe I got this from my Twitter stream but I cannot find the original source now.)

Link: Filenames.WTF

In Filenames.WTF, Daniel Rutter runs down the reasons first why paying attention to file extensions is ridiculous, and then the reasons why it's still the best solution to the problem that we have. Spoiler: it's because people have spent decades creating file formats that suck.

(Via philliph on Twitter.)

Another Russ Cox regexp article: How Google Code Search Worked

Russ Cox has just added another article in his series on regular expressions; this one is titled Regular Expression Matching with a Trigram Index, or How Google Code Search Worked. It's as worthwhile as all of the previous three.

Link: Russ Cox's articles on regular expressions

If you have any interest in regular expression matching, especially efficient regexps and understanding why Perl, Python, and so on have sometimes oddly slow implementations, you really want to read Russ Cox's series of articles on regular expressions.

The core things to read are his three part series, Regular Expression Matching Can Be Simple And Fast, Regular Expression Matching: the Virtual Machine Approach, and Regular Expression Matching in the Wild.

(I know, this is late, since Hacker News discussed this a couple of years ago (plus the comment here). The gears of my link-pointing machinery evidently grind very slowly, but better late than never.)

Link: Pollution in 1.0.0.0/8

IANA has recently allocated 1.0.0.0/8 to APNIC, which has caused a certain amount of concern that it is 'polluted' by people already using it for various reasons. Pollution in 1/8 is a report from RIPE Labs on what happened when they announced routing for some bits of it as part of their debogonising work.

This is clearly going to be what they call 'interesting'.

(via Hacker News.)

Link: Using colour well in data visualization

Why Should Engineers and Scientists Be Worried About Color? is about how straightforward use of colour in data visualizations can mislead you and hide information (and how to do better). Some of their examples are eye-opening and alarming.

(Via Hacker News.)

(Since I took up photography I've had a much increased interest in how we perceive things, including colour.)

The quote of the time interval, on XML

From an article by Henri Sivonen:

Draconian error handling creates an unstable equilibrium in Game Theory terms—it only lasts until one player breaks the rule. One non-Draconian XML5 implementation in a key client product and the Draconian XML ranks would break.

(Discovered through Mark Pilgrim, specifically his firehose.)

Applications to XHTML are left as an exercise for the reader.

Link: XML on the web summarized

The link of the time interval comes from the online comic strip Bonobo Conspiracy, which neatly summarizes the reality of XML on the web in today's strip.

Link: you are what you code

From Robert Brewer comes You are what you code, which has given me something to think about. I'll quote the opening:

Hey, you. Do you realize what you're writing? The long-standing IT joke is that you always end up coding your own job out of existence. But what are you coding yourself into?

(From Planet Python, where his blog is aggregated.)

Update: I apologize to my readers for putting a link here that doesn't work without an extra, annoying step (see the comment).

Update2: the situation has now been fixed.

QOTD: There are three types of authentication

There are three types of authentication:

They are:

  1. Something you've lost,
  2. Something you've forgotten, and
  3. Something you used to be.

The full entry includes an illustrative story and bonus comments (and, unfortunately, a certain amount of comment spam, at least right now).

(From Richard Johnson of river.com.)

Link: Why the ease of installing Java matters

In Java in The Land of Make Believe, Ryan Tomayko unloads a righteous rant about why Java's license matters and what effects it has in the Linux and *BSD worlds, with great bits like:

If you want to get on the bad side of software developers and system admins, the fastest route is to waste their time.

Amen. What he said.

(The good news is that Sun GPL'ing Java may finally be changing all of this mess, which Tomayko happily acknowledges.)

(From many places, but I saw it originally on Planet Python, as Tomayko's blog is syndicated there.)

Link: Peter Gutmann on PKI

Everything you never wanted to know about PKI but were forced to find out [PDF] by Peter Gutmann is a set of slides about just that: a pile of the warts and issues with PKI in general and the SSL model in specific. If you're interested in the whole field, his home page has links to enough additional papers to keep you reading for some time.

(From Chris Samuel, and that in turn from Russell Coker.)

Link: Threads Cannot be Implemented as a Library

I've already linked to this in passing, but I'm going to rerun it as an explicit link. Threads Cannot be Implemented as a Library by Hans Boehm makes the argument in its title:

We provide specific arguments that a pure library approach, in which the compiler is designed independently of threading issues, cannot guarantee correctness of the resulting code.

There is also a discussion of this paper at Lambda the Ultimate that may be interesting reading. On a quick skim of the LtU discussion thread, this Usenet article jumps out as a useful summary of the entire volatile and multiprocessor programming issue, ending up with the conclusion that using volatile is both unnecessary and harmful in shared-state concurrent programming.

Link: OpenBSD spamd

OpenBSD spamd - greylisting and beyond is a presentation by Bob Beck of the University of Alberta about the OpenBSD's spamd system, how spammers react to it and similar systems, how you can exploit this, and the University of Alberta's experiences with spamd, complete with interesting numbers. I'm sadly jealous, as local feelings insure that I'm not going to get to deploy this sort of technology any time soon.

(Also from Richard Johnson of river.com.)

Link: varnish, a HTTP accelerator

Varnish - the http accelerator [PDF] is the slides for a presentation about a HTTP accelerator for dynamic websites/CMS systems (its website is here). Slide three made me laugh out loud, and I have to say 'what he said'.

(From Richard Johnson of river.com.)

Link: A lovely summary of the XHTML issue

On the WHATWG mailing list, Henri Sivonen put together a marvelous and concise summary of the whole problem with XHTML in today's world, and why XHTML advocates usually irritate me. I'm not going to quote anything; just read the whole thing here.

(From Sam Ruby, who linked to an Ian Hickson WHATWG mailing list message that quoted Henri Sivonen's message.)

Link: Serif vs. Sans Serif Legibility

Which Are More Legible: Serif or Sans Serif Typefaces? by Alex Poole is a review and summary of a whole pile of writing about this. I'll cut to the conclusion (don't worry, it's not a spoiler since Alex Poole puts it in the first paragraph of the introduction):

To date, no one has managed to provide a conclusive answer to this issue.

Alas, none of this helps me configure liferea to improve its legibility on a 17" CRT monitor. (I would be happy if I could just clone a Firefox setup, but this is stupidly difficult and/or impossible for no good reason.)

(From someone I chat with online, when I was asking around about this.)

Link: Golden Rules for Bad User Interfaces

Golden Rules for Bad User Interfaces is more or less what it sounds like. I could wish that the sarcasm was more biting, but that would probably be ungracious and besides, it's from SAP.

(From Greg Wilson.)

Link: On Bots

On Bots is a fascinating report on a large scale experiment to see how web search bots would explore an almost limitless set of linked pages. Whether or not the results generalize (or are still applicable), it's got a bunch of pretty pictures.

(From Tim Bray, rather belatedly.)

Link: Pumas on Hoverbikes

Pumas on Hoverbikes is about managing system administrators, and it's funny. Here's a somewhat out of context quote:

This is because managers are usually people who proved that they were handy with a chaingun and were thus rewarded by having their thumbs cut off and their weapons handed to some punk college hire.

From this you should be able to figure out if you want to read the rest. There's other articles too, like Suck Factor, which is where I first dropped into the site.

(From comments on this.)

Link: Unicode Spaces

Presented without comment, the 18 spaces of Unicode.

(From Sam Ruby.)

Link: HTML Doctype declarations inventoried

Activating the Right Layout Mode Using the Doctype Declaration is pretty much summarized by its title. As a bonus, it includes a handy chart of how various browsers react to various specific DOCTYPE declarations (or did, as of when the chart was made; browser DOCTYPE behavior is an ever-changing target, and the chart is a good illustration of how much variety there can be).

(From Anne van Kesteren.)

Link: Warning Signs for Tomorrow

Warning Signs for Tomorrow is a collection of warning signs for tomorrow. Amusing and potentially useful ones (for me; your mileage may vary) include 'lack of internet connectivity', 'ubiquitous surveillance', and 'motivation hazard'.

(From James Nicoll.)

Link: IRON File Systems

IRON File Systems [PDF] is a paper from the 2005 ACM Symposium on Operating Systems Principles. To quote from the abstract:

Commodity file systems trust disks to either work or fail completely, yet modern disks exhibit more complex failure modes. We suggest a new fail-partial failure model for disks, which incorporates realistic localized faults such as latent sector errors and block corruption. We then develop and apply a novel failure-policy fingerprinting framework, to investigate how commodity file systems react to a range of more realistic disk failures. [...]

They did their primary analysis on Linux ext3, ReiserFS 3, and (Linux) JFS; the results are comprehensive, interesting, and sometimes scary.

Link: The Single Unix Specification et al

The Open Group Base Specification Issue 6 is, well, to quote it:

This standard is the single common revision to IEEE Std 1003.1-1996, IEEE Std 1003.2-1992, and the Base Specifications of The Open Group Single UNIX Specification, Version 2.

(Those IEEE standards are better known as 'POSIX'.)

The Single Unix Specification (SUS) is a very useful authoritative reference for how various things should behave in theory. (How they behave in fact is a different issue; not everything is correctly implemented, and not everything is SUS/POSIX compliant to start with.)

You'd think that the Open Group would make this stuff openly available, but instead they want you to register and provide them with various personal details. As we can see here, that is not strictly speaking necessary; you just need the right magic URL.

(From Andree Leidenfrost via Debian Planet.)

Link: Csh Programming Considered Harmful

Tom Christiansen's Csh Programming Considered Harmful used to be posted to various Usenet comp.unix groups, nigh on ten years ago or so. I consider it sort of a pity that it isn't still being posted, because every so often someone still decides that writing shell scripts in csh would be a good idea.

Some of the problems Christiansen identified have since been fixed by modern versions of tcsh, but not all of them.

(The article can also serve as an interesting catalog of sh programming tricks.)

Link: When the "best tool for the job"... isn't.

When the "best tool for the job" isn't argues that what we might think is the best tool for the job isn't. (I'm not going to mangle its ideas by trying to summarize it more than that.)

This is an issue that I sometimes feel moderately acutely, since I use X Windows in preference to something like OS X, while the general view is that Apples are the machines for people who want both Unix and a decent user experience (and there's a certain population that questions the sanity and wisdom of Unix people who aren't interested in that migration).

(From the Voidspace Techie Blog, via Planet Python.)

Link: Ten Risks of PKI

Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure is a paper by Carl Ellison and Bruce Schneier. These aren't technical risks, at least not directly, and it makes for interesting reading. (And after you're done reading your printed copy of the PDF you can leave it out in a strategic spot for other people to run across.)

(From this comp.lang.python article by Edward Elliot, which I ran across through the Daily Python URL.)

Link: Linguistic blindness illustrated

If you can answer this, you are not paying attention is a nice illustration and discussion of the importance of thinking about what you're writing in prompts and questions in software. Also interesting is a followup entry on why everyone is so against using 'yes' and 'no' for answers in dialog boxes.

(From Daring Fireball.)

Link: non-errors in English

Non-Errors is a nice catalog of things that aren't English usage errors, even though a lot of people tend to think that they are. Since I do any number of them I find this reassuring, and it's amusing to see just how old some of these perfectly proper usages turn out to be.

(From Daring Fireball.)

Link: 'Document Centric'

Document Centric is about the disconnect between relational databases and regular users, and why people keep stuffing data into spreadsheets and the like instead of 'real' databases.

(They do. Joel Spolsky has written about the Excel team's surprise at finding this out about how real users used Excel.)

(From Carlos de la Guardia.)

Link: The virtual furniture police

The Virtual Furniture Police is ultimately an unflattering view of how IT departments too often attempt to have a great deal of control over user desktops. The opening paragraph summarizes things nicely:

This is a review, of sorts, of the book Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister. Then a segue to explain how typical corporate IT policies contravene some of the excellent advice in this book.

And the title is lovely; I think I have a new catchphrase.

(From a comment here.)

Link: The Unix Heritage Society

The Unix Heritage Society has a nice statement of its aims on its front page, but let me skip straight to the neat bits: complete source code for early Unix versions, such as V7 and V6. You can browse things online, or get your own personal mirror. For a long time, having this sort of thing was a Unix geek dream, and now I have my own (legal!) copy of it all.

One of the neat things I like doing with TUHS is browsing to see the original full versions of such famous Unix bits as the 'you are not expected to understand this' kernel source comment. Here it is in full, from the swtch() routine in /usr/sys/ken/slp.c in the Sixth Edition:

 /*
  * If the new process paused because it was
  * swapped out, set the stack level to the last call
  * to savu(u_ssav).  This means that the return
  * which is executed immediately after the call to aretu
  * actually returns from the last routine which did
  * the savu.
  *
  * You are not expected to understand this.
  */

While I'm in the area, I'd be remiss if I didn't link to the Wikipedia entry on Lions' Commentary on UNIX 6th Edition, with Source Code. This is a famous work for old Unix geeks, and the Wikipedia entry even has links to a PDF version.

(TUHS also has links to PDP-11 simulators and disk images, so you can actually run V7 et al. Maybe even faster than it ran on a real PDP-11/70, back in the days.)

Link: a Unix sysadmin rosetta stone

Rosetta Stone for Unix is a very handy cross-index of various commands and tasks across various Unix variants. The index of tasks is especially handy as a quick 'how do I do this on X' pointer. It's available in several formats, and as a bonus you get some helpful links as well.

(Since I was just using this today to figure out how to do various things on Solaris, I figured I should finally get around to mentioning it.)

(From a Slashdot comment.)

Link: Classic Mistakes Enumerated

Classic Mistakes Enumerated is an exerpt from the book Rapid Development by Steve McConnell; it runs through 36 familiar classic development mistakes that people make over and over again. Brooks's Law makes an appearance, of course.

(From Bill de hÓra.)

Link: Why overtime is bad for everyone

The really interesting bit of Why Crunch Mode Doesn't Work: 6 Lessons for me can be summed up in the lead-in:

There's a bottom-line reason most industries gave up crunch mode over 75 years ago: It's the single most expensive way there is to get the work done.

The article elaborates this, and makes for interesting reading. In the same area is Hours of Work in U.S. History, if one wants another set of data.

(Unfortunately I have lost where I got the first link from.)

Link: an engineering management hack

Engineering Management Hacks: The BigBook Technique is an amusing story of how a group of engineers got their management to pay attention to Brooks's Law ("Adding manpower to a late software project makes it later"). I won't spoil the punchline; read it yourself.

Around here we don't have problems with Brooks's Law, perhaps because we don't have the extra manpower to add to late projects to start with.

(From Daring Fireball.)

Link: an excerpt from On Writing Well

Here are chapters 2 through 4 of William Zinsser's On Writing Well, a classic book on, well, writing well. Just start with the opening of chapter 2 and keep going:

Clutter is the disease of American writing. We are a society strangling in unnecessary words, circular constructions, pompous frills and meaningless jargon.

Remind you of any computer manuals you've read recently? (Hopefully it does not remind you too much of WanderingThoughts. I try, but I know I have a long way to go.)

On Writing Well itself can be gotten from the online bookseller of your choice. (My choices are Canadian.)

(From a comment on a Slashdot article about writing.)

Link: Search engine page size limits for indexing

Search Engine Indexing Limits: Where Do the Bots Stop? takes an experimental approach to seeing how big a page various search engine bots will fetch, and how much of large pages they index. I find this an interesting question because it affects how you organize your content and generate indexes to it, especially for dynamic websites with auto-generated aggregate pages.

One area not investigated in the article is how far down the pages the search engine bots will go looking for links to follow. I smell a followup project for someone.

(From Ned Batchelder, who has interesting information on the size of his own blog pages as a result of this.)

Link: Readable colour text combinations

Color Test Results is a summary of the results of surveying a bunch of Internet users about what colour text on what background they found the easiest to read. The summary quote:

As you can see, the most readable color combination is black text on white background; overall, there is a stronger preference for any combination containing black.

Not coincidentally, most of my text is black on white (or black on slightly off-white). I was interested to see that white on black actually rates fairly highly, because for me bright colours on black (like white, jwz's green, etc) rapidly give me eye-searing, headache inducing afterimages.

(The survey is pretty old, but human perception is unlikely to have changed that much in ten years or so.)

(From Bill de hÓra.)

Link: Scaling Apache at ftp.heanet.ie

ftp.heanet.ie serves a huge volume of mostly static file downloads with Apache on a single machine. This results in interesting Apache tuning issues, among other things.

If this sort of thing is your cup of tea, much of Colm MacCárthaigh's blog may be interesting.

(From Tim Bray.)


Page tools: See As Blog, See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.