But the data itself can and does lead to tracking.
I'm not sure how to express it any clearer: anonimized info, by definition and by design, does not and cannot lead to tracking.
Does Amazon pay well enough to justify staying there?
That's hard to tell, because everyone tends to stick with the best job they could have.
Anonymized data as a concept has always been a joke. With enough data points, the origin can usually be traced.
The design goal of anonimized data is that it is processed to explicitly disallow tracing. This means not only removing personally identifiable information but also disallow session data.
He is completely right in this context, not all European countries have the same workers right as Germany.
I understand that this isn't an academic discussion on logic, but it's also not correct to claim that Europe doesn't have basic worker's rights because there might be a country or two in the dozens of countries that make up Europe that might not have explicitly prohibit a specific form of abuse.
This article seems to be well-meaning but contrasts with the de-facto standard way of storing dotfiles. The Linux Filesystem Hierarchy Standard is quite unambiguous in how it specifies that the purpose of $HOME is to store dotfiles.
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s08.html
FHS also specifies that applications can store their dotfiles in subdirectories, and this is leveraged by other standards like the Freedesktop's xdg-user-dirs spec to default to ~/.config
https://www.freedesktop.org/wiki/Software/xdg-user-dirs/
I'm not sure what's the point of arguing against the standard way of storing dotfiles while basing the remarks on no standard or reference.
At that volume of communication, the Github workflow of “clicking through stuff” is way inferior to an efficient email workflow. Essentially, your workflow turns into email anyways because its the only sane way to consume based on push (...)
I don't agree. Any conversation on pull requests happens through issues/tickets, which already aggregate all related events and are trivially referenced through their permanent links, including through the Git repo's history.
So you want me to invest my time (...)
I don't want you to do anything, but I'm not the one wasting my time complaining over how others contribute to FLOSS projects. If you feel entitled to complain about other people's contributions, in the very least you need to put your money where your mouth is.
I’m sorry, which of those recent commits aren’t things a single linter run would catch?
Ask yourself why the code still had those typos, and why nobody did anything about it except the guy contributing code cleanup commits.
I feel like the takeaway here should be that the experience of contributing to the project was not great. That’s it.
I don't think this is a valid summary. I think the first-time contributor had a rather self-centered approach to the bugfix, and turned a run-of-the-mill bugfix in a huge drama-riddled personal attack on a FLOSS maintainer for no good reason.
Only in the OP's one-sided and vindictive account of the whole ordeal does the project maintainer have questionable behavior. The central theme of the one-sided account is also absurd, as if a kernel maintainer needs to wait around for first-timers to contribute a patch for them to "rob" it to have a commit to show for.
The whole soap opera is so regrettable, and the OP comes out not looking good at all.
I think it would be beneficial for their community to take the wish for more credit more serious and try to make him feel welcome.
I think they did. Apparently the maintainer trusted the first-time contributor enough to propose tackling another bug.
If the goal is to get more contributions, I think that's exactly what should happen. I feel the kernel maintainer is being treated unfairly.
Whining about getting extra work feels like the author didn't intended to contribute anything else and just put all this reputation chips on that one isolated ticket.
The commit history I looked through has multiple commits for something that should realistically be a single “linted the project” commit. It’s valid criticism in this case.
I don't agree. The trunk features multiple typo fixes and whatnot, but they are days apart and spread over weeks on end.
If anything, this shows that no one is contributing to the project, and people like the blogger wasted more effort writing posts on how no one is doing anything while they themselves do nothing at all, and to make matters worse they criticise the ones actually contributing something.
If the blogger really feels strongly about this, he should put their money where their mouth is and lead by example.
That's basically what $HOME is is used for in UNIX: a place for applications to store user-specific files, including user data and user files.
https://www.linfo.org/home_directory.html
UNIX, and afterwards Unix-like OSes, were designed as multi-user operating systems that supported individual user accounts. Each user needs to store it's data, and there's a convenient place to store it: it's $HOME directory. That's how things have been designed and have been working for close to half a century.
Some newer specs such as Freedesktop's directory specification build upon the UNIX standard and Unix-like tradition, but the truth of the matter is that there aren't that many reasons to break away from this practice.