Logbook

cultivating a community in a federated space

Cultivating a community around a product takes time and steady, ongoing effort, plus a measure of institutional support aligned with your work. You are looking to build a small crowd of friendlies, a larger crowd that knows of and nods approvingly when they reference your work, and enough of a digital footprint that you seem to be everywhere that's relevant. That doesn't happen right away - you have to keep working at it, every week and every month, showing up regularly with news or information or other displays of conspicuous competence.

It's harder to do this on federated systems than on centralized ones. You can't just buy ad time or keywords or whatever. You can't just wish that people would discover you, or that you would discover them. Federation means that the audience is where it is, including places that you haven't heard about yet. Somehow your digital visibility needs to overlap with the world's digital viewport, and you have to account for that in your plans.

On the plus side, whatever attention you get is unquestionably "earned media", which marketing people value at a multiple compared to "paid media". Just don't expect that attention will pour in all at once.

Originally posted to Hachyderm in an abbreviated form.

"birdchan"

As seen on Mastodon, to refer to Twitter.

running Tailscale's golink on fly.io

I am using golink from Tailscale to manage bookmarks for commonly used services. At its simplest, it remaps a URL of something like go/gmail/ to https://mail.google.com . At the most complicated, it will do a limited amount of address rewriting based on the path you give. The application is small and has modest needs, enough so that it fits easily on a Raspberry Pi 4 that has other things going on.

https://github.com/tailscale/golink

I had previously heard of fly.io as a place to host containerized applications. You get a teeny tiny Firecracker based microVM connected to a Wireguard network, hosted by a network that's in multiple data centers around the world. If you need performance in multiple regions, you can leverage their Anycast infrastructure. It's pretty nifty all in all.

https://fly.io/docs/reference/architecture/

golink helpfully comes with instructions on how to run on fly.io. They assume a little bit of familiarity with the system, which is easy to gain by poking at it a little. Very helpfully, the combination of the application and Tailscale means that you can deploy this microVM without a globally routed IPv4 address, and then access the golink service on it over your Tailscale network. It's a nice way to extend your private Tailnet one function at a time, and the golink service very easily fits into the free tier offering with lots of room to spare.

https://github.com/tailscale/golink/issues/63

The one catch: how do you migrate your data into this system? Helpfully, golink has a REST based API both for downloading an existing database and for creating new links. What was missing was an export-import or clone function that was based on the API.

jq -c '[.Short,.Long]' go.export.json | sed -e 's/^\[/curl -d short=/' -e 's/,/ -d long=/' -e 's/\]$/ go-1/' > import.sh

The above code takes an export file from golink and munges it into a script that can be run to import the data into your new instance. Caveat: you will lose reference counts, you'll lose link attribution if you have more than one user, and basically you'll be starting over. But if that's OK this is a quick restart to get going again.

fly.io has nice charts and graphs to keep you as aware as you want to be able application system usage. It has a comprehensive CLI, flyctl, which looks like it should let you script pretty much anything you'd want to handle from the command line. An hour into my effort I had something running and working within the free trial tier. I'll be looking for more sorts of services to host this way.

Obsidian at the 2500 page mark

I've been using Obsidian long enough to have accumulated about 2500 separate notes in it as of early February 2023. My goal, such as it is, it to let this total get to about 10000 pages, and then to re-evaluate everything. I'm on pace to hit that by something like 2027.

I use it for everything that might be useful in a daily diary. That means pages for dates, locations, names, etc. The rule of thumb: if it's a noun, it might be a page.

As you might expect with so many pages, most of them are short, suggesting they are there to jog my memory and not to replace it.

I like Obsidian but it's not my first go-around using a wiki as a personal knowledge base. The previous observations are probably true here too: if it gets large enough to really be interesting, it's too large to keep current. You're best off putting dates everywhere you possibly can, so that things that are stale are more obviously stale, and that observations that are old are treated as historical.

1600 pages: https://vielmetti.typepad.com/logbook/2022/06/obsidian-as-a-daily-note-taker-a-year-out.html

on the mass exodus from Twitter, the view from November 2022

From the looks of it, a lot of people are moving their short form public group chats to something other than Twitter. Lots of reasons for this, cascading from the $44 billion transaction that led to a change of control at the site.

There have been online mass exodus movements before.

New management by Yahoo after a $1.1 billion acquisition of Tumblr in 2013 had Tumblr users flee en masse to WordPress, taking their blogs with them. By 2019, Automattic - the makers of WordPress - acquired the site for a reported mere $3 million.

