<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: judofyr</title><link>https://news.ycombinator.com/user?id=judofyr</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sat, 01 Aug 2026 02:24:09 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=judofyr" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by judofyr in "How old is Ann?"]]></title><description><![CDATA[
<p>I imagined that I'm 24 years old and I have a 20 years old brother. When I were his age, he would have been 16 years old.<p>I also realized that this can be expressed in terms of a two pairs of sibling:<p>> Mary and Ann are the same age difference as Jane and Claire. Mary is 24 years old. Mary is twice as old as Jane. Claire is as old as Ann. How old is Ann?<p>This highlights also why it's so confusing:<p>> Mary is 24 years old. She [Mary, today] is twice as old as Ann was [Ann, past] when Mary was [Mary, past] as old as Ann is [Ann, today] now. How old is Ann?<p>In one sentence we're comparing past and present ages.</p>
]]></description><pubDate>Thu, 30 Jul 2026 15:39:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=49111526</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=49111526</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49111526</guid></item><item><title><![CDATA[New comment by judofyr in "How old is Ann?"]]></title><description><![CDATA[
<p>Rephrasing it makes it easier to grasp:<p>Mary is 24 years old. When Mary was Ann’s current age, Ann was 12 years old (half Mary’s current age).<p>This makes it a bit easier to realize that Ann’s age has to be right in the middle of 12 and 24.</p>
]]></description><pubDate>Thu, 30 Jul 2026 13:51:37 +0000</pubDate><link>https://news.ycombinator.com/item?id=49110038</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=49110038</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49110038</guid></item><item><title><![CDATA[New comment by judofyr in "PostgreSQL's MVCC is bad. So is everyone else's"]]></title><description><![CDATA[
<p>Some examples just from the second paragraph:<p>- <i>while none of this is exaggerated</i><p>- <i>it comes down to a real design choice</i><p>- <i>the bloat, the amplified writes, the vacuum babysitting</i><p>- <i>every charge traces to a decision, not a defect</i><p>- <i>the verdict that spreads from community to community always stops one question early</i><p>- <i>watch the damage happen yourself</i><p>Here's one way of how to write it in simpler language:<p>> These are not user mistakes and it's easy to reproduce these issues in a few lines of SQL on the latest version of Postgres. We're going to go through each of these problematic cases one by one to understand what's happening. Next, we're going to look at how other databases are solving it. Turns out there is no silver-bullet here: Postgres just makes a different set of trade-offs than other databases.<p>EDIT: And you can read for yourself how the LLM rates these two paragraphs compared to each other: <a href="https://chatgpt.com/share/6a6a3120-fec4-83eb-9c8b-dbb6294aa5ea" rel="nofollow">https://chatgpt.com/share/6a6a3120-fec4-83eb-9c8b-dbb6294aa5...</a></p>
]]></description><pubDate>Wed, 29 Jul 2026 16:54:15 +0000</pubDate><link>https://news.ycombinator.com/item?id=49099985</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=49099985</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49099985</guid></item><item><title><![CDATA[New comment by judofyr in ".gitignore Isn't the only way to ignore files in Git"]]></title><description><![CDATA[
<p>Not sure where I picked up this, but I’ve added this to my global Git ignore:<p><pre><code>    attic
</code></pre>
That way you can just create an attic directory in any project where you can keep random stuff that should never be committed. I’ve yet to find a repo which actually has such a directory checker in.</p>
]]></description><pubDate>Thu, 18 Jun 2026 14:34:27 +0000</pubDate><link>https://news.ycombinator.com/item?id=48586050</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=48586050</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48586050</guid></item><item><title><![CDATA[New comment by judofyr in "It's OK to compare floating-points for equality"]]></title><description><![CDATA[
<p>Ignoring the misuse of epsilon, I'd also say that you'd be helping your users more by <i>not</i> providing a general `assert_f64_eq` macro, but rather force the user to decide the error model. Add a required "precision" parameter as an enum with different modes:<p><pre><code>    // Precise matching:
    assert_f64_eq!(a, 0.1, Steps(2))
    // same as: assert!(a == 0.1.next_down().next_down())

    // Number of digits (after period) that are matching:
    assert_f64_eq!(a, 0.1, Digits(5))

    // Relative error:
    assert_f64_eq!(a, 0.1, Rel(0.5))</code></pre></p>
]]></description><pubDate>Sat, 18 Apr 2026 12:07:01 +0000</pubDate><link>https://news.ycombinator.com/item?id=47815260</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=47815260</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47815260</guid></item><item><title><![CDATA[New comment by judofyr in "Optimizing a lock-free ring buffer"]]></title><description><![CDATA[
<p>This is just wrong. See <a href="https://en.cppreference.com/w/cpp/atomic/memory_order.html" rel="nofollow">https://en.cppreference.com/w/cpp/atomic/memory_order.html</a>. Emphasis mine:<p>> A store operation with this memory order performs the release operation: <i>no reads or writes in the current thread</i> can be reordered after this store. <i>All writes in the current thread</i> are visible in other threads that acquire the same atomic variable (see Release-Acquire ordering below) and writes that carry a dependency into the atomic variable become visible in other threads that consume the same atomic (see Release-Consume ordering below).</p>
]]></description><pubDate>Thu, 26 Mar 2026 15:02:15 +0000</pubDate><link>https://news.ycombinator.com/item?id=47531350</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=47531350</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47531350</guid></item><item><title><![CDATA[New comment by judofyr in "Password managers less secure than promised"]]></title><description><![CDATA[
<p>It’s just an encrypted file on disk. You’d depend on whatever backup solution you already have in place.</p>
]]></description><pubDate>Sat, 21 Feb 2026 23:06:51 +0000</pubDate><link>https://news.ycombinator.com/item?id=47105921</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=47105921</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47105921</guid></item><item><title><![CDATA[New comment by judofyr in "Building a Rust-style static analyzer for C++ with AI"]]></title><description><![CDATA[
<p>Very cool project! Always happy to see more work around static analysis.<p>However, looking at the recent commits it doesn't quite look like the most solid foundation: <a href="https://github.com/shuaimu/rusty-cpp/commit/480491121ef9efecdb7012909fe95e4a3dbf1e07" rel="nofollow">https://github.com/shuaimu/rusty-cpp/commit/480491121ef9efec...</a><p><pre><code>    fn is_interior_mutability_type(type_name: &str) -> bool {
        type_name.starts_with("rusty::Cell<") ||
        type_name.starts_with("Cell<") ||
        type_name.starts_with("rusty::RefCell<") ||
        type_name.starts_with("RefCell<") ||
        // Also check for std::atomic which has interior mutability
        type_name.starts_with("std::atomic<") ||
        type_name.starts_with("atomic<")
    }
