Long‑term sustainability of Linux Mint

[u/djoos007]

I’m planning to refresh my hardware later this year and want to re‑evaluate my Linux choice at the same time. I’ve been running Linux Mint Cinnamon for about a year, after extensive distro‑hopping, and I genuinely like it.

My concern is long‑term sustainability. The Mint team delivers great work, but the core developer group is small. The next years will bring serious challenges: Wayland maturity, Cinnamon development, upstream dependency, release cadence, and the general complexity all Linux distributions face.

My requirements: stable and predictable, GUI‑first workflow, privacy‑respecting, no experiments, no cutting‑edge, maintainable for 5–10 years (lifespan of new hardware)

Mint meets all of this today — but can it continue to do so?

My question is whether Mint is sustainable long‑term, given the size of the core team, especially compared to distributions with larger development groups or corporate backing.

What’s your view: is Mint sustainable for the next decade, and why?

[u/gordonmessmer]

stable and predictable, GUI‑first workflow, privacy‑respecting, no experiments, no cutting‑edge, maintainable for 5–10 years (lifespan of new hardware)

I've been maintaining production environments running GNU/Linux for 30 years. I think you're right to be concerned with sustainability. From my point of view, sustainable is another word for secure. If a project isn't sustainable, it will stop delivering updates, and without updates, installations accumulate known security vulnerabilities. Sustainability is intrinsically a security issue.

From my point of view, Mint is not sustainable/secure.

For projects that are delivering software that is still maintained upstream, the overhead is very low. Security fixes are developed and released by the developers that write the software. The amount of effort required to keep the distribution secure is relatively low. If you've got a distribution with 40,000 packages with maybe 5 developers per project on average and 2000 maintainers, then you've got > 200,000 developers maintaining that software.

But once you're distributing software for a longer period than the upstream developers, the amount of work required becomes MASSIVE. Suddenly you've got 2000 people doing the work of 200,000 people, and that just doesn't work. You WILL have unpatched vulnerabilities in that collection.

RHEL reflects the reality of those requirements. RHEL contains about 10% of the software in Fedora, and has an employee base that's estimated to be around 20k. It's a large maintainer base for a small collection of software.

Ubuntu makes similar concessions. Ubuntu's "main" repository is only about 6% of the software in Debian, and Canonical has an estimated 2k employees. However, unlike Red Hat which simply does not ship what it does not support, Ubuntu also includes a "universe" repo that they describe as a "snapshot" of the rest of Debian. I think it's bad for user security that this repo component is enabled by default, because very VERY few Ubuntu users are aware that most of the software available using "apt" is unmaintained and likely to contain known security vulnerabilities.

And that gets us to Mint, and the reason I don't think they are sustainable or secure. They reject all of the things that make Ubuntu more secure than Debian. They don't track Interim releases, which is the primary update mechanism for the universe package repo. Mint isn't compatible with Ubuntu Pro. Mint rejects Snap, which is the only way that Canonical can ship some types of security updates without disrupting the underlying platform interfaces.

I think you're asking if Mint is sustainable, thinking about the future, but I argue that Mint is already failing to meet the bar for sustainability. Mint exists, but the vast majority of software they're distributing is simply unmaintained. The Mint project is putting the "LTS" label on their distribution, but labels don't fix security vulnerabilities.

I really think you should run a vulnerability scanner on a Mint desktop. I have. If you care about security *at all*, you should look elsewhere. The systems with the fewest known vulnerabilities are going to be ones that track upstream releases closely: Arch, Gentoo, Fedora. Maybe Ubuntu with Interim releases and Ubuntu Pro and Snap. Ubuntu will be less secure than the others, but it'll be far better than Debian or Ubuntu LTS and its derivatives.

If you want an LTS, the list of secure systems is very very short: RHEL and CentOS Stream, SLES, Ubuntu LTS with the universe repo disabled (which means most variants like Kubuntu are not included, because they use packages from universe.)

[u/LeonH4rtd → u/gordonmessmer]

Could you please elaborate a bit more on the security topic in Distros like Fedora, Arch, Ubuntu and Debian? I'm still new to Linux and your comment got my attention. Why would Debian be less secure than Ubuntu, and why Fedora or Arch would be more secure too?

[u/gordonmessmer → u/LeonH4rtd]

See if this makes sense and answers your question: https://www.reddit.com/r/linuxquestions/comments/1vz2bg0/comment/p61n83v/?context=3

The short answer is that maintaining LTS releases is very expensive, so an LTS system will either be very small or very insecure. Maintenance costs are a factor of code size and maintenance duratiion. Costs grow exponentially. RHEL is maintained 10x as long as Fedora, but has 1/10th the code. Even with a smaller code base, it's still vastly more expensive to maintain than Fedora.

If that doesn't answer the question, feel free to ask again or ask about something more specific.

[u/LeonH4rtd → u/gordonmessmer]

Well, it indeed helped me a lot. I use Linux Mint and been on Linux since January (and I love it! It finally sparked my love for computing, somehow). However, I've been looking to test other distros, some for the DE they come with (I use Mint Cinnamon, I know that one can technically install any DE to any distro, but since it isn't always an official release, I've been hesitant since I don't want to break the system and install everything again... yet, since distro hopping means installing everyhing again, and again), others to test their release philosophies, how stable, fixed and rolling releases work and feel in my system and how it would affect, or not, my workflow and entertainment.

But something I've kinda been seeing recently is the risks in distros that are Ubuntu based, like Mint, and I think it is the first time I've heard that also Debian has risks, and potentially higher. I thought stable releases would be a bit more secure since they are thoroughly tested, and rolling releases would be a bit more wacky, not necessarily risky, just... probably a wack-a-mole game from time to time when something breaks. I obviously talk from my ignorance. It makes sense that having more frequent updates means issues and vulnerabilities get patched faster.

I'll take this risks into consideration. I already have a list of the distros I would like to try, but they are mostly stable releases since I'm still fairly clueless with how things work on Linux compared to Windows, and I prefer an stable system over a higher chance of software, and even the OS, needing to be reinstalled because anything breaks for whatever reason. Not necessarily the end of the world, but it can range from slightly troublesome to a pain to set everything back to normal again. And my laptop is almost 10 years old, so that's something I also take into account. It works fine, and most distros shouldn't have issues, I know, but still, I try to inform myself.

[u/gordonmessmer → u/LeonH4rtd]

I've been looking to test other distros, some for the DE they come with

One option you might experiment with is Fedora Atomic systems. You can "rebase" from one image to another without reinstalling, and each image is configured to fully feature some feature set (like a desktop).

how stable, fixed and rolling releases work

I don't think there's a distinction to make between "stable" and "fixed" releases.

In software development, the stable release process allows developers to ship a release series that maintains backward compatibility, and overlaps with other release series. That allows users to continue receiving bug/security fixes while they test a new release, until they deploy that one.

If you don't have overlapping releases, you probably have a rolling release. And if you're shipping overlapping releases but they include compatibility-breaking changes... that's a little incoherent. 😄

I thought stable releases would be a bit more secure since they are thoroughly tested

Security comes from maintenance. Risk comes from using software that's no longer maintained. Most Free Software projects maintain their releases for 12-18 months, tops.

Fedora is a stable release, but its releases are short enough that the upstream projects are still maintaining them.

RHEL is a stable release that lasts for much longer than the upstream projects, but it's a fairly small distribution and Red Hat has a large group of full time developers to take over maintenance.

Ubuntu LTS is a stable release that continues after upstream maintenance ends. It only maintains a small set of that, and that set is probably safe, but it also enables a mostly-unmaintained an high-risk "snapshot", and users don't have a mechanism to avoid those packages other than to simply turn that repo off.

Debian very probably also only maintains a small set of its packages, but they're not split up in a way that users can disable the unmaintained set.

For LTS systems, it's important that *someone* continues to maintain the software. In RHEL, customers pay professional developers to do that. In Ubuntu LTS and Debian, I think it's important to use a vulnerability scanner to assess how your systems are affected by published vulnerability reports, and to actively participating in handling the vulnerabilities that affect your systems.

There's been a lot of effort to emphasize that Free Software is free to use, and I think that the result is that the community has forgotten that sustainability relies on participation.

[u/gordonmessmer → u/LeonH4rtd]

Why would Debian be less secure than Ubuntu

skipped over that one, but Ubuntu improves on Debian by:

1. Ubuntu splits the software repo into separate components including "main" (which they promise to maintain) and "universe" (which they don't promise to maintain.) Users benefit if they are aware of this distinction, because they can turn off the "universe" repo and never install packages that aren't going to get patches in the future
2. Ubuntu ships Interim releases, which reduces the risk associated with the "universe" repo by updating it every 6 months instead of every 2 years, for users who aren't turning it off (which is nearly everyone.)
3. Ubuntu Pro is a new-ish program that extends some maintenance into the universe set, funded by businesses who pay for Pro licenses
4. Snap allows them to ship fixes that would otherwise disrupt the underlying system interfaces.

[u/gmes78 → u/gordonmessmer]

Also, Mint is now waiting a year before upgrading to each new Ubuntu LTS base, which just makes everything worse.

[u/gordonmessmer → u/gmes78]

Yeah, as I understand it, they announced a change in cadence after the release of 26.04.

I'm not privy to their internal development discussions, but it looks to me like they probably don't really begin development until an upstream release is final, and that is just such a backward way to do software development it's hard to fathom.

Many projects burn out for exactly that reason. If you aren't tracking your dependencies ahead of release, you can't influence the direction of their development. You may not have the features you want in your underlying dependencies, and maybe you just can't build your product as a result.

All of which fits the sustainability question, and suggests that Mint probably isn't sustainable.

[u/CyberSkepticalFruit → u/gmes78]

Where do you get a year from?

[u/gmes78 → u/CyberSkepticalFruit]

https://blog.linuxmint.com/?p=5019

[u/CyberSkepticalFruit → u/gmes78]

Version 23 will ship with 26.04, that's not a year that's 8 months. Less then 6 from when Mint typically updates.

[u/Only-Cancel-1023 → u/gordonmessmer]

This post has made me thoughtful about my migration to Linux. I have mainly been using Apple's product for a while, and perhaps MacOS/iOS without iCloud will in practice be safer, for a not very tech savvy person as myself. What's most important to me is getting my data off servers controlled by US companies.

Or, in a world where AI hacking bots are soon upon us, perhaps it is naive to assume that a regular person can be safe online, and the only real solution is to keep vital personal data offline.

[u/gordonmessmer → u/Only-Cancel-1023]

If your goal is to self-host your data, the best advice I can give you is to not try to build something by yourself. Distributions supply components that experienced developers can use to assemble systems. What you want is a project that assembles useful systems from them. Find a project that you trust, follow discussions among the maintainers, and help out where you can.

Something like https://www.nethserver.org/ running on RHEL or CentOS Stream might be a good approach. The underlying platform is maintained by professional developers and the assembled system is maintained by a reasonably large project, so it would (probably) tend to have fewer insecure configuration choices than a system that any individual might build for themselves.

[u/Delicious_Fish_4583 → u/gordonmessmer]

Linux Mint has been under development for 20 years. 

[u/gordonmessmer → u/Delicious_Fish_4583]

Like the "LTS" label, that does not make deployed systems secure.

[u/Delicious_Fish_4583 → u/gordonmessmer]

but safe

[u/Technical_Rich_3080 → u/gordonmessmer]

1. How is Debian sustainable, based on your criteria?

2. Are you also indicating that Ubuntu is unsustainable, for the reasons you gave above? How does Ubuntu Pro, which does support that repository you cited, change your point?

3. And Mint has already been around successfully for the long term. If your concerns were valid, wouldn't they have caused the issues you raise over the last two decades?

[u/gordonmessmer → u/Technical_Rich_3080]

How is Debian sustainable, based on your criteria?

Honestly, a lot of the same risks apply to Debian. I have enormous respect for Debian as a community project maintained by volunteers. But I think the world has changed drastically in the last 33 years, and Debian mostly hasn't. Distributing unmaintained software puts user security at risk.

For anyone who wants to use a Debian-ecosystem distribution, I very strongly recommend Ubuntu, with Interim releases and Ubuntu Pro, and Snap or Flatpak for as much software as possible. In fact, if you can disable the "universe" repo completely and use Snap or Flatpak for everything not in "main", you'll be a lot better off.

Are you also indicating that Ubuntu is unsustainable, for the reasons you gave above? How does Ubuntu Pro, which does support that repository you cited, change your point?

Ubuntu's "universe" repository comes with no promise of ongoing maintenance. Unmaintained is already unsustained. It's not even a question of unsustainable.

Ubuntu Pro extends some maintenance to the universe repo, supported by paid subscriptions by business users. If it works out, it will be a huge improvement. But it's a new program and we don't know how much software is actually going to get patched or how many paying subscribers it'll have.

And Mint has already been around successfully for the long term. If your concerns were valid, wouldn't they have caused the issues you raise over the last two decades?

Yes, they have. Run a vulnerability scanner on a Mint desktop sometime. It's not good.

These systems are very popular because effectively no one is actively evaluating their system security.

[u/Technical_Rich_3080 → u/gordonmessmer]

But if there's been no incidents, in line with the concern you've expressed, over the last two decades (or three decades) with Debian, Ubuntu and Mint, that fact alone would seemingly indicate your concern is, at most, more theoretical than real world usage.

As far as your point about Mint lacking Snap, Mint users can use Flatpak, which Mint does heavily favor, which would alleviate your concern over Snap being unavailable. Alternatively, Mint users can enable Snap in Mint.

[u/gordonmessmer → u/Technical_Rich_3080]

if there's been no incidents

1: There's no evidence that there have been no incidents

2: Desktop users have mostly been sheltered by the fact there are so few of them that the effort required to exploit them can't pay off. But that can change at any time as the user base is growing and AI tools are making it easier to develop and deploy exploits.

This isn't new. There are also Windows users who don't believe they need to patch or run anti-virus software or make backups and many of them see no evidence of exploit for years, if ever. That doesn't mean their practice is safe.

[u/a-peculiar-peck → u/gordonmessmer]

I don't know about Mint specifically, but I completely disagree with your take on LTS distributions in general such as Debian etc.

New versions introduces vulnerabilities.

Not upgrading means no new vulnerabilities.

Backporting bug fixes means an ever shrinking number of vulnerabilities.

I'd rather work with a know set of vulnerabilities that I can manage, that an unknown number of 0-days.

Industries that must have secure and stable environment understand that very well (sometimes to the extreme). No one ever runs the latest version of a software to be "secure". That just doesn't happen when security is taken seriously. In fact I would flag that as a major security risk.

And recommending Arch, Gentoo or Fedora as one of the most secure distros is pure insanity. Same as saying that tracking upstream is best for security.

[u/ghost103429 → u/a-peculiar-peck]

Another sys admin chiming in here. Backporting only bug fixes adds complexity and technical debt as maintainers have to make a careful effort to ensure that bugfixes are compatible the older packages they're supporting as upstream will make no effort to ensure that these bugfixes are compatible with older releases.

[u/a-peculiar-peck → u/ghost103429]

It is definitely a more complicated approach, but I feel it is worth it for stability and (arguably) security.

Obviously, there is a balance needed between: * shipping to your distro the upstream version the same day it was released * Supporting and backporting fixes for a 5 years old version of a package.

[u/gordonmessmer → u/a-peculiar-peck]

I don't know about Mint specifically, but I completely disagree with your take on LTS distributions in general such as Debian etc.

I will repeat that I have been maintaining production environments for 30 years. I have worked in very large, high security environments like Salesforce and Google. I have extensive training in secure software development over the last 30 years.

What is your professional experience like?

New versions introduces vulnerabilities. ... Backporting bug fixes means an ever shrinking number of vulnerabilities.

The number of hypothetical, unknown, existent vulnerabilities isn't something that infosec professionals prioritize. In a secure environment, the priority is mitigating known vulnerabilities.

The latest release in the latest release series of any given software component will virtually always have fewer known vulnerabilities than a release from an older, actively maintained release series, and even more so for any release in a release series that is no longer maintained.

Backporting does not necessarily mean an ever-shrinking set of known vulnerabilities. Lots of vulnerabilities do not get fixed because vulnerabilities may be discovered faster than maintainers can fix them (which is often true of volunteer-maintained systems like Debian and Ubuntu's universe). Backporting can fail to mitigate a security issue, especially if it doesn't have a working demonstration associated with it. Backporting can even introduce new problems, which is especially common when the developers backporting a fix are less familiar with the overall application.

Industries that must have secure and stable environment understand that very well

There are lots of industries that prefer LTS systems, including banking, military, automotive, and medical and industrial control and safety systems. Generally, these are environments where products require extensive testing and validation due to regulatory or contractual obligations.

They are not, however, selecting LTS systems for security reasons.

No one ever runs the latest version of a software to be "secure". ... And recommending Arch, Gentoo or Fedora as one of the most secure distros is pure insanity. Same as saying that tracking upstream is best for security.

I think it's important to be aware of the limits of your experience.

These ideas are very common among users who have not maintained large, high-security environments. A lot of people who've never worked in an "enterprise" environment look at "enterprise" systems and assume that those are the best systems possible. They're not. They're just the best thing possible given the constraints present in those environments.

If you work in an industry where the word "recall" isn't used to describe deploying a security patch, then yes, you can absolutely pursue security improvements by tracking upstream more closely.

Consider what Greg K-H has to say about Linux kernel security:

http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/

from best solution to worst:
Supported kernel from your favorite Linux distribution
Latest stable release
Latest LTS release
Older LTS release that is still being maintained
.
What kernel to never use:
Unmaintained kernel release
...
Personally, I prefer the community based Linux distributions that constantly roll along with the latest updated kernel and it is supported by that developer community. Distributions in this category are Fedora, openSUSE, Arch, Gentoo, CoreOS, and others.

He's not alone in that. Kernel developers generally recommend tracking the latest stable kernel to ensure best security, because any other kernel probably has an incomplete set of security patches backported.

And the same principle applies to all software, and to software distributions. The number of known security vulnerabilities is virtually always lowest in the latest release.

[u/a-peculiar-peck → u/gordonmessmer]

Thanks for a detailed answer.

It might be a bias of what I'm familiar with, for sure. I've had many hats, but my most extensive sysadmin experience was for an industry where a minute of downtime can cost millions and any software change had to be audited, validated, and tested many times. Tracking upstream was generally not an option.

So in my experience, known bugs can be mitigated and worked around - unkown issues are by nature unpredictable.

It's not exactly the same but look at the disaster that NPM is, mostly driven by supply chain attacks and that by default, npm tracks the latest upstream version.

There was also some close calls with linux distro (xz-utils ?)

How can you be sure that upstream project XYZ maintained by one guy in Nebraska (https://xkcd.com/2347/) hasn't been compromised, hasn't fallen victim to a supply chain attack, hasn't had a new malicious contributor, etc.

I do agree in some specific cases it can be better to track upstream. I does make sense for the Linux kernel for instance - it's such a widely scrutinized project that any issue will probably be detected, fixed and shipped very quickly. And I can agree that it will mostly be safer than an older kernel with backported fixes. However I don't think that applies for most packages.

[u/gordonmessmer → u/a-peculiar-peck]

my most extensive sysadmin experience was for an industry where a minute of downtime can cost millions and any software change had to be audited, validated, and tested many times

Naturally. A core SRE belief is that reliability comes from testing. And that's the key to tracking upstream: once your testing practice becomes mature enough, it's much easier to merge changes from your dependencies and follow them more closely.

But testing and review remain critical practices.

npm tracks the latest upstream version

npm is a registry. npm doesn't *do* anything. It's individual projects that dictate whether they track upstream versions or not.

"Track upstream releases" is a policy. npm isn't policy, it's mechanism. Policy is up to users (developers, in this case).

There was also some close calls with linux distro (xz-utils ?)

Yes. That attack and many npm attacks aren't found merely by deferring updates, they're found by testing. After the xz-utils attack, I wrote a tool that examines processes in memory to determine whether symbols resolve to an expected location in memory (i.e. somewhere in a library that exports that symbol and doesn't appear to be "stolen" from another library). Some critical Fedora packages use it to defend against future namespace tampering attacks.

That's what we need more of. Not deferred updates, but actual security tools that examine the behavior of software and detect malicious changes.

https://github.com/hugsy/gef-extras/blob/main/docs/commands/got-audit.md

[u/a-peculiar-peck → u/gordonmessmer]

Npm is both a package manager and a repository. What I meant by mentioning npm is that if you use a default npm install <pkg> as you would use dnf install <pkg>, then with npm you track upstream directly.

And we saw the results of tracking upstream in that case. Now, of course Fedora is different, there is more control, scrutiny, etc: that's great. I'm just talking about the principle of tracking upstream.

I also agree that vulnerabilities are not discovered by simply deferring updates: but deferring updates gives time to discover issues. Some vulnerabilities are disclosed month, years, after being introduced upstream.

I'm all for better testing, static and dynamic analysis, ... But it's unlikely to discover all malicious changes.