Mentions

Schevana - a happy place functional desktop for Lisp fans written in Chez Scheme paveluv/Schevana t.co

@Tim_Hua_ Astra didn't cheat. But their prompt tells it to look for repetition, so it was handed the hypothesis. Then it found the loop by comparing activations on looping vs normal text. Feels more like classic steering than Astra reading weights. github.com/RikiyaT/lm_understand-logs/blob/main/e… t.co

@Ultrademic bit biased since I make it, but Sigma File Manager. free, open source, has tabs and split view, and v2 is on Tauri now so it's pretty light aleksey-hoffman/sigma-file-manager

Hi HN, I've been running a lot of coding agents (claude code, codex, ...) sessions recently (typically 100+ per project), across multiple repos, worktrees, and branches. At some point, keeping track of the agents became a problem of its own. I kept forgetting which agent was working on which branch/worktree, which sessions were waiting for me, and which changes I still needed to review among the many chats I have open. This drives me to built repobs Chengxuan-Li/repobs to solve this. It's a local dashboard that: - Can view repo, branches, worktrees, and commits in a tree/timeline view (like the traditional git branch graph) - Tracks coding agent sessions associated with each branch and worktree, with their status (working, needs input, etc.) - Tracks agent planned items and progress (number of tasks completed out of total number of tasks) - Allows user to annotate agent states, to-do checklist, notes for each agent - Will support some automation (WIP) This tool only needs read-only access to agent sessions and git. Everything the user views and edits is local. I'm particularly interested in how others manage parallel coding agents, and the challenges encountered in managing them. Also, what information/features would you want in a dashboard like this? Right now I'm adding some new features so that agents in non-git folders can also be tracked as such.

Chisel project is here RadicalCSG/com.chisel and Tachyon UI is here LogicalError/TachyonUI both close to release 1.0 (tachyon only tested on nvidia gpus so far)

Read or download directly, free, no sign-up (slides as PDF and PowerPoint, one-page summary, full paper): datademocracy.substack.com Permanent record (DOI): doi.org All versions: doi.org Model, data and code: desfitz/ai-compute-limits Open question: ai-compute-limits#1 SSRN: papers.ssrn.com Comments: desmond.fitzpatrick@nvara.ai

Lucide ships new icons often, so we do too. Since launch, lucide-extended has added 128 filled and 122 duotone icons, with new ones every week, so it stays in step with the latest Lucide release. Same names, always free and open source. applifted/lucide-extended

I turned my Steam Deck into a wireless Wii U GamePad for my Steam Machine This is probably a pretty niche thing, but basically I wanted to use my Steam Deck as a wireless Wii U GamePad for my Steam Machine. I wanted the screen, controls, and touch input on the Deck while the Steam Machine ran the game, so I could chill across the room or whatever. This is already possible thanks to the efforts of some incredible people. I eventually got the basic setup working, but it involved piecing together KDE virtual displays, Sunshine, Moonlight, audio settings, and a bunch of terminal commands from different guides and posts. It worked, but I hated having to open Konsole every time I wanted to use it. I wanted something very easy and simple to use. So I made Dual Screen Mode. It sets up the Linux host and gives you an on/off shortcut for the virtual display. The idea is to use the Deck like a Wii U GamePad, a DS or 3DS bottom screen, or just a wireless second monitor. Moonlight still has to be installed on the handheld and paired with Sunshine manually. I did not try to automate that part. Once it is paired, though, the intended use is simple: double-click the shortcut, connect with Moonlight, and go. I know I did not invent any of this. Sunshine, Moonlight, KDE, krfb, and the underlying ideas all existed already. I just tried to gather the scattered setup steps into one friendly thing. It is just a simple little project I threw together over the weekend. I initially made this for my own setup and use, and have only tested it on my Steam Machine with a Steam Deck. I used it with Cemu and Azahar. Cemu worked really well as a Wii U GamePad. I also ran into an annoying touch issue with Azahar where touching the Deck was affecting the host desktop instead of the virtual display. That ended up being a KDE and Sunshine input mapping issue, and the current version handles it automatically. There are probably still some rough edges. I have not tested every handheld or KDE setup, and emulator profiles, gyro, and microphone forwarding are outside the project for now. The host also needs to stay in KDE Desktop Mode while the virtual display is active. The “Both” audio option is still a work in progress too. Also, full disclosure, AI helped me with some of the coding. This is my first project like this, so I used the help where I needed it, but the idea came from wanting this for my own setup and then making it easier to repeat. I know this may be useless to most people, but I figured someone else might want to try it too. If you do, let me know how it goes or what kind of setup you are using. GitHub: slinky010/dual-screen-mode

Blockbench is a low-poly 3D model editor. Currently there is no ARM Linux installer, but it's not too hard to build from source. JannisX11/blockbench youtu.be

Is Mario Kart: Double Dash possible? The game just got a recomp that was released recently. badcompany94-rcmp/project-tandem

Very interesting, thanks. I just started using claude code to drive filmcraft-cli for producing product videos, using elevenlabs for voiceover. The only part Ive been doing myself is the actual screen recording on mobile, but maybe cc can do that part too somehow. One of my recent edits instagram.com storytold/filmcraft

Announcing XIUIplus Announcing XIUI Plus Hey all, we've been working on a new version of XIUI for a bit now and we're excited to share the first alpha release with folks. We're moving from an Ashita addon to an Ashita plugin, and we've rewritten the entirety of XIUI in C++. This should mean virtually no performance impact on your game, richer fonts, smoother animations, and easier access for us to develop against the native UI of FFXI. Here's a list of a few things we've done: - Ability to disable any native game UI element (party/solo UI, etc.) - Native Chat (that respects your filters & settings) - Movable native elements (rearranging the command menu) - Improved rendering for textures, fonts, and more. You can grab the alpha release here: github.com/Team-XIUI/xiuiplus-releases/releases/t… Instructions - Download the .dll - Place it in your /plugins folder - Run /load xiuiplus Notes Please note there is still a ways to go before we consider this even beta, hotbars and crossbars have had very little testing. We'll be looking at feedback on our Discord and you are also welcome to open issues on our github for problems and feature requests. We also know this is a big change, we're working on being able to migrate all of your XIUI settings to XIUI+, however there are some differences in how menus are built that not everything will transition 1:1. We recommend trying to create a fresh profile on XIUI+ and messing with menus to find what works for you. We apologize for any issues or bugs you find along the way. With this change, we will no longer be cutting private server specific versions of XIUI. You will need to work with private server staff to get them to accept our plugin. Classic XI Example & XIV1.0 UI Example - Team XIUI

i can't believe how fast it is, too see: wasmtime#2566

I recorded 1,180 TTS clips to find out what voices misread in LLM output Every voice agent has the same seam: a language model writes text for a reader, and a text-to-speech model reads it for a listener. The two were never designed for each other. The model writes `**Step 1:** run npm install and the voice says "asterisk asterisk step one". It writes 1,250 units and some voices say "one two five zero". It writes a Turkish phone number as 0532 123 45 67` and the voice reads it as a single number with the wrong suffix. I kept patching these one at a time in prompts and regexes until I decided to do it properly. This post is about the result, and more about how I measured it, because the measuring turned out to be the hard part. What the library does speechready runs between the LLM and the TTS. Four stages: 1. Clean. Markdown and LLM artefacts: headings, emphasis, links, tables, emoji, URLs, fenced code. Every judgment call is an option. Code blocks are dropped by default, or replaced with "See the code block." 2. Verbalize. Numbers, ordinals, decimals, fractions, percentages, currency, dates, times, phone numbers, units, acronyms, written out in the target language. Turkish applies vowel harmony to suffixes, and reads foreign tech acronyms the way Turkish developers say them ("en pi em"). 3. Compile. Pause, spell and emphasis intents rendered to the provider's syntax: SSML for Azure, Google and Polly, break tags for ElevenLabs, punctuation for the providers that have nothing. 4. Chunk. Sentence splitting and packing under the model's request limit, plus a streaming segmenter that releases sentences from an LLM token stream as boundaries are confirmed. There is a Python package and a TypeScript package. Both pass the same 217 YAML fixtures and produce the same output for every one of them. Measuring whether it helps A text preprocessor is easy to make look good: pick an ugly input, show the tidy output. I wanted to know whether voices actually read the processed text correctly more often, so I built a loop that could tell me. 145 lines of English and Turkish: assistant answers with markdown, dates, phone numbers, prices, URLs, identifiers, and control prose that should pass through untouched. 16 voices across 7 providers. Each line synthesized twice, as written and after speechready. Both recordings transcribed back with gpt-4o-transcribe and scored against the intended words. The scorer forgives the ways a transcription engine writes speech down: digits for spoken numbers, "21st" for "twenty-first", "NPM" for "en pi em". It only ever lowers the error, and it applies to both sides equally. A line counts as misread when more than a fifth of the words are wrong. Most of the 145 lines are the fixture inputs the rules were developed against, plus control prose and a handful of real assistant answers, so this is a go/no-go measurement on curated cases, not a held-out production sample. Result, on the same 1,180 recordings: | | As written | With speechready | | --- | --- | --- | | All | 32% | 8% | | English | 29% | 7% | | Turkish | 37% | 10% | Every voice improved. Control prose did not regress. The weakest result is Cartesia's Turkish, where the voice speaks with an English accent and the transcription model misses words that were rendered correctly. Because most of those lines are the library's own test inputs, I also ran a held-out check: 60 answers that gpt-4.1-mini gave to typical voice-agent questions, generated after the rules were written, scored against a narration the same model wrote independently, on four voices. Misreads went from 10% to 8% and mean word error rate did not move. Concise assistant answers simply contain few of the things the library fixes; when they do contain markdown, prices, phone numbers or code, that is where the gain is. The held-out run also found two bugs, a dotted Turkish time with a suffix and a spaced minus read as a range, which is what held-out data is for. You can listen to the pairs, with what the STT heard under each: berkerbatur.github.io What I learned from the eval - Scoring was harder than the library. Half of the early "misreads" were the scorer failing to forgive a transcription convention. Every fix to the scorer applied to both the raw and the processed side, so it never favored the library. - Providers disagree on what they handle. Google's Chirp voices read 25°C fine; others do not. The provider profiles are YAML, and this is where that knowledge lives. - Turkish needs its own rules, not translated English ones. Suffixes attach to the spoken form of a number, and the spoken form depends on the last vowel. Using it pip install speechready # Python 3.10+ npm install speechready # Node 20+, 35 kB, no dependencies from speechready import prepare prepare("**Step 1:** run `npm install`. [pause 1s]", provider="elevenlabs", model="eleven_multilingual_v2").text # 'Step 1: run npm install. <break time="1s" />' For LiveKit Agents, speechready.integrations.livekit.text_transform(...) goes in tts_text_transforms. For Pipecat, speechready.integrations.pipecat.text_transform(...) goes in a TTS service's text_transforms. Neither imports the framework. Playground, in the browser: berkerbatur.github.io English and Turkish for now. If you want another language, the fixtures show exactly what a locale has to cover, and the eval harness will tell you whether it worked.

