Logbook

Sisyphus's inbox

From Oliver Burkeman's 2021 "Four Thousand Weeks"

In ancient Greek myth, the gods punish King Sisyphus for his arrogance by sentencing him to push an enormous boulder up a hill, only to see it roll back down again, an action he is condemned to repeat for all eternity. In the contemporary version, Sisyphus would empty his inbox, lean back, and take a deep breath, before hearing a familiar ping: "You have new messages . . ."

In another world I am the author of a plug-in (also named Sisyphus) for your email which tracks the progress of the enormous boulder and encourages you to cheer it on while it rolls back down the hill. (And looking at this display I realize I should turn it upside down to better represent the relative motion of the boulder.)

keeping shared community knowledge alive when your chat channel expires over time

I'm wrestling with the problem of keeping small group common knowledge around and up to date in the face of expiration and regular deletion of chats in free channels (e.g. Slack). This is similar to the problem that early Usenet had, when you couldn't count on any specific message being available because various sites had expiration times in the weeks to small number of months range for postings.

Having a shared wiki - or at least a thing that has wiki nature - sounds like it should be an answer. It needs to have a "recent changes" feed to stay relevant so that people who care can see what's new. Otherwise if new changes are invisible the whole thing goes stale very fast.

Slack "canvases" are appealing, but I fear putting too much into a free system that could change their usage policies. They have a lot of nice functions even on a free plan, with a one-channel-per-canvas structure. Relying on something free to keep long-term knowledge seems like a risk.

Monthly FAQ posts? That was what Usenet did. I'm not sure if monthly is the right pace, but periodic copying out of things that need to be said more than once has proven effective in the distant past. It's not clear that people used to search or even AI will reread the repetitive texts.

Amdahl's Law and the limits of high core count systems

Amdahl's Law (1967) notes that a parallel process always has some serial component to it, and the speedup by parallelization is limited by the serial path. It's the argument to be made for getting processors that have faster cores rather than more cores, because you get more incremental results by having fast cores than having a vast array of slow cores.

You can see the results of Amdahl's Law on a multicore processor running something complex (like a big software build) by using htop. The usual experience is that the system buzzes along for a long time with all the cores busy and then suddenly comes to a screeching halt when the serial part of some effort (e.g. a serial linker) has its turn to run. Your fancy 128-core system grinds away with only one or two cores running through that serial part of the process.

I found this "Cornell Virtual Workshop" https://cvw.cac.cornell.edu/parallel/intro/index on parallel computing in my search for a good writeup on Amdahl's Law. It also introduces "Gustafson's Law" (1988) https://cvw.cac.cornell.edu/parallel/efficiency/amdahls-law which suggests that as researchers get access to more cores, they focus not on making their runtimes go faster with the added processing power, but in doing more work within an acceptable amount of time. So if you decide that it's good enough to run a test suite in 10 minutes, and your system gets faster by adding more cores, instead of pushing to reduce the time to something smaller you'll be inclined to run more tests within that 10 minute time window.

See http://www.johngustafson.net/pubs/pub13/amdahl.htm for Gustafson's formulation of this, "One does not take a fixed-size problem and run it on various numbers of processors except when doing academic research; in practice, the problem size scales with the number of processors."

using "just" and a justfile to simplify common operations

"just is a handy way to save and run project-specific commands."

https://just.systems

If you are used to make and Makefiles, just fits right in. It doesn't have the complexity of dependency checking so it's not suitable as a full-scale replacement for a complicated build system, but what it does have is an easy configuration syntax and a straightforward way to save and then reuse shell commands associated with a project.

Use it for example to save complicated and rarely used command line invocations and alias them to something simpler.

It's a lot more compact than having a ~/bin file full of project-specific tooling, and when you invoke it with just -l it lists out everything that's been configured. All in all good things to help reduce the amount of human memory needed to keep complex systems running.

Ultralytics Github Actions plugin compromised by git branch name shell injection attack

Some notes on this novel attack, which injected a crypto miner into affected systems.

https://github.com/ultralytics/ultralytics/issues/18027

Code in the published wheel 8.3.41 is not what's in GitHub and appears to invoke mining. Users of ultralytics who install 8.3.41 will unknowingly execute an xmrig miner.

A related security advisory spells out the attack vector, which embeds shell code in the name of a branch. The branch variable is expanded in Github Actions and used to do its nefarious deeds.

https://github.com/advisories/GHSA-8v8w-v8xg-79rf

The tj-actions/branch-names GitHub Actions references the github.event.pull_request.head.ref and github.head_ref context variables within a GitHub Actions run step. The head ref variable is the branch name and can be used to execute arbitrary code using a specially crafted branch name.

An earlier security advisory for this same package is similar

https://github.com/advisories/GHSA-7x29-qqmq-v6qc

Any workflow that uses the action and runs on pull_request_target is vulnerable to arbitrary code execution within the context of the base branch. An attacker can use this to abuse the GITHUB_TOKEN or steal secrets from the workflow.

Github warns against this and other related attacks that leverage unsanitized and untrusted inputs, and gives examples of how to mitigate this risk:

https://securitylab.github.com/resources/github-actions-untrusted-input/

