Appimage

DanielBowman

DanielBowman

Can someone enlighten me, why is not Appimage used on FreeBSD?
Is there some some fundamental difference to Linux?
I tried to ask it's author (probono) on X (fka twatter) but didn't want to sound like ungrateful ahole...he answered something else and I did not want to waste his time.
 
Because we don't need it?

DanielBowman said:
Is there some some fundamental difference to Linux?
Click to expand...
For one, there are a million and one different Linux distributions (all fundamentally different in some way), and there's only one FreeBSD. On different Linux distributions critical dependencies can have vastly different versions, while on FreeBSD all supported versions use one and the same ports tree. Exactly the same third party software (and the same version of that software) is available for all supported versions.
 
SirDice said:
Because we don't need it?


For one, there are a million and one different Linux distributions (all fundamentally different in some way), and there's only one FreeBSD. On different Linux distributions critical dependencies can have vastly different versions, while on FreeBSD all supported versions use one and the same ports tree. Exactly the same third party software (and the same version of that software) is available for all supported versions.
Click to expand...
What if the sought after software is not (yet) in ports - the creator might be OK generating AppImages but not dealing with porting process.

Given the uniformity of FreeBSD it should be much easier to create the AppImage, no?
 
DanielBowman said:
What if the sought after software is not (yet) in ports - the creator might be OK generating AppImages but not dealing with porting process.
Click to expand...
I come from the Linux world and I think they are making a mistake with Appimage, Snap or Flatpack: yes, it is easier for a application to run on your computer if the developer dedicates themselves to creating an image of it, but you are losing the security of official repositories because the developer is improving their application, not checking if one of the libraries they compiled the application with and included in the package has a vulnerability. You are also duplicating libraries, and the application won't work as well as those in repositories. In the end, you have more applications, but they perform worse, and developers will start prioritizing their packages over the repositories. This already happens with cargo in Rust or pyp in Python, where you have to install packages that have not been audited by anyone of FreeBSD team.
I am in favor of things I do not use if it will help other FreeBSD users (I recently said in a thread that I do not like Linuxulator, but as long as it does not affect the performance of the base system and since many users want improvements, go ahead), but I think this worsens the future of the operating system, and I cannot agree with it.
 
LoganGreystone said:
I come from the Linux world and I think they are making a mistake with Appimage, Snap or Flatpack: yes, it is easier for a application to run on your computer if the developer dedicates themselves to creating an image of it, but you are losing the security of official repositories because the developer is improving their application, not checking if one of the libraries they compiled the application with and included in the package has a vulnerability. You are also duplicating libraries, and the application won't work as well as those in repositories. In the end, you have more applications, but they perform worse, and developers will start prioritizing their packages over the repositories. This already happens with cargo in Rust or pyp in Python, where you have to install packages that have not been audited by anyone of FreeBSD team.
I am in favor of things I do not use if it will help other FreeBSD users (I recently said in a thread that I do not like Linuxulator, but as long as it does not affect the performance of the base system and since many users want improvements, go ahead), but I think this worsens the future of the operating system, and I cannot agree with it.
Click to expand...
I agree.
From the security perspective however, AppImage can be jailed/sandboxed more easily and then you don't even have to have those (maybe one day) vulnerable libraries installed in the system at all. And if the AppImage is not run as service (*cough* docker *cough*) I can live with running the vulnerable libraries from time to time from inside an image, maybe even jailed.
 
MrBSD said:
Which part of...

... you didnt understand ?
Click to expand...
I did not understand the "WE" part.
AppImage is useful piece of software technology. There ought to be more to it than 'Nah, we don't need it...that much.' And I wonder why - that is why this forum exists, no?

Especially if the Linux world switches to snaps and flats...and number of software developers who are willing to maintain/take into consideration FBSD ports, will dwindle.
 
LoganGreystone said:
I come from the Linux world and I think they are making a mistake with Appimage, Snap or Flatpack: yes, it is easier for a application to run on your computer if the developer dedicates themselves to creating an image of it, but you are losing the security of official repositories because the developer is improving their application, not checking if one of the libraries they compiled the application with and included in the package has a vulnerability. You are also duplicating libraries, and the application won't work as well as those in repositories. In the end, you have more applications, but they perform worse, and developers will start prioritizing their packages over the repositories. This already happens with cargo in Rust or pyp in Python, where you have to install packages that have not been audited by anyone of FreeBSD team.
I am in favor of things I do not use if it will help other FreeBSD users (I recently said in a thread that I do not like Linuxulator, but as long as it does not affect the performance of the base system and since many users want improvements, go ahead), but I think this worsens the future of the operating system, and I cannot agree with it.
Click to expand...
The Linuxulator is a nice piece of engineering.

