Flatpak is a gigabeast / discussion about QEMU...

[spiritwild]

Can't say I didn't try but I never really used it much so I finally just deleted it from my system.
I didn't find many apps to be of much use and the amount of space it took up was pushing 7 gigs with no apps installed

To each their own but it just wasn't practical to me.

[fredx181]

Can't say I didn't try but I never really used it much so I finally just deleted it from my system.
I didn't find many apps to be of much use and the amount of space it took up was pushing 7 gigs with no apps installed

To each their own but it just wasn't practical to me.

Yeah, me too, tried but don't like it, also AFAIK it requires systemd, which I try to avoid (edit: or perhaps I confuse with "snap" (requiring systemd), which is a beast too, btw).

[rockedge]

I tried out Flatpak which worked on a Bionic64 but never liked it. The overhead was too immense.
Snap was no better.

I can do better with less strain on the system by just running QEMU or VirtualBox running a small OS with whatever application installed in it.

[sonny]

Flatpak should change its name to Gigapak or Fatpak

[geo_c]

We've got the answer here at the puppylinux-forum: appimages, rox apps, and @mikewalsh portables.

[wiak]

Coincidentally, I was today trying out AppImage, Flatpak, and snap to see what worked best for me for a particular purpose. I don't 'normally' use any of these mechanisms, not even sfs portables - I tend to be an official package manager sort of a person because, all going well, that provides smallest and most efficient installs, and I tend to use Arch-based or Void-Linux based distros, which are rolling distros and therefore tend to provide up-to-date packages.

But... I use Zorin lite (a Ubuntu Fossa spin) for business purposes and some apps are terribly old for my taste and usage with that. Most of the time, that is fine because newer compiles are often available via special PPA repos (such as for my favourite Cherrytree, for example). But I need KDE's Okular for various clever tricks it does that MasterPdfEditor cannot do...

So I hunted first for Okular AppImage - I've uses AppImages occasionally before; main one being for Ferdium, which I use for all my social messaging needs and a bit more (it is great and they provide an AppImage version and worth its weight for my purposes...). However, AppImage for Okular without newest glibc and similar was over 400MB in size, and it didn't work on Zorin lite because the glibc was too old, but another AppImage including new glibc was available as an alternative, but at OVER 900MB in size! Crazy. Certainly, I can use the old version of Okular apt install brings down in Zorin, but it is terribly old and I want new version. So now I tried Snap... after all that's a Canonical product... okay so I got almost the newest via snap - had to get all the other snap junk too unfortunatlely so the /var/lib/snapd folder suddenly occupying about 650MB!!! Crazy again... And it takes a few seconds to open the app... Forget it.

And last I tried Flatpak, which Zorin actually supports out-of-the-box... Well despite the article below, turned out Flatpak in this case the Okular wasn't too bad in overall size, probably because Zorin specially set up to support it. I have to do this again, they may well have cheated and brought down loads of kde-related libs via some other mechanism, but at least inside /var/lib/flatpak/app, the x86_64 okular folder is 'only' 134MB in size. I could live with that, and no snapd junk with flatpak. BUT BUT BUT: However, my overall /var/lib/flatpak direcory is actually MASSIVE, being 2.7 GB!!!!!, but that may or may not be okular related - Zorin 'may' already have filled that up they way they install their main system (I'm doubtful but trying to be optimistic) - I will do an overall reinstall tomorrow and check - mind you, maybe the issue IS Flatpak!!!! Otherwise, for this one particular new Okular version need, Flatpak won hands down if that 134MB is the actual install size required - though if so, pretty sure will be different if same done for a different distro, but it depends on what flatpak runtime is required and how it has been made - meaning partly what underlying Zorin system libs are being used so not needed in the Flatpak...But no,... I suspect the install size was actually 2.7GB!!!!! AAAGH!!! The flatpak came from KDE so I presume they made the runtime, so not actually anything to do with Zorin I think... so I'm not sure if Zorin has any say in the overall size therefore. Horrible if really needed 2.7GB just for my new Okular, so I'm hoping the 134MB figure is the actual increase hence importance of my re-installing/checking later. I will report the result thereafter.

