HackerNews Digest

March 09, 2026

Agent Safehouse – macOS-native sandboxing for local agents

Agent Safehouse lists a collection of AI‑focused coding tools and agents, presented primarily through image alt texts. The referenced items include Claude Code, Codex, OpenCode, Amp, Gemini CLI, Aider, Goose, Auggie, Pi, Cursor Agent, Cline, Kilo Code, and Droid. No substantive narrative, technical specifications, or functional descriptions accompany the list; the surrounding text consists of unrelated commands and informal remarks. Consequently, the core content is a simple enumeration of these named agents, implying a curated set of tools for code generation, assistance, or automation, but providing no further detail on capabilities, architecture, or usage.
Read full article →
The comments are broadly supportive of a lightweight, bash‑only sandbox‑exec wrapper, valuing its simplicity, preset policies and lack of extra dependencies. Reviewers repeatedly call for clearer documentation, automated tests, and verifiable trustworthiness, noting that existing sandbox tools are under‑documented. Many emphasize that effective isolation must extend beyond filesystem limits to network, resource‑cost, and API controls, and that layered safeguards and supervisory oversight are essential to prevent destructive actions. Concerns also arise about sandbox‑exec’s deprecation, cross‑platform compatibility, and the need for more sophisticated, production‑grade sandboxing solutions.
Read all comments →

Microscopes can see video on a laserdisc

The page presents a collection of navigation links that outline the main informational and service sections of the YouTube platform. Listed items include “About,” “Press,” “Copyright,” “Contact us,” “Creators,” “Advertise,” “Developers,” “Terms,” “Privacy,” “Policy & Safety,” “How YouTube works,” “Test new features,” and “NFL Sunday Ticket.” These headings indicate categories for corporate information, user resources, developer tools, legal policies, feature testing, and a sports subscription service. The footer also contains the copyright notice “© 2026 Google LLC.” No additional content, descriptions, or functional details are provided beyond these labeled links and the copyright statement.
Read full article →
The discussion expresses strong approval of the Tech Tangents channel, highlighting its detailed engineering focus on early technology and the creator’s effort. Viewers appreciate the supplementary live‑stream material, such as comparisons of ink technologies, and find the analysis of disc formats informative, noting the analogue nature of laserdisc encoding versus digital media. Technical observations about CAV encoding, disc mechanics, and data representation are shared, while there is modest curiosity about visual demonstrations. Overall sentiment is positive and appreciative of the educational content.
Read all comments →

PCB devboard the size of a USB-C plug

AngstromIO is a 8.9 × 9 mm devboard built around an ATtiny1616 MCU (16 KB flash, low‑power, Arduino‑compatible). It provides USB‑C power (5 V) with a 3.3 V LDO, two RGB SK6805 LEDs, and breakout pins for SCL, SDA, PB2 (TX), PA3, +5 V, GND, and UPDI. A dual CH340E module supplies separate USB‑C ports for programming (Serial‑UPDI) and UART debugging; only the debugging port delivers 5 V to the board. Voltage selection between 3.3 V and 5 V is supported. A companion CH32V003 devboard, intended for experimentation, uses a 0.25 USD RISC‑V MCU (26 KB flash) with a breadboard‑friendly layout, USB‑C power (3.3 V LDO, 5 V‑tolerant PC6/PC5), and a 4 × 5 charlieplexed LED matrix. Programming requires a SWIO programmer (WCH LinkE). Both boards are PCB‑designed in EasyEDA Pro (2‑layer, 1 mm thick, purple soldermask) and panelized onto a single PCB. Arduino libraries are partly supported via SpenceKonde’s megaTinyCore adaptations; development is done with the Mounriver Studio IDE.
Read full article →
The comments express strong enthusiasm for the compact development board, highlighting its appealing design and thorough documentation. Users repeatedly note curiosity about the benefits of its reduced size compared to alternatives such as the ESP32‑C3 and question what functional advantages the smaller form factor offers. There is notable interest in seeing similar boards based on other microcontrollers, particularly STM32, and a suggestion to provide a male USB‑C connector. Overall, the feedback is positive, inquisitive about technical trade‑offs, and supportive of expanded variant options.
Read all comments →

