Top 10 Hacker News posts, summarized
HN discussion
(367 points, 294 comments)
Andrej Karpathy describes an experiment where he gave Opus 5 (Anthropic's model) the first paragraph of *The Lord of the Rings*, a 1M token budget (~$10), and asked it to create a Three.js procedural rendering of the story. The model spent ~2 hours generating 5,500 lines of code that procedurally places and animates polygon assets in 3D coordinates. Karpathy notes the result is "janky but fun" and highlights the shift from "no one would ever do this" to "sure, why not, it's ~free" for hyper-custom content creation. He envisions ephemeral, on-demand worlds (like "GTA Hobbiton") where users could participate as NPCs or characters. However, he identifies a key limitation: LLMs cannot efficiently perceive or play within their creations, forcing Opus 5 to slowly take screenshots to audit its work, leading to errors. The project is playable at karpathy.ai/lotr-movie/.
Commenters express skepticism about the pelican SVG test as a meaningful benchmark, with several calling it a "gimmick" or "marketing slop." Former game developers argue that AI-generated "games" show zero genuine engagement—players click links out of curiosity about the tech, not the gameplay, and no AI-generated experience has retained players for 15+ minutes. Critics note Karpathy's apparent shift from claiming reliable agents are a decade away to promoting Anthropic's capabilities. Technical observations include that Anthropic models may be overtrained on Three.js specifically, that LLMs lack the iterative playtesting essential to game design, and that the LoTR demo misinterprets narrative events (e.g., Bilbo's disappearance as teleportation). Some suggest the future lies in "throwaway software" generated cheaply and discarded if broken, while others point to CAD/engineering domains where rigorous interpretation engines guarantee visual correctness.
HN discussion
(182 points, 116 comments)
The article analyzes changes between the 1953 General Service List (GSL) and the 2023 New General Service List (NGSL), two curated vocabulary lists for English language learners covering over 84% and 90% of general English usage respectively. Over 70 years, roughly 600 words were dropped and 1,100 added. The shift reflects a move from concrete, physical-world vocabulary (e.g., *fork, soap, goat, flour, bake*) toward abstract, institutional, and systemic terms (e.g., *mortgage, corporation, analysis, legislation, perspective*). Semantic categorization shows declines in categories tied to the immediate physical world (Food and Farming, Objects, Body) and growth in abstract concepts, government, commerce, and science. Concreteness ratings confirm a significant reduction in sensory-grounded words. Adverbs nearly doubled in share, adding precision modifiers like *approximately, definitely, relatively* to qualify abstract claims. The author argues this linguistic shift mirrors societal transformation: a life less centered on direct making and physical surroundings, more mediated by complex systems, regulations, and distant institutions.
Commenters engaged with both the linguistic findings and the article's presentation. Several noted the semantic shift in social vocabulary: words for direct interpersonal virtues (*humble, loyalty, fellowship*) were replaced by terms for group identity and structural belonging (*community, identity, ethnic, gender, narrative*), which one user linked to rising inequality and tribalization. Others highlighted the practical difficulty of creating universal vocabulary lists, as priority words differ vastly by learner goal (travel, media consumption, news, daily life). A technical perspective connected the rise of precise, abstract language to computing's influence, where unambiguous, logical expression is required, contrasting with the probabilistic, subjective output of LLMs. Multiple users criticized the webpage's scroll-jacking animations and readability issues, advocating for standard scrolling or reader mode. One commenter questioned whether percentage-based category comparisons were distorted by the list's overall growth from 2,300 to 2,800 words, though acknowledged absolute counts likely aligned with the reported trends.
HN discussion
(138 points, 60 comments)
F* is a general-purpose proof-oriented programming language developed by Microsoft Research, Inria, and the community, combining dependent types with SMT-based proof automation and interactive theorem proving. It supports both purely functional and effectful programming, compiles by default to OCaml, and can extract to C, WebAssembly, F#, or assembly via KaRaMeL and Vale toolchains. F* is open source under Apache 2.0 and bootstrapped using OCaml. The language features Low*, a low-level subset for verified systems programming, and extensive learning resources including an online book and tutorials. F* is used in production through Project Everest, which delivers verified cryptographic libraries (HACL*, ValeCrypt, EverCrypt) deployed in Firefox, Linux kernel, Python, WireGuard, and Tezos, as well as EverParse for verified binary parsers used in Windows Hyper-V and Azure. Research applications span semantics and effects (Dijkstra monads, concurrent separation logics like SteelCore and PulseCore), security and cryptography (TLS 1.3, QUIC, Signal protocol, MLS), systems (WebAssembly sandboxing, memory allocators), parsing (ASN.1, CBOR), and programming language verification (Rust translation, garbage collectors, quantum logic).
Commenters express mixed reactions: one user praises F* for incremental C migration and external library interoperability, while another criticizes the website for lacking prominent code examples and syntax demonstrations. Questions arise about F*'s suitability for compiler implementation and formal verification of compilers, and whether it handles basic types (subtraction, u8) better than Lean. A user notes F* appears to be a collection of multiple languages and proof systems, making it difficult to understand. Industry adoption is questioned, with a response pointing to the tutorial page. Another commenter seeks real-world experience reports from practitioners.
HN discussion
(131 points, 57 comments)
Unable to fetch article: HTTP 403
The discussion centers on the sentencing details for seven former eBay security employees who orchestrated a harassment campaign against a newsletter editor and her husband, with commenters noting the surprisingly lenient sentences for some (including time served and home confinement) versus 57 months for the former Senior Director of Safety. A dominant thread of skepticism questions whether this was an isolated incident, with multiple users finding it implausible that seasoned professionals—including former police captains—would escalate to cross-country intimidation and vandalism without prior similar conduct, and speculating about potential broader targeting of other critics. Additional reactions highlight the absence of charges against senior executives who may have directed or enabled the operation, while tangential comments criticize eBay’s seller fee structure and cite the case as an example of unsupervised corporate power enabling systemic abuse.
HN discussion
(150 points, 36 comments)
Kakehashi is an experimental userspace translation layer that runs macOS ARM64 (Darwin Mach-O) binaries natively on Linux aarch64 without JIT compilation. It loads a freestanding `libSystem`, translates BSD syscalls, and handles TLS switching, alt stacks, and NEON register save/restore at the syscall boundary. Current working prototypes include 7-Zip (`7zz`) with multi-threaded compression, `curl` with over 200 command/option combinations passing automated tests, and basic Xcode Tools `git` commands. The tool installs via `cargo install kakehashi`, manages a "bottle" at `~/.local/share/kakehashi/bottle/` that bridges the host filesystem at `/Volumes/linux/…`, and provides a `kh` CLI for installing and running guest binaries. Performance on 7-Zip multi-file compression is approximately 5.2× slower than native Linux execution, attributed to syscall-boundary overhead and path-walk costs rather than algorithmic differences. The primary product goal is CI cost reduction: GitHub Actions macOS runners cost roughly 10–12× more per minute than Linux arm64 runners, so even a 5× slowdown can yield lower billable cost. The project explicitly states it is not derived from Darling and vendors no proprietary Apple SDKs or blobs, licensing under Apache 2.0.
Commenters expressed strong interest in the concept, with several noting they had waited for such a tool. The author (vlad_kalinkin) confirmed working prototypes for 7-Zip, curl, and Xcode git, and acknowledged the early stage. Multiple users asked about the relationship to the Darling project (which has an open ARM64 PR); the author and others clarified Kakehashi is a clean-room, CLI-first approach distinct from Darling's broader macOS compatibility layer. One commenter questioned how clean-room status could be verified. Another asked whether a virtualization framework using a real macOS rootfs (like console decompilation projects) would be simpler. There was interest in running Audio Unit (AU) plugins via a yabridge-like layer and in building iOS apps on Linux ARM runners. One user inquired about total development hours, and another claimed the README appeared AI-written.
HN discussion
(168 points, 17 comments)
Meshdiff is a browser-based, client-side 3D diff tool for visually comparing two STL, 3MF, or OBJ files. It renders a voxel-based difference view directly in the browser using a Web Worker, with green indicating added material and red indicating removed material. Users can adjust tolerance (0.05–1mm) and view volume delta metrics. The tool requires no file uploads, preserving privacy. Built with React, TypeScript, React Three Fiber, and a custom voxel diff engine, it avoids libraries like Manifold or CGAL because real-world STLs are often "triangle soup" rather than clean CSG topology. The developer created it to solve the problem of clients sending iterative filenames (e.g., `part_v3_FINAL.stl`) without a quick way to see changes.
Commenters praised the tool's utility and client-side approach, with several noting they had immediate use cases. Feature requests included synchronized viewports (locking rotation across diff panes), warnings when comparing a file to itself, and support for multi-group OBJ files. There was interest in a CLI or CI integration for automated diff generation, and suggestions to embed Meshdiff as a GitHub PR check for 3D assets. One user initially confused "STL" with the C++ Standard Template Library. The author acknowledged the feedback and indicated a roadmap for improvements.
HN discussion
(164 points, 21 comments)
Bor v0.8.0 introduces three new policy types — Thunderbird, Microsoft Edge for Business, and Firewalld zones — alongside a comprehensive web UI overhaul built on PatternFly 6, per-action RBAC for finer-grained delegation, and a dedicated security hardening pass. The Thunderbird and Edge policy types integrate with existing package formats (RPM, DEB, Flatpak) and include tamper-protected managed files with full policy editors in the UI. The Firewalld zone type manages zones, services, ports, and rich rules with validation via `firewall-cmd`. The web UI modernization adds URL routing, server-side paginated lists, full-page policy editors with safety rails (unsaved-changes guards, JSON validation, setting previews), destructive-action protection, and WCAG 2.2 AA accessibility. Policy catalogues are now protobuf-generated for a single source of truth across server, agent, and frontend. Security improvements include strict mTLS-bound agent identity, TOTP secret migration to HKDF, SSRF protection for repository helpers, spreadsheet formula injection guards, removal of initial admin password from logs, automatic TLS certificate regeneration, and resolution of all Dependabot alerts. The release upgrades to React 19.2, react-router 8.3, gRPC 1.82.1, and Go crypto 0.52.0, with packages available for major distributions across x86_64, aarch64, and ppc64le.
Commenters expressed strong interest in Bor's positioning relative to existing solutions (Intune, Cosmic Sync) and asked for clarification on competitive differentiation. Feature requests centered on Linux Mint Cinnamon support, custom script execution, SCAP/DISA STIG compliance, and screen-time enforcement for parental controls. Technical questions focused on configuration drift handling without polling (answered by the author noting inotify-based tamper detection), conflicting policy resolution across sources, and LDAP-only authentication for non-domain personal machines. The mTLS/gRPC push architecture drew praise, while documentation diagrams were criticized as ad-hoc ASCII with a suggestion to adopt Mermaid. Several users managing small fleets or non-profits indicated immediate intent to evaluate the tool.
HN discussion
(143 points, 25 comments)
RISC OS Open Ltd (ROOL) celebrates its 20th anniversary on 20 June 2026, marking two decades since its incorporation with the goal of opening the proprietary RISC OS to community collaboration. The article chronicles yearly milestones: the initial shared source release in 2006-07, the Bounty Scheme for community-funded features (2010), the pivotal Raspberry Pi port that dramatically expanded the user base (2012), the first stable ROM release in years supporting legacy hardware (2013), and the landmark Apache 2.0 relicensing in 2018 after Castle's acquisition by RISC OS Developments. Subsequent years brought public GitLab migration (2019), Raspberry Pi 4 and 400 support (2020), NVMe and native Git client integration (2023-24), and the launch of the Moonshots initiative (2024-25) to fund full-time engineering for a 64-bit Arm transition. The project also recovered a long-lost Fortran compiler from archival tape. ROOL credits the community—code contributors, bounty funders, testers, and forum participants—for transforming RISC OS from a moribund proprietary system into a actively developed, multi-platform OS.
Commenters with Acorn Archimedes experience express surprise at the project's longevity, noting most original users had left by the mid-1990s and the community was always small compared to Amiga or Atari ST. Several emphasize RISC OS's historical significance as the original ARM operating system and its design influence, with Sibelius (originating on Archimedes) cited as a notable surviving application. A former developer recalls writing ARM assembly applications like !Director, highlighting the platform's accessible low-level programming. Technical praise focuses on RISC OS's exceptionally fast boot time on Raspberry Pi versus Linux alternatives. Criticism targets the project website's lack of screenshots for a graphical OS. One commenter speculates a growing niche for custom hardware running OSes free from AI, ads, and spyware, grouping RISC OS with ReactOS and Haiku.
HN discussion
(73 points, 41 comments)
The article presents a personal AI benchmark challenging multiple language models to generate an SVG of a frog with a Habsburg jaw (mandibular prognathism). The provided content displays raw SVG outputs from several models — including Anthropic's Claude Opus 5 and multiple Google Gemini variants — each rendering the prompt with varying anatomical fidelity. The SVG code includes inline comments labeling features such as "massive protruding mandible," "recessed upper lip," "protruding lower teeth over the upper lip," and "Habsburg jaw," revealing how each model interprets and structures the exaggerated deformity. Outputs differ in visual coherence: some integrate the jaw naturally into the frog's head, while others produce a disconnected "blob" for the mandible. Annotations across models range from neutral structural labels to editorial descriptions emphasizing royal bearing or anatomical deformity.
Commenters treat the benchmark as a practical test of instruction following and hallucination control. A key observation is that 7 of 14 models silently introduced royalty motifs (crowns, regal posture) despite the prompt specifying only an anatomical trait, with two models explicitly acknowledging the extrapolation ("because Habsburg") and doing it anyway. Determinism varies: Mistral produced byte-identical outputs across runs, while Gemini narrates its reasoning in dozens of comments and Llama remains silent. Opus 5 is widely rated the strongest result ("frogmaxxed"), with Gemini 3.6 Flash also praised for handling the royal portrait context. Several users request additional models (DeepSeek v4 Flash, GPT-5) and note the benchmark's utility for evaluating how much models embellish beyond explicit instructions. Skeptics question the practical relevance of SVG frog benchmarks, while others propose alternative tests (mammoths in non-majestic poses, Batman with Julia Child, MacBook rendering).
HN discussion
(79 points, 29 comments)
The EU's open-source age-verification project mandates hardware-bound attestation as a core architectural requirement, using protected hardware (Android TEE, StrongBox, Apple Secure Enclave) to store cryptographic keys and prevent credential cloning. While the system aims to prove age without revealing personal identity, critics argue this design creates dependency on a limited set of approved devices, operating systems, and attestation providers. The reference implementation requires native cryptographic hardware but does not universally mandate stricter checks like root detection or Play Integrity, leaving those to individual deployers. A separate governance rule requires Proof of Age providers to issue credentials only to applications on an EU Commission-maintained compliance list, meaning open-source code alone does not guarantee service access. Linux is not explicitly banned but lacks a native wallet; desktop users would need a supported mobile device to scan QR codes. The project plans to publish a security review and threat model to justify the hardware-binding trade-off.
Commenters focus on three main concerns: the effective exclusion of Linux and alternative OS users who would need a second Google/Apple-approved device; the anti-competitive implications of governments mandating reliance on proprietary hardware ecosystems; and privacy risks from hardware attestation exposing unique device identifiers that could be correlated across services and linked to purchase records. Several note that hardware-bound keys are not inherently problematic, but restricting trust to Apple/Google ecosystems is. Practical usability questions arise about requiring mobile approval for every desktop website visit. Some comments reference related HN discussions on digital ID and age verification, while others express broader political frustration with EU digital policy direction.
Generated with hn-summaries