lobsters-digest.xml

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>

<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><![CDATA[**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><![CDATA[**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><![CDATA[**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><![CDATA[**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><![CDATA[**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><![CDATA[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><![CDATA[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><![CDATA[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><![CDATA[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><![CDATA[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><![CDATA[
        <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><![CDATA[
        <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>
  </channel>
</rss>