HackerNews Digest

None

Leanstral is an open‑source code‑generation agent for the Lean 4 proof assistant, released under Apache 2.0 and available via Mistral Vibe and a free API (labs‑leanstral‑2603). Built with a highly sparse 6 B‑parameter architecture, it is optimized for proof‑engineering tasks and can be upgraded through arbitrary MCPs, especially the lean‑lsp‑mcp. Evaluation on the FLTEval benchmark (formal proofs in the FLT project) shows Leanstral achieving 26.3 pass@2 and 31.9 pass@16, beating open‑source peers (GLM5 744 B ≈ 16.6, Kimi‑K2.5 1 T ≈ 20.1, Qwen3.5 397 B ≈ 25.4 after four passes) with a single pass. Compared with the Claude suite, Leanstral outperforms Sonnet 4.6 by 2.6 points at pass@2 while costing $36 (vs $549), and beats Claude Opus 4.6 in cost‑efficiency (Opus ≈ $1,650, 92× higher). Case studies include diagnosing a Lean 4.29.0‑rc6 rewrite‑tactic failure (suggesting “abbrev” over “def”) and translating Coq IMP semantics to Lean, generating correct inductive definitions and proofs. Users can start instantly with “/leanstall” in Vibe, download the weights for self‑hosted deployment, or access the API.

Meta is reaffirming its commitment to jemalloc, the high‑performance memory allocator used throughout its infrastructure. After a period of technical debt accumulation, Meta engaged with the jemalloc community—including founder Jason Evans—to reassess stewardship and revive the open‑source repository. The renewed focus aims to reduce maintenance overhead, modernize the codebase, and evolve the allocator for new hardware and workloads. Key improvement areas are: • Technical‑debt cleanup and refactoring for reliability and usability. • Enhancements to the huge‑page allocator (HPA) to better exploit transparent hugepages and improve CPU efficiency. • Optimizations for memory packing, caching, and purging to increase overall memory efficiency. • Performance tuning for the AArch64 (ARM64) platform to ensure strong out‑of‑the‑box behavior. Meta invites community contributions and feedback to guide jemalloc’s future development.

The repository quantifies fixable waste in U.S. healthcare using primary federal and international data, identifying ≈ $98.6 billion in annual savings across three issues: - **Issue 1 – OTC drug coverage ($0.6 B/yr).** Medicare Part D pays for prescription versions of drugs available over‑the‑counter. Implementing step‑therapy that requires OTC equivalents before coverage would eliminate this spend. Analysis uses 2026 retail OTC prices, a 30‑unit‑per‑claim estimate, and excludes PBM rebates/dispensing fees. - **Issue 2 – Brand‑name drug price differentials ($25 B/yr).** Medicare pays 7–25× higher prices than peer OECD nations. Applying international reference pricing (benchmarking against Germany, France, Japan, UK, Australia) based on CMS Part D gross spend and Peterson‑KFF 11‑country averages would capture the differential before rebate adjustments. - **Issue 3 – Hospital procedure markup ($73 B/yr).** Commercial insurers pay 254 % of Medicare rates for identical procedures (e.g., hip replacement $29 k vs. <$11 k abroad). Capping payments at 200 % of Medicare—via commercial reference pricing already used in Montana and many self‑insured employers—would reduce the $528 B commercial hospital spend by 21.3 %. Data sources include CMS HCRIS FY2023 cost reports, Part D Public Use File, OECD health statistics, and RAND pricing studies; all code is open‑source and reproducible. Issue 4 will examine pharmacy‑benefit‑manager practices.

The article defines the “small web” as non‑commercial, ad‑free sites accessed via standard browsers, contrasting it with the Gemini protocol—a minimalist, low‑commerciality system with roughly 6 000 capsules and a few hundred active users, primarily IT professionals. The author uses Gemini feed aggregators, which collect ATOM or RSS updates from many capsules onto a single page, and explores whether a similar aggregator could work for the broader small web. Kagi’s “small web” list, which includes sites that publish update feeds, grew from about 6 000 to 32 000 entries. After filtering out feeds lacking timestamps, invalid URLs, and sites with fewer than one update per month, ~9 000 active sites remained. On a typical day (e.g., March 15) these sites produced about 1 250 content updates, ranging from minor edits to new posts. The volume is too large for a single‑page daily aggregator, but the activity demonstrates a vibrant, growing community of private, non‑commercial websites despite the dominance of commercial web content.

