HackerNews Digest

Tim Cook will transition from CEO to Executive Chairman of Apple’s board on September 1 2026, remaining CEO through the summer to assist with the hand‑over. John Ternus, senior vice president of Hardware Engineering, will assume the CEO role on that date and join the board. Arthur Levinson, longtime non‑executive chairman, will become lead independent director. Cook joined Apple in 1998, became CEO in 2011, and oversaw growth from roughly $350 billion to $4 trillion in market cap, revenue from $108 billion (FY 2011) to over $416 billion (FY 2025), expansion to 200+ countries, 500+ retail stores, and a 2.5 billion‑device installed base. He led the launch of Apple Watch, AirPods, Vision Pro, and expanded services to exceed $100 billion. Ternus, at Apple since 2001, led hardware engineering for iPad, AirPods, iPhone, Mac, and Apple Watch, introducing products such as MacBook Neo, iPhone 17 series, and advanced recycled‑material components. Both executives emphasize continuity, innovation, and sustainability.

The post describes a systematic optimization of a simple AST‑walking interpreter for the dynamic language Zef, improving performance from 35× slower than CPython to competitive with Lua, QuickJS, and CPython. Initial design used a 64‑bit tagged value, recursive evaluation, std::string keys, and hash‑table‑based scopes, yielding severe overhead. Optimizations applied include: 1. Parser‑generated dedicated AST nodes for each operator and RMW operator, eliminating string‑based dispatch (≈17.5 % and 3.7 % gains). 2. Removing unnecessary IntObject checks (1 %). 3. Replacing strings with hash‑consed Symbol pointers (18 %). 4. Inlining value functions via a separate header (2.8 %). 5. Overhauling the object model with pre‑computed storage offsets, inline caches, and watchpoints, reducing allocation and lookup costs (4.55× faster). 6. Streamlining argument handling, getter/setter specialization, callMethod inlining, and global method lookup tables (cumulative ~20 % gains). 7. Eliminating std::optional allocations, specializing argument types, improving slow‑path value handling, and specializing sqrt, toString, and array literals (additional 1–8 % each). 8. Build‑time tweaks (disable RTTI, hardening, asserts) added ~1–2 % each. Overall, the interpreter achieved a 16.6× speed‑up, becoming only ~2× slower than CPython and within 20 % of Lua/QuickJS, with further gains possible using a more efficient GC.

Jujutsu’s “megamerge” workflow uses an octopus merge (a commit with three + parents) to combine every branch a developer cares about—feature branches, bug‑fixes, pending PRs, local setup branches, etc.—into a single, local “megamerge” commit. The megamerge itself is never pushed; only its constituent branches are published. Because all work is built on this combined state, the codebase compiles and runs only if all parts interoperate, dramatically reducing surprise merge conflicts and making task switching frictionless. Creating a megamerge is simple: `jj commit --message "megamerge"` with each target branch as a parent, yielding an empty commit atop the merged history. New work is done above this commit. Changes are integrated using Jujutsu’s `absorb` (auto‑squash into downstream commits), `squash` (interactive or full), or `rebase` to move WIP commits onto appropriate branches. Convenient revset aliases streamline the process: * `closest_merge(to)` finds the nearest merge ancestor. * `stack` rebases a revset after `trunk()` and before the megamerge. * `stage` stacks the entire descendant chain after the megamerge. * `restack` rebases only mutable commits onto `trunk()` (`roots(trunk()..) & mutable()`). The workflow keeps the megamerge up‑to‑date, isolates personal changes from others’ branches, and enables rapid, low‑conflict development across many parallel streams.

None

The Kimi Vendor Verifier (KVV) is an open‑source tool released alongside the Kimi K2.6 model to help users confirm that their inference implementations match official behavior. It addresses frequent benchmark anomalies caused by incorrect decoding parameters and broader infrastructure inconsistencies across diverse deployment channels. KVV comprises six targeted benchmarks: Pre‑Verification (enforces temperature = 1.0, top p = 0.95), OCRBench (5‑minute multimodal smoke test), MMMU Pro (vision input preprocessing), AIME2025 (long‑output stress test for KV‑cache and quantization issues), K2VV ToolCall (F1 and JSON‑schema accuracy), and SWE‑Bench (full agentic coding test, not open‑sourced). The project collaborates with vLLM, SGLang, and KTransformers to fix root‑cause bugs rather than merely detect symptoms. Validation is performed pre‑release, and results are published on a public leaderboard to encourage vendor accountability. Full evaluation on two NVIDIA H20 8‑GPU servers took ~15 hours sequentially, with scripts optimized for streaming, retries, and checkpoint resumption. Vendors are invited to join; contact is provided.

