Be sure to sandbox your flatpaks… for security. There are numerous threads on how to do that, in this forum.
But isn’t the disk space a short commodity on Chromebooks? If so, snaps/flatpaks have no place on it, unless you add bigger SSDs to it.
Also I am not fully getting this security talk. Normal installed packages are not sandboxed and some flatpaks and snaps are from what I heard? So if some aren’t, then why is it so bad and problematic? Did anyone had any issue with it, what is so insecure and dangerous about it? This is all hazy and unclear.
mostly because it’s spread that they are sandboxed, and that’s not really the case and does not depends on local flatpack config, but on how the dev did the package. so not in the hand of the user.
Cool, but what about that… ?
My Chromebook has 32 Gb and if I uninstall the Android version of OnlyOffice and replace it with a flatpak version, I should have a comparable amount of diskspace left. LO will eat away some space, but I have enough to spare. In the end: I occasionally need to be able to read and annotate docx files that are too complex for G Suite, and I get them emailed, so I am sometimes offline by the time I open the email. WPS office is good, Onlyoffice is better.
With regards to security:
- The kids like using the chromebook, but I never feel as if my security is at risk when they do whatever on it.
- Auto-updating is truly smooth. Manjaro is great, ChromeOS is just incredible.
- All logins are through google-accounts for which I’ll get alerts if it is suspicious.
- One powerwash away from normality should something go wrong.
- majority of what I do is in google-docs which gets auto-sync’d. No real worries about backups, except periodic copy from my google-account to my nas or another cloud-based drive.
Ok, but why using flatpack LO while you can use version from repo? It would take less space. Unless repo version is old (which is to be expected on Debian) and flatpak may be up to date.
Still don’t get it. Native packages are not sandboxed and we are not screaming that they are insecure. And how would such breach of security look like when using some popular flatpak package like gimp or vlc? Who would put the malicious code in them? This is all so confusing.
Also, did someone heard of ANY CASE when something bad happened because of that?
As to old runtimes, this is true and real security whole. I think that there will be pressure to use newest runtimes but currently situation is still fresh and problematic. It’s good that people are talking about it. Sooner or later this will force some change in that matter but package systems like snaps or flatpaks won’t ever be so secure as native repo versions, period. That’s the nature of things.
Repos are small, controlled, more secure, up to date or patched.
Flatpaks/snaps can contain unlimited amount of packages that is only controlled by developers, not the distro devs or distro community, so things can slip and things never be secure. They will be easy accessible, working, convenient for devs and users (aside the used space and lack of DE integration) but at a price.
Hmm… If they only had similar feature like AUR: mark package as out of date… so if people could mark flatpak packages with outdated, insecure repos…
EDIT: When I think about it longer, sandboxing may be good for security if app is compromised (has security wholes), so maybe there is something to it… So far it looks like using flapaks gives you Windows like level of security… So after some thought, the guy from the flatkill site may be right. If Linux would be more popular and was build on flatpaks, it would be full of security wholes like swiss cheese…
I expect that more and more software-producers will start making their software available as snap and flatpak. Onlyoffice snaps are provided by onlyoffice, for example. Some distros are already mentioning that they will use these type of packages.
On my chromebook it will be a bit of “see how it goes”. On my laptops I already run Onlyoffice snaps because they are official versions unlike the AUR ones. The snaps update in the background. There is some overhead, but it is acceptable.
So where do you think the AUR ones come from then?
I will tell you from the official source code from the developer they also get updated as the source code is released and no malware can be introduced from the developer.
Yeah, the only AUR downsize is, that the maintainer may oversleep and not update PKGBUILD to newer version of onlyoffice, but that can be done manually if someone is impatient. Just replace with a link to newer version and update checksums. However, usually someone marks the package as outdated, maintainer gets emailed and updates the PKGBUILD.
If you mark Octopi or Pamac to check AUR updates you get notified so you will get newest version anyway from the source, lean and clean, without flatpak bloat.
I repeated it many times: flatpaks or snaps are the last resort. If a package is accessible natively from repo or AUR it’s always better.
If I am not mistaken the Onlyoffice-bin comes from the offical *.deb version. The maintainer may be Onlyoffice related, but I do not think it is. There are several onlyoffice related packages in the AUR.
Although the chromebooks update wonderfully, I do not think all their linux-packages will automatically update. So I prefer versions that come from the supplier and that auto-update. A pity that Chromebooks do not do Snaps yet and there are no flatpaks yet of onlyoffice.
I think you get me wrong i don’t dislike the idea if used as it was designed for, not to replace distro packages but to enhance your choice when the package is not in the repro.
While i was using CentOS flatpak was a boon I could use up to date software the difference i was running flatpak on the platform it was designed to run on
I tried the same thing with Arch Linux it was not practicable in any way or form a lot of packages were broken some had missing features, others the themes were non existent etc etc just added 7gb of bloat for one program over a month or two for a couple of programs.
I noticed it too. My runtime was 1GB but I only tested vlc and gimp. 2 programs added 1GB runtime! I can’t imagine how it would work if I had 14-20 or 30 flatpaks. This is insane. Windows programs come with their own libraries but it doesn’t take so much space.
So far it looks like we should avoid flatpaks at all costs here, too many things speak against them. I’m curious how snaps are doing in comparison. What is their bloat, their security, etc.? So far I have two snaps, both are apps based on electron and they do have global menu in Plasma. Electron don’t use themes so I see no issues on that front either. So far those snaps seem to be much better then flatpaks I tested. However, I am not sure how much space they take.
Is there any way to check snap’s taken space?
I don’t use snap never will they are to much of a security risk supported by a unethical Ubuntu.
But Like I mentioned Flatpak has its place for Debian CentOS and R/H distros and with centOS really blended in well so no complaints. In Arch when I saw my / partition grow to nearly 25gb I thought this is so wrong its the size off win10 that is when I went digging more into it.
/home wants to be structured as /var/home to put the junk into userspace, which is how it is structured in Silverblue, a la an “immutable filesystem.”
There is a reason for that design that does not (yet) transfer across-distributions at this point. Just as you’ve mentioned, this whole Flatpak, software store, yada yada, works best in the distributions for which it was intended and designed, which are managed corporate desktop workstations.
For the rest of us there’s just plain old (but themeable) GNOME, warts and all.
There’s a discussion on the Arch AUR General mailing list about how to package AppImages, and supporting these sorts of packages in Arch/Manjaro doesn’t make a whole lot of sense.
All of these self-contained formats are designed for frozen-pool distros where packaging can be difficult. Arch is different - new software built against current libraries is what Arch is, and with the AUR there’s no reason for anything other than native packaging formats.
Building from source to create a native package is always more efficient than installing a standalone blob.
Exactly, those packaging methods are a work-around for an obsolete model of development.
We don’t need more packaging formats support, but more straightforward ways of packaging. The AUR was a big leap on that, I think that it could even be improved.
I’m developing a script that allows to instantly package any software already on a Git repository, and test if it works properly. I’m thinking about standarising it, and making it available in the AUR as a command line tool.
If its possible just extract appimages,snaps and flatpaks and use them as source like deb,rpm,tar and make a script to install them as native package on arch/manjaro but it just makes kinda aur… OK I’m now confused is it really possible???
Make also versions for other distro families. Because of AUR we have usually have git versions in AUR so installing them is very easy, but being on Mint, Ubuntu or other non-Arch system it’s more complicated to a newbie to install something from git.
The question is, can such tool be made universal given the differences in distros? Probably not, but Ubuntuland would need this even more then we do, so maybe do some related script-command for them as well?
Actually the idea isn’t to manually build packages yourself, but to make it easy to test them before publishing them. Both manually and automatically.
If the build process fails it will tell you, in the most terse manner, where and why. So you could easily write a supervisor script for those packages. The idea is having continuous integration Arch style.
Other distributions models of development won’t work well with this approach, as their system libraries and dependencies will be too old.
I left Ubuntu Quality after three years of frequent contribution because of this, because I realised good quality won’t be ever possible under that model.
The best model is small continuous changes, exactly as Arch does. If something fails it’s just what has been changed, versus updating everything all together and getting a bulk of mud for months. It lowers defects and resistance to get new things done.