Distrowatch review grumbles

[j2mcgreg]

I have never seen MX need to take a step backward from a beta to get to a final.

Well, actually that is sort of happening right now. In the Beta2 reply thread it's mentioned that Disk Manager was replaced with Gnome Disk Utility which apparently is clunky and difficult to use. Then in the next post it's stated that one of the developers, nite coder, is working on porting the currently unmaintained Disk Manager to Python 3 and that he / she expects to have it ready sometime in October. That's what beta testing is for -- you try something out and if it works, great. If it doesn't, you take a step back and regroup in order to move forward.

[SwampRabbit]

Well, actually that is sort of happening right now. In the Beta2 reply thread it's mentioned that Disk Manager was replaced with Gnome Disk Utility which apparently is clunky and difficult to use. Then in the next post it's stated that one of the developers, nite coder, is working on porting the currently unmaintained Disk Manager to Python 3 and that he / she expects to have it ready sometime in October. That's what beta testing is for -- you try something out and if it works, great. If it doesn't, you take a step back and regroup in order to move forward.

IMHO I consider that a "side step" not a "step back". In fact its actually all working towards improving things, so could be considered a small "step forward", a "step back" IMHO would be removing something or regressing.
Which I don't think has happened between B1 and B2 at all. Disk Manager isn't being replaced from B1 to B2, Disk Manager didn't exist in B1 at all, so adding Gnome Disk Utility is actually ADDING functionality which didn't exist in the first place. Gnome Disk Utility seems to work pretty fine.

We have like 100s of people with VScode, Atom, etc, etc in their QSIs... and like 0 people submitting Pull Requests on GitHub.

People with "mad coding skills" commenting about things but not doing even small code reviews or PRs... is just as bad as making half baked Distrowatch reviews and not joining the Beta feedback threads.

[Eadwine Rose]

I have never seen MX need to take a step backward from a beta to get to a final.

Well, actually that is sort of happening right now. In the Beta2 reply thread it's mentioned that Disk Manager was replaced with Gnome Disk Utility which apparently is clunky and difficult to use. Then in the next post it's stated that one of the developers, nite coder, is working on porting the currently unmaintained Disk Manager to Python 3 and that he / she expects to have it ready sometime in October. That's what beta testing is for -- you try something out and if it works, great. If it doesn't, you take a step back and regroup in order to move forward.

I consider that a forward step, given the app is no longer developed but will hopefully be taken over, and the gnome disks thing isn't installed by default like disk manager was.

[j2mcgreg]

Eadwine, you are right that porting Disk Manager to Python 3 is the step forward. In this instance, the step back was realizing after the fact that the Disk Manager utility was specifically needed and what had to take place to make it happen.

[Eadwine Rose]

Ahhh now I get the approach you meant. Thanks

[JayM]

On the downside, the default installations come with too many packages and add-ons for most users. Even Xfce ran with a particular high RAM footprint, compared to other distros. I understand the need to cater to a variety of use cases, but I would prefer a slimmer installation. There is a community "minimal" installer, but it's not up-to-date.

"Most users" indeed! IIRC there's a small minority complaining that if they want a smaller, slimmer system they have to put in some effort to uninstall things and disable unneeded services. "Most users" find that MX can do at least 90% of what they want to do on their computer right out of the box. Other than the MX-specific tools and utilities I don't think it has more that most other distros come with: Firefox, Thunderbird, LibreOffice, a video player and so on.

My biggest gripe with MX is that you cannot upgrade the system between major version numbers (corresponding to Debian releases). That means that if you're using the current version (19.4), you'll have to perform a clean install if you want to use the upcoming version 21.x (based on Debian 11). I imagine someone who uses MX, as opposed to base Debian, wants to stay relatively up to date, so this limitation is unfortunate.

If you run Windows 8 and want to upgrade to 10 you have to reinstall also. What's the reviewer's point?

[Adrian]

My biggest gripe with MX is that you cannot upgrade the system between major version numbers (corresponding to Debian releases).

Ahem... https://mxlinux.org/wiki/upgrading-from ... nstalling/

[pannet1]

Atleast sometime in the past, I was under an impression that XFCE is with less eye candy and hence would consume very less memory or cpu. Surprisingly, someone proved with a benchmark with KDE consumes far less memory or cpu in comaprision. i may be little out of context here, i don't have the resource that had the benchmark right now.

The point is it may be not the fault of MX Linux in ending up the more resource hungry distro. Can you please share your thoughts on this.

[Stevo]

We've all known for years that KDE has made great strides in reducing resource usage, while XFCE has become somewhat heavier with the migration to GTK 3. This is not news. You can try the KDE MX if you want.

[asqwerth]

It's now a matter of which interface, and look and feel philosophy you prefer, not so much the resource consumption.

Some just like straightforwardness of xfce without so many bells and whistles, plus its modularity . Others love the extreme customizability of plasma, and pretty visual effects that are possible.