Similarly, the Yahoo purchase of the del.icio.us in 2005 for less than $30 million caused a great number of users to move their bookmarks to the competing Pinboard site, and Pinboard ultimately acquired the remaining husk of del.icio.us in 2017.

When America Online opened up access to Usenet News in September 1993, the "Eternal September" era of Usenet started, with newsgroups being overrun by clueless newbies with no understanding of or interest in the social norms of that system.

This brings us out of the past to the present day, when Twitter users are casting about for somewhere new to go.

One destination is group chat sites like Discord. You gather up all your friends, recruit some others, and talk amongst yourselves on a multichannel system that's members only.

A second option is to join one of the many sites that makes up Mastodon, a federated network of sites that interchange traffic using the ActivityPub protocol. Mastodon sites have seen a sharp uptick in traffic from Twitter refugees.

Because Mastodon is federated, you can join the network nearly anywhere and have a mostly similar experience. There are, however, a lot of differences between Mastodon sites, and your choice of a main server actually makes a difference. The biggest and most popular Mastodon sites are currently straining under load and will be slow and laggy. The little ones are harder to fund, but many of them have active moderation and a strong topical theme. On these sites reading the "local" feed of all posts generated by users of the server will be much closer to on topic for a single topic.

Twitter is staring at a series of crisis conditions at the moment, with rumors of impending mass layoffs, a pause in spending from some advertisers, and a whole pile of uncertainty over its future. There are lots of possible outcomes from this turmoil, but past history suggests strongly that the new Twitter under new management will cause many of its most valuable readers, contributors, and advertisers to change their focus of attention away from the site onto something new.

git security fixes lead to "fatal: transport 'file' not allowed" error in CI systems; CVE-2022-39253

If you are running a CI system that uses git to check out software for builds, and if that environment uses "git submodule add" to bring in files from the filesystem, then you might be affected by this change.

As of git v2.38.1 and the back port of the associated patch to v2.30.6, v2.31.5, v2.32.4, v2.33.5, v2.34.5, v2.35.5, v2.36.3, and v2.37.4, git will now refuse to clone repositories via the --local clone optimization if there are symbolic links present within the objects directory. The vulnerability, CVE-2022-39253, describes an attack that traverses symbolic links to break a security boundary. Cory Snider of Mirantis gets credit for identifying this issue.

https://github.blog/2022-10-18-git-security-vulnerabilities-announced/#cve-2022-39253 https://lore.kernel.org/lkml/xmqq4jw1uku5.fsf@gitster.g/

The Github security issue GHSA-3wp6-j8xr-qw85 provides a few more details, noting that the malicious actor can use this misfeature to attack "docker build" and "podman".

https://github.com/git/git/security/advisories/GHSA-3wp6-j8xr-qw85

The change in behavior is reported as bug 1993586 to Ubuntu's "Launchpad", and readers there have pinpointed the Ubuntu versions that have this change. The bug is closed as "invalid" as the change in behavior is as intended.

https://bugs.launchpad.net/ubuntu/+source/git/+bug/1993586

If your build is broken as a result of this change - noted by Jérôme Petazzoni to affect at least some Arch AUR packages and Debian apt packages - you will need to make changes. Here are some examples.

https://twitter.com/jpetazzo/status/1583112279012257797

Microsoft fixed their "go-infra" repository by adding the option -c protocol.file.allow=always to their git invocation in their test infra.

https://github.com/microsoft/go-infra/pull/71/files

The stack project of Haskell set a global variable with git config --global protocol.file.allow always in their integration test system. The "spack" package manager did likewise.

https://github.com/commercialhaskell/stack/pull/5909/files https://github.com/spack/spack/pull/33429

As of this writing, this Github search for the error string has 13 open issues, so there's some set of people who are chasing this down right now to get their build systems back online.

https://github.com/search?q=%22fatal%3A+transport+%27file%27+not+allowed%22&type=issues

SHEFA-2 cuts take the Shetland Islands offline

Two separate fiber cuts on the SHEFA-2 cable that connects the Faroe Islands to Scotland via the Shetland Islands took most of communications on the islands offline on 20 October 2022. Services were restored the next day, per a BBC report.

https://www.bbc.com/news/uk-scotland-north-east-orkney-shetland-63337473

SHEFA-2 ("SHEtland-FAroes") is run by SHEFA, a 100% owned subsidiary of Faroese Telecom. SHEFA-2 was put into service in 2008, replacing an earlier SHEFA-1 which dated from 1971.

https://www.shefa.fo

SubmarineCableMap.com has a detailed map, listing landing points at Maywick and Sandwick.