Packaging is hard. Not even the largest Linux distros can manage the complexity. Python & Rust are the worst in this regard. Golang also introduces its own challenges being statically linked.

 
DanielBowman said:
I agree.
From the security perspective however, AppImage can be jailed/sandboxed more easily and then you don't even have to have those (maybe one day) vulnerable libraries installed in the system at all. And if the AppImage is not run as service (*cough* docker *cough*) I can live with running the vulnerable libraries from time to time from inside an image, maybe even jailed.
Click to expand...

Correct me if I'm wrong but a sandboxed AppImage still has access to the user's home directory, no? That makes the isolation mostly useless.

That makes occasionally living with vulnerable libraries a chore. Let's say libfoo-1.0 is vulnerable and libfoo-1.1 is fixed. You start out with 6 copies libfoo-1.0, 5 in appimages and 1 in the outer OS. How long will you have to wait for all 6 to be upgraded. And how will you learn about it? For the outer OS you get security notifications. For the appimages - ??? Do you subscribe to one mailing list per appimage that you install?
 
cracauer@ said:
Correct me if I'm wrong but a sandboxed AppImage still has access to the user's home directory, no? That makes the isolation mostly useless.

That makes occasionally living with vulnerable libraries a chore. Let's say libfoo-1.0 is vulnerable and libfoo-1.1 is fixed. You start out with 6 copies libfoo-1.0, 5 in appimages and 1 in the outer OS. How long will you have to wait for all 6 to be upgraded. And how will you learn about it? For the outer OS you get security notifications. For the appimages - ??? Do you subscribe to one mailing list per appimage that you install?
Click to expand...
I believe even with simple sandbox like jails you can limit the exposure of outer OS. I read about jailed firefox limited to ~/Download directory.

Maybe libfoo-XY is not even present in my outer OS at all. If critical vulnerability is discovered I do not need to wait for outer OS update - I either delete or sandbox the AppImage.
True, I might not even learn about the CVE or possibility of the fix. Therefore I will have the usecase for AppImage be - none on critical systems; limited on non-critical e.g. grannies desktop. And I can employ utility to check the vulnerabilities in AppDir AppImages for me. It can be done. Flatpacks have regular updates on Linux.
 
DanielBowman said:
I tried to ask it's author (probono) on X (fka twatter) but didn't want to sound like ungrateful ahole...he answered something else and I did not want to waste his time.
Click to expand...

Wishing AppImage technology just because an app is not in ports tells me that this approach is quite wrong.
Switching to another OS means also adopting its own technology, its philosophy, its way of doing things, if you can't then what is the point?
Just use a tool for what it can do, not for what you wish it would do.

If your favorite apps is not ported, I see 3 possible options:
1) ask kindly if someone can port it, or may be add your request here https://wiki.freebsd.org/WantedPorts
2) find an alternative app, more than often there is a solution.
3) if living without your app is really too difficult, switching back to your previous OS might solve the issue, there is no shame.
 
DanielBowman said:
Especially if the Linux world switches to snaps and flats...
Click to expand...
If it ever does, then perhaps you might want to resurrect this thread. No point doing it before. Likely it will fizzle out and no need to waste time with it.

DanielBowman said:
and number of software developers who are willing to maintain/take into consideration FBSD ports, will dwindle.
Click to expand...
FreeBSD ports are done by the FreeBSD community. There is nothing that Linux can do to dwindle that.
 
Why not go back to statically linked images and run them in a sandbox that has no access to any system level outside the sandbox?
 
gotnull said:
Wishing AppImage technology just because an app is not in ports tells me that this approach is quite wrong.
Switching to another OS means also adopting its own technology, its philosophy, its way of doing things, if you can't then what is the point?
Just use a tool for what it can do, not for what you wish it would do.

If your favorite apps is not ported, I see 3 possible options:
1) ask kindly if someone can port it, or may be add your request here https://wiki.freebsd.org/WantedPorts
2) find an alternative app, more than often there is a solution.
3) if living without your app is really too difficult, switching back to your previous OS might solve the issue, there is no shame.
Click to expand...
Well, that was not my point - I certainly do not need or want AppImage. I simply wonder why AppImage is not adopted, especially if one of it's creators is no stranger to FreeBSD. If there is some fundamental obstacle, maybe. From what I gathered form gihub posts, kindly provided by T-Deamon, there were some hiccups around squashfs etc.
 
