LineageOS 24.0
LineageOS 24.0, built on Android 17, introduces extensive back‑porting of security patches (August 2025 – October 2026 for active branches, November 2025 for legacy 15.1, 16.0, 17.1) while preserving patch‑level strings only on Google‑supported releases (Android 14+). Core applications receive Material Design 3 updates, adding a new Canvas image editor, TV launcher Catapult enhancements, Etar, Jelly browser PWA shortcuts, Twelve music improvements, and a redesigned Updater with streamed A/B installs. WebUSB flash tools now support ADB, Fastboot, Amlogic Burn and Samsung Odin protocols directly from browsers. CI/CD pipelines automatically post CI votes, run tests, and deploy APKs via GitHub Actions. An external accessibility audit led to UI revisions and contributor training. Legacy devices using kernels 4.4/4.9 are limited to LineageOS 22.2, with continued monthly patches until Android 15 security bulletins cease. The release adds common SoC kernels, shared “shims,” expanded Wiki with MD3 styling, generic build targets for emulators, GSI, automotive, and experimental bare‑metal hardware, and encourages translation and developer contributions.
Build your own decision model
The note describes “system‑one” decision models that restrict a language model’s output to a predefined set of options (e.g., A‑E) and generate a single‑pass answer by masking the vocabulary. An implementation using Qwen‑3‑1.7B demonstrates constrained decoding: token IDs for the options are pre‑computed, logits for the final token are soft‑maxed over only those IDs, and the highest‑probability option is returned with its probability. On a simple sky‑color test the model selects “B” (Blue) with ≈ 0.999 confidence. Evaluated on a random CommonsenseQA hold‑out (1 221 items) the zero‑shot model achieves 59.4 % accuracy (macro F1 ≈ 0.584). A brief fine‑tune raises accuracy to 62.4 % (macro F1 ≈ 0.623). Calibration analysis shows severe over‑confidence; confidence bins do not match observed accuracy. Temperature scaling (optimal ≈ 3.797) flattens the distribution, aligning confidence with accuracy across bins. A GitHub repository provides scripts for dataset creation, evaluation, fine‑tuning, and calibration.
Comments show strong enthusiasm for experimenting with Jev‑style decision models, with multiple users sharing implementations, tutorials and successful applications such as game agents and lightweight classifiers. At the same time, several contributors express skepticism about the hype, questioning whether the approach offers genuine architectural advances beyond existing zero‑shot LLM classifiers and noting performance or cost limitations on local hardware. Requests for more real‑world examples, documentation improvements, and tools for calibration appear alongside concerns about evaluation practices and usability glitches. Overall the discussion balances excitement for rapid prototyping with critical appraisal of the technology’s novelty and practicality.
2D Vehicles
The prototype implements a 2‑D rigid‑body physics core extended with three simple vehicle models—Brick, Ship and Car—using a single persistent body. The physics engine updates in fixed time steps, separating input handling, force integration and Canvas rendering. Rigid‑body state includes position, velocity, angle and angular velocity; forces applied at the centre produce translation, while off‑centre forces generate torque and spin. Collision with barriers is handled by a friction‑less edge solver that restores penetration and applies a contact impulse based on point velocity.
Vehicle behaviours are layered on the core: Brick receives forces from pointer drags, Ship adds thrust at an attachment point, and Car applies engine force, steering and tyre‑resistance forces at four wheel positions. Each tyre resolves its local velocity into longitudinal and lateral components, applying proportional damping—weak for rolling, strong for sideways slip—plus steering adjustments and a hand‑brake effect that raises rear rolling resistance and reduces lateral grip. A vehicle coordinator invokes the selected dynamics object, integrates motion, transforms shape points for drawing and selects barrier contact points using mid‑edge contacts to avoid artificial spin.
The comments express broad enthusiasm and nostalgia for the 2‑D vehicle simulation, praising its feel, simplicity and historical significance while many contributors share personal projects that built on or recreated the model. Positive feedback highlights the fun of handbrake turns, the value of prototyping, and the impact on games like GTA 1‑2. Several remarks note technical shortcomings, such as unclear diagrams, occasional unrealistic lateral motion, missing understeer, and odd behavior when switching configurations, and some request features like a parking‑training mode. Overall, appreciation outweighs criticism, with a shared interest in further refinement.
A city-building game in which the city would prefer you didn't
I’m unable to provide a summary because the submitted text contains only a title and no substantive content to summarize.
Comments blend humor with criticism, using game analogies to highlight perceived bureaucratic obstacles in San Francisco’s housing development. Many express frustration over complex, time‑consuming processes and question the practicality of proposed solutions such as building high‑rise apartments over transit stations. While some appreciate the aesthetic and educational intent of the simulation, a prevailing view finds the UI overly convoluted and the gameplay discouraging, suggesting the design could be streamlined to better convey the housing‑policy message. Overall sentiment leans toward wanting simpler, more actionable tools.
The Lightbulb Computer
The article proposes the “Lightbulb Computer,” a speculative personal‑computing device that integrates a compact projector with on‑device computer‑vision sensors in a bulb‑shaped enclosure. Mounted in a portable base, a wall/ceiling socket, or a lamp, it can project high‑resolution images onto any surface and interact via voice, pointing gestures, and visual analysis. Use‑case scenarios include kitchen overlays (recipes, timers), contextual Q&A while reading, collaborative large‑format maps, photo sharing, board‑game facilitation, smart‑home control by pointing, ambient displays (time, weather, calendar), and interactive 3‑D house maps with real‑time data layers. The author contrasts this approach with current screen‑centric and eyewear‑based AR/VR solutions, arguing that projectors avoid the social and ergonomic constraints of head‑mounted devices while preserving shared, spatial interaction. Recent advances in projector brightness, resolution, and computer‑vision speed make a prototype feasible, though consumer‑grade hardware is not yet available. Privacy is addressed through on‑device processing, hardware interlocks, indicator lights, and optional camera covers. Historical references include I/O Bulb, LuminAR, Humane Pin, Dynamicland, and Folk Computer.
The comments are broadly enthusiastic about the prototype’s novelty and its promise for hands‑free, projected interaction, noting parallels to earlier concepts like Sixth Sense and recent voice‑assistant patents. Many highlight the low cost of required hardware and suggest refinements such as reduced latency, better speech cues, and more reliable projection under varied lighting. Simultaneously, a substantial share voices concerns over privacy, constant monitoring, data ownership, and the practicality of indoor‑only, non‑persistent displays, warning that commercial versions could become cloud‑dependent and intrusive. Overall sentiment mixes optimism about user‑experience potential with caution about security and usability constraints.
How big is a Git commit?
A newly‑initialized repository occupies ~64 KB in .git. Adding 250 tiny files (each “foo”) and committing creates about 47 KB of Git objects, raising the .git size to ~112 KB. Changing a single file and committing again adds roughly 17 KB, bringing the total to ~130 KB. The size increase comes from new Git objects: each commit generates a commit object, one or more tree objects (for the root and affected directories), and a blob object for the modified file. These objects are stored in .git/objects as 4 KB‑sized, zlib‑compressed files; even a 3‑byte change results in several new 4 KB objects. Log files also grow modestly (≈0.1 KB). Thus, Git’s storage model inflates small edits into multiple compressed objects, explaining why a minimal change can add several kilobytes to repository size.
The comments describe an effort to build a streamlined Git alternative that leverages AST paths for further compression, but the experiment concluded that Git’s existing mechanisms, including delta compression and packfiles, outperform the proposed approach. The discussion notes Git’s efficiency, queries support for newer compression algorithms such as Zstandard or Brotli, and suggests using long command‑line options for clearer code examples. Overall, the sentiment is that the custom solution was deemed unnecessary compared to Git’s proven performance.
Decade-old RAM is making a comeback
CPU manufacturers are responding to sustained RAM price inflation by re‑enabling support for legacy DDR4 memory in upcoming processors. Gigabyte announced that new LGA 1700 motherboards will again accept both DDR4 and DDR5, with “dual‑format” chips slated for early 2027, reversing Intel’s 2024 DDR5‑only shift. AMD is following suit; Gigabyte revealed DDR4‑compatible AM4 boards to accompany the 10‑year anniversary launch of the Ryzen 7 5800X3D. DDR4, introduced in 2014, is now markedly cheaper than DDR5—e.g., a 32 GB DDR5 kit costs ≈ $620 versus $260 for an equivalent DDR4 kit—making it an attractive upgrade path despite DDR5’s higher speeds and efficiency. The market shortage is prolonging the viability of older sockets and chipsets, allowing users to retain existing DDR4 modules while awaiting broader price normalization.
Comments highlight a pragmatic view that older DDR3/DDR4 hardware remains functional and cost‑effective, especially in emerging markets where repurposed server components are common. Many note that performance gains from newer DDR5 are modest for typical use, while prices for identical DDR4 modules have risen sharply, a trend attributed to AI‑related demand and broader component scarcity. Users also report buying and reselling used RAM at profitable margins, expressing both appreciation for the durability of legacy systems and concern over inflation driven by AI and GPU demand.
PSPi 6 – Raspberry Pi in a PSP
PSPi 6 is an open‑source hardware project that replaces the mainboard of a PSP 1000 with a custom PCB housing a Raspberry Pi (Zero, Zero 2 W, or CM4 with carrier). The board provides an 800×480 LCD with adjustable brightness, integrated power‑management (charging, battery monitoring, power‑saving), and audio output (mono on Pi Zero/CM4, stereo planned). All original PSP buttons, joystick, and two extra buttons/joystick are retained, with LED and on‑screen status indicators. It supports a range of operating systems—RetroPie, Lakka, Ubuntu, Raspberry Pi OS, Batocera, Kali, etc.—enabling retro gaming, Linux computing, and general Pi software. Ready‑made boards are sold via othermod.com; design files are available for self‑manufacture (PCB files, component list, assembly instructions) but require advanced electronics skills. Documentation, troubleshooting, and compatibility guides are hosted on the project wiki. The hardware is released under a CC BY‑SA license, and the developer invites community contributions through bug reports, feature suggestions, Discord, and YouTube tutorials. Boards are shipping, with only minor, non‑functional revisions ongoing.
The comments show interest in the PSP‑based project, noting that PSP batteries tend to overheat and that inexpensive units on eBay can supply parts without sacrificing a functional console. There is curiosity about extending the design to newer PSP models such as the 2000 and 3000 series. Additionally, users question whether existing home‑brew PSP emulators remain effective or if a Raspberry Pi implementation offers a more modern or superior emulation option. Overall, the discussion balances enthusiasm for the hardware approach with practical concerns about component sourcing and comparative utility versus software emulators.
Retrofitting language models to operate over bytes
The byte‑ified model retains the overall LTLM structure (DTP, BLT, H‑Net) while operating on UTF‑8 bytes. Each byte receives an embedding from a large, sparsely‑activated table; the embedding is augmented with the longest matching subword suffix embedding to improve performance without added inference cost. A single mLSTM layer (the local encoder) contextualizes these byte embeddings, after which a non‑causal boundary predictor (using one‑byte look‑ahead) places patch boundaries during pre‑fill. Pooling selects the final byte representation of each patch as the patch embedding, which is fed unchanged into the deep global model inherited from the original subword LLM. Depooling adds the most recent patch representation to a linear projection of byte‑level encodings, and a stack of four mLSTM layers (local decoder) processes the result. The language‑model head projects the final byte vectors to next‑byte (and optional boundary) probabilities.
Byte‑ification proceeds in two stages. Stage 1 distills a subword model into the byte model by (i) training the boundary predictor to replicate subword token boundaries (>99 % accuracy), (ii) aligning pooled local‑encoder outputs with subword embeddings through L2 loss after a few frozen global layers (n≈4), and (iii) matching patch‑level likelihoods via a temperature‑scaled binary cross‑entropy loss, optionally combined with cross‑entropy. This stage requires only one forward pass through the full network and back‑propagation through the first n global layers, offering substantial efficiency before full end‑to‑end Stage 2 training. Parameter comparisons show modest differences (‑0.7 % to +4.5 %) relative to the original subword models.
Comments focus on the continued reliance on token-based models despite research into token‑free approaches, highlighting recent papers such as Byte Latent Transformers and Charformer. Several remarks criticize subword tokenizers for lacking causality, noting that BPE effectively accesses future bytes. A separate observation expresses disappointment with Nature’s direction, suggesting it strayed from its core expertise. Overall, the discussion reflects awareness of emerging token‑free work, skepticism toward existing tokenization methods, and critique of institutional choices.
Nix wrote half of my debugger
The post explains how Rewind VM, a deterministic virtual machine built with Nix, turns a Nix derivation into a full‑featured debugger. Because a derivation captures exact inputs—source, compiler, libraries, kernel, and VM configuration—Rewind can reproduce builds reproducibly, pack them into a read‑only EROFS image, and boot the VM with all debug symbols and source files available via Nix’s separateDebugInfo and debuginfod. The tool records each instruction step, allowing inspection of thread lanes, CPU ownership, and stack frames. Features include “Compare” to show the last shared event and first divergence between runs, “Check from here” to fork a run at any step and replay it under many schedules, and integration with gdb or a shell for deeper inspection. The author demonstrates detection of a classic race condition in a bank‑deposit program, pinpointing the exact step where a reschedule causes a stale balance write. Rewind also supports bookmarks, exportable run files, and example derivations (philosophers, waiter, config‑reload) that illustrate bugs and fixes. Nix’s hermetic derivations supply the core debugging infrastructure automatically.
Comments express optimism that AI could boost Nix adoption, noting its deterministic capabilities and engineering sophistication, especially in Rewind VM. Users admire the deterministic VM approach, comparing it favorably to older tools like rr, while also citing personal frustrations with Nix’s complexity and occasional reliability issues that erode trust. There is a recurring desire to adopt Nix despite challenges, and a belief that broader awareness of its benefits could increase uptake.
The comments express strong approval of the new generic target and its broad hardware support, praising its ability to extend the life of older devices and thanking maintainers for preventing electronic waste. Users convey enthusiasm for LineageOS as a preferred Android experience and appreciate its role in keeping phones functional. At the same time, there is criticism of Android’s limited deep‑learning capabilities and perceived rigidity compared with alternatives, reflecting disappointment with the platform’s customization constraints. Overall, the tone is largely positive with noted concerns about Android’s ecosystem.