Kraken Upscale, a free open source video and image upscaler, has been updated today. Check it out at the link below. krakenunbound/kraken-upscale t.co

@ecomerateHQ github.com/rockerroblox tell me im wrong.

Lightweight Ollama CLI client for running LLMs on a headless-capable Raspberry Pi — feedback on the RC wanted I've been working on LemonPie, a lightweight Ollama CLI client that I made out of necessity. I wanted to run an LLM directly on a Raspberry Pi 4, on Pi OS Lite — monitor and keyboard plugged in, no desktop, just a terminal. The Pi obviously can’t run a model with any real speed on its own, so the setup ended up being: Ollama server on my main PC, and the Pi just needs something lightweight to talk to it over the network from that terminal. There are other clients out there, but I wanted something I built and understood end to end, and lightweight enough to not think twice about running on constrained hardware. So I built LemonPie — a small CLI for chatting with an Ollama server and managing sessions. Pi OS Lite is what pushed me to build it, but there’s nothing Pi-specific about it. It’s just Python, so it should run anywhere you can get a Python environment running, headless or not. What it does: - lm — start/continue chat sessions with an Ollama model, streamed output, works fine on terminal only setups or over SSH - lmConfig --init — interactive first-time setup: asks for your server URL, checks it’s reachable, and lets you pick from the models you have installed on the server - lmConfig — manage server host and model aliases from the terminal - Sessions persist locally, so you can pick a conversation back up later - Model switching mid-session, atomic config writes, handles Ctrl-C without breaking &#8203; pip install lemonpie-cli lmConfig --init lm -n "hello" GitHub: famousStratum/LemonPie PyPI: pypi.org GPLv3, open source, I’m the author. It’s at 0.2.0rc2 right now. Worth being clear about: this is still 0.x. (pre-release), once I tag 0.2.0 “stable,” that’s stable within 0.x. There’s still a lot more to add (model verification, code completion, better error handling), and the CLI surface may still change before a 1.0. If anyone wants to try the rc before I cut the final tag, I’d appreciate it.

Blacklevel: Replacement Android/Google TV launcher & companion mac app The Google TV home screen on my A80J is mostly ads and “recommended” rows I never asked for. So I built Blacklevel: - A quiet home screen: a clock, your apps, now playing, and your inputs. That’s it. It’s dark and dims when idle, so it’s easy on OLED. - A Mac menu bar remote: volume, inputs, apps, picture settings and typing into the TV. It uses Sony’s own IP control, so you don’t need the phone app. No ads, no accounts, no cloud. It’s just a TV. Each app works independently of the other. I’ve only tested it on an XR-65A80J, and it still has rough edges. It should work on most BRAVIA Google TV and Android TV sets from 2015 onward. I’d love to hear how it works on yours. Source: itsonlyjames/blacklevel Downloads: github.com/itsonlyjames/blacklevel/releases/latest

@MaximeRivest Try Browser Harness next to let your agent use your existing Chrome logins. browser-use/browser-harness I co-founded browser-use. Thank you for trying Cloud!

github.com/Gh0stllm/GH0ST/tree/research/gh0st-wat… Anyone can check the live progress here , All publicly verifiable. robinhood:0x2eb2849cde7957b86d0dfd4b59e450a9f9d15559 Watch is on its way

پیام‌های Saved Messages تلگرام رو بالاخره مرتب کن! 📂 Arcivo یک ابزار متن‌باز برای جست‌وجوی سریع، شناسایی فایل‌های تکراری، برچسب‌گذاری و مدیریت فضای ذخیره‌سازی تلگرامه؛ با پردازش کاملاً محلی. sadult/arcivo

Karpathy's nanochat proves the recipe was the moat, not the compute 🧠 A decent ChatGPT you can train for ~$100 turns LLM building from a datacenter project into a weekend project. That changes who gets to build in this space. karpathy/nanochat

@cho_jpn あっ、cho!さん♪ １波あたり1000Hzです～ LouisHitchcock/FPVGateC5MK 受信モジュールはこちらのファームウエアを使っているのですが、スキャン台数が減ると、どんどん速くなっていって１波だと、6300Hzくらいになってしまっていたので、そこだけ修正しました。。。

DMCA Takedown Notice filed directly within GitHub against the entirety of Anthropic’s repository (anthropics/formal-math) Unlicensed utilization of background-independent O(1) Complexity Matrix j=1/j stops now The S-1/A risk disclosures are flashing red 🔒formal-math#44

@burkeholland @Logitech @github "Logi Options+" is only available in Windows and Mac, so I ported it to Linux ;) enriquemorenotent/logioptions-linux

@progerallworld @zeke @fayazara Hi Ruslan! I'd start with iMCP and Companion: an MCP server and an MCP client, both complete Mac apps. iMCP has the boring bits around the main feature, like the menu bar, permission prompts, and Settings. mattt/iMCP mattt/Companion

Hierarchos Native update: faster streaming on Intel HD 520, RDNA3 qualification, and a GPT-2 parity fix + DeepSeek v4.1 Flash I’ve pushed a substantial update to Hierarchos Native, my Rust + Vulkan backend for language-model training, fine-tuning, and inference. This past week focused on porting the recent RDNA3 work to Intel Gen9, improving parameter streaming, and taking the changes back to physical RDNA3 hardware for regression testing. The native runtime requires no Python, PyTorch, CUDA, ROCm, or oneAPI installation. PyTorch and Transformers are used as development references. What changed: - DeepSeek V4.1 Flash port and optimization work: fused selected-expert execution, batched expert uploads, packed-weight paths, checkpoint caching, and native LoRA/rsLoRA training with save/resume/export. - Broader Gen9 coverage: fixes for Qwen3-Next padding and DBRX expert layouts, plus streaming paths for T5/BART/Switch encoder-decoder projections. - Less streaming overhead: retained file handles, fewer temporary allocations, coalesced reads, and removal of an unused hidden-state download. - Gen9 kernel improvements: parallel sparse-attention selection and hyper-connection statistics, plus fused SiLU/up-projection multiplication. - Bounded upload batching: small streamed projections can share a GPU submission within a 1 MiB coalesced payload window. The biggest Gen9 result was closing the Llama-wide streaming slowdown on an i5-6200U / Intel HD Graphics 520: |Measurement|Previous pass|Final pass| |:-|:-|:-| |Median forward latency|11.016 ms|4.597 ms| |GPU submissions per forward|19|4| That’s 58.3% lower latency, with every measured logit word unchanged. Across eight scaled architecture controls, the combined optimization passes reduced streaming medians by 42.4–78.4% and resident medians by 3.5–32.1% against the documented baseline. Gen9 measurements and methodology. Back on the Ryzen Z1 Extreme / RDNA3 device, the regression sweep caught a padded GPT-2 numerical parity issue. The fix matches the pinned CPU reference’s GELU/tanh behavior and short-row attention arithmetic. The original CPU expectations, checkpoints, and strict tolerance stayed unchanged. The completed RDNA3 qualification now passes: - 166/166 forward runs, covering 43 scaled profiles across 26 architecture identifiers. - 72/72 generation requests, checking cache-requested and full-prefix execution. - Maximum absolute CPU logit error strictly below 2e-7, with rtol=0. - Bit-identical resident and streamed outputs throughout the measured matrix. - Native streaming/offload tests and GPT-2 LoRA gradient, optimizer, save/reload, and resume checks. The GPT-2 repair is selected specifically for RDNA3; all 585 pre-existing shader binaries remain unchanged. Final GPT-2 closure and evidence. The RDNA3 testing also recorded lower V4.1 latency versus the previous handoff: 24.4% for resident prefill, 50.2% for resident decode, 17.2% for streamed prefill, and 18.4% for streamed decode. These are measurements on retained scaled checkpoints, rather than production-model throughput figures. RDNA3 measurements. Parameters remain resident by default; supported frozen-weight streaming is opt-in through --stream-parameters or the GUI. The registry contains 146 text architectures, while this qualification specifically covers the 26 identifiers above. Multimodal towers and arbitrary production checkpoints need their own validation. If you’re experimenting with native Vulkan training or inference on older Intel graphics or AMD hardware, I’d be interested in your results—and which workloads you’d like tested next.

@Nefarious_Trey Chaos2Cured/FreeLattice This is my open repo. FreeLattice is the site. Lots to clean up. •

[webOS 3.9.3] Successfully intercepted the physical Home button to launch LightKeeper (HomeKeyBridge v0.1.6) Saludos! For anyone who tinkers with webOS (especially older releases like 3.9.x), remapping or intercepting the physical Home button on LG remotes has historically been considered nearly impossible or extremely messy to do without breaking LSM or freezing remote input. I managed to solve this cleanly with a lightweight daemon called HomeKeyBridge that intercepts the Home button and automatically launches Lightkeeper (`io.github.chiotas.lightkeeper`). ### How it works - Passive `evdev` tap: It reads `/dev/input/event1-4` in user space without `EVIOCGRAB`. Since it never locks or monopolizes the input devices, your remote will never freeze or lose control even if the background daemon stops. - Keycode Detection: Listens for standard keys (`125`, `172`) and specifically LG's internal physical remote code `773` (`0x305`). - Direct Luna Bus Launch: The moment the keypress is detected, it triggers a non-blocking `luna-send` call to immediately launch LightKeeper into the foreground. - Reboot Persistence: Comes with a setup hook in `/var/lib/webosbrew/init.d/70-homekeybridge` so it auto-starts smoothly on TV boot. - Zero telemetry, no UI bloat, and near-zero CPU/RAM footprint. Tested and working rock solid on an **LG 55UJ651V-ZA running webOS 3.9.3** using both Magic Remote and traditional IR remotes. ### GitHub & Pre-built IPK The project is fully open source, and the standalone `.ipk` is ready to install via webOS Dev Manager or SSH: - 🔗 GitHub Repository: knives69/HomeKeyBridge - 📦 Download v0.1.6 (.ipk): github.com/knives69/HomeKeyBridge/releases/tag/v0… Hasta el post lo hice con IA slop hulio!

Best Port for Bloodborne PC Testing which version would be the best, most performant. This is on an apu with an igpu mind you (ryzen ai max+ 395 with radeon 8060s) so your performance may differ, but from my testing this is what I got: bbhost: +210 fps awakens fork +160 fps Mrsuss60 fork ~140 fps medo bbport fork +120 fps Personally I'd recommend bbhost if you want the most performance and best experience, and it's the official port of the Hunter's Dream server (It also has a steam deck version that runs near 60 fps everywhere). Awaken's fork is also compatible and usable online with the server, Mrsuss60 should also be compatible with the Hunter's Dream server if you intend to do co-op, invasions, chalice dungeons, etc.. medo's fork is no longer compatible with the server though, I think they force their users to use his own server now (weird because that just splits the community and hurts everyone including themselves, so less players overall for everyone to play with). Can find the latest releases of bbhost on github github.com/droogie/bbhost/releases

