Appimage

Golang goes a step farther than just bringing its libraries in a binary. They can carry arbitrary files in a virtual filesystem inside the executable.

Compare that to all the crap you have to drag around for a Python program. No wonder people ship a whole copy of the developer's machine. Well, without the debugging tools, but that's another issue.
 
cracauer@ said:
Compare that to all the crap you have to drag around for a Python program.
Click to expand...
Arguably this would also be improved if python developers learned a bit more about release engineering.

Running a bunch of pip commands and fetching some random clutter from the internet is not release engineering. They should notice that when they install any other piece of software, they don't need to do this.
 
kpedersen said:
Arguably this would also be improved if python developers learned a bit more about release engineering.

Running a bunch of pip commands and fetching some random clutter from the internet is not release engineering. They should notice that when they install any other piece of software, they don't need to do this.
Click to expand...

There are packagers for Python that are used to cons up single executables from Python programs and libraries. But they aren't official. They are also used as obfuscation so that people can't easily read the source code.
 
cracauer@ said:
There are packagers for Python that are used to cons up single executables from Python programs and libraries. But they aren't official. They are also used as obfuscation so that people can't easily read the source code.
Click to expand...
Yep, so it really should be quite easy for developers to do this.

I recall .exe makers for Java too. Useful mainly because .jar files were almost always incorrectly registered on Windows systems and the various .bat files almost always failed too.
 
  • Thanks
Reactions: mer
cracauer@ said:
I haven't used them myself but I hear that these packagers are quite fuzzy and behave differently on different platforms.
Click to expand...
So long as they are more deterministic than the random list of instructions that typically come with large python programs (usually just for one or two of the main platforms), I don't see this as a deal-breaker. But until the tools evolve, they can just automate release-engineering like we tend to do with C and C++.
 
Sorry to reuse this (relatively) old thread, but the name probably will permit the future users to find the information more simply.
With recent efforts of FreeBSD Foundation we expect more desktop/laptop users will come to FreeBSD world. So, the question of running some 'not FreeBSD friendly' software will come back. For example, there are tons of different software based on Electron. As Chrome and Electron do not support FreeBSD natively, we have no chance that all this software will be ported to FreeBSD. Sure, thanks to some FreeBSD devs, Chromium and some most known projects have FreeBSD ports (for example, VS Code). But without the support of Electron developers we'll never be able to have many useful applications running on FreeBSD. So, AppImage format, used by (almost) all Electron based project would really help FreeBSD users to get their favorite software running.

I would like to know if there is a known source of information about running AppImage based software on FreeBSD. I propose to all users who have such information to post it here.

As for me - I'm searching for a way to run Joplin Desktop on FreeBSD. This is an Electron software in AppImage format...
 
cracauer@ said:
Do you subscribe to one mailing list per appimage that you install?
Click to expand...

Since almost all of them are on github I subscribe to the rss feed of the release page, which gets checked every six hours so get notified when new release is done. Before even thinking of downloading one I check the release history to ensure it is not one hit wonder you see in so much of open source. The person who put out the one release or so then nothing since. I also look for gpg signed files when you are downloading them or at the least a md5sum. Not a lot of them crypto-graphically sign their appimages so that is harder to find. Snap or flatpaks I am not interested in those garbage solutions pushed by parasite corporations looking for vendor lock in. If I wanted that I would be making my life easier using a Mac or Windows.
 
Peter2121 said:
Sorry to reuse this (relatively) old thread, but the name probably will permit the future users to find the information more simply.
With recent efforts of FreeBSD Foundation we expect more desktop/laptop users will come to FreeBSD world. So, the question of running some 'not FreeBSD friendly' software will come back. For example, there are tons of different software based on Electron. As Chrome and Electron do not support FreeBSD natively, we have no chance that all this software will be ported to FreeBSD. Sure, thanks to some FreeBSD devs, Chromium and some most known projects have FreeBSD ports (for example, VS Code). But without the support of Electron developers we'll never be able to have many useful applications running on FreeBSD. So, AppImage format, used by (almost) all Electron based project would really help FreeBSD users to get their favorite software running.
Click to expand...
Edit rc.conf:
Code: 
sysrc linux_enable="YES"
service linux start

Enter on shell: 
pkg install linux_base-c7

Download the appimage.

Code: 
chmod +x Joplin-*.AppImage

./Joplin-*.AppImage

Done, this should do the trick.
 
Re Rust, on their main "medias" such as the Reddit group, they are hell bent to call anyone almost stupid to use a OS package manager.

(they also promote the "curl | sh" way of installing...)

One of the primary arguments is - "Rust and crates in the distro packages are used to build the distro and thus will remain stale".

If that doesn't give you enough ammo for the argument that internally package managed language has no place being an operating system language, I don't know what does.

Now as somebody that works in Rust I appreciate the FreeBSD way way-more because there is no confusion of this sort. No FreeBSD byte has been Rust-compiled, therefore Rust is free to live as a 3rd party application the way it wants. I'm using our quarterly packages and all my cargo is fresh.
 
Zare said:
Re Rust, on their main "medias" such as the Reddit group, they are hell bent to call anyone almost stupid to use a OS package manager.
Click to expand...
Aww, those poor little sweethearts have never had to do cross platform development before. They just call into a "clever" C library (through various bindings) that does this difficult work for them.

So its fair that they wouldn't know or understand about OS specific patches for platforms outside of Win/Mac/Lin that naive tools like cargo or crates.io have no infrastructure to handle.
 
You must log in or register to reply here.
Back
Top