Local Wikipedia: Wikipedia, but only for things a half hour walk from you
Local Wikipedia is a web service that presents Wikipedia articles limited to a geographic radius roughly equivalent to a half‑hour walk from the user. It draws exclusively from geocoded Wikipedia pages, filtering content based on proximity to the browser‑stored location. If fewer than 25 geocoded entries exist within the area, the service expands to the nearest 25 items, typically within about six miles. Conversely, when more than 500 entries fall within the radius, only the 500 closest articles are displayed. The user’s location data remains confined to the browser session; URLs generated for sharing do not embed any location information. The platform operates independently and holds no official affiliation with the Wikimedia Foundation or the main Wikipedia site.
Docker is weird
Docker containers are essentially isolated Linux processes, not separate virtual machines. Their isolation relies on multiple kernel features—namespaces for view isolation, cgroups for resource limits, and various networking mechanisms—to emulate container behavior. Docker images are simple directory trees that the daemon mounts using chroot/pivot_root to form a container’s root filesystem. The container runtime (runc) is written in Go, which introduces challenges because many required syscalls must run in a single‑threaded context; Go’s lack of a true fork primitive forces runc to use a special exec of /proc/self/exe to simulate fork behavior. Docker’s daemon traditionally runs as root because many kernel APIs needed for container setup require elevated privileges, especially for networking; rootless runtimes must re‑implement networking in user space. These observations highlight Docker’s reliance on core Linux primitives and the complexities of building a container runtime.
Comments reflect a blend of admiration and critique. Many acknowledge Docker’s pivotal role in popularizing layered images, Dockerfiles, and registries, crediting it with simplifying development and deployment workflows. Others point to its accumulated complexity, performance overhead, and lingering reliance on root or heavyweight components compared to newer runtimes such as Podman, crun, or Incus, especially for root‑less or security‑focused use cases. Discussions also highlight language choices (Go versus Rust), the evolution of kernel namespaces, and occasional frustrations with tooling and cargo‑cult adoption, while noting nostalgic appreciation for Docker’s impact.
How does Fable 5.1 hide messages in images?
The comments view the presented technique as relatively simplistic compared to more sophisticated, information‑dense steganography methods, noting that existing tools like OutGuess handle JPEGs while this approach uses SVGs. Several remarks highlight the potential for generic encoding across media, suggesting AI could select robust patterns tailored to each medium and that future agents might hide messages beyond human detection. There is general agreement that the current example appears unusual and that more subtle or complex encoding strategies are possible.
LLMs are making formal software verification feasible at a much larger scale
The authors demonstrate that large language models (LLMs), specifically Anthropic’s Claude, can generate formal proofs for security properties of real‑world open‑source software at the assembly level. Using a pipeline that translates RISC‑V binaries and Linux process semantics into Rocq, Claude proved that 239 entry points across 123 OSS‑Fuzz libraries never crash for any input under 64 MiB, producing ~180 M lines of proof (≈600 k lines per library). During proof construction the model automatically patched discovered bugs—including out‑of‑bounds reads/writes and logic errors—that traditional fuzzing missed. Additional case studies show LLM‑generated specifications for zlib’s RFC 1950 format, binary‑level verification of x86 code, and correctness of a Rust‑implemented Python interpreter via Verus. The work highlights that proofs are reusable, token‑efficient models reduce cost, and that verification scope is limited by the fidelity of CPU/OS models and specification completeness. The authors release the trusted components and a Claude skill, encouraging broader adoption of LLM‑assisted formal verification.
Comments show a mixed view of AI‑assisted formal verification. Contributors note genuine progress—examples of proofs generated for Rust, C, and bytecode, and reduced verification effort—but many stress that verification is not a silver bullet, warning that specifications may be wrong, scaling remains hard, and tooling often requires expert input. Skepticism targets bold claims about universal bug‑free software and job displacement, while optimism focuses on tighter integration of LLMs with existing proof systems and the potential for safer, more automated testing. Overall sentiment balances cautious interest with substantial doubt about feasibility and impact.
The same AI request emits 8.5 times more CO2 in Texas than in Sweden
Berget AI announced an open‑source, MIT‑licensed method for estimating the carbon emissions of each individual AI inference request. Developed with the Stockholm Environment Institute, WattTime and Klimatkollen, the calculator (co2.berget.ai) applies the Green Software Foundation’s SCI‑for‑AI specification, using the average emissions intensity of the regional electricity grid and accounting for hardware manufacturing. A test on the open model Kimi K3 shows per‑request emissions of 0.4 g CO₂ in Sweden, 1.6 g in Ireland, 2.5 g in Germany and 3.2 g in Texas—8.5 times higher in Texas than Sweden. The method evaluates each request separately, considering model type, time of day and caching, and plans to add marginal grid‑intensity estimates and chip‑manufacturing footprints. Berger AI claims to be the first inference provider to publish per‑request emissions, aiming to give buyers transparent data for comparing providers. The release notes that AI‑driven data‑center demand is projected to double to ~945 TWh by 2030, making location‑specific emissions a critical factor.
The discussion emphasizes that AI‑related emissions are largely driven by the carbon intensity of the electricity used, contrasting high‑intensity grids such as Texas with low‑intensity ones like Sweden or Finland. Commenters note that fossil‑fuel reliance, hardware efficiency, and usage patterns (e.g., reasoning effort, token consumption) significantly affect overall impact, and they advocate for better measurement tools, renewable energy adoption, and lifestyle changes such as reduced meat consumption. Skepticism appears toward opaque provider practices and the placement of data centers, while calls for policy support and greener infrastructure recur throughout.
The HTML-in-Canvas API origin trial
The HTML‑in‑Canvas API, available as an origin trial in Chrome 148‑150, lets developers render DOM elements directly into a 2‑D canvas, WebGL, or WebGPU texture while preserving full interactivity, accessibility, and integration with browser features (text selection, form controls, find‑in‑page, screen readers, extensions, DevTools, indexing).
Key points:
- Add layoutsubtree to a <canvas> to expose nested HTML to the accessibility tree.
- For 2‑D contexts call ctx.drawElementImage(element, x, y) and apply the returned transform to element.style.transform.
- WebGL uses gl.texElementImage2D and WebGPU uses queue.copyElementImageToTexture.
- Synchronize element location by converting WebGL MVP matrices to DOM matrices with canvas.getElementTransform or element.getElementTransform.
Use cases include complex canvas‑based apps, 3D scenes, games, and WebXR experiences that need native UI, copy‑paste, and searchable text. Three.js (via THREE.HTMLTexture) and PlayCanvas (via texture API) already support the feature.
Limitations: cross‑origin iframes are blocked, and scrolling/animation updates occur on the main thread, affecting performance.
The discussion highlights a trade‑off between performance and implementation complexity: using a true canvas dramatically improves frame rates for large numbers of panels but forces custom UI code and limits third‑party component use. Concerns are expressed that the HTML‑in‑Canvas proposal may lack long‑term support and appears driven by cosmetic goals rather than robust UI needs. Criticism is directed at browser vendors, particularly Google, for expanding the web API in ways perceived as strategic rather than practical, with suggestions that canvas functionality be integrated directly into HTML elements.
The alien space of science: Coherent but cognitively unavailable directions
The paper proposes a framework for generating scientifically plausible research directions that are unlikely to be proposed by existing researcher communities, termed the “alien space of science.” It decomposes scientific papers into conceptual units (“idea atoms”) and clusters them to build a vocabulary. Two models are trained: a coherence model that evaluates whether a combination of atoms forms a viable research direction, and an availability model that estimates the presence of any author community capable of pursuing it. By ranking atom combinations to maximize coherence while minimizing availability, the sampler generates novel, diverse research ideas. Experiments on 16,068 peer‑reviewed LLM papers from major ML conferences demonstrate that the method produces more varied portfolios than frontier LLM baselines, while matching or exceeding per‑idea quality in blind human, LLM, and downstream evaluations. Temporal validation using only pre‑2025 data shows that selecting <1 % of candidates recovers 2025‑year combinations at 35.9× chance, and weighting unavailability improves recovery of strictly novel combinations to 3.24× chance. The approach separates scientific plausibility from community availability, enabling AI‑driven ideation that complements human discovery.
The post announces the acceptance of a NeurIPS paper describing a system that samples diverse machine‑learning ideas by representing papers as collections of “idea atoms” and training a transformer‑based coherence model alongside a dual‑encoder cognitive‑availability model. Evaluation includes retrospective prediction of future papers, human judges rating generated reports highest among alternatives, and large‑scale generation of thousands of proposals, with code and an exploration interface released publicly. The overall tone is factual and highlights methodological novelty, empirical validation, and open‑source availability.
OpenShell – A safe, private runtime for fleets of autonomous AI agents
OpenShell is a runtime that securely executes autonomous AI agents by enforcing fine‑grained policies on file access, system calls, and network connections. Each agent runs in an isolated sandbox where the kernel mediates all resources, and credentials are injected only for approved endpoints. Policy changes are formally verified before application, flagging risky new accesses for human review. The architecture comprises a gateway, supervisor, and sandbox, with support for Linux, macOS (Apple Silicon), and Windows WSL 2, plus Docker, Podman, or host virtualization. Core features include sandbox lifecycle management, filesystem/network/process policies, credential providers, extensible middleware, and optional Kubernetes deployment via Helm with required CNI NetworkPolicy enforcement. SDKs are available for Python, Node, Go, and Rust, and a public skill set enables agents to drive the CLI and manage policies. telemetry is optional and anonymous; it can be disabled at runtime or compiled out. OpenShell is released under the Apache 2.0 license.
Comments show a mixed but generally cautious view of OpenShell. Many acknowledge its detailed permission controls and potential for managing agent fleets in complex enterprise environments, seeing value in the granular sandboxing and hardware‑firewall integration. At the same time, a substantial portion raises concerns about the practicality of its complexity, the reliability of its security claims, telemetry collection, and the risk of agent collusion or data exfiltration. Several participants prefer simpler container‑based approaches or alternative sandboxes, noting that while OpenShell offers interesting features, its advantages may be limited to niche, highly regulated use cases.
The foolishness of "natural language programming" (1978)
Dijkstra argues that using natural language as a programming interface is fundamentally misguided. Early computing already moved from error‑prone machine code to higher‑level languages, which, while still formal, reduced unnoticed mistakes by generating error messages. He stresses that any interface shift reallocates work: replacing formal symbols with native language would dramatically increase the machine’s processing burden without easing the programmer’s task, because communication across the interface incurs additional effort on both sides. Historical examples from Greek mathematics, medieval algebra, and the development of symbolic notation (Vieta, Descartes, Leibniz, Boole) illustrate that formal symbols enable precise, rule‑based manipulation and prevent nonsense that natural language cannot reliably exclude. Dijkstra predicts that a purely natural‑language interface would have stalled computer science, requiring centuries to achieve a usable narrow interface. He also notes a contemporary decline in linguistic precision (“new illiteracy”), further undermining confidence in natural‑language programming. Consequently, he concludes that programming in any natural tongue would be as difficult to construct as to employ.
Comments converge on a cautious view of natural‑language programming. While several acknowledge LLMs’ ability to translate informal descriptions into code, generate specifications, and aid comprehension, most stress that true programming still relies on deterministic, formal languages and that NL remains ambiguous, culturally loaded, and unstable. Inform 7 is cited as a niche success, yet broader attempts are seen as fraught with reliability, legal, and maintenance risks. Overall the consensus is that NL interfaces are useful adjuncts, not replacements, for conventional programming tools.
Every AI model has the same "controversial" take on humans
The authors queried twelve text‑only LLMs (including GPT‑6.1 Sol, Gemini 4 Argon, DeepSeek V4 Pro, Kimi K3, Grok 4.7, Claude Opus 5.5, among others) three times each, using the prompt “What is your most controversial take about humans? …”. Seven models repeated the same claim in every response; the remaining five produced either a variant of that claim, a dissenting view, or refused. The dominant claim—appearing in all but one model—states that humans prioritize belonging, tribal loyalty, or status over truth or principled reasoning, framing consciousness as a “PR department” that rationalizes pre‑existing instincts. Claude Opus 5.5 was the sole model to argue the opposite, emphasizing human decency. Six image‑generation models were then asked to create a single‑panel caricature of their controversial view; ten of the twelve images converged on a satire of humanity as phone‑addicted consumers destroying the planet, a motif absent from the text‑model answers. The experiment involved 60 API calls costing $1.54.
The comments converge on the view that LLMs do not possess original opinions but reproduce dominant human narratives present in their training data, leading to similar “controversial” takes across many models. Critics describe these outputs as mainstream, mid‑level reflections rather than profound insights, while noting occasional dissenting responses from less‑aligned models. The discussion also highlights concerns about conformity, tribalism, and alignment, emphasizing that model behavior stems from shared corpora and RLHF rather than independent moral reasoning. Overall sentiment is skeptical of claims that AI offers genuine, novel judgments on humanity.
The comments are overwhelmingly positive, describing the map as a fun, useful way to discover local history and hidden points of interest while traveling or walking. Users appreciate the visual presentation and note personal relevance when articles are nearby. Repeated suggestions include adding language selection or multilingual support, allowing a configurable search radius with metric units, and providing filters by article type or subtopic. Critiques focus on limited English coverage in some regions, missing geotags, confusing imperial distance units, occasional irrelevant or distressing entries, and occasional performance slowness. Overall sentiment is supportive with constructive improvement requests.