Last active
March 12, 2026 13:20
-
-
Save puf/b3df69776c3f7a506e278c62b03cf4fa to your computer and use it in GitHub Desktop.
Lobsters Digest Feed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <?xml version='1.0' encoding='utf-8'?> | |
| <rss version="2.0"> | |
| <channel> | |
| <item><title>Lowdown Manpage Support</title><link>https://kristaps.bsd.lv/lowdown/mdoc.html</link><description><p><strong>The Gist:</strong> The linked content introduces new manpage support in Lowdown 3.0.0, aiming to simplify the process of writing manpages for libraries or programs, especially for those put off by the complexity of traditional manpage languages. The author's involvement with the <code>mandoc</code> team suggests a high quality implementation.</p> | |
| <p><strong>The Lobsters Take:</strong> The discussion revolves around the value of making manpage creation easier and explores alternative tools and the nuances of manpage markup. User <a href="#c_nnbjmg">dzwdz</a>, the submitter, highlights the new Lowdown feature and the author's expertise. User <a href="#c_bcxwmh">acatton</a> suggests <code>scdoc</code> as an alternative. User <a href="#c_exlfpt">telemachus</a> expresses appreciation for initiatives that increase manpage availability, noting their accessibility over project READMEs, and mentions the now unmaintained <code>ronn</code> as a tool with a similar Markdown-based approach. User <a href="#c_f1b6k7">fanf</a> supports making manpages easier to write, praises the semantic clarity of <code>mdoc</code> over older `-man` macros, and hopes Lowdown, when used with <code>mandoc</code> linters, can help authors create consistent and correct manpages despite potential pitfalls of lightweight markup.</p></description><pubDate>Thu, 12 Mar 2026 04:31:01 -0500</pubDate><guid isPermaLink="false">https://lobste.rs/s/rz6gak</guid><comments>https://lobste.rs/s/rz6gak/lowdown_manpage_support</comments></item><item><title>Claude Code isn’t going to replace data engineers (yet)</title><link>https://rmoff.net/2026/03/11/claude-code-isnt-going-to-replace-data-engineers-yet/</link><description><p><strong>The Gist:</strong> The linked article, titled "Claude Code isn’t going to replace data engineers (yet)," discusses the current capabilities of AI, specifically Claude, in the context of data engineering and suggests that it is not yet capable of fully replacing human data engineers.</p> | |
| <p><strong>The Lobsters Take:</strong> No comments yet.</p></description><pubDate>Thu, 12 Mar 2026 04:25:16 -0500</pubDate><guid isPermaLink="false">https://lobste.rs/s/mcwe1g</guid><comments>https://lobste.rs/s/mcwe1g/claude_code_isn_t_going_replace_data</comments></item><item><title>Grief and the AI Split</title><link>https://blog.lmorchard.com/2026/03/11/grief-and-the-ai-split/</link><description><p><b>The Gist:</b> The full content of the linked article "Grief and the AI Split" from blog.lmorchard.com was not provided in the given HTML. Therefore, a summary of the article cannot be generated.</p> | |
| <p><b>The Lobsters Take:</b> There is only one comment on the post by <a href="/~carlana">carlana</a>, which simply states: "Deep blue…".</p></description><pubDate>Thu, 12 Mar 2026 00:17:51 -0500</pubDate><guid isPermaLink="false">https://lobste.rs/s/wssz9m</guid><comments>https://lobste.rs/s/wssz9m/grief_ai_split</comments></item><item> | |
| <title>Pike - Solving the "should we stop here or gamble on the next exit" problem</title> | |
| <link>https://tomjohnell.com/pike-solving-the-should-we-stop-here-or-gamble-on-the-next-exit-problem/</link> | |
| <comments>https://lobste.rs/s/anyib0/pike_solving_should_we_stop_here_gamble_on</comments> | |
| <pubDate>Wed, 11 Mar 2026 06:57:34 -0500</pubDate> | |
| <guid>https://lobste.rs/s/anyib0/pike_solving_should_we_stop_here_gamble_on</guid> | |
| <description>**The Gist:** The article, titled "Pike - Solving the "should we stop here or gamble on the next exit" problem," explores a decision-making scenario where individuals or systems must choose between a known, immediate option and the uncertain outcome of waiting for a potentially better alternative. The full content of the article is not available. | |
| **The Lobsters Take:** No comments yet.</description> | |
| </item> | |
| <item> | |
| <title>U+237C is Azimuth</title> | |
| <link>https://ionathan.ch/2026/02/16/angzarr.html</link> | |
| <comments>https://lobste.rs/s/e8lebp/u_237c_is_azimuth</comments> | |
| <pubDate>Tue, 10 Mar 2026 22:07:37 -0500</pubDate> | |
| <guid>https://lobste.rs/s/e8lebp/u_237c_is_azimuth</guid> | |
| <description>- **The Gist:** The article "U+237C ⍼ is Azimuth" by Jonathan Chan discusses the Unicode character U+237C, also known as the "right angle with downward zigzag arrow," and its connection to the concept of azimuth. The author explores its typography, historical context, and potential meanings, particularly within the Unicode and linguistic communities. | |
| - **The Lobsters Take:** The Lobsters post has 4 comments. The snippet provided only contains the header for the comments section but not the actual comments themselves, preventing a summary of the discussion.</description> | |
| </item> | |
| <item> | |
| <title>Why I Still Blog — and Why the Future of Blogging Is Connected</title> | |
| <link>https://www.ssp.sh/blog/why-i-still-blog/</link> | |
| <comments>https://lobste.rs/s/wrpqt6/why_i_still_blog_why_future_blogging_is</comments> | |
| <pubDate>Wed, 11 Mar 2026 10:01:23 -0500</pubDate> | |
| <guid>https://lobste.rs/s/wrpqt6/why_i_still_blog_why_future_blogging_is</guid> | |
| <description>**The Gist:** The article "Why I Still Blog — and Why the Future of Blogging Is Connected" by Simon Späti explores the author's decade of blogging experience, detailing his writing process and how connected note-taking with a second brain approach (specifically using Obsidian) enhances it. The piece advocates for the future of personal blogging, emphasizing its value and the importance of building toward it. | |
| **The Lobsters Take:** No comments yet.</description> | |
| </item> | |
| <item> | |
| <title>Using Unicode Half-Stars Symbols in Ratings</title> | |
| <link>https://hyperborea.org/tech-tips/half-stars/</link> | |
| <comments>https://lobste.rs/s/ndtuji/using_unicode_half_stars_symbols_ratings</comments> | |
| <pubDate>Wed, 11 Mar 2026 12:20:13 -0500</pubDate> | |
| <guid>https://lobste.rs/s/ndtuji/using_unicode_half_stars_symbols_ratings</guid> | |
| <description>**The Gist:** The article "Using Unicode Half-Stars Symbols in Ratings" on Hyperborea Tech Tips discusses the use of Unicode star symbols for ratings on websites. The author, Kelson Vibber, notes that while full and outlined stars (☆★) have long been supported in Unicode, half-star symbols have only been available since Unicode 11 (2018) and still have inconsistent font support. To address this, the article suggests embedding a font that supports these half-star symbols directly on a website, thereby allowing for granular ratings like four and a half stars without relying on images or scripts. The author's motivation stems from a desire to maintain small page sizes and avoid loading extra scripts or images. | |
| **The Lobsters Take:** No comments yet.</description> | |
| </item> | |
| <item> | |
| <title>OpenBSD ext4fs update</title> | |
| <link>https://www.kmx.io/blog/openbsd-ext4fs-update</link> | |
| <comments>https://lobste.rs/s/ggify2/openbsd_ext4fs_update</comments> | |
| <pubDate>Wed, 11 Mar 2026 11:05:49 -0500</pubDate> | |
| <guid>https://lobste.rs/s/ggify2/openbsd_ext4fs_update</guid> | |
| <description>- **The Gist:** The article details the progress on an `ext4fs` driver for OpenBSD. Initially, the developer successfully implemented block descriptor groups, allowing the mounting of `ext4fs` partitions and basic directory listing, despite encountering kernel panics. A significant update on 2026-03-11 reports read-only support at 200MB/s and read/write support at nearly 500KB/s from a USB3 key formatted with `ext4` on Linux. The project utilizes `e2fsprogs` on OpenBSD, which is compatible with Linux userland and the new driver's on-disk format. Notably, the driver was developed using "pure AI (ChatGPT and Claude-code)" combined with manual code reviews and rigorous testing. | |
| - **The Lobsters Take:** The actual comments content was not provided in the snippet, though the metadata indicates "2 comments".</description> | |
| </item> | |
| <item> | |
| <title>On The Need For Understanding</title> | |
| <link>https://blog.information-superhighway.net/on-the-need-for-understanding</link> | |
| <comments>https://lobste.rs/s/wxk0ka/on_need_for_understanding</comments> | |
| <pubDate>Wed, 11 Mar 2026 16:25:23 -0500</pubDate> | |
| <guid>https://lobste.rs/s/wxk0ka/on_need_for_understanding</guid> | |
| <description>**The Gist:** The article "On The Need For Understanding" reflects on the importance of genuine understanding, especially in the era of "coding agents." It references a Mastodon post by Andy Wingo and thoughts from Gerald Sussman, suggesting a discussion around the depth of comprehension versus automated or superficial approaches. | |
| **The Lobsters Take:** The Lobsters page indicates there is "1 comment" on the story. However, the content of this comment is not available in the provided snippet.</description> | |
| </item> | |
| <item> | |
| <title>Temporal: The 9-Year Journey to Fix Time in JavaScript</title> | |
| <link>https://bloomberg.github.io/js-blog/post/temporal/</link> | |
| <comments>https://lobste.rs/s/ei0ans/temporal_9_year_journey_fix_time</comments> | |
| <pubDate>Wed, 11 Mar 2026 11:07:15 -0500</pubDate> | |
| <guid>https://lobste.rs/s/ei0ans/temporal_9_year_journey_fix_time</guid> | |
| <description>**The Gist:** JavaScript's `Date` object has been a long-standing source of bugs. Temporal is a modern replacement that has just reached Stage 4, offering immutable types, robust time zone and calendar support, and nanosecond precision. This article details the nine-year collaborative effort between Bloomberg, Igalia, and the TC39 community to standardize Temporal. | |
| **The Lobsters Take:** The comments section for "Temporal: The 9-Year Journey to Fix Time in JavaScript" can be found [here](https://lobste.rs/s/ei0ans/temporal_9_year_journey_fix_time). The snippet provided indicates there are "3 comments" but does not include their content, so a summary of the discussion cannot be generated.</description> | |
| </item> | |
| <item> | |
| <title>//go:fix inline and the source-level inliner</title> | |
| <link>https://go.dev/blog/inliner</link> | |
| <comments>https://lobste.rs/s/vjsm2q/go_fix_inline_source_level_inliner</comments> | |
| <pubDate>Wed, 11 Mar 2026 13:04:41 -0500</pubDate> | |
| <guid>https://lobste.rs/s/vjsm2q/go_fix_inline_source_level_inliner</guid> | |
| <description>- **The Gist:** The Go 1.26 release introduces a new source-level inliner, designed to help with self-service API migrations. This feature provides a mechanism for developers to manage changes to APIs more smoothly, by inlining code at the source level rather than solely relying on compiler optimizations. This approach aims to reduce friction when evolving APIs and maintaining backward compatibility. | |
| - **The Lobsters Take:** No comments yet.</description> | |
| </item> | |
| <item> | |
| <title>Okmain: you have an image but you want a colour</title> | |
| <link>https://dgroshev.com/blog/okmain/</link> | |
| <comments>https://lobste.rs/s/t43mh5/okmain_you_have_image_you_want_colour</comments> | |
| <pubDate>Wed, 11 Mar 2026 11:20:45 -0500</pubDate> | |
| <guid>https://lobste.rs/s/t43mh5/okmain_you_have_image_you_want_colour</guid> | |
| <description>**The Gist:** The article introduces "Okmain", a library designed to address the issue of generating dull and muddy background colors from images when simply resizing to 1x1 pixel. Okmain aims to find a visually pleasant and representative "main" color for an image by employing color clustering, Oklab color calculations, and chroma/position cluster sorting. The author developed the library in Rust with a Python wrapper and provided documentation and releases on crates.io and PyPI. | |
| **The Lobsters Take:** The comments section indicates that there are "2 comments", but the provided "Comments Snippet" does not contain the actual comment text, only the HTML structure of the Lobsters page up to the story details. Therefore, the actual discussion content is not available.</description> | |
| </item> | |
| <item> | |
| <title>Lobsters Interview with ngoldbaum</title> | |
| <link>https://alexalejandre.com/programming/interview-with-ngoldbaum/</link> | |
| <comments>https://lobste.rs/s/6lqnhh/lobsters_interview_with_ngoldbaum</comments> | |
| <pubDate>Wed, 11 Mar 2026 17:16:55 -0500</pubDate> | |
| <guid>https://lobste.rs/s/6lqnhh/lobsters_interview_with_ngoldbaum</guid> | |
| <description>- **The Gist:** The article is an interview with Nathan Goldbaum, discussing his work on making Python multithreaded and moving the ecosystem to a free-threading build, effectively "slaying Python's GIL." The interview also touches upon topics such as burnout, version control systems like Mercurial and Jujutsu, and his preference for pull requests that significantly reduce lines of code. | |
| - **The Lobsters Take:** No comments yet.</description> | |
| </item> | |
| <item> | |
| <title>Faster asin() Was Hiding In Plain Sight</title> | |
| <link>https://16bpp.net/blog/post/faster-asin-was-hiding-in-plain-sight/</link> | |
| <comments>https://lobste.rs/s/bunmdv/faster_asin_was_hiding_plain_sight</comments> | |
| <pubDate>Wed, 11 Mar 2026 11:00:20 -0500</pubDate> | |
| <guid>https://lobste.rs/s/bunmdv/faster_asin_was_hiding_plain_sight</guid> | |
| <description>- **The Gist:** The article investigates and presents a faster method for computing the `asin()` (arcsine) mathematical function, suggesting that an optimized approach was previously overlooked or not widely known. | |
| - **The Lobsters Take:** There are 8 comments discussing the article, but their content was not provided in the snippet, so a summary of the discussion cannot be generated.</description> | |
| </item> | |
| <item> | |
| <title>My PostgreSQL database got nuked lol</title> | |
| <link>https://akselmo.dev/posts/they-broke-my-server/</link> | |
| <comments>https://lobste.rs/s/vb7ipx/my_postgresql_database_got_nuked_lol</comments> | |
| <pubDate>Wed, 11 Mar 2026 13:06:57 -0500</pubDate> | |
| <guid>https://lobste.rs/s/vb7ipx/my_postgresql_database_got_nuked_lol</guid> | |
| <description>**The Gist:** Akseli Lahtinen details how his PostgreSQL database, used for his `linkhut` fork `scalie.computer`, was repeatedly "nuked." Initially baffled, he discovered the issue: he had inadvertently exposed the PostgreSQL port (`5432`) directly to the internet using `docker run -p 5432:5432`, leaving it unsecured without a password. Logs revealed numerous connection attempts from various IPs, followed by the database being wiped. The author expresses frustration with the complexity of self-hosting and securing services. | |
| **The Lobsters Take:** No comments yet.</description> | |
| </item> | |
| <item> | |
| <title>Tony Hoare (1934-2026)</title> | |
| <link>https://blog.computationalcomplexity.org/2026/03/tony-hoare-1934-2026.html</link> | |
| <description><p><strong>The Gist:</strong> Turing Award winner and former Oxford professor Tony Hoare passed away last Thursday at the age of 92. Hoare is renowned for his work on quicksort and other significant contributions to computer science.</p> | |
| <p><strong>The Lobsters Take:</strong> The discussion includes personal tributes and reflections on Tony Hoare's legacy, such as one user's admiration for his enduring intellect and a <a href="https://lobste.rs/c/vzzygw">freshman college experience</a> where Hoare demonstrated great politeness and generosity. Initially, there was some skepticism regarding the announcement's veracity due to a lack of immediate official sources, as noted in <a href="https://lobste.rs/c/yunufu">one comment</a>. However, this was clarified by a user who pointed out that Jim Miles, a personal acquaintance, had firsthand confirmation of Hoare's passing (<a href="https://lobste.rs/c/lce2gj">comment here</a>). Another user provided <a href="https://lobste.rs/c/86cmbz">links</a> to valuable resources, including the preface of "Theories of Programming: The Life and Works of Tony Hoare" and his Turing Award page, for those wishing to learn more about his career.</p></description> | |
| <pubDate>Tue, 10 Mar 2026 10:42:09 -0500</pubDate> | |
| <guid>https://lobste.rs/s/lyktdk</guid> | |
| <comments>https://lobste.rs/s/lyktdk/tony_hoare_1934_2026</comments> | |
| </item> | |
| <item> | |
| <title>RISC-V is sloooow</title> | |
| <link>https://marcin.juszkiewicz.com.pl/2026/03/10/risc-v-is-sloooow/</link> | |
| <description><p><strong>The Gist:</strong> Marcin Juszkiewicz, an AArch64 porter for Fedora Linux, discusses his experience with RISC-V development, particularly focusing on its current performance limitations. He highlights the significant difference in package build times between RISC-V and other architectures (e.g., aarch64, x86_64), with RISC-V taking considerably longer (143 minutes for binutils vs. 36 minutes for aarch64). This slowness necessitates disabling Link Time Optimization (LTO) to manage memory usage and build times. While acknowledging upcoming hardware improvements like UltraRISC UR-DP1000 and SpacemiT K3, he stresses the need for more powerful, rackable, and manageable RISC-V server hardware to make it a primary architecture for Fedora Linux. He also notes that QEMU emulation with many cores can sometimes outperform actual RISC-V hardware for building heavy packages like LLVM.</p> | |
| <p><strong>The Lobsters Take:</strong> The discussion revolves primarily around the current state of RISC-V performance and its practical implications, with some skepticism regarding its immediate viability as a workstation alternative. Commenters express frustration with the "just around the corner" narrative, pointing out that currently available RISC-V hardware significantly lags behind x86_64 and AArch64 offerings in performance (see <a href="https://lobste.rs/c/suqbvf">this comment</a> for a detailed comparison of current RISC-V SBCs to Raspberry Pi generations). There's debate on whether RISC-V's current slowness hinders its adoption in projects like Fedora Linux, with some arguing that slow iteration speed can kill a project and that maintainers should focus on more widely used architectures (<a href="https://lobste.rs/c/6chckw">comment</a>). Others question the premise, suggesting that Fedora's stance implies an inability to administer systems that aren't "fast enough" (<a href="https://lobste.rs/c/ix3p22">comment</a>). Some commenters highlight the cost-effectiveness of RISC-V hardware, suggesting that a build farm of multiple cheaper RISC-V boards could be a viable alternative to expensive high-core x86 machines (<a href="https://lobste.rs/c/6zww6y">comment</a>). The consensus appears to be that while RISC-V has great potential and is a "humongous step forward" for non-performance-bound computing, a parity RISC-V core comparable to high-end x86 or AArch64 systems does not yet exist (<a href="https://lobste.rs/c/iykjnx">comment</a>).</p></description> | |
| <pubDate>Tue, 10 Mar 2026 14:49:53 -0500</pubDate> | |
| <guid>https://lobste.rs/s/ta3jjk</guid> | |
| <comments>https://lobste.rs/s/ta3jjk/risc_v_is_sloooow</comments> | |
| </item> | |
| <item> | |
| <title>AI should help us produce better code</title> | |
| <link>https://simonwillison.net/guides/agentic-engineering-patterns/better-code/</link> | |
| <description><p><strong>The Gist:</strong> Simon Willison argues that AI, specifically coding agents, should help developers produce *better* code, not worse. He counters the fear that AI will lead to a drop in quality by stating that shipping worse code with agents is a choice, and we can choose to ship better code instead. Willison emphasizes that coding agents are ideal for tackling "simple but time-consuming" technical debt fixes, such as refactoring, renaming concepts, combining duplicate functionality, or splitting large files. He suggests that the cost of these improvements has dropped significantly, allowing for a "zero tolerance attitude to minor code smells." Furthermore, AI tools can help consider more options during planning and facilitate exploratory prototyping, allowing developers to quickly test multiple solutions. He advocates for "Compound Engineering," where lessons learned from agent runs are documented to improve future results, leading to a continuous increase in codebase quality.</p> | |
| <p><strong>The Lobsters Take:</strong> The discussion largely revolves around the implications of AI on code quality, developer learning, and technical debt. Many commenters echo the article's sentiment that AI can improve code quality and reduce technical debt. One user states, "<a href="https://lobste.rs/c/pv8zin">AI makes me care more about code quality</a>," while another notes that they can now address cross-codebase changes and refactoring at a scale previously "psychologically balked at" because of agents. One user highlights that LLMs help them write code faster by avoiding "silly" bugs, automating plumbing, and ensuring good error messages and documentation. The sentiment of AI assisting learning is also present, with a commenter optimistically comparing it to how "<a href="https://lobste.rs/c/iroex0">calculators didn't stop motivated people from learning mathematics</a>."</p> | |
| <p>However, some concerns are raised, particularly regarding new developers and the understanding of code quality. A user questions, "<a href="https://lobste.rs/c/f2g9wg">how is that person expected to learn the code?</a>" and "<a href="https://lobste.rs/c/8oogvt">how will someone know that the code is bad without learning how to program first?</a>" Another commenter touches on the subjective nature of "good" code, pointing out that "<a href="https://lobste.rs/c/xbsqjf">"Bad" and "good" code aren't well defined. These are aesthetic qualities.</a>" The article's assertion about avoiding technical debt entirely is also debated, with a user stating that it's "<a href="https://lobste.rs/c/9l3muq">as idealistic as it was pre agents</a>," but agrees that agents make paying down debt much quicker. The discussion also touches on agent-based PR review and the potential for agents to regularly review code for architectural or performance issues.</p></description> | |
| <pubDate>Tue, 10 Mar 2026 17:38:37 -0500</pubDate> | |
| <guid>https://lobste.rs/s/tiktds</guid> | |
| <comments>https://lobste.rs/s/tiktds/ai_should_help_us_produce_better_code</comments> | |
| </item> | |
| <item> | |
| <title>RISC-V is sloooow</title> | |
| <link>https://lobste.rs/s/ta3jjk/risc_v_is_sloooow</link> | |
| <guid>ta3jjk</guid> | |
| <pubDate>Tue, 10 Mar 2026 14:49:53 -0500</pubDate> | |
| <description>**The Gist:** The author, an ARM developer, shares their experience working with the RISC-V port of Fedora Linux over three months. While they've successfully triaged bugs and sent 86 pull requests for Fedora packages, a significant challenge is the "sloooow" performance of current RISC-V hardware, leading to drastically longer build times compared to aarch64, i686, ppc64le, s390x, and x86_64 architectures. For instance, building the binutils package takes 143 minutes on RISC-V, versus 25-46 minutes on others. This slowness necessitates disabling Link Time Optimization (LTO) to conserve memory and reduce build times. Current RISC-V builders typically have 4 or 8 cores and 8-32GB RAM, with performance comparable to older Arm Cortex-A55 cores. Newer SoCs like UltraRISC UR-DP1000 and SpacemiT K3 are expected to improve the situation but aren't seen as a "final solution." The author emphasizes the need for rackable, manageable hardware capable of building packages like binutils in under an hour with LTO enabled for RISC-V to become a primary Fedora architecture. QEMU with 80 emulated cores is still faster for some builds (e.g., llvm15 takes 4 hours on QEMU vs. 10.5 hours on a Banana Pi BPI-F3). Future plans include building Fedora 44, initially with LTO still disabled, and bringing in faster builders. | |
| **The Lobsters Take:** The comments revolve around the central theme of RISC-V's current performance limitations. | |
| * **classichasclass** [link to comment kvfuvl] directly challenges RISC-V enthusiasts to name a workstation-comparable RISC-V chip available today, expressing fatigue with promises of future improvements and noting that current offerings seem to compete with Raspberry Pi. They mention still using a POWER9, indicating a willingness to invest in alternatives if viable. | |
| * **alexrp** [link to comment yfnlhj] agrees that claims of immediate x86/AArch64 comparable performance are "borderline insane." They point to the upcoming Tenstorrent Atlantis silicon dev platform as a promising development for acceptable daily use performance and a potential replacement for slow Milk-V Jupiters in CI. | |
| * **brucehoult** [link to comment suqbvf] explains that RISC-V is extremely new, citing that the first $100 RISC-V SBC was equivalent to a 2012 Raspberry Pi (9 years behind), and a more recent Milk-V Megrez (shipping January 2025) is equivalent to a mid-2019 Raspberry Pi 4 (5.5 years behind), indicating the significant catching up required.</description> | |
| </item> | |
| <item> | |
| <title>LLM Neuroanatomy: How I Topped the AI Leaderboard Without Changing a Single Weight</title> | |
| <link>https://lobste.rs/s/zzjjyo/llm_neuroanatomy_how_i_topped_ai</link> | |
| <guid>zzjjyo</guid> | |
| <pubDate>Tue, 10 Mar 2026 15:12:41 -0500</pubDate> | |
| <description>**The Gist:** The article "LLM Neuroanatomy: How I Topped the AI Leaderboard Without Changing a Single Weight" by David Noel Ng describes how the author achieved the top spot on the HuggingFace Open LLM Leaderboard with the model `dnhkng/RYS-XLarge` without altering any model weights or performing new training. The innovation involved duplicating a specific seven-layer block from an existing 72-billion parameter model and re-integrating it. This technique, termed "LLM Neuroanatomy," was inspired by observations such as an LLM's unexpected ability to process and respond to Base64 encoded input, suggesting a deeper internal understanding despite the format being out-of-distribution for its training. | |
| **The Lobsters Take:** | |
| * **thesnarky1** found the article "fascinating" for its deep dive into model structure and the impact of structural changes, distinguishing it from typical "vibecoding" articles. | |
| * **kornel** expressed concern over Transformer architecture allocating equal compute to simple and complex tasks, and suggested that dynamically selecting the number of loops or skipping layers (MoE style) could be a logical next step given the fascinating discovery of layer looping. | |
| * **skycam** pondered whether a similar method could identify and replace redundant layers with pointers, potentially reducing memory requirements without the performance sacrifices often associated with traditional pruning.</description> | |
| </item> | |
| <item> | |
| <title>Source-available projects and their AI contribution policies</title> | |
| <link>https://lobste.rs/s/ysvfji/source_available_projects_their_ai</link> | |
| <guid>ysvfji</guid> | |
| <pubDate>Tue, 10 Mar 2026 10:45:04 -0500</pubDate> | |
| <description>**The Gist:** A survey of 112 major source-available projects revealed that 71 had explicitly AI-assisted commits, with many more allowing AI contributions without clear labeling. Only 4 projects (Zig, NetBSD, GIMP, qemu) entirely banned AI contributions, while some like DuckDB and Elasticsearch had AI commits despite policies seemingly against them. The survey found no clear pattern in AI adoption or banning across low-level and high-level projects. It notes that "Not found" in the data indicates no explicit policy or accepted AI contributions were identified. The article provides a table detailing AI contribution policies and accepted AI-assisted commits for various programming languages, web browsers, and databases, including preferred AI providers where mentioned. | |
| **The Lobsters Take:** The author, eatonphil, clarified that their survey found 70 of 112 projects already had AI-assisted commits, while 4 banned them. They noted that surveying distributions like Gentoo for AI policies was harder due to distributed codebases. The author emphasized that the survey makes no judgment. Another user, eminence32, questioned the classification of "llama.cpp" in the survey, pointing out a discrepancy between its policy ("does not accept pull requests that are fully or predominantly AI-generated. AI tools may be utilized solely in an assistive capacity.") and the survey's "Allows AI contributions = yes (AI-assisted)" label. They also couldn't find explicit preferred AI providers (Claude, Gemini) mentioned for llama.cpp.</description> | |
| </item> | |
| <item> | |
| <title>Dependency Tracking is Hard</title> | |
| <link>https://lobste.rs/s/lsjk8m/dependency_tracking_is_hard</link> | |
| <guid>lsjk8m</guid> | |
| <pubDate>Tue, 10 Mar 2026 03:47:35 -0500</pubDate> | |
| <description>**The Gist:** The provided article content snippet primarily contains CSS and HTML boilerplate, with the title "Dependency Tracking is Hard" from `daniel.haxx.se`. The actual body of the article content is not available in the snippet, preventing a detailed summary of the article itself. | |
| **The Lobsters Take:** The discussion revolves around the article's premise that "dependency tracking is hard." Commenters question whether the article adequately considers traditional package managers like `dpkg`, `RPM`, `ports`, and `Nix`, which are designed for robust dependency management. `iv` suggests the article might be focusing on the challenge of tracking *vendored* dependencies (those bundled directly with a project or OS rather than installed via a package manager). `technomancy` points out that distributions like Debian package `curl` normally, making its dependencies clear, and finds it odd if the article's tools or screenshots ignore `apt` given its widespread use. `untitaker` adds that expecting upstream software to "support" specific package managers like `apt` is unusual, as many projects don't maintain distro-specific packages.</description> | |
| </item> | |
| <item> | |
| <title>Rebasing in Magit</title> | |
| <link>https://lobste.rs/s/5mf3cb/rebasing_magit</link> | |
| <guid>5mf3cb</guid> | |
| <pubDate>Tue, 10 Mar 2026 09:05:15 -0500</pubDate> | |
| <description>**The Gist:** The article "Rebasing in Magit" by kqr, published on 2026-03-10, highlights the discoverability and efficiency of using Magit for Git operations, specifically focusing on the `git log` command within Magit. The author, inspired by Ian Whitlock's article on Magit, explains how Magit provides unintrusive hints for various `git log` options, making complex commands easily discoverable without needing to memorize man pages. Examples include filtering by author, date range, and file paths. The article emphasizes that Magit transparently shows the underlying Git commands it executes, helping users understand Git CLI better rather than hindering it. It sets the stage for discussing rebasing by first establishing the importance and power of Magit's `git log` interface for understanding repository structure. | |
| **The Lobsters Take:** The comments section shows strong appreciation for Magit. User "untrusem" mentions Magit (and ediff) being crucial for a 2-year-old fork rebase and praises its ability to teach Git, citing `--autostash` as an example. "slondr" extends this, noting that `M-x magit-clone` offers a superior directory picker than the terminal. "ubernostrum" points out a VS Code extension that mimics the Magit experience for those who don't use Emacs. "aardvark179" acknowledges Magit's excellence for rebasing but notes that some complex scenarios, like type renames, still occasionally require exporting patches and manual search/replace.</description> | |
| </item> | |
| <item> | |
| <title>RISC-V is sloooow</title> | |
| <link>https://lobste.rs/s/ta3jjk/risc_v_is_sloooow</link> | |
| <guid>ta3jjk</guid> | |
| <pubDate>Tue, 10 Mar 2026 14:49:53 -0500</pubDate> | |
| <description>Summary unavailable.</description> | |
| </item> | |
| <item> | |
| <title>LLM Neuroanatomy: How I Topped the AI Leaderboard Without Changing a Single Weight</title> | |
| <link>https://lobste.rs/s/zzjjyo/llm_neuroanatomy_how_i_topped_ai</link> | |
| <guid>zzjjyo</guid> | |
| <pubDate>Tue, 10 Mar 2026 15:12:41 -0500</pubDate> | |
| <description>Summary unavailable.</description> | |
| </item> | |
| <item> | |
| <title>Source-available projects and their AI contribution policies</title> | |
| <link>https://lobste.rs/s/ysvfji/source_available_projects_their_ai</link> | |
| <guid>ysvfji</guid> | |
| <pubDate>Tue, 10 Mar 2026 10:45:04 -0500</pubDate> | |
| <description>Summary unavailable.</description> | |
| </item> | |
| <item> | |
| <title>Dependency Tracking is Hard</title> | |
| <link>https://lobste.rs/s/lsjk8m/dependency_tracking_is_hard</link> | |
| <guid>lsjk8m</guid> | |
| <pubDate>Tue, 10 Mar 2026 03:47:35 -0500</pubDate> | |
| <description>Summary unavailable.</description> | |
| </item> | |
| <item> | |
| <title>Rebasing in Magit</title> | |
| <link>https://lobste.rs/s/5mf3cb/rebasing_magit</link> | |
| <guid>5mf3cb</guid> | |
| <pubDate>Tue, 10 Mar 2026 09:05:15 -0500</pubDate> | |
| <description>Summary unavailable.</description> | |
| </item> | |
| <title>Lobsters Digest</title> | |
| <link>https://lobste.rs/</link> | |
| <description>Summarized Lobsters feed</description> | |
| <item> | |
| <title>Tony Hoare (1934-2026)</title> | |
| <link>https://blog.computationalcomplexity.org/2026/03/tony-hoare-1934-2026.html</link> | |
| <guid>lyktdk</guid> | |
| <description> | |
| <p><strong>The Gist:</strong> A blog post reporting the passing of computer scientist Tony Hoare.</p> | |
| <p><strong>The Lobsters Take:</strong> The community is discussing the validity of the rumor, noting a lack of official sources like the BBC, and mentioning edit wars on Wikipedia regarding his status. (<a href="https://lobste.rs/s/lyktdk/tony_hoare_1934_2026">Link to discussion</a>)</p> | |
| </description> | |
| </item> | |
| <item> | |
| <title>Amazon holds engineering meeting about GenAI based outages</title> | |
| <link>https://arstechnica.com/ai/2026/03/after-outages-amazon-to-make-senior-engineers-sign-off-on-ai-assisted-changes/</link> | |
| <guid>t5dvs5</guid> | |
| <description> | |
| <p><strong>The Gist:</strong> Amazon is reportedly making senior engineers sign off on AI-assisted changes after GenAI-based outages.</p> | |
| <p><strong>The Lobsters Take:</strong> Discussions likely revolve around the reliability of AI-generated code and the necessity of human oversight in large-scale engineering systems.</p> | |
| </description> | |
| </item> | |
| <lastBuildDate>Wed, 11 Mar 2026 05:15:21 GMT</lastBuildDate> | |
| </channel> | |
| </rss> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment