I think the issue comes from the practice of always running "git add ." from the cli. As a git gui user [1], I see exactly what files I stage, so this is a non-issue.
Also, the .gitignore file can document what files you are supposed to have in your project and where they come from
[1]: I'm currently a happy Fork user after having tried Sublime Merge, Git Kraken and lazygit.
This reads a bit like "Door locks do not survive contact with reality."
The point is not to prevent state-sponsored actors to produce fake media, but to add friction and avoid shady marketing agency and photographs from claiming their pictures are genuine.
Yeah, the target is not the cryptographic "safe forever", but a real world "safer than not having it".
If we're trying to decide whether a high profile politician has committed a crime, then yeah, C2PA on the footage isn't fully trustworthy. However, every bit of footage you get that corroborates the story raises the threshold of the attack.
If we're trying to decide whether Joe Everyman has crossed a double solid while driving his truck? C2PA is probably good enough. The chances of that footage being faked by a malicious party would be low even without C2PA, but C2PA makes them even lower.
I find the concept of having multiple types of personalities that are to love in their own ways interesting. I reminds me of the love languages classification.
Centralized package repositories like the one provided by canonical have similar limitations to the Mac App Store, you need to get your app reviewed, you need to push updates to each platform where you distribute your app and in exchange you get visibility.
I'd argue that installing and updating apps on MacOS is simpler than on Linux distros because most apps have built-in auto-updates (or you can just drag the app to the applications folder) instead of having to rely on snap / apt / insert your package manager which may a lot of outdated and unmaintained packages and apps.
I tried raylib and I love it, but I need to build a lot from scratch (like most game frameworks). But I also really dislike engines as I prefer making games with code rather than a GUI.
I am currently working on a framework/engine hybrid called vectarine [1] where I make my game with code while still enjoying niceties of an engine like hot reloading, integrated debugging, asset management etc.
You just need an Apple Developer account ($99/year), which you likely already have if you're distributing apps. Notarization itself has no per-build cost — you can notarize as many builds as you want. The process is essentially: codesign your app, zip it up, submit it to Apple's notary service via xcrun notarytool, and staple the ticket. It can be automated in CI too — this project uses a GitHub Actions workflow for it. The $99/year is really the only cost, and that's for the developer account itself, not notarization specifically.
The git seems to only contain the build of the website with no source code.
The author is probably using git to push the content to the hosting server as an rsync alternative, but there does not seem to be much leaked information, apart from the url of the private repository.
It exposed their committer email (I know its already public on the site, but still)
You can wget the whole .git folder and look through the commit history, so if at any point something had been pushed which should not have been its available
For CLI tools, the program usually only executes for a few seconds and then returns. In this context, you don't even need arena allocators or any memory management at all. You can write the tool in C with malloc and let the OS free the memory at the end without worry.
You could argue with the reasoning that C feels more practical than Zig for real-world CLI tools.
The argument provided by the author feels a bit besides the point.
Also, the .gitignore file can document what files you are supposed to have in your project and where they come from
[1]: I'm currently a happy Fork user after having tried Sublime Merge, Git Kraken and lazygit.