</code></pre>
… which then 30 minutes later is being removed again because it turns out to be completely dead code: <a href="https://github.com/shuaimu/rusty-cpp/commit/84aae5eff72bb45046e140ade6f62c49c6b7b7ff" rel="nofollow">https://github.com/shuaimu/rusty-cpp/commit/84aae5eff72bb450...</a><p>There's also quite a lot of dead code. All of these warnings are around unused variable, functions, structs, fields:<p><pre><code>    warning: `rusty-cpp` (bin "rusty-cpp-checker") generated 90 warnings (44 duplicates)</code></pre></p>
]]></description><pubDate>Mon, 05 Jan 2026 08:32:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=46496513</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=46496513</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46496513</guid></item><item><title><![CDATA[New comment by judofyr in "Linux Sandboxes and Fil-C"]]></title><description><![CDATA[
<p>Can you show an actual minimal C program which has this problem? I’m trying to follow along here, but it’s very hard for me to understand the exact scenario you’re talking about.</p>
]]></description><pubDate>Sun, 14 Dec 2025 16:57:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=46264522</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=46264522</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46264522</guid></item><item><title><![CDATA[New comment by judofyr in "My favourite small hash table"]]></title><description><![CDATA[
<p>Is there a specific reason to store the key + value as an `uint64_t` instead of just using a struct like this?<p><pre><code>    struct slot {
      uint32_t key;
      uint32_t value;
    }</code></pre></p>
]]></description><pubDate>Tue, 09 Dec 2025 16:35:05 +0000</pubDate><link>https://news.ycombinator.com/item?id=46206978</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=46206978</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46206978</guid></item><item><title><![CDATA[New comment by judofyr in "Over fifty new hallucinations in ICLR 2026 submissions"]]></title><description><![CDATA[
<p>> If a carpenter shows up to put a roof yet their hammer or nail-gun can't actually put in nails, who'd you blame; the tool, the toolmaker or the carpenter?<p>I would be unhappy with the carpenter, yes. But if the toolmaker was constantly over-promising (lying?), lobbying with governments, pushing their tools into the hands of carpenters, never taking responsibility, then I would <i>also</i> criticize the toolmaker. It’s also a toolmaker’s responsibility to be honest about what the tool should be used for.<p>I think it’s a bit too simplistic to say «AI is not the problem» with the current state of the industry.</p>
]]></description><pubDate>Sun, 07 Dec 2025 16:39:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=46182981</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=46182981</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46182981</guid></item><item><title><![CDATA[New comment by judofyr in "Over fifty new hallucinations in ICLR 2026 submissions"]]></title><description><![CDATA[
<p>I think this is a bit unfair. The carpenters are (1) living in world where there’s an extreme focus on delivering as quicklyas possible, (2) being presented with a tool which is promised by prominent figures to be amazing, and (3) the tool is given at a low cost due to being subsidized.<p>And yet, we’re not supposed to criticize the tool or its makers? Clearly there’s more problems in this world than «lazy carpenters»?</p>
]]></description><pubDate>Sun, 07 Dec 2025 15:47:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=46182550</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=46182550</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46182550</guid></item><item><title><![CDATA[New comment by judofyr in "What Happened in 2007?"]]></title><description><![CDATA[
<p>I’m sorry, but this is such a terribly unscientific approach. You want to make a case for your hypothesis? Follow a structured approach with real arguments.<p>Saying «I know that correlation doesn’t imply causation», but then only demonstrating correlation isn’t really bringing this discourse any further.</p>
]]></description><pubDate>Sun, 19 Oct 2025 12:40:59 +0000</pubDate><link>https://news.ycombinator.com/item?id=45633737</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=45633737</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45633737</guid></item><item><title><![CDATA[New comment by judofyr in "Ruby Blocks"]]></title><description><![CDATA[
<p>Maybe I explained it a bit imprecise. I was trying to explain the following behavior:<p><pre><code>    def foo
      p 1
      yield
      p 2
    end

    foo { break }
