See how a minor change to your commit message style can make a difference.
git commit -m"<type>(<optional scope>): <description>" \ -m"<optional body>" \ -m"<optional footer>"
| @echo off & setlocal enableextensions | |
| title Reset AnyDesk | |
| reg query HKEY_USERS\S-1-5-19 >NUL || (echo Please Run as administrator.& pause >NUL&exit) | |
| chcp 437 | |
| call :stop_any | |
| del /f "%ALLUSERSPROFILE%\AnyDesk\service.conf" | |
| del /f "%APPDATA%\AnyDesk\service.conf" | |
| copy /y "%APPDATA%\AnyDesk\user.conf" "%temp%\" | |
| rd /s /q "%temp%\thumbnails" 2>NUL | |
| xcopy /c /e /h /r /y /i /k "%APPDATA%\AnyDesk\thumbnails" "%temp%\thumbnails" |
See how a minor change to your commit message style can make a difference.
git commit -m"<type>(<optional scope>): <description>" \ -m"<optional body>" \ -m"<optional footer>"
| This file helps you mute every discord channel in your account | |
| you have to run it in the developer console on the web client | |
| follow the instructions below. this is tested on firefox and chrome. | |
| 1. open the discord webapp at https://discord.com/channels/@me | |
| 2. manually expand all server folders | |
| (note any servers inside collapsed server folders will not be modified, this can be useful for leaving certain groups of servers unmodified) | |
| 3. open browser network inspector | |
| 4. right click on a sever icon | |
| 5. (un)mute a server |
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.
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.
| #!/bin/zsh | |
| # WARNING! The script is meant to show how and what can be disabled. Don’t use it as it is, adapt it to your needs. | |
| # Credit: Original idea and script disable.sh by pwnsdx https://gist.github.com/pwnsdx/d87b034c4c0210b988040ad2f85a68d3 | |
| # Disabling unwanted services on macOS Big Sur (11), macOS Monterey (12), macOS Ventura (13), macOS Sonoma (14), macOS Sequoia (15) and macOS Tahoe (26) | |
| # Disabling SIP is required ("csrutil disable" from Terminal in Recovery) | |
| # Modifications are written in /private/var/db/com.apple.xpc.launchd/ disabled.plist, disabled.501.plist | |
| # To revert, delete /private/var/db/com.apple.xpc.launchd/ disabled.plist and disabled.501.plist and reboot. From Terminal : sudo rm -r /private/var/db/com.apple.xpc.launchd/* | |
| # user |
The first thing you'll need is someway to connect to the serial port on the Pi. This can be done with a USB to UART adapter (preferably one that has a individual DuPont connnectors), or via a second Pi (in which case you'll need three DuPont jumper wires, with female ends).
You'll want to be running GDB from the machine/VM that's also building the kernel, as the debugger will need access to all the source code. If you're running the build from a VM, and using a USB-serial adapter you'll need to make sure you can add this device to the VM.
note In theory you should have a cross-compiled GDB, one that runs on your system that is targetted to arm64. I believe Ubuntu has the 'gdb-multiarch' package available that contains a compatible version (I did my testing on Fedora). However, I didn't seem to have any issues using my x86-64 GDB to debug it. It might only be an issue when it needs to disassemble instructions.
The first step is to recompiling the kernel for the target Pi you want to debug. Ensure these c
A pattern for building personal knowledge bases using LLMs. Extended with lessons from building agentmemory 20K+ Stars ⭐️, a persistent memory engine for AI coding agents.
This builds on Andrej Karpathy's original LLM Wiki idea file. Everything in the original still applies. This document adds what we learned running the pattern in production: what breaks at scale, what's missing, and what separates a wiki that stays useful from one that rots.
The core insight is correct: stop re-deriving, start compiling. RAG retrieves and forgets. A wiki accumulates and compounds. The three-layer architecture (raw sources, wiki, schema) works. The operations (ingest, query, lint) cover the basics. If you haven't read the original, start there.
Recent AI research lands in existing codebases through specific extension points — modules, callbacks, or data-structure fields where a new method can plug in. Which extension points a repo provides determines which methods can be tried against it without a rewrite. We ran an agentic method-search loop that dispatches recent arxiv papers as draft integrations against 6 production repos; the by-product across 36 cycles was a per-repo inventory of the specific extension points those repos are missing.
Packaged as a CLI subcommand in remyxai-cli #46:
remyxai outrider autoresearch --repo owner/name \This script does most of the widget creating work for you if you've found the manual tutorials too hard to follow.
How to use:
Console tab