Top 10 Hacker News posts, summarized
HN discussion
(775 points, 221 comments)
The article presents a browser-based version of Need for Speed Underground 2 playable via WebGL/WASM. It documents the implementation's features including cloud saves that sync across devices, mod support with a translations tab, and comprehensive control schemes for keyboard (WASD/arrows for steering, Space for handbrake, Shift/Ctrl for manual shifting, plus keys for nitrous, camera, hydraulics, horns, headlights, drift mode, and quick chat), touch controls with configurable thumb steering and tilt options, and gamepad support. The interface includes menus for fullscreen, controls, logs, and settings.ini editing. Multiplayer functionality appears integrated with free roam, outruns, messaging, and quick chat systems. The project loads game assets directly in the browser with no installation required.
Commenters express mixed reactions: nostalgia and amazement at smooth performance on older phones and tablets contrast with reports of stuttering, asset-loading issues, and the need for experimental Chrome flags (enable-unsafe-webgpu) to run. Technical skepticism centers on WASM/WebGL suitability for complex 3D games due to garbage collection pauses. Legal concerns dominate discussion—multiple users question the legality of hosting copyrighted game assets and soliciting donations, noting the game remains unavailable for purchase due to music licensing. The NFSU2Recomp GitHub project is referenced as a native recompilation alternative, though it's unclear if it includes the browser version's multiplayer features. Broader worries emerge about game preservation dynamics and potential industry crackdowns on such projects. Controller support questions and manual transmission confusion indicate incomplete on-screen control documentation.
HN discussion
(572 points, 329 comments)
Since macOS 13 (2022), every Mac runs two undocumented daemons that continuously build a personal knowledge graph stored in 51 SQLite databases under `~/Library/IntelligencePlatform`. The graph ingests data from Contacts, Calendar, Photos, Messages, Mail, location history, Screen Time, Family Sharing, Health emergency contacts, Siri Suggestions, App Intents, and device signals (Wi‑Fi, Bluetooth, charging, screen lock, and a “PhysicalSocial” proximity log). It models 181 entity classes and 278 predicates, assigning confidence scores to every inferred relationship. Notably, two on‑device XGBoost classifiers use 144 behavioral features — including messaging patterns, photo co‑occurrence conditioned on day/time (e.g., `photosPersonPosteriorProbabilityGivenSaturdayNight`), and household identifiers — to score 17 kinship labels (family, mother, partner, child, coworker, etc.) for each person. Deleted contacts are not fully removed; they move to an `expired_stable_graph` table retaining confidence and provenance for at least 48 hours, and inferred conclusions can outlive their source evidence. Apple provides no user‑facing documentation, inspection tool, or correction mechanism. The authors released **iKnow**, a local, read‑only dashboard that lets users browse their own graph, and demonstrated how the consolidated store — linking household members, calendars, locations, installed apps, and communication logs — creates a privacy “single point of failure” that could be weaponized if extracted.
Commenters expressed alarm at the scale and opacity of the on‑device profiling, with many noting it runs even when Siri and Apple Intelligence are disabled. Several argued the system violates GDPR’s purpose‑limitation and consent requirements, since data collected for communication or scheduling is repurposed for relationship inference without opt‑in. The lack of an off switch, the plaintext storage (albeit behind Full Disk Access), and the persistence of deleted data in `expired_stable_graph` were cited as critical flaws. Some users reported the graph’s inferences are often inaccurate or sparse, while others emphasized that accuracy is beside the point — the aggregated, linkable nature of the store makes it a high‑value target for attackers or future policy changes. A thread compared Apple’s on‑device approach favorably to cloud‑based profiling by Meta/Google, but others countered that local computation does not mitigate the absence of transparency, consent, or user control. The release of iKnow was welcomed as a rare inspection tool, and multiple commenters predicted regulatory action or class‑action litigation. A minority viewed the graph as a necessary substrate for useful on‑device LLM features (e.g., disambiguating “Text James”).
HN discussion
(302 points, 247 comments)
The Asahi Linux project's Linux 7.3 progress report details significant upstreaming achievements: the macaudio driver (~3,100 lines) and AVD driver (~13,000 lines) were submitted for mainline inclusion, alongside initial Devicetrees for M4 Pro/Max and M5 SoCs. The project is shifting to an upstream-first development model for components like TI USB-PD, SPMI, and Thunderbolt. M3 support is now generally available with DCP enabled, bringing sleep support and usable notch-area display on MacBooks. Reverse engineering advances include virtualizing macOS on M4/M5 via m1n1 (now spawning three EL1 VMs) and M3 GPU initialization demonstrated by drawing a triangle at XDC. After nearly five years, Thunderbolt support ships with USB3, XDomain, and Thunderbolt Networking functional, though PCIe and DisplayPort tunneling remain unsupported. Gaming compatibility improved via Android's P3S patchset enabling 4 KiB userspace pages on 16 KiB kernels, allowing some x86 games to run without the muvm VM penalty, though the solution is hard-coded and upstream viability uncertain. Microphone beamforming performance doubled via SIMD optimizations. Fedora Asahi Remix 45 shipped same-day as upstream Fedora. Citing exploitation of permissive licensing—code lifted from private forks, published without attribution, and obfuscated via LLMs—the project announced transition from MIT to GPLv2+ for all repositories.
The licensing change dominated discussion. Supporters praised the move as necessary protection against bad-faith appropriation and AI-driven code laundering, with some increasing donations. Critics argued the switch targets competitor distributions like Omarchy (which uses Asahi as a base), claiming it restricts ecosystem collaboration rather than protecting freedom. Omarchy's maintainers and users countered that their project is MIT-licensed and explicitly builds on Asahi, not replacing it. Several commenters questioned the fundamental motivation for running Linux on Apple Silicon given Apple's virtualization support, while others cited external display support as a remaining blocker. A separate project (Gravity Linux) claimed faster progress on Vulkan and suspend. The community also debated LLM use in reverse engineering, with Asahi noted as relatively anti-LLM, and some suggested Framework laptops as an alternative for Linux-friendly hardware.
HN discussion
(312 points, 216 comments)
Apple maintains a "grey list" of over 100,000 words and phrases that its predictive text and swipe-typing features will not autocomplete or complete via gesture input. Discovered by independent researcher Derik Kauffman, the list includes references to drugs, sexual acts, and corporate-protection phrases like "iMessage isn't working," alongside politically charged terms such as "Dictator Trump," "NSA spies," "Trayvon Martin," "Kashmir dispute," "Muslim extremist," and "male chauvinist pig." Language-specific restrictions also exist: Hebrew blocks "the occupied territories" and Arabic blocks "the Hamas movement." When users attempt to swipe-type these phrases, the keyboard often produces erroneous alternatives (e.g., "United Ireland" becomes "United Iceland"). Apple states the design avoids offering inappropriate or offensive predictive suggestions and notes users can still type any phrase manually. The list reflects the evolution of autocorrect from simple dictionary lookups to n-gram statistical prediction and, most recently, a transformer-based system resembling an LLM.
Commenters debated whether the grey list constitutes censorship or a reasonable safety feature. Critics argued the list's hidden nature and inclusion of specific political terms (e.g., "Trayvon Martin," "occupied territories") indicate ideological bias and soft coercion, with some questioning potential state pressure. Defenders characterized it as a practical guard against accidental sends of risky phrases via error-prone swipe typing, emphasizing manual typing remains unrestricted. Several users cited broader iOS keyboard quality issues—erratic autocorrect, the persistent "ducking" substitution, and degraded swipe accuracy—comparing unfavorably to Google's Pixel keyboard and the stagnating SwiftKey. Others noted such filtering is standard industry practice for PR protection, referencing Google's autocomplete controversies and Microsoft's Tay chatbot. A minority viewed the list as beneficial for preventing unintended messages, while others rejected Apple products entirely over the principle.
HN discussion
(327 points, 188 comments)
The author describes the formation and dissolution of Microsoft Research's AI Frontiers (AIF) group, a ~50-person sub-organization created in 2023 to pursue coordinated, fundamental AI research after ChatGPT demonstrated that individual efforts could not compete with well-resourced, focused teams. AIF produced work on agent frameworks (Autogen, Fara), novel architectures (Full Bandwidth Transformer, Next Latent objective), and shared infrastructure like a monorepo with model-building pipelines. In September 2024, AIF was reorganized into Microsoft AI (MAI) under ex-Inflection leadership. The author argues MAI's philosophy is exclusively "scaling-only"—prioritizing data and compute over research innovation—creating a fundamental incompatibility. After attempting to place team members, the author and other founding leaders departed. The author cites two reasons for not returning to core MSR: research lacks a path to real product use, and the implicit contract ("do good work and good things happen") was broken by the non-consensual reorg despite productive output.
Commenters largely frame the episode as emblematic of an industry-wide shift toward transformer scaling at the expense of exploratory research, with several noting similar dynamics at Meta and other labs. A recurring theme is Microsoft's historical pattern of shutting down successful internal projects (e.g., Microsoft Academic), suggesting systemic organizational dysfunction. Some defend the scaling focus as rational given current returns, while others argue basic research has migrated to venture-backed startups with equally short horizons. A few commenters question the author's framing, suggesting truly valuable research would not require organizational force to be adopted. The discussion also notes the article's unusual publication on Digg and clarifies that only the "AI Frontiers" subgroup—not Microsoft Research broadly—was dissolved.
HN discussion
(201 points, 182 comments)
Unable to fetch article: HTTP 403
The discussion reveals that many commenters found the DNA confirmation of Gothic origins in Scandinavia unsurprising, citing longstanding linguistic and geographic evidence such as the names Gotland, Götaland, Gothenburg, and the Geats. Several users noted that Gothic presence in the Black Sea region was already documented via the 4th-century Wulfila Bible, while others highlighted the tribe's linguistic legacy in Spanish words like *bandido*, *casco*, *tregua*, *casa*, and *sofá*. Questions arose about the drivers of the migration—whether climate change or other pressures prompted a movement of whole communities rather than just warriors—and some drew parallels to Herodotus, whose once-doubted accounts have also been validated by modern archaeology. Humorous asides contrasted the historical Goths with the modern subculture, and a few users referenced prior popular coverage (e.g., *Hardcore History*) and Swedish historical claims to the Gothic lineage.
HN discussion
(190 points, 192 comments)
Discord is replacing its Electron-based desktop client with a new Rust implementation called "Discord Phoenix," built on the GPUI framework from the Zed editor team. In a cold-start comparison video shared by CTO Stanislav Vishnevskiy, the Rust client loaded the friends list before the Electron app cleared its loading screen, using 290.2 MB RAM with two accounts signed in simultaneously—roughly 70% less than the Electron version's typical 1–2 GB idle usage. The new architecture eliminates the "Starting" update screen by bootstrapping instantly and auto-updating in the background. Discord chose GPUI over alternatives like Tauri or WinUI for cross-platform GPU-accelerated rendering without HTML, while retaining system webviews for embedded content like YouTube and Activities. Mobile apps will drop React Native in favor of shared Rust logic with native UIs, and the web client will shift logic to WebAssembly. Private testing begins soon with no public release date announced.
Commenters acknowledged the performance gains but emphasized Electron's enduring value proposition: enabling small teams to ship cross-platform apps with minimal effort using existing web skills. Several noted that Discord's rewrite is unreleased and unproven at scale, with concerns about accessibility and IME support in Rust GUI toolkits—a known weak point compared to Electron's mature web-based accessibility. Others pointed out that Microsoft Teams and Outlook obscure memory usage by running under Edge processes, while apps like Signal and VS Code remain on Electron. Some argued Discord's path (Electron → React Native → Rust/GPUI) reflects poor strategic choices compared to Kotlin Multiplatform for true native code sharing. A few users highlighted alternative approaches like Crux (Rust core with native UI shells) or Raycast's hybrid model, while others simply expressed frustration with pervasive software bloat and hope for a broader shift toward native tooling, potentially accelerated by LLMs.
HN discussion
(281 points, 66 comments)
The author details their experience running a homelab on a $10 OpenStick, a compact ARM-based device with 512 MB RAM (450 MB usable), 4 Cortex-A53 cores at 1 GHz, 4 GB eMMC, Wi-Fi, 4G modem, GPS, and passive cooling. Despite modest specs, the device runs Debian with systemd and Podman, hosting a suite of lightweight self-hosted services: CastSponsorSkip for skipping YouTube sponsorships on Cast devices; an AdGuard Home fork for DNS-level blocking (blocking 60% of queries); Zeroclaw, an AI agent harness accessible via Telegram for server monitoring; Cloudflare Tunnel for secure external access; Beszel and Dozzle for system and container monitoring; Gatus for service uptime monitoring; Fusion RSS for feed reading; Shiori for bookmark archiving; and Diun for container update notifications. Total memory usage remains well within the device's constraints, demonstrating the viability of ultra-low-cost self-hosting.
Commenters discuss alternative hardware (ChromeBoxes, used Xeon workstations, RPi Zeros), with several noting the OpenStick's price appears to be $20 rather than $10. Technical questions arise about using Wi-Fi instead of 4G for connectivity, whether Debian is preinstalled or other distros can run, and requests for the author's AdGuard Home fork source code. Some users suggest Podman auto-update as a lighter alternative to Diun, while others debate the privacy implications of Cloudflare Tunnel. One commenter offers ~300 units for sale with original firmware/IMEI preserved. The thread reflects interest in minimal-resource self-hosting and practical considerations around device availability, backup strategies, and monitoring trade-offs.
HN discussion
(228 points, 102 comments)
The author, a solicitor running decoded.legal (a small English law firm specializing in Internet, telecoms, and tech law), provides a 2026 update on operating their practice entirely on Free and open-source software. On the client side, they use Debian with GNOME on a ThinkPad X1 Yoga, relying on Thunderbird and mutt for email, LibreOffice Writer for Word-compatible documents, pandoc and typst for Markdown-to-PDF workflows, reveal.js for presentations, and a suite of terminal-based tools (vim, ikhal, newsboat, etc.) for efficiency. File synchronization uses Syncthing with Cryptomator encryption, while password management employs Bitwarden/vaultwarden with YubiKeys. The server side is self-hosted on Intel NUCs, running postfix/dovecot for email, Syncthing and radicale for file/calendar sync, Signal for video calls, InvoicePlane and Kimai for invoicing and time tracking, EspoCRM for matter management, WireGuard for VPN, and various monitoring/security tools (Wazuh, Uptime Kuma, OpenVAS). The website and blog are static (mkdocs, BSSG), hosted on Apache with a Tor onion service. Mobile uses a Pixel with GrapheneOS and F-Droid. The author emphasizes zero compatibility issues when working with clients using Microsoft or Apple ecosystems.
Commenters expressed both admiration and skepticism. Several questioned the operational risk of a solo practitioner managing complex self-hosted infrastructure, citing the "bus factor" if the lawyer becomes unavailable, the time burden of DevOps maintenance, and potential client expectations for institutional reliability and security certifications. Others debated the practicality of non-Microsoft Word workflows in legal practice, with one commenter claiming a respected open-source lawyer stated avoiding Word could constitute malpractice, while another practicing lawyer reported successful long-term LibreOffice use. Technical discussions included email delivery challenges with self-hosted Postfix (prompting a fallback to Google Workspace), accounting software gaps (GnuCash, ERPNext mentioned), and the redundancy of Pi-Hole alongside Unbound. A recurring theme was the tension between ideological commitment to software freedom and the pragmatic demands of legal service delivery, with some arguing the lawyer's time is better spent on law than system administration.
HN discussion
(192 points, 84 comments)
The article documents the author's experience getting the $8 Pine64 Ox64 RISC-V board running Linux. The Ox64 features three heterogeneous cores (64-bit 480MHz C906, 32-bit 320MHz E907, 32-bit 150MHz E902) and 64MB PSRAM, but at the time of writing lacked working ethernet, wifi, and SD card support. Programming requires UART via GPIO pins rather than USB, and the author encountered six hurdles: the official DevCube flashing tool crashes on Wayland; a CH340G USB-UART dongle failed handshakes; an RP2040 (KB2040/Pico) was needed as a serial bridge running picoprobe; DevCube still couldn't flash the board, requiring bflb-mcu-tool instead; and bflb-mcu-tool required source modification to strip DTR/RTS handling. After overcoming these, the author achieved serial console output from the board.
Commenters contextualized the Ox64 against alternatives: the $9 CHIP computer was more capable; the Raspberry Pi Zero sold for $5; and current options like the LicheeRV Nano (SG2002, $15-20), Milk-V Duo ($6, with working Linux 7.0/WiFi/Bluetooth), and Banana Pi boards with vector-capable C908 cores offer better peripheral support. Several noted the Ox64's kernel repo appeared inactive since 2023 with peripherals still unsupported. Others highlighted the board's appeal as a tiny GPIO-enabled Linux device rather than pure cost savings, while some shared parallel tinkering projects using $10 USB 4G dongles or free older hardware. The discussion reflected both enthusiasm for cheap RISC-V experimentation and pragmatism about choosing boards with working software stacks.
Generated with hn-summaries