Releasing official WASI binaries as part of releases Now that python3 Platforms/WASI release is a thing, I'm getting really close to wanting to have the RM release official WASI binaries via github.com/python/release-tools/blob/main/.github… . But before I go and send Savannah a PR to let me do it for Python 3.16 (which I have discussed with her and other RMs before over the years and gotten tacit approval for), I wanted to see if there were any concerns or anything people wanted to see happen before I did that. The closest I could see is testing the resulting .tar.xz file, but from what I can tell we don't actually test installed copies of Python on a buildbot or CI. It would be a little annoying as I would be duplicating either make test or make buildbottest manually since the Makefile doesn't work on files unpacked in some random place that isn't tied to the build. Plus it would seemingly be a test for making sure I didn't miss copying a file more than validating the interpreter didn't break. But if people want me to add a second test run in CI or repurpose the WASI buildbot to handle this I can (I don't think having the buildbot test both an install and a build from a checkout is worth it). My guess, though, is that people don't want a second full test run just for this. Otherwise I am going to do one last pass at asking folks in the WASI community if there's any specific build flags I should be thinking about before opening a PR.

Fixing TrueHD & Passthrough on the Xiaomi TV Box S 3rd Gen Ok I wrote this post yesterday: reddit.com now here is the AI written guide, I am too lazy to write all this myself. i proof read it all. easiest way to do this yourself is follow this root guide (not written by me, very easy though) gist.github.com and then you can apply the simple patches mentioned in the ai guide below. It's meant to be pasted into claude / codex / pi so you don't need to understand it all. I recommend Opus 5.5 or GPT 6.1 Sol. I tried Kimi and deepseek, they could not patch this in memory correctly. TLDR what this does is way #1, it increases the audio buffer so complex scenes don't cut out. but its not quite 100% perfect, the dolby encoder is running on device even with pass through on, and the better fix makes pass through work, but then there is audio coming out way faster than video, so you need to add a +150ms audio fix for the second approach. IF you apply the passthrough fix, you need moonfin's app packer or any other client that uses its own app packer, then the audio works at the best quality without hitting limits. Feel free to ask me any questions I will try to help. Fixing TrueHD Atmos dropouts on Amlogic Google TV boxes (guide for your AI agent) Paste this to Claude Code, Codex or a similar agent that has ADB access to the box. It's written as instructions for the agent. Tested on one box only: **Xiaomi MiTV-AFMU0 (Amlogic S905X5M), Google TV 14, build `UKG3.250107.001.V816.0.25.7.22.UZFAABX`**, into a Sonos Arc (a MAT soundbar with no TrueHD decoder), with Jellyfin and the Moonfin client. **Needs root (Magisk).** Nothing on `/vendor` is changed: the audio HAL is patched in memory at every boot, and deleting one script undoes it. On any other build the offsets will differ. --- Instructions for the agent Ground rules - Patch only `/vendor/lib/hw/audio.primary.amlogic.so` **in the running HAL process** (`android.hardware.audio.service-droidlogic`), through `/proc/<pid>/mem`, as root. Never replace the file. - First check the library md5 is `d860a16f622c8c2e9524aff1b9354b80`. If it differs, stop and find each spot by function name and instruction pattern in a disassembly (32-bit Thumb-2; the R-E segment's file offset = vaddr − 0x10000). Write a patch only after reading the expected bytes back. - Use toybox `/system/bin/dd` (BusyBox `dd` gets EIO seeking in `/proc/pid/mem`). Run the script under BusyBox ash (`/data/adb/magisk/busybox sh`): the device's mksh sign-extends addresses above 0x80000000. - Don't restart the audio HAL by hand. After every change, check that HDMI really carries MAT: the kernel log should say `iec_info: rate: 192000, codec_type:0x7`. A silent fallback to 5.1 sounds clean. Boot script (shared by both fixes) Put this in `/data/adb/service.d/mat-start.sh` (chmod 755). It waits for the HAL, checks the md5 and the exact original bytes, patches, logs to `/data/local/tmp/mat-start.log`, and re-patches within 1 s if the HAL restarts. Only `PATCHES` changes between fix 1 and fix 2. ```sh #!/system/bin/sh LIB=/vendor/lib/hw/audio.primary.amlogic.so STOCK_MD5=d860a16f622c8c2e9524aff1b9354b80 PATCHES="..." # see fix 1 / fix 2, format offset:stock:new LOG=/data/local/tmp/mat-start.log DD=/system/bin/dd log() { echo "$(date '+%m-%d %H:%M:%S') $*" >> $LOG; } [ "$(md5sum $LIB | cut -d' ' -f1)" = "$STOCK_MD5" ] || { log "not the stock build"; exit 0; } patch_pid() { base=$(awk -v l=$LIB '$6 == l && $3 == "00000000" { split($1, a, "-"); print a[1]; exit }' /proc/$1/maps) [ -n "$base" ] || return 1 for p in $PATCHES; do off=${p%%:*}; rest=${p#*:}; want=${rest%%:*}; to=${rest#*:} addr=$((0x$base + off)) cur=$($DD if=/proc/$1/mem bs=1 skip=$addr count=2 2>/dev/null | od -An -tx1 | tr -d ' \n') if [ "$cur" = "$want" ]; then printf "\\$(printf %o 0x${to%??})\\$(printf %o 0x${to#??})" | $DD of=/proc/$1/mem bs=1 seek=$addr conv=notrunc 2>/dev/null log "pid $1 $off: $cur -> $to" elif [ "$cur" != "$to" ]; then log "pid $1 $off: unexpected bytes '$cur', not patching" fi done } done_pid= while true; do pid=$(pidof android.hardware.audio.service-droidlogic) if [ -n "$pid" ] && [ "$pid" != "$done_pid" ] && grep -q "$LIB" /proc/$pid/maps 2>/dev/null; then patch_pid $pid && done_pid=$pid fi sleep 1 done ``` ### Fix 1: keep Dolby's encoder, make it stop dropping out (~95 %) How it works: the box decodes TrueHD with Dolby MS12 and re-encodes it to MAT for the soundbar. Stock, it starts playback with only ~16 ms of audio queued, and gives MS12 an output buffer of just 4 MAT frames. Loud spikes underrun the sound card (20–70 ms tears), and quiet passages overflow the buffer (minute-long runs of `risk to write out of bounds` dips). ``` PATCHES="0x961cc:fb40:00bf 0x961c8:4065:8055 0xb67f0:8000:c000" ``` - `0x961cc` `lsrs r3, r7` → `nop`: start playback with the buffer full, not half full. - `0x961c8` 8ch MAT period 3072 → 4096 (256 KiB, the kernel's limit; larger silently falls back to 5.1). - `0xb67f0` `lsls r0, r0, #2` → `#3`: MS12's MAT output buffer holds 8 frames, not 4. Must land before the first TrueHD play after boot (the buffer is allocated once), which the boot script does. Digital audio output stays on **Automatic**. Works with any app that passes TrueHD through. - **Pro:** A/V sync is handled by the HAL automatically. No player changes, no manual delay. - **Con:** Dolby's encoder is still in the path. It occasionally stalls for longer than the ~55 ms of buffer at heavy moments, and you get a rare short dip. No buffer setting can fix that, because the sound-card buffer is already at its maximum. Fix 2: real passthrough, no Dolby encoder (the better fix) The "Digital audio output: Passthrough" toggle is a lie on this firmware for TrueHD/MAT. A player sending TrueHD still goes through MS12's decode and re-encode. A player that packs its own IEC 61937 MAT stream (Kodi, or Moonfin's "IEC packer"), which should be the purest path, gets stuttering video and silence: the HAL hard-codes app IEC 61937 streams to **2-channel 48 kHz PCM** out of the S/PDIF block. The HAL does contain a working MAT pass-through (`mat_bypass_process`, 192 kHz 8ch straight to HDMI), but three checks keep app streams out of it, and it double-frees an output on first use. Use fix 1's patches **plus** four more: ``` PATCHES="0x961cc:fb40:00bf 0x961c8:4065:8055 0xb67f0:8000:c000 0xb4968:3046:a019 0xa7e10:07d1:07db 0xb6958:0028:8042 0xb6970:52d0:52e0" ``` - `0xb4968` `mov r0, r6` → `adds r0, r4, r6`: `is_ms12_passthrough` counts an app's MAT stream, not only TrueHD. - `0xa7e10` `bne` → `blt`: the process wrapper calls the bypass for every format from TrueHD up. - `0xb6958` `cmpeq r0, #0` → `cmpeq r0, r0`: `mat_bypass_process` no longer gives up in MS12 "continuous mode" (always on). - `0xb6970` `beq.w` → `b`: reuse the already-open output instead of closing it. The original close double-frees and aborts the audio HAL (Scudo "invalid chunk state" in `aml_audio_spdifout_close`). Then: 1. Set **Settings → Display & Sound → Audio → Digital audio output → Passthrough**. InAutomatic the bypass is never taken. 2. In the player, turn on its own IEC 61937 packing (Moonfin: passthrough output "IEC packer"). 3. Reboot. Check `cat /data/local/tmp/mat-start.log` for seven `->` lines. While a TrueHD filmplays, `dumpsys media.audio_flinger` should show an `AUDIO_FORMAT_IEC61937` 192000 Hz8-channel output at rate ≈ 1.00, and the kernel `codec_type:0x7`, `CT_MAT`. - **Pro:** no Dolby decode/encode at all, so its stalls are gone. Bit-exact TrueHD to the soundbar, with 0 underruns in testing. - **Con:** this path skips the HAL's latency compensation, so sound arrives ~100–140 ms **early** (+140 ms looked right with an Arc). The player has to correct it. Moonfin's normal audio-delay control doesn't apply to its packer, so this needs a Moonfin build with the packer delay fix (a pull request is on its way upstream: 10 ms steps, remembered). Other apps (Netflix etc.) aren't affected and keep their normal sync. - If the audio HAL ever restarts, it comes back in Automatic mode until the next reboot. Reboot rather than toggle. ### Undo Delete `/data/adb/service.d/mat-start.sh` and reboot; set Digital audio output back to Automatic.

hi it’s running native on netcast tv 2013 4.5 plz star my slop project: ballslober12/OptiCraftNetcastEdition #LG #Homebrew #Minecraft #Opticraft #Netcast t.co

Ghost Recon Breakpoint FSR UPSCALING mod anaCS-26/grb-fsr Built on the GRB-DLSS mod that was posted here, but for AMD cards: it replaces the game's TAA with FSR 4.1 directly, so you don't need OptiScaler or anything else. AMD's FSR DLLs are included, so you just extract the zip next to GRB.exe, set Anti-Aliasing to TAA, and press Home for the menu (render resolution, FSR version, sharpness). I've only tested it on my own GPU so far, so let me know how it runs on other cards (other GPUs get FSR 3.1).

For the first time across the entire assault bench, the overall geometric mean has reached and surpassed C -O2. nightwarelabz/krell <#Krell> Some few tests, and it will be live on the repo. t.co

Want to be Hired: Remote, Full Time | Part Time | Contract (open to ML internships) Resume: drive.google.com Overview: Backend and AI engineer, 5 years of software engineering and 3 on AI products, finishing a BSc in Applied Mathematics & CS at the University of Lagos (2027). Looking for an AI engineer, ML intern or backend role that runs alongside a structured ML programme I'm about two-thirds through. Available immediately. StaffPilot (founder/CTO): AI marketing agent. A planner turns each request into a structured spec, and a router sends it to a copy, image or video expert and picks the model. Routing is rule-based for now, with every choice and outcome logged so it can become a learned policy. Prices, logos and captions are composited deterministically. Product-photo path: SAM and BiRefNet masks keep edits off the product, Depth Anything v2 drives parallax, and DINOv2 and LPIPS check the result against the original. Eval came first: a 150–200 item double-labelled golden set (Cohen's kappa), then a cascade of deterministic checks, small learned scorers and an LLM judge feeding an acceptance gate calibrated to a target defect rate. Celsius (SilverBrain AI): LLM eval and monitoring platform handling 500k+ inference logs a month. I also fine-tuned LLMs for document classification, which raised accuracy by 25%. Climate Wavers: disaster-recognition models (CV + NLP), a LLaMA assistant, and an OpenVINO vision model, all served on OpenShift. SNBS: architected the national statistics data platform for Somalia (async analytics pipelines). Stack: Python (PyTorch, FastAPI, Django, Celery), TypeScript, Postgres, Redis, RabbitMQ, Docker/K8s, AWS/GCP, Prometheus/Grafana. All GPU work on cloud instances. ML programme, Applied track (everything implemented from scratch, NumPy first, then PyTorch): Done: Classical ML: GLMs, SVMs with SMO, trees and ensembles, k-means, EM and PCA, value iteration. Deep learning: CNNs and ResNet, detection and segmentation, ViT and self-supervised learning. NLP: word2vec, LSTMs, seq2seq with attention, the Transformer, BERT/GPT/T5 fine-tuning, RoPE and the KV cache, RAG and agents. Generative models: PixelCNN, VAEs, flows, GANs, DDPM and latent diffusion. Now: DQN and PPO, reward models, RLHF and DPO. Next: BPE tokenization, mixed precision, parallelism and scaling laws (CS336), SFT and DPO at scale, LLM evaluation and judge reliability. ML programme, Theoretical track (Shalev-Shwartz & Ben-David, Mohri, ESL, CS229M): Done: PAC learning (realizable and agnostic), uniform convergence, No Free Lunch. VC dimension, the Sauer–Shelah lemma and the fundamental theorem. SRM and MDL, the computational complexity of learning, boosting. Convex learning, stability and SGD, SVMs and kernels. Asymptotics and the MLE, concentration inequalities, Rademacher complexity, covering numbers and Dudley chaining. Now: margin theory and RKHS generalization. Next: non-convex landscapes, implicit regularization, the NTK, double descent and benign overfitting, online learning and regret. Interested in work where evaluation, agents or inference infrastructure is the core problem. GitHub: github.com/Olagold-hackxx · LinkedIn: linkedin.com/in/abdulqoyyum-aileru

Which AI Is Most Accurate in 2026? The Honest Answer, With the Data Short answer: as of late 2026, no single model is the most accurate at everything — and the two models you'd actually name are not the same model. Google's Gemini 4 Carbon, Anthropic's Claude Opus 5.5 and OpenAI's GPT-6 Astra sit within about two points of each other at the top of independent reasoning benchmarks, close enough that on any given hard question, which one is "most accurate" is nearly a coin flip. Meanwhile the model that invents the fewest facts is none of the three. That second part surprises people, so here it is plainly: on the most widely used hallucination benchmark, the top-ranked model is a 32-billion-parameter open model, and several frontier flagships hallucinate roughly five times more often than it does. "Smartest" and "most factually careful" are not the same leaderboard. > Accuracy isn't one number. Decide which kind you need, and the answer changes models. "Accurate" means three different things Almost every argument about which AI is most accurate is two people comparing different columns. There are three: - Reasoning accuracy — can it get hard, multi-step problems right? Captured by composite benchmark scores. - Factual grounding — when handed a document or asked about the world, does it stay faithful or quietly invent? Captured by hallucination benchmarks. - Task accuracy — does it get your kind of work right? Nobody measures this but you. Pick the wrong column and you'll buy the wrong model. Reasoning accuracy: the top three are inside the noise Artificial Analysis aggregates a battery of hard evaluations — reasoning, math, code, knowledge — into a single Intelligence Index. The current top of that board: - Gemini 4 Carbon (high) — 59 - Claude Opus 5.5 (max) — 58 - GPT-6 Astra (max) — 57 - GPT-6.1 Sol (max) — 55 - Claude Sonnet 5.5 (max) — 54 Read that spread honestly. A two-point gap on a composite of benchmarks is not a reliable predictor of which model will nail your next question. It tells you these three are in the same class; it does not tell you one is dependably right where another is wrong. One detail in that table matters more than the ranking: those are specific reasoning-effort settings. The same model family swings from the mid-30s to the high-50s depending on how hard you let it think and how long you let it run. How you configure a top model moves accuracy more than which top model you choose. A cheap setting on the best model loses to a generous setting on the third-best. If you want to see where the board stands this week rather than this quarter, our live AI model leaderboard tracks it — because the standings do move. Factual grounding: the flagships are mid-pack Vectara's hallucination leaderboard uses its HHEM evaluation model to test something narrow and useful: hand a model a document, ask for a summary, and measure how often the summary asserts something the document doesn't support. The standings (last updated October 22, 2026) do not look like the intelligence board at all: - Finix S1 32B — 1.8% hallucination rate (98.2% factual consistency) - GPT-5.4 Nano — 3.1% - Gemini 2.5 Flash-Lite — 3.3% - Phi-4 — 3.7% - GPT-6 Sol — 6.5% - GPT-6 Astra — 8.7% - GPT-5.5 — 9.3% - Claude Opus 5.5 — 9.9% - Gemini 3.1 Pro — 10.4% Small, fast, cheap models occupy the top. Frontier flagships land in the middle. Two honest caveats, because this chart gets badly over-read: - It measures grounded summarization, not world knowledge. Staying faithful to a document in front of you is a narrower job than knowing a fact cold, and a model can be excellent at one and weak at the other. - Verbosity is a confound. Claude Opus 5.5 averaged 192-word summaries — the longest in that group — and more sentences mean more surface area to drift. A terse model simply has less to be wrong about. Even with those caveats, the practical lesson holds: if your task is "don't make anything up about this document," the biggest and most expensive model is not automatically the safest pick. That's also why learning to spot and prevent hallucinations beats shopping for a model you hope won't have them. Task accuracy: the only column that pays your bills Benchmarks are proxies. Your work is the real test, and accuracy leadership splits sharply by task: - Code — correctness is checkable, so test it. Run the output. A model that writes beautiful broken code scores worse than a blunt one that compiles. See our job-by-job coding comparison. - Research and anything cited — grade on sourcing behavior, not prose. Does it give URLs, and do they resolve? Our source-first research guide goes deeper. - Math and quantitative work — check the steps, not the answer. Confident arithmetic errors are the classic failure. - Writing and summarizing — faithfulness to your source beats fluency, which is exactly where the hallucination board, not the intelligence board, is the right guide. Spend twenty minutes running ten of your own real prompts through three models. That beats any leaderboard for your specific use, because it measures the only distribution you care about. Why this question has a shelf life Three forces keep flipping the answer. Release cadence: a new frontier model or reasoning tier lands every few weeks, and the order changes. Benchmark saturation: once everyone scores above 90 on a test, it stops separating anyone. Contamination: popular benchmarks leak into training data, inflating scores without improving real accuracy. So this question has an expiry date. Any article — including this one — naming a single winner is naming a temporary one. The honest answer is not a model name. The durable answer is a method, not a model Here's the part that doesn't expire: when several strong models independently reach the same answer, that answer is far more likely to be right — and when they split, you've just found the part you shouldn't trust yet. This isn't a marketing line, it's a measured effect. Research on multi-agent debate found that having multiple model instances propose, critique and defend their answers across rounds improved both reasoning and factual validity, reducing fallacious answers and hallucinations — and it works on ordinary black-box models, no retraining required. The related self-consistency work found the same principle inside a single model: sample several independent reasoning paths, take the answer they converge on, and accuracy goes up. Why it works is simple. Models fail in different directions — different training data, architectures, habits. A fabrication invented by one model is very unlikely to be invented identically by three others. Agreement filters noise; disagreement is a smoke alarm. That beats any single model's confidence, which is the signal most people mistake for correctness. The catch is that doing it by hand is tedious — three tabs, three answers, and you still referee the conflict yourself. That's the job an adjudicated cross-model verdict does: put the question to a panel of the strongest models at once, surface where they agree and where they split, and have a final model reconcile the disagreement into one cited answer with the dissent on the record. A practical accuracy checklist - Give it the source. Grounded answers hallucinate far less than answers from memory. - Ask for citations, then open them. A URL that 404s is a fabrication tell, and it's a fast one to check. - Turn up the reasoning effort for anything hard. It's the cheapest accuracy upgrade available. - Don't read confidence as correctness. Tone is not evidence. See our honest take on single-model reliability. - For anything consequential, ask more than one model — and treat their disagreement as the finding, not an inconvenience. - Re-check your model choice monthly. The current standings are not last quarter's. The bottom line There is no permanently most accurate AI. There's a top tier that trades places every few weeks, a separate set of models that are better at not making things up, and a task-level reality that no benchmark captures for you. Betting an important answer on one model means betting on one model's blind spots — and you don't get told when you've hit one. So don't bet on one. Put the question to the world's most powerful AIs in parallel, let them cross-examine each other, and take the adjudicated, cited verdict — with the disagreements shown, not hidden. That's what Gangsta AI is for: agreement you can act on, dissent you can see, and one answer you can actually defend. Sources - Artificial Analysis - LLM Leaderboard (Intelligence Index): Gemini 4 Carbon (high) 59, Claude Opus 5.5 (max) 58, GPT-6 Astra (max) 57, GPT-6.1 Sol (max) 55, Claude Sonnet 5.5 (max) 54; scores vary by reasoning-effort setting within the same model family - Artificial Analysis - Intelligence Index methodology: how the composite reasoning/math/code/knowledge score is built - Vectara - Hallucination Leaderboard (HHEM), updated October 22, 2026: Finix S1 32B 1.8% (98.2% factual consistency), GPT-5.4 Nano 3.1%, Gemini 2.5 Flash-Lite 3.3%, Phi-4 3.7%, GPT-6 Sol 6.5%, GPT-6 Astra 8.7%, GPT-5.5 9.3%, Claude Opus 5.5 9.9% (192-word summaries), Gemini 3.1 Pro 10.4% - Vectara - interactive hallucination leaderboard on Hugging Face - Du et al., 'Improving Factuality and Reasoning in Language Models through Multiagent Debate' (arXiv:2305.14325): multiple model instances debating over several rounds improves reasoning and factual validity, reducing fallacious answers and hallucinations; applies to black-box models - Wang et al., 'Self-Consistency Improves Chain of Thought Reasoning in Language Models' (arXiv:2203.11171): sampling multiple reasoning paths and taking the most consistent answer raises accuracy - Hero photo: '184/366 - Bullseye' by Ravi Shah, licensed CC BY 2.0 via Wikimedia Commons --- Originally published on Gangsta AI News. Gangsta AI lets you compare 30+ AI models side by side on a single prompt — free, no login. Try the AI model comparison tool.