https://www.submarinecablemap.com/submarine-cable/shefa-2

BBC Radio Shetland is the broadcaster to the archipelago, and its evening broadcast of the 20th of October has an account of the impact on the 23,000 residents there. Phone service, internet service, automatic teller machines, and access to emergency services were all affected.

https://www.mixcloud.com/BBCShetland/good-evening-shetland-thursday-20th-of-october-2022/

In the case of a single fiber cut, there is redundancy, in the sense that traffic from Shetland has an alternate return path via the Faroe and the FARICE-1 cable. But there are only two ways out, and if both of them are offline.

Subsea cables go out of service with some regularity. Fishing trawlers which tow nets at the very bottom of the ocean will snag a cable, and this is a suspected cause of the Shetland incident. Other natural causes for outages include earthquakes and the associated submarine landslides that can wreck service. Submarine Telecoms Forum tracks these outages, which have affected diverse cables such as PPC-1 (Papua New Guinea), IMEWE (Egypt), Greenland Connect (Greenland), SEAMEWE-5 (Pakistan), and APG (Vietnam) in the past few months.

https://subtelforum.com/category/cable-faults-maintenance/

A more sinister threat to subsea cables is deliberate damage by military interests. The UK government cut off Germany's submarine telegraph cables in 1914 during World War I, which forced German communications onto the worldwide British network where they could be more easily intercepted and decoded.

https://www.bbc.com/news/world-europe-42367551

Since then the cable network has vastly expanded, but the threat is still there. And while there's no indication that the Shetland incident on SHEFA-2 is anything other than a routine failure, policy makers have recently raised an alarm of recent Russian activity in mapping the cable network.

https://www.theguardian.com/uk-news/2022/jan/08/uk-military-chief-warns-of-russian-threat-to-vital-undersea-cables

Converting hot takes into a proper weblog

I wonder what my blog would look like if I took my hot Twitter takes and wrote 500 words on each rather than 280 characters.

(Yes, I still have a blog, a couple of them actually.)

The instant publication of a tweet is very appealing, with a quick hit of dopamine possible if you happen to get really lucky and write something that triggers a quick response. That's great, in the same way that a rat pressing a lever thinks that getting fed is great.

In the olden days of web rings and RSS feeds and Google scooping up all of the blog content it could find, posting to a blog felt a lot more "live". If you wrote about something that people were searching for right at that moment, there was an opportunity to do serious numbers. Those days are mostly gone, with changes to the world leaving blogs behind as the source of hot news.

The biggest advantage of the blog format over the tweet (aside from its absurd length) is that you have a lot more room to ponder an idea and a lot more space to link out to other people's takes on the same subject. The writing has some space to breathe, there's a lot more chances to edit, and the shelf life of the words is a lot longer.

Not many people read blogs though any more so they fail for general audience seeking. We're in the Newsletter Era, so I suppose the reasonable option is to somehow cajole people into signing up for everything you publish. Direct email does increase the chance that any given thing will be read. The downside I guess is that readers expect to write back! Suddenly your hot take is an extended conversation and maybe you were just chasing a passing interest rather than a deep thought to ponder.

One thing is for sure: when you write blog instead of a tweet, there's a whole lot more time spent typing your own ideas, and a lot less time hitting the refresh button hoping someone else somewhere in the world has said something interesting. I can get into that.

My next small, hackable computer - a Steam Deck?

For the longest time the Raspberry Pi has been my go to for a small, inexpensive, easy to buy and hackable computer. I have a few of them running, powering a DMR gateway and an ADS-B receiver. Software support is good, third party peripheral support is good, and lots of people have gone to some substantial efforts to get workable tools running on arm64.

However;

The Pi has gotten very hard to buy over the past year, with most of the production inventory diverted to industrial and OEM clients. There is good supply of the RP2040 microcontroller, and the Pi folks seem to have diverted their "here, have a cheap and cheerful device to learn from" to systems built around that chip. That's great, don't get me wrong, but not my focus of interest right now.

This brings me to the subject line. What if the next obvious target for a small and hackable computer is not a Pi, but instead is a game machine? The Steam Deck runs all the Steam games, but it's Linux based, and it's easy to drop into a Linux environment. There's a built in display and a built in battery and easy ways to connect to external devices. And the form factor - a "cyberdeck" and not a bare board - is appealing.

Yes, it costs more; way more, to be honest. As of this writing there's still a queue for ordering so it will take a little while to ship. One per customer, please, so you're not going to see insane clusters of these things.

Some interesting reading:

