Surprise! It's on crimeflare.
831 karma · joined April 24, 2014
Surprise! It's on crimeflare.
Or in the OPs case, installed a totally different application and was surprised by an incompatibility.
They live in ~/.cache which is defined as "user-specific non-essential (cached) data".
Despite this user's impressive résumé, they simply misunderstood the feature.
I fully recognise that it doesn't make sense for huge projects like the Linux kernel to do this. But for 99% of projects conventional commits combined with semver vastly improves the release process status quo and makes it easy to automate.
https://docs.github.com/en/authentication/managing-commit-si...
Notice that the original commit is verified: https://github.com/pedronauck/reworm/commit/df8c1803c519f599...
While the malicious one is not: https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6...
Sorry, that is incorrect: https://pkg.go.dev/slices#Clip
> It's a common newbie mistake to think they do work like that, and write "append(s, ...)" instead of "s = append(s, ...)". It might even randomly work a lot of the time.
"append(s, ...)" without the assignment doesn't even compile. So your entire post seems like a strawman?
https://go.dev/play/p/icdOMl8A9ja
> So (generalizing) Go won't implement a feature that makes mistakes harder, if it makes the language more complicated
No, I think it is more that the compromise of complicating the language that is always made when adding features is carefully weighed in Go. Less so in other languages.
The answer is that it is a fragile, unmaintainable security nightmare.
Wayland has separation of concerns to fix that problem, with the tradeoffs described in the blog post.
By contrast, the tested version of ghostty v1.2.3 is two weeks old.
I have seen so many takes lamenting how this kind of supply chain attack is such a difficult problem to fix.
No it really isn't. It's an ecosystem and cultural problem that npm encourages huge dependency trees that make it impractical to review dependency updates so developers just don't.
How is this news?
Unpatched long-lived VMs are much more cumbersome to fix than an outdated Docker image. And good luck reproducing your long-lived VM with years of mutation-via-patch.
If you have specific issues, please file them over at systemds GitHub issue tracker.
> Here's the technical takeaway: Never use CASCADE deletes on critical foreign keys. Set them to NULL or use soft deletes instead. It's fine for UPDATE operations, but it's too dangerous for DELETE ones. The convenience of automatic cleanup isn't worth the existential risk of chain reactions.
What? The point of cascading foreign keys is referential integrity. If you just leave dangling references everywhere your data will either be horribly dirty or require inconsistent manual cleanup.
As I'm sure others have said: just use a test/staging environment. It isn't hard to set up even if you are in startup mode.