Because every time I want to flash a new ROM, I forgot how I did it the last time.
This is how I re-flashed my unbranded Samsung Galaxy S4 (german black edition) with a stock ROM (because Cyanogenmod crashed my phone all the time). The correct Stock ROM for my Galaxy S4 is: I9505XXUHOJ2_I9505OXAHOJ2_I9505XXUHOJ2
TLDR: JWTs should not be used for keeping your user logged in. They are not designed for this purpose, they are not secure, and there is a much better tool which is designed for it: regular cookie sessions.
If you've got a bit of time to watch a presentation on it, I highly recommend this talk: https://www.youtube.com/watch?v=pYeekwv3vC4 (Note that other topics are largely skimmed over, such as CSRF protection. You should learn about other topics from other sources. Also note that "valid" usecases for JWTs at the end of the video can also be easily handled by other, better, and more secure tools. Specifically, PASETO.)
A related topic: Don't use localStorage (or sessionStorage) for authentication credentials, including JWT tokens: https://www.rdegges.com/2018/please-stop-using-local-storage/
The reason to avoid JWTs comes down to a couple different points:
| Overview | |
|---|---|
| JSX HTML | <div>...</div> |
| JSX Component | <Component property={javascript} /><Component property='string' /> |
| JSX Component with Children | <Component>{children}</Component>reference: props.children |
| Escaping JavaScript | {...} |
require statements |
const React = require('react');const ReactDOM = require('react-dom'); |
npm modules |
react, react-dom |
While a lot of Node.js guides recommend using JWT as an alternative to session cookies (sometimes even mistakenly calling it "more secure than cookies"), this is a terrible idea. JWTs are absolutely not a secure way to deal with user authentication/sessions, and this article goes into more detail about that.
Secure user authentication requires the use of session cookies.
Cookies are small key/value pairs that are usually sent by a server, and stored on the client (often a browser). The client then sends this key/value pair back with every request, in a HTTP header. This way, unique clients can be identified between requests, and client-side settings can be stored and used by the server.
Session cookies are cookies containing a unique session ID that is generated by the server. This session ID is used by the server to identify the client whenever it makes a request, and to associate session data with that request.
*S
Reconstructed from Danny Postma's talk How I Built My Own AgentOS on Claude's Agent SDK (So You Can Too) (2026). This document is both a product spec for a human and an implementation prompt for an AI coding agent. Build exactly this system. Do not invent features that are not specified here.
Role contracts and prompts in this file are reconstructed from the talk, not his verbatim files. Mark every reconstructed prompt in code comments and docs as such.
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.
I've been running Andrej Karpathy's LLM Wiki pattern for several months — reading sources, compiling them into a compounding, git-diffable wiki instead of re-deriving everything from scratch every session — and I'm a genuine convert. But two things kept nagging at me: query salience (finding the right page reliably, not just something plausible) and token economy (not re-reading half the wiki to answer one question).
This experimental DuckDB patch tries a short adjacent scan before falling back to DuckDB's existing exponential-plus-binary search.
An ASOF join answers questions such as:
| """ | |
| The most atomic way to train and run inference for a GPT in pure, dependency-free Python. | |
| This file is the complete algorithm. | |
| Everything else is just efficiency. | |
| @karpathy | |
| """ | |
| import os # os.path.exists | |
| import math # math.log, math.exp |