To be fair, there’s also Linux Mint and distributions like Manjaro. Their popularity is not that small. However, I also heard that Manjaro is pretty unstable and way overhyped for what it is.
Linux Mint is fine, but compared to Ubuntu it is less stable and less compatible. When it comes to stability and usability, the big 5 (or how much ever anyone wants to count) will always be the winners, whether we like it or not.
And MX. Cant leave out the top runner
Yes. Might be the case. I’m not up to date on this topic, anymore. Stopped ditribution hopping a long time ago.
When the time has come, I will switch to NixOS and this will be my final solution. As it is the case, right now, this is the best distribution for people who really want a very specific and reproducible operating system setup.
I think Void has about 10 years up. Not sure about Solus.
They are both stable and usable.
I mean, yes, it depends on the definition. My definition (and that of many other people) of stable is, that it can run on pretty much any weird end-consumer hardware possible, just like Windows. It should support any hardware Windows supports.
That’s the first thing.
Secondly, it needs to get the basics right.
0% font issues.
0% window size issues.
0% resolution issues.
0% taskbar issues.
0% printer issues.
0% base issues, like writing, editing text, etc.
One of the biggest no-nos is graphics card support. It sometimes even breaks on Windows. Now, try to run NVIDIA on Linux. It’s a hit or miss. Either you are lucky and it works, or it straight up won’t work.
However, it gets worse. Even if it works, it usually does not work to its full potential. For example, I had issues with NVIDIA SLI on Debian GUI.
So, there are a million issues that need to be fixed, before I would even start using the stable word in any context involving a GNU/Linux distribution.
I see many people, that say Debian GUI is stable or some derivative is stable or even Manjaro is stable, etc. Then I ask, what do they do on their computer?
They say, opening e-mails, browsing the internet and opening the occassional virtual machine.
Like, yes, if that’s all I would do, I probably would already be able to use a Linux GUI distribution for everything.
However, I do much more stuff on my computer and GNU/Linux GUI can’t handle it.
Starting with my NVIDIA card and my 5+ monitors attached to the graphics card and APU…
Linux can’t even start to handle this, according to my last tries.
Thats not stability, that is unusual hardware issues.
I may have been lucky, but never had an NVIDIA card issue.
I dont tend to push the graphics and display side of things, I push the numerics and the memory management. Never had issues there. Any linux will do my computing reasonably well.
I agree, driving peripherals is where Linux falls over most. BSD is worse. The best is probably Apple.
Unusual? I didn’t get any Linux distribution to even fathom the idea of getting it to work. Not to mention getting it to work the way I need/want to.
If you use a single card, with one or two monitors, then yes, you shouldn’t have an issue.
However, going anything beyond that is huge in Linux.
In Windows it’s just a matter of attaching the right cables to the right slots. 
Apple is bad, too. It just fakes its stability by forcing the user to pay over-priced components from its own eco-system. Whereas Windows users use 3rd party hardware all the time. If Apple people would use 3rd party hardware all the time, the term “stability” would get scratched from macOS’ dictionary altogether. 
I believe you.
I just find that surprising. I thought Linux was flexible enough to do anything.
So is anyone taking up the challenge?
It is, but not without an unreasonable amount of effort. And some things will probably never work as good, as in Windows.
What bothers me, is that too many Linux users say something along the lines of “oh, it works, but just disable this and this and this and this and that and then it works” and then I think to myself, why do I have to disable half of my computer, to get this one thing working?
It should work, without disabling stuff.
I see that all the time with graphical issues. “Just use this driver. It will disable all your graphics card’s features, but it will work then.”. Why disable all the features? Why not let it load normally?
All this works on Windows. It does not work reliably on Linux and if it works, it’s highly unstable and restriced.
I think, AMD graphics cards work not that bad. However, it’s common knowledge that NVIDIA pretty much isn’t supposed to work. It has so many issues, it could get its own book.
Such issues, and the very fact that I am writing this post, are my biggest gripe with GNU/Linux GUI operating systems.
I don’t want to deal with such issues. I don’t even want to talk about it. It’s a waste of time. Basics like having your graphics card work the way it’s supposed to is something that should work out of the box, without me having to do anything after installing the hardware’s driver. Just as it is the case in Windows.
I just plug in the cables, move around the windows to have them set up the way I want and boom, I’m done. No screwing around. No frustration - nothing. In Windows, it just works.
Many Linux GUI users hate to hear that, but it’s the sad truth.
I cant disagree with that.
The problem is NVIdia, not Linux.
There will always be non opensource hardware that Unix can not support properly
Support AMD or find another graphics card maker that is more cooperative.
How does Microsoft get to drive nvidia properly? Cant we do what they do?
It’s the egg & hen problem.
If Linux is not popular, not many people use it.
If not many people use it, there is little to no incentive for companies, especially huge ones, to support that platform.
If support by big companies is too little for that platform, a minority of people will use it.
Since few people use the platform, Linux is not popular.
Rinse and repeat.
Well every recursive algorithm needs an escape clause.
Why only a problem with graphics cards… and maybe wifi?
Cant we get Intel to make graphics cards? They seem more open minded.
Its really only a problem with high end graphics. I dont even know what graphics cards my computers have… they just work.
Yes, its an important thing for AI and/or machine learning freaks and gamers.
Especially, with the hellish graphics cards prices in the past 5 years, people take what they can. Whatever is currently at a barely payable price, but also serves the individual needs.
So, being picky about graphics cards is not an option for most people, especially in these past 5 years. It’s hell out there.
Not being able to use a high end or at least high mid-range graphics card for that time, means for the aforementioned addressees, that they miss out on their hobby for years.
This is a huge reason, why such things just have to work. Graphics cards are complicated but at the same time they are very fundamental to many PC enthusiasts.
I’m late to this party, but… a lot of problems with Inkscape 1.x are caused by extensions — specifically, Python extensions. (Not necessarily user-installed / add-on extensions — the Inkscape distribution comes with a lot of functionality that’s implemented as preinstalled Python extensions). You can’t really run Inkscape without Python anymore, and therein can lie the problem.
Python is good at a lot of things, but there are also some things it doesn’t handle well at all.
It isn’t very good at dependency management.
I suspect @JANDOE 's message in the OP:
“Extension “Export to PDF via Scribus” failed to load because a dependency was not met.”
…was likely caused by a missing Python package in Inkscape’s Python install. Which package? No idea! Seems like it should tell us, doesn’t it?
Well… remember how I said the dependency management is shitty? Let’s just label that message Exhibit A.
It really isn’t good at backwards-compatibility in the core language. Python 3.10 broke the entire world with one tiny change: it no longer accepted passing floating-point values to integer function-call parameters.
In Python 3.9, 3.8. 3.7, … if you had a function that took two integer parameters, say gridPoint(x, y) where x and y are both integers, you could call gridPoint(3, 2.5) with no problems. Python would just happily truncate the value 2.5 to 2 and go on its merry way.
Starting with Python 3.10, that call triggers a traceback rather than narrowing the 2.5 value and losing precision. A huge amount of pre-Python 3.10 code out in the wild contains implicit narrowing bugs, as was only discovered when the tracebacks started flying the first time it was run under Python 3.10+. The only solution to making it work under Python 3.10 is to update the code.
Technically this change wasn’t “sudden” (it only felt that way), because for several Python versions prior to 3.10, deprecation warnings would be triggered by instances of implicit narrowing, noting that as of Python 3.10 the warnings would instead become errors. So, in theory it was possible to detect and fix these issues by running affected code under Python 3.8 or Python 3.9.
…In theory. In reality, the problem is that those deprecation warnings ARE DISABLED BY DEFAULT.1 So, unless a developer was proactive enough to go looking for them,2 there wouldn’t have been any indication that their code contains errors that would cause it to crash under Python 3.10+.
The implicit-narrowing thing is just one example, the most recent and spectacular, but there have been plenty of other backwards-incompatible changes along those lines; there are some in practically every minor version release of the Python core.
Python isn’t quite Lua. (Lua 5.1, 5.2, 5.3, 5.4, etc… are all completely separate, incompatible languages, and code written for any specific version is expected to require modifications before it will run on any of the others.) But it suffers from a lesser version of the same thing, just without having the balls to be honest about it.
For a scenario where user-installed code from various sources may be run, not all of it necessarily kept up to date, these things all add up to a pretty fragile environment unfortunately.
Snap/Flatpak packages tend to work better, at least for the bundled extensions, because the Python version in use is typically controlled rather than being at the whim of the system installation. (On Fedora, in particular, that’s usually the latest and greatest release, a version much of the bundled code may not have been tested against, and may not run properly under (see above.)
But those packaged builds also make it harder to work with user-installed extensions, since they tend to be sandboxed, self-contained, and not very easily extensible.
I don’t have any great solutions to offer, it’s all kind of a mess. And that’s just on the Python front. There may be other types of issues besides those, as others have pointed out.
Why? FuckIfIKnow. Because the Python language developers enjoy watching people fall through trap doors? Because they hate the sight of running code? I can’t come up with any non-stupid reasons, so we can assume that whatever reasons they have are pretty damn stupid.
Anyone who writes, maintains, or even just runs Python code should try running it in a terminal with PYTHONWARNINGS=always set in the process environment. Just watch the warnings fly!
Well that is a really great clarification. Thank you.
Is this not a problem of the package management systems not doing their job properly? I mean, if Python3 comes up with a heap of dependency changes, should not the package system maintainers refuse to implement it, or even roll it back ?
The Inkscape problem has been long standing, and you have finally pointed the finger at Python3. It is not the only case, there is a problem with Wicd which is also a python dependency issue. Even such a conservative distro as Debian stable, has allowed Python3 to creep in and break dependencies. That is bad management. One might expect thst sort of thing from rolling releas distros like Arch, but the whole point of stable release distros like Debian is to prevent this sort of thing, even if it means witholding new releases of apps.
Regards, and thank you
Neville
You brought my hate for Python to the point. Thank you so much. I owe you.
Agree, but it is the distro maintainers responsibility to weed this sort of thing out. They have let us down. They need to blacklist python3.
OK - I now have InkScape installed by both SNAP, and RPM (i.e. “sudo dnf install inkscape”) in Fedora…
And so far, so good…
Unfortunately, that is not possible. The hype for Python was so huge, that half of the most important stuff on Linux runs on Python. If we would remove it, the aforementioned stuff would right out stop working. It’s terrible and I hate that. Even apt uses Python in some way… I failed to find the sources showing where Python is used, but I had seen a Python stacktrace a couple of times when using apt in some way, if I remember correctly. I assumed it was written in Python, but the sources show C++ files. Maybe Python is just wrapping the underlying structure. Not sure.
Either way, there are many crucial tools straight up written in Python. So, if you ever have a deep underlying problem, as was already explained in this thread, then these tools might stop working at least misbehave. It’s horrible.
It worked ok with python 2… go back to that. A few apps might have to be wound back too, but so what? There is no way forward, we have to go back.