<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: Athas</title><link>https://news.ycombinator.com/user?id=Athas</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 12 Oct 2026 04:22:12 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=Athas" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by Athas in "WSL3 Performance is about 5-60% faster than WSL2 depending on the workload"]]></title><description><![CDATA[
<p>I don't know what "well" means, but I suspend my laptop whenever I move it around, travel, etc. I used hibernation a lot many years ago, where it worked as perfectly as I would expect.</p>
]]></description><pubDate>Sat, 10 Oct 2026 18:41:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=50035812</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=50035812</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=50035812</guid></item><item><title><![CDATA[New comment by Athas in "WSL3 Performance is about 5-60% faster than WSL2 depending on the workload"]]></title><description><![CDATA[
<p>I'm surprised to hear that about laptops. When I first switched to Linux in 2003, laptops were supposedly a somewhat iffy thing. When I got my first laptop in 2007, I had to do a bit of research, but ultimately ended up with a ThinkPad where everything worked fine, modulo the need for proprietary graphics drivers as was common at the time. Since then, I don't think I've ever stressed about whether a laptop would be properly supported. I am easily believe that maybe some things are a little better in Windows (maybe automatic firmware update, or the CPU governor), but which laptops are "not very well supported" by Linux these days?</p>
]]></description><pubDate>Sat, 10 Oct 2026 14:27:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=50033361</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=50033361</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=50033361</guid></item><item><title><![CDATA[New comment by Athas in "Parley: Federated, decentralised chat that speaks plain IRC"]]></title><description><![CDATA[
<p>I used Bitlbee until not that many earth rotations ago - it's an IRC daemon that provides bridging of various other chat protocols. It worked way better than you would expect, especially back in the day when you could use XMPP to connect to the various proprietary chat services.<p>I didn't stop using it until I stopped caring about those chat services.</p>
]]></description><pubDate>Mon, 28 Sep 2026 11:39:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=49876490</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=49876490</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49876490</guid></item><item><title><![CDATA[New comment by Athas in "Book review: Is parallel programming hard, and, if so, what can you do about it?"]]></title><description><![CDATA[
<p>I think there is a deep conceptual unlock: concurrency is about semantics, whilst parallelism is an operational property. I use this distinction a lot in my own work. Concurrent programming primitives are inherently non-deterministic (and usually about handling non-deterministic events), on top of which we must then establish some kind of properties (sometimes determinism to some extent). Many interesting parallel operations are however completely deterministic, and the fact that they are parallel is a property of their assigned cost model (and hopefully implementation, in practice).<p>I agree that this distinction is hardly universal, but it seems to be growing increasingly established, and I think it is worth fighting for it.</p>
]]></description><pubDate>Thu, 24 Sep 2026 20:26:44 +0000</pubDate><link>https://news.ycombinator.com/item?id=49836355</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=49836355</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49836355</guid></item><item><title><![CDATA[New comment by Athas in "Larger Pacific striped octopus"]]></title><description><![CDATA[
<p>They ask the guy who also names telescopes for the next name on the list.</p>
]]></description><pubDate>Thu, 10 Sep 2026 07:11:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=49639573</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=49639573</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49639573</guid></item><item><title><![CDATA[New comment by Athas in "Danish high schoolers will have to verbally defend written assignments"]]></title><description><![CDATA[
<p>The problem is not the total time commitment, but the flexibility of when that time can be spent. The time expenditure for a written exam (writing the exam set, testing it, correcting submissions, having a grading meeting) can be spread over many weeks, with plenty of room to move things around to take care of other responsibilities, and easy tolerance for delays. Oral exams have to be scheduled in a dense block because students are only available during designated exam weeks, and any delays have cascading effects.</p>
]]></description><pubDate>Sun, 09 Aug 2026 10:10:04 +0000</pubDate><link>https://news.ycombinator.com/item?id=49230034</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=49230034</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49230034</guid></item><item><title><![CDATA[New comment by Athas in "Danish high schoolers will have to verbally defend written assignments"]]></title><description><![CDATA[
<p>Clarification for non-Danes: this post is not entirely accurate. Not all Master's courses in Denmark have oral examinations, and many courses before the Master's level (including elementary school) have oral exams. It is unrelated to the academic level, and instead related to the academic discipline and the size of the course. The latter is in my experience the main constraint, as oral exams are difficult to scale. They usually take 20-30 minutes per student, and if you have a course with 200 students, well, you're in for a long time.<p>The oral exam format described is also somewhat unusual, in my experience. It is usually the case that there is one internal examiner and one external examiner in the room. More than that would be ruinously expensive. The format varies; usually it's a combination of a short presentation and questions asked by the examiner. Drawing a random topic is very common.<p>Source: I am a university teacher in Denmark who teaches master-level courses without oral exams, and I have been an examiner for many oral exams at university level.</p>
]]></description><pubDate>Sat, 08 Aug 2026 21:12:19 +0000</pubDate><link>https://news.ycombinator.com/item?id=49225958</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=49225958</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49225958</guid></item><item><title><![CDATA[New comment by Athas in "99% of My Website Traffic Is Bots"]]></title><description><![CDATA[
<p>I run my personal website (and a bunch of other websites and services) off a somewhat more expensive but still reasonable VPS (I think 20€ at TransIP - it's so little that I forgot). Load is basically nil most of the time anyway. I think the bot problem is not so bad for personal websites.</p>
]]></description><pubDate>Fri, 07 Aug 2026 15:18:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=49211787</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=49211787</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49211787</guid></item><item><title><![CDATA[New comment by Athas in "Microsoft Comic Chat is now open source"]]></title><description><![CDATA[
<p>One of the charming parts of IRC is just how simple it is to do things with it. Much is lost in more featureful protocols.</p>
]]></description><pubDate>Fri, 17 Jul 2026 10:47:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=48945699</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=48945699</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48945699</guid></item><item><title><![CDATA[New comment by Athas in "Microsoft Comic Chat is now open source"]]></title><description><![CDATA[
<p>Yes, I really wonder how they expected people would react to that.</p>
]]></description><pubDate>Thu, 16 Jul 2026 20:20:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=48939697</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=48939697</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48939697</guid></item><item><title><![CDATA[New comment by Athas in "Microsoft Comic Chat is now open source"]]></title><description><![CDATA[
<p>Comic Chat is a piece of Internet history, but I remember that it was somewhat reviled when I first started being active on IRC. This was around 2002, so it was probably due to some cultural memory rather than anyone having actually used it in years.<p>The issue, as I remember it, is that Comic Chat extended the IRC protocol with support for explicitly indicating the appearance and emoting of your comic character, rather than relying entirely on contextual cues. This was essentially done by adding some nonsense string to every message, which presumably could be decoded by other Comic Chat users, but read like spammy noise to everyone else. I <i>know</i> it did that, because I remember downloading Comic Chat to check it out, but I forget whether it was the default or not.</p>
]]></description><pubDate>Thu, 16 Jul 2026 16:49:04 +0000</pubDate><link>https://news.ycombinator.com/item?id=48936972</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=48936972</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48936972</guid></item><item><title><![CDATA[New comment by Athas in "What happens when you run a CUDA kernel?"]]></title><description><![CDATA[
<p>I have never used Qualcomm's OpenCL driver, but it is not unknown to get the NVIDIA driver into a state where some kernel is stuck in a running state, or some memory is allocated long after the originating process has terminated. This is usually down to application bugs, sure - but no application bug should be able to wedge the driver. While developing GPU kernels, the code will certainly be buggy, and hence the driver should be robust. For that matter, maybe I am running untrusted GPU code, and anytime the driver gets in a weird or stuck state, I am uneasy that it might not be many steps away from an exploitable situation. We don't accept this in CPU operating systems, so why should it be acceptable for GPUs? We are talking <i>unprivileged</i> code - nothing runs as root. Ever since I first got into GPGPU programming (about 2012), I noticed that they were far less robust in the face of buggy code than I was accustomed to.<p>It is also common in my experience for buggy GPU code to crash displays if the GPU is simultaneously used to drive a monitor. This usually happens for kernels that go into infinite loops, or out-of-memory conditions.<p>It is my understanding that modern GPU drivers even have watchdog systems that notice when they get stuck and forcibly reboot them, which to me is mere symptom treatment.</p>
]]></description><pubDate>Mon, 29 Jun 2026 22:34:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=48726225</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=48726225</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48726225</guid></item><item><title><![CDATA[Parallel Parentheses Matching]]></title><description><![CDATA[
<p>Article URL: <a href="https://williamdue.github.io/blog/parallel-parentheses-matching">https://williamdue.github.io/blog/parallel-parentheses-matching</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=48678623">https://news.ycombinator.com/item?id=48678623</a></p>
<p>Points: 124</p>
<p># Comments: 17</p>
]]></description><pubDate>Thu, 25 Jun 2026 20:12:24 +0000</pubDate><link>https://williamdue.github.io/blog/parallel-parentheses-matching</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=48678623</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48678623</guid></item><item><title><![CDATA[New comment by Athas in "Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28"]]></title><description><![CDATA[
<p>Yes, this also stood out to me. I usually think of CPUs and memory having parity in the early 80s, but I never bothered to check for sure. I do remember some early computer architects writing about memory being faster than the CPU!</p>
]]></description><pubDate>Fri, 19 Jun 2026 08:57:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=48596425</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=48596425</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48596425</guid></item><item><title><![CDATA[New comment by Athas in "Accelerate – Embedded language for high-performance array computations"]]></title><description><![CDATA[
<p>I wrote a bit about this some years ago: <a href="https://futhark-lang.org/blog/2020-05-03-higher-order-parallel-programming.html" rel="nofollow">https://futhark-lang.org/blog/2020-05-03-higher-order-parall...</a> - but note that Jax isn't subject to these constraints; it's more like Accelerate and Futhark.<p>I'm not a Jax expert. Accelerate's 'map' allows for almost arbitrary sequential code - there is some fine print, because it's an embedded language, and the biggest fine print is that nested parallelism is not allowed. You can define your own Haskell-level higher order functions, and Accelerate will handle them just fine, because essentially all the Haskell-level computation is "compiled away" (by being run) before the Accelerate code is JIT-compiled at run-time. You can consider Haskell to be a meta-language in which you ultimately construct Accelerate program terms, and then <i>those</i> are compiled and run - not too dissimilar from how Jax does it, actually.<p>Recursion works, but for an uninteresting reason: the recursion is on the Haskell side, and will essentially be unrolled before Accelerate gets its hand on it. This allows you to do some fun things (like partially evaluating a ray tracer on its scene description), but it's often not what you want, and Accelerate provides some combinators (that look like higher-order Haskell functions) for expressing sequential looping.</p>
]]></description><pubDate>Sat, 16 May 2026 17:13:53 +0000</pubDate><link>https://news.ycombinator.com/item?id=48162004</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=48162004</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48162004</guid></item><item><title><![CDATA[New comment by Athas in "Accelerate – Embedded language for high-performance array computations"]]></title><description><![CDATA[
<p>One big difference compared to NumPy (which you may or may not care about depending on how picky you are), is that Accelerate is a higher-order programming model. Basically, you can have 'map' (with a user-provided function), and it will go fast, in contrast to NumPy's model where only first-order operations go fast.</p>
]]></description><pubDate>Sat, 16 May 2026 16:30:08 +0000</pubDate><link>https://news.ycombinator.com/item?id=48161619</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=48161619</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48161619</guid></item><item><title><![CDATA[New comment by Athas in "Accelerate"]]></title><description><![CDATA[
<p>Making Haskell programs go faster. I will say that Accelerate is in most cases not faster than similar libraries for other languages (e.g. Jax), but the integration with normal Haskell is very pleasant. As Haskell is a very nice and practical language for general-purpose programming, it's convenient to be able to use Accelerate for those parts where numerical performance is critical (but not so critical that you rewrite the entire program in CUDA or C).</p>
]]></description><pubDate>Sat, 16 May 2026 16:27:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=48161597</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=48161597</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48161597</guid></item><item><title><![CDATA[New comment by Athas in "Incident with Issues and Webhooks – Resolved"]]></title><description><![CDATA[
<p>> Isn't the data they capture so valuable that they (Microsoft) are happy to eat the cost?<p>Even if that is true, unless the value of the data corresponds to near-term revenue, then eventually the cost may simply not be possible to meet. Or for that matter, the capital to manage the increasing load may simply not exist - it does not matter how much valuable data you have, if the supply of hardware cannot keep up with your demand.<p>Also, I suspect that most of the "data" obtained by the incessant hammering on GitHub is not very valuable. Most business code is routine, and getting Copilot to help out with generating enormous amounts of it may not contribute much in return.</p>
]]></description><pubDate>Mon, 04 May 2026 16:21:52 +0000</pubDate><link>https://news.ycombinator.com/item?id=48010779</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=48010779</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48010779</guid></item><item><title><![CDATA[New comment by Athas in "What Is in Road Flares?"]]></title><description><![CDATA[
<p>This page reads like an exasperated response to constant discussions and requests for how to extract strontium nitrate from road flares, and emphasizes that it is hard and pointless in the first place. I never noticed such discussions, but maybe it's outside of my bubble! Quite an amusing read nonetheless.</p>
]]></description><pubDate>Wed, 15 Apr 2026 09:26:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=47776686</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=47776686</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47776686</guid></item><item><title><![CDATA[New comment by Athas in "I love the work of the ArchWiki maintainers"]]></title><description><![CDATA[
<p>As others have mentioned, such tools exist. However, I believe they do more harm than help. Good --help output does not make for good --man output. In particular, while man pages are terse, good ones are more than just lists of command line options, and the part of them that are a list of command line options will usually have more detail than --help. The writing of documentation is a place where I often see programmers employ automation inappropriately.</p>
]]></description><pubDate>Sun, 15 Feb 2026 15:58:19 +0000</pubDate><link>https://news.ycombinator.com/item?id=47024723</link><dc:creator>Athas</dc:creator><comments>https://news.ycombinator.com/item?id=47024723</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47024723</guid></item></channel></rss>