OpenCode – Open source AI coding agent
Summary
OpenCode is an open‑source AI coding agent that has attracted a substantial community on GitHub, accumulating more than 120 000 stars, around 800 contributors, and over 10 000 commits. The project is actively maintained and sees widespread adoption, with over 5 million developers reporting monthly use. Its popularity reflects broad trust in the tool’s capabilities for automating or assisting software development tasks, supported by a large, collaborative contributor base and a significant volume of ongoing code contributions.
Read full article →
Community Discussion
Comments reveal a divided view of OpenCode. Users appreciate its open‑source flexibility, model‑agnostic subagents, web UI, remote deployment options, and ability to integrate local or inexpensive models, often citing productivity gains and valuable features like MCP support. However, many express frustration with rapid, under‑tested releases, frequent bugs, high resource usage, unstable TUI behavior, limited offline or telemetry controls, and perceived poor maintainership. Comparisons to Claude Code, Copilot, and Aider highlight both strengths—customizability and cost‑effectiveness—and weaknesses—stability and usability inconsistencies. Overall sentiment is mixed, balancing strong enthusiasm for its potential against notable reliability and governance concerns.
We rewrote our Rust WASM parser in TypeScript and it got faster
Summary
The openui‑lang parser was originally written in Rust, compiled to WebAssembly, and called from JavaScript. Each call incurred a fixed overhead: copying the input string into WASM memory, parsing in Rust, serialising the result with `serde_json::to_string`, copying the JSON back, and deserialising it with `JSON.parse`. This boundary cost dominated latency, not the Rust parsing itself. Replacing JSON with `serde‑wasm‑bindgen` (direct `JsValue` return) was ~30 % slower because constructing a JS object requires many fine‑grained conversions across the runtime boundary.
The team rewrote the six‑stage pipeline (autocloser, lexer, splitter, parser, resolver, mapper) in TypeScript, eliminating the WASM boundary. Single‑call benchmarks showed 2.2–4.6 × faster parses and 2.6–3.3 × lower total streaming cost. Further gains came from an incremental streaming parser that caches completed statement ASTs, reducing cumulative work from O(N²) to O(N).
Key takeaways: WASM excels for compute‑heavy, low‑interop tasks (e.g., image/video processing, cryptography). For frequent small‑input parsing where data must cross the boundary, JS implementations with algorithmic improvements are more efficient. Profiling actual bottlenecks before choosing a language is essential.
Read full article →
Community Discussion
The comments converge on the view that observed speedups when moving code between languages are usually attributable to redesign, bug fixes, or more efficient data handling rather than the language itself. Several contributors highlight the cost of JSON marshaling across the WASM‑JS boundary and suggest shared buffers or binary formats as mitigations, while also noting algorithmic improvements as the primary performance factor. Skepticism is expressed toward the AI‑generated article and its benchmarks, with calls for clearer explanations, verification, and awareness of security implications.
Ghostling
Summary
Ghostling is a minimal terminal emulator demo built on the libghostty C API, implemented in a single C file and using Raylib for windowing and 2D rendering. It showcases libghostty‑vt, a zero‑dependency library that parses VT sequences, manages terminal state (cursor, styles, reflow, scrollback), and provides renderer state without any drawing code; the host supplies rendering. Features inherited from Ghostty include resize with text reflow, 24‑bit and 256‑color support, bold/italic/inverse styles, Unicode grapheme handling, keyboard input with modifiers, Kitty keyboard protocol, mouse tracking/reporting (X10, normal, button, any‑event, SGR, URxvt, UTF8), scroll‑wheel handling, draggable scrollbar, and focus reporting. Planned exposures are Kitty Graphics Protocol, OSC clipboard, and OSC title. libghostty does not provide GUI elements such as tabs, splits, session management, or configuration UI; these must be implemented by consumers. Build requires CMake ≥ 3.19, a C compiler, and Zig 0.15; Raylib is fetched via CMake. Debug builds are slow; release builds use `-DCMAKE_BUILD_TYPE=Release`. libghostty‑vt’s C API is language‑agnostic, allowing bindings for Rust or other languages, and it is renderer‑agnostic, supporting alternatives to Raylib, including WASM.
Read full article →
Community Discussion
The comments express overall enthusiasm for libghostty and its ability to package TUIs as desktop applications, noting its ease of use, cross‑platform functionality and effective resource‑embedding approach. Users appreciate the small, readable C source and view the autogenerated font header as an innovative solution. While some rely on existing window managers and terminal multiplexers and do not need advanced features, there is interest in trying Ghostty, especially with planned OSC support, and a desire for a simpler plugin system.
France's aircraft carrier located in real time by Le Monde through fitness app
Community Discussion
Comments converge on the view that consumer fitness apps increasingly jeopardize military operational security by broadcasting precise locations of personnel and vessels, a problem seen as longstanding yet intensified by ubiquitous mobile connectivity. Observers note that satellite surveillance already reveals ship movements, but the exposure of individual identities raises additional risks such as targeting or coercion. Consensus calls for stronger OPSEC training, device restrictions, and purpose‑built secure operating systems or app whitelists, while critiquing current policies and highlighting the need for systemic safeguards.
Linux Applications Programming by Example: The Fundamental APIs (2nd Edition)
Summary
The GitHub repository “arnoldrobbins/LinuxByExample-2e” contains the source code accompanying *Linux Application Development By Example – The Fundamental APIs* by Arnold Robbins. The work is copyrighted 2004‑2026 by Pearson Education (ISBN‑13 978‑0‑13‑532552‑0; ISBN‑10 0‑13‑532552‑8). The repository’s **Documents** folder stores reference material, including the author’s code license and an **errata.txt** file that is updated with any discovered errors. Subfolders correspond to each chapter and hold the example programs discussed in the book. Users can report book issues via GitHub issues, and the repository’s latest commit was on 10 Oct 2025 17:07 IDT. An image with alt text “@arnoldrobbins” is also present.
Read full article →
Community Discussion
The discussion presents an informative overview of an older, high‑level UNIX system‑programming text that uses OCaml, noting its low‑level, imperative style and the way OCaml’s runtime and exception handling simplify error management compared with C. The tone is neutral and factual, emphasizing the material’s educational value while also acknowledging that its simplicity may be misleading. The comment concludes by asking whether a formal book version of the content is available.
A Japanese glossary of chopsticks faux pas
Summary
The article lists Japanese chop‑stick etiquette violations (kiraibashi) in alphabetical order, describing each prohibited action. Highlights include: Agebashi – raising chopsticks above the mouth; Araibashi – cleaning them in soup or drinks; Awasebashi (or hashiwatashi) – passing food between chopsticks, a serious taboo linked to funeral rites; Ukebashi – holding out a bowl while still gripping chopsticks; Utsuribashi – repeatedly using the same side‑dish chopsticks without alternating with rice; Urabashi – picking up food then returning it; Ogamibashi – holding chopsticks with both hands while saying *itadakimasu*; Oshikomibashi – pushing food deep into the mouth; Kaeshibashi – reversing chopsticks when serving to avoid contaminating food; Tatebashi – standing chopsticks upright in rice, a grave funeral symbol; Chigaibashi – using mismatched‑material chopsticks; Hashibashi – laying chopsticks across a dish as a “finished” signal (instead of a rest). Additional entries detail actions such as dropping, licking, stabbing, pointing, stirring, tapping, shaking, or using chopsticks as a toothpick, each considered impolite or taboo in Japanese dining culture.
Read full article →
Community Discussion
Comments show a mixture of curiosity and amusement about the extensive list of chop‑stick “taboos,” with many contributors noting that most rules are minor, health‑oriented conventions rather than strict prohibitions. Several observers describe these practices as evolving or already lax, especially in casual settings, and stress that foreigners need only avoid obvious disrespectful actions. While a few defend certain etiquette points as genuinely rude, the dominant view is that the majority are overemphasized, culturally specific details that rarely affect everyday dining.
Lent and Lisp
Summary
The author expands a previous post on coinciding religious dates by adding Ash Wednesday and Chinese New Year, using calendar algorithms from Reingold & Dershowitz’s *Calendrical Calculations*. The original Common Lisp source (calendar.l) fails to load in SBCL/CLISP due to package/export declarations; removing the duplicated `(in-package "CC4")` and export list allows the file to load as `calendar.lisp`. A CLISP script (`ramadan‑lent`) loads this library, defines weekday and month name vectors, a `gregorian-date-string` formatter, and iterates 500 Islamic years (±250 years from the current year). For each year it computes Ramadan 1 (fixed‑date) and the corresponding Ash Wednesday (`easter(gyear) - 46`). When the dates match it prints the Gregorian date. Output shows nine matches between 1799 and 2253, with typical intervals of 98 years and occasional 31‑ or 67‑year gaps. A second script adds a check for Chinese New Year using `chinese-new-year-on-or-before`; matches occur in 1799, 2026, 2124, and 2222, confirming a triple coincidence after a 227‑year gap and predicting the next after 98 years. The author plans further exploration of the calendrical library.
Read full article →
Community Discussion
The discussion proposes replacing the calendar.l header with a package definition that explicitly lists a large number of exported symbols, using a defpackage form followed by an in-package declaration. It notes that symbols can be referenced as symbols, uninterned symbols, or strings, with string‑designators offering advantages when many symbols are involved. The comment also clarifies that “package” in Common Lisp already denotes a namespace, making the phrase “packages and namespaces” redundant, and suggests the underlying issue likely relates to package handling.
Attention Residuals
Summary
Attention Residuals (AttnRes) replace standard Transformer residuals with depth‑wise softmax attention, allowing each layer l to compute its hidden state as hₗ = ∑ᵢ₌₀^{l‑1} α_{i→l} vᵢ, where α are derived from a learned pseudo‑query wₗ ∈ ℝᵈ. This mitigates PreNorm dilution, keeping output magnitudes bounded and distributing gradient norms more uniformly across layers.
- **Full AttnRes**: attends over all previous layer outputs; memory cost O(L d).
- **Block AttnRes**: partitions L layers into N blocks, uses standard residuals within blocks and inter‑block attention over block representations, reducing memory to O(N d). With ≈8 blocks it recovers most Full AttnRes gains with marginal overhead.
Empirical results (Kimi Linear 48B/3B, 1.4 T tokens) show consistent loss reductions; Block AttnRes matches a baseline trained with 1.25× more compute. Downstream gains include +7.5 points on GPQA‑Diamond (multi‑step reasoning) and +3.1 on HumanEval (code generation). The method is a drop‑in replacement for residual connections, requiring only a pseudo‑query projection and RMSNorm per layer.
Read full article →
Community Discussion
The comments express strong enthusiasm for the new Attention Residuals technique, highlighting its impressive computational savings—around a 20 % reduction in training cost—and its dramatically lower inference bandwidth, which could enable better performance on consumer hardware. Reviewers note the method’s similarity to LSTM input gates and appreciate its claim as a drop‑in replacement that retains most benefits of full attention residuals while using far less memory. Overall, the community views the approach as a notable and promising advancement.
Molly Guard
Summary
The term “molly guard” originates from early computing hardware and refers to a small plastic safety cover that must be removed before operating a significant button, preventing accidental activation. The name allegedly derives from an incident where an engineer’s daughter, Molly, pressed a critical red button twice during a datacenter visit. Physical examples appear in aircraft combat movies, recessed buttons, protective ridges around keys, and even SIM‑card ejection holes. Software analogues include confirmation dialogs and required modifier keys (e.g., Ctrl+Alt+Del) that act as guards. A contrasting concept, “reverse molly guards,” describes buttons that activate automatically after a period of inactivity, viewed as considerate design. The author notes the frustration for programmers when a system remains idle overnight, awaiting a non‑essential response.
Read full article →
The Ugliest Airplane: An Appreciation
Summary
The TransAvia AirTruk originated from Luigi Pellarini’s unconventional agricultural designs. In the mid‑1950s New Zealand needed a low‑cost top‑dressing aircraft, prompting the PL‑7 (a steel‑tank biplane with twin tail booms, tricycle gear, and a 400 hp Armstrong Siddeley Cheetah radial). After a 1958 hangar fire, Pellarini redesigned it as the PL‑11 (monoplane, 600 hp Pratt & Whitney radial, cockpit atop the tank, twin booms) using parts from surplus North American Harvards; first flight occurred in 1960 but bureaucratic delays halted production. The subsequent PL‑12, renamed “AirTruk,” was a sesquiplane with a 285 hp Continental flat‑six, retaining the twin‑boom layout and allowing a small cabin for crew. Formed in 1965, TransAvia produced 120 AirTruks (1967‑1988), employed for fertilizer spreading, occasional air‑ambulance or forward‑air‑control proposals, and a brief appearance in *Mad Max Beyond Thunderdome*. Competition from U.S. models and lack of government support ended production. Today only a few examples remain operational, chiefly as airshow aircraft and hobby flyers in Australia and the United States.
Read full article →
Community Discussion
The discussion conveys a generally positive impression of the Australian‑manufactured aircraft, noting its visual similarity to a familiar “road warrior” flyer and describing its appearance as appealing and endearing. Commenters associate the plane with cultural references to Australian aviation and emphasize its cute aesthetic, indicating a favorable, light‑hearted reception without raising criticisms or technical concerns. The overall tone remains appreciative and nostalgic.