sleirsgoevy

On offsets

After the recent release of ps5-kstuff with support for PS4 fpkg files, there is a lot of questions about porting this to other firmwares (4.50 and 4.51 are important in particular, because users of those firmwares can't update to 4.03, but they are still vulnerable to all of the used exploits). The main problem with these ports it the bespoke XOM, which prevents finding the offsets by simply examining the dumps. So in this document I'm going to go over what offsets are important for ps5-kstuff, and how I found them for 4.03.

These are the main categories of offsets:

1. Kernel data offsets, those can be found from data dumps that are not XOM-protected
2. Kernel text offsets pointed to by kernel data
3. doreti_iret offset (that's one offset, but it deserves its own word)
4. Offsets found from single-stepping of kernel functions

jetnet

Kilo Code CLI Comprehensive Cheatsheet

Updated against the current official Kilo CLI docs and CLI reference on 2026-04-12.

This sheet prefers the current Kilo terminology and file names.

• Use agents (not legacy “modes”) in day-to-day language.
• Use plan for architecture/planning work; it is the modern equivalent of the older “Architect” idea.
• Treat orchestrator as deprecated.
• Prefer kilo.jsonc / .kilo/kilo.jsonc for config today, even though some official pages still mention kilo.json, config.json, or older opencode.json(c) compatibility paths.

apiboxguru

{
  "xa-ar": "Arabia",
  "xa-en": "Arabia (en)",
  "ar-es": "Argentina",
  "au-en": "Australia",
  "at-de": "Austria",
  "be-fr": "Belgium (fr)",
  "be-nl": "Belgium (nl)",
  "br-pt": "Brazil",
  "bg-bg": "Bulgaria",

karpathy

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.

badlogic

/**
 * Diff Extension
 *
 * /diff command shows modified/deleted/new files from git status and opens
 * the selected file in VS Code's diff view.
 */

import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
import { DynamicBorder } from "@mariozechner/pi-coding-agent";
import { Container, Key, matchesKey, type SelectItem, SelectList, Text } from "@mariozechner/pi-tui";

april

# latest supported electron version as of october 2024
LATEST_SUPPORTED_VERSION=30
RED='\033[0;31m'
GREEN='\033[0;32m'
NC='\033[0m' # no color

mdfind "kind:app" 2>/dev/null | sort -u | while read app;
do
  filename="$app/Contents/Frameworks/Electron Framework.framework/Electron Framework"
  if [[ -f $filename ]]; then

rajkosto

#!/usr/bin/env python3


#
# Nokia/Alcatel-Lucent router backup configuration tool
# G2425 support added by rajkosto on 20/11/2022
# XS-2426G-B support added by rajkosto on 28/02/2023
#
# Features:
# - Unpack/repack .cfg files generated from the backup and restore functionnality

MangaD

Comprehensive Guide to Release, Debug, RelWithDebInfo, and MinSizeRel Build Types in CMake

Disclaimer: ChatGPT generated document.

In C++ development, build configurations affect performance, debugging capabilities, and binary size. CMake provides four standard build types:

1. Debug – Full debugging symbols, no optimizations.
2. Release – Maximum optimizations, no debugging symbols.