AppImage "integration"?

[whoami]

I just wonder if it would make sense to have a special section in the Q-launcher menu for AppImages. Since AppImages are standalone programs they should run easily in minimal templates (to my silly knowledge about mini templates).

What do you think?
Could this help non-advanced users to by-pass the manual work to setup minimal templates?

[enmus]

Well, I am almost sure people tend to have same AppImages in different VMs (I’d do for security and privacy reasons), which should be kept on mind regarding confusion and/or cluttering.

We will anyway have new launcher, so its Favorite section seems the best place to me for such needs. Allowing to create folders in favorites would be logical step ahead, so I will just suggest it on the correspondent topic, hahah.

[whoami]

Wow, what a thread

Curl-proxy / wget-proxy scripts in Templates so users can add GPG distro keys linked to added external repositories

Updates Edit: Extended PoC of this idea is here. This is the blocking version (where non-networked TemplateVM will not translate curl/wget to curl-proxy/wget-proxy in the wrapper scripts. Edit2: PoC code download here Edit3: A non-blocking example for curl-wrapper automatically translates curl calls to curl-proxy calls under this post. Edit4: No go. MOTD is a better approach. Proxy with static port is now considered risky by thread participants. @deeplow @unman I created issue Deploy curl-…

@Insurgo

In the past I had these issues to install Signal. My solution (as low skill terminal user) was a standalone AppVM which I personally don’t like - one template for one app.

To avoid standalone AppVM I prefer standard AppVM with AppImages (if they are available). For this approach I would like to have a more integrated and user friendly approach in Qubes OS.

1. Download AppImage (in any AppVM)
2. Right-click on *.appimage than create AppImage AppVM (based on a minimal / “medium” template with network on) and create a new folder “AppImage” in home directory. Somehow the same routine like ‘copy to other AppVM’ and ‘open in disposable AppVM’. Afterwards copy *.appimage into this new folder.
3. Add this AppImageVM to the AppImage menu (see proposal above).

Advantage:

Simple: Two-clicks software installation. (Beside the permission to launch the appimage) no terminal command required. Easy to maintain / update.

secure: App is isolated in its own AppImageVM. Possible to set individual firewall settings.

[Insurgo]

@whoami

To avoid standalone AppVM I prefer standard AppVM with AppImages (if they are available). For this approach I would like to have a more integrated and user friendly approach in Qubes OS.

For this complete different approach (not Template based, no update warning, user not knowing if running latest version unless the app “phones home” and warns user of a newer version at runtime) this is a way to go.
Upstream software installation guides will sometimes only propose AppImages. Or snap/flatpak. In my own beliefs, AppImages are the last ones I would install, while I understand the need for packages maintainers wanting to deploy apps without burden of packaging those apps and maintaining repositories. Flatpak/snap on the other side depends on a repository-like system, but is working outside of Qubes update warning system: deploying applications from repositories will warn the user that updates are available. The use applying such updates will receive logs of what was updated. And tge user will receive warnings that qubes depending on an updated template needs to be restarted to run updated software. Flatpak/snap/Appimages won’t do that. Leaving the advanced user responsible to do the maintenance and keep track of what software was installed in which way and carefully maintain used softwares.

Micah Lee proposed an interesting app manager (which i hope has made its way into Qubes Contrib repositories @fepitre? ) which permits flatpak installation directly into a qube. But yet again, when a user launches that already installed app in a qube, said update scripts working in thr background will deploy the update without notification to the user to close and relaunch app.

Qube Apps: a Flatpak-based app store for each qube

I continue to be a firm believer that:

• Best way to deploy software is from repositories, if available.
• AppImages are last, since not updated automatically and requires from users a buch of additional steps to ensure of integrity/authenticity
• Snap/flatpak are better then nothing, where I try to push software maintainers to at least support debian/fedora. But Qubes support is not complete here, as said before. User will use older version until he restarts its qubes, after silent updates are applied, but where Micah Lee’s app manager improves the situation. Here, the user can decide to deploy flatpak in Template in a centralized way (where updates wont be installed automatically) or per qubes, which if app is usef in multiples qubes, network usage/disk usage goes up drastically, those payloads redownloading static dependencies to work on any linux, and where flatpak repositories are sometimes less frequently updated then their repositories counterparts and where packages maintainers are also sometimes not the from the software distribution team.

Convenience vs security, again

@adw thoughts here again welcome.

[whoami]

@Insurgo

Micah Lee proposed an interesting app manager (which i hope has made its way into Qubes Contrib repositories @fepitre? ) which permits flatpak installation directly into a qube. But yet again, when a user launches that already installed app in a qube, said update scripts working in thr background will deploy the update without notification to the user to close and relaunch app.

That’s cool. Thanks for sharing!
Hopefull, it makes its way to Qubes OS standard.