We should revisit literate programming in the agent era

Literate programming intertwines code with explanatory prose so readers can understand a program as a narrative. Historically it has seen limited adoption because maintaining parallel code and text is labor‑intensive; Jupyter notebooks exemplify its use in data science, while Emacs Org Mode supports polyglot literate programming via org‑babel, requiring “tangling” of code from the document. The author notes that manual tangling can cause overwrites when edits occur directly in source files. With large language model (LLM) agents, the workflow can be automated: agents generate Org runbooks, execute code blocks, capture results, and keep prose synchronized, eliminating the need for separate extraction steps. Agents can be instructed (e.g., via an AGENTS.md file) to treat the Org file as the single source of truth, handling tangling, updating prose, and summarizing intent. This reduces the overhead of literate programming, enables export to multiple formats, and may improve code quality by keeping intent visible. Limitations remain in Org’s tight Emacs integration; the author suggests Markdown as an alternative despite its lack of metadata support. The key question is whether agents can make large, narrative‑style codebases practical.
Read full article →
The discussion acknowledges that natural‑language documentation is inherently ambiguous and can drift from code, yet many see value in clearer, well‑structured prose—especially when paired with LLMs that can help maintain sync and generate code. Opinions converge on favoring lightweight literate practices such as thorough docstrings, top‑level module explanations, and style guides, while full‑scale literate programming is viewed as excessive or fragile without better tooling. Overall, participants recognize that improved documentation aids both human readers and AI assistants, though tooling and maintenance remain key challenges.
Read all comments →

Ask HN: What Are You Working On? (March 2026)

None
Read full article →
The overall tone is upbeat and forward‑looking, with many creators highlighting recent development work across a range of indie tools, games, AI‑driven services, and infrastructure projects. Common themes include leveraging open‑source or community‑driven ecosystems, integrating large‑language‑model agents, addressing niche user needs, and experimenting with novel interfaces or automation. Several authors note early‑stage adoption, limited marketing reach, or ongoing performance refinements, while expressing confidence in the utility and progress of their respective solutions.
Read all comments →

Every single board computer I tested in 2025

The 2025 SBC roundup covered 15 boards from eight manufacturers, spanning SoCs from Rockchip, Broadcom, Qualcomm, MediaTek, Allwinner, StarFive, CIX and Texas Instruments, with prices from $42 to $590. * **Budget (< $50)** – Six boards: BeagleBone Green Eco (TI Sitara AM3358, 512 MB DDR3L, $42); VisionFive 2 Lite (StarFive JH7110S, 4 GB LPDDR4, $43); Arduino UNO Q (Qualcomm QRB2210, 2 GB LPDDR4X, $44); Orange Pi RV/RV2 (JH7110 and Ky X1, 4 GB LPDDR4/4X, $46‑$50); Radxa Cubie A7A (Allwinner A733, 6 GB LPDDR5, $45) – the Cubie A7A delivered the highest Geekbench scores in this tier (641 SC/1,545 MC). * **Mid‑range ($50‑$100)** – Notable boards: Radxa ROCK 4D (Rockchip RK3576, 8 GB LPDDR5, $60, 319 SC/1,332 MC); Radxa Dragon Q6A (Qualcomm QCS6490, 6 GB LPDDR5, $70, 1,180 SC/3,215 MC); ArmSoM CM5 (RK3576 compute module, $95); Banana Pi R4 (MediaTek MT7988A network‑oriented SoC, 8 GB LPDDR4, $99). * **High‑end (>$100)** – Highlights: Raspberry Pi 500+ ($200, 16 GB LPDDR4X, NVMe); ArmSoM AIM7 (RK3588, $239, Jetson‑Nano form factor); CIX P1 boards – Radxa Orion O6N ($199) and Orange Pi 6 Plus ($260) with 32 GB LPDDR5, achieving > 1,300 SC and > 7,000 MC; Radxa Fogwise Airbox Q900 ($590, Qualcomm IQ‑9075, 36 GB LPDDR5, AI‑edge focus). Key trends: CIX P1 emerged as the top‑performing SoC; Qualcomm entered the SBC market with competitive performance; RISC‑V boards improved but lag behind ARM; Rockchip RK3576 solidified its mid‑range role; RAM pricing volatility impacted board costs.
Read full article →
Comments focus on the need for clearer information about software support, especially main‑line Linux compatibility, security updates, and distro readiness for SBC and SoC platforms. There is a recurring request for more detailed benchmarking data, consistent model reporting, and summarized tables. Hardware concerns include the scarcity of USB‑C DisplayPort Alt‑mode on lower‑priced boards and the importance of hardware‑accelerated PPPoE performance versus CPU‑only solutions. Users also note preferences for router firmware options and emphasize the relevance of driver upstreaming and reliable boot device ordering.
Read all comments →

