Linux Mint's Sobering Update: A Glimpse into the Personal Struggles Devs Face
forbes.com
forbes.com
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 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.
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).
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.
>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.
Later on Mint developed its own profile, this was way before Cinnamon.
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.
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
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.
[0] https://wiki.archlinux.org/index.php/List_of_applications
[1] https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/c...
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.
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.
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.
Does it? In ways that are worse than what the devs are dealing with as mentioned in the OP?
That sounds like a pretty big assumption to me.
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 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?)
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").
Just an idea.
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.
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.
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.
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.
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...
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.
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.
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!
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.
Thank you for taking your time and knowledge to provide some open-source tools! There's a lot of users out there that silently appreciate it.
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.
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.
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.
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.
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.
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.
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.
The flaming is the required price for not spending all your time in an echo chamber and for leaving your comfort zone.
And gosh, if you really want flaming, just mention a Code of Conduct. Even a CLA doesn't bring the worst of the dreck out like a CoC does.
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.
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.
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 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.
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.
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!
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 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.
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 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.
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 :-)
Sometimes a change of scenery is great, in this case, this mean mention of Mint makes me want to go back.