The best practice to avoid code and command injection vulnerabilities in GitHub workflows is to set the untrusted input value of the expression to an intermediate environment variable.

LinkedIn and AI

We trained an AI on LinkedIn on hot takes and thought leadership, and now half the posts are pointless numbered spangly bullshit.

You don't have to type every fleeting thought into the nearest rectangle

"You don't have to type every fleeting thought into the nearest rectangle", he wrote, copying the text into the nearest rectangle.

Sometimes people who you know and like use social media in a way that generates a lot of messages in a short time. On systems where there's an Algorithm that tends to get damped down, but on Mastodon which has a chronological approach to a timeline you can get a lot of messages from a single person, perhaps more than you are ready to deal with right now.

Mastodon has some options for reducing the posting load while not endangering any real-world friendships that might have reciprocal obligations.

• "hide boosts from", if the oversharing has something to do with high-intensity retooting. There is no subtlety to it, just "on" or "off", but it will reduce your feed.

• "mute", which will let you keep following someone but temporarily hide their posts from your feed. You can mute indefinitely or for a shorter amount of time.

• "lists", which you can add anyone who you are following to. In the default configuration, posts by a person on a list will be both your home timeline and the list timeline. When in the configuration setting for the list you select "Hide these posts from home", you can sequester your loquacious friend into that channel only. Please note that you have to follow someone for them to be eligible to be on your list, so the workflow I had of "add to list and unfollow" was exactly wrong. The how-to from Fedi.Tips will be useful: https://fedi.tips/how-to-use-the-lists-feature-on-mastodon/

• "filters", which let you selectively mute keywords from your timeline.

If you find yourself oversharing, there are options there as well. One which I am trying out is "memos" https://www.usememos.com an open source and self-hosted memo toolkit that gives you your own private "note to self" infrastructure complete with hashtags that doesn't need to be shared with the world. If you just have to type it in but don't really care that anyone else except yourself will see it, this is the place for that. I have an instance running on my MacBook for the past couple of days and it has been a rectangle to type into that doesn't require reciprocal anything.

"mqttui", an MQTT command line client and terminal user interface written in Rust

mqttui is a terminal user interface for the MQTT telemetry protocol. You point this client (written in Rust) at an MQTT broker, and it displays the current tree of messages as they are updated.

You can also use it as a functional replacement for the mosquitto_pub and mosquitto_sub command line clients.

Source code available from EdJoPaTo on Github: https://github.com/EdJoPaTo/mqttui

I seem to be collecting MQTT components, as part of having a toolkit to work with Home Assistant.

Via Terminal Trove, https://terminaltrove.com/mqttui/

Getting data into Home Assistant with MQTT

I am running Home Assistant at home. It kind of works, in a kind of haphazard way as if you had an old-school Lego set with no instructions and you just puttered around building things until you were bored or done. My dashboards are a bit of a mess, in the way that things are when you try them out to see if they work and then wander off to the next project once they do.

One of the limits of my exploration to date is that I really don't want to have a haunted house, and so I'm really rather reluctant to outfit every room with sensors and motors and automation that does things for me. This could get out of control pretty easily. But I do want to explore, and for that I want to have some data and devices (even simulated ones) to use.

My previous successful tries at HA have involved logging the size of my Gmail inbox, tracking how many spaces are free in the parking structures around Ann Arbor, and watching radon levels in the basement before and after remediation. My next round is going to be using MQTT, a simple publish/subscribe system, to push some data into HA that I can play with.

What kind of data? Well, the idea here is that if I don't want to buy a whole bunch of sensors then I can periodically type in some numbers with my fingers and send them in through mosquitto_pub which will publish them to a topic. They will show up in HA and then whateer automation I care do to can be downstream of that.

Some useful hints on the journey:

Install Mosquitto on HA: https://github.com/home-assistant/addons/blob/master/mosquitto/DOCS.md

Add the MQTT integration: https://www.home-assistant.io/integrations/mqtt

Install an MQTT client locally; on my Mac I just use mosquitto as well, installed with Homebrew.

HA supports MQTT device auto-discovery which is great but also not great because there's an assumption that every channel you set up will have a bunch of configuration with it. This gets in the way of exploration when getting started because there are too many options. So I followed this advice:

https://community.home-assistant.io/t/how-to-use-mosquitto-pub-to-create-new-mqtt-device-with-answer/443286/1

where you can create a new MQTT entity from a command line invocation.

Proof of work at the top! This is a command to set a HA entity that updates happiness (in volts)

mosquitto_pub -h host -u user -P password -t mood/happy -m $1

the vector of interestingness

Every once in a long while you get to pursue things because they are interesting, not because you did them yesterday or because they are lucrative or expected of you.

The bet is that if something is actually interesting to you, and if you can sustain that interest over time, then you'll get an opportunity to explore something far more deeply than if you were motivated by short-term gain. The further bet is that if it's interesting to you then you can make it interesting to someone else.

A caution: some things are interesting because they have been designed to be addictive, and you can fall into a trap of what you think is pursuing them because they are actually pursuing you. I suppose what I am after is "intrinsic interestingness" which is just about as undefinable as is gets.