FrameBook

The “FrameBook” project retrofits a 2006 MacBook A1181 chassis with modern hardware. The builder sourced damaged black MacBooks and OEM chassis parts, stripped them to bare frames, and installed a Framework Laptop 13 mainboard (Intel Core i7‑1280P) together with a CSOT MND307DA1‑9 display panel, a USB‑C hub, Framework speaker kit, and an EZQuest 6‑in‑1 USB‑C hub for I/O. The original Apple keyboard/trackpad were wired to a custom‑soldered USB cable, and 3‑D‑printed standoffs (glued with Gorilla glue) replaced the original brass inserts to mount components. Custom I/O shields were 3‑D‑printed and glued to accommodate the hub ports; the right‑side DVD‑bay slot was reused for a USB‑C port. A small LED module was mounted behind the top case to recreate the glowing Apple logo. Power‑button and webcam connections were routed through a small USB breakout board. The build took roughly three months, teaching soldering, 3‑D modeling, and integration techniques; future revisions may replace USB hubs with custom PCBs and improve mounting methods.
Read full article →
The comments show strong enthusiasm for repurposing vintage laptop shells, especially MacBook cases, with many expressing admiration for the project’s creativity and desire to apply similar techniques to other models such as Jornada, ThinkPad, and Toughbook. Practical concerns arise around power delivery, heat management, structural reinforcement, and weight, while nostalgia for the original designs is evident. Praise is directed toward Framework’s modular components and its role in enabling such hacks, though a few remarks criticize the article’s writing style and the older aesthetic of the bezels. Overall sentiment is supportive and constructive.
Read all comments →

Linux Internals: How /proc/self/mem writes to unwritable memory (2021)

The article explains why writes to /proc/self/mem succeed on pages without write permission. User‑space code can open /proc/self/mem, seek to any virtual address, and write bytes; the kernel’s implementation bypasses normal MMU protection. When a write request arrives, the kernel’s mem_rw() calls access_remote_vm(), which uses get_user_pages_remote() with the FOLL_FORCE flag. This flag forces the page‑table walk to ignore the VM_WRITE flag, obtaining the backing physical frame even for read‑only mappings. The frame is then mapped into the kernel’s address space with kmap() (using PAGE_KERNEL RW permissions), and the data is copied via copy_to_user_page() (a simple memcpy). Because the kernel accesses the memory through its own writable mapping, the CPU’s Write‑Protect (CR0.WP) and SMAP settings are irrelevant. Thus, virtual‑address permissions apply only to accesses made through that address; the kernel can remap any physical page with arbitrary permissions, enabling the “punch‑through” semantics used by tools like the Julia JIT and rr debugger.
Read full article →
The discussion expands the view of CPU mechanisms that limit kernel memory access beyond the two commonly cited settings, noting memory‑protection keys, virtualization page‑table structures (NPT/EPT), and hardware enclaves such as SEV, SGX, and TDX range registers. It emphasizes that the kernel retains ultimate control of page tables and can bypass hardware translation when handling /proc/self/mem, using software emulation to override existing protection. The tone is informative and highlights the complexity and flexibility of kernel memory handling.
Read all comments →

