Ageless Linux ⧁

California has passed a law that requires operating system providers, as well as application providers, to verify a “users” age before allowing them to use the OS or application. Companies like Apple, Google, and Microsoft already have an infrastructure in place to comply with this. The 600+ Linux distributions do not. Nor can they afford to implement one. Same for all the independent application developers.

Ageless Linux pointedly, and rather adroitly, shows that the true purpose of the law is not to protect children. The point is a law enforcement mechanism to be used as a cudgel at the sole discretion of the Attorney General.

Claude Cycles ⧁

Donald Knuth on Claude AI solving a problem he’d been working on. I am somewhat embarrassed to admit this paper was where I learned the Claude the LLM was name after Claude Shannon, the father of information theory.

Calendar Synchronization Woes

I prefer desktop clients to web interfaces. I can CMD-tab between apps running on my computer far faster than I can switch to my web browser and then have to hunt through the open tabs to find my mail or calendar. (Yes, I know I can pin tabs. That’s another issue for another day.)

My employer uses Microsoft 365 for email and calendars, etc. Apple’s Calendar app uses Exchange Web Services (EWS) for synchronization. M365 uses a more modern sync stack, Graph + MAPI. The mismatch between these two methods can, and does, break synchronization between the Apple Calendar app and the M365 calendar it is showing. These breaks occur silently.

There are three background processes involved in synchronization for Mail and Calendar:

• exchangesyncd
• CalendarAgent
• accountsd

By quitting Mail.app and Calendar.app and then killing those processes, sometimes the synchronization will catch up.

sudo pkill exhangesyncd
sudo pkill CalendarAgent
sudo pkill accountsd

When this fails to correct the issue, there are more steps that can be tried.

You can clear the Exchange Calendar cache. This does not wipe out the calendars, it only resets the Exchange EWS state.

rm -rf ~/Library/Calendars/Exchange*
rm -rf ~/Library/Calendars/Calendar\ Cache*
rm -rf ~/Library/Calendars/com.apple.CalendarAgent/Data/Library/CalendarAgent

This should force a re-pull from M365. Reopen Calendar and give it time to synchronize.

The big-hammer solution, if the above steps fail, is to reboot the computer. Not ideal, but it (usually) works.

I can either switch to using the web interface or use Microsoft Outlook. As I said at the top, using web interfaces is not my thing. Switching to Outlook is a reasonable solution, but one I struggle with as the UI is clunky to my way of thinking.

For example: In the “new” Outlook, you can only have a multi-line (sender / subject / preview) view in the Inbox if you have the message reading pane enabled. If you want to hide the message until you are ready to open it, and therefore you disable the reading pane, you are forced to have a single line entry for each message in the Inbox.

The legacy Outlook does allow 1, 2, or 3 line previews with no reading pane, but Copilot isn’t available with the legacy Outlook.

I know I’m being stubborn and picky about the tools I use, and how I want to configure those tools. Not terribly surprising as my career in IT has been built on paying attention to minute details. The “how it looks” is as important as the “what it does”.

I’ll install and configure Outlook and give it a try, while searching for a solution to the synchronization issue between M365 and Calendar.app.

Hugo Helpers

I have four bash scripts that I use when working with my Hugo-based website.

drafts

Displays all content that have the keyword draft:

function drafts() {
  grep -ril content/ -e "^draft:"
}

deploy

Uses rsync to transfer the contents of public/ to my host
deploy defaults to running rsync with the --dry-run flag set. In order to actually deploy the site the --go flag has to be included.

function deploy() {
  local dry_run="--dry-run"
  if [[ "$1" == "--go" ]]; then
      dry_run=""
  fi
  rsync -azr --delete --include='.*' --info=name,stats2 "$dry_run" public/ pair:~/public_html/zanshin
}

build

Rebuilds the site into public/

function build() {
  hugo --cleanDestinationDir
}

create

Creates new content
create is by far the most complicated of these helper scripts. With four archetypes active on my site, the create command expects a type as well as a title. The type is converted to the correct archetype before it is used. The title is formatted to be all lowercase, and to replace alphanumeric words with a dash, and to compress repeated dashes to a single instance.

function create() {
    # create [post|link|video|note] <title>
    local type="$1"
    local title="$2"

    case "$type" in
        post)  local archetype="posts" ;;
        link)  local archetype="links" ;;
        video) local archetype="videos" ;;
        note)  local archetype="notes" ;;
        *)     echo "Unknown type: $type"; return 1 ;;
    esac

    # from https://onebite.dev/create-new-hugo-post-faster-with-bash/
    # replace alphanumeric words with a dash, compress repeated dashes to a single
    # dash, replace capital letters with lower case
    post=$(echo "$title" | sed -e 's/[^[:alnum:]]/-/g' | tr -s '-' | tr '[:upper:]' '[:lower:]').md
    hugo new "$archetype"/"$post"
    nvim content/"$archetype"/"$post"
}

Taxonomy

History

Like most websites, mine initially had only one kind of content: a post. I liked the link-style posts that Daring Fireball uses so I mimicked that for my site. Sometimes I like to post a YouTube video and I could never remember the shortcode Hugo uses for that, so I create a third content type: videos. The latest posting type I have added are notes. These are short posts with no visible title on the main page.

Each of these different content types are referred to as archetypes by Hugo. Since my types grew organically over the course of years, they were not all created consistently. In fact, each of the first three (posts, links, videos) used a different mechanism to identify the post type. This made setting up the archive list and individual post pages cumbersome.

As a part of adding notes to the mix, I have refactored all the archetypes and set things up in a more Hugo idiomatic way.

Archetypes

Each of the four archetypes I have has a template Markdown file in the archetypes directory. Each of these now have a common set of front matter parameters:

• title
• date
• type
• draft
• tags

Link posts have an additional parameter for the link URL. Video posts include a template for the YouTube shortcode. Having these templates makes creating new content much easier.

Layouts

Having a type parameter for each archetype makes constructing the site far simpler. The index.html layout can now easily include all four types, and can set type specific icons. Handling the combination of link URL and post URL for link posts is also controlled by the type parameter.

The single page layouts and list layout were also updated to make use of the type parameter.

The code for iterating over all the content to create the archive page is less complicated and easier to modify. Cleaning up the archetypes was worthwhile.

Front Matter

Each content type has YAML front matter. With over 2300 posts on my site, realigning them all to the same set of parameters, and eliminating no longer necessary parameters, and correcting the type parameter, was no mean feat.

Some of that work was accomplished using find, grep, and sed commands. Redoing the base parameters for every post was done via a Python script. The script leaves the content alone, but reworks the front matter. I did this on a copy of the content first, and only after all the wrinkles were ironed out, did I run it for real. The front_matter.py script was created with help of AI.

Tags

I have temporarily hidden tags from the metadata show for each posting. My tags are a mess, both in how they are captured in the post’s front matter, and in the proliferation of different tag values. Cleaning that mess up is a project for another day.

Pull Request

All of these changes made for one of the largest (if not the largest) pull request I’ve ever created. Over 3000 files modified, with 49,909 lines added and 57,270 lines removed.

Summary

My site is better structured, hews more closely to the “Hugo way” of doing things, and it now has four posting types. I have wanted short note postings for some time, having that in place feels good.

I’ll run from the Git branch for a while, to make sure everything is working as expected. Once I’m sure nothing is broken, I’ll merge it into the main branch.