holmanb

#!/bin/sh
# https://gist.github.com/smoser/14df5f0cd621e10d2282d7c90345e322
# This is /etc/schroot/setup.d/91smoser
# I use it to apply local updates to schroots.
# make sure it is executable (chmod +x).
# Things it does:
#   a.) sets proxy inside.  If apt proxy is configured outside, it will
#       apply that inside.
#   b.) uses a portion of 'apt-go-fast'
#       https://gist.github.com/smoser/5823699/

holmanb

Latency Comparison Numbers (~2012)
----------------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD

holmanb

Steps

1. Cream sugar and butter.
2. Add bananas and eggs.
3. Add flour, salt, and baking soda.
4. Optional: add chocolate chips, walnuts, pecans...
5. Bake in greased loaf pan at 350F for 45-50 min.

1x naner bread

holmanb

bcachefs multi-device with systemd

Multi-device bcachefs mounts in fstab cause system hang on boot. Additionally systemd integration for mounting degraded needs work to "just work" for users, using the same mount interface that they expect from mount.

During boot, the system should attempt mounting the filesystem degraded, and once a mount succeeds it should add subsequent disks that are part of a filesystem to the already mounted filesystem.

holmanb

Merge conflict represents drift between main and a release branch, which is not represented in a debian/patch and is not represented in the upstream source code.

Our model of merging upstream source code into our release series branches is problematic. It involves carrying an entire copy of the upstream source code in every release branch, which inevitably drifts due to human error, and results in routine unreviewable merges during every release.

An alternative

Imagine for a moment a different release model. Under this different model, the upstream branch would contain no debian/ directory (just like it is today). Downstream series release branches, however, would contain only debian/ directory. Under this different model, a release would happen by generating an orig.tar.gz directly from the tagged upstream release. To build a downstream package, one would cherry-pick the downstream debian/-only release branch onto the tagged release branch, then sbuild the result.

Benefits

holmanb

#!/usr/bin/env python3

import sys
import os
from pathlib import Path

help = """\
iterate a directory of directories, printing
the files in the sub-directory as alphabetical csv

holmanb

# We want to identify the number of community commits since Ubuntu 23.04 landed, which was cloud-init release 23.1
# Release 23.1.1 has commit hash 4896402b2b0
 
# Find the number of commits since 23.04:
$ git log --format='%ae' 4896402b2b0..HEAD | wc -l   
308

# Find the number of commits authored by non-Canonicalers
$ git log --format='%ae' 4896402b2b0..HEAD | grep -v -e canonical -e ubuntu -e bholman -e orndorf -e catmsred | wc -l  
130

holmanb

# Download image
wget https://download.freebsd.org/releases/VM-IMAGES/13.2-RELEASE/amd64/Latest/FreeBSD-13.2-RELEASE-amd64.qcow2.xz

# Decompress image
unxz FreeBSD-13.2-RELEASE-amd64.qcow2.xz

# Generate metadata.yaml
cat << EOF
architecture: x86_64
creation_date: 1643062675

holmanb

ubuntu@ubuntu:~$ systemd-analyze critical-chain cloud-init-local.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

cloud-init-local.service +1min 27.432s
└─systemd-remount-fs.service @35.183s +1.631s
  └─systemd-fsck-root.service @29.899s +3.711s
    └─systemd-journald.socket @26.502s
      └─system.slice @26.076s
        └─-.slice @26.073s

holmanb

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules