Linux Mint seems to take a fairly regular beating from the Linux community at large, and I'm not sure why. It became fashionable after their ISO downloads were briefly compromised in 2016, and a popular LWN post became the script for people to reiterate every time Mint is mentioned in any capacity.[0]
I think it's a terrible shame. For all the stuff I wish it did better, it does so much right that I still overwhelmingly consider it the best distro for converting friends and family away from Windows or OSX, even if I don't use it myself.
I really like the desktop environment they have developed, Cinnamon. But I agree with this LWN thread about their broken approach to packaging. Furthermore, I tend to find people commenting in LWN really respectful even if they are critical, as it was the case here.
We are currently going through a bit of a Cambrian explosion of Linux distributions, but some do have indeed shaky technical foundations. Many distributions would fare much better if they were built as a thin layer on top of something clean and reproducible like Gentoo, Arch or, ideally, GuixSD/NixOS.
In reality, we are seeing lots of distributions, like Mint, as a layer on top of Ubuntu. Which in turn is based on Debian. Seasoned users like those posting on LWN find this frustrating as it obscures things a lot.
Personally, I have not seen good technical foundations for Linux distributions aside from things that have either a very simple imperative architecture (like Arch) or purely functional (Nix/Guix).
Cambrian explosion? The main distros (Debian/Ubuntu, RH/Centos, Arch, Mint, Gentoo, Suse, Slackware) haven't changed in like ten years or more, the only relatively recent additions being the Devuan branch of Debian, and Alpine. Or have I overlooked something?
Elementary OS, Void Linux, Deepin, Antergos and Tails are a few notable ones off the top of my head. Void has been around for a minute but has become a lot more popular recently.
Elementary is Ubuntu trying to be OSX. Deepin and tails are Debian. A Tetris is Arch.
Void is it’s own thing and xbps was really good when I used it. But since the thing where the one guy with sole control over their resources disappeared, and then losing their domain, and not having a distinct legal entity/org behind it last I checked... I dunno about longevity here despite the project being 10 years old already.
Elementary is great, I'm using it on my spare laptop and I have only one complaint and it's the removal of the wingpanel indicator without implementing a proper replacement.
Totally - Mint was my bridge from OSX to Linux. Great stuff. My impression is that the "cool kids" like to dis Mint because it's popular and easy to use. I found that its ease of use allowed me to get comfortable with the Linux ecosystem at a relaxed pace and not throw my hands up in frustration.
I've actually gone the other way: started out on Debian, went through Ubuntu, and now I'm on Mint because it's least surprising of the lot of them (while being familiar enough that I don't need to relearn the world).
It was fashionable long before that. IIRC Mint had an embarrassing start being advertised as particularly secure (great for online banking!!) despite not really offering anything good in that department.
Mint was just weird back then. Ubuntu was so young and had so much things going on, and then came Mint sipping a bit of that energy away. Some users would end up in the Ubuntu support forum I was active at the time and mention they use Mint, and we were like "why would you do that?" In my bubble it felt like a diverging amateur approach (it felt, no idea about whether that was the case) right at the wrong moment with misleading advertisement. That was still very early days for Ubuntu, when users still had to be educated not to break their system with strange and insecure tweak bash scripts downloaded from other forums. And I'd argue it was also before one could understand why you'd want to fork Ubuntu, before there were controversial decisions - especially not with "we make the desktop easier!", Ubuntu was already doing that.
Later on Mint developed its own profile, this was way before Cinnamon.
The "security" thing is deceptive, although I don't see that any worse than what's currently on ElementaryOS's frontpage[0]:
>Safe & Secure
>We’re built on GNU/Linux, one of the most secure systems in the world. It’s the same software powering the U.S Department of Defense, the Bank of China, and more.
> This creates something that we in Debian call a "FrankenDebian" which results in system updates becoming unpredictable [2].
I believe this comment shows how a condescending communication style in FLOSS hurts goodwill and clogs the virtuous cycle of enthusiasm that fuels FLOSS.
Here's something that's true:
Debian Jessie ships a LTS Firefox for which it grants an exception to its strict package security update policy. That LTS Firefox version has its own support schedule, and its own arch support policy. Both of those skew from Debian's own policy and timeline.
This means that one of the two most popular browsers on Debian doesn't provide the same ARM support that Debian claims to support on its website. It also means that Debian updates Firefox on stable (as well as Chromium on stable) whole cloth. It doesn't backport security updates because Debian does not have the resources to take on such a difficult project.
That means for every Debian box set up as a user desktop, the two most popular packages cannot follow the package security guidelines that the quoted Debian fan/dev would hold up as one of Debian's strengths.
To be clear: when Firefox LTS released an update that worked perfectly fine on all of their supported archs, that release broke Firefox completely on Debian Jessie on ARM. In other words, you can install a Debian called "stable" on an arch they call "supported" and end up upgrading yourself into a state where an official Debian package no longer works.
In short-- all Debian stable packages are potentially "FrankenDebian" for this reason, and-- worse-- for really popular and important desktop packages.
Elementary logic and social skills dictate that the person I quoted should be finding common ground with Linux Mint devs. Say package maintenance is hard. Say security backports don't really scale anymore. Say random number generators are tricky to get right. Pointing out one's own failures and citing sources for the rare successes seems like a winning strategy to me. Or at least one that doesn't threaten to zap all the energy of the people one communicates with/about.
You'd think a project like Debian with its myriad guidelines and processes would have at least one sentence in there like, "Don't treat others like they're teenagers loitering outside your fast-food restaurant," or, "Don't be self-righteous." Or more pointed, "Don't talk down to other distros."
Is there a Debian dev here who agrees with my upshot? There's apparently this whole inculcation process to become a member, so maybe one of those sentences could be part of it.
Thank you for that link. The whole discussion was in my eyes (apart from the occasional derailment into vaccines) quite a good example of how to deliver criticism without resorting to personal attacks on anybody.
The background for this seems to be that the maintainer decided to stop shipping security updates for certain packages. One of the people in the discussion put in some work to help rectify these and other packaging problems only have their changes reverted by the lead maintainer.
The project then proceeded to host their downloads with an insecure Wordpress blog. After serving malware, the response was to remove the malware and return to normal. When downloads were compromised a second time, however "briefly", the above discussion happened. In the light of that the discussion is a lot more civil than could be expected.
> I still overwhelmingly consider it the best distro for converting friends and family away from Windows or OSX
Unless the situation has improved significantly in those three years, perhaps you are not doing them a service moving them to more sparse security updates. It's 2019 now and security is not optional.
Entitled users exist, and can be a problem, but the situation here seems to be a lot more complicated than what the author wants to believe.
I use Mint for over 5 years as my main OS and it allowed me to make a seamless transition from Windows/macOS to Linux for everyday tasks, on high-end hardware with multiple HiDPI monitors and including games with recent Steam updates (thanks to Ubuntu + Valve as well!). I can't imagine being stuck with Windows 10/macOS these days.
I've been using it for 2-3 years now on a Chromebook I converted to dual-boot with one of the options being Linux Mint on a USB. I don't use it every day but I do use it probably one a week for something vital. So I want to second the Thank You to the Mint developers!
THANK YOU. I used it for 7 years, because I was sick of constantly tending to my Gentoo install. I used LM because it Just Worked. I never had to think about the OS, I could just focus on my work.
The biggest bug I had in 7 years of using it was my /boot partition filling up because new kernel installs wouldn't delete the old kernels/initrd.img. Other than that, it just worked. Thank you
I use Arch. Kind of complex reasons, I guess. It wasn't that LM was deficient in any way, just figured it was time to really dig in and understand what my OS was doing. Arch has the best documentation, so I decided to switch to it.
> Arch has the best documentation, so I decided to switch to it.
Not an Arch user but their documentation is amazing (small sample[0]). I toyed with FreeBSD years ago and have never forgotten just how well documented the entire system was too[1].
Well-written documentation (with plenty of real world examples) is severely underappreciated in modern tech. It's not only empowering but it's just plain fun getting under the hood.
> Well-written documentation (with plenty of real world examples) is severely underappreciated in modern tech. It's not only empowering but it's just plain fun getting under the hood.
This can't be said enough. Complete, well-written, well-maintained documentation is a key divide separating open- and closed-source. It's expensive and time-consuming to produce — and absolutely essential. Trying to understand how to access a critical setting that some UI wizard has hidden from view in Windows? GLWT.
> We can get demotivated, uncertain, depressed even by negative reactions or interactions, and it can lead to developers stepping away from the project, taking a break or even leaving for good.
It truly is a struggle. I have a couple of projects with moderate numbers of users, and between the "it doesn't work" private messages (not even mentioning which project) and some abusive and entitled users, I do wonder sometimes what would be the best way to protect ourselves as maintainers of open source projects.
There are of course sensible users whom I truly appreciate, though encouraging messages are easily drowned out by low quality support requests and negative interactions.
We may step away for a while or cut off communication channels in order to heal, but I don't see a real solution to this problem, other than to delegate tasks so that abuse is spread out evenly between a team of maintainers.
So, it seems like there is a potential way for a non-dev user to help out with open source, here. Basically, if a person volunteers to be an intermediary, reading the feedback and distilling it down to the relevant content (stripping out the unproductive negativity), that could be useful. It would also be emotionally easier to read harsh feedback, when it's not about _your_ work, just the work of a product you use. Many open source projects have plenty of non-dev users, who cannot really help out currently, but some of them might be willing to if shown a good entry point.
Again, they wouldn't be blocking the feedback, just distilling it down to the most relevant part (e.g. "your piece of sh*t update broke the f#$King feature I depend on for my work!" becomes "newest update caused a regression in this menu item").
While the idea is good and kind, it's not as easy as it seems.
That's called a support line, and it requires good understanding of the project by non-dev support. That requires to educate someone about your project, and maintain their knowledge to be up to date.
That's not an easy task even in commercial projects with a team of several people, and ability to delegate, and requires a non-trivial skill of leadership.
In other words, the project is very lucky to have such people. And while it sometimes happen organically, it's hard to implement this intentionally.
They don't necessarily need full knowledge of the product or any such thing, they just need to be able to provide a sort of filter, remove anything uselessly abusive or congratulatory without value, open defects for obvious bugs with reproduction instructions and get users to dig in and provide useful details when asking questions.
Those questions can then be answered directly by them or forwarded off to a dev who will have more detail and be able to get answers faster without the drudge of dealing with the rest of it.
Personally while working at a small company and doing both support and development work, I found it helpful to simply tell customers we'd address issues "with the development team" even when that meant I was going to work on it. Drawing that line in the sand between support and development roles compartmentalize those activities and reduces the immediacy of demand from users.
I'm sure it's not easy, but...
1) a support line offers support to the end user, which is different; I'm talking about filtering out the emotion from the content
2) most people who could do this, do not know that they could, that there is a need, or how one would volunteer to do it
3) the same person would not have to process all feedback, just as much as they have time for; at least some of the pile of feedback would be processed by someone other than a dev
4) the non-technical nature of the person is actually helpful, because that is usually where the originator of the feedback is coming from, and the job of this person would not be to determine the fix, but only to separate content from emotionally motivated criticism
I have help multiple roles that could be called "very technical support" - technical enough to understand the guts of a project, troubleshoot, deflect reports that are just user error, report bugs on behalf of users with extra debugging insight, etc... but not technical enough to contribute meaningfully to the source code.
That job is just as exhausting and unrewarding as any support role. There's no fucking way I would do it for free on open source software that wasn't my own creation.
EDIT: Unless it was a definite path to being a core contributor to a project I was very passionate about.
In theory it's a great idea but I think in practice very few people want to do that (or anything). In the same way that non-dev users could help with translating documentation etc but very rarely do. As it happens I recently had a guy translate our documentation into Catalan and he's just started on Spanish - but it's the first time I've been offered that sort of help in 6 years.
You are no doubt correct, but I could easily believe that 1% of people would be willing to, but don't know that there is a need, or how to volunteer for it if they did. Also, a system for crowdsourcing this, with "crowd" being minimally vetted volunteers, so that maybe you can't get everything but you could do 5% of the total.
>> I do wonder sometimes what would be the best way to protect ourselves as maintainers of open source projects.
Well, some of us develop an attitude of contempt towards their userbase (the techincal illiterate and rude part of them at least). "Cannot configure? RTFM! Doesn't compile? Read the damn error messages! Outdated libs? Fork or fuck off!".
It helps keeping your peace of mind, but it doesn't help the situation in any way, since we are just loading up the contempt we receive to other users (even the ones with good intentions). This is neither good for you nor for the project.
So, as I am writing this I am trying to change my personal style when dealing with those issues, but it flares up fom time to time, and that never has solved any issues but created even more.
I have no convincing answer as of yet, but people who don't even try to be "not-rude as default" are being pushed lower in the "to-answer" queue.
You get to decide how much support you're going to give, and what kind of access. The easier access people have to you, the more they're going to share their frustrations and start demanding things.
My first suggestion is to limit access. Only provide a mailing list e-mail address, so people know their comments are going to be public, and they have to subscribe to it and craft an e-mail.
Second I'd suggest you provide your users with clear expectations of use and support. Tell them you're not producing it for them, but for you, so you're not going to take feature requests, but you are open to suggestions. Tell them you aren't responsible if they can't get it working, but you are open to legitimate bug reports. Provide a mechanism to determine bug reports such as system information dumps to spend less time troubleshooting.
If people get through your filters and are still rude, there's always public shaming.
I agree that this is how it should work. Though in practice issue and feature request templates are usually left there unfilled, and people will find a way to reach out on all of your social media accounts. My experience has been that the lines we draw are regularily disrespected.
More and more projects are turning off GH Issues & PRs and I think it's a good practice.
I think setting the expectations early and visibly may prevent some of the disrespect on social media, but private or pseudonymous amounts may help too. (Maybe all code authors should use pseudonyms, the way book authors do?)
That can be cathartic, but normalizing hostility towards users will ultimately hurt both you and your project. There are no winners in this context once you decide to draw your weapon.
On the other hand, letting people use the project forums to vent, or to attack others users, or attempting to hoard the devs' attention, will create its own set of problems.
I'd say 1 or 2 polite warnings are due (everyone can have a bad day). If the misbehavior continues, take out the banhammer. Use it judiciously but decisively.
It's not about winning or losing, it's about setting healthy boundaries. No one owes anyone anything but if you are giving the fruits of your hard work away for free you get to set the rules. I have fired clients who were being dicks before and they were paying me good money. This is no different.
My trick to solve this problem:
Include the name of the project in the email address, e.g.
dessant+project1@gmail.com
dessant+project2@gmail.com
etc...
That's a neat trick, though I only accept bug reports over GitHub, but that doesn't stop people from contacting me through any other email address or social media account they can find.
The problem is not the lack of processes, but that we don't have a good way to enforce them.
Even on GitHub issue templates are often ignored, and there is no option for making them mandatory. Some projects resort to accepting bug reports only through a third-party service such as Google Forms, because that supports mandatory form fields.
GitHub could really step up and offer proper tools for controlling how bugs are reported.
> Beyond that, keep in mind that while donations keep Linux Mint and other distributions afloat, the occasional message of appreciation can be encouraging, and at times personally invaluable.
Exactly. This issue isn't just something that "maintainers deal with"; it's also something that "users can help with".
The next time you install a library that makes your life easier, write someone an email. Star the project on GitHub. Open up a "TODO: Keep Being Awesome" ticket where others can show their gratitude.
Even if you don't have the skills or bandwidth to contribute to a project's development, you can contribute to its morale.
Thanks for this. I'm not sure I've ever done it with devs I don't know, but I absolutely should - especially for small projects.
Come to think of it, there's one random package that quietly solved the most mindbending pdf issues I've ever faced... Sounds like a good first person to drop a thank you note to!
I wish people would realize that being kind gets you results 10x faster and better than being mean/critical.
In my own experience I've had people tell me certain projects on GitHub are complete garbage and criticized all the shortcomings of the tool compared to other tools. It made me feel bad and want to take it down.
On the other hand, I've had users praise other projects and excitedly request some missing features and that made me feel like a million bucks and I was filled with motivation to improve the tool.
I can't even imagine the stress from public comments that comes from working on an open source operating system.
I don't use Mint but I'm hugely sympathetic to the devs who have to deal with the backlash from, of all things, a logo and website design change that they likely had little to no involvement with.
It’s not completely thankless, but the thanks seem to be mostly direct and private and then you face public ridicule for errors, bugs, missteps or just when people have different aesthetics or taste and don’t like your project. There are so many “behind the scenes” sorts of projects too, stuff that matters and isn’t quite as visible to the common end user.
I think of OpenSSL, the big security hole got more marketing and PR than the project ever did with “heart bleed.” Then some of the comments during the libressl review were very harsh. They did their thing in anonymity for decades, got used by everything and then took a public beating; clearly it depends on where the developers’ hearts are when that happened, maybe it wasn't so bad, it felt bad to watch.
With something like mint, just about everything is subjective. There are going to be a lot of haters just because of opinion.
Almost every python package that I've used seems to have Github "issues" opened where someone asks "Why even do this when there's [insert similar but different thing]". Who cares? Pip uninstall it if it isn't what you want? Fork it if you want something slightly different? Or contribute to a productive discussion about the direction of the project? Do SOMETHING positive.
I worked for a while on a distro. The issue tracker is stressful for two main reasons. One, a lot of esoteric bugs that are hardware dependent. It's so frustrating to ask for help in testing to be ghosted or told 'no.' People don't seem to understand that as a small team, you don't have and won't buy all the hardware choices that exist to work on something for free.
The second stressor are people being adament and pushy about what they want, and not bugs at all. Go build your own distro, guys.
I found myself being a real dick to some people, so stepped away as it wasn't worth the stress, and I didn't want to tarnish the reputation of others who worked on the project.
> People don't seem to understand that as a small team, you don't have and won't buy all the hardware choices that exist to work on something for free.
that's why there shouldn't be as many distros. With fewer distros, it would be easier to test them on various configurations. Also it would make sure any fixes for specific hardware are used more widely, rather than ending up a patch in a single distro.
Yeah, but much of the reason I think there's as much volunteer involvement as there is is because distros are different, and the volunteers are happier to contribute their time to something they believe in.
If you have fewer distributions, that means they're going to make design choices more people won't like, which means volunteers aren't going to be as interested in contributing. You can't please all the people all the time, remember. A small number of distros will equate to making lots of compromises, so no one will be happy. This works for corporate products, because people are getting paid to work on something they don't care much about, but it doesn't work for a volunteer project.
Just as an example: if I were working on, say, Linux Mint, but then all the distro maintainers decided to have a giant meeting and in it they decided we really only need one Linux distro, CentOS, I'd just quit. There's no way in hell I'd want to work on CentOS of all things. I can find more enjoyable ways of spending my free time. I'm sure you'll find this with anything that people are passionate about: if you try to get them to redirect their energy to something "boring", they're not going to do it.
I see your point... but realize that 99 percent of such bugs are upstream. So it's a matter of locking packages, or adding hacky things to a shell script that runs at install time. In a lot of way, it feels at times a distro maintainer is a secretary between the end user and upstream packages, since we end up opening the bugs.
I worked as a front line developer at a major Linux distro known for making some unpopular decisions. I came to the position knowing full well how 10% of all people out there are loudmouth asscracks . People without experience or inside knowledge who think they know better than those with, and expect to have only their own personal demands met at the expense of everyone else probably because they are getting something for free.
As long as he approaches the job knowing he is going to see some of the most wretched examples of scum and villainy, the dude can abide with grace. Just don't take it personally.
Heya bregma, good to see you! We had a Code of Conduct we could enforce on at least official properties to make sure people behave, though I wasn't able to find one for Mint.
It doesn't stop if completely, but at least it's nice to be able to do your job without too much flaming. Reddit or blogs might be nuts, but at least the work mailing lists and bug trackers were relatively ok.
Linux Mint is my main desktop operating system now after abandoning Windows and MacOS. I tried Debian, Ubuntu, Open Suse, but settled on Mint because I was familiar with Ubuntu and Mint feels traditional and polished.
Every day I see sad examples of eternal September's march to the written abyss.
I had a dream of writing a significant open source project but the reality of entitled user disruption, lack of clear economic benefit, lack of even personal benefit makes me think its a terrible idea. I wrote a closed source software that sells on the Apple app store. Despite nearly a million Downloads, and thousands of reviews and some real money too, the level of serious entitled bitchyness found everywhere in the open source world is non existant with my product. I even sell it for $19.99 well above typical app store prices.
I love open source, I wish I could contribute but as of now there are more downs than ups.
I ran my own company for a few years just to make money to stop working so I could contribute to open source. By the time I finally made enough to not have to worry about money anymore, I had spent enough years working with open source to realize that big companies get great benefits (I was in meetings with HP, IBM, and Oracle VPs where open source was being supported to transfer responsibility and costs away from those companies.) At the same time, it is Software Developers and associated staffs which lose income. There is also less profit to invest in high quality documentation, training, support, and research (ever notice how most open source companies didn't actually develop the technology - they are just monetizing it through support or consulting?)
So I had the chance to live my dream - supporting our community through open source - but realized that it was ultimately the wrong dream for our society.
Now that I'm no longer super young, I am very much aware of the precious time every day where I can do valuable, creative work (outside work). From this subjective point of view I question if many open soure projects are truly worth it.
Valuable activities would
1. improve relevant, marketable skills
2. bring joy
3. help improve the world
4. make some money
It appears that many activities around maintaining a linux distro are mundane chores, compared to the learning process of, say, studying security issues deep inside the kernel. It certainly does not bring joy as reliable and immediate as, say, switching off the computer and going outside for some pickup basketball, and there are already plenty of linux distros out there, with marginal differences and little impact general progress. Nothing needs to be said regarding my #4.
So I will offer my unsolicited opintion: Life is short, focus your effort on things that are really worth it.
This touches on something I've seen in (some, not all) large open source communities: the language used on a daily basis. The default tone is one devoid of empathy or understanding.
> This update is shit.
or
> [new build gets published, person's pet bug doesn't get addressed]
> The devs are lazy.
At what point did this sort of tone get normalized? I initially chalked it down to non-native English speakers using verbiage from forums and IRC channels, but over time I've observed that isn't the case.
it's a little bit lazy to blame it on nature. Not all communities function like this. As one of the users above points out, the degree to which abrasive language and behavior tends to pop up in OSS / linux communities is definitely grounded in a "usenet" culture.
There's a long history of excusing aggressiveness as honesty and throwing "RTFM" responses around, or turning the smallest disagreement into a flame war. Now that OSS projects are really large and not dominated by in-groups any more, it has become a significant problem. This sort of thoughtless communication only works when the people having the conversation know each other.
To the Mint guys: thanks! I don't use Mint, but I have in the past, and hundreds(thousands?) of people try it each day. Packaging open source software is a labor of love, and the community appreciates the work you are doing. No one ever says "good job!" when it works, but they raise hell when it doesn't.
Keep doing what you are doing, because while you may not get to perceive it often: people really, really, really appreciate the fruits of your work!
I would like to propose something that has long been simmering in my mind: zero tolerance to toxicity from the open source community at large. Too often I see entitled developers show up in these forums and just hurl abuse at the people who provide these wonderful tools free of charge. I propose that, if the request is anything less than respectful or if they, say DM a maintainer with abuse or what have you, they get banned. Shoot I'd say they not even be allowed to use the damn software anymore (although that would probably be difficult to manage). If what I am proposing sounds impractical, thats because it is but that doesn't mean we shouldn't start setting precedents. You don't like the new Mint logo? Fine. Tell them but do so nicely. Shoot maybe offer up something substantive and actionable. Whatever you do stop yelling things like "new logo is terrible change it back NOW". There's no excuse for going after someone to the point that THEY ARE CONSIDERING QUITTING MAKING THE SOFTWARE YOU CARE SO MUCH ABOUT. We all know how hard this job is. We should be lifting each other up and ejecting anyone with extreme prejudice who thinks that treating people in this manner is ok. </rant>
That's a straightforward path into irrelevance. Every user and developer has a bad day or two; every user and developer has an obscure subject that riles them up well beyond what's reasonable. Zero tolerance here means they do go elsewhere, where quality of discussion is at maybe 90% instead of 100%, but at least they can partake in the discussion. Lastly, assholes make for effective leaders. Unfair? Maybe, but holds true through ages and cultures.
A perhaps contrived example, but here goes: email spam. We have complex solutions to it, blacklists, whitelists, heuristics, whatnot, spread between servers and mail clients. Some end-users may indeed be running zero-tolerance rules, but by and large the system as whole is elastic. If you ever end up on a spam shitlist, be it due to a mistake or actual malice, there's always a way back. If the system was indeed geared for zero tolerance, it would be close to useless, if for no other reason because it would be pretty easy to get unsuspecting victims on a shitlist, dealing them permanent harm.
Coming to think of it, no system in wider society is truly zero tolerance, except the death penalty - and that one is usually very heavily protested, just as well as guarded against mistakes and abuses by several layers of interleaved protections.
I would respectfully ask you to re-read my comment. I did acknowledge that zero-tolerance would be impractical (perhaps not as clearly as I should have) but its the ideal to strive for. A sort of "shoot for the moon and hit the stars" type thing. I think that we need to deter abuse in OSS as a whole. Right now it's a way for developers to vent frustration into a faceless void which is part of where the vitriol comes from I think.
To your point, I think also that practicality dictates an escalating type of warning system such as we see in social networks. You mistreat developers in a forum you get a warning about it, next you can't comment for 30 days, finally you are just banned. If you send a direct message to a maintainer or the like with abuse, you get immediately banned. Something like that. The point is, it's not cool to abuse people who make you stuff for free that you use to earn a living. Just a giant hell no.
And lastly, I would like to tell you that you are dead wrong about assholes being effective leaders. Effective leaders are people who are right more often than they are wrong. Effective leaders have vision. Effective leaders inspire people to be better than themselves. If they also happen to be an asshole that is in SPITE of their success. Not because of it.
I wish that this idea would die out. I have seen no evidence for it. The most effective leaders I have worked with and under, and those I try to emulate were never assholes. Or if so then only in rare moments that they regretted (and I agree that everyone can get triggered). Effective leaders need to be strict, they need to make unpopular decisions, but they never need to be assholes.
> Remember that these folks are pouring all of their energy into a free product, and remember that they're sensitive to how you perceive it.
I hope I live to see the day when the internet stops bringing out the worst in us. The Linux community might not be as vitriolic as cesspools like gaming, but some days it really isn't that far off.
As someone who has published a free app for fun, I've learned that due to any mix of entitlement and ignorance, anything you put out there can make some people emotionally angry. I'm still learning how to move on and accept that this is OK, for them and for me.
I tend to ignore the negative feedback, and reply to the postive feedback (with a simple thank you or something of the likes).
If you did something for fun, it doesn't really matter what people think. Just keep doing stuff for fun, and kudos for putting it out there for others to enjoy! Even if you get some people who don't like it, remember you did not do it for them :-)
Thank you! Overall it has been a positive experience :) This is my first time dealing with 'the public' and I'm likely overdue for the lesson that one can never (and shouldn't) make everybody happy.
UX stupidity is just as big a problem. Some users are 'stupid' (because they're mere mortals, lacking the towering IQ's of HN posters). Some UX designers and stupid and lazy, and have zero empathy for the way their UX choices enrage and frustrate their end users.
I think part of it was the tone set by Linus. He had an attitude that on the surface seemed to be perfectionism but was really just abusive. It's good that he stepped back and rethought how we dealt with people.
Linux Mint MATE is awesome and runs really, really well on older laptops. I have installed it for many newcomers to Linux and it has served these people well.
I've been juggling the idea of switching _back_ to Linux Mint after running Ubuntu on my dev machine for the past year. I used Mint on my main PC a few years back and it was simply terrific - ultra fast and did everything as needed.
Sometimes a change of scenery is great, in this case, this mean mention of Mint makes me want to go back.
If you like Mint -- and I do -- please consider supporting the devs through a one-time donation or a Patreon monthly commitment: https://www.patreon.com/linux_mint/overview
As much as I think that Linux Mint is a distribution with great potential, I don't want to support something that blatantly states that they don't want my help or the help of anyone who supports Israel.
I think it's a terrible shame. For all the stuff I wish it did better, it does so much right that I still overwhelmingly consider it the best distro for converting friends and family away from Windows or OSX, even if I don't use it myself.
[0]https://lwn.net/Articles/676664/