<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: aseipp</title><link>https://news.ycombinator.com/user?id=aseipp</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Tue, 04 Aug 2026 03:12:13 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=aseipp" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by aseipp in "Postmortem for Kernel Soundness Bug #14576"]]></title><description><![CDATA[
<p>The relevant kernel code isn't written by Claude though. According to git blame, 95% of the code in inductive.cpp is 5+ years old, with only ~3 hunks (totaling less than 30 lines) coming within the last 12 months including this fix. The Lean kernel in general does not seem to change very much, e.g. the last two years are very sparse in terms of activity with relatively contained changes when I examine the history (especially so when contrasted with the pace of the rest of the project).<p>Beyond that it looks like a pretty simple oversight. Coq and Isabelle have also had 'prove False' bugs, it isn't the end of the world. Stuff like this happens.</p>
]]></description><pubDate>Sat, 01 Aug 2026 19:40:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=49137685</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=49137685</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49137685</guid></item><item><title><![CDATA[New comment by aseipp in "JEP 541: Deprecate the macOS/x64 Port for Removal"]]></title><description><![CDATA[
<p>"Does the hardware physically work" isn't ever really the question under consideration, though, for better or worse. For Macs specifically, it is going to get increasingly difficult to even test things in the coming years. Mac x86 builds are by far the flakiest on GitHub in my experience, there's no expanding capacity, only refurbished machines 6 years out, and the number of users is dwindling, not to mention the enormous performance gap. So what do you do? When we last asked about it in a project I work on a few users expressed interest, so we kept it, but that isn't forever. The JDK as a project probably has a different risk profile than most other projects too so the cost of keeping around that code can be relatively high.<p>Not saying it is always good, in fact I would say there is rarely a "good" happy outcome in these cases, just trying to give the alternative perspective when you have to make these calls.</p>
]]></description><pubDate>Fri, 24 Jul 2026 17:58:08 +0000</pubDate><link>https://news.ycombinator.com/item?id=49039384</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=49039384</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49039384</guid></item><item><title><![CDATA[New comment by aseipp in "Qualcomm Linux 2.0"]]></title><description><![CDATA[
<p>Point well taken.</p>
]]></description><pubDate>Thu, 02 Jul 2026 04:27:59 +0000</pubDate><link>https://news.ycombinator.com/item?id=48756573</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=48756573</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48756573</guid></item><item><title><![CDATA[New comment by aseipp in "Qualcomm Linux 2.0"]]></title><description><![CDATA[
<p>They've been upstreaming drivers for the X2 platform for months at this point, since at least late 2025 (just search "glymur" or "kaanapali" on LKML).<p>The patch referenced in the Phoronix article is just a device tree file. That is the easiest part of the whole thing. As usual he's just farming every random LKML patch he can for clicks.</p>
]]></description><pubDate>Thu, 02 Jul 2026 03:41:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=48756251</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=48756251</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48756251</guid></item><item><title><![CDATA[New comment by aseipp in "OpenAI unveils its first custom chip, built by Broadcom"]]></title><description><![CDATA[
<p>Not having a free toolchain that can actually handle the real language has probably been pretty bad on the downstream public knowledgebase. Hopefully Verilator can eventually close that hole, and there can be more high-quality designs and codebases incorporated into future models. Claude is at least good enough to write SV that triggered a compiler crash or two. :)</p>
]]></description><pubDate>Wed, 24 Jun 2026 20:50:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=48665451</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=48665451</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48665451</guid></item><item><title><![CDATA[New comment by aseipp in "F3"]]></title><description><![CDATA[
<p>Despite the name seemingly implying otherwise, F3 is an alternative to columnar storage formats like Parquet; the goal is not to support every conceivable encoding of every file type such as a PDF. Think of the use cases being more like "What if you used a specialized compressor and need a custom block decompression algorithm" or "Decode internal format into Arrow output" or something like that.</p>
]]></description><pubDate>Tue, 23 Jun 2026 18:06:39 +0000</pubDate><link>https://news.ycombinator.com/item?id=48648878</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=48648878</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48648878</guid></item><item><title><![CDATA[New comment by aseipp in "Claude Fable 5"]]></title><description><![CDATA[
<p>They almost certainly already make a fuckload more money off API pricing than they do subscriptions, even if there might be more total subscription users. So offering subscriptions even at some loss is probably going to continue. Honestly, I'd be surprised if they even lost money on most subs; there are definitely Token Whales out there who mess up all the accounting up, though.<p>Realistically I think Anthropic just has insane demand but finite capacity to run models, and Fable will just make them more money if they dedicate it to API pricing. I suspect the goal here is something like: get individual engineers/PMs on their personal plans to taste Fable and then go to their meetings and say "Yes doubling the price of every single input/output token is a good idea, boss".</p>
]]></description><pubDate>Tue, 09 Jun 2026 17:45:15 +0000</pubDate><link>https://news.ycombinator.com/item?id=48464650</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=48464650</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48464650</guid></item><item><title><![CDATA[New comment by aseipp in "Moving beyond fork() + exec()"]]></title><description><![CDATA[
<p>I suspect it's a long tail sort of thing; it mostly doesn't matter except when it really matters. It's interesting that the stated motivation for the patch is in the context of agentic tools spawning subcommands. There's some related prior art in this area where the payoffs could be much greater, like fuzzing: <a href="https://gts3.org/assets/papers/2017/xu:os-fuzz.pdf" rel="nofollow">https://gts3.org/assets/papers/2017/xu:os-fuzz.pdf</a> is an example. It would be very interesting to see this patch applied to e.g. AFL++</p>
]]></description><pubDate>Sat, 06 Jun 2026 16:36:59 +0000</pubDate><link>https://news.ycombinator.com/item?id=48426584</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=48426584</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48426584</guid></item><item><title><![CDATA[New comment by aseipp in "Moving beyond fork() + exec()"]]></title><description><![CDATA[
<p>This paper is great and I also really like one of its references [29] as it goes into some more subtle parts of scalable interfaces, including fork. It's a gem IMO: The Scalable Commutativity Rule: Designing Scalable Software for Multicore Processors <a href="https://people.csail.mit.edu/nickolai/papers/clements-sc.pdf" rel="nofollow">https://people.csail.mit.edu/nickolai/papers/clements-sc.pdf</a></p>
]]></description><pubDate>Sat, 06 Jun 2026 16:22:17 +0000</pubDate><link>https://news.ycombinator.com/item?id=48426457</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=48426457</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48426457</guid></item><item><title><![CDATA[New comment by aseipp in "Did Claude increase bugs in rsync?"]]></title><description><![CDATA[
<p>> That's my impression from that sentence, at least. Don't you agree?<p>No. Given a choice between doing laundry and driving Lamborghinis, I would probably choose the latter. But I still have to do my laundry. I might use a washing machine to do so. It's just a responsibility among many responsibilities. It isn't that deep, really.<p>The reality few people want to admit is that maintaining open-source software is often closer for many people to "doing laundry" than like, being the software equivalent of Atticus Finch.<p>> Or did Claude just gave some basically retired programmer, who doesn't even want to work on his project anymore,<p>The only thing Claude has "done" apparently is give a bunch of annoying people online a license to engage in armchair psychoanalysis of someone they don't know at all, from what I can tell.</p>
]]></description><pubDate>Sat, 06 Jun 2026 14:21:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=48425410</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=48425410</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48425410</guid></item><item><title><![CDATA[New comment by aseipp in "Nvidia RTX Spark"]]></title><description><![CDATA[
<p>The GB10 itself is pretty good and I love using mine for broad Linux development. But it's too expensive for consumer level pricing, and even for the "prosumer" the price is pretty stiff. Even if they dropped the CX-7 and halfed the RAM and shipped a smaller hard drive, would it be below, say, $2500 USD? I guess we'll see, but this variant is coming out pretty late so maybe it's just best to wait for the 2nd generation.</p>
]]></description><pubDate>Mon, 01 Jun 2026 12:24:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=48355902</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=48355902</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48355902</guid></item><item><title><![CDATA[New comment by aseipp in "Tailscale-rs: Official Rust library for embedding Tailscale"]]></title><description><![CDATA[
<p>Imagine something like writing a server with an /metrics HTTP endpoint that Prometheus can then scrape -- but you bind it on separate port only inside a tailnet, with an ephemeral tailnet key and name it "metrics-service-blahblah".<p>Now you can simply write a script that uses the tailscale API to find all "metrics-service-*" nodes in your tailnet, and then adds their IP/DNS to your prometheus scraping list. Run it every 60 seconds. Done, now you can just deploy your app anywhere on any cloud and it will get scraped and that route will never be exposed to the outer internet.<p>This will basically just let you attach bespoke <i>applications</i> and not just "computers" to your network. I suspect I will get a lot of use from it.</p>
]]></description><pubDate>Thu, 16 Apr 2026 20:26:40 +0000</pubDate><link>https://news.ycombinator.com/item?id=47799047</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=47799047</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47799047</guid></item><item><title><![CDATA[New comment by aseipp in "jj – the CLI for Jujutsu"]]></title><description><![CDATA[
<p>Yes, almost all JJ users do this constantly. Just "track" the particular branch. JJ has an idea that only some commits are immutable, the set of "immutable heads", and the default logic is something like "The main branch is always immutable, remote branches are immutable, 'tracked' remote branches are mutable." In other words, tracking a remote branch removes it from the set of immutable heads.<p>So just run:<p><pre><code>    jj bookmark track myname/somecoolfeature --remote origin
</code></pre>
and the default settings will Do What You Want. This is intended as a kind of safeguard so that you do not accidentally update someone else's work.<p>Some people configure the set of immutable heads to be the empty set so they can go wild.</p>
]]></description><pubDate>Tue, 14 Apr 2026 14:52:57 +0000</pubDate><link>https://news.ycombinator.com/item?id=47766439</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=47766439</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47766439</guid></item><item><title><![CDATA[New comment by aseipp in "We've raised $17M to build what comes after Git"]]></title><description><![CDATA[
<p>Jujutsu is not "VC funded". But some of the developers, including me, work at East River Source Control (I worked on Jujutsu before that, too). The majority of the code in the project doesn't come from us -- or Google, for that matter. We don't allow people to approve patches when the author is from the same company, anyway.</p>
]]></description><pubDate>Fri, 10 Apr 2026 10:36:49 +0000</pubDate><link>https://news.ycombinator.com/item?id=47716039</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=47716039</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47716039</guid></item><item><title><![CDATA[New comment by aseipp in "We've raised $17M to build what comes after Git"]]></title><description><![CDATA[
<p>jj is not "one guy who works at Google" and the vast majority of submitted code comes from non-Google developers. Even if Google were to stop developing jj (they won't) the project would be healthy and strong.<p>There's some legal annoyances around e.g. CLA which was a result of being a side project of Google originally. Hopefully we'll move through that in due time. But realistically it's a much larger project at this point and has grown up a lot, it's not Martin's side project anymore.</p>
]]></description><pubDate>Fri, 10 Apr 2026 10:31:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=47716003</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=47716003</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47716003</guid></item><item><title><![CDATA[New comment by aseipp in "Astral to Join OpenAI"]]></title><description><![CDATA[
<p>Just to be clear: I think uv and the other Astral projects will probably be just fine! I don't really think this the end at all.<p>I was just trying to explain why people are so upset by the <i>perceived</i> change of hands; that perception isn't perfect of course, it's a mixture of fear, honesty, skepticism, truth etc. I think some people here are just being absurd (e.g. the idea that community projects are magically more sustainable by the fact they are community projects is literally just wishcasting with a mix of Red-Dots-On-Plane syndrome). But I can definitely understand the source of it.</p>
]]></description><pubDate>Fri, 20 Mar 2026 16:32:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=47456970</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=47456970</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47456970</guid></item><item><title><![CDATA[New comment by aseipp in "Astral to Join OpenAI"]]></title><description><![CDATA[
<p>Part of the reason Astral as a team is so well liked is precisely <i>because</i> they are not part of the main fold or related to "Core Python"; they are an independent vendor, one that delivered high quality code and listened directly to users and their own (extensive) experience to do so, and they succeeded at that repeatedly. Python packaging has {been seen as, actually been} miserable <i>for years</i>, and so by the same token the capacity to believe in/buy into solutions from the "core project" has dwindled. "If it took Astral to fix it, why would it be any different going forward?"<p>So that's all it really comes down to; uv isn't loved just because it's great but because it is <i>in good hands</i>. This real/perceived change of hands pretty much explains all the downstream responses to the news that you see in this thread. Regardless of who bought them, any fork is going to have very, very big shoes to fill, and filling those shoes appropriately is the big worry.</p>
]]></description><pubDate>Thu, 19 Mar 2026 19:52:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=47444932</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=47444932</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47444932</guid></item><item><title><![CDATA[New comment by aseipp in "A Decade of Slug"]]></title><description><![CDATA[
<p>Not quite, just the pixel/vertex shaders and the algorithm is public domain. Slug "the software package" is not open source (you can get a copy of it along with C4 Engine for $100 to take a peek if you want, though).</p>
]]></description><pubDate>Tue, 17 Mar 2026 21:08:27 +0000</pubDate><link>https://news.ycombinator.com/item?id=47418345</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=47418345</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47418345</guid></item><item><title><![CDATA[New comment by aseipp in "Arm's Cortex X925: Reaching Desktop Performance"]]></title><description><![CDATA[
<p>Yeah, I was more just trying to paint a broad picture. Nvidia in particular I think had fast and large-ish L1 on Tegra (X2?) despite being tied to 4k pages.</p>
]]></description><pubDate>Wed, 04 Mar 2026 12:50:17 +0000</pubDate><link>https://news.ycombinator.com/item?id=47246724</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=47246724</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47246724</guid></item><item><title><![CDATA[New comment by aseipp in "Arm's Cortex X925: Reaching Desktop Performance"]]></title><description><![CDATA[
<p>I feel like that was much more true in the past but the X925 was only spec'd 18 months ago(?) and you can buy it today (I'm using one since October). Intel and AMD also give lots of advance notice on new designs well ahead of anything you can buy. ARM is also moving towards providing completely integrated solutions, so customers like Samsung don't have to take only CPU core and fill in the blanks themselves. They'll probably only get better at shipping complete solutions faster.<p>Honestly, Apple is the strange one because they never discuss CPUs until they are available to buy in a product; they don't need to bother.</p>
]]></description><pubDate>Tue, 03 Mar 2026 16:27:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=47234818</link><dc:creator>aseipp</dc:creator><comments>https://news.ycombinator.com/item?id=47234818</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47234818</guid></item></channel></rss>