Blacksky AppView

Blacksky’s fork of the AT Protocol reference implementation adds AppView performance optimizations, caching, and community‑specific features. The primary change replaces the upstream TypeScript firehose consumer with the Rust indexer **rsky‑wintermute**, which processes events in parallel queues (live, backfill, repo backfill, labels) and achieves >10 k records / s versus ~90 records / s, reducing a full backfill from years to 2‑4 weeks. Wintermute provides tooling for direct account indexing, PLC bulk import, label replay, blob repair, and queue management. Additional optimizations include: * PostgreSQL LATERAL JOIN rewrites for `getTimeline`/`getListFeed` to force per‑user index usage. * Redis cache (profiles 60 s, records 5 min, counts 30 s, post metadata 5 min) – currently disabled due to a protobuf timestamp serialization bug. * Server‑side enforcement of notification preferences, JWT verification with force‑refresh to bypass stale DID cache, and JSON sanitization that strips null bytes and control characters. * Community‑post support via a custom lexicon, separate table, and membership gating. The architecture links the firehose → wintermute → PostgreSQL 17 (optional OpenSearch) → dataplane (gRPC) → appview (HTTP), with optional Redis and a separate membership DB. Known operational issues (COPY JSON corruption, queue poisoning, TLS provider init, label negation ordering) and their fixes are documented. The repository is read‑only; upstream atproto should be used for canonical updates.
Read full article →
The discussion centers on the cost of operating a relay, countering claims of high expense with examples of monthly fees as low as $18 to $34. It highlights Blacksky’s goal of offering a platform tailored to the U.S. Black community while maintaining interoperability, framing user choice as socially driven rather than purely technical. Concerns about self‑imposed segregation are raised, alongside criticism that Bluesky’s decentralization is ineffective and a preference for ActivityPub as a superior protocol.
Read all comments →

Artificial-life: A simple (300 lines of code) reproduction of Computational Life

A 300‑line Python implementation reproduces the experiment from “Computational Life: How Well‑formed, Self‑replicating Programs Emerge from Simple Interaction.” The simulation creates a 240 × 135 cellular grid where each 8 × 8 block encodes a 64‑instruction Brainfuck‑like program. Programs are initialized randomly; each iteration randomly pairs neighboring programs, concatenates their instruction tapes, and executes the combined program for up to 2¹³ steps. During execution, instructions can loop and mutate the tapes, enabling programs to modify themselves and their neighbor’s code. After execution, the tape is split back into the original two programs. The system observes spontaneous emergence of self‑replicating programs that copy themselves onto adjacent tapes; these replicators proliferate across the grid. Over time a more efficient replicator evolves and eventually dominates the entire population. Visualizations map each instruction to a unique color, with black pixels representing raw data cells. The demo shows early emergence of a replicator followed by its replacement by a higher‑efficiency variant.
Read full article →
The discussion centers on fascination with the simulation’s emergence of dominant species and a desire to increase ecological complexity to prevent single‑species takeover, mirroring real‑world biodiversity. Commenters express appreciation for the code’s elegance and draw parallels to past genetic‑programming work and recent AI self‑replication studies, noting similar dynamics of efficient replicators outcompeting others. Several participants propose experimental extensions, such as alternative character encodings and varying no‑op frequencies, while questioning whether the current self‑replicating mechanisms represent a theoretical optimum. Overall, the tone is inquisitive and constructive.
Read all comments →