</code></pre>
This only prints "1" because the break stops the execution of the invoked method (foo).</p>
]]></description><pubDate>Sat, 18 Oct 2025 12:43:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=45626904</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=45626904</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45626904</guid></item><item><title><![CDATA[New comment by judofyr in "Ruby Blocks"]]></title><description><![CDATA[
<p>Blocks are fundamentally different from functions due to the control flow: `return` inside a block will return the <i>outer</i> method, not the block. `break` stops the whole method that was invoked.<p>This adds some complexity in the language, but it means that it’s far more expressive. In Ruby you can with <i>nothing but Array#each</i> write idiomatic code which reads very similar to other traditional languages with loops and statements.</p>
]]></description><pubDate>Sat, 18 Oct 2025 10:11:46 +0000</pubDate><link>https://news.ycombinator.com/item?id=45626195</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=45626195</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45626195</guid></item><item><title><![CDATA[New comment by judofyr in "Strong Eventual Consistency – The Big Idea Behind CRDTs"]]></title><description><![CDATA[
<p>> This has massive implications. SEC means low latency, because nodes don't need to coordinate to handle reads and writes. It means incredible fault tolerance - every single node in the system bar one could simultaneously crash, and reads and writes could still happen normally. And it means nodes still function properly if they're offline or split from the network for arbitrary time periods.<p>Well, this all depends on the definition of «function properly». Convergence ensures that everyone observed the same state, not that it’s a <i>useful</i> state. For instance, The Imploding Hashmap is a very easy CRDT to implement. The rule is that when there’s concurrent changes to the same key, the final value becomes null. This gives Strong Eventual Consistency, but isn’t really a very useful data structure. All the data would just disappear!<p>So yes, CRDT is a massively useful <i>property</i> which we should strive for, but it’s not going to magically solve all the end-user problems.</p>
]]></description><pubDate>Tue, 09 Sep 2025 08:51:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=45179344</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=45179344</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45179344</guid></item><item><title><![CDATA[New comment by judofyr in "macOS dotfiles should not go in –/Library/Application Support"]]></title><description><![CDATA[
<p>> The standardized location is Library.<p>Except for Zsh (~/.zshrc), SSH (~/.ssh/config), Vim (~/.vimrc), Curl (~/.curlrc), Git (~/.gitconfig). Apple could have chosen to patch these and move the configuration files into ~/Library if they really wanted.</p>
]]></description><pubDate>Tue, 26 Aug 2025 12:15:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=45025491</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=45025491</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45025491</guid></item><item><title><![CDATA[New comment by judofyr in "IQ tests results for AI"]]></title><description><![CDATA[
<p>> Suggest contrary to that is wrongthink and enough to have one ostracized not only from science, but also society as a whole.<p>There's <i>many</i> scientists who have published the "contrary". They were not ostracized from science or from society as a whole. These saw next to none negative impact to their position while they were alive. Other scientists have published rebuttals and later some of the originals articles have been retracted.<p><i>J. Philippe Rushton:</i> 250 published articles, 6 books, the most famous university professor in Canada. Retractions of this work came 8 years after his death.<p><i>Arthur Jensen:</i> Wrote a controversial paper in 1969. Ended up publishing 400 articles. Remained a professor for his full life.<p><i>Hans Eysenck:</i> The most cited living psychologist in peer-reviewed scientific journal literature. It took more than 20 years before any of his papers were retracted.<p>There's <i>a lot</i> of published articles about the "contrary view" that you can read. You can also read the rebuttals by the current scientific consensus (cited above).<p>> The analogous claim would therefore be that “although height differences have a large hereditary component, it does not follow that disparities in height between families have a genetic basis.” This seems very clearly false to me.<p>But this is not an analogous claim since you're talking about disparities between <i>families</i>. The analogous claim would be: "although height differences have a large hereditary component, it does not follow that disparities in height between <i>groups</i> have a genetic basis".<p>A very simple example for height[1]: The Japanese grew 10 cm taller from mid-20th century to early 2000s. Originally people thought that the shortness of the Japanese was related to their genetics, but this rapid growth (which also correlates with their improved economy) suggests that the group difference between Japanese and other groups was <i>not</i> related to the genetic component of height variance.<p>[1]: Secular Changes in Relative Height of Children in Japan, South Korea and Taiwan: Is “Genetics” the Key Determinant? <a href="https://biomedgrid.com/pdf/AJBSR.MS.ID.000857.pdf" rel="nofollow">https://biomedgrid.com/pdf/AJBSR.MS.ID.000857.pdf</a></p>
]]></description><pubDate>Sun, 17 Aug 2025 18:14:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=44933637</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=44933637</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44933637</guid></item><item><title><![CDATA[New comment by judofyr in "IQ tests results for AI"]]></title><description><![CDATA[
<p>Your first link (Wikipedia) directly contradicts your examples:<p>> Although IQ differences between individuals have been shown to have a large hereditary component, it does not follow that disparities in IQ between groups have a genetic basis[18][19][20][21]. The scientific consensus is that genetics does not explain average differences in IQ test performance between racial groups.[22][23][24][25][26][27].</p>
]]></description><pubDate>Sun, 17 Aug 2025 13:59:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=44931603</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=44931603</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44931603</guid></item><item><title><![CDATA[New comment by judofyr in "Traps to Developers"]]></title><description><![CDATA[
<p>No, sorry. I was just remembering where I've typically seen sequential consistency being used. For instance, Peterson's algorithm was what I had in mind. Spinlock is indeed a good example (although a <i>terrible</i> algorithm which I hope you haven't seen used in practice) of a mutex algorithm which only requires acquire-release.</p>
]]></description><pubDate>Sun, 17 Aug 2025 08:42:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=44929979</link><dc:creator>judofyr</dc:creator><comments>https://news.ycombinator.com/item?id=44929979</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44929979</guid></item></channel></rss>