<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: drougge</title><link>https://news.ycombinator.com/user?id=drougge</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Wed, 20 May 2026 14:52:09 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=drougge" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by drougge in "Mad Bugs: Vim vs. Emacs vs. Claude"]]></title><description><![CDATA[
<p>Those that have some git status information in their shell prompts should probably make sure they are not bitten by the same git issues. I currently have to following (zsh syntax) setup for that:<p><pre><code>   git=(git -c core.hooksPath=/dev/null)
   fsmonitor=$($git config core.fsmonitor)
   if [[ -n $fsmonitor && $fsmonitor != true && $fsmonitor != false ]]; then
           git+=(-c core.fsmonitor=false)
           echo "Worrying git core.fsmonitor setting: $fsmonitor"
   fi</code></pre></p>
]]></description><pubDate>Wed, 01 Apr 2026 11:24:58 +0000</pubDate><link>https://news.ycombinator.com/item?id=47599398</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=47599398</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47599398</guid></item><item><title><![CDATA[New comment by drougge in "In praise of –dry-run"]]></title><description><![CDATA[
<p>Probably inspired by Vinum's "NO FUTURE" for destructive operations. (Vinum was a raid system used on older versions of FreeBSD.)</p>
]]></description><pubDate>Sun, 01 Feb 2026 15:44:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=46846950</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=46846950</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46846950</guid></item><item><title><![CDATA[New comment by drougge in "Reverse engineering a neural network's clever solution to binary addition (2023)"]]></title><description><![CDATA[
<p>This seems interesting, but I got stuck fairly early on when I read "all 32,385 possible input combinations". There are two 8 bit numbers, 16 totally independent bits. That's 65_536 combinations. 32_285 is close to half that, but not quite. Looking at it in binary it's 01111110_10000001, i.e. two 8 bit words that are the inverse of each other. How was this number arrived at, and why?<p>Looking later there's also a strange DAC that gives the lowest resistance to the least significant bit, thus making it the biggest contributor to the output. Very confusing.</p>
]]></description><pubDate>Sat, 08 Nov 2025 14:14:20 +0000</pubDate><link>https://news.ycombinator.com/item?id=45856781</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=45856781</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45856781</guid></item><item><title><![CDATA[New comment by drougge in "Show HN: MyraOS – My 32-bit operating system in C and ASM (Hack Club project)"]]></title><description><![CDATA[
<p>There's probably a lot of other memory bugs though. The first thing I looked at was the shell, and almost immediately I spotted an out of bounds write (input[n] = '\0' where n could be sizeof(input)).</p>
]]></description><pubDate>Mon, 27 Oct 2025 14:29:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=45721401</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=45721401</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45721401</guid></item><item><title><![CDATA[New comment by drougge in "The Peach meme: On CRTs, pixels and signal quality (again)"]]></title><description><![CDATA[
<p>The C= 1084S he uses is a more a (very good) PAL TV than a computer monitor, even if it was sold as a monitor. So "576i" in your terminology. (It was also sometimes sold with a TV tuner, or at least the earlier 1084 (same picture tube AFAIK) was.)</p>
]]></description><pubDate>Mon, 20 Oct 2025 16:46:56 +0000</pubDate><link>https://news.ycombinator.com/item?id=45646012</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=45646012</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45646012</guid></item><item><title><![CDATA[New comment by drougge in "AMD and Sony's PS6 chipset aims to rethink the current graphics pipeline"]]></title><description><![CDATA[
<p>Surely that 20+ year old CRT didn't run at more than 240Hz? Something other than framerate is at play here.</p>
]]></description><pubDate>Sun, 12 Oct 2025 11:07:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=45557259</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=45557259</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45557259</guid></item><item><title><![CDATA[New comment by drougge in "I just want an 80×25 console, but that's no longer possible"]]></title><description><![CDATA[
<p>I have a related complaint about modern consoles: They are frequently unreadable, because they just have to use all the pixels. I booted Debian (IIRC) on a laptop with a 13" 4K screen and got something like 426x135 characters. No chance for me to read them, but there sure were a lot of them. My eyes aren't the best, but I think most people would find that unreadable.<p>Defaulting to 80x25 (or anything else reasonable) in an almost infinitely ugly font would be a vast improvement.</p>
]]></description><pubDate>Wed, 17 Sep 2025 09:43:57 +0000</pubDate><link>https://news.ycombinator.com/item?id=45273730</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=45273730</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45273730</guid></item><item><title><![CDATA[New comment by drougge in "Linux Kernel Exploitation: Attack of the Vsock"]]></title><description><![CDATA[
<p>One thing that really annoys me about the HTTP standards is that some older version used to say that text/* without a declared charset was definitely latin-1 (don't remember which version exactly). Then a later version said no, text/* without a declared charset is definitely utf-8. In practice I feel this means they said "not declaring a charset is definitely not ok", but in a way that no one will understand.<p>Possibly a newer version that I haven't read fixed how they said that. As long as I don't check I can hope.</p>
]]></description><pubDate>Thu, 01 May 2025 08:36:39 +0000</pubDate><link>https://news.ycombinator.com/item?id=43855050</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=43855050</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43855050</guid></item><item><title><![CDATA[New comment by drougge in "Path Isn't Real on Linux"]]></title><description><![CDATA[
<p>Using "#!sh" at the top of the file does work, but not predictably. It may execute sh in your current directory, which is what Linux does, but your shell may override that (zsh does if the first attempt fails). So it works, but not the way you want it to.<p>And I'm sure other kernels do other things too.</p>
]]></description><pubDate>Tue, 29 Apr 2025 23:39:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=43839385</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=43839385</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43839385</guid></item><item><title><![CDATA[New comment by drougge in "Zig; what I think after months of using it"]]></title><description><![CDATA[
<p>I think it's worth pointing out that the example in the article contains a bug caused by not having shadowing: "const foo3 = try foo.addFeatureB();" should not be using the original foo, but foo2.</p>
]]></description><pubDate>Wed, 05 Feb 2025 07:17:05 +0000</pubDate><link>https://news.ycombinator.com/item?id=42945017</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=42945017</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42945017</guid></item><item><title><![CDATA[New comment by drougge in "Show HN: Interactive systemd – a better way to work with systemd units"]]></title><description><![CDATA[
<p>I have now found the documentation for ExecStop (in systemd.service(5)), which hopefully improves my understanding.<p>It definitely seems to be both "cause to stop" and "after (unexpected) stop" in one. You can look at $MAINPID to see which case you have. This design apparently makes sense to you, but to me and several others in this thread a service that has already stopped isn't in need of being stopped and shouldn't execute commands intended for that. (There is a separate ExecStopPost for "after stopping, for any reason".)</p>
]]></description><pubDate>Sun, 19 Jan 2025 14:22:49 +0000</pubDate><link>https://news.ycombinator.com/item?id=42757219</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=42757219</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42757219</guid></item><item><title><![CDATA[New comment by drougge in "Show HN: Interactive systemd – a better way to work with systemd units"]]></title><description><![CDATA[
<p>The name sounds like it means "this is how I want you to cause the service to stop" to me (and clearly to others as well). That would be symmetrical with ExecStart meaning "this is how I want you to cause the service to start". If it runs after the service stopped it should be called "ExecAfterStop" or something like that.</p>
]]></description><pubDate>Sun, 19 Jan 2025 03:10:17 +0000</pubDate><link>https://news.ycombinator.com/item?id=42753250</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=42753250</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42753250</guid></item><item><title><![CDATA[New comment by drougge in "I sent an Ethernet packet"]]></title><description><![CDATA[
<p>VGA is much easier to produce, and the RP2040 can do 1280x1024@60 no problem. The official examples use several clock cycles per pixel (2 IIRC, but it might be even more), but you don't have to.<p>I made half a terminal with that output, aiming for something that ran the original VT100 ROM. I never finished the emulator part, but I did write video output (including scan line emulation) for VT100 memory -> VGA. Adding SSH once the rest works should be perfectly possible. (Not bit banging ethernet at the same time, but using some external chip.)<p>I should probably put that online somewhere. Or finish it and then put it online.</p>
]]></description><pubDate>Mon, 11 Nov 2024 18:41:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=42109415</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=42109415</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42109415</guid></item><item><title><![CDATA[New comment by drougge in "TCP Puzzlers (2016)"]]></title><description><![CDATA[
<p>I have felt for a long time that this half closed state was a mistake. It fails to match naive expectations and can be hard to handle correctly even if you know about it. And as far as I can see there is no real benefit to having it. Is there some real use case for it (i.e. not just a minor convenience)?</p>
]]></description><pubDate>Sat, 24 Feb 2024 15:43:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=39492340</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=39492340</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39492340</guid></item><item><title><![CDATA[New comment by drougge in "9999999999999999.0 – 9999999999999998.0"]]></title><description><![CDATA[
<p>I consider myself an old unix person, but I use dc. Possibly to make it more confusing to anyone who looks at what I'm doing.<p>It also gives the math result here of course.<p><pre><code>  % dc
  9999999999999999.0 9999999999999998.0 - p
  1.0
  %</code></pre></p>
]]></description><pubDate>Thu, 11 Jan 2024 18:42:04 +0000</pubDate><link>https://news.ycombinator.com/item?id=38956701</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=38956701</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=38956701</guid></item><item><title><![CDATA[New comment by drougge in "Git scraping: track changes over time by scraping to a Git repository (2020)"]]></title><description><![CDATA[
<p>If you're using a somewhat modern shell there is $RANDOM which gives you a 15 bit random number. So e.g.<p><pre><code>    sleep $((RANDOM / 546))
</code></pre>
but I guess most cron jobs run with an extremely conservative shell that might not have it.</p>
]]></description><pubDate>Sat, 12 Aug 2023 14:16:42 +0000</pubDate><link>https://news.ycombinator.com/item?id=37100434</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=37100434</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=37100434</guid></item><item><title><![CDATA[New comment by drougge in "Chicago95 – Windows 95 Theme for Linux"]]></title><description><![CDATA[
<p>These modern useless scrollbars really anger me.<p>I can theme some things (unless some modern packaging tech makes the app ignore my theme), I can make the ones in Firefox usable but ugly (with widget.gtk.overlay-scrollbars.enabled and widget.non-native-theme.scrollbar.style), and so on. But I can see where we are heading. Scrollbars are one of many UI features that were too useful, so they must be destroyed.<p>I did not expect to feel so old at such a young age.</p>
]]></description><pubDate>Sun, 30 Jul 2023 15:32:01 +0000</pubDate><link>https://news.ycombinator.com/item?id=36932253</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=36932253</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=36932253</guid></item><item><title><![CDATA[New comment by drougge in "Keep stuff linkable"]]></title><description><![CDATA[
<p>His mention of Google also links to DDG, so I think it's all intentional. Possibly because the modern word for searching the internet is "to google".</p>
]]></description><pubDate>Tue, 18 Apr 2023 00:07:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=35608314</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=35608314</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=35608314</guid></item><item><title><![CDATA[New comment by drougge in "Is RAM wiped before use in another LXC container?"]]></title><description><![CDATA[
<p>I'm someone who likes to use fork() and then actually use both processes as they are, with shared copy-on-write memory. I'm happy to use it on things consuming much more than 100MB of memory. In fact that's where I like it the most. I'm probably a terrible person.<p>But what would be better? This way I can massage my data in one process, and then fork as many other processes that use this data as I like without having to serialise it to disk and and then load it again. If the data is not modified after fork it consumes much less memory (only the page tables). Usually a little is modified, consuming only a little memory extra. If all of it is modified it doesn't consume more memory than I would have otherwise (hopefully, not sure if the Linux implementation still keeps the pre-fork copy around).<p>(And no, not threads. They would share modifications, which I don't want. Also since I do this in python they would have terrible performance.)</p>
]]></description><pubDate>Wed, 05 Apr 2023 12:07:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=35452695</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=35452695</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=35452695</guid></item><item><title><![CDATA[New comment by drougge in "WezTerm is a GPU-accelerated cross-platform terminal emulator written in Rust"]]></title><description><![CDATA[
<p>Part of the problem is probably that termcap uses : as a separator between capabilities. There is \C for colon, but there are implementations that don't support it. If nothing else I know the termcap[info] command in screen doesn't.<p>That doesn't stop terminals from supporting it of course, just from saying they do.</p>
]]></description><pubDate>Mon, 13 Mar 2023 18:08:49 +0000</pubDate><link>https://news.ycombinator.com/item?id=35139880</link><dc:creator>drougge</dc:creator><comments>https://news.ycombinator.com/item?id=35139880</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=35139880</guid></item></channel></rss>