DanielBowman said:
I agree.
From the security perspective however, AppImage can be jailed/sandboxed more easily and then you don't even have to have those (maybe one day) vulnerable libraries installed in the system at all. And if the AppImage is not run as service (*cough* docker *cough*) I can live with running the vulnerable libraries from time to time from inside an image, maybe even jailed.
Click to expand...
You can run vulnerable software in jails: it is not as convenient because you have to create the jail and compile the application, but it is more isolated.
T-Daemon said:
AppImage support for (Free)BSD is being worked on:

Consider adding support for FreeBSD #126

. https://github.com/search?q=org:AppImage+FreeBSD&type=issues

. https://github.com/search?q=org:AppImage+FreeBSD&type=pullrequests
Click to expand...
I had not read it, so everyone was happy, :) .
 
LoganGreystone said:
I come from the Linux world and I think they are making a mistake with Appimage, Snap or Flatpack: yes, it is easier for a application to run on your computer if the developer dedicates themselves to creating an image of it, but you are losing the security of official repositories because the developer is improving their application, not checking if one of the libraries they compiled the application with and included in the package has a vulnerability.
Click to expand...
I agree with this part 100%.
DanielBowman said:
I did not understand the "WE" part.
Click to expand...
We, the freebsd users.
DanielBowman said:
AppImage is useful piece of software technology. There ought to be more to it than 'Nah, we don't need it...that much.' And I wonder why - that is why this forum exists, no?
Click to expand...
I was using linux for almost 15 years now, and i never EVER used flatpak/snap or appimage. Im strictly against those "technologies" because the whole concept is just bad. If the package doesnt exist in the official repo or i cant compile it myself, i will simply not use that aplication. I dont want to adapt to that nonsense. Im also against compatibility layers like wine. If the application can not run natively, i dont use it.
DanielBowman said:
Especially if the Linux world switches to snaps and flats...and number of software developers who are willing to maintain/take into consideration FBSD ports, will dwindle.
Click to expand...
Linux world can be described with one word. Chaos. You have snap/flatpak/appimage nonsese, different kinds of init systems, tons of different distributions with different kinds of package managers. Just look whats happening with arch linux user repositories that are full of malware. Not to mention continuous ddos attacks. Its just drama and chaos. Im tired of all that. I found peace with freebsd. I dont need linux cancer in any shape or form on my system. And im sure i speak for many people on these forums when i say, we dont need that.

Cheers.
 
Things like AppImage and container images are the opposite of what the shared dynamically linked libraries and package managers do. I always found that very odd, how the same people critical of static linking are fine pushing Docker. They claim it's bad, difficult to update, inefficient, and insecure to build the binaries in that way. Yet it's totally fine to ship a copy of the entire system in a image.

It boggles my mind. Why not just keep it simple and use static builds.
 
mer said:
Why not go back to statically linked images
Click to expand...

tuaris said:
keep it simple and use static builds.
Click to expand...
I agree with you both. I actually have a feeling that many developers don't know what this is these days....

There is some argument that it restricts you from replacing the lib with a "fixed" version later on but AppImage/Snaps and all that crap needs a regen of the package to do equivalent so its safe to say that a relink of the binary is also fair game in that case...

A client *was* going to use RockyLinux, so I made a package aggregator (dnf_bundle) to propose instead of the usual suspects that their junior developers (really just analysts with python knowledge) were leaning towards (AppImage/Docker/Snaps). But luckily they moved away from Linux entirely. So ultimately, even if no static linkage; just bundle the damn libs and run that in a Jail, or even chroot.
 
mer said:
And there are those of us that still remember the static to dynamic transition :) "The good old days".
Click to expand...

That static build ship sailed with Object Oriented Programming or more precisely GUI and the myriad of changing libraries it entails.
You would not fit the executable in to memory - with all due respect to your computer rig.
 
mer said:
Why not go back to statically linked images and run them in a sandbox that has no access to any system level outside the sandbox?
Click to expand...
This is what Golang & Docker did. But static & shared have all their pros and cons.

And we're also talking about interpreted languages dependencies. Packaging Python dependencies is a nightmare.
 
DanielBowman said:
That static build ship sailed with Object Oriented Programming or more precisely GUI and the myriad of changing libraries it entails.
You would not fit the executable in to memory - with all due respect to your computer rig.
Click to expand...
So the idea was that dynamic libraries are loaded *once* and shared by multiple processes. Only if they are the same version.

AppImage/Snaps/Docker/etc provide different instances of the same dynamic library, of different versions. So in many ways this has proven that static linking (as is done by Golang by default, which google provides strong rationale for) is perfectly feasible.
 
You must log in or register to reply here.
Back
Top