Distrowatch review grumbles

[dolphin_oracle]

Can not install on a pure EFI system. USB boots intermittently, tried multiple USB sticks. When in the livedemo gparted keeps saying overlapping partitions. Same disk installs OpenSuse, debian and Mint no problems. I am done

Is this a problem?

it is, but its with the user's system, not our setup. fehlix has a post up with a repair procedure.

[Stevo]

Yeah, the review above killed our average by giving us a "1". The next review refutes the complaint with

Overlapping partitions was not reported, in any case a system with that error is not in a safe condition as it has danger of data corruption in the overlapping area. Needs rectification before an installation. If an Installation fails due that error be thankful, it can save a painful experience at a later date.

How do you get overlapping partitions, anyway?

[colin_b]

This is a bit rich...

It is better to recommend a distro like Fedora Xfce because it is more intuitive, more up-to-date, easier to install, more stable, yes more stable and more secure (firewall, Selinux) from the first use.

More stable? Really?

From Fedora reviews https://distrowatch.com/dwres.php?resou ... tro=fedora

Some of the kernel updates kill the xfce installation. Keep a backup. Not very reliable!

[colin_b]

Version: 17.1
Rating: 4
Date: 2018-10-24
Votes: 0

After using MX-Linux for a couple of months, a few issues have surfaced. Let me preface by saying I am not a newb nor am I an expert with linux distros. MX-linux seems to corrupt very easily. For instance flatpaks usually do not run. Indicators point to an issue creating directories (and no, I am not going to run every flatpak with sudo commands...shouldn't have to).

My video editors, Shotcut and Flowblade, can no longer open any files, video or otherwise. I could criticize the finickiness of shotcut all day, but these apps should open video files with absolute ease. My guess is ffmpeg, but reinstalls do absolutely nothing.

After a recent home directory corruption (my guess anyway), MX-linux simply would not login to user sessions. No errors to evaluate, nothing. Only root sessions worked. This is poor error handling for any operating system. No recovery options in any way.

I have no idea about the points being made, but I thought they are worth a mention if problems exist.

[dolphin_oracle]

The flatpak issue is one I've reported upstream. When running under sysvinit /dev/shm isn't where flatpak expects and apps won't start. First I found was discord but it doesn't supris me that there are others.

If the user updated flatpak from the test repo the problem is actaually worse.

Running apps as sudo won't help as its not really a permission issue.

The issue is not present running systemd.

As to his home.folder...I suspect since he can't open files that he changed the permissions on his home folder. The solution being to change them back. That's a guess of course but one we've seen from time to time especially since the permission change tools are in the thunar right click menu. That would also prevent his user login. I think mx17 might have shipped with the older version of the change owner function that didn't reset the gksu password before running running the command thereby requiring the password.

[asqwerth]

@D_O, @Stevo

Maybe that flatpak update in the Test Repo should be withdrawn for the moment?

You mentioned this buggy behaviour in the Flatpak Thread under Package Requests. With an actual report of the problem in DW's MX review page , it seems to me that leaving the flatpak update in Test Repo will lead to more problems than it's worth.

There will always be users who keep Test Repo permanently enabled and choose to update whatever's in there indiscriminately.

Or they may specifically update flatpak out of interest, but then get upset when it doesn't work well, even though it's a TEST repo. And in this case it's a flaw in flatpak itself.

[richb]

I understand that flatpacks are a feature that many are attracted to. It seems they are more trouble than they are worth. Our packagers cede control to some other packager and therefore cannot really vouch for the quality of the package. In full disclosure I have never been a fan and that influences my opinion.

[asqwerth]

@rich,

Your comments appear to be focused on the packages that are packaged in flatpak format.

What D_O said in the Flatpak thread was that the present version of the Flatpak program (not the apps packaged as flatpaks) in the Stable repo was ok, but not the one in Test Repo.

viewtopic.php?p=464056#p464056


So I'm just saying, keep the one in Stable Repo and withdraw the Test Repo version.

And I would think most people would only use flatpak apps as a last resort when you truly needed a version of a package not possible to be packaged in the Debian way for MX's native system by our packaging team. Like D_O said in his blog, it's just another option.

[richb]

@rich,

Your comments appear to be focused on the packages that are packaged in flatpak format.

.............................
............................

And I would think most people would only use flatpak apps as a last resort when you truly needed a version of a package not possible to be packaged in the Debian way for MX's native system by our packaging team. Like D_O said in his blog, it's just another option.

I think that is a hope.

In your opinion, however, is the premise I posed that some control of the packaging is lost with flatpacks invalid? I think that still applies.

[asqwerth]

@rich,

Your comments appear to be focused on the packages that are packaged in flatpak format.

.............................
............................

And I would think most people would only use flatpak apps as a last resort when you truly needed a version of a package not possible to be packaged in the Debian way for MX's native system by our packaging team. Like D_O said in his blog, it's just another option.

I think that is a hope.

In your opinion, however, is the premise I posed that some control of the packaging is lost with flatpacks invalid? I think that still applies.

Sure, but then it's the same way with Appimage too. For some things that can't be packaged any further by our team (or which might cause some issues), having other options is good, right?

Examples -
Libreoffice 6 appimage for MX15/16?
VLC 3 flatpak for MX15/16, viewtopic.php?p=448322#p448322

And from what I've read in the Krita thread, latest version can't be packaged for MX17, so Appimage it is.

viewtopic.php?p=463488#p463488


The first 2 are what I use in MX15/16. And Lollypop as a flatpak.

Krita in MX15/16 - I have an appimage as well.

I don't think I have krita at all in MX17.