Apple introduces M6 and M5 Ultra
Apple announced two new silicon chips: the M6 (2 nm) for Mac mini and the M5 Ultra for Mac Studio.
M6
- 2 nm process, 12‑core CPU (2 “super” cores, 4 performance, 6 efficiency) → fastest single‑threaded CPU core, 1.2× multithreaded speed over M5, 2.4× over M1.
- 12‑core GPU with a Neural Accelerator in each core, ~30 % higher AI compute than M5 and >8× M1.
- Dual 16‑core Neural Engine, delivering up to 2× peak AI compute versus prior generation.
- Up to 32 GB unified memory, 170 GB/s bandwidth (+10 % vs M5).
- Supports hardware‑accelerated ray tracing, Dynamic Caching, and 50 % higher geometry rates.
M5 Ultra
- First quad‑die Apple‑silicon using UltraFusion (two dual‑die M5 Max chips).
- Up to 36‑core CPU (12 super, 24 performance) → 1.25× single‑thread, 1.3× multi‑thread performance over M3 Ultra.
- GPU up to 80 cores, each with Neural Accelerator; up to 4.5× AI compute vs M3 Ultra, >6× M1 Ultra.
- 32‑core Neural Engine, advanced Media Engine (H.264/HEVC/ProRes encode/decode, AV1 decode).
- Unified memory up to 512 GB, 1.2 TB/s bandwidth (+50 % vs M3 Ultra).
Both chips integrate with Apple’s developer tools (Core AI, Core ML, Metal, Xcode) to enable on‑device AI model training and inference.
FDA authorizes first wearable device that monitors ketone and blood sugar levels
The comments combine a personal tribute with a focus on the new ketone‑sensing wearable, expressing cautious optimism that large datasets could advance research while questioning its practical value for most diabetics. Contributors note that ketone spikes typically accompany high glucose, making the added sensor potentially redundant, and raise concerns about accuracy, regulatory clearance, cost, and whether it truly qualifies as a “wearable.” Opinions diverge between seeing it as a useful tool for specific groups—such as those at risk for DKA or athletes—and viewing it as a marketing gimmick that distracts from improving core glucose sensor performance.
OpenAI Jalapeño: Better than Nvidia Blackwell
OpenAI’s “Jalapeño” is a custom inference ASIC developed with Broadcom, taped‑out in November 2025 (CoWoS) and brought to silicon within nine months. Designed on TSMC N3P, the chip uses a weight‑stationary systolic matrix engine (MXFP format), 64‑bit scalar cores, FP32/INT32 vector cores, and an out‑of‑order core with L1 cache, diverging from the typical scratch‑pad designs of GPUs and TPUs. It integrates 15.4 TB/s HBM4 bandwidth (≈10 Gbps per pin, supplied by Samsung) and achieves 13.4 PFLOPs MXFP4 at 700 W TDP, yielding the highest FLOPs‑per‑watt and HBM‑bandwidth‑per‑watt among contemporary accelerators.
Performance benchmarks (InferenceX) on models such as DeepSeek R1, Kimi‑K2.5, and GPT‑OSS show token‑throughput per MW exceeding Nvidia Blackwell, AMD, and Google chips, with single‑token prediction reaching >700 tokens s⁻¹ user⁻¹ at concurrency 1 and up to 1,400 tokens s⁻¹ user⁻¹ on larger models. Results are provided by OpenAI; no AgentX (long‑context, multi‑turn) data are available yet.
The architecture foregoes prefill‑decode disaggregation, using a homogeneous pool to maintain locality and reduce KV‑cache movement. Scaling is achieved via a 128‑ASIC rack (Vindaloo trays) interconnected with 32‑lane N3E I/O chiplets (800 Gb/s SerDes) and Tomahawk 6 switches, supporting up to 2,048 XPUs across 16 racks (≈160 kW total power). Software is programmed in Gluon (built on Triton) with Codex‑generated kernels; a megakernel (“gigakernel”) reduces launch overhead. Production is slated for gradual ramp‑up in 2027.
Comments reflect optimism that dedicated AI inference chips could dramatically reduce token costs and enable broader deployment, while also expressing skepticism about performance claims, benchmark comparisons, and speculative decoding benefits. Observers note competition may pressure Nvidia pricing and question OpenAI’s ability to mass‑produce chips at scale. Concerns are raised about potential monopolistic effects, water‑power constraints, and the long‑term viability of custom silicon versus general‑purpose GPUs. Overall sentiment mixes cautious enthusiasm for hardware advances with doubts about hype and market dynamics.
New Mac Studio with M5 Max and M5 Ultra
Apple announced the 2026 Mac Studio, offered with two Apple‑silicon options: M5 Max (18‑core CPU, up to 40‑core GPU, Neural Accelerators per GPU core, up to 128 GB unified memory) and M5 Ultra (up to 36‑core CPU, up to 80‑core GPU, up to 512 GB unified memory). Both chips deliver up to 4.3× faster on‑device AI compute versus M3 Ultra, 1.8× faster graphics and up to 1.3× higher CPU speed, with memory bandwidth reaching 1.2 TB/s. Storage performance is up to 2× faster via a next‑generation SSD; Thunderbolt 5 (120 Gb/s) and Wi‑Fi 7/Bluetooth 6 provide extensive connectivity, and multiple units can cluster via Thunderbolt 5/RDMA for up to 3× AI inference speed. The devices support up to eight external displays (four 5K 120 Hz Studio Display XDR), hardware‑accelerated ray tracing, and a Media Engine capable of 33 simultaneous 8K ProRes 422 streams. They launch with macOS 27 “Golden Gate,” featuring Siri AI and Apple Intelligence. Pricing starts at US$2,499 for M5 Max and US$5,499 for M5 Ultra, with pre‑orders August 25 and shipments beginning September 22. The product uses 35 % recycled materials and 40 % renewable‑energy manufacturing.
The comments converge on the impression that Apple’s new Mac Studio models deliver impressive CPU, GPU and storage bandwidth but are hampered by extremely high prices, especially for large unified‑memory configurations, and limited upgradeability. Reviewers note the appeal of local‑AI capabilities yet question whether the performance and token throughput justify the cost for most users, comparing it unfavorably to multi‑GPU or server solutions. Concerns also surface about memory pricing, thermal behavior of PCIe Gen 6 SSDs, lack of Linux support, and anticipated supply shortages, while a minority express satisfaction with the hardware and optimism about future AI‑focused software.
Queryable Executables
SELF is a file format where an executable is a SQLite database. Using binfmt_misc, the kernel launches a custom interpreter that opens the file (via argv[0]) as a SQLite database, reads segment tables to locate the entry point, and then transfers control to the program. The program can query and modify its own file, storing state (e.g., logs, configuration) transactionally alongside code and assets. A proof‑of‑concept web server (“self‑httpd”) demonstrates this: routes, visitor logs, and button‑press records are stored in tables routes, visits, and presses within the same file. Content updates are performed with standard SQL UPDATE and can be rolled back, enabling live site edits without redeployment. Existing SQLite features such as FTS5 virtual tables and sqldiff provide full‑text search and diffing of program versions. Deployment reduces to copying a single file; data migration can be expressed as INSERT … SELECT between attached databases. The approach collapses binary tooling, state management, and distribution into a unified, queryable executable format.
The discussion proposes using database migrations instead of post‑processing binaries for schema updates, and outlines a zero‑downtime self‑upgrade approach that writes new data into the existing file, signals the process, and relies on fork‑exec handover. It suggests extending the SELF schema to support multiple segment sets, which could enable multi‑architecture binaries and more efficient asset serving, but stresses that a publicly exposed service binary must never be self‑writable. The comment also notes the broader creativity of “cursed” projects, mentions virtual filesystem mounting via SQLite, and draws parallels to OS/400’s object‑oriented library model, expressing overall enthusiasm tempered by security caution.
Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
Maiao is a community‑maintained fork of the original adevinta/maiao, providing a Gerrit‑style stacked pull‑request workflow for GitHub, GitLab, Gitea, Forgejo, Bitbucket Cloud, and Cursor Origin. The tool adds the git review command, which creates one PR/MR per commit in the current branch, automatically establishes parent‑child dependencies, and registers native stacks where supported (GitHub Stacks, GitLab auto‑detected stacks). It tracks commits via Change‑IDs (using the Gerrit commit‑msg hook), supports git commit --fixup <sha> for iterative fixes, and auto‑rebases the stack when PRs/MRs merge. Provider detection occurs from the remote URL; for self‑hosted instances the provider is prompted once and saved in git config maiao.provider. Configuration options include maiao.useNativeStack (auto, true, false) to control native stack registration. The workflow enables granular reviews, clean history, automatic dependency handling, and seamless updates across multiple hosting platforms. Maiao is released under the MIT License; contributions follow the guidelines in CONTRIBUTING.md.
Comments express confusion and frustration about the repository’s shift from “adevinta” to “runetes” and the practice of opening separate pull requests for each commit. Users question compatibility with tools like jujutsu and inquire about support for GitHub’s stacked‑PR feature. Several remarks lament the loss of Gerrit’s UI/UX, wishing for similar review experiences on GitHub, while also noting that stacked PRs are already documented. Overall, the tone is mixed, combining curiosity, disappointment with the workflow, and a desire for more familiar review tooling.
Black hole singularity is a surface not a point
The provided excerpt contains only the paper title “Black hole singularity is a surface not a point” and a list of image placeholders (archive, license icon, BibSonomy, Reddit, Simons Foundation, Simons Foundation International, Schmidt Sciences). No substantive abstract, introduction, methodology, results, or conclusions are present to summarize.
The comments focus on correcting popular misconceptions about black holes, distinguishing the event horizon—a geometric surface—from the interior singularity, which some argue is a surface rather than a point. Contributors note that graduate‑level knowledge already covers these basics, criticize sensationalist journalism, and express uncertainty about the true nature of singularities, mentioning alternatives such as fuzzball models and unresolved quantum‑gravity issues. There is interest in clearer lay explanations, curiosity about observational tests of spin and horizon effects, and overall acknowledgment that theoretical understanding remains incomplete.
New Mac mini, featuring M6 and M5 Pro
Apple announced two new Mac mini models—M6 and M5 Pro—delivering up to 4× faster AI performance, 2× faster graphics, and 40 % higher CPU speed versus the prior M4. The M6 variant features a 12‑core CPU, 12‑core GPU with Neural Accelerators, dual 16‑core Neural Engine, 16 GB unified memory (configurable to 32 GB) and up to 170 GB/s bandwidth; benchmarks show 13.5× faster LLM prompts than M1 and 2× faster ray‑traced gaming. The M5 Pro variant offers an 18‑core CPU, 20‑core GPU with third‑generation ray tracing, up to 64 GB memory and 307 GB/s bandwidth, delivering 8.5× faster LLM prompts versus M2 Pro and 4.5× faster Blender rendering. Both models support Wi‑Fi 7, Bluetooth 6, 2.5 Gb Ethernet (optional 10 Gb), Thunderbolt 4 (M6) or Thunderbolt 5 (M5 Pro), HDMI, and front USB‑C ports. They run macOS 27 with Apple Intelligence and Siri AI. Pricing starts at $899 (M6) and $1,699 (M5 Pro), with availability September 22, 2026. The devices use 50 % recycled materials and renewable‑energy manufacturing.
Comments express mixed reactions to the latest Mac mini lineup. Many note disappointment with the sharp price increases that diminish the perceived value of earlier models, while still recalling positive experiences with past M‑series devices and their performance for development or server tasks. Skepticism appears around Apple’s marketing language such as “up to 2× faster” and the relevance of new AI‑focused hardware for typical users. Requests for clearer benchmark data, Linux support, and more affordable configurations coexist with curiosity about GPU‑core versus memory trade‑offs and anticipation of future releases.
When str.lower() is a security vulnerability in Python – Seth Larson
Python’s IDNA 2003 implementation uses the StringPrep algorithm, which requires Unicode 3.2.0 case‑folding rules (RFC 3454 tables B.2 and B.3). The standard library’s stringprep module imports unicodedata.ucd_3_2_0, but the case‑folding step calls str.lower(). str.lower() applies the Unicode version bundled with the interpreter (e.g., 17.0.0), not the required 3.2.0 tables. This mismatch causes different IDNA encodings for the same input, creating a security vulnerability (CVE‑2026‑17084). For example, "ᎠᎠ".encode("idna") yields 'xn--58da' under RFC‑3454‑compliant folding versus 'xn--kz9aa' with the newer Unicode folding. The remediation adds specific exceptions so that str.lower() behaves as if using Unicode 3.2.0 for the affected code points, restoring compliance. Users are advised to prefer the idna package (IDNA 2008) over .encode('idna') (IDNA 2003). The fix was contributed by Bitshift, Stan Ulbrych, Marc‑Andre Lemburg, and Petr Viktorin.
The discussion centers on the divergence between Python’s str.lower implementation and Unicode 3.2 specifications, with many commenters questioning whether this constitutes a true security vulnerability or simply a compliance bug. Technical concerns focus on IDN handling, SAN DNS matching, and the potential for Unicode conversion errors to be exploited, while the proposed fix—adding exceptions for specific code points—is viewed as overly hacky. References to similar past incidents and remarks about unexpected Unicode behavior (e.g., “ß”.upper) highlight broader unease, but consensus leans toward treating the issue as a spec‑violation rather than an immediate exploit.
Agentic Context Management: Memory and Cost as Architecture Problems
The paper “Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems” proposes a framework for handling the context (memory) of autonomous agents. It argues that memory limitations and computational expense should be addressed through systematic lifecycle management and architectural design rather than ad‑hoc heuristics. The authors introduce mechanisms for context pruning, summarization, and hierarchical storage that align with the agent’s operational phases, aiming to reduce token usage and improve efficiency. By redefining context handling as an integral part of agent architecture, the approach seeks to balance performance with resource constraints, offering a structured solution to the scalability challenges of large‑language‑model‑based agents.
The response expresses a favorable view of the paper, noting its clear explanation of context challenges in large language models and endorsing the proposed compaction with validation and predictive fetching approaches. It shows interest in a practical implementation, inquiring whether it handles non‑conversation document contexts, how it compares to RAG on large datasets, and what on‑premise deployment options exist, while outlining a plan to begin with memory engineering before scaling the system.
The comments convey mixed feelings toward Apple’s new M‑series hardware. Many acknowledge impressive performance and potential for AI work, yet most criticize the extremely high prices, limited memory options, and a closed macOS ecosystem that hinders customization, debugging, and Linux integration. Users express a desire for official Linux support, better‑priced configurations, and more practical local‑LLM models, while some remain loyal to Apple’s build quality and consider leasing or waiting for future chips. Overall, enthusiasm for hardware is tempered by concerns about cost, software restrictions, and limited AI‑focused tooling.