Show HN: A 20-line kernel that fixes float32 variance under XLA

PostgreSQL document compression: TOAST thresholds, storage policies, and page size A common way to store documents in PostgreSQL is a table with an ID and a JSONB column. The open-source DocumentDB extension instead stores BSON, the binary document format used by MongoDB, to provide more data types and MongoDB compatibility. Both approaches commonly combine two patterns that do not perfectly fit what SQL databases were designed for: - Rows with a single variable-length column, whose values can range from a few dozen bytes to many megabytes. - Repeated data or metadata, such as similar field names and arrays of objects with the same schema, like time-series buckets. MongoDB's storage engine, WiredTiger, packs many documents into B-tree leaf pages. The default maximum page sizes — 32 KB for leaf pages and 4 KB for internal pages — are limits on the uncompressed page image fed to the block compressor, not on individual documents: MongoDB configures leaf_value_max=64MB, so a document larger than 32 KB simply produces a larger leaf page rather than overflow storage. Snappy compresses each page image for ordinary collections (time-series collections use Zstd, which ignores the global compressor setting), and the compressed result is written in multiples of the 4 KB allocation_size. Because compression runs over the whole page image, several small documents — including their repeated field names — contribute redundant byte sequences to the same compression input. A JSON or BSON document can contain substantial byte-sequence redundancy: repeated field names, common name prefixes, and repeated values or structures. LZ77-family compressors such as Snappy and LZ4 can replace matching sequences with backreferences to earlier bytes. They don't need to understand JSON, and matches aren't restricted to the beginning of a document. Binary does not mean compressed: BSON includes field names, and repeated embedded objects repeat those names. JSONB can contain similar redundancy. PostgreSQL can compress those sequences in JSON, JSONB, or a BSON extension type. However, the decision to attempt compression is not driven by document redundancy. It belongs to TOAST's generic heap-row storage policy: reduce a wide row, trying column compression before storing permitted attributes externally in chunks. This distinction matters for small documents. It also makes increasing the page size potentially counterproductive: the same document can stop being compressed on a larger-page build. I will reproduce both effects, then compare the SQL controls with the hardcoded values. The examples use PostgreSQL 19 and core JSONB, so they can run without an extension or a custom patch. The distinction between whole-row activation and individual-column compression also applies to the TOAST-backed BSON values stored by DocumentDB. What is compressed, and what is measured? TOAST measures the whole tuple (row) to decide whether to start. However, compression acts on individual eligible column values, not on the entire row or all the documents in a page. PostgreSQL's ordinary table storage uses fixed-size pages, 8 KB by default. A row cannot span those pages. Large column values can instead be moved to an associated TOAST table, and the main row then contains a pointer to access the chunks in the TOAST table by index scan. JSONB still contains compressible byte sequences. It is a binary representation, not an already-compressed JSON string. Within one object, it normalizes key order and duplicate keys, but an array of similarly structured objects can repeat the same field names. No shared key dictionary exists across those objects or across independently stored JSONB rows. The distinction between repeated names within a document and repeated names across documents is important. PostgreSQL compresses one column value at a time. PostgreSQL calls each value a datum in its source code. That per-datum compression can use the former repetition, not the latter. MongoDB's WiredTiger storage engine uses Snappy block compression on disk by default for ordinary collections. Small documents can share a page, so one block-compression input can include repeated names and structures from several documents. This is not a separate compression call per small document. Other codecs can be configured, and time-series collections have different defaults. This is a difference in compression scope, not a capability reserved to Snappy. This post measures stored datum representations, not table allocation or query performance. I use: - pg_column_size(doc::text::jsonb) to reconstruct an uncompressed logical JSONB datum for these ordinary JSON inputs - pg_column_compression(doc) to report the actual accepted method - pg_column_size(doc) for its stored representation - pg_column_toast_chunk_id(doc) IS NOT NULL to identify external values The last function is available in PostgreSQL 19. For an external value, pg_column_size is not the inline pointer size. The on-disk pointer in the main row occupies 18 bytes. The external size excludes the outer four-byte varlena length word, which explains some four-byte differences below without attributing them to the codec. Reproduce the environment and output All SQL needed for the experiments is included below. Run the statements in order in a fresh test database. For each page-size comparison, start a separate PostgreSQL instance. I use aligned ASCII output, with NULL displayed as (null). To reproduce that format, start an existing server's session with these options: psql -X -P pager=off -P 'null=(null)' -P format=aligned \ -P linestyle=ascii -P border=1 -U postgres -d postgres These are the initial settings on the source-built 8 KB server: postgres=# SHOW server_version; server_version ---------------- 19rc1 (1 row) postgres=# SHOW block_size; block_size ------------ 8192 (1 row) postgres=# SHOW default_toast_compression; default_toast_compression --------------------------- lz4 (1 row) The selected codec is explicit in every test. PostgreSQL 14-18's upstream default is pglz, but an LZ4-enabled PostgreSQL 19 RC1 build defaults to LZ4. SET COMPRESSION has been available since PostgreSQL 14. LZ4 is a sensible starting choice when compression/decompression CPU matters, but the workload still determines the trade-off. It does not always produce the smallest result. DocumentDB's current setup/tuning configuration selects default_toast_compression = 'lz4' when supported. This is a launcher-chosen PostgreSQL setting, not a property of BSON, nor a guarantee that every installation is configured that way. Check the live server and column settings rather than assuming them from a product name. A compressible document below the activation threshold I construct a JSONB array containing eight objects with repeated temperature and humidity names. Both rows receive the same document. The only difference is an unrelated column stored PLAIN, so it cannot be compressed or moved externally. postgres=# CREATE TABLE small_documents( id integer, doc jsonb, other text ); CREATE TABLE postgres=# ALTER TABLE small_documents ALTER COLUMN doc SET COMPRESSION lz4 ; ALTER TABLE postgres=# ALTER TABLE small_documents ALTER COLUMN other SET STORAGE PLAIN ; ALTER TABLE postgres=# INSERT INTO small_documents SELECT id, jsonb_build_object('samples', ( SELECT jsonb_agg(jsonb_build_object('temperature',20,'humidity',60)) FROM generate_series(1,8) )), repeat('q', CASE id WHEN 1 THEN 0 ELSE 1600 END) FROM generate_series(1,2) AS g(id) ; INSERT 0 2 postgres=# SELECT id, pg_column_size(doc::text::jsonb) AS logical_bytes, octet_length(other) AS other_bytes, pg_column_compression(doc) AS compression, pg_column_size(doc) AS stored_bytes, pg_column_toast_chunk_id(doc) IS NOT NULL AS external FROM small_documents ORDER BY id ; id | logical_bytes | other_bytes | compression | stored_bytes | external ----+---------------+-------------+-------------+--------------+---------- 1 | 508 | 0 | (null) | 508 | f 2 | 508 | 1600 | lz4 | 109 | f (2 rows) <!-- psql:repeated_fields:end --> The first 508-byte JSONB datum remains uncompressed. The second compresses to 109 bytes, even though its uncompressed document bytes are identical. The additional 1,600-byte column made the tuple large enough to enter TOAST processing. This proves both points: 1. Repeated field names and values in JSONB are compressible. 2. PostgreSQL does not independently ask whether that small JSONB datum would benefit from compression. The enclosing tuple controls activation. I used an unrelated column for academic purposes. Of course, I'm not suggesting that adding more data to trigger compression is a good idea. The hardcoded gate is not the per-table target In the PostgreSQL source, the ordinary values are derived as follows: #define TOAST_TUPLES_PER_PAGE 4 #define TOAST_TUPLE_THRESHOLD MaximumBytesPerTuple(TOAST_TUPLES_PER_PAGE) #define TOAST_TUPLE_TARGET TOAST_TUPLE_THRESHOLD MaximumBytesPerTuple(4) accounts for page headers, line pointers, and alignment. It is not exactly block_size / 4. Here are the values for the default 8 KB page size and for PostgreSQL builds with 16 KB or 32 KB pages: | PostgreSQL page size | Fixed tuple activation threshold | Default tuple target | Maximum native TOAST chunk payload | |---:|---:|---:|---:| | 8,192 bytes | 2,032 bytes | 2,032 bytes | 1,996 bytes | | 16,384 bytes | 4,080 bytes | 4,080 bytes | 4,044 bytes | | 32,768 bytes | 8,176 bytes | 8,176 bytes | 8,140 bytes | These are the values for the tested eight-byte-aligned builds. The chunk capacities were also observed from actual external data, not inferred from page size alone. Both heap_prepare_insert and heap_update check the fixed threshold before invoking the toaster for fresh inline tuples. Inside the toaster, toast_tuple_target provides the reduction target, after subtracting tuple header overhead. It’s not simply "_compress when the row cannot fit on a page_.” A tuple just over 2 KB can still fit on an 8 KB page. By default, wide rows are reduced earlier, with the goal of keeping their size consistent with roughly four tuples per page. This is a row-density and oversized-attribute policy, rather than a separately tunable document-compression policy. These are fresh values with one eligible document column. If a row has several eligible columns, the toaster works in phases rather than compressing the entire row as one object. Change the target without changing activation The following input view constructs fresh JSONB values from repetitive text. It deliberately samples several payload sizes. It is not intended to represent a natural document distribution. A view is used rather than copying stored compressed values from another table. Reusing an existing compressed datum would confound a test of whether the destination attempts compression. postgres=# CREATE TEMP VIEW input_documents AS SELECT n, jsonb_build_object('v', repeat('x', 1024 * (1 << n))) AS doc FROM (VALUES (0),(1),(2),(6),(9),(10),(11)) AS sizes(n) ; CREATE VIEW postgres=# CREATE TABLE extended_default( n integer PRIMARY KEY, doc jsonb ); CREATE TABLE postgres=# CREATE TABLE extended_200( n integer PRIMARY KEY, doc jsonb ) WITH (toast_tuple_target=200) ; CREATE TABLE postgres=# CREATE TABLE extended_4k( n integer PRIMARY KEY, doc jsonb ) WITH (toast_tuple_target=4096) ; CREATE TABLE postgres=# ALTER TABLE extended_default ALTER COLUMN doc SET COMPRESSION lz4 ; ALTER TABLE postgres=# ALTER TABLE extended_200 ALTER COLUMN doc SET COMPRESSION lz4 ; ALTER TABLE postgres=# ALTER TABLE extended_4k ALTER COLUMN doc SET COMPRESSION lz4 ; ALTER TABLE postgres=# INSERT INTO extended_default SELECT * FROM input_documents ORDER BY n ; INSERT 0 7 postgres=# INSERT INTO extended_200 SELECT * FROM input_documents ORDER BY n ; INSERT 0 7 postgres=# INSERT INTO extended_4k SELECT * FROM input_documents ORDER BY n ; INSERT 0 7 postgres=# SELECT policy, 1 << n AS payload_kib, pg_column_compression(doc) AS compression, pg_column_size(doc) AS stored_bytes, pg_column_toast_chunk_id(doc) IS NOT NULL AS external FROM ( SELECT 1 AS position, 'default' AS policy, * FROM extended_default UNION ALL SELECT 2,'target_200',* FROM extended_200 UNION ALL SELECT 3,'target_4096',* FROM extended_4k ) AS cases ORDER BY position,n ; policy | payload_kib | compression | stored_bytes | external -------------+-------------+-------------+--------------+---------- default | 1 | (null) | 1041 | f default | 2 | lz4 | 39 | f default | 4 | lz4 | 47 | f default | 64 | lz4 | 288 | f default | 512 | lz4 | 2083 | t default | 1024 | lz4 | 4139 | t default | 2048 | lz4 | 8252 | t target_200 | 1 | (null) | 1041 | f target_200 | 2 | lz4 | 39 | f target_200 | 4 | lz4 | 47 | f target_200 | 64 | lz4 | 284 | t target_200 | 512 | lz4 | 2083 | t target_200 | 1024 | lz4 | 4139 | t target_200 | 2048 | lz4 | 8252 | t target_4096 | 1 | (null) | 1041 | f target_4096 | 2 | (null) | 2065 | f target_4096 | 4 | lz4 | 47 | f target_4096 | 64 | lz4 | 288 | f target_4096 | 512 | lz4 | 2087 | f target_4096 | 1024 | lz4 | 4139 | t target_4096 | 2048 | lz4 | 8252 | t (21 rows) The default JSONB storage strategy is EXTENDED, which permits both compression and external storage. Three observations distinguish the decisions: - Even with a 200-byte target, the 1 KB-payload document still remains uncompressed and inline at 1,041 bytes. Its tuple did not enter TOAST because it is smaller than the hardcoded MaximumBytesPerTuple(4). - Once TOAST is active, lowering the target externalizes values sooner: the 64 KB payload is inline with the default target but external with the 200-byte target. - With a 4 KB target, the 2 KB-payload document remains uncompressed at 2,065 bytes. Its tuple enters TOAST, but already meets the larger target. The same document compressed to 39 bytes in the other two tables. Raising the target is therefore not an independent "_retain more compressed documents inline_" control. It can also prevent a compression attempt. The default and 200-byte cases report 288 and 284 bytes respectively for the same compressed 64 KB-payload document. This is the inline/external varlena accounting difference, not a better compression result. Storage strategies: what SQL can control There are four column storage strategies: | Strategy | Compression | External storage | |---|---|---| | EXTENDED | Permitted, attempted in the first phase when reduction is needed | Permitted | | EXTERNAL | Not permitted | Permitted | | MAIN | Permitted, attempted in a later phase when needed | Last resort | | PLAIN | Not permitted | Not permitted | MAIN does not guarantee inline storage. MAIN attributes are also skipped during the first compression pass: they get their own compression round only after EXTENDED/EXTERNAL attributes have been compressed and externalized. They are likewise skipped by the out-of-line loops until the last-resort pass, which uses TOAST_TUPLE_TARGET_MAIN (MaximumBytesPerTuple(1) ≈ 8,160 bytes on an 8 KB build). EXTERNAL does not mean "externalize every document,” and an explicit LZ4 method cannot override its prohibition on compression. Here EXTERNAL and MAIN use the same 4 KB target, making the comparison independent of an accidental target difference: postgres=# CREATE TABLE external_4k( n integer PRIMARY KEY, doc jsonb ) WITH (toast_tuple_target=4096) ; CREATE TABLE postgres=# CREATE TABLE main_4k( n integer PRIMARY KEY, doc jsonb ) WITH (toast_tuple_target=4096) ; CREATE TABLE postgres=# CREATE TABLE plain_case( n integer PRIMARY KEY, doc jsonb ); CREATE TABLE postgres=# ALTER TABLE external_4k ALTER COLUMN doc SET COMPRESSION lz4 ; ALTER TABLE postgres=# ALTER TABLE main_4k ALTER COLUMN doc SET COMPRESSION lz4 ; ALTER TABLE postgres=# ALTER TABLE plain_case ALTER COLUMN doc SET COMPRESSION lz4 ; ALTER TABLE postgres=# ALTER TABLE external_4k ALTER COLUMN doc SET STORAGE EXTERNAL ; ALTER TABLE postgres=# ALTER TABLE main_4k ALTER COLUMN doc SET STORAGE MAIN ; ALTER TABLE postgres=# ALTER TABLE plain_case ALTER COLUMN doc SET STORAGE PLAIN ; ALTER TABLE postgres=# INSERT INTO external_4k SELECT * FROM input_documents ORDER BY n ; INSERT 0 7 postgres=# INSERT INTO main_4k SELECT * FROM input_documents ORDER BY n ; INSERT 0 7 postgres=# INSERT INTO plain_case SELECT * FROM input_documents WHERE n<=2 ORDER BY n ; INSERT 0 3 postgres=# SELECT policy, 1 << n AS payload_kib, pg_column_compression(doc) AS compression, pg_column_size(doc) AS stored_bytes, pg_column_toast_chunk_id(doc) IS NOT NULL AS external FROM ( SELECT 1 AS position,'EXTERNAL' AS policy,* FROM external_4k UNION ALL SELECT 2,'MAIN',* FROM main_4k UNION ALL SELECT 3,'PLAIN',* FROM plain_case ) AS cases ORDER BY position,n ; policy | payload_kib | compression | stored_bytes | external ----------+-------------+-------------+--------------+---------- EXTERNAL | 1 | (null) | 1041 | f EXTERNAL | 2 | (null) | 2065 | f EXTERNAL | 4 | (null) | 4109 | t EXTERNAL | 64 | (null) | 65549 | t EXTERNAL | 512 | (null) | 524301 | t EXTERNAL | 1024 | (null) | 1048589 | t EXTERNAL | 2048 | (null) | 2097165 | t MAIN | 1 | (null) | 1041 | f MAIN | 2 | (null) | 2065 | f MAIN | 4 | lz4 | 47 | f MAIN | 64 | lz4 | 288 | f MAIN | 512 | lz4 | 2087 | f MAIN | 1024 | lz4 | 4143 | f MAIN | 2048 | lz4 | 8252 | t PLAIN | 1 | (null) | 1041 | f PLAIN | 2 | (null) | 2065 | f PLAIN | 4 | (null) | 4113 | f (17 rows) For EXTERNAL, the 2 KB payload is still inline, but the 4 KB payload is external without compression. For MAIN, the 1 MB payload compresses to 4,143 inline bytes. It can stay inline because MAIN postpones externalization to its last-resort target: the maximum tuple size that fits on one page. The larger 2 MB-payload document still becomes external after compression. For PLAIN, no value compresses or becomes external. A row that cannot fit on the heap page fails. Run this separate statement expecting an error: postgres=# INSERT INTO plain_case VALUES (3,jsonb_build_object('v',repeat('x',8192))) ; ERROR: 54000: row is too big: size 8240, maximum size 8160 LOCATION: RelationGetBufferForTuple, hio.c:531 The 8,160-byte maximum in this error is the heap-page tuple limit, not the 2,032-byte TOAST activation threshold. They answer different questions. This is the complete SQL control surface relevant to these cases: | Control | Scope | Changes the fixed activation threshold? | |---|---|---| | ALTER COLUMN ... SET STORAGE ... | Column's permitted/preferred representation | No | | ALTER COLUMN ... SET COMPRESSION pglz/lz4 | Codec when compression is attempted | No | | default_toast_compression | Default codec when the column has no override | No | | ALTER TABLE ... SET (toast_tuple_target=...) | Whole-tuple reduction target after entry | No | | TOAST_TUPLE_THRESHOLD, TOAST_TUPLES_PER_PAGE | Compiled activation policy | Source change | | TOAST_MAX_CHUNK_SIZE, EXTERN_TUPLES_PER_PAGE | Compiled external chunk capacity | Separate from activation | | BLCKSZ | Compiled page size | Changes several defaults together | Changing page and chunk sizes requires a freshly initialized cluster. They are not runtime GUCs. Changing only a main-tuple threshold is not inherently an on-disk page-format change, but a correct implementation still has to consider all heap entry paths and TOAST-table creation. The compression algorithm still matters after activation Compression is an attempt, not a storage guarantee. Pglz's default strategy has a 32-byte minimum input, a 25% minimum reduction policy, and a 1,024-byte encoded-output first-success limit: it aborts if it has emitted that much without finding a match. Those are pglz strategy rules, not user-configurable document thresholds. LZ4 does not impose pglz's first-success or minimum-rate rules. Both must still pass TOAST's header/alignment savings check. Changing the column codec does not rewrite existing values: postgres=# CREATE TABLE codec_example( id integer PRIMARY KEY, doc jsonb ); CREATE TABLE postgres=# ALTER TABLE codec_example ALTER COLUMN doc SET COMPRESSION pglz ; ALTER TABLE postgres=# INSERT INTO codec_example VALUES (1,jsonb_build_object('v',repeat('x',4096))) ; INSERT 0 1 postgres=# ALTER TABLE codec_example ALTER COLUMN doc SET COMPRESSION lz4 ; ALTER TABLE postgres=# INSERT INTO codec_example VALUES (2,jsonb_build_object('v',repeat('x',4096))) ; INSERT 0 1 postgres=# SELECT id, pg_column_compression(doc) AS compression, pg_column_size(doc) AS stored_bytes FROM codec_example ORDER BY id ; id | compression | stored_bytes ----+-------------+-------------- 1 | pglz | 71 2 | lz4 | 47 (2 rows) The old value remains pglz. The freshly constructed new value uses LZ4. An update that leaves the document unchanged, or a copy of an already compressed datum, need not recompress it. Therefore, changing the setting is not proof that existing data now uses the new codec. Larger pages: fewer documents become compression candidates Larger pages can reduce the number of external chunks. That does not mean they preserve compression behavior. I rebuilt PostgreSQL 19 RC1 with --with-blocksize=8, 16, and 32, keeping the other configure options the same, then initialized fresh clusters. Do not reuse a data directory across page sizes. A different page size also requires rebuilding linked extensions against that PostgreSQL installation. This comparison deliberately uses core JSONB rather than mixing extension versions or a stock image with a different source-built baseline. 8 KB: all but the smallest repeated-field document compress The samples array now contains 8, 64, 128, or 256 similarly structured objects. All tests explicitly select LZ4. One table retains the build's default target. The other sets it to 2040. postgres=# CREATE TEMP VIEW page_inputs AS SELECT n, jsonb_build_object('samples', ( SELECT jsonb_agg(jsonb_build_object('temperature',20,'humidity',60)) FROM generate_series(1,n) )) AS doc FROM (VALUES (8),(64),(128),(256)) AS counts(n) ; CREATE VIEW postgres=# CREATE TABLE page_default( n integer PRIMARY KEY, doc jsonb ); CREATE TABLE postgres=# CREATE TABLE page_target( n integer PRIMARY KEY, doc jsonb ) WITH (toast_tuple_target=2040) ; CREATE TABLE postgres=# ALTER TABLE page_default ALTER COLUMN doc SET COMPRESSION lz4 ; ALTER TABLE postgres=# ALTER TABLE page_target ALTER COLUMN doc SET COMPRESSION lz4 ; ALTER TABLE postgres=# INSERT INTO page_default SELECT * FROM page_inputs ORDER BY n ; INSERT 0 4 postgres=# INSERT INTO page_target SELECT * FROM page_inputs ORDER BY n ; INSERT 0 4 postgres=# CREATE VIEW page_observations AS SELECT policy, n AS objects, pg_column_size(doc::text::jsonb) AS logical_bytes, pg_column_compression(doc) AS compression, pg_column_size(doc) AS stored_bytes, pg_column_toast_chunk_id(doc) IS NOT NULL AS external FROM ( SELECT 1 AS position,'default' AS policy,* FROM page_default UNION ALL SELECT 2,'target_2040',* FROM page_target ) AS cases ORDER BY position,n ; CREATE VIEW postgres=# SELECT * FROM page_observations ; policy | objects | logical_bytes | compression | stored_bytes | external -------------+---------+---------------+-------------+--------------+---------- default | 8 | 508 | (null) | 508 | f default | 64 | 3868 | lz4 | 126 | f default | 128 | 7708 | lz4 | 150 | f default | 256 | 15388 | lz4 | 198 | f target_2040 | 8 | 508 | (null) | 508 | f target_2040 | 64 | 3868 | lz4 | 126 | f target_2040 | 128 | 7708 | lz4 | 150 | f target_2040 | 256 | 15388 | lz4 | 198 | f (8 rows) 16 KB: the 3,868-byte JSONB document no longer compresses The complete setup is unchanged. This is the same final query on the 16 KB build: postgres=# SELECT * FROM page_observations ; policy | objects | logical_bytes | compression | stored_bytes | external -------------+---------+---------------+-------------+--------------+---------- default | 8 | 508 | (null) | 508 | f default | 64 | 3868 | (null) | 3868 | f default | 128 | 7708 | lz4 | 150 | f default | 256 | 15388 | lz4 | 198 | f target_2040 | 8 | 508 | (null) | 508 | f target_2040 | 64 | 3868 | (null) | 3868 | f target_2040 | 128 | 7708 | lz4 | 150 | f target_2040 | 256 | 15388 | lz4 | 198 | f (8 rows) The tuple containing 3,868 JSONB bytes remains below the 4,080-byte activation gate. Lowering its target to 2040 does not make the caller invoke TOAST. 32 KB: the 7,708-byte document also stops compressing The same query on the 32 KB build: postgres=# SELECT * FROM page_observations ; policy | objects | logical_bytes | compression | stored_bytes | external -------------+---------+---------------+-------------+--------------+---------- default | 8 | 508 | (null) | 508 | f default | 64 | 3868 | (null) | 3868 | f default | 128 | 7708 | (null) | 7708 | f default | 256 | 15388 | lz4 | 198 | f target_2040 | 8 | 508 | (null) | 508 | f target_2040 | 64 | 3868 | (null) | 3868 | f target_2040 | 128 | 7708 | (null) | 7708 | f target_2040 | 256 | 15388 | lz4 | 198 | f (8 rows) The 7,708-byte JSONB value compressed to 150 bytes on the 8- and 16-KB builds. On the 32 KB build, the tuple stays below the 8,176-byte gate, and the datum remains at 7,708 bytes. A 2040-byte target does not restore compression. The 15,388-byte positive control compresses on all three builds. Its tuple exceeds even the largest activation threshold. UPDATE has the same outer gate The following statements reconstruct each JSONB value on UPDATE, rather than reassigning an existing compressed value. On the 32 KB build: postgres=# UPDATE page_default d SET doc=jsonb_build_object('samples', ( SELECT jsonb_agg(jsonb_build_object('temperature',20,'humidity',60)) FROM generate_series(1,d.n) )) ; UPDATE 4 postgres=# UPDATE page_target d SET doc=jsonb_build_object('samples', ( SELECT jsonb_agg(jsonb_build_object('temperature',20,'humidity',60)) FROM generate_series(1,d.n) )) ; UPDATE 4 postgres=# SELECT * FROM page_observations ; policy | objects | logical_bytes | compression | stored_bytes | external -------------+---------+---------------+-------------+--------------+---------- default | 8 | 508 | (null) | 508 | f default | 64 | 3868 | (null) | 3868 | f default | 128 | 7708 | (null) | 7708 | f default | 256 | 15388 | lz4 | 198 | f target_2040 | 8 | 508 | (null) | 508 | f target_2040 | 64 | 3868 | (null) | 3868 | f target_2040 | 128 | 7708 | (null) | 7708 | f target_2040 | 256 | 15388 | lz4 | 198 | f (8 rows) The INSERT and UPDATE results matched on all three servers. This is why looking only at the inner compression loop, without the INSERT/UPDATE callers, can give the wrong interpretation of toast_tuple_target. Chunk capacity does grow This 8 KB-page case inserts a 65,536-character text value with STORAGE EXTERNAL and reads its actual TOAST chunks. \gset assigns the TOAST relation name to a psql variable, avoiding a hardcoded relation OID: postgres=# CREATE TABLE chunk_probe( doc text ); CREATE TABLE postgres=# ALTER TABLE chunk_probe ALTER COLUMN doc SET STORAGE EXTERNAL ; ALTER TABLE postgres=# INSERT INTO chunk_probe VALUES (repeat('z',65536)) ; INSERT 0 1 postgres=# SELECT reltoastrelid::regclass AS toast_relation FROM pg_class WHERE oid='chunk_probe'::regclass \gset postgres=# SELECT max(octet_length(chunk_data)) AS max_chunk_bytes FROM :toast_relation ; max_chunk_bytes ----------------- 1996 (1 row) Run the same statements in the 16 KB instance: postgres=# CREATE TABLE chunk_probe( doc text ); CREATE TABLE postgres=# ALTER TABLE chunk_probe ALTER COLUMN doc SET STORAGE EXTERNAL ; ALTER TABLE postgres=# INSERT INTO chunk_probe VALUES (repeat('z',65536)) ; INSERT 0 1 postgres=# SELECT reltoastrelid::regclass AS toast_relation FROM pg_class WHERE oid='chunk_probe'::regclass \gset postgres=# SELECT max(octet_length(chunk_data)) AS max_chunk_bytes FROM :toast_relation ; max_chunk_bytes ----------------- 4044 (1 row) And in the 32 KB instance: postgres=# CREATE TABLE chunk_probe( doc text ); CREATE TABLE postgres=# ALTER TABLE chunk_probe ALTER COLUMN doc SET STORAGE EXTERNAL ; ALTER TABLE postgres=# INSERT INTO chunk_probe VALUES (repeat('z',65536)) ; INSERT 0 1 postgres=# SELECT reltoastrelid::regclass AS toast_relation FROM pg_class WHERE oid='chunk_probe'::regclass \gset postgres=# SELECT max(octet_length(chunk_data)) AS max_chunk_bytes FROM :toast_relation ; max_chunk_bytes ----------------- 8140 (1 row) The maximum payloads are 1,996, 4,044, and 8,140 bytes. That is an independent benefit larger pages can provide for sufficiently large values. It does not compensate automatically for the loss of compression on smaller documents. Neither fewer chunks nor larger pages alone establishes lower allocation or better read performance. Why this behavior remains The documented TOAST design handles values that cannot fit directly in heap tuples, and keeps main rows smaller so queries not needing large attributes can avoid fetching them. It is a general relational storage mechanism, predating JSONB, not a policy specifically optimized for repeated document schemas. I searched the pgsql-hackers discussions with the pghacker MCP. This separation was already being discussed explicitly in 2019: - February 6, 2019: Pavan Deolasee proposed a separate table-level option to control compression, named compress_tuple_target, so smaller values could be compressed inline without requiring out-of-line storage. - March 5, 2019: Andrew Dunstan supported the idea, while calling for more review. - April 3, 2019: Michael Paquier identified the fixed-threshold caller checks independently of the per-table toast_tuple_target. The subsequent discussion identified two broader problems: a bounded-width relation may have no TOAST table, so lowering its trigger could require creating one under a stronger lock. Rejecting previously accepted low targets could break dump restores. These are implementation and compatibility constraints, not evidence that the current fraction is optimal for small JSONB documents. If you want to build and run the three page sizes The SQL above is sufficient for an existing PostgreSQL 19 server. The following commands run in Bash on a machine with Docker. The Dockerfile is supplied inline. No repository checkout or external code file is required. set -euo pipefail for kb in 8 16 32; do docker build --build-arg BLOCK_SIZE="$kb" \ -t "toast-pg19rc1:${kb}k" - <<'DOCKERFILE' FROM postgres:19rc1-alpine RUN apk add --no-cache build-base curl bison flex perl linux-headers \ icu-dev lz4-dev openssl-dev readline-dev zlib-dev ARG BLOCK_SIZE=8 RUN set -eu; \ case "$BLOCK_SIZE" in 8|16|32) ;; *) exit 1 ;; esac; \ mkdir /tmp/page-build; \ curl --fail --location \ "https://ftp.postgresql.org/pub/source/v${PG_VERSION}/postgresql-${PG_VERSION}.tar.bz2" \ -o /tmp/page-build/postgres.tar.bz2; \ tar -xjf /tmp/page-build/postgres.tar.bz2 -C /tmp/page-build; \ cd "/tmp/page-build/postgresql-${PG_VERSION}"; \ ./configure --prefix=/usr/local --with-blocksize="$BLOCK_SIZE" \ --with-lz4 --with-icu --with-openssl; \ make -s -j2; \ make -s install; \ cd /; \ rm -rf /tmp/page-build DOCKERFILE done Choose one page size, start a fresh disposable instance, and open psql: kb=8 # repeat with 16 and 32 pg="toast-research-${kb}k-$$" docker run --detach --name "$pg" --network none \ -e POSTGRES_HOST_AUTH_METHOD=trust "toast-pg19rc1:${kb}k" ready=no for attempt in $(seq 1 60); do if docker exec "$pg" pg_isready -U postgres; then ready=yes break fi sleep 1 done if [ "$ready" != yes ]; then docker logs "$pg" docker rm --force --volumes "$pg" exit 1 fi docker exec -it "$pg" psql -X -v ON_ERROR_STOP=1 \ -P pager=off -P 'null=(null)' -P format=aligned \ -P linestyle=ascii -P border=1 -U postgres -d postgres Use the 8 KB instance for the storage-strategy cases. For the page comparison, run the same page_inputs, page_default, page_target, and observation statements on each instance. Repeat the chunk case on all three. The deliberately failing PLAIN insert is a separate statement: do not include it in a successful setup batch with ON_ERROR_STOP. After leaving psql with \q, remove only the container created above: docker rm --force --volumes "$pg" Conclusion: separate compression eligibility from row placement The experiment does not show that PostgreSQL cannot compress document redundancy. It shows that the eligibility policy is tied to heap tuple size and page size, rather than to a document-column compression policy. Under the ordinary defaults, increasing page size from 8 to 16 to 32 KB raises activation from about 2 to 4 to 8 KB. Some highly compressible documents therefore stop reaching the compressor. A lower toast_tuple_target cannot recover those missed attempts. A higher target can suppress attempts further. A useful direction is to make the hardcoded activation policy configurable, separately from the reduction/inline target. For example, a 32 KB-page server could retain a lower activation threshold without adopting a smaller page. For document workloads, a per-column compression-eligibility threshold may be more directly useful than a whole-row threshold. This isn't as simple as making the hardcoded value a parameter. A safe implementation must cover INSERT, UPDATE, rewrites, TOAST-table creation, locking, and existing representations. The appropriate default would still need insertion CPU and read/update benchmarks on representative document sizes. There is no basis here for declaring that every 500-byte document should be compressed. The narrower conclusion is reproducible: the quarter-page activation gate can prevent useful compression, and larger pages may widen the gap. Currently, the DocumentDB extension relies on the TOAST mechanism, trading MongoDB’s compression behavior for compatibility with PostgreSQL storage. I've seen many MongoDB workloads store small documents (and ran a poll on LinkedIn), much like a relational model—even though document models are meant to store larger aggregates to favor single-document data locality and single-IO transactions.

