<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: GabrielTFS</title><link>https://news.ycombinator.com/user?id=GabrielTFS</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sat, 04 Jul 2026 13:53:57 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=GabrielTFS" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by GabrielTFS in "Linux eliminates the strncpy API after six years of work, 360 patches"]]></title><description><![CDATA[
<p>The issue with strncpy is that it doesn't actually necessarily terminate - in fact in any case where the source is larger than the destination it will just leave it unterminated (like, it will copy the last character it can from the source instead of terminating the destination string with a NUL)</p>
]]></description><pubDate>Sun, 21 Jun 2026 11:53:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=48618110</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=48618110</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48618110</guid></item><item><title><![CDATA[New comment by GabrielTFS in "Felix "fx" Lindner has died"]]></title><description><![CDATA[
<p>Oh oops, my apologies :(</p>
]]></description><pubDate>Mon, 09 Mar 2026 22:14:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=47316377</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=47316377</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47316377</guid></item><item><title><![CDATA[New comment by GabrielTFS in "Felix "fx" Lindner has died"]]></title><description><![CDATA[
<p>Sad news. I wonder if his projects (e.g. dietlibc) will continue development or not...</p>
]]></description><pubDate>Mon, 02 Mar 2026 19:57:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=47223247</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=47223247</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47223247</guid></item><item><title><![CDATA[New comment by GabrielTFS in "25 Years of Wikipedia"]]></title><description><![CDATA[
<p>> If this much effort were being put into writing about government policy I'd totally agree with you, but this level of detail is uncharacteristic even for Wikipedia.<p>Honestly, I think you're very much underestimating how much Wikipedia writes about government policy - but perhaps more to the point, it's trivial to find articles about controversies regarding the "other side" that are also quite well furnished, e.g.:<p>- <a href="https://en.wikipedia.org/wiki/Barack_Obama_tan_suit_controversy" rel="nofollow">https://en.wikipedia.org/wiki/Barack_Obama_tan_suit_controve...</a><p>- <a href="https://en.wikipedia.org/wiki/Let%27s_Go_Brandon" rel="nofollow">https://en.wikipedia.org/wiki/Let%27s_Go_Brandon</a><p>- <a href="https://en.wikipedia.org/wiki/I_Did_That" rel="nofollow">https://en.wikipedia.org/wiki/I_Did_That</a>!<p>- <a href="https://en.wikipedia.org/wiki/2023_White_House_cocaine_incident" rel="nofollow">https://en.wikipedia.org/wiki/2023_White_House_cocaine_incid...</a><p>- <a href="https://en.wikipedia.org/wiki/Township_High_School_District_211_transgender_student_locker_room_access_controversies" rel="nofollow">https://en.wikipedia.org/wiki/Township_High_School_District_...</a><p>- <a href="https://en.wikipedia.org/wiki/Code_name_Geronimo_controversy" rel="nofollow">https://en.wikipedia.org/wiki/Code_name_Geronimo_controversy</a><p>So I don't think there's much of an argument to say that they're being particularly biased in doing this (you might believe that none, or almost none of these articles at all should exist, but that's a different issue).</p>
]]></description><pubDate>Fri, 16 Jan 2026 17:54:51 +0000</pubDate><link>https://news.ycombinator.com/item?id=46649464</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=46649464</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46649464</guid></item><item><title><![CDATA[New comment by GabrielTFS in "Understanding the bin, sbin, usr/bin, usr/sbin split (2010)"]]></title><description><![CDATA[
<p>Moving away from Program Files would cost far more than it's worth - it'd cause lots of issue for a massive amount of users and be of very little value for others, when the only practical issue with the Steam folder being in Program Files right now is people going "oh I didn't expect that directory to be writable I guess" which is not something worth spending a bunch of time orchestrating a massive transition over.</p>
]]></description><pubDate>Sun, 04 Jan 2026 20:40:41 +0000</pubDate><link>https://news.ycombinator.com/item?id=46491949</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=46491949</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46491949</guid></item><item><title><![CDATA[New comment by GabrielTFS in "C/C++ Embedded Files (2013)"]]></title><description><![CDATA[
<p>#include also searches for the file you give it in an "implementation-defined manner", so if you have this complaint about #embed, you ought to also consider #include equally problematic</p>
]]></description><pubDate>Fri, 26 Dec 2025 19:46:56 +0000</pubDate><link>https://news.ycombinator.com/item?id=46395461</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=46395461</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46395461</guid></item><item><title><![CDATA[New comment by GabrielTFS in "Free Software Foundation receives historic private donations"]]></title><description><![CDATA[
<p>They would generally need to convert to fiat to do something useful, yes, but 501 (c) (3) nonprofits generally don't pay capital gains tax, no.</p>
]]></description><pubDate>Thu, 25 Dec 2025 17:52:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=46385927</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=46385927</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46385927</guid></item><item><title><![CDATA[New comment by GabrielTFS in "PRC elites voice AI-skepticism"]]></title><description><![CDATA[
<p>Very minor nitpick but I'd have said France went through four different monarchic systems in that time frame (1776-1790 Ancient Régime, 1791-1792 Constitutional monarchy, 1814-1830  Bourbon Restoration and 1830-1848 July Monarchy)</p>
]]></description><pubDate>Wed, 26 Nov 2025 20:52:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=46062180</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=46062180</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46062180</guid></item><item><title><![CDATA[New comment by GabrielTFS in "An official atlas of North Korea"]]></title><description><![CDATA[
<p>I don't think much of anyone thinks unification is actually possible absent some big change, and indeed neither government is truly pursuing it actively (unless "trying to destabilize and make the other government collapse" qualifies). But both are trying to be as ready as possible for unification when the opportunity presents itself (most likely, it would happen in a way alike to German reunification - that is, the government of one of the two countries becomes quite compatible with the other, because the previous form of government in it collapsed and was replaced by that of its neighbor)</p>
]]></description><pubDate>Tue, 18 Nov 2025 00:28:46 +0000</pubDate><link>https://news.ycombinator.com/item?id=45960056</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=45960056</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45960056</guid></item><item><title><![CDATA[New comment by GabrielTFS in "FFmpeg to Google: Fund us or stop sending bugs"]]></title><description><![CDATA[
<p>If Google wanted nothing more than to simply make blog posts, why wouldn't they just only report the big bugs that they can make blog posts out of (and avoid having to spend any resources on finding the rest) ?<p>I don't know if you'd be satisfied with that, but certainly this would allow them to easily make the blog posts you seem to be complaining about, all while making the load on maintainers rather minimal, at least insofar as blog posts appear to be quite infrequent compared to the total amount of vulnerabilities they report - around 20 vulnerability reports per year certainly seems like a manageable load for the entire FOSS community to bear, especially given almost none of these 20 yearly vulnerability reports would go to ffmpeg (if not literally none, given the Project Zero blog has 0 search results for "ffmpeg" or "libav"), and a significant portion of their blog posts aren't even about FOSS at all but instead about proprietary software like the operating systems Microsoft and Apple make.<p>I do think such a thing would be bad for everyone, though (including the ffmpeg developers themselves, to be honest) - Project Zero is good for everyone's security, in my opinion, and even if all FOSS developers were to universally decide to reject all Project Zero reports that don't come with a patch, and Google decided to still not make such patches, people being able to know that these vulnerabilities exist is still a good thing nonetheless - certainly much better than more vulnerabilities being left in for malicious actors to discover and use in zero-day attacks.</p>
]]></description><pubDate>Thu, 13 Nov 2025 22:43:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=45921653</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=45921653</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45921653</guid></item><item><title><![CDATA[New comment by GabrielTFS in "FFmpeg to Google: Fund us or stop sending bugs"]]></title><description><![CDATA[
<p>In practice, it doesn't matter all that much whether the software project containing the vulnerability has the resources to fix it: if a vulnerability is left in the software, undisclosed to the public, the impact to the users is all the same.<p>I, and I think most security researchers do too, believe that it would be incredibly negligent for someone who has discovered a security vulnerability to allow it to go unfixed indefinitely without even disclosing its existence. Certainly, ffmpeg developers do not owe security to their users, but security researchers consider that they have a duty to disclose them, even if they go unfixed (and I think most people would prefer to know an unfixed vulnerability exists than to get hit by a 0-day attack). There's gotta be a point where you disclose a vulnerability, the deadline can never be indefinite, otherwise you're just very likely allowing 0-day attacks to occur (in fact, I would think that if this whole thing never happened and we instead got headlines in a year saying "GOOGLE SAT ON CRITICAL VULNERABILITY INVOLVED IN MASSIVE HACK" people would consider what Google did to be far worse).<p>To be clear, I do in fact think it would be very much best if Google were to use a few millionths of a percent of their revenue to fund ffmpeg, or at least make patches for vulnerabilities. But regardless of how much you criticize the lack of patches accompanying vulnerability reports, I would find it <i>much worse</i> if Google were to instead not report or disclose the vulnerability at all, even if they did so at the request of developers saying they lacked resources to fix vulnerabilities.</p>
]]></description><pubDate>Wed, 12 Nov 2025 00:57:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=45895117</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=45895117</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45895117</guid></item><item><title><![CDATA[New comment by GabrielTFS in "FFmpeg to Google: Fund us or stop sending bugs"]]></title><description><![CDATA[
<p>Full (immediate) disclosure, where no time is given to anyone to do anything before the vulnerability is publicly disclosed, was historically the default, yes. Coordinated vulnerability disclosure (or "responsible disclosure" as many call it) only exists because the security researchers that practice it believe it is a more effective way of minimizing how much the vulnerability might be exploited before it is fixed.</p>
]]></description><pubDate>Tue, 11 Nov 2025 23:06:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=45894143</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=45894143</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45894143</guid></item><item><title><![CDATA[New comment by GabrielTFS in "FFmpeg to Google: Fund us or stop sending bugs"]]></title><description><![CDATA[
<p>A solution definitely ought to be found. Google putting up a few millionths of a percent of their revenue or so towards fixing the bugs they find in ffmpeg would be the ideal solution here, certainly. Yet it seems unlikely to actually occur.<p>I think the far more likely result of all the complaints is that Google simply completely disengages from ffmpeg and stops doing any security work on it. I think that would be quite bad for the security of the project - if Google can trivially find bugs at a high speed such that it overwhelms the ffmpeg developers, I would imagine bad actors can also search for them and find those same vulnerabilities Google is constantly finding, and if they know that those vulnerabilities very much exist, but that Google has simply stopped searching for them upon demand of the ffmpeg project, this would likely give them extremely high motivation to go looking in a place they can be almost certain they'll find unreported/unknown vulnerabilities in. The result would likely be a lot more 0-day attacks involving ffmpeg, which I do not think anyone regards as a good outcome (I would consider "Google publishes a bunch of vulnerabilities ffmpeg hasn't fixed so that everyone knows about them" to be a much preferable outcome, personally)<p>Now, you might consider that possibility fine - after all, the ffmpeg developers have no obligation to work on the project, and thus to e.g. fix any vulnerabilities in it. But if that's fine, then simply ignoring the reports Google currently makes is presumably also fine, no ?</p>
]]></description><pubDate>Tue, 11 Nov 2025 22:47:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=45893949</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=45893949</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45893949</guid></item><item><title><![CDATA[New comment by GabrielTFS in "You Don't Need Anubis"]]></title><description><![CDATA[
<p>Empirical evidence appears to show that it is ¯\_(ツ)_/¯</p>
]]></description><pubDate>Mon, 10 Nov 2025 14:11:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=45876181</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=45876181</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45876181</guid></item><item><title><![CDATA[New comment by GabrielTFS in "You Don't Need Anubis"]]></title><description><![CDATA[
<p>Do you find no one at all being able to access the bug tracker to be preferable to "getting delays and errors" ?</p>
]]></description><pubDate>Sun, 09 Nov 2025 22:22:17 +0000</pubDate><link>https://news.ycombinator.com/item?id=45869783</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=45869783</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45869783</guid></item><item><title><![CDATA[New comment by GabrielTFS in "The fix wasn't easy, or C precedence bites"]]></title><description><![CDATA[
<p>I would guess a significant portion of people using the style (if not most), did so inspired by Windows, though</p>
]]></description><pubDate>Sat, 25 Oct 2025 13:02:31 +0000</pubDate><link>https://news.ycombinator.com/item?id=45703564</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=45703564</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45703564</guid></item><item><title><![CDATA[New comment by GabrielTFS in "The X.Org Server just got forked (announcing XLibre)"]]></title><description><![CDATA[
<p>Can someone explain what's the big idea with that ? I keep seeing conspiracy theories about how Red Hat is sabotaging the Linux desktop on purpose, but I would quite honestly like to see an explanation as to *<i>why*</i> Red Hat would do that.</p>
]]></description><pubDate>Tue, 10 Jun 2025 15:58:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=44238380</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=44238380</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44238380</guid></item><item><title><![CDATA[New comment by GabrielTFS in "Mozilla Firefox – Official GitHub repo"]]></title><description><![CDATA[
<p>This seems like a poor argument. I don't like much either having the obligation to give GitHub my phone number, but it's not the same thing as a social security number, now is it ? Would you argue otherwise ?</p>
]]></description><pubDate>Tue, 13 May 2025 20:28:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=43977341</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=43977341</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43977341</guid></item><item><title><![CDATA[New comment by GabrielTFS in "Comparison of C/POSIX standard library implementations for Linux"]]></title><description><![CDATA[
<p>That's the generic implementation - it's not used on most popular architectures (I think the most popular architecture it's used on would be RISC-V or MIPS) because they all have architecture-specific implementations. The implementation running on the average (x86) computer is likely to be <a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/strlen-evex-base.S;h=8055cd04b1647fc6b9f39c0451f0f713dd1b50a0;hb=HEAD" rel="nofollow">https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86...</a> (if you have AVX512), <a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/strlen-avx2.S;h=856b93330a18365ccc47f985a81ca30dd5801606;hb=HEAD" rel="nofollow">https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86...</a> (if you have AVX2 and not AVX512) or <a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/strlen-sse2.S;h=5a70c7e90a1a80093507d5d66a4baac9d530c4c9;hb=HEAD" rel="nofollow">https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86...</a> (if you have neither AVX2 nor AVX512 - rather rare these days)</p>
]]></description><pubDate>Tue, 13 May 2025 19:03:08 +0000</pubDate><link>https://news.ycombinator.com/item?id=43976422</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=43976422</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43976422</guid></item><item><title><![CDATA[New comment by GabrielTFS in "A decompilation and port of Sonic Advance 2-a GameBoy Advance game written in C"]]></title><description><![CDATA[
<p>Sonic Advance 2 might be late enough that developers started to take that seriously, e.g. I recall hearing that earlier games like Ocarina of Time already were being developed using CVS, for instance, and another game from around that time that I specifically recall would be Pokemon Diamond & Pearl, developed in an SVN repository</p>
]]></description><pubDate>Fri, 28 Mar 2025 08:45:37 +0000</pubDate><link>https://news.ycombinator.com/item?id=43503001</link><dc:creator>GabrielTFS</dc:creator><comments>https://news.ycombinator.com/item?id=43503001</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43503001</guid></item></channel></rss>