Tdesktop: telegram appimage

[kskarthik]

I made appimage for telegram which i believe is better packing format than your existing one for linux.

Download: https://www.dropbox.com/sh/r46jrd6t6k28myq/AAChgJdZT5yaB0d1bZt6OVCaa?dl=0

Advantage: Only one file to run no need to extract the zip & updater binary can be included inside appimage. Please let me know your opinion.

Thank you :smiley:

[stek29]

It's awesome!
Now please make a PR which allows to build appimage...

[kskarthik]

Well, @probonopd can you help me with this ?

[diazbastian]

@kskarthik What is the real advantage of using AppImage above the current distribution system?

AppImage seems a good distribution system, however, does not offer advanced features such as sandboxing. Besides the "universality" of AppImage is reduced to recent versions of the Linux desktop. Compared to the current distribution system, at least I see no advantage to warrant the effort.

There are other current alternatives with great potential with advanced features including enhanced security through sandboxing:

• GNU GUIX: It is fantastic, however, it specializes in providing free software only, which makes it unfriendly to developers (to be popular) and is unfriendly for the end user (usability).
• Snap: Canonical development. It was recently released for the desktop. Has good targets, however, it seems that is about half development, design leaves little to be desired and has dependencies that make it very hard to make it work outside Ubuntu. (really)
  Currently, Telegram is already distributed in a Snap package, thanks to an employee of Canonical.
• Flatpak (aka xdg-app): It is my favorite distribution system, completely independent of the distro (despite their origins) and is currently accessible to the most popular distros. It is still in development, but it is very promising options and ease of use. Some organizations opt for use, as TDF with LibreOffice.

I'd like much Telegram, to be distributed with a system that allows sandboxing (Flatpak please 😍). Would gain much security at least gnu/linux, however, I doubt that it is a priority task.

[probonopd]

AppImage seems a good distribution system, however, does not offer advanced features such as sandboxing.

I am working on sandboxing, see
https://github.com/probonopd/AppImageKit/tree/master/sandbox
and
https://www.youtube.com/watch?v=7C9thHXPZd8
(your input is welcome!)

Besides the "universality" of AppImage is reduced to recent versions of the Linux desktop.

AppImage is just a bundle format. The binaries inside the AppImage have the distro requirements that the binaries have. Snap and Flatpak download extra dependencies as "runtimes", which makes these systems quite a bit more complex as you need some sort of a dependency manager.

[diazbastian]

I am working on sandboxing, see

Yeah, I know... However, that is only one of the desired advanced options (and bubblewrap is great). As a portable application would fulfill its purpose, however, the alternatives offer that and more today.

AppImage is just a bundle format. The binaries inside the AppImage have the distro requirements that the binaries have. Snap and Flatpak download extra dependencies as "runtimes", which makes these systems quite a bit more complex as you need some sort of a dependency manager.

Even to use safely AppImages applications you need to install additional software. It is paid for the security price. Snap and Flatpak are a bit more complex, but thanks to that offer greater options package management. For example, updates will be direct and fast... at least make things easier for the end user and may install/update their applications at a click away.

AppImage is a solution with a very different perspective and as a portable app is excellent, however, think Flatpak be a system more accessible in the future as alternative app distribution (installation directly from the software store).
Is it necessary now? I do not think so. But only third parties can distribute Snap or Flatpak currently safely.

@kskarthik Maybe it's a good idea to change the title to "Add alternative distribution system for GNU/Linux". Windows has a portable application and OS X has an alternative download from the AppStore.

[probonopd]

For example, updates will be direct and fast

AppImage can do that too, even faster and easier:
https://github.com/probonopd/AppImageKit/blob/master/AppImageUpdate.AppDir/README.md

[diazbastian]

Sorry @probonopd, but is not the same. I know the AppImage implementation. AppImageUpdate makes things a little more complex things for the end user. What are the advantages over the current Telegram distribution system, including client updates? ... Not much

Telegram is currently simple and "portable". So I think it would be interesting to discuss an alternative application distribution system, however, I see no interest from developers.

[probonopd]

Indeed Telegram is already now doing an excellent job in upstream-providing binaries for Linux. Wish the same could be said for every open source project.

[diazbastian]

Yeah, Telegram Desktop is very efficient, so I think AppImage is not necessary now and alternatives should be discussed in the future.

[grulja]

I managed to create a flatpak manifest for telegram desktop client. In case you are interested see http://www.jgrulich.cz/2016/07/08/telegram-desktop-client-for-flatpak/.

[shoogle]

AppImages are just self-contained executables, so the current distribution mechanism is practically an AppImage already. Simply rename the Telegram static binary to Telegram.AppImage and voila!

However, to get the advantages of the latest "Type 2" AppImage specification, such as integration with application menus and the desktop environment, you would actually leave the binary alone and instead:

1. Swap the xz archive for a self-extracting squashfs container.
2. Name the container Telegram-x86_44.AppImage.
3. Add an icon and .desktop file.

