<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: ablob</title><link>https://news.ycombinator.com/user?id=ablob</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 15 Jun 2026 12:36:31 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=ablob" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by ablob in "Your ePub Is fine"]]></title><description><![CDATA[
<p>The lovecraftian horror of pdf mostly comes into play through the sheer amount of software that supply almost correct pdf. It's not enough to be able to read pdf anymore, you also have to be able to deal with software that emits subtly wrong documents.</p>
]]></description><pubDate>Sun, 14 Jun 2026 23:54:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=48534477</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=48534477</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48534477</guid></item><item><title><![CDATA[New comment by ablob in "Not everyone is using AI for everything"]]></title><description><![CDATA[
<p>I'd like to add that there is almost no way of "running away" from it.
If I search for anything on the internet I am almost guaranteed to be handed pages and pages of AI generated content.
In lieu of that I found that directly prompting for an answer tends to yield better results nowadays. Not because it's good per-se, but because having control over the prompt beats having little to no control over it though search by proxy.<p>It saddens me to see that high quality content is drowned in this sea of garbage to the point of being almost impossible to find.</p>
]]></description><pubDate>Sun, 14 Jun 2026 15:57:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=48528674</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=48528674</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48528674</guid></item><item><title><![CDATA[New comment by ablob in "Software Is Made Between Commits"]]></title><description><![CDATA[
<p>I personally stumble upon many topics where I only care about the what.
In that case all the theory is just a distraction I'm just wading through to get to the point.
If it's optional, then looking into the how and why is certainly nice, but it should be part of an appendix or a commentary and not interspersed within the proof unless an uncommented version exists.</p>
]]></description><pubDate>Thu, 11 Jun 2026 19:49:31 +0000</pubDate><link>https://news.ycombinator.com/item?id=48495514</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=48495514</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48495514</guid></item><item><title><![CDATA[New comment by ablob in "Why are cells small?"]]></title><description><![CDATA[
<p>I feel like keeping the amount of molecules the same within the simulation needs to be justified.
How would it look like if the average amount of molecule was the same across a um?</p>
]]></description><pubDate>Mon, 08 Jun 2026 21:45:44 +0000</pubDate><link>https://news.ycombinator.com/item?id=48452648</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=48452648</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48452648</guid></item><item><title><![CDATA[New comment by ablob in "IPv6 zones in URLs are a mistake"]]></title><description><![CDATA[
<p>Isn't this just an issue with rsync? (or rather your ancient version of it)
I think you'd run into the same issues when using an IPv4 address port combination.
It was rsync's choice to use colon as an indicator in lieu of IPv6's existence.
You'd be complaining all the same for other separator choices if rsync just happened to pick the same one.<p>Nonetheless I do agree that the choice of colons isn't great due to how it ambiguates their meaning.</p>
]]></description><pubDate>Thu, 04 Jun 2026 23:35:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=48406119</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=48406119</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48406119</guid></item><item><title><![CDATA[New comment by ablob in "Every Byte Matters"]]></title><description><![CDATA[
<p>Two fields should be fine, actually.
The way caches are organized you are very unlikely to thrash with the lookups (due to n-way associativity) while only keeping relevant data in the cache at the same time.
You still have roughly the following layout (in the cache), where A is the field and V is valid:<p><pre><code>  | A1 A2 A3 A4 | A5 A6 A7 A8 | ...
  | V1 V2 V3 V4 | V5 V6 V7 V8 | ...
</code></pre>
The former access pattern still yields a clean cache layout where no unnecessary data is loaded (which is the most costly operation here by far) as opposed to<p><pre><code>  | A1 V1 B1 C1 | ... | A2 V2 B2 C2  | ...
</code></pre>
In the general case there will exist a number of fields for which SOA layout will be worse if all are accessed close to each other, but for just a validity indicator this should not be the case. I think your statement is not wrong, but also not 100% correct.<p>This is on par to linear search being faster than binary search for small n. As soon as caches and branch prediction chime in many rules of thumb just change. Most importantly, however, is that a distinction between small and large n basically _needs_ to happen at that point.</p>
]]></description><pubDate>Wed, 03 Jun 2026 18:59:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=48388285</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=48388285</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48388285</guid></item><item><title><![CDATA[New comment by ablob in "Please Do Not Vibe Fuck Up This Software"]]></title><description><![CDATA[
<p>According to the thread rsync broke for incremental backups and increases the cpu load heavily. The whole thread only started because people noticed regressions and were wondering what happened.<p>Since I quite a few users are using distros that won't update for a while it gets even better: this trend may continue and as soon as the update actually happens we'll be so far down the road that it will be too late to take a step back and reconsider due to the delayed feedback.
This is pretty much about the few people _already_ having issues with it.<p>That being said, if the creator wants to use AI to work on the project they are free to do so. I just hope nothing of value is lost because of it.<p>P.S.: If you stop writing by hand and start delegating - to AI or other people - something has changed. There shouldn't be any discussion about it. Delegation is different than writing it yourself.</p>
]]></description><pubDate>Sun, 31 May 2026 09:49:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=48344344</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=48344344</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48344344</guid></item><item><title><![CDATA[New comment by ablob in "Everything in C is undefined behavior"]]></title><description><![CDATA[
<p>If we're talking two's complement it's not undefined that is right.
Having to emit checks though, that is where I beg to differ.
A check is only useful if you want to actually change the behavior when it happens, otherwise it is useless.
Furthermore, it might be "essentially free" from a branch prediction point, but low and behold caches exist.
You would pollute both the instruction cache with those instructions _and_ the branch prediction cache.
From this it doesn't follow at all, that there is no cost.<p>In the end small things do add up, and if you're adding many little things "because it doesn't cost much nowadays" you will end up with slow software and not have one specific bottleneck to look at.
I do agree that having the option for checked operations is nice (see C#), but I have needed this behavior (branching on overflow) exactly once so far.</p>
]]></description><pubDate>Wed, 20 May 2026 11:22:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=48205991</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=48205991</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48205991</guid></item><item><title><![CDATA[New comment by ablob in "Bill to block publishers from killing online games advances in California"]]></title><description><![CDATA[
<p>Somehow I highly doubt that a small game company is going to run a "huge network of interconnected cloud services".
I've also yet to find a small game company running their own big online multiplayer game.</p>
]]></description><pubDate>Fri, 15 May 2026 21:40:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=48154273</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=48154273</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48154273</guid></item><item><title><![CDATA[New comment by ablob in "Windows API is Successful Cross-Platform API (2024)"]]></title><description><![CDATA[
<p>http3 operates on a different OSI layer</p>
]]></description><pubDate>Sun, 03 May 2026 04:57:20 +0000</pubDate><link>https://news.ycombinator.com/item?id=47993482</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=47993482</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47993482</guid></item><item><title><![CDATA[New comment by ablob in "Dear friend, you have built a Kubernetes (2024)"]]></title><description><![CDATA[
<p>I just feel like "you can do this with Kubernetes" is a slippery slope.
"You can do X with Y, so use Y" is a great way to add a dependency, especially if it is "community vetted" already.
Sometimes simple is better - you don't need to add anything that implements some of you logic as a dependency to stay DRY or whatever you want to call it.<p>It really feels like we are drowning in self-imposed tech debt and keep adding layers to try and hold it for just a while longer.
Now that being said, there is no reason not to add Kubernetes once a sufficient overlap is achieved.</p>
]]></description><pubDate>Sun, 26 Apr 2026 18:14:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=47912504</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=47912504</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47912504</guid></item><item><title><![CDATA[New comment by ablob in "Reflections on 30 years of HPC programming"]]></title><description><![CDATA[
<p>afaik, you always have to break open abstractions for more performance.
If you ignore cache-levels in your program you're gonna have a bad time - and depending on the system the layout (and with it how you should use it) is different.
The same is true for how machines are interconnected.
Depending on the wiring you have different throughput-values when sharing data between nodes.
The whole area screams "not universal" to me.</p>
]]></description><pubDate>Fri, 17 Apr 2026 22:38:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=47811329</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=47811329</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47811329</guid></item><item><title><![CDATA[New comment by ablob in "Reflections on 30 years of HPC programming"]]></title><description><![CDATA[
<p>So what would be such an HPC language that you're so fond of?
A quick web search reveals only languages that use C++/CUDA code as a back end (python), are new and experimental (Julia) or FORTRAN.
For what you're talking about none seem all to good, so you've peaked my curiosity.</p>
]]></description><pubDate>Fri, 17 Apr 2026 22:30:46 +0000</pubDate><link>https://news.ycombinator.com/item?id=47811285</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=47811285</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47811285</guid></item><item><title><![CDATA[New comment by ablob in "Reflections on 30 years of HPC programming"]]></title><description><![CDATA[
<p>C++ by comparison doesn't stand in your way too much either.
I feel like the biggest gripe Rust has is what happens when you do have to go unsafe.
That seems to be a strong point of contention for many folks.
Maybe all the reasons that lead people to use unsafe rust go away or the attitude about it shifts in some manner.<p>For me Rust turned out to be less interesting after I saw the whole ceremony about typing.
The amount of things I had to grasp just to get a glimpse into what a library does felt much more involved than any of the things I did with C++.
The whole annotation-ting feels much less necessary and more like a proper opt-in there.</p>
]]></description><pubDate>Fri, 17 Apr 2026 22:19:52 +0000</pubDate><link>https://news.ycombinator.com/item?id=47811209</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=47811209</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47811209</guid></item><item><title><![CDATA[New comment by ablob in "Scan your website to see how ready it is for AI agents"]]></title><description><![CDATA[
<p>Anything that increases the entry time by a second or more is a pretty good way to make me (and probably others) just not bother with opening the website.</p>
]]></description><pubDate>Fri, 17 Apr 2026 17:19:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=47808275</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=47808275</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47808275</guid></item><item><title><![CDATA[New comment by ablob in "Want to write a compiler? Just read these two papers (2008)"]]></title><description><![CDATA[
<p>I think his point is that "form follows function".
If you know what kind of semantics you're going to have, you can use that to construct a syntax that lends itself to using it properly.</p>
]]></description><pubDate>Wed, 15 Apr 2026 16:47:44 +0000</pubDate><link>https://news.ycombinator.com/item?id=47781710</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=47781710</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47781710</guid></item><item><title><![CDATA[New comment by ablob in "Want to write a compiler? Just read these two papers (2008)"]]></title><description><![CDATA[
<p>I guess "back in the day" you had to be able to write an efficient parser, as no parser generators existed. If you couldn't implement whatever you wanted due to memory shortage  at the parser level, then obviously it's gonna be a huge topic.
Even now I believe it is good to know about this - if only to avoid pitfalls in your own grammar.<p>I repeatedly skip parts that are not important to me when reading books like this.
I grabbed a book about embedded design and skipped about half of it, which was bus protocols, as I knew I wouldn't need it.
There is no need to read the dragon book from front to back.<p><pre><code>  > But there's a reason most modern resources skip over all of that and just make the reader write a recursive descent parser.
</code></pre>
Unless the reason is explicitly stated there is no way to verify it's any good.
There's a reason people use AI to write do their homework - it just doesn't mean it's a good one.
I can think of plenty arguments for why you wouldn't look into the pros and cons of different parsing strategies in an introduction to compilers, "everyone is(or isn't) doing it" does not belong to them.
In the end, it has to be written down somewhere, and if no other book is doing it for whatever reason, then the dragon book it shall be. You can always recommend skipping that part if someone asks about what book to use.</p>
]]></description><pubDate>Wed, 15 Apr 2026 16:43:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=47781653</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=47781653</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47781653</guid></item><item><title><![CDATA[New comment by ablob in "Do you even need a database?"]]></title><description><![CDATA[
<p>So you trade the overhead of SQL with the overhead of JSON?</p>
]]></description><pubDate>Wed, 15 Apr 2026 16:20:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=47781292</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=47781292</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47781292</guid></item><item><title><![CDATA[New comment by ablob in "Someone bought 30 WordPress plugins and planted a backdoor in all of them"]]></title><description><![CDATA[
<p>The question was not if it was possible within price boundary X, but if it was possible at all.
There is a difference, please don't confound possibility with feasibility.</p>
]]></description><pubDate>Mon, 13 Apr 2026 23:17:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=47759221</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=47759221</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47759221</guid></item><item><title><![CDATA[New comment by ablob in "C# in Unity 2026: Writing more modern code"]]></title><description><![CDATA[
<p>C# has had the reputation of not being viable for Linux for a long time.
Therefore, the people already on Linux didn't have a reason to use it or even try it.
If you're already doing stuff in other languages it's hardly worth it to switch to C#.<p>I personally use it quite a lot - but I came as a windows user writing all my utilities in C#.
Also, afaik C# is mostly used in corporate environments that don't open-source their projects. You're unlikely to hear from it unless you're working on it for this very reason.</p>
]]></description><pubDate>Thu, 09 Apr 2026 12:00:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=47702529</link><dc:creator>ablob</dc:creator><comments>https://news.ycombinator.com/item?id=47702529</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47702529</guid></item></channel></rss>