I installed the AMD64.deb file from mega.nz: megasync_5.2.0-1.1. I use scaling so thought that was the problem, but disabled it and didn’t fix the appearance issue.
Anyone else here use Megasync on KDE Neon? I didn’t install the Flatpak because it is unverified and I feel there’s more safety in installing it directly from Mega.
FYI, Mega is a quality cloud storage service that offers a generous 20 GB free. Unlike Google Drive, it has end to end encryption (that is not broken despite some hyped up headlines in the past) and has consistently maintained a Linux client. It uses Qt 5.
I’m using X11. Pretty sure the issue is the same on Wayland.
Update: turns out it was the scaling I had enabled of almost 120%. It took a restart to set it back to 100%, and now it is rendered perfectly.
I think this here is a perfect example of why the “unverified” badge in Flathub was a bad idea.
As a rule of thumb, a Flatpak (or snap) will always be safer than a native OS package (.deb or .rpm) as there is some sandboxing with some protection. A native system package has script that are running with root permissions, can install actions that will run all the time or whenever you log in, and when you run the application it can access any and all files you can normally access, run any process, connect to any socket and write and delete anything you can do. A flatpak application can do (almost) none of that and has to request specific permissions to do such things.
So - if you have the option of install a Flatpak or a native OS package, and you worry about security - install the Flatpak.
Specifically for MEGASync - the Flathub entry shows that it was created by MEGA cloud services, and has the global name nz.mega.Megasync so it is almost unquestionably was created by the original Mega company from New Zealand, and the only reason it is listed as “unverified” is because they didn’t do the extra steps Flathub requires for verification - out of laziness or ignorance, but its not actually their fault, its Flathub’s fault for being dicks.
Thank you for the reply. As noted, I fixed the problem by reducing my scaling down to 100% and restarting. Not a complete solution because I do like scaling, but at least it tells me the issue is nothing more than that.
RE: Mega and Flatpak, why don’t they link the Flatpak on the website? I’m always afraid with unverified Flatpaks of installing some malicious code that hasn’t been properly vetted. For example, the Dropbox Flatpak definitely isn’t made by Dropbox. It says that clearly. Therefore, I don’t know how well it can be trusted.
One more thing. I read by Vivaldi’s creator that any Chromium browser should be installed without using Flatpak. Apparently the Flatpak reduces the quality of the sandboxing for that app.
It is maybe a warranted concern but installing native OS packages not from your OS vendor repositories is always worse: Flatpak case is just double vetting - the creator was vetted by Flathub then (maybe) the app was vetted by Flathub staff. With an OS package from the OS vendor, it was also vetted twice - the developer was vetted by the OS vendor and then the app was vetted by the package maintainer.
With a deb you downloaded from the internet there is 0 (zero) vetting - some guy posted a binary file that you downloaded and run with system permissions. This is exactly like on windows running a .exe you downloaded from the internet - at best there’s an anti-virus that maybe will warn you if something fishy is going on, and with Linux you don’t even get that.
Yes, but you can tell who it was - press “Links” and you can browse the Github repository for that and see that it was originally created by Endless OS and then maintained bythesefinepeople - so at least you know who they are and what they do. This is infinitely better than a deb off of the internet.
The question is - what does the sandbox protect? If it protects the host from the website, then its definitely better to run it inside the rather OK Flatpak sandbox containing the now slightly broken Chromium sandbox - a double bag where the internal one maybe a bit leaky is still better than a single bag.
So why do websites like mega.nz and Google not link the Flatpak and instead allow users on their official websites to download only the .deb? That’s what gives people the impression the .deb is more trustworthy.
Meanwhile, thanks to you I was able to look at who contributes to the Dropbox flatpak, and I agree there is a good and respectable team there. However, the Mega flatpak has just a few people who don’t seem on the same level.
This is why I usually avoid Flathub, and by consequence, flatpak in general as most flatpak versions of software are hosted there.
Its flatpak version wasn’t submitted by Mega, nor is maintained by Mega.
But the way they label it, it leads a user to think it is an officially sanctioned version.
See they are referencing “upstream” in some recent issues:
One comment even read: “I still haven’t lost hope that one day upstream will officially start maintaining Flathub build.”
Flathub used to be more clear that a flatpak version was community maintained. But now they make it very difficult to guess.
As a rule of thumb, anything “unverified” is community maintained, and often the original developer isn’t even aware someone packaged their app as a flatpak until they get flooded by flatpak-related issues.
One could say this is similar to traditional packaging by distros, but usually “traditional” packaging doesn’t label something as official, and packagers at least let maintainers know they are doing it.
In this specific case, I wouldn’t handle my credentials to an unofficial version.
Also, do you know why the Dropbox desktop app uses about 4X the memory of the Mega app? I tried the Dropbox app (Flatpak), the pCloud app (AppImage), and the Mega app (.deb), and the Mega deb seems by far the best in terms of using the least resources, including being the least active for CPU cycles and network activity.
One thing I like about pCloud is that every time I e-mail support I get a fast and caring reply.
As I say, I can reasonably trust the Flatpak of Dropbox based on the Links page showing who is responsible for it but the Flatpak for Mega doesn’t inspire the same confidence based on the same data. So far I’ve only ever used the Mega Debian version from the official Mega website. In general, I highly prefer downloading software direct from the manufacturer.
With my Mega free account I have to log in at least once every 3 months to keep it active, so if I am mainly storing backups there (as I am), I have to remember to do that to avoid deactivation/deletion. The others have more lenient activity policies although have weaknesses in other respects, such as much less data and lack of zero knowledge end to end encryption.
Visual-functional app quality is best with pCloud, then Mega as a close second, and Dropbox third. The Dropbox app is very minimal. Not sure why it needs so much more memory than the Mega app. Could be a matter of the .deb file format having some advantages? As mentioned I’m comparing not just different apps but different file formats.
This is an effect of “sandboxing” and application containerization: containerized application cannot use shared resources in the operating systems due to security concerns and therefor need to have their own copy of such resources that are normally shared - like shared libraries. Worse, if you run multiple containerized applications - each need their own copy.
This is definitely an assertion of value that each individual has to do for themselves. By pointing out where one can “do their own research” and come to their own conclusion, I consider my job here is done and will chalk it up as a win for me