Overall, here is a damning opinion (the following is extract only, but whole opinion is worth reading) about all above mechanisms (aside from using actual distro repo package manager that is - drawback of which is backward compatibility of libs of course, including libs used in different distros):

https://ludocode.com/blog/flatpak-is-not-the-future

The stability of the Linux desktop has dramatically improved in recent years. Core library developers are finally seeing the benefits of maintaining compatibility. Despite this, many developers are no t interested in depending on a stable base of libraries for binary software. Instead, they have decided to ignore and override almost all libraries pre-installed on the user’s system.

The current solutions involve packaging entire alternate runtimes in containerized environments. Flatpak, Snap, AppImage,
...
At the time of this writing, the latest KCalc AppImage (if you can even figure out how to download it) is 152 MB. For a calculator.
...
So how big are these runtimes? On a fresh machine, install KCalc from Flathub. You’re looking at a nearly 900 MB download to get your first runtime. For a calculator.
...
If you install GIMP in Fedora 34’s Software store, it defaults to Fedora’s Flatpak of GIMP. This pulls in Fedora 35’s 650 MB runtime, not any freedesktop.org runtime. Nothing will be shared with our freedesktop runtime KCalc we installed from Flathub earlier. On my machine /var/lib/flatpak is using over 3 GB of disk space for just these two apps.
...
All of these technologies are essentially building an entire OS on top of another OS just to avoid the challenges of backwards compatibility.

Oh well, at least I have latest Okular - the KDE provided Flatpak package at cost of either 2.7GB or 134Mb determining what I later discover is the case - will be ditched if 2.7GB!!!!

Fact is, the old package manager Okular download does the job I need really - I am just being fussy wanting the newest version. Overall, forget any and all portable apps mechanisms for me - nothing like good package managers, though mikewalsh/fredx181 sfs type not too bad for sharing between distro purposes!

[wiak]

My goodness... so I had no option but to re-install Zorin 16.2 to check flatpak prior to okular install.

/var/lib/flatpak was just 9MB in size, so installing okular resulted in it becoming 2.7GB indeed!!! Forget that.

So none of AppImage, Snap, and certainly not Flatpak was acceptable to me for this Okular app need...

Of course, from my point of view, the real problem is that Zorin is based on old Ubuntu Fossa. So if I want Ubuntu base I should look for something other than Zorin. If Jammy based, by default get okular 21.12, whereas newest from KDE is 22.08.3

Actually the winning solution would be to ditch Ubuntu base altogether, forget Zorin, Fossa, Jammy, blah blah blah, and sensibly go with KLV-Airedale since Void Linux provides Okular version 22.08.2, runs much faster and more efficiently, and will no doubt have slightly newer 22.08.3 soon via its official Void xbps package manager being a rolling release distro. If I wanted to use a Puppy distro in the business, then it should be VoidPup, since provides same packages as KLV-Airedale...

