I've been using Mint for about four years now since switching from Windows. I've been very happy with it. It just works. This article has reminded me to go and make a donation for this year - so thanks!
The Linux Mint team has introduced a fix for a memory leak it does not fully understand: restarting the Cinnamon desktop. Cinnamon is a desktop environment which began as a fork of GNOME 3 and is developed primarily for Linux Mint, though there are also non-Cinnamon flavours of Mint, using MATE (based on GNOME 2) or the …
May I be the first to say "Fsck you, Mint devs"? I may have perfectly sound reasons to not apply a patch at this particular moment in time.
As for the "we don't understand it, so we'll just force a restart", what numpties. Sadly, Microsoft has TheGreatUnwashed brainwashed into thinking this is normal, so they will probably get away with it.
May I be the first to suggest you go SCREAM AT THEM FOR YOUR MONEY BACK OR ELSE?
Maybe demand to speak to the manager, too!
Threaten to switch to another OS, even!
Show them who's the boss!
/s because that was a seriously weird post, makes one wonder if some words and/or sentences from the article were just not read at all...
This is a temporary workaround.
I'd be fired, rightly, if I introduced a "workaround" like that in one of our products and shipped it to a customer. Memory leaks are normal and there are dozens of tools available to find them. If the Mint developers are so incompetent that they're willing to ship a "have you tried turning it off and on again" workaround as part of the product because they can't find the actual problem then they deserve to lose their customers.
A "temporary workaround" as an emergency solution to a customer would be instructions on how to restart, or a patch script to do it when required. You would never bake it into a release of the product, that's how "workarounds" end up still being there 10 years later, baffling the next support engineer.
an astoundingly shitty place.
No, a large and professional one. We fix our problems, we don't bodge "solutions".
"No, a large and professional one. We fix our problems, we don't bodge "solutions".
Ok.well we had a system, one of the most reliable systems out there (think 5 9's is their MINIMUM reliability), by a multi-billion dollar company. We, along with a few others, had a bug that caused a race condition in one component causing it fail.
A " bodge" was to restart a background service every 48 hours.
A proper fix arrived 3 months later. Why three months? Because when you are running high availability systems installed in thousands of multi-billion pound companies, the last thing you want to do, is rush out a fix, to cause a catastrophic failure in multiple systems.
It's called thorough testing. And I applaud them for that.
A " bodge" was to restart a background service every 48 hours. A proper fix arrived 3 months later.
Precisely, a temporary out-of-band fix, provided as a patch to keep the customer's system running while the real fix is developed. That's professional, and that's how we'd do it.
That's a very different response to Mint's "We don’t know what causes these leaks yet but we’ll have a workaround in Cinnamon 5.0 ... It would be better to fix the leak, he acknowledged". A major new release with a bodge baked-in because they can't find the problem? That is not professional. If I released a new x.0 version of a product with a bug that required regular restarts I'd be explaining myself to my SVP.
I once worked for an obscure company, (name rhymes with "frugal") that had a policy of stopping applications (and starting another instance) whenever the JVM entered major garbage collection. The good news: minor memory leaks turned into increases reboot rates. The bad news: memory leaks did not always get the attention they deserved.
The usual effect was that even fairly sever problems (restart required every hour), which resulted in very senior teams being diverted to address, never affected the customer. Mind, one of the band-aide solutions was to allocate more memory to the processes. Which again, kept the problem away from the customer. The only time I saw a "bad" outcome was when a really small (for us) service ended up running on a max-memory allocation, and STILL would need a lot of restarted. I threw the flag, and got the leak fixed.
Keeping the customer/cashcow coming back is job #1. If the customer thinks it works, that give time to do things right. If not...
Sure, assuming the shipping of a working system is not a primary concern but purity is.
I have worked on a team who engineered, and shipped, and even got excellent customer reviews for shipping a telephone exchange platform that reboots the active Linux kernel and spins up the backup in six seconds without dropping any calls.
Nobody cares about how something works, the purity of the code, the flawless management of resources, no, they care about that it does work now and it keeps on working.
An impossible goal, if one was playing whack-a-mole with memory leaks in Linux code that one doesn’t really control instead of fulfilling system requirements.
Reading comprehension fail
""Fsck you, Mint devs"? I may have perfectly sound reasons to not apply a patch at this particular moment in time."
Depends what the patch is for. I rather get the impression they're referring to critical security patches.
"As for the "we don't understand it, so we'll just force a restart", what numpties"
You understand what a temporary workaround is, right? And that they can't even replicate it, which makes it a bit problematic? (they said they will fix it in the future)
"Depends what the patch is for."
No, it does not. THEY have no idea what I am doing with my system, nor why I am doing it that way. Making a so-called security update without my permission might very well fuck up whatever it is that I am doing. This is a cardinal sin of computing.
"And that they can't even replicate it, which makes it a bit problematic?"
If they can't replicate it, does it even exist? What, exactly, are they working around? From my perspective (as a long-term Linux dev), it's operator error induced by computer illiterate end-users who don't even have the computer sense to describe how they made the error in the first place!.
This is not cause for a temporary "kill and restart it", this is a rather obvious CAN'TFIX ... at least not until they have more info to go on.
 Browsing dodgy pR0n sites would be my guess ...
Looking at the original post, it will be automatically updating by default. That implies that experienced users will be able to override the setting and update when they have planned it in.
I think it is a good middle ground. Users who don't know or care about security and patching will be automatically protected, whereas experienced users will know to shut off the option and manually manage patches as before. As long as there is an option to disable auto-patching during the update to the new version that calls it out, I have no problem with such a solution - experts will see it, know what it means and disable it, if it isn't for them; those that don't know what it means will leave it enabled.
"Looking at the original post, it will be automatically updating by default. That implies that experienced users will be able to override the setting and update when they have planned it in."
Re-read TFA ... he said the OS will INSIST on doing upgrades. Users, experienced or not, will have no say in the matter. Still feel all warm and fuzzy?
"operator error induced by computer illiterate end-users who don't even have the computer sense to describe how they made the error in the first place!"
Some years ago, my system was being regularly crashed by Cinnamon. I was eventually able to reproduce it by the following steps:
(1) Reboot Mint.
(2) Go to bed and come back next morning. Cinnamon was hogging far too much memory.
(3) Go away and leave the machine for the day. By the next morning, Cinnamon was hogging even more memory.
I reported the issue, and it disappeared in the next release. But for that release, I had to swtich to another desktop, because I could not use a machine where R crashed half way through a long analysis for a client because Cinnamon had gobbled up all the memory.
My suspicion is that Cinnamon was being bamboozled by some feature of my hardware, although it is always fun to blame systemd. If it is a hardware issue, I can't fault the Mint team for not being able to reproduce it on their machines, and I salute their approach of offering a software workaround until they can get better information.
"Some years ago, my system was being regularly crashed by Cinnamon."
Some years ago, the citizens of the United States re-elected President Obama to a second term.
Both statements are true, and yet completely meaningless in the context of today's conversation.
Yes, I'm a Slacker.
But as a Linux advocate, I sometimes recommend other distros for various reasons. Mint was one of the ones I recommended. Was. This latest example of following the Redmond Way of doing things (which started with their mindless inclusion of the systemd-cancer because Ubuntu told them to) is just the last straw.
I've been using Mint for four or five years now, partly based on comments here. I've become increasingly unhappy with the way it has been going, and this will probably be the last straw. I'm not a Linux wizard by any means, but the Microsoftesque belief that my computer belongs to them not me (even if I can switch off auto-updates) is, a philosophy is one I cannot tolerate. I'll be looking for something else now.
The problem I have is that I keep having to move my chosen distro as this infectious mindset pervades the industry. The old "for the common good" rationale. As stated by others, they don't know what I'm doing with my machine and why I've chosen not to do something.
It's the dumbing down and "consumerisation" that's everywhere. It's personally hit me with android, and google products in general, where they seem to believe that removing options completely is the way to make products more usable by Joe Public.. Ironic, when their UI/HCI/accessibility teams are clueless, and they keep making pointless changes that finally made my non-techie, partially sighted mum give up on them only last week, when I told her I couldn't revert the stupid changes they'd made to her tablet and her chromebook.
You may have perfectly sound reasons for not applying a patch at a particular moment in time.. may I suggest that if this situation actually comes to pass that you right click on the Update Manager icon and select 'Quit' until you are good and ready? It's what you would do with Windows - turn off updates.
As for the memory leak, yes, problems with Operating Systems are, indeed, normal; things change, things break, devs go looking for the problem. I've had to remove Pulseaudio in Kubuntu in order to get sound - perhaps I should rant at the devs? No, a bug has been reported and somewhere,
Linux Mint on laptop uses the church wifi perfectly - Windows 10 on the same machine refuses to see the routers SSID - should I rant at the devs (in this case I paid good money to have the OS on the machine but I seriously doubt they'd be bothered.!)
If you are so distraught why not switch to a different Desktop (MATE?) or another Distro ,? I believe the choice is quite extensive in the free OS market.. ;)
"may I suggest that if this situation actually comes to pass that you right click on the Update Manager icon and select 'Quit' until you are good and ready?"
Yeah, yeah, yeah, that works. Today. But did you bother reading TFA? Lefebvre said “In some cases the Update Manager will be able to remind you to apply updates. In a few of them it might even insist.”
See that word "insist"? Do you understand what it means for the future?
Those and the fact mint 20 doesn't like my video card and monitor is the reason I am staying in 19.3.
Afterwards I may finally move to LMDE... Hopefully by then I will either have compatible video card and monitor or the issues will be fixed.
Because yes, LMDE has the same problems.
Currently running Mint 20.1 whilst waiting for the next Devuan. Not, however, running Cinnamon. It does very nicely with KDE. I wonder if Mint have whought about batching up updates with a bit less granularity. Two lots in the day is a bit much and I can visualise users deciding to hold off for a few days in case there are a few more in the pipeline.
Surely if people are holding off upgrading as the upgrade may stop the system working, and Mint goes ahead and upgrades anyway, aren't they going to end up with systems being rendered unusable? Apart from the obvious annoyance of having your system rendered unusable (by design), won't that just prompt people to change distros anyway?
Well, there is a choice of distributions organised within a few related families. Each distro comes its own set of default settings, so the chances are people will be able to find a distro that is close to their requirements.
I mostly use Slackware (you get the bugs from upstream pure and undiluted, and as much automation as you want to set up). But I have mint on a laptop that I use specifically for online work with zoom sessions, MS 365/sharepoint, teams, various VLEs and online teaching resources of various kinds. Works fine. Not running long enough on each session for memory leaks to show. Does like its updates though.
Icon: to all involved with open/free/libre software
I'm the same, but Slackware (for real work) and Debian (for random online zoom/ms/etc stuff I don't really like but am stuck with). But I still had to tweak the Debian (primarily a new kernel to get some hardware working), so I'd not like them e.g. forcibly "upgrading" my kernel to a more recent instance of an older branch).
But then since I have put debian on child#1's laptop, where it is not clear that without me, updating of any kind would ever get done at all, I'm not totally opposed to some rather insistent "update me now" nagging from the o/s, in the case of significant and necessary security updates.
Given that linux installs are now ending up in the hands of distinctly non-computery people, some default/starting-point balance has to be struck between wider population safety and the specific preferences of capable users (although, imo, still a balance with the option of a cast iron opt out).
You have just--and I do mean JUST--expressed in very few words what is precisely wrong with (almost) the entire field of 'modern' Linux distributions.
One can NOT upgrade most 'modern' Linux distributions without having something, which worked on a previous distribution (from the same supplier) NOT work any more. The Distribution will claim--or rather the fanboys will claim; the distro makers proper have no time nowadays to respond to their users (they're too busy working on their next 'latest and greatest, which will contain even more bugs and regressions)--that you're just a 'whiner' and a Luddite; that you need to buy a new computer if you want all the latest and greatest from this newest distrbution.
Unfortunately, "...the latest and greatest..." means things which didn't break last year now do. Just as unfortunately, Mint Linux has been a member of this questionable group for quite some time, and continues to cement its position as a charter member.
To the extent that it is true (and it is to a very limited extent), this has a lot to do with the long tail. I don't know when my current HW was new--it was retired from work at the end of 2014. As much as I would like to run the latest software on HW which is more than a decade old, it's not really reasonable for me to demand that off the shelf of free software.
Maybe we need Chick Linux--for those of us who are really chee<bs>ap!
No fancy pants here! Not when I'm rolling around in the mud, trying to find bugs so your future 15.0 is as hassle free as possible. OK, I'll admit it, I'm not doing it for you, I'm selfishly doing it to make my own life easier over the long haul.
Have a beer anyway :-)
Should you be using a graphical session, are you using wayland or Xorg?
If wayland, what window manager?
From your previous posts, I don't think of you as a plasma kind of chap and I'm just wondering about window manager alternatives in the Brave New World.
Coat: off to get vaccinated in a bit
I use X.org ... Wayland is an interesting experiment that has far too many loose ends for me to consider using it in a production environment. It is nowhere near ready for prime-time. I suspect this will not change any time soon. Slackware includes a rather stable Wayland setup (available from AlienBOB since around 2017; ta, Eric!), and I've fiddled about with it quite extensively, so this isn't a typical "I hates it because different!" comment.
The GUI/window manager I use doesn't really make much difference to me, other than the fact that I utterly abhor Gnome. No, I'm not a plasma kind of chap, but I do use a cut-down, basic KDE for most of my friends and family's desktops ... so I often use it for myself, too, just to make life easier. ThisOldLaptop runs XFCE, though (I'm sure you can guess why). Thankfully, Slackware (including the upcoming 15.0) ships with both.
If you have a device driver that is built from source a kernel update can stop it working. Had this happen twice now with unbuntu. I'll keep the systems upto date until they are commissioned, but once commissioned the updates are stopped and only applied after being reviewed. It's a security balancing act. Luckily for me most of the systems once commissioned are not connected to the internet.
In parallel with introducing this workaround, is there anything we Mint users could do to help? Could the new workaround-enabled software provide some sort of crashdump which might help them pinpoint what's going on? There would be information about the system in there granted, but not necessarily any personally-identifiable info.
(I'm quite happy with Cinnamon, so am open to helping them fix what must be an annoying bug.)
"Could the new workaround-enabled software provide some sort of crashdump which might help them pinpoint what's going on? There would be information about the system in there granted, but not necessarily any personally-identifiable info."
It's easier to sell snow to Eskimos than selling telemetry to Linux folks.
Tell them exactly what software you had running, your exact hardware configuration, and what you were doing, that caused the memory leak. That way, they might be able to replicate it.
Until then, they should ignore it. If they can't see it, they can't fix it. Period. Causing a restart at pretty much random isn't any kind of professional answer, all it does is mollify the user-base.
Which reminds me of one of the old AI koans ...
A novice was trying to fix a broken Lisp machine by turning the power off and on.
Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”
Knight turned the machine off and on.
The machine worked.
I never really bothered with Cinnamon on Linux Mint. When I first installed Mint on a PC back in around 2010 the specs of the PC were not really up to running Cinnamon so i went with Mate. And even though my laptop is now more than capable of running Cinnamon, ive still stuck with Mate versions as I didn't really see the need to change while Mate works for my needs.
No, because one is for system binaries, and the other is for shared read-only user executables. Yes, there really is a difference, and yes, there really are multiple reasons for keeping them separated. But that's OK, you go on believing that it's just a pants artifact of history if it makes you feel better.
I don't agree with the update plan -- I already commented in the earlier article. Nor do I agree with the memory leak bodge -- mostly because it sounds like in the future it's not going to be fixed, just the workaround will be different.
But this merge thing makes me do a double-take. If the devs have /bin and /usr/bin merged, how would I get an install without those merged? If I install Mint, I would expect the folders to mirror what the devs are using, for better or worse. I can understand if the installer provides those merged, and if I delete the symlink then any issues are on me. But it sounds to me like the installer provided those unmerged, but the devs have them merged. Is it the case that older versions are unmerged and what you get today depends on whether you did an upgrade or a re-install?
This sounds like a mess made by the devs, but somehow the article makes it seem like the end users are the ones doing it "different". I'm really scratching my head on this one.
Biting the hand that feeds IT © 1998–2022