nodeg

Tracing route to FIN [216.81.59.173]:

  1    76 ms    96 ms    99 ms  192.168.1.254
  2     *        *        *     Request timed out.
  3    18 ms    18 ms    17 ms  195.66.225.189
  4    22 ms    24 ms    24 ms  10gigabitethernet1-1.core1.lon1.he.net [195.66.224.21]
  5    24 ms    24 ms    24 ms  10gigabitethernet2-4.core1.par2.he.net [72.52.92.42]
  6    97 ms    97 ms   100 ms  10gigabitethernet7-1.core1.ash1.he.net [184.105.213.93]
  7   109 ms   109 ms   112 ms  10gigabitethernet1-2.core1.atl1.he.net [184.105.213.110]
  8   109 ms   108 ms   108 ms  216.66.0.26

nodeg

Keybase proof

I hereby claim:

• I am nodeg on github.
• I am nodeg (https://keybase.io/nodeg) on keybase.
• I have a public key ASCIPHX_i_YDf3qfef4EzMBFumEON6TWern-TnvxvBw_Fgo

To claim this, I am signing this object:

nodeg

{
  "breeds": {
    "redhat": {
      "rhel4": {
        "signatures": [
          "RedHat/RPMS",
          "CentOS/RPMS"
        ],
        "version_file": "(redhat|sl|centos)-release-4(AS|WS|ES)[\\.-]+(.*)\\.rpm",
        "version_file_regex": "",

nodeg

#!/usr/bin/env python3

import argparse
import logging
from logging.config import dictConfig
import sys

__version__ = "0.1.0"
__author__ = "Tux Penguin <tux@example.net>"

nodeg

Removing a Mac's Firmware Password By Reflashing EFI ROM

According to Apple, the only way to remove an unknown firmware password from a MacBook (2011 and later) is to take it to the Apple Store with the original proof-of-purchase. However, I've found that there is another way, which I've been successful with for the unibody MacBook Pro--it's essentially just modifying a couple bytes in the EFI ROM, which should be simple. What's not simple, however, is figuring out how to read and write to the EFI chip. In this post, I'll talk about the process that I figured out and what worked for me.

The Official Method

Apple's method of resetting the firmware password is not reproducible, as Apple generates an SCBO file that unlocks the EFI using their private key. You can read more about this process here. The problem with this system is that, if you are in the unfortunate situation of neither having the firmware unlock pass

nodeg

#!/bin/zsh

# Define color codes
RED="\033[31m"
GREEN="\033[32m"
YELLOW="\033[33m"
BLUE="\033[34m"
RESET="\033[0m"

# Define arrays to track installed and failed apps

nodeg

name	code-review-turbo
description	Run a triple-agent code review on the current branch's PR. Waits for Cursor Bugbot, runs a Claude sub-agent and Codex in parallel, then cross-references all findings to filter out hallucinations. Use when you want a thorough, multi-perspective code review before merging.
metadata	disable-model-invocation argument-hint true [pr-number]
allowed-tools	Bash(gh:*) Bash(codex:*) Bash(cat:*) Bash(tee:*) Bash(sleep:*) Agent Read Grep Glob Write(/tmp/*)

Code Review Turbo

nodeg

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.