One other, always excellent alternative I have is to go back to using Arch Linux base for the business, so KLA will also do beautifully since uses Arch Linux official package manager pacman and provides up-to-date Okular also (well, even newer - 22.12, a dev version - that's the risk with Arch sometime...). In fact I used KLA predecessor WDL_Arch64 for two years rock solid - only moved when a rebuild temporarily failed when Arch adopted zst compressed modules - but have that all working again now anyway.

[geo_c]

All of these technologies are essentially building an entire OS on top of another OS just to avoid the challenges of backwards compatibility.

The one factor still in favor of appimage/portable, as opposed to snap, flatpak, or package manager, is that the appimage approach sits outside the system, and therefore isn't installed at all and can be deleted at will, or used between OS's.

I don't use any installed browsers for instance, and share my appimage/portable browsers between 7 different OS, that all run and all with my personal profile stored outside the systems themselves. So say a browser appimage folder is 700MB, divide that by 7 OS's and it just comes to 100MB.

[rockedge]

Why not just compile Okular on the system it will run on? I just half halfheartedly tried building it and came close first try.

Attempt on F96 = cmake version too old

Code: Select all

# cmake -DCMAKE_INSTALL_PREFIX=/opt ..
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  CMake 3.22 or higher is required.  You are running version 3.16.3


-- Configuring incomplete, errors occurred!

But on KLV with some coaxing will compile. And is going to be way way smaller, like around 16-18 MiB. This will get one version 22.12. From the Void Linux repo it's version 22.08 at this hour.

Absolute insanity and asking for trouble using Flatpak, SNAP and what those offer.

What is wrong with Okular 22.08? What makes 22.12 better?

[mikewalsh]

@wiak :-

Okular is, as you say, a KDE app. And that automatically means requiring the Dolphin file-manager (and related dependencies) along with the entirety of the Plasma desktop (and related dependencies).......because the KDE Project have built things in such a way that nothing will run without these two on the system. They are, if you like, "dependencies" for everything else.

The things are so tightly integrated it reminds you of the way Internet Exploder was impossible to remove from Windows, because it, too, was integrated with FileExplorer. But, there's the reason for the enormous size.....and is why all KDE 'portables' are so large. There's at least half of another OS within them.

There ARE a few exceptions to the rule. There always are. The KDE Project's screenshot tool, KSnip, is a featherweight at a 'mere' 24 MB.....and barely requires any KDE stuff at all. I use this quite a bit; it's rather similar to HotShots, with an integrated editor and the ability to auto-upload to image-sharing sites all built-in.

But at the end of the day, it's a simple case of 'horses for courses'. Use whatever works for you.....and what you're happy to have on your system. Nobody's gonna criticise your personal choices........think about it; who's in any real position to do so? And more to the point, why should anyone care?

Mike.

[rockedge]

@wiak @mikewalsh my solution to running Okular on F96_4-radky2-CE :
QEMU running KLV-Airedale-rc2 hosted by F96_4-radky2-CE. This is a qemu-vnc virtual machine and with TigerVNC-Viewer can be accessed on the host or any machine on the LAN that can run TigerVNC or any other VNC client.

Screenshot.gif (462.02 KiB) Viewed 1020 times

[wiak]

Why not just compile Okular on the system it will run on? I just half halfheartedly tried building it and came close first try
...
What is wrong with Okular 22.08? What makes 22.12 better?

Yes, compiling onto system is one sure way to fix matters, but I preferred to avoid it since using deb packages makes system maintenance more convenient for my business IT purposes.

In fact, my cherrytree 'memory' contained alternative I forgot about: KDE backports PPA:

https://launchpad.net/~savoury1/+archiv ... &start=900

which works fine.

I doubt there is much difference between 22.08 and 22.12 - so using KLV-Airedale makes matters particularly easy since Void Linux so up-to-date with everything, but at least also have Zorin lite 16.2 sorted out with Okular now and avoided these massive flatpaks and snaps.

Yes AppImage has its place being a one file totally portable solution. As I said, I use it for Ferdium and it is great for that, but Okular on it just too big.

@mikewalsh No, for Okular, though you do need some KDE libs and qt5, you do not need anything like full Plasma - Dolphin and so on is not required.

In the end I just stuck with the old Okular version 19.12.3 for Zorin (standard version for Ubuntu FocalFossa). Only needed 45MB compressed archives installed for that one on pristine Zorin, and good enough for my purposes.

[wiak]

@wiak @mikewalsh my solution to running Okular on F96_4-radky2-CE :
QEMU running KLV-Airedale-rc2 hosted by F96_4-radky2-CE. This is a VNC virtual machine and with TigerVNC-client can be accessed on the host or any machine on the LAN that can run TigerVNC

Actually that's a pretty neat approach to avoiding AppImages, Flatpaks, Snaps and so on, @rockedge, uses low resources really and provides a nice second and very powerful distro, which is also great for dev work, all at the same time! I should experiment doing things that way on Zorin too since gives me best of both worlds and on pretty powerful business machines anyway.

EDIT: what commandline do you suggest to start up KLV in QEMU? - I haven't been using QEMU for a whiile.

[rockedge]

@wiak Nice that you have it going on Zorin with the version that fits. I would bet without looking that F96 and QEMU running KLV combined still use far less of everything compared to Flatpak (odd name for it) SNAP and Co.

I have been using aqemu to setup QEMU mostly but it can create start scripts and of course show the arguments

Code: Select all

#!/bin/sh
# This script created by AQEMU
/usr/bin/qemu-system-x86_64  -smp 4 -soundhw ac97 -machine accel=kvm -m 4096 -cdrom "/mnt/home/KLV-Airedale-rc2.iso" -hda "/root/.aqemu/KLV_Airedale_rc2_HDA.img" -boot once=d,menu=off -net nic -net user -rtc base=localtime -name "KLV-Airedale-rc2" -cpu host -vnc 192.168.254.15:0 $*

[wiak]

@wiak Nice that you have it going on Zorin with the version that fits. I would bet without looking that F96 and QEMU running KLV combined still use far less of everything compared to Flatpak (odd name for it) SNAP and Co.

I have been using aqemu to setup QEMU mostly but it can create start scripts and of course show the arguments

Code: Select all

#!/bin/sh
# This script created by AQEMU
/usr/bin/qemu-system-x86_64  -smp 4 -soundhw ac97 -machine accel=kvm -m 4096 -cdrom "/mnt/home/KLV-Airedale-rc2.iso" -hda "/root/.aqemu/KLV_Airedale_rc2_HDA.img" -boot once=d,menu=off -net nic -net user -rtc base=localtime -name "KLV-Airedale-rc2" -cpu host -vnc 192.168.254.15:0 $*

Thanks, I'll investigate that Aqemu method and also I'll check out the Zorin tutorial: https://forum.zorin.com/t/qemu-and-virt ... setup/4178 (which uses Virtual Machine Manager)
and try your idea out in practice as an overall Snap, Flatpak, and even AppImage replacement methodology! You may well be correct that the whole thing could end up more resource efficient and certainly very flexible and specially in conjunction with tigervnc and similar.

[Clarity]

Hi @wiak
For @qemu please report on this command:

Code: Select all

qemu-system-x86_64 -boot d -m 2048 -enable-kvm -smp 2 -soundhw all -cdrom KLV-Airedale-CurrentVersion.iso

On your configuration after you get to KLV desktop, do you have sound active?

Further, does this boot KLV to the video desktop on your system, too?

Code: Select all

qemu-system-x86_64 -enable-kvm -m 2048 -soundhw hda -vga cirrus -smp cpus=2 -drive format=raw,media=cdrom,readonly,file=KLV-Airedale-CurrentVersion.iso 

Lastly, which version of QEMU did you install to your system.

P.S. Your VM's OS should run or appear to run FASTER than your host OS. And you can run as many VMs as you choose under your host.

[rockedge]

On your configuration after you get to KLV desktop, do you have sound active?

Yes. Audio works on both host and virtual machine.

I use either an FTP or samba connection between host and virtual machine so I can easily pass files between the two.

Your VM's OS should run or appear to run FASTER than your host OS

The qemu virtual machine running KLV-Airedale is very quick and responsive.

[Clarity]

...samba connection between host and virtual machine so I can easily pass files between the two...

Which qemu command string (stanza) do you use for your SAMBA connection? The feature in the QEMU GUI is broken. The VM is not started with the support needed.

And I should explain why I ask the question to @wiak: If IIRC his machine configuration was a little different from a manufacturer's edition. So I was curious of his results. I might be wrong on this, though.

Thanks for your results of those 2 commands.

[wiak]

...samba connection between host and virtual machine so I can easily pass files between the two...

Which qemu command string (stanza) do you use for your SAMBA connection? The feature in the QEMU GUI is broken. The VM is not started with the support needed.

And I should explain why I ask the question to @wiak: If IIRC his machine configuration was a little different from a manufacturer's edition. So I was curious of his results. I might be wrong on this, though.

Thanks for your results of those 2 commands.

Added to my priority list to-check @Clarity. Will take time to get round to it though since have Zorin fully configured now, but running KLV-Airedale in virtual machine is high on my mind at the moment (though going out for coffee right now...)

[Clarity]

@wiak, I am going to respond on the KLV thread as want to insure QEMU covers the communiity work there. We all know how valuable using a VM on all the 64bit modern machines from the past 15 years can be to both users and developers, alike. And with the phenomenal speed it provides, its use is pertinent.

See you on the forum, there.