The author migrated from Google Nest Minis to a fully local Home Assistant (HA) voice assistant using llama‑cpp and custom LLM models. Hardware includes a UnRaid NAS for HA, a Beelink MiniPC with USB4 and an eGPU enclosure (GPUs from RTX 3050 to 3090 tested), three HA Voice Preview satellites (one Pixel 7a as hub), and a USB4‑connected eGPU. Software components are llama‑cpp as the model runner, various Speech‑to‑Text (Voice In) and Text‑to‑Speech (Voice Out) options, and HA LLM integrations (LLM Conversation, LLM Intents) for tool calling, web search, weather, and music. Key findings: - Higher‑quantized GGUF models from HuggingFace outperform default Ollama 4‑bit models. - Stable Wi‑Fi and streaming‑enabled Piper TTS eliminated stuttered audio. - Prompt engineering (sectioned instructions, explicit tool‑call directives, removal of emojis) was essential for reliable weather, business‑lookup, and knowledge queries. - Automations bridge gaps where the LLM cannot invoke services directly, exemplified by a music‑assistant script mapping satellites to media players. - A custom “Hey Robot” wake‑word was trained in ~30 minutes on the GPU, achieving false‑positive rates comparable to Google devices. Overall, the setup provides a locally processed, privacy‑preserving voice assistant capable of core home‑automation tasks, though it requires considerable configuration and tuning.

NASA’s spaceflight software must remain robust despite limited hardware, radiation, and communication delays. Architects employ multiple identical computers—often five on the Shuttle, four on Orion, and dual “A/B” systems on Voyager—to provide fault‑tolerant voting and rapid switchover without Earth intervention. Early Apollo software introduced asynchronous load‑management that allowed low‑priority tasks to be dropped, enabling recovery from overloads (e.g., the “1202” alarm). Redundancy proved critical for Voyager’s launch‑phase safe mode, the extended life of Opportunity and Curiosity, and for updating sensors on Mars orbiters via star‑tracking software. Over time NASA shifted from exhaustive pre‑flight perfection toward designs that expect and recover from failures, integrating onboard fault detection and software updates. However, redundancy can introduce errors in its management layer, and increasingly complex code may propagate identical faults across all backups. Future crews‑ed spacecraft (e.g., Orion) will use four computers with parallel processors and a backup, emphasizing autonomous decision‑making while still confronting the challenge of software‑centric failure modes.

Oxyde ORM is an asynchronous, type‑safe ORM built around Pydantic v2 models and a Rust‑based SQL engine. It offers a Django‑style API (e.g., Model.objects.filter()), strong typing, full validation, and serialization. The core generates and executes queries in native Rust for high performance and supports PostgreSQL, SQLite, and MySQL. Features include async‑first operation with asyncio, transaction management via a transaction.atomic() context manager with savepoints, and Django‑style makemigrations/migrate CLI for schema migrations. Example usage demonstrates initializing the database, creating, reading, updating, and deleting records, and integrating with FastAPI via a lifespan hook. An auto‑generated admin panel provides CRUD, search, filters, and export for frameworks such as FastAPI, Litestar, Sanic, Quart, and Falcon. Benchmarks compare Oxyde’s operations per second against other Python ORMs. The project is under active development, MIT‑licensed, and welcomes contributions through GitHub issues and pull requests.

Beyond Meat’s chief executive stated that market conditions are currently unfavorable for plant‑based meat, emphasizing that “it’s just not the moment” for the category following the company’s recent rebranding to Beyond The Plant Protein Company. The comment reflects strategic concerns about consumer demand and growth prospects after the name change. No further financial data, product details, or operational metrics were provided in the excerpt.

ThermalMarky is a Python‑based tool that formats Markdown for thermal receipt printers. It supports basic Markdown (headers, bold, underline, lists) plus custom tags for alignment (`[align=center]`), horizontal lines, QR codes, and line effects. Users can print via a web UI with built‑in editor shortcuts, a CLI (`print.py`), or by piping content. Configuration is provided through a `.env` file, specifying printer connection type (USB or network), vendor/product IDs for USB devices, or IP/port for network printers, and printer limits (`MARKY_MAX_LINES`, `MARKY_LINE_WIDTH`). The project is Docker‑ready; `docker compose up --build` launches a HTTPS server on `https://localhost:8000` (self‑signed certificate). Bare‑metal setup requires Python 3.12+, `python-escpos`, and development libraries (`libusb‑1.0‑0-dev`, `libjpeg-dev`, `zlib1g-dev`, `libcups2-dev`). Example usage includes `python print.py file.md`, piping markdown, or `curl` POST requests. Linux USB access may need udev rules or privileged Docker execution. Tested with MUNBYN Thermal Printer / ITPP047UE‑WH‑UK.