Everything else I've open-sourced has gone pretty well, comparatively.
But I also find the psychology behind this sort of reply interesting, because there's lots of factors that lead to this sort of extreme.
Firstly, we don't know the age of the replier, but my guess would be someone also young, or at least immature. Telling people to kill themselves is not something adults typically do in any context.)
So it suggests another junior, desperate to prove their own standing, and needing to compete against others rather than collaborate. I've seen this kind of response in one adult (abusive to other forum members) but he clearly had quite severe mental health issues (and the user was banned.) In youngsters it is usually extinguished with firm moderator guidance.
With adult responders, frustration and tedium play a role. Personally I'm more generous with replies in the morning than the evening. At times I almost "fake" patience (when I'm getting impatient) with people who are simply not thinking, and who aren't listening.
Overall it is very imbalanced. The asker is asking 1 question. The replier may answer tens or hundreds in a day. So it's hard to answer each one as if it's original, as if it matters, as if you've not heard it a million times before (especially if it's right there in the FAQ.)
Part of answering well, and the quality of any forum, is in participants answering well, even if the question is trivial.
We all were newbies once. Asking stupid questions is how we grew from there. Answering stupid questions is how we pay it forward.
We appreciate your many positive contributions to HN, and we just ask you keep in mind that HN can only be a good place to participate if enough people make the effort to keep it that way.
It’s pretty typical of the alpha-nerd type who derives a ton of their self worth from superiority in some arcane area.
I'm writing such harsh words when I expect 0 improvement from the company but I hope at least to make the customer support person reconsider their life choices and quit the evil company
One of my suggestions was that they include hash tables, rather than rely on records (linked lists with named key). Got flamed as ignorant, and I've never emailed that mailing list again. A while later, they ended up adding hash tables to the language.
Still, I really don't think most people need to be told not to tell other people to kill themselves, and in many places where I hung out when I was younger I strongly believe you would have been tempbanned for "flaming". I was a forum moderator and I can tell you I would not have hesitated.
But you said the magic words, so it bears addressing; I think we all get the picture that the Code of Conduct drama usually doesn't have much to do with the actual rules that are contained within, which really aren't that controversial on their face, but rather the way in which power is moved from stakeholders within a project to other people by virtue of initiatives like establishing Code of Conducts and the governance structures that enforce them. And, I think most people will probably not get upset over the idea that telling someone else to go kill themselves might get you suspended from a discussion forum... Rather, the drama comes in when you see the reach of a project or organization's CoC start to extend outward past what people actually want to stop (toxic, unproductive communication) and past the edges of the project (and into policing the rest of the Internet.) Two notable examples I'd cite are Python with Tim Peters (who as far as anyone can tell genuinely didn't do anything wrong) and Freedesktop.org with Vaxry (who can be a bit immature, but is primarily accused of not moderating the Hyprland Discord... Which is a fair complaint about the Hyprland Discord, but not a very good reason for him to be banned from Freedesktop.org.)
Of course, truthfully, there is no 100% winning answer here; if the stakeholders who have control over a project by virtue of being the original developers don't want to cede any control to people for CoC enforcement, they don't really have to (although in reality, external pressures to implement one might make it an untenable position to hold.) In that case, you have to rely on those people to hold themselves accountable to reasonable conduct, and nobody's perfect. It's kind of like when police departments conduct internal investigations and find no problems; even if you're pretty pro-police, you must feel somewhat skeptical that they actually were reasonably impartial in conducting said investigation.
But, I generally side with The Evil I Know, which is that the project authors and biggest stakeholders should generally maintain most of the power and control in an open source project including the ultimate decisions regarding moderation. In cases where developers have proven particularly egregious with their conduct, forking has proven to be effective enough as a mitigation strategy, and the fact that it comes at a cost is a sort of feature, as it's better if a power shift like that isn't easy; while I can't guarantee that the original authors and maintainers of a project will act reasonably and impartially, I can at least say that I expect them to have the project's best interests at heart, whereas the kinds of people that go around looking for established projects and organizations to join roles that have authority tend to not be the kinds of people you usually want in those roles. Having it be difficult means you need people who genuinely care about the project rather than the types of people who just kind of seek power. (And I am sorry, but there are fuckloads of those people among us and they are absolutely dirty enough to hide under the guise of anything to get a modicum of control. Running an online community for any appreciable amount of time opens your eyes to this IMO.)
All of this to say, it reflects poorly on the state of the Internet at the time and KDE's mailing lists that the situation happened and was possibly not rectified in a way that is satisfactory (it sure doesn't sound like it.) The correct thing to do is obviously to issue a ban, and you don't need a rule book of any kind to figure that out. I think when people push for these things during major incidents, it's misguided at best, because usually the core problem was not that a "don't tell people to kill each other" rule didn't exist, but that people actually would've needed such a rule to decide the behavior was unacceptable in the first place. This isn't some complex gray area case. I don't think people are acting in bad faith when they suggest it as an option after a drama incident, but I still think it's the wrong knee jerk 99% of the time.
(The most favorable thing I can say is that I think a CoC might possibly have value in very large projects like Linux or Kubernetes, but so far the execution has always felt like it leaves something to be desired. Seeing people occasionally openly threaten to contact the CoC committees over effectively technical disagreements leaves a bad taste in my mouth.)
(The main example of these people was a guy named Erik Naggum, but a few still exist somewhere out there and I met one on a programming reddit yesterday. You can spot them because they won't stop telling you how great Lisp Machines are, can't explain why nobody uses them, and for some reason they insist on calling JavaScript "ECMAScript".)
That said, I also remember that codes of conduct were popularized about a decade ago by someone who was then fired from GitHub for harassing junior programmers (she claimed this was "mentoring" and seemed mentally incapable of noticing something could be wrong with her behavior.) So it seemed like an obvious case of reputation laundering at the time.
Agreed.
> You couldn't ask them for help with anything without them calling you a moron who should kill yourself.
Never got that, though. I hung out on comp.lang.lisp back in the day.
I recall once, writing a small utility to read a file in /etc/ and do $SOMETHING based on the settings therein. I asked about the best way to read ini/config files; did not mention /etc.
I got flamed for not storing my configs in s-expr and simply using the builtin reader ... needless to say I was never going to switch all the files in /etc to s-expressions.
My friend kept locking himself out of root and would be forced to single user the system to recover. This was difficult for many reasons, including remote hands costing up to and including $50 per call. I decided to look into why su would only work with root. Found a very simple check that I thought was unreasonable. Made my first patch and proudly posted to the FreeBSD mailing list thinking I was going to change the world. Man, instead I come back to everyone chewing me a new one, calling my friend too dumb to use FreeBSD, and other things that was not rooted in reality. I didn’t even try to defend my patch, I had spent so much time evangelizing FreeBSD up to that point that it really made me question my support of the project.
Anyway fast forward like 5 years, I was telling the story to coworkers when I decided to look up the su source. shocked-pikachu someone took my patch and applied it (without attribution). I have since moved on from FreeBSD entirely and my open sourced works have never been so negatively picked apart again ¯\_(ツ)_/¯
I'd be more than happy to put you in touch - email address in my profile if you're interested.
Like, if your installation has useful services running on it, it should not also have a customized kernel and it probably shouldn't have a C compiler installed at all. What it should have is backups and a way to stage/test/revert config changes instead of just making them on prod. It… does not do this.
IME if you bring this up you'll just get a hundred complaints from people saying "I built a system to do this out of poudriere and duct tape so it's fine". I guess because the people who know about declarative programming all use Docker.
Which is a perfectly legitimate opinion to hold. "Cattle, not pets" is an opinion about best practices, not a religious dogma where those who don't agree must be cast out of the community.
not a religious dogma where those who don't agree must be cast out of the community
Besides that, I'd say the current approach is just wrong because it's obsolete. FreeBSD sells itself as a "server/embedded OS", but the assumptions are those of basically someone who owns a single computer at home and makes random sysctl tweaks to because they read on a mailing list it was faster. Which is the kind of person who's an OS developer or a small-business/academic sysadmin - basically someone who loves being on the computer in the first place and wants an excuse to spend more time on it.
But they should've realized that was obsolete by the time Google released the SRE book (which has a chapter about how you should never make manual edits), and certainly by the time virtualization and cloud hosting became common.
Of course, many people still do think it's fun to own a computer with a silly name and make random sysctl tweaks to it, so they're not going to like me telling them it should be boring and impossible to do. At least there's Docker and Nix though.
I will still reach out because BSD dev was a small community back then and we have probably crossed paths!
I was told I should just ignore the error messages I was seeing. When I kept asking, some of the most active members started insulting and ridiculing me. Then others started joining in.
The only thing I had in mind was to improve the guide for other people new to arch, that came after me. Instead, I was only insulted and ridiculed. I uninstalled Arch and never did anything with it again. The toxicity of that community still makes me angry today.
I was confused while reading because I nearly only ever use su to switch to the superuser account and obviously to get root permissions you should be root or else it's a security issue. Looking up what su does on FreeBSD, I was reminded that it can switch to any user. I've actually used that before. You made that? :o
Telling someone to kill themselves is wildly inappropriate and shouldn't have happened to you.
When people reminisce about "the old internet" they tend to forget how hostile it was.
Being devils advocate it wasn't common for young people to engage in the activity but harsh and unfair critic was happening often.
It still exists today, but in much smaller scale than back then.