linuxdeploy creates the squashfs container and names it for you. The icon and desktop file can be taken from existing Linux packages.

It would take a bit more effort to get the updater working, but not much! Presumably Telegram would check for updates the same way it does now and then the Updater would simply update the container rather than the binaries. (The Telegram and Updater binaries would be included inside the container.)

[arielnmz]

I personally dislike AppImage because you end up with tons of *.AppImage files in the downloads directory, plus, it doesn't really offer a way of managing apps like flatpak does (similar to packaging systems), plus, each app has to have code to check for updates and has to bundle all dependencies in the "img" (bloat).

[probonopd]

Other people like it for exactly those reasons. Hence, it's good that different formats exist for different use cases. Regarding "bloat" I challenge you: The other formats are not more efficient at all.

[shoogle]

@arielnmz, all of the "downsides" you mention apply to Telegram's existing distribution mechanism, but for good reason. Telegram has taken a "do it ourselves" approach because they don't want to deal with the multitude of packaging systems available on Linux: they just want one package that works on all systems. AppImage is simply a standard way to provide just that.

By the way, the "bloat" and "disorganisation" is not inherent to the AppImage format. AppImage are stored compressed so they often take up less space than equivalent distribution packages, and tools like AppImageLaucher exist to organise and update AppImages for you. However, the main advantage of the format is that it works even when these management tools are not present, just like .app on Mac or .exe on Windows.

[diazbastian]

Telegram has taken a "do it ourselves" approach because they don't want to deal with the multitude of packaging systems available on Linux

@shoogle Sorry, but some time ago the versions for flatpak and snap are official.

[shoogle]

@diazbastian, those are not the only packaging systems on Linux. But my point was not a criticism, far from it! I use AppImage myself because I do not want to deal with the multitude of packaging systems on Linux. That is the purpose of AppImage.

[arielnmz]

Other people like it for exactly those reasons

I doubt people like having tons of files just lying around, each checking for updates whenever they see fit and doing god-knows-what kind of voodoo to integrate with the desktop, possibly leading to fragmentation. At least the people that know what they want. I think AppImage's model is for people who just don't bother, like the ones that already use Windows or Mac OS. That's exactly the reason I switched to linux, because it gives me control, like flatpak or a decent package manager does.

Regarding "bloat" ...

It's not about efficiency, why would an app bundle its own code to install, update and check for updates? That's bloat, aka unnecessary stuff. I think it's the job of the platform to define where goes what, and I think it's just better to delegate that part of the job to whoever does it best.

But that's just my 2 ¢

[probonopd]

I think AppImage's model is for people who just don't bother, like the ones that already use Windows or Mac OS.

Yes, especially Mac OS X.

That's exactly the reason I switched to linux

And I exactly want Linux to be more like Mac OS X. Not needing a package manager.
Those are just my 2 ¢. The point: It always depends on your viewpoint and on your needs.

[arielnmz]

But what's so bad about using a proper package manager? Also, aren't windows and Mac OS already switching to package-manager like environments (aka app stores)? What does the concept of "self-bundled" apps do better than system-managed packages?

[probonopd]

But what's so bad about using a proper package manager?

It's not "bad", but some people (me included) find it way easier to use drag-and-drop in the file manager (Finder), e.g,, to achieve things like:

• Keep different vesions of applications in different directories (folders)
• Put an application on a local file server
• Copy an application to a USB stick
• Delete an application by just moving its icon to the trash
• Copying a whole bunch of applications at once
• Use applications on Live ISOs
• Use the same set of applications with multiple Linux distributions, without having to re-download the applications for every distribution
• Put applications on various external drives because the boot disk is full

and so on.

Also, aren't windows and Mac OS already switching to package-manager like environments (aka app stores)?

Apple and Microsoft are trying to push this model, and as a result, making things much more complicated. Which is why we need a good Linux desktop alternative.

What does the concept of "self-bundled" apps do better than system-managed packages?

See above.

[shoogle]

@arielnmz, I agree with all that you are saying. It is nice to have a package manager make decisions for you in terms of where to put things, when to install updates, etc. However, there is no single definitive package manager for Linux like there is for Windows and Mac, so developers end up having to choose what they are willing to support. Also, some people prefer to organise things differently, or have different requirements (e.g. distributing programs via torrents or USB sticks because their internet is slow, unreliable, or censored).

Ultimately this is not about which approach is better. As @diazbastian pointed out, Telegram already offers Flatpack and Snap packages. Nobody is arguing that should change.

However, as I pointed out, Telegram already offers something that is almost an AppImage. So why can't we make the small changes necessary to turn it into a fully-fledged AppImage?

[lucypol]

Appimages can be sandboxed, even says so on the website, they even suggested "firejail", a package does not need to have sandboxing itself, it should be optional, and you can run it in a sandbox if you wish, install a sandbox and run it within it.

There should be separation between runtime environment of a sandbox and a package, this is the Unix/Linux way, separation of purpose, stop fudging concepts into one and turning things into bloatware