New Lobste.rs Links RSS Feed - lobsters-feed

lobsters-feed.xml

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>New Lobste.rs Links</title>
    <link>https://lobste.rs</link>
    <description>Daily digest of new links from lobste.rs with summaries and community comments</description>
    <lastBuildDate>Wed, 03 Dec 2025 06:00:00 GMT</lastBuildDate>
    <item>
      <title>zmx: session persistence for terminal processes</title>
      <link>https://github.com/neurosnap/zmx</link>
      <guid>https://github.com/neurosnap/zmx</guid>
      <pubDate>Wed, 03 Dec 2025 06:00:00 GMT</pubDate>
      <description>&lt;h3&gt;Excerpt&lt;/h3&gt;
&lt;blockquote&gt;Session persistence for terminal processes. After a couple of months of R&amp;amp;D, zmx provides attach/detach functionality as a standalone tool. It extracts this from tmux and defers window management to your OS window manager instead. The tool features terminal state and history restoration using libghostty-vt, which holds terminal state and scrollback, enabling users to pick up where they left off as if they never disconnected. The daemon and client processes communicate via Unix sockets, with each session creating its own daemon. The architecture is remarkably simple: fork() → setsid() on child → forkpty() → attach on parent.&lt;/blockquote&gt;
&lt;h3&gt;Summary&lt;/h3&gt;
&lt;p&gt;zmx is a lightweight session persistence tool written in Zig that provides attach/detach functionality for terminal processes without the window management overhead of tmux. It features terminal state restoration via libghostty-vt and supports multiple clients connecting to the same session, making it ideal for users who prefer their OS window manager over tmux's built-in panes and splits.&lt;/p&gt;
&lt;h3&gt;Top Comments&lt;/h3&gt;
&lt;ul&gt;
  &lt;li&gt;&lt;strong&gt;zie:&lt;/strong&gt; "I've seen this trend pick up to avoid tmux/screen like tools. It's an interesting/new way of working from how I have been. This tool seems like it's finally possible to use this workflow."&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;erock:&lt;/strong&gt; "shpool only supports a single client connected to a single session, zmx lets multiple clients connect to the same session. zmx uses libghostty for better terminal state support. zmx creates a daemon per terminal session so if a single session crashes it doesn't kill all terminal sessions."&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;LolPython:&lt;/strong&gt; "This rocks and I honestly think this workflow is the future. There was really too much friction with tmux for me."&lt;/li&gt;
&lt;/ul&gt;</description>
    </item>
    <item>
      <title>In defense of lock poisoning in Rust</title>
      <link>https://sunshowers.io/posts/on-poisoning/</link>
      <guid>https://sunshowers.io/posts/on-poisoning/</guid>
      <pubDate>Wed, 03 Dec 2025 06:00:00 GMT</pubDate>
      <description>&lt;h3&gt;Excerpt&lt;/h3&gt;
&lt;blockquote&gt;Rust's mutex implementation includes a feature called "lock poisoning" - when a panic occurs while holding a mutex lock, the mutex is marked as poisoned, and subsequent lock attempts return a PoisonError. This is a deliberate design choice to detect when critical sections have been unexpectedly interrupted. When a thread panics in the middle of a critical section, the invariants guarded by that mutex can be left in an inconsistent state. Lock poisoning is the mechanism that detects this corruption, making it "the only indication that a panic previously occurred in a critical section!" The key insight is that while panics don't always cause invariant violations, they're common enough and the downsides of undetected corruption so severe, that poisoning is valuable as a strong heuristic.&lt;/blockquote&gt;
&lt;h3&gt;Summary&lt;/h3&gt;
&lt;p&gt;Lock poisoning in Rust is a critical safety feature that detects when mutex-guarded data has been left in an inconsistent state due to unexpected panics or future cancellations. The author argues that the unbounded downside of undetected corruption outweighs ergonomic concerns, and proposes making lock() automatically panic on poisoned mutexes rather than removing poisoning entirely.&lt;/p&gt;
&lt;h3&gt;Top Comments&lt;/h3&gt;
&lt;ul&gt;
  &lt;li&gt;&lt;strong&gt;kornel:&lt;/strong&gt; "Poisoning is persistent. Without a specific mechanism to fix/restore/reset state, the lock remains useless forever. Instead of poisoning, I'd prefer locks that automatically reset potentially-corrupt state."&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;dap:&lt;/strong&gt; "There's a big asymmetry: choosing to poison as the default - the downside risk is bounded; choosing not to poison - the downside risk is potentially enormous."&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;munin:&lt;/strong&gt; "One of the specific things I like about Rust is how variables have no default values, requiring that the developer reason out ahead of declaration."&lt;/li&gt;
&lt;/ul&gt;</description>
    </item>
    <item>
      <title>100000 TPS over a billion rows: the unreasonable effectiveness of SQLite</title>
      <link>https://andersmurphy.com/2025/12/02/100000-tps-over-a-billion-rows-the-unreasonable-effectiveness-of-sqlite.html</link>
      <guid>https://andersmurphy.com/2025/12/02/100000-tps-over-a-billion-rows-the-unreasonable-effectiveness-of-sqlite.html</guid>
      <pubDate>Wed, 03 Dec 2025 06:00:00 GMT</pubDate>
      <description>&lt;h3&gt;Excerpt&lt;/h3&gt;
&lt;blockquote&gt;SQLite massively outperforms network databases like Postgres when queries require multiple round trips, because Amdahl's law applies to network latency holding locks across connections. With Postgres on the same machine: 13,756 TPS. Add 10ms network latency: 660 TPS (a 95% reduction!). But SQLite achieves 44,096 TPS locally. By eliminating the network and batching writes, SQLite reaches 121,922 TPS with savepoint-based nested transactions. The single-writer model enables dynamic batching that self-optimizes for both throughput and latency.&lt;/blockquote&gt;
&lt;h3&gt;Summary&lt;/h3&gt;
&lt;p&gt;SQLite's single-writer design enables dynamic batching with savepoint-based nested transactions, achieving 121,922 TPS compared to Postgres's 660 TPS in realistic interactive scenarios with network latency. The fundamental limitation of network databases is Amdahl's law applied to latency: holding row locks across a network creates an unbreakable performance ceiling that no amount of additional resources can overcome.&lt;/p&gt;
&lt;h3&gt;Top Comments&lt;/h3&gt;
&lt;ul&gt;
  &lt;li&gt;&lt;strong&gt;glesica:&lt;/strong&gt; "Application servers in different data centers from the DB server is mentioned early on, but this isn't possible with the Sqlite version either, unless you can shard the data and requests by DC, right?"&lt;/li&gt;
&lt;/ul&gt;</description>
    </item>
  </channel>
</rss>