Since ELIZA, the more we try to apply the Turing Test, the more evidence we get that the Turing Test about human gullibility, rather than saying anything meaningful about the machine [1,2]. Surprisingly it turns out that even critical thinker Richard Dawkins is quite gullible.
It has nothing to so with NTFS, but all with the Win32 API. The Windows kernel supports this file model, proven by WSL1. There is a blog post somewhere (Old New Thing?) stating the engineers would like to e.g. allow deleting a file even if there is still a program with with a file handle to it, but are concerned deviation from current behavior would cause more problems than it solves.
The reason that they want a reboot is that they do not want to support a system using two versions of the same library at the same time, let's say ntdll. So they would have to close any program using that library before programs that use the new version can be started. That is equivalent to a reboot.
And I completely understand the reason. For a long time when Firefox would update on Linux, the browser windows still open were broken; it opened resources meant for the updated Firefox with the processes runnung the non-updated Firefox. The Chrome developers mentioned [2] that the "proper" solution would be to open every file at start and pass that file descriptor to the subprocesses so all of them are using the same version of the file. Needless to say, resource usage would go up.
> This ticket is rather long and has a lot of irrelevant content regarding this new topic. If I need to bring in a colleague I do not want them to have to wade through all the irrelevant context. If you would like, please open a new issue with regards to how we support middlebox compatibility.
The author turns this into:
> The GitHub issue comment left at the end leads me to believe that they aren't really interested in RFC compliance. There isn't a middleground here or a "different way" of implementing middlebox compatibility. It's either RFC compliant or not. And they're not.
This is a bad-faith interpretation of the maintainer's response. They only asked to open a new, more specific issue report. The maintainer always answered within minutes, which I find quite impressive (even after the author ghosted for months). The author consumed the maintainer's time and shouldn't get the blame for the author's problems.
It doesn't matter whether OSS is American (in whatever sense) -- anything that is America-specific (e.g. server addresses) can be patched for a localized European version. The different commercial model does matter: American law does not apply (Cloud Act, National Security Letters, ...)
Live tiles are nearly universally praised in retrospect, but it might be a case of hindsight bias [1]. The video [2] brings up some problems of the concept and why no other company copied the concept.
The patent expired, but the minifigs is also a EU 3D trademark. This is not possible for the brick which (only) serves a technical function, namely to hold on each other. Trademarks do not expire while in use. Another example for a 3D trademark, also in this US, is the Coca Cola bottle.
From the GitHub issue it becomes clear that blocking happens by the EasyPrivacy blocklist. The blocked URL youtube.com/api/stats/atr is/can also be used for tracking users, this is why some are arguing that it legitimately on that blocklist.
The tracking not malicious. YouTube has a legitimate interest to verify views, e.g. to recommend popular videos to others. If a view counter was increased by just invoking an API, view counts could be manipulated easily. Also see the video [1] from ... 13 years ago ... so it might be slighly outdated. Just slightly.
Please don't downvote comments only because you don't like their opinion (reply to them instead). It cannot be that the same opinion is valueable when someone famous write it [1].
Autotools are not backwards-compatible. Often only a specific version of autotools works. Only the generated configure is supposed to be portable.
It's also not the distribution model for an Autotools project. Project distributions would include a handwritten configure file that users would run: The usual `./configure && make && make install`. Since those configure scripts became more and more complex for supporting diverse combinations of compiler and OS, the idea of autotools was for maintainers to generate it. It was not meant to be executed by the user: https://en.wikipedia.org/wiki/GNU_Autotools#Usage
[1] https://medium.com/@innovariart/the-turing-test-no-longer-me...
[2] https://arxiv.org/abs/2405.08007