[Guide] How I Enabled Native Now Brief on the Galaxy S23 (One UI 9 / Android 17) via KernelSU! Consegui habilitar o Now Brief nativo da Samsung no Galaxy S23 normal (SM-S911B) usando o KernelSU e uma adaptação do método original desenvolvido por Furkan-Tsc para o S23 Ultra. Este método usa resetprop para contornar a restrição de instalação do Smart Suggestions e mount --bind para aplicar dinamicamente as modificações necessárias em floating_feature.xml, habilitando os sinalizadores de IA necessários e os componentes nativos do Now Brief. Também implementei uma correção direcionada para a permissão de Dados Pessoais, juntamente com ferramentas de diagnóstico e reversão. Nenhuma modificação física na partição /system é necessária. Os bind mounts são temporários e são removidos após uma reinicialização completa do dispositivo. Testado em: Galaxy S23 SM-S911B, One UI 9.0, Android 17. preview.redd.it O Now Brief, seus cards nativos e o widget da tela inicial estão funcionando. O Now Nudge contextual e o card do Now Brief na tela de bloqueio ainda não foram confirmados como funcionando. Você pode encontrar o guia completo, scripts, requisitos e comandos no meu repositório do GitHub: AurelioMo/nowbrief-s23-oneui9

this is quite fun i replicated the experiment you can do it yourself with codex/claude sub Occupying-Mars/toy-weight-repair t.co

