I'm not sure how we disagree. At least, I don't disagree with you. My whole comment was talking about "what" comments. "Why" comments are a very good thing to have where they're needed
That's not what I said. I said that comments can often (but not always) be replaced with good and explicit names.
This can be pushed to some extreme by making functions that only get called at a single place in the code, just for the sake of being able to give a name to the code that's inside (instead of inlining it and adding a comment that conveys the same informations as the function's signature)
It's definetly not for everyone, but for beginners/juniors it gives something objective they can aim for when trying to build good coding habits
Apart from the fact that, as another commenter said, "smells" are not "rules", I think most of these points come down to developing good habits, and ultimately save a lot of time in the long run by initially spending some time thinking about maintainability and preventing/limiting technical debt accumulation.
It's often a good idea to make the code itself very explicit through verbose function and variable names, rather than writing comments that could lead to inconsistencies between code and comments (by not updating the comments at the same time as the code) (see "Fallacious Comments" from the catalog)
They are both serialization formats that are supposed to be able to represent the same thing. Converting between these 2 formats is used in the article as a way to highlight yaml's parsing quirks (since JSON only has a single way to represent the false boolean value, it makes it clear that the no value in yaml is interpreted as a boolean false and not as the "no" string)
Anyway, I disagree with your point about YAML and JSON not being interchangeable
The problem is specifically that in't not exactly clear what's considered ambiguous. For instance, no is the same thing as false, but as evidenced in the linked post, in the context of country codes, it means "Norway" and it's not obvious that it might get interpreted as a boolean value.
It's the same thing as this famous meme about implicit type conversions in JS :
In any almost other context (where boolean values exist), strings must be delimited by quotes, eliminating the ambiguity with false as string contents and the false boolean value
I think most open-source contributions come from a tiny fraction of users who initially get involved because they want to improve the project or fix a bug for their own usage
CIDR ranges (a.b.c.d/subnet_mask) contain 2^(32-subnet_mask) IP addresses. The 1.5 I'm using controls the filter's sensitivity and can be tuned to anything between 1 and 2
Using 1 or smaller would mean that the filter gets triggered earlier for larger ranges (we want to avoid this so that a single IP can't trick you into banning a /16)
Using 2 or more would mean you tolerate more fail/IP for larger ranges, making you ban all smaller subranges before the filter gets a chance to trigger on a larger range.
This is running locally to a single f2b instance, but should work pretty much the same with aggregated logs from multiple instances
I used to get a lot of scrappers hitting my Lemmy instance, most of them using a bunch of IP ranges, some of them masquerading their user agents as a regular browser.
What's been working for me is using a custom nginx log format with a custom fail2ban filter that mets me easily block new bots once I identify some kind of signature.
For instance, one of these scrappers almost always sends requests that are around 250 bytes long, using the user agent of a legitimate browser that always sends requests that are 300 bytes or larger. I can then add a fail2ban jail that triggers on seeing this specific user agent with the wrong request size.
On top of this, I wrote a simple script that monitors my fail2ban logs and writes CIDR ranges that appear too often (the threshold is proportional to 1.5^(32-subnet_mask)). This file is then parsed by fail2ban to block whole ranges. There are some specific details I omitted regarding bantime and findtime, that ensure that a small malicious range will not be able to trick me into blocking a larger one. This has worked flawlessly to block "hostile" ranges with apparently 0 false positives for nearly a year
I've been tinkering with pmOS for a few days, trying to fix some issues with my old oneplus3t
I'm still far from being able to daily drive it (trying to launch an X server crashes the whole thing, some physical buttons are not detected, and I rely on a dirty hack to even get the onscreen tty to refresh) but it has been a really interesting learning journey.
From a quick search on my instance, I could find 3 posts that are still up, and I could also find specific comments I remembered from a post that got removed since.
That's at least 4 occurrences on Lemmy alone
I did not criticize people sharing it here, but rather Ente themselves for making vague fear-mongering claims for viral marketing purposes
What's up with this website popping in my feed for the 6th time in less than a week ?
Edit : nevermind, after digging the website for a grand total of 5 seconds, it appears to be an advertising website for Ente (which has a paid plan besides being self hostable). That's shitty marketing from them if you ask me
When looking at the CVE itself, it seems like a bug that only gets triggered on a very specific corner case that neither the client or website alone can trigger.
Of course, it's good that it gets reported and fixed, but I'm pretty sure these kind of bugs can only get caught by people randomly stumbling on them
When refactoring, it's often the "what" that changes, not the "why"