| name | explain-diff-html |
|---|---|
| description | Use when the user asks for a rich explanation of a code change, diff, branch, or PR. Produces HTML output. |
Please make me a rich, interactive explanation of the specified code change.
It should have these sections:
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.
Slides and code examples from my "Pythons Sinister Secrets" presentation.
The slide deck can be downloaded here.
| RDP Eavesdropping and Hijacking | |
| ******************************* | |
| I spent some time this evening looking at ways to eavesdrop and hijack RDP sessions. Here is a gist of (semi) interesting findings | |
| that is not very new... | |
| =========== | |
| Inspiration | |
| =========== | |
| As you may already know... |
| #!/bin/bash | |
| # Desktop build | |
| MAKE="make -j 4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-" | |
| # C.H.I.P. build | |
| #MAKE="make" | |
| CDIR=$PWD | |
| LINUX=$CDIR/CHIP-linux | |
| WIFI=$CDIR/RTL8723BS |
By default when Nginx starts receiving a response from a FastCGI backend (such as PHP-FPM) it will buffer the response in memory before delivering it to the client. Any response larger than the set buffer size is saved to a temporary file on disk. This process is also explained at the Nginx ngx_http_fastcgi_module page document page.
Since disk is slow and memory is fast the aim is to get as many FastCGI responses passing through memory only. On the flip side we don't want to set an excessively large buffer as they are created and sized on a per request basis (i.e. it's not shared memory).
The related Nginx options are:
fastcgi_buffering appeared in Nginx 1.5.6 (1.6.0 stable) and can be used to turn buffering completely on/off. It's on by default.fastcgi_buffer_size](http://nginx.org/en/| var debug = process.env.NODE_ENV !== "production"; | |
| var webpack = require('webpack'); | |
| module.exports = { | |
| context: __dirname, | |
| devtool: debug ? "inline-sourcemap" : null, | |
| entry: "./js/scripts.js", | |
| output: { | |
| path: __dirname + "/js", | |
| filename: "scripts.min.js" |
Roll your own iPython Notebook server with Amazon Web Services (EC2) using their Free Tier.