On Mon, 8 Feb 2021 10:43:00 +0100 Andrea paz via Cin <[email protected]> wrote:

I use Arch Linux KDE (Rolling always updated, now with kernel 5.10.13 and glibc 2.33) I tested effects, transitions, Cuts with drag and drop, videoscopes, OpenEDL, Nested clip and proxies. All OK for both "newer" and "older". From now on I will use only the newer. Great job! Thanks MatN.

Stupid question: The sources size is 137MB, the AppImage is 79MB; shouldn't the size of the AppImage be much larger?

The source size is typically (much) bigger that the resulting program, a CinGG distribution is like 60 MByte. The beauty of AppImage is that increases portability at the expense of some size. The various portability versus size solutions, in order of size (as per my current understanding): - Executable set up for dynamic linking (external libraries (.so files, in Windows these are .dll files) linked at startup time. Smallest executable, but dependent on (versions of) libs available on the platform. So older/newer platforms could have different versions of libraries, with slightly different functionality. In Windows this used to be known as DLL hell. - Executable set up for static linking, including much of the external libraries, so less dependent on platform-specific versions of availability. Because CinGG already does this anyway, a dynamic or static build does not have a difference in size as far as I know, but I have not looked at that in detail. - AppImage. This includes the executable, plus an environment of even more external libraries, reducing the dependence of the underlying system even further. It does not include the graphical environment. Because CinGG already includes so many, the increase in size is not too bad. The disadvantage is that it might not be able to use the newest versions of system libraries, but it is much more portable. An AppImage is a specialised .zip file, if you add the extension .zip you can see what is inside with your archive manager. - Docker containers. These are interesting. Basically they are a whole Linux system with the exception of the lowest layers. When you make one of the existing ones, you specify what they should be based on (like Fedora version xxx), and it builds a specialised image as a container. This large file is stored somewhere locally, but afterwards can be started VERY quickly. I think they are smaller that a Flatpack. For instance, two containers for testing Joomla (that is an Apache webserver + Joomla, and MySql) together take 750 MByte. Containers are very handy for testing an AppImage, and I used them for that. But if you use a not-already-constructed container, it is more work. For some overview, see https://www.docker.com/resources/what-container . - Flatpack/Snap. These includes much more, like parts of the graphical environment, so the application using this can look different from those "native" of the platform. These are easily 700 or more MByte in size, yesterday I cam across one that would take 2.2 GByte of disk space! - A special case is Microsoft's Windows Subsystem for Linux version 2 (WSL2). This is like a container, but the lowest layers are implemented by a software layer (Hyper-V) that maps them to low-level Windows services. These require specialised versions of Linux distro's like Ubuntu to be installed, without the kernel things. I don't know if you can make an "application" like thing out of it. Don't know how big such a WSL2 instance is. But because you have to install an almost complete Linux first, it is not likely small nor quick to start. - Virtual machines (VMs). These emulate the hardware of a whole computer, and you install a complete OS in a ¨instance" of it. They are slightly slower to start than native on the hardware, but because their storage is a file and not a partition on a hard disk, you don't need more storage space than it actually takes. For instance, A VirtualBox VM of Mint 19.3 XFCE takes < 8G. Very handy for trying different distributions, e.g. if CinGG works well on some distributions. They are much more flexible than containers. In theory, you can make an application specific VM, which then could be distributed, but when I tried that with CinGG it didn't work well (I forgot what it was, and they are too big, 8G or more). There are virtual machines that can emulate other hardware, like QEMU. VirtualBox only does x86 32 or 64 bit hardware. And special interfaces like VAAPI, OpenGL, OpenCL or CUDA might not be supported, so a program running inside a VM cannot use such features. Note 1: There might be some limitations with AppImages as compared to a native executable, like command line interfaces. Have not looked at that yet. Note 2: I just noticed that my Synaptic package manager lists CinGG as taking up 179 MByte storage space. The AppImage is half the size, although slightly larger to download, and slower to start. Interesting. Mat Nieuwenhoven

El lunes, 8 de febrero de 2021 09:58:06 -03 mat via Cin escribió:

- Virtual machines (VMs). These emulate the hardware of a whole computer, and you install a complete OS in a ¨instance" of it. They are slightly slower to start than native on the hardware, but because their storage is a file and not a partition on a hard disk, you don't need more storage space than it actually takes. For instance, A VirtualBox VM of Mint 19.3 XFCE takes < 8G. Very handy for trying different distributions, e.g. if CinGG works well on some distributions. They are much more flexible than containers. In theory, you can make an application specific VM, which then could be distributed, but when I tried that with CinGG it didn't work well (I forgot what it was, and they are too big, 8G or more). There are virtual machines that can emulate other hardware, like QEMU. VirtualBox only does x86 32 or 64 bit hardware. And special interfaces like VAAPI, OpenGL, OpenCL or CUDA might not be supported, so a program running inside a VM cannot use such features

Hi Mat. we can have graphics acceleration in virtual machines. it just takes a little more work and also the type of hardware to use. example. PCI GPU passthrough in the excellent arch wiki there is good information https://wiki.archlinux.org/index.php/QEMU/Guest_graphics_acceleration https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF Thanks for the AppImage -- - | Walter Casanova | - - | Gnu / Linux - SysAdmin | -

Andrea, I use Arch Linux KDE (Rolling always updated, now with kernel 5.10.13

and glibc 2.33) I tested effects, transitions, Cuts with drag and drop, videoscopes, OpenEDL, Nested clip and proxies. All OK for both "newer" and "older".

Thanks for a much more inclusive test than what I did.

From now on I will use only the newer.

BUT, I hope you continue to do your builds and GIT checkout because that is where the early testing is most needed to find bugs before they go into appimage (which will only be created maybe monthly so will not have latest mods).