Top 8 Hacker News posts, summarized
HN discussion
(290 points, 178 comments)
Adult film producer Strike 3 Holdings, which files thousands of "John Doe" copyright lawsuits annually against anonymous BitTorrent users, has identified a Meta Reality Labs executive as the subscriber behind a residential AT&T IP address sued in a routine piracy case. Strike 3 alleges the executive downloaded nearly 20,000 files, including VR adult titles compatible with Meta's Quest headset, and argues the timing is suspicious: residential infringement appeared hours after Strike 3 notified Meta's lawyers of BitTorrent activity on corporate IP addresses in March 2025. Strike 3 has moved to relate this John Doe case to its separate $446 million lawsuit against Meta—accusing the company of downloading 2,973 films for AI training—so the executive's home downloads can serve as evidence. Meta opposes the linkage, arguing an IP address does not identify the infringer, the downloads could be personal use by a household member, and Strike 3's theory contradicts its own claim that corporate downloading continued long after the March notice.
Commenters expressed skepticism that a Meta executive would torrent over a home IP without a VPN, suggesting household members could be responsible. Many noted two plausible readings of the timing: either Meta deliberately shifted infringing activity to a residential connection, or the executive was personally torrenting at work and moved activity home after being warned by corporate IT. Several highlighted Meta's rebuttal that Strike 3's own complaint alleges corporate downloading persisted after the notice, undermining the "shift" theory. The volume and variety of downloads—including mainstream media, software, and books alongside VR porn—were cited as evidence against a coordinated AI-training operation. Strike 3 was characterized as a prolific copyright troll, and some questioned whether fair use defenses for AI training could apply. A few commenters speculated the downloads might relate to content moderation filter training rather than generative AI.
HN discussion
(374 points, 83 comments)
The author details their month-long process of solving the Jane Street Reverse Engineering Challenge, which required reverse engineering an ASIC from a GDS (Graphic Data System) file. After initially building custom tooling including a circuit simulator, parser, GDS viewer, and waveform viewer—all later abandoned—the author used Python's gdstk library to parse the GDS files and identified the sky130_fd_sc_hd standard cell library. The warmup puzzle (27 components) was solved by extracting a netlist, converting to Verilog, and simulating a circuit containing shift registers, an adder, and a comparator to find a 120-bit input sequence summing to 496. The main puzzle (nearly 10k components, 81 types) required implementing 40 additional cell types and optimizing extraction performance. The author discovered a bug in the challenge circuit (an undriven wire connected to non-I/O pins), which Jane Street confirmed. Using Z3 as a constraint solver with a backward-time simulation approach, the author solved for the 120-bit input by constraining 24 wires to be high at step 120, ultimately finding the solution that produced the "TWO STARS" output.
Commenters discussed the challenge's relevance to Jane Street's trading operations, speculating it tests skills for ultra-low-latency hardware optimization. Multiple solvers shared alternative approaches: Karel Peeters detailed a similar Z3-based method with circuit-to-equation conversion; another used Codex to automate Z3 solving; a third used KLayout's Python API for GDS parsing and Yosys for assertion checking. The open-source Degate tool was mentioned for real-world chip reverse engineering. Several commenters noted the author's "NIH syndrome" in building custom tools instead of using existing EDA software. Questions arose about whether a "three stars" solution exists, whether spoilers were published prematurely, and a typo in the solution image link was corrected. The author's writing style was praised for capturing the authentic experience of deep technical problem-solving.
HN discussion
(206 points, 244 comments)
IBM has launched "IBM Bob," an AI-powered development partner positioned as an agentic AI tool for enterprise software development. The platform features autonomous agents that can work in parallel on codebases, "Literate Coding" for natural language-to-code generation, a command-line interface (Bob Shell), and analytics dashboard (Bobalytics). It targets enterprise modernization with premium packages for Java upgrades, IBM i/mainframe development (RPG/COBOL), and compliance workflows (HIPAA, FedRAMP). IBM Bob integrates with Red Hat and Instana, and operates with guardrails requiring user approval before code changes. The marketing page includes testimonials from various organizations claiming 90% faster Java modernization (3 days vs 30+), strong RPG/COBOL understanding, and rapid prototyping capabilities.
Hacker News reaction is overwhelmingly skeptical and mocking. The dominant theme is the unfortunate naming collision with "Microsoft Bob" (1995's infamous failed UI), with multiple commenters predicting similar failure. Users question the product's actual nature—whether it's a model, a VS Code fork, or an agent harness—and note the "late 2024 energy" of the offering. The term "Bobalytics" drew particular ridicule. One commenter noted the $20/month pricing for specialized skills like Java modernization. Several former IBM acquisition employees reported negative experiences ("absolutely dreadful," "Bobcoins"). The consensus views this as IBM chasing the AI coding trend without clear differentiation from established players like OpenAI or Anthropic.
HN discussion
(205 points, 66 comments)
The project is an open-source e-ink bike computer built around a 4.7" sunlight-readable e-paper panel. It integrates GPS, capacitive touch, a front light, a 1,500 mAh battery, USB-C, and Bluetooth 5 for heart-rate, power, and cadence sensors on a single board. An SD card slot stores offline maps, routes, ride files, and logs, and firmware can be flashed from a desktop Chromium browser over USB. Key tradeoffs include the lack of a barometric altimeter (climbing data is estimated from map tiles), a basic single-band GPS receiver that struggles under tree cover, no magnetometer for compass heading while stationary, approximately 7–8 hours of battery life with the light off, weak hardware buttons that make gloved or wet use difficult, and no waterproofing or IP rating — the bare board requires a separate case for wet conditions.
Commenters praised the technical achievement, particularly the implementation of ANT+ sensor support over a BLE radio, and several noted the clean e-ink UI and interactive website walkthrough. Durability and weather resistance were common concerns: multiple users questioned real-world viability in rain or vibration-heavy environments, citing e-ink fragility and the absence of waterproofing. Others debated e-ink’s suitability for bike computers versus modern transflective LCD units (e.g., Garmin), arguing that current devices already offer 30+ hour battery life, good sunlight readability, and color maps, while e-ink suffers from slow refresh rates, poor dark visibility, and lack of color. Several developers shared parallel projects — phone-based apps, e-reader repurposing, and custom hardware — and expressed interest in self-hosted fitness data pipelines. A few requested video demos and details on mounting solutions.
HN discussion
(199 points, 72 comments)
Mullvad is discontinuing its public encrypted DNS (DoH) service, which it has operated since 2022, and will instead financially support the Quad9 Foundation. The company states that its DoH servers are unnecessary for Mullvad VPN users because traffic is already encrypted and handled by internal DNS. For non-VPN users, the service provided default DNS for Mullvad Browser and a free public option to protect DNS queries from ISPs. Mullvad argues that running a privacy-focused public DNS is a highly specialized undertaking and that Quad9 is the undisputed leader, so resources are better spent supporting Quad9 rather than duplicating efforts. Existing users must migrate to Quad9 by November 2, 2026; Mullvad Browser defaults will automatically switch, while custom configurations and iOS/macOS profiles require manual updates.
The Hacker News discussion reveals mixed reactions. Some users praise the move as pragmatic, trusting Quad9's expertise and jurisdiction alignment. Others express disappointment, noting that consolidating on well-known providers like Quad9 increases vulnerability to national blocking, and that lesser-known alternatives help circumvent censorship. Commenters also question Quad9's lack of ad-blocking, highlight Mullvad DoH's superior performance for pipelined queries, and speculate about Mullvad's broader service reductions. Security concerns arise about centralized privacy services being targets for intelligence agencies, with some advocating for self-hosted recursive resolvers like Unbound combined with blocklists and VPN/Tor tunneling. One commenter disputes the "highly specialized" claim, describing a simple Unbound setup. A broader theme favors decentralized, mirror-like DNS infrastructure, potentially enabled by QUIC, to resist censorship and single points of failure. A few users lament the loss of a service they trusted more than alternatives.
HN discussion
(112 points, 69 comments)
OpenAI's demo of GPT-6 Astra designing a PCB in KiCad prompted the atopile team to detail EEBench, their benchmark for evaluating AI circuit design capability. EEBench uses declarative code (atopile) rather than GUI automation, letting models work directly with components, constraints, and SPICE simulations. Tasks include real-world engineering trade-offs: a residential energy meter holdup circuit requiring capacitor selection under voltage derating, tolerance corners, cost, and size constraints; and analog filter synthesis with worst-case component tolerances. Grading is deterministic—designs are built, simulated across corners, and measured against electrical specs and BOM cost. The September 2025 leaderboard shows Claude Opus 5 at 61.6%, Grok 4.6 at 57.1%, and OpenAI's GPT-5.5 at 42.3%. xAI included EEBench in Grok 4.6's model card under "engineering acceleration." The same simulation harness provides RL reward signals for post-training. EEBench V1 covers analog and digital design through simulation but not layout, manufacturing, or bring-up. The authors conclude AI can already design a useful and growing set of circuits, though not yet safety-critical ones like pacemakers.
Commenters report mixed practical experiences: AI excels at library management, footprint verification, BOM review, and schematic review—often catching human errors—but struggles with full schematic generation and especially PCB layout, which multiple users describe as "terrible" or "spectacular fail." Success requires feeding datasheets and errata; analog/RF designs still collapse under complexity. Several users report fabricated working boards from AI-assisted workflows using tools like tscircuit, atopile, and KiCad MCP servers. Key remaining gaps cited include component sourcing/substitution from distributors, extracting simulation models from datasheets, and autorouting. One commenter notes the benchmark approach mirrors evolutionary FPGA design that exploited physical quirks. Others question why such rigorous evals don't exist for human engineers. The consensus: AI is a powerful co-pilot for discrete tasks today, but end-to-end board design remains unreliable without human oversight.
HN discussion
(52 points, 129 comments)
The article argues that "next-token predictor" is an incomplete mental model for modern LLMs because it describes only the autoregressive emission mechanism while ignoring how post-training fundamentally changes what the model learns from. During pre-training, models learn solely by making actual next tokens from existing training sequences more likely. However, reinforcement learning with verifiable rewards (RLVR) introduces a second training loop where the model explores new sequences and makes explored tokens more likely based on the rewards those sequences earn. This means post-trained LLMs learn from outcomes of their own generated sequences—sequences never seen in the training data—rather than merely imitating statistical patterns from a fixed corpus. The chess analogy illustrates the distinction: a system trained only on grandmaster games predicts likely moves, while a system that explores all possible games chooses moves that maximize winning probability. Additional post-training methods like RLHF further shift behavior toward simulating a helpful assistant. The core claim is that the same next-token loop can encode either imitation of existing text or discovered knowledge and goal-directed behavior, making the "predictor" label misleading.
Commenters largely fall into three camps. Several agree the label is reductive: danielmarkbruce argues "predictor" is the wrong word post-RLHF/RLVR because the model searches for high-reward token sequences rather than predicting from a distribution; DonHopkins compares it to calling a GPS a "next-turn predictor," ignoring the map, route, and destination; atleastoptimal notes the phrase is often used to downplay emergent capabilities. Others defend the model's utility: Systemerror7A69 and chrisjj maintain that token-by-token generation still fits "next-token predictor," just with a different optimization target; bluegatty calls it the best available mental model despite limitations. A third group offers technical refinements: imenani points out pretraining optimizes intermediate representations for all future tokens, not just the immediate next one; xg15 highlights non-determinism from initialization and training dynamics; polotics suggests "next-embedding" or "next-meaning" predictor better captures layer-wise computation. Dlemlo frames next-token prediction of "everything" as a fitness function that compresses world knowledge into intelligence, while jvanderbot emphasizes agentic frameworks and tool use create emergent systems beyond the base predictor.
HN discussion
(120 points, 38 comments)
Statichost.eu is a static site hosting platform built entirely on European infrastructure by a European company (based in Stockholm), explicitly avoiding US cloud providers like AWS and Cloudflare. It offers standard modern static hosting features: git-based deployments compatible with any static site generator, webhook-triggered rebuilds, custom domains with free SSL certificates, preview links for branches/PRs, instant rollbacks, and a worldwide CDN (currently in private beta) designed for GDPR compliance. The service emphasizes "European values" and data sovereignty, with a free tier and paid plans starting at €9/month. Founder Eric Selin positions it as an alternative to "European" hosting that secretly runs on American clouds.
Commenters raised several practical concerns: pricing is viewed as high compared to EU VPS options (e.g., Scaleway at €5/month with unlimited bandwidth) and OVH's free static hosting included with domains; the git-only deployment workflow lacks SFTP/rsync support; and documentation gaps exist around TLS certificate automation and storage limits. Technical critiques noted missing public key authentication and questioned the relevance of "build minutes" for static sites. The "European values" claim drew scrutiny over geographic ambiguity (non-EU European countries). Design feedback called the site's mobile layout and spacing inconsistent and "cheap." Positive notes included a real-world user successfully hosting a low-traffic site on the free tier, and appreciation for more EU-hosted alternatives.
Generated with hn-summaries