Notes from actually running the popular r/linuxonally optimization guide on a stock SteamOS install. Two of its steps silently fail on an unmodified system. This is the corrected version, with every step verified on-device.
Original guide: https://www.reddit.com/r/LinuxOnAlly/comments/1stcom1/ultimate_guide_i_installed_steamos_38_on_my_rog/
| # Development Guidelines | |
| You are writing code in a repo that follows strict TDD. These rules override your defaults. When they conflict with each other, the order is: the failing test -> §1 -> your language section -> conventions in the file you're editing. | |
| **If you notice you've already broken §1:** stop, delete the code you wrote out of order, restart from the test, and say so in your reply. Do not continue forward and backfill tests — a test written after the code passes for the wrong reason. Do not quietly fix it either; tell me it happened. | |
| ## 1. The four rules | |
| **1. Show the failing test before you write implementation.** Write the test, run it, paste the failure output. Then implement. Then run again. A bug fix begins with a test that reproduces the bug — if you can't reproduce it, say that instead of guessing at a fix. |
Issue: System clock instability, dual monitor flickering, and log noise on Ubuntu/Debian. Hardware: Beelink SER3 / AMD Ryzen 7 3750H with Radeon Vega Mobile Gfx.
This fixes the "TSC unstable" kernel panic and the "AMDGPU" screen flickering by adjusting boot parameters.
# Backup, apply fixes, and update bootloader in one go
When you move or resize partitions, GParted may change partition UUIDs. The bootloader (GRUB) and /etc/fstab reference partitions by UUID, so those references become invalid.
---
name: simplicity-reviewer
description: Use this agent when you need to review code changes for unnecessary complexity, over-engineering, or violations of the YAGNI (You Aren't Gonna Need It) principle. This agent should be called after code has been written or modified to ensure it maintains simplicity and clarity. Examples: <example>Context: The user has just implemented a new feature with configuration classes and abstraction layers. user: 'I've added a new configuration system for handling different client types with a factory pattern and multiple inheritance levels' assistant: 'Let me use the simplicity-reviewer agent to check if this implementation might be over-engineered for the current requirements' <commentary>Since the user has implemented what sounds like potentially complex architecture, use the simplicity-reviewer agent to evaluate if the complexity is justified.</commentary></example> <example>Context: The user has written a function with multiple layers of indirection. user: 'Here's my
| #!/bin/bash | |
| # Hammerspoon ShiftIt Setup Script for macOS | |
| # This script automates the installation and configuration of Hammerspoon with ShiftIt | |
| set -e # Exit on any error | |
| echo "🔨 Hammerspoon ShiftIt Setup Script" | |
| echo "====================================" | |
| echo "" |
| definition( | |
| name: "Device Refresher", | |
| namespace: "chutchens", | |
| author: "Cody Hutchens", | |
| description: "Refresh Z-Wave Devices on a schedule", | |
| category: "Convenience", | |
| iconUrl: "https://cdn-icons-png.flaticon.com/512/1828/1828817.png", | |
| iconX2Url: "https://cdn-icons-png.flaticon.com/512/1828/1828817.png" | |
| ) |