HackerNews Digest

Japanese researchers have created a recycling process that extracts up to 90 % of lithium from spent electric‑vehicle batteries, far exceeding the <50 % recovery typical of conventional methods. The technique replaces sodium hydroxide with recovered lithium hydroxide, converting the “black mass” of battery waste into high‑purity lithium suitable for new cells and cutting associated carbon emissions by roughly 40 % versus standard recycling. Japan, which imports the majority of its battery minerals, could lessen import reliance and stabilize supply chains if the method scales. Current recycling rates are low—about 14 % of used lithium‑ion packs are captured—so collection infrastructure must be expanded. The developers aim to increase processing capacity by 2027 and target extraction of tens of thousands of tons of material annually by 2035, positioning the technology as a potential global benchmark for lithium recovery.

The article reviews Git’s experimental **git history** command, introduced in versions 2.54 and 2.55, which provides three sub‑commands—**fixup**, **reword**, and **split**—for atomic history rewriting without leaving the repository in a conflicted state. * **git history fixup \** folds staged changes into the specified old commit, creates a new commit hash, and automatically rebases all local branches that descend from that commit (optionally limited to the current branch). It does not operate on histories containing merge commits. * **git history reword \** opens an editor to modify an old commit’s message, then rebuilds the subsequent graph with new hashes, updating descendant branches while leaving the index and working tree untouched. * **git history split \** interactively selects hunks from a commit’s diff, creating two new commits (kept and dropped hunks) and rebases later commits onto the split pair. All operations are atomic and reject actions that would cause conflicts; unlike the tool *jj*, they cannot carry a conflicted state through a rebase. The command is part of core Git, requiring no extra installation, and the author expects future enhancements such as first‑class conflict handling.

Fundamentals of Wireless Communication (David Tse & Pramod Viswanath) comprises: - Introductory overview of wireless systems. - Detailed treatment of the wireless channel model. - Point‑to‑point communication covering detection, diversity techniques, and channel uncertainty. - Cellular system design, focusing on multiple‑access schemes and interference management. - Capacity analysis of wireless links and multiuser environments, including opportunistic communication. - MIMO technology in four parts: spatial multiplexing and channel modeling; capacity and multiplexing architectures; diversity‑multiplexing tradeoff with universal space‑time codes; multiuser MIMO communication. - Appendices: (A) detection and estimation in additive Gaussian noise; (B) foundational information‑theoretic principles. - Supporting material: references, index, instructor resources (solutions, lecture slides), examination copy, and short‑course content.

Arvind Narayanan’s keynote frames AI as a “normal technology” whose economic impact follows a four‑stage model— invention, innovation, diffusion, and long‑term adaptation—paralleling historic shifts such as electrification. He argues that current AI advances, especially large‑language‑model agents, improve capability faster than reliability; reliability gains (consistency, robustness, calibration, safety) lag behind accuracy gains, limiting immediate automation and keeping AI primarily a collaborative tool. Using software engineering as a case study, Narayanan shows that AI compresses the “execute” layer (coding) but leaves the “decide” and “deliver” layers (requirements, integration, accountability) largely unchanged, often expanding them. Consequently, productivity gains have not reduced employment; instead, demand for knowledge work grows, echoing Jevons’ paradox. He cautions against assuming a near‑term recursive self‑improvement (RSI) takeover, noting that creativity, clinical trials, and other non‑verifiable tasks remain bottlenecks. The future will involve humans operating, understanding, and supervising increasingly capable AI systems rather than being displaced by them.

None

Xcode must be installed, but all building, signing and notarizing can be run from the shell using the tools bundled inside Xcode.app: xcodebuild, notarytool, stapler and devicectl. First set the command‑line toolchain to Xcode ( sudo xcode-select –s /Applications/Xcode.app/Contents/Developer ). Perform one‑time GUI actions: log in with a paid Apple Developer account, create a **Developer ID Application** certificate (installed in the login keychain), and store a notarization credential with `xcrun notarytool store-credentials ` using an app‑specific password. Install **XcodeGen** (Homebrew or GitHub) and keep only a `project.yml` in source; the `.xcodeproj` folder is regenerated on each build. Add a `Local.xcconfig` containing `DEVELOPMENT_TEAM` and `BUNDLE_PREFIX` and exclude it from git. A single script (e.g., `scripts/release.sh`) automates the full pipeline: 1. Regenerate the project with xcodegen. 2. Archive via xcodebuild ‑‑archivePath. 3. Export a Developer ID‑signed app using an ExportOptions.plist. 4. Zip and submit to Apple with notarytool ‑‑wait. 5. Staple the notarization ticket using stapler. 6. Verify with spctl and copy the app to /Applications. After the initial setup, builds and deployments are completely headless.

Apple’s new on‑device SpeechAnalyzer (iOS 26/macOS 26) achieved a 2.12 % word‑error rate (WER) on LibriSpeech test‑clean, outperforming all tested Whisper models (Small 3.74 %, Base 5.42 %, Tiny 7.88 %) and the legacy SFSpeechRecognizer (9.02 %). On the noisier test‑other set SpeechAnalyzer recorded 4.56 % WER versus Whisper Small’s 16.25 % and SFSpeechRecognizer’s 16.25 %, a 3.5–4× accuracy gain. All engines ran fully on‑device on an Apple M2 Pro (32 GB, macOS 26.5.1), delivering 12–40× real‑time speed; SpeechAnalyzer was roughly three times faster than Whisper Small per second of audio. The benchmark used identical production code paths, a shared text normalizer, corpus‑level WER calculation, and forced on‑device processing (cloud fallback disabled). Limitations include English‑only evaluation, read‑audiobook speech, single‑hardware testing, and Whisper runs via quantized CoreML (differences may exist with GPU implementations). Whisper remains advantageous for multilingual support (~30 locales) and non‑Apple platforms.

Emily Eden, a British woman who lived in India during the mid‑19th century, is highlighted for her sketches that document the empire’s social diversity as it transitioned. The page lists numerous archival images (all dated 1844 or thereabouts) with alt‑text descriptions of portraits and genre scenes: Indian officials such as King Fateh Prakash and Raja Khurruk Singh; teachers, servants, and attendants at Government House in Calcutta; Muslim students and daughters of government employees in traditional dress; and assorted figures like Arabs and local dignitaries. The images emphasize clothing, jewellery, and status symbols, illustrating everyday life and hierarchical relations in northern India. Interspersed are unrelated entries—a headline about a typhoon evacuation in Zhejiang, China, and contemporary photos of a Bangkok fire and a brain illustration—indicating that the scraped page mixes the Emily Eden collection with unrelated news and visual content.

None

The x86 Ecosystem Advisory Group’s ACE extension builds on Intel’s AMX matrix‑multiply accelerator (TMUL) by keeping the same 8 KB tile registers but fixing tile dimensions (64 bytes × 16 rows), dropping complex‑number support, adding FP8, and providing outer‑product instructions instead of inner‑product ones. ACE takes its operands from AVX‑512/AVX10 vector registers, allowing larger output tiles (e.g., 32 × 64) and reducing the need to keep inputs in tile registers. It introduces VUNPACKB, VPERMB/VPERMI2B, and a 1024‑bit Block Scale Register (BSR0) for flexible 2‑to‑7‑bit quantization and per‑group scaling, similar to Arm’s SME2 lookup‑table mechanism but more general. Compared with Arm’s SME/SME2, ACE uses fixed‑width 512‑bit vectors versus scalable vector lengths (128‑2048 bits) and also accelerates outer products. Bandwidth analysis shows ACE’s tile‑based approach can lower cache traffic versus AVX‑512‑VNNI and AMX, potentially improving compute‑bound performance and allowing tile registers to serve as a limited scratchpad. No hardware implementation of ACE exists yet, so actual performance and efficiency remain uncertain.