Putting Tailscale on the Steam Deck, from Tailscale's Xe Iaso. Some of the trickier bits of systemd work you need to do in order to get the Tailscale VPN software running on the Steam Deck. You'll learn about systemd-sysext, which uses an overlay filesystem (overlayfs) to install components "on top of" an underlying immutable filesystem.

Running KrakenSDR on the Steam Deck, RTL-SDR Blog. KrakenSDR is a multi-device coherent software defined radio, with applications like direction finding for radio signals ("fox hunting"). The blog notes that the Steam deck "is essentially a powerful handheld computer with s creen and good battery life, so it makes an excellent mobile SDR computing platform too." For this particular application you'd want an external battery pack to power the SDR.

Listening to HAM radio on my Steam Deck, /u/freeloz on Reddit. A demo with video of SDR reception using an AirSPY HF+, a loop antenna, and the Gqrx software.

Flathub is a home for "flatpaks", a portable software installation format supported natively on SteamOS. This lets you develop your own applications and package them for easy use on the platform, and also opens up a library of software from the Linux world that's easier to install.

Of course, the main market for the Steam Deck is games, either brand new titles or old games via emulation.

updates and later additions

Direction-finding with help from the Steam Deck, Hackaday, 2022. Aaron (cemaxecuter) demonstrates radio direction finding with KrakenSDR and a Steam Deck as a portable controller in marine operations on a boat on Lake Redwine in Georgia. Like and subscribe to his Youtube channel for more information about DragonOS Focal, a software distribution for SDR applications.

Asahi Linux on MacBook Air M1 - an update

Previously: Asahi Linux alpha on M1 MacBook Air / Apple Silicon, first impressions

After a few months of idleness, I decided to revisit my Asahi Linux installation on my MacBook Air. As you may remember, Asahi Linux is adapted for the Apple Silicon (M1 and M2) chips, and is based on Arch Linux. It installs in a partiton on your Mac and you can dual boot it (long press the power key at start to bring up a menu).

The first snag in getting online was logging in. I am sure that I picked an easy to remember yet secure password five months ago, so easy to remember and so secure that I didn't write it down. Oops. Couldn't remember it, the usual tries didn't work, so it was time to break in.

Fortunately, Arch Linux has a nice primer on resetting a lost root password which jogged my memory as to what was possible. When you edit the boot sequence so that the init process is replaced with a shell - e.g "init=/bin/sh" - it's straightforward to boot into a single-user mode and run "passwd" to fix up the situation. Make sure that the drive in question is mounted read-write, and make sure you "sync" a few times after doing the edits so that the buffers are flushed to disk.

That little problem disposed with, it was time to update the system. Arch uses the "pacman" package manager, and the command "pacman -Syu" is all you need to trigger a complete update. There were 800+ packages that had updates. To be extra sure that everything was all in sync after all of those changes, I did a reboot and the system came up just fine.

When last I tried this, the Chromium browser didn't work because it didn't support the 16K pages that Asahi (and the Mac hardware) provides. Since then that bug has been fixed and Chromium starts just fine, with the caveat that it throws a couple of GPU related complaints along the lines of "Exiting GPU process due to errors during initialization" when starting. This is Chromium 104.0.5112.101 installed with "pacman -S chromium". Chromium did work well enough that a little bit of web browsing worked ok, but I didn't try anything very complex (the usual show-stopper is Youtube).

I had previously installed Firefox and that seems to continue to be just fine.

One goal I have on this system is to get some Electron based apps up and running, notably Obsidian. Obsidian has an "Appimage" flavor of distribution for arm64, so I tried that, and it immediately crashed with a segmentation fault (16K pages again). I can't tell at a glance which version of Electron that Obsidian ships with, but with a similar discussion for VSCode the winning version seems to be some flavor of Electron 19. I did not pursue trying VSCode out, but the VSCode issue Update to Electron 19 looks like the cutting edge of discussion. I'll make a point to try to get that working next time I'm in.

Asahi doesn't start up out of the box with an ssh daemon installed, so I put opensshd on the system and enabled it. Together with Tailscale, this got me to the point where I successfully logged into Asahi from my Android phone. A next step will be to enable "Tailscale ssh" on Asahi, but I stopped before adding that step.

My usual observations about the Linux desktop user interface still hold - everything feels just a little bit less precise than the Mac desktop (or even the Windows desktop) that I am used to, and there are enough key bindings that I am also used to that are different enough to make things confusing for occasional use.

All in all a good evening's exercise, good to have a system in reserve for when you need to see how things are. I'm not ready though to have Asahi as a daily driver.