Link: Linux Load Averages: Solving the Mystery

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

Load averages are an industry-critical metric – my company spendsmillions auto-scaling cloud instances based on them and other metrics– but on Linux there's some mystery around them. Linux load averagestrack not just runnable tasks, but also tasks in the uninterruptiblesleep state. Why? I've never seen an explanation. In this post


Some notes from my brief experience with the Grumpy transpiler for Python

I've been keeping an eye on Google's Grumpy Python to Go transpiler more orless since it was introduced because it's always been my great white hope for speeding up myPython code more or less effortlessly (and I like Go). However,until recently I had never actually tried to do anything much withit because I didn't really have a problem that it looked like agood fit for. What changed is that I finally got hit by the startupoverhead of small programs .

As


On the Internet, merely blocking eavesdropping is a big practical win

One of the things said against many basic encryption measures, suchas SMTP's generally weak TLS when one mail server is deliveringemail to another one, is that that they're unauthenticated and thuscompletely vulnerable to man in the middle attacks (and sometimesto downgrade attacks). This is (obviously) true, but it is focusedon the mathematical side of security. On the practical side, thereality is simple:

Forcing attackers to move from passive listening to activeinterception is almost always a big win .


How encryption without authentication would still be useful on the web

In HTTPS is a legacy protocol , I talkedabout how we are stuck with encryption being tightly coupled to website authentication then mentioned in an aside that they could besplit apart. In a comment, Alexy asked a good question:

How could encryption be useful at all without authentication? Withoutauthentication, any MITM (i.e. ISP) could easily pretend to be otherside and happily encrypt the connection. And we would still get ourISP-induced ads and tracking.

The limitation that Alexy mentions is absolutely


We care more about long term security updates than full long term support

We like running so-called 'LTS' (Long Term Support) releases of anyOS that we use, and more broadly of any software that we care about,because using LTS releases allows us to keep running the same versionfor a fairly long time. This is generally due to pragmatics on twolevels. First, testing and preparing a significant OS upgrade simplytakes time and there's only so much time available .Second, upgrades generally represent some amount of increased riskover our existing environment. If our


There will be no LTS release of the OmniOS Community Edition

At the end of my entry on how I was cautiously optimistic about OmniOSCE , I said:

[...] For a start, it's not clear to me if OmniOS CE r151022 willreceive long-term security updates or if users will be expected tomove to r151024 when it's released (and I suppose I should ask).

Well, I asked ,and the answer is a pretty unambiguous 'no' .The OmniOS


Our decision to restrict what we use for developing internal tools

A few years ago, we (my small sysadmin group) hit a trigger pointwhere we realized that we were writing internal sysadmin tools(including web things) in a steadily increasing collection ofprogramming languages, packages, and environments for doing thingslike web pages and apps. This was fine individually but created acollective problem, because in theory we want everyone to be ableto at least start to support and troubleshoot everything we haverunning. The more languages and environments we use across all ofour tools, the harder


I've been hit by the startup overhead of small programs in Python

I've written before about how I care about the resource usage andspeed of short running programs . However,that care has basically been theoretical. I knew this was an issuein general and it worried me because we have short running Pythonprograms, but it didn't impact me directly and our systems didn'tseem to be suffering as a result of it. Even DWiki running as aCGI was merely kind of embarrassing.

Today, I turned a hacky personal shell script into a better doneproduction ready


The problem with distributed authentication systems for big sites

In the comments on my entry on 'sign in with your Google/Facebook'authentication , people wished for a distributedcross-site web authentication system (of which there have been some number ) but then lamentedthat nobody significant adopted any of them (as Anton Eliasson put it). As it happens, I thinkthat there are good reasons for this disinterest by big sites beyondthe obvious business ones.

The simple version is that when you allow your users to authenticatethemselves using another site you put part of their


Imposing temporary CPU and memory resource limits on a user on Ubuntu 16.04

Suppose, not entirely hypothetically, that you sometimes have userson your primary login server who accidentally run big CPU-consumingand memory-eating compute jobs that will adversely impact themachine. You could kill their process or their entire login session,but that's both a drastic impact and potentially not a sure cure,and life gets complicated if they're running something involvingmultiple processes. In an ideal world you would probably want toconfigure this shared login server so that all users are confinedwith reasonable per-