GabrielTFS

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)

Oh oops, my apologies :(

Sad news. I wonder if his projects (e.g. dietlibc) will continue development or not...

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.

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.:

- https://en.wikipedia.org/wiki/Barack_Obama_tan_suit_controve...

- https://en.wikipedia.org/wiki/Let%27s_Go_Brandon

- https://en.wikipedia.org/wiki/I_Did_That!

- https://en.wikipedia.org/wiki/2023_White_House_cocaine_incid...

- https://en.wikipedia.org/wiki/Township_High_School_District_...

- https://en.wikipedia.org/wiki/Code_name_Geronimo_controversy

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).

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.

#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

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.

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)

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)

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) ?

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.

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.

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.

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).

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 much worse 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.

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.

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.

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)

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 ?

Empirical evidence appears to show that it is ¯\_(ツ)_/¯

Do you find no one at all being able to access the bug tracker to be preferable to "getting delays and errors" ?

I would guess a significant portion of people using the style (if not most), did so inspired by Windows, though

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 *why* Red Hat would do that.

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 ?

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 https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86... (if you have AVX512), https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86... (if you have AVX2 and not AVX512) or https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86... (if you have neither AVX2 nor AVX512 - rather rare these days)

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

SEGA seems to always have been a lot more generous with this kind of thing... Much of the disassembly or decompilation projects I've seen come out of old SEGA games include all the assets with them (e.g. look up disassemblies for the Genesis games), and ROM hacks are typically distributed as full ROMs - I've basically never seen SEGA use the DMCA against any disassemblies/decompilations/ROM hacks.

git clean refuses to work ?

Well, not on MacOS, I imagine (you tell me which repository/mailing list they should send a PR to :p). Really Windows and MacOS seem like the places where a malloc replacement is generally quite useful (Windows is a particularly big offender in this regard, Windows malloc is abysmal - MacOS less so iirc but still pretty bad) - it's glibc that's somewhat of an outlier by being generally pretty good.

The receipts still aren't there, even though they had said they'd be up there before Valentine's Day (now they just say "coming over the weekend", I wonder if they'll make that deadline or have to update the text again...).

Transparency would have been most important before they started randomly cancelling contracts, but it seems they didn't bother.

To my knowledge, out-of-tree drivers are quite inconvenient to maintain compared to in-tree drivers, due to the kernel's unstable API (a driver that works on a given version of the kernel likely only works on that single version unless it has lots of ifdefs to handle all the other versions).

Well, the explicit demands of the 1958 coup was to put him in place, and in that sense it did succeed - now, whether or not he participated in the planning of it is basically a mystery, but it does seem plausible (even though there is, to my knowledge, no proof of this) simply on the basis that he was the direct beneficiary of it.

Additionally, during the 1958 coup itself he did basically give his support for it in the sense that he explicitly said he was "ready to assume the powers of the republic" if asked for (which is what the leaders of the coup demanded be done).

What is "CRA" referring to here ? I can't find any reference to what that acronym means when looking it up...

A world where people on HN are statistically extremely likely to be at least in the top 5% of the population in terms of skill at using a computer.

See also https://xkcd.com/2501/

What's the distinction, then ? I can't imagine a company can set precedent to their liking on basically any issue by suing someone who has a vague relation to that issue and doesn't have to money to fight back to get them to sign up to some random settlement that says "the company is right, please set a precedent on this issue. - person who didn't have the money to fight back", right ?

People have a license under the GPL to redistribute Yuzu, and the devs know this - I don't think a settlement can compel them to commit perjury (which is what they would be doing if they knowingly lied in a DMCA takedown)