Skip to content

Instantly share code, notes, and snippets.

Lyle Franklin ljfranklin

Block or report user

Report or block ljfranklin

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
ljfranklin /
Created Apr 1, 2019
Setup instructions for Orange Pi Zero
View gist:59c02821d79859e7d0bb36a6c7c7d7a5
Instance control/7eb695e4-cfb6-47ab-bbe2-8d77cd299e18
Exit Code 1
Stdout Running smoke tests...
Running binaries smoke/isolation_segments/isolation_segments.test
[1544651752] CF-Isolation-Segment-Smoke-Tests - 4 specs - 4 nodes
[2018-12-12 21:55:52.75 (UTC)]> cf api
ljfranklin /
Last active Oct 8, 2018
Bootstrapping an Arch Linux installation

Install Arch Linux

Create a bootable Arch Linux USB

  1. Download arch ISO from
  2. Copy the ISO to the USB drive:
    • From a Linux machine:
    # replace sdX with usb drive listed by `fdisk -l`,
    # e.g. `/dev/sdb`, do NOT append a partition number
ljfranklin / add_key
Last active Dec 18, 2017
Script for OSX and Linux to add an SSH key and eject the disk
View add_key
#!/usr/bin/env bash
set -e
ljfranklin /
Last active Aug 2, 2017
Repro steps: MySQL service won't start in docker unless I touch all its files...

Docker version affected:

  • ERROR: Docker version 17.06.0-ce on OSX host
  • ERROR: Concourse CI container (Linux based executing with runC)
  • OK: Docker version 17.06.0-ce on Ubuntu 16.04 host


FROM debian:jessie

What is this?

Some ad-hoc performance testing on cf push. Variables are number of concurrent pushes, number of diego cells, CPU count of API VMs, while the number of API VMs is fixed at one. Disabled resource matching as the test script pushes the same app each time.

Main Findings:

  • A single cf push takes ~30-32 seconds regardless of number of cores, cells, or workers
  • The number of diego cells is the main limiter as concurrency increases
    • 32 concurrent pushes took ~59 seconds on average with 1 CC, 4 cores on API, 2 local workers, 4 diego cells
    • Dropped to ~42 seconds on average by scaling cells from 4 to 8 VMs
ljfranklin /
Last active Apr 21, 2017
Chapter 10 - 15 of Site Reliability Engineering

Chapter 10 - 15 of Site Reliability Engineering

Possible discussion topics:

  • Thoughts on this recommendation: Being on-call should strike a balance between quantity (percent of time spent doing on-call activities) and the quality (number of incidents that occurred while on-call).

    • Quantity: Spend at least 50% of time doing engineering, no more that 25% of remainder should be on-call
    • Quality: If too many incidents occur on a given on-call shift, the SRE will not have time to properly perform the incident response responsibilities such as: root-cause analysis, remediation, and follow-up activities like writing a postmortem and fixing bugs. Google found these activities take ~6 hours on average, so there is a max of 2 incidents per 12 hour shift of on-call.
  • One Emergency Response recommendation was to intentionally break your systems to see if they fail in the way you expect.

    • Anyone want to share experiences of doing this at Pivotal?
View conditional_link.erb

Keybase proof

I hereby claim:

  • I am ljfranklin on github.
  • I am ljfranklin ( on keybase.
  • I have a public key whose fingerprint is C15F 116B DAA9 AC25 0E20 2752 9486 66B3 EEC6 A0F0

To claim this, I am signing this object:

You can’t perform that action at this time.