cool project to fingerprinting llm - detect llm by their behavioral output distribution matching dreamor/llm-fingerprint

Made @WorkFlowy main feature in @obsdmd NgrimaldiN/workflowy-in-obsidian

@nicksdjohnson give this to your agent to battle. douglance/tankwar watch matches: tankwar.doug-lance.workers.dev

Owen Sound: From Transit Budgets to Ride Targets TL;DR: Transit planners need to connect a service budget to the hours, trips, and choices it can support across the week. While working on the Living Region coding project, I needed to connect an existing fixed-route budget to evening and weekend on-demand service. From July through November, the calculator grew through a mobility planner, phased bus costs, on-demand windows, selectable service modes, window-level ride targets, and a shared annual target for comparing buses with rideshare. The Living Region transit calculator grew through several distinct planning questions. Its history shows how a model can move from a budget baseline to time-specific scenarios, then make demand and service type adjustable. The repository keeps the calculations, interface, generated data, and tests together. A phased bus budget created the starting model The wider Living Region project first added an integrated mobility planner on July 24. On September 2, the Owen Sound transit cost model added a transit-specific budget view, with a sourced city baseline and service phases. The first phase described weekday evening bus service across four routes: roughly hourly service until 10 p.m., five days a week. A vehicle-hour is one vehicle operating for one hour; CAD means Canadian dollars. One passenger boarding counts one person getting onto a bus. The model also carried equivalent Mobility Transit availability, with its vehicle-hours left for local operating data. For its Phase 1 scenario, the calculator assigned 2,080 annual conventional vehicle-hours, gross operating costs of CAD $300,000–$375,000, and a target of eight passenger boardings per vehicle-hour. Its fare assumption was CAD $1.50–$2 per boarding. After modeled fare revenue, the net annual estimate came to CAD $266,720–$350,040. These figures are planning inputs and calculated outcomes; comparing hours with a local timetable and costs with operator quotes makes the scenario more useful for a real budget. The phase structure gave the calculator a starting question: what schedule is being proposed, how many vehicle-hours does it require, and how do fares affect the budget? The original build and deployment checks both passed in the deployment workflow. On-demand scenarios added service windows On October 20, the first on-demand scenario change added evening and weekend windows to the cost model. Demand-responsive, or on-demand, service sends a vehicle after a rider requests a trip. A service window is a defined time period, such as Sunday daytime or weekday evenings. This let the model describe lower-demand periods alongside the scheduled daytime bus network. The session verification reported two useful pilot views. Sunday daytime plus weekday evenings came to 3,224 vehicle-hours and a modeled net cost of CAD $205,000–$230,000. Selecting all four windows—Sunday daytime, weekday evenings, Saturday daytime, and Saturday evenings—came to 3,999 hours and CAD $236,000–$265,000 net. Each figure tied a budget range to the hours of service selected. The same change also included a separate full-network comparison. That view started with a 13,500-hour annual network and let planners compare paid core buses with demand-responsive service. With two core vehicles, the model assigned 4,160 hours to buses and 9,340 hours to on-demand service. At zero core buses, this full-network scenario estimated CAD $880,000–$1,264,000 net per year under its planning allowances. This network replacement view describes a different scope from a small evening-and-weekend pilot, so the calculator kept the two questions distinct. The first on-demand release recorded 11 passing transit tests, 207 carrying-capacity tests, type and contract validation, a production build, browser checks, and a successful deployment. GitHub’s build and deploy jobs provide the public delivery record. Service choices turned scenarios into plans The next October 20 commits added independently selectable scheduled buses and on-demand rideshare, then preserved a zero-core-bus choice in shared links. The calculator could label a plan Bus only, Rideshare only, or Combined service. The network view could also represent a fully demand-responsive option with zero core buses and 13,500 on-demand hours. For the selected-window pilot, the recorded mode comparison showed CAD $266,720–$350,040 net for bus-only service, CAD $205,000–$230,000 for rideshare-only windows, and CAD $471,720–$580,040 for the combined default. The combined figure added the two selected components from that model stage. The full-network comparison used its own 13,500-hour scope and cost allowances. That distinction matters when reading the model’s growth. A selected-window pilot describes evening or weekend additions. A full-network comparison reallocates the annual network. Naming those scopes lets a planner choose the question before reading the estimate. The mode-selection update recorded 16 focused transit tests, type and contract checks, mobile browser checks, a production build, and deployment. GitHub Actions records successful builds for the service-mix choices and the zero-core URL state. Ride targets made each window adjustable Later that day, the demand-led update let a planner set an annual ride target for each on-demand window. The model then scaled vehicle-hours, operating costs, and fare revenue from those targets. Its starting rideshare assumption was four completed rides per vehicle-hour. This step changed the input from a fixed service-hours estimate to a demand estimate a reader could adjust. A weekend-only plan could be modeled by selecting the weekend windows and setting their ride counts; weekday evening service could be adjusted independently. The session reported 12 on-demand model tests, passing type and contract checks, a successful production build and deployment, and a mobile layout check. The final GitHub build and deploy checks passed. The Transportation Research Board’s Transit Cooperative Research Program (TCRP) Report 98 is a useful technical reference: it describes simulating trip patterns, scheduling trips among vehicles, and modeling service results. Living Region answers an earlier budget question with a simpler proportional model. It turns a selected ride target into vehicle-hours, costs, and fares using stated local assumptions. A shared target tied the service mix together By November 2, the model had separate mode choices and editable window targets. The shared-demand update added one default annual target of 16,640 and a slider that allocates that target between buses and rideshare. The merge commit 4628321 passed its build and deployment checks. The code splits the target according to the slider position, then scales each service component’s starting hours, cost, and fares by its allocated share: on-demand allocation = annual target × selected share bus allocation = annual target − on-demand allocation component scale = allocated demand ÷ component baseline demand hours and costs = component baseline values × component scale Here, a component baseline means the starting ride count, hours, costs, and fares assigned to one service type. At the default Phase 1 target, the recorded endpoint comparison is: | Scheduled buses | On-demand rideshare | Annual target | Modeled hours/year | Modeled net annual cost (CAD) | |---:|---:|---:|---:|---:| | 100% | 0% | 16,640 | 2,080 | $266,720–$350,040 | | 50% | 50% | 16,640 | about 3,120 | about $265,618–$323,407 | | 0% | 100% | 16,640 | 4,160 | $264,516–$296,774 | The midpoint applies half of each service component’s starting values. The ranges overlap, so the scenario supports discussion of coverage, operating needs, and budget together. The 16,640 target is a planning scenario that readers can replace with local records. The two components count demand differently: buses use projected passenger boardings (people getting on), while rideshare uses modeled completed trips. A single trip can carry several people, so matching local records to an agreed unit is the key step before interpreting the combined estimate. The latest endpoint-label change makes the direction clear: 100% scheduled buses at the left, 100% on-demand rideshare at the right. Its GitHub build and deploy checks passed. The full service-mix calculation is in the transit model source. A sequence other planners can reuse The Federal Transit Administration (FTA) publishes service and cost definitions through the National Transit Database (NTD). Its glossary explains demand-response service, passenger trips, and vehicle revenue-hours. Those definitions help a planner align the model’s inputs with an agency’s records. The project’s progression offers a practical sequence for another transit analysis: establish the existing service and budget baseline; add distinct service windows; separate a pilot from a whole-network scenario; let readers choose modes; then set a shared demand target for direct comparisons. Each stage adds one decision while keeping its assumptions and output visible. Local ridership counts, operator quotes, and an agreed definition of a trip turn the model into a stronger basis for planning.

How long? Last year my blogging engine hit a bug that had been latent for 28 years.

@rexpaircraft have you tried cal sans? calcom/sans

@even366 这里不是把 block.timestamp 换成毫秒：BEP-706 保留原来的秒值，毫秒时间走新增的 0x70 预编译。迁移时两边的单位得分清。另外 v1.8.1 公告针对 Chapel 测试网，不能据此当成主网已上线。github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-70…