MX Linux Package Installer review - Nice but can be nicer

Updated: May 12, 2021

A couple of moons back, I tested MX Linux 19.3 on my new test laptop. The results were quite decent. Overall, MX Linux is a pretty solid distro, with decent looks, generous functionality out of the box, a nod toward the normies population, and several unique and cool features, like say the MX Tools, eh, toolbox. But software management ain't one of them.

In the review, I complained that users don't get any proper store - and various readers emailed me to point out that, in addition to Synaptic I mentioned, there's also MX Package Installer (MXPI), which is part of the MX Tools set. All of these emailed focused on my omission of mention of this utility, but not on the very specific phrasing I used - store. Indeed, when it comes to "shopping", Linux distros don't really offer any cohesive experience to the users. That said, let's review MXPI, shall we?

Simplifying the nerdology

Like most things MX, the Package Installer is designed to bridge the vast chasm of nerdonics and allow people who don't care too much about technology to be able to use this distro with only a minimal shedding of tears and blood. But the tragic problem is - the solutions really have to be all or nothing. A friendly nerdy tool doesn't do anything - it pisses off the hardcore veterans and confuses the newbs. Hence, the need for a store.

Until and if and when that happens, MX Linux has to do with its MXPI. The utility comes with a simple tabbed interface, and it offers the end users several options. First, install stuff from a curated list of popular stuff, sorted by categories - and there's search, too. The list is pretty comprehensive and useful overall. More on that later.

Start

Select app 1

Select app 2

The next three tabs offer you, well - exactly what Synaptic offers. Except, this is even more confusing. You have the choice to install packages from conflicting repositories and break your system in a really convoluted way. In general, Linux packaging and dependency management is hard, and this exposes the hardship in a friendly way, inviting people to make mistakes. Also, terms like Stable, Backports and such don't really mean anything to ordinary folks, nor does Debian, which is listed here. The nerdy friendliness paradox.

Stable

Test repo

The second-to-last tab lets you install Flatpaks - self-contained application packages. But this ain't trivial either, because no remote source is enabled by default. If you try to install applications shown here, you'll get a sudo prompt - why, since MXPI already asked for it once - and then Flathub will be added. Again, for average users, this is meaningless.

Flatpak, authenticate

Another problem - in addition to hazard warnings you get going through the different repo tabs, the actions do not get saved. Say you select a couple of applications on the first tab, click on the second, boom, the selection is gone. So you must commit actions on the same tab before moving away to the next, if at all.

Package message

Notification after app selection, apt log in the background. Is this useful info for the ordinary user? Besides, what's i10n really? Why does the user need to know about specific packages and dependencies?

Weirdly, I'd expect something more, because MX Linux lets you save your live session data when installing, so why not offer persistence here, too? Or even data import? This would be something new users would definitely appreciate.

Grab the apps and enjoy - if you can

I decided to install a handful of browsers and see what gives. The Console tab activated - it's grayed out and inaccessible until you install something. In essence, this is just a frontend for apt and such. But as I mentioned, it's not a store. You have no screenshots, no reviews, you cannot really browse and look around. Unless you know what you're looking for, you won't find it.

Falkon and Chromium were soon on me disk, and I decided to launch the programs. 50% success. The former crashed majestically. The latter worked fine. But then, it makes me wonder. If this is a curated list that MXPI offers, how if at all are these applications selected or tested? This then ties into the bigger Linux problem of non-existent QA and testing. Almost everything is a chaotic patchwork of independent components, with little to no integration, and no proper work to ensure these pieces actually work when they land in the hands of the end user.

Browsers, results

You could say, but Falkon is a KDE application, and it's the KDE team's responsibility... Yes, of course. But as the END user, I don't care about the journey. I care about the end. I want the application to work. And technically, unless it's the developer of the application who packaged it and provided it for MX Linux (or Debian or whatever runs in the background), then the responsibility lies with the distro owners and maintainers - indeed, in most cases, there are distro teams who gate the inclusion of software into the distro repos, regardless of the upstream ownership. And that makes you wonder. What testing is in place to ensure that the included code works fine? When you take into account the fact there are hundreds if not thousands of applications, and ten times more software libraries, you can guess the answer.

And we go back full circle to the original problem of Linux fragmentation, lack of testing, impossibility of testing all the different permutations and options (like Falkon running on 200 different distros), the fact every distro has its own little world and rules, and that it's virtually impossible to have a unified approach across the board.

This is a philosophical thing - I'm not pointing fingers or trying to blame anyone - but to end users, it matters not. You install software that's on the "recommended" list or whatever, and it doesn't work. Somehow, someway, the task failed successfully.

Conclusion

MX Package Installer is not a bad idea. But it's a workaround to the horrible mess that's Linux packaging. If anything, it just makes the problem more prominent, and puts it into the user's hands really. And, when we integrate over the problem space, the fault ends up at the MX doorsteps, because it's an MX Linux component that created the possibility for the user to try a program, all hopeful, and then to have it crash.

Ideally, every software component would have a clearly defined, rigorous test procedure. Every system would have a chain of these tests, declared, defined, interlinked. No application would be allowed for inclusion or publication without successful testing that proves the components work great on their own and as part of the overall complex system. The responsibility can be shared, if needed, whatever works the best. But to rely on third parties for your own success means gaps and problems and issues and tons of blameshifting. It's Debian, no it's MX, no it's KDE, no it's the user, and so on. Who cares? The Linux desktop isn't growing. Well, I do. I want it to grow.

So this would be the conclusion of this review. MXPI is a nice thing, but it's still 90% nerdy, 10% friendly, and the equation needs to be flipped. Over the years, the MX team has done pretty cool stuff, and I believe and hope they will be able to polish up MXPI. After all, they did it with their distro, and really transformed it from a nerdbox into a cool, accessible system. But the journey is far from over.

Cheers.

You may also like: