Take a look at

https://appimage.org/

Is this possible for Freepascal and Lazarus?

Yes, of course. It's even quite easy for vanilla FPC apps.

It's nothing but a zip with the needed dependencies. A vanilla FPC app doesn't need any libraries (unless you link them in). I imagine that for Lazarus it's also quite easy, since the needed libs are known.

I suspect the idea is taken from MacOS, where apps are bundled in a similar way.

Michael.

Though I'm not able to help you, it seems to be similar to https://www.docker.com/. Though docker apps can run on other platforms like windows and mac as well.

Rgds, Darius

Michael Van Canneyt wrote

It's nothing but a zip with the needed dependencies.

More precisely, they use a standard ISO image that gets loop mounted. Simply rename any *.AppImage application with a .iso extension and you can examine the directory structure and content.

This is nothing new really. Linux has had many such attempts over the years. Anybody remember AutoPackage, Zero Install and others? I think Snappy from Canonical was the last of them took
hold in the don't really know why - I have always thought "app bundles" was a good idea. Maybe 10th time lucky - after all, this is the year of Linux. ;-)

I suspect the idea is taken from MacOS, where apps are bundled in a similar way.

Yeah, it looks or sounds similar, but like I said, this was done a few times before on Linux already.

Regards,
Graeme

Am 16.01.2018 00:50 schrieb "Graeme Geldenhuys" <

:

Michael Van Canneyt wrote

It's nothing but a zip with the needed dependencies.

More precisely, they use a standard ISO image that gets loop mounted. Simply rename any *.AppImage application with a .iso extension and you can examine the directory structure and content.

This is nothing new really. Linux has had many such attempts over the years. Anybody remember AutoPackage, Zero Install and others? I think Snappy from Canonical was the last of them took hold in the don't really know why - I have always thought "app bundles" was a good idea. Maybe 10th time lucky - after all, this is the year of Linux. ;-)

Maybe because each app will have its own dependencies, thus duplicating code.
Also if you have different versions of dependencies they might access shared global configuration in incompatible ways.
Not to mention that if there is a (security) bug in one dependency you need to update all apps containing the bugged library instead of merely the library (that is if you can easily find out that an app contains that library).
So, yeah, I'm definitely skeptical about such approaches.

Regards,
Sven

For me the andvantage of the easy installation is higher.

You can leave the base Linux system as it is.

But if you want to install a hand full of special Apps you can do it fast. If there is a security bug, then (easy) update your hand full of Apps.

If I make an App I do it always in a separate directory with minimum dependencies. So you have it easy and a have good overview of the needed app and data files.

Sven Barth wrote

So, yeah, I'm definitely skeptical about such approaches.

All valid points. But if it was such a big concern, then why was Apple happy to go with it. Maybe the concern is not so bad. As for bigger apps (due to bundled dependencies).... That might have been a concern years back, but nobody seems to care now about large apps. Hell, even websites are now 5+MB per page downloads (massive JavaScript libraries, huge high-res images etc). View a few pages and you have downloaded some 50MB easily.

Regards,
Graeme

I think because Apple's base system is very stable and well controlled. In the linux world, this is not so. The challenge is therefor bigger.

Michael.

Yes.

This is a very understandable constructive propagation. Everyone who can think right, especially from the view of a user should say, yes it is easy and good.

And yes, memory is enough there today. Since some years already.

My way is always a separate directory with all in it and an entry application.

And the key is to try to generate as less dependencies as possible.

Better less functionallity but almost working and extensible than an obstructive dependency.

Rainer Stratmann wrote

And the key is to try to generate as less dependencies as possible.

Yup! Welcome to my world.... [see fpGUI Toolkit]. ;-)

Regards,
Graeme

Am 16.01.2018 20:41 schrieb "Graeme Geldenhuys" <

:

Sven Barth wrote

So, yeah, I'm definitely skeptical about such approaches.

All valid points. But if it was such a big concern, then why was Apple happy to go with it. Maybe the concern is not so bad. As for bigger apps (due to bundled dependencies).... That might have been a concern years back, but nobody seems to care now about large apps. Hell, even websites are now 5+MB per page downloads (massive JavaScript libraries, huge high-res images etc). View a few pages and you have downloaded some 50MB easily.

Because here Apple simply enforced it. This won't work in the more diverse Linux world where users are more free to decide.

Regards,
Sven

Sven Barth wrote

This won't work in the more diverse Linux world where users are more free to decide.

But if you take a closer look at this (diverse) that is some kind of pseudo free and decide.

It would be technical no such problem to make some compatibility between the distributions. I am not deep in the KDE and Gnome development, but I wonder why it is not possible to make compatibility between them. That prevents a progress which is long overdue. Instead of they are fighting against each other who has the better window manager.

Also it is not a lack of choice if you put for example two distributions in one and make it possible to behave either like distro1 or distro2 by a checkbox. Or better to make it behave like distro1 and distro2. I guess that would be also technical possible.

Sven Barth wrote

Because here Apple simply enforced it. This won't work in the more diverse Linux world where users are more free to decide.

I fully agree. And explains why all previous attempts and such "app bundles" have not succeeded in the Linux space.

Regards,
Graeme

Rainer Stratmann wrote

Instead of they are fighting against each other who has the better window manager.

And that is what I love, and why we have such great Linux desktop environments. Competition drives innovation. Just compare it to the cr*p Windows 10 interface or MacOS interface. At one stage the latter two were all about consistency, Human Interface Guidelines across the board etc. Now they are the most inconsistent environments of all, and by far the most bland and uninspiring! Yes, I work on FreeBSD, Windows and MacOS on a daily basis, so it is very easy for me to compare them all.

Linux package managers have made great strides in easing the installation of software. I always felt "app bundles" could be an addition to that, but it seems most of the community don't agree. Then again, things evolve over time, so maybe there is a possibility this time round.

Regards,
Graeme

Am 16.01.2018 22:58 schrieb "Rainer Stratmann" <

:

Sven Barth wrote

This won't work in the more diverse Linux world where users are more free to decide.

But if you take a closer look at this (diverse) that is some kind of pseudo free and decide.

It would be technical no such problem to make some compatibility between the distributions. I am not deep in the KDE and Gnome development, but I wonder why it is not possible to make compatibility between them. That prevents a progress which is long overdue. Instead of they are fighting against each other
who has the better window manager.

KDE and Gnome use two completely different toolkits, namely Qt and GTK, so if course they aren't compatible to each other. Same for other like Enlightenment and what else is there. And then there are users like me who *only* use a window manager and no desktop it is not a lack of choice if you put for example two distributions in one and make it possible to behave either like distro1 or distro2 by a checkbox. Or better to make it behave like distro1 and distro2. I guess that would be also technical possible.

But there aren't just two distributions. There are many. And if one would do what you suggest then we would simply have one more distribution. Not to mention that it isn't as simple as you make it out to be. Let's take Debian and Gentoo or ArchLinux for example. The first is a very stable release and updates are checked and checked again before they're added to packages while the other two are rolling releases close to the bleeding edge of the upstream software and on Gentoo also compiled to the user's wishes. Combining these two... well... worlds would essentially look like this: namely a selection of the one or the other during boot with maybe a shared data partition.
Thus nothing gained here either.

The world of Linux distributions is simply too diverse for something like this. Everyone simply picks the distro one likes best and we're done.

Regards,
Sven