PrismML announced Ternary Bonsai, a family of 1.58‑bit language models (8 B, 4 B, 1.7 B parameters) that use ternary weights {-s, 0, +s} encoded as {-1, 0, +1} with a shared FP16 scale per 128‑weight group. This representation yields a memory footprint ~9× smaller than standard 16‑bit models while maintaining full‑network quantization (embeddings, attention, MLPs, LM head). Benchmarking shows the 8 B model scores 75.5 average, 5 points higher than the 1‑bit Bonsai 8 B (70.5) and approaches Qwen3 8 B performance, despite using only 1.75 GB (vs 16.38 GB). Throughput reaches 82 tokens/s on Apple M4 Pro and 27 tokens/s on iPhone 17 Pro Max, with energy use of 0.105 mWh/tok (M4 Pro) and 0.132 mWh/tok (iPhone). Models run natively on Apple devices via MLX, are released under Apache 2.0, and extend the Pareto frontier for capability versus size, offering a trade‑off between the ultra‑compact 1‑bit Bonsai and higher‑quality models.

A 2‑layer decoder‑only transformer (≈25 k int8 parameters) has been implemented in hand‑written 6502/6510 assembly and runs on an unmodified 1 MHz Commodore 64. The model uses 4 attention heads (8‑dimensional each), 32‑dimensional token embeddings, and a 64‑unit feed‑forward network. All activations are Q8.8 fixed‑point (int16); weights are int8 with per‑tensor power‑of‑2 shift scaling, and biases are int16 pre‑scaled. Multi‑head causal self‑attention, softmax (via a 128‑entry exponent lookup table with a 14‑bit score shift), and RMSNorm are fully integer‑based; matrix‑vector multiplication is realized with shift‑and‑add because the 6502 lacks a multiply instruction. The model occupies ~6 KB code/token tables, ~25.3 KB weights, and ~5.8 KB activation buffers, fitting on a floppy disk with room to spare. Inference takes ~60 s per token, producing a SID beep per token. Training employs quantization‑aware training with fake‑quantized int8 weights and bias scaling, label smoothing, and periodic integer‑forward evaluation to select checkpoints based on int8 argmax accuracy. The repository includes scripts for training, building the C64 binary, and testing the full pipeline.

ggsql is an alpha‑release library that implements the grammar of graphics using pure SQL syntax. Plots are defined with a VISUALIZE clause that maps table columns to aesthetics (e.g., x, y, color), followed by DRAW layers (point, bar, histogram, smooth, boxplot, etc.) and optional PLACE annotations. SCALE clauses translate data values to visual properties (e.g., color palettes), and LABEL adds titles and axis labels. The SQL part of the query runs on the backend (DuckDB in the examples) and streams only the aggregated results needed for each layer, avoiding materialization of full datasets. ggsql targets SQL‑centric analysts, offering a declarative, composable interface that aligns with the grammar of graphics and works in environments like Quarto, Jupyter, Positron, and VS Code without requiring R or Python runtimes. Benefits include lightweight embedding, sandboxing, and efficient large‑scale data handling. Future plans mention a Rust‑based writer, theming, interactivity, a language server, and spatial data support, while ggplot2 development will continue unchanged.

None

Quantum computers threaten asymmetric primitives (ECDH, RSA, ECDSA, EdDSA) via Shor’s algorithm, but they do not compromise symmetric schemes such as AES, SHA‑2, or SHA‑3. The common claim that Grover’s algorithm halves symmetric security—requiring 256‑bit keys for 128‑bit security—is incorrect because: - Grover’s quadratic speed‑up requires a long, serial quantum circuit; parallelization only partitions the key space, degrading the advantage. - Realistic estimates (1 µs gate time, 10‑year run) show breaking AES‑128 would need ~1.4 × 10¹⁴ quantum processors each with ~724 logical qubits, yielding a depth × width cost far exceeding that of breaking 256‑bit elliptic curves with Shor’s algorithm. - NIST and the German BSI both classify AES‑128 (and larger) as Category 1 post‑quantum secure and keep all AES key sizes allowed through 2035. - NIST’s FAQ and IR 8547 stress that Grover’s practical impact is limited; no guidance advises doubling symmetric key lengths now. - Consequently, the post‑quantum transition should focus on asymmetric algorithms, while AES‑128, AES‑192, and AES‑256 remain safe for the foreseeable future.