search

noisetorch / NoiseTorch

Real-time microphone noise suppression on Linux.
Other
9.3k stars 231 forks source link

Distribute as an AppImage #39

Open andreyfedoseev opened 4 years ago

andreyfedoseev commented 4 years ago

It would be nice if you provided an .AppImage file along with a tar.gz

You already have a static binary, an icon and a desktop file. That's all you need to to build an AppImage.

This would greatly simplify installation and uninstallation.

See https://docs.appimage.org/reference/appdir.html#ref-appdir-specification and https://appimage.github.io/appimagetool/

lawl commented 4 years ago

Hey, I'm not super familiar with AppImages and was under the impression that we wouldn't gain a lot, since as you know, it's already a static binary with no dependency.

Could you elaborate a bit more on what you think would be the advantage shipping it as an AppImage?

andreyfedoseev commented 4 years ago

AppImage can be integrated into user environment with "one-click" (install). They can can also be easily removed from the system (uninstall), including the AppImage itself, and all supporting files such as the desktop file and the icon.

It's more convenient than dealing with archives and files stored in different locations.

probonopd commented 4 years ago

Providing an AppImage would have, among others, these advantages:

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

lawl commented 4 years ago

@probonopd thanks, but most of these are things noisetorch already does, or don't apply to us.

The only point that I think is in favour of an appimage is:

I'd like to have a more integrated install method than "untar this file". But i'm not sure how widespread adoption is for appimaged is.

vchernin commented 4 years ago

Not to add a confusing amount of options, but has flatpak and/or snap been considered? Similarly to appimage, these provide desktop integration, and unlike appimage, are conveniently installed from distro app stores instead of github.

In my experience while appimages do mostly work as advertised, desktop integration ends up being a manual process as appimaged or appimagelauncher is not preinstalled.

https://flatpak.org https://snapcraft.io

An overview of the different options: https://makealinux.app

lawl commented 4 years ago

@vchernin yes it has, but this thread is about appimage, if you'd like to discuss this further, i'd prefer a new issue.

Short answer to your question. snaps: Blocked on this bug and Canonical giving us the permissions needed. Flatpaks: I refuse to until this is supported as a matter of principle.

DQnkGHD8 commented 4 years ago

1 The developer shouldn't have to bother with the packaging. 2 Appimages and the like are regressive (0\evil). If you want a portable app, just download the tar and uncompress it where you like.

mksaleem commented 3 years ago

Looks like they have granted you the permission "@lawl - your snap is now granted use of classic and your next upload should pass automated review"

lawl commented 3 years ago

Yes, but the bug in their pulseaudio patch isn't fixed, thus a snap is borderline useless because it won't work on ubuntu and derivatives.

LinuxForEveryone commented 3 years ago

Has there been any update on AppImage distribution? I'm featuring this on Linux For Everyone soon (it's brilliant software, thank you!) and a good chunk of my audience seem to prefer GUI over CLI when it comes to installing/using software.

lawl commented 3 years ago

No update yet, but I agree that installation needs to be simpler. I'll try to look more into AppImage next week.

lawl commented 3 years ago

I've been looking more into AppImage probably for the like fifth time now. And it's still confusing. So here are my current assumptions:

And this is where the issues start, how do end-users make use of that metadata?

The references I've seen are to appimaged which is archived and links to a new repo go-appimage which tells you that if you're looking for production code, you should look at AppImageKit which in turns again sais it uses appimaged...

Additionally AppImageKit doesn't seem focused on end users and had it's last release in 2019 (is it just complete and doesn't need updates anymore or is it abandonware)?

What or where is a/the de-facto standard package manager à la apt/emerge/dnf.? Where do I point people to, to tell them: use this to get updates and desktop integration if you don't just want to chmod +x it for a test drive?

probonopd commented 3 years ago

We already have a statically linked binary, so we don't actually need the whole "bundle up dependencies" stuff that AppImage, snap, or flatpak provide

Good! In the case of statically linked binaries, you don't need to bundle dependency libraries then. As you say, AppImages may still be worthwhile for the icons and other metadata, and the updating.

how do end-users make use of that metadata

Various tools exist to use this metadata. The best option would be if your desktop environment would provide native AppImage support, but unfortunately few do so far. So a whole collection of desktop integration tools have been developed:

https://github.com/AppImage/awesome-appimage#desktop-integration

Again, native support in the file manager would be best, so I consider all of them as workarounds as long as desktop environments don't put in native support.

Additionally AppImageKit doesn't seem focused on end users and had it's last release in 2019

The low-level components that AppImageKit contains are basically feature complete by now. Which I think is a good thing. No constant changes are needed anymore. AppImageKit is not gearead toward end users at all. Many of the AppImage production tools use its appimagetool under the hood.

What or where is a/the de-facto standard package manager

AppImage is designed specifically so that you don't need a package manager! Just go to the download page of the application author, and download the AppImage. Like Windows and Mac users are used to.

lawl commented 3 years ago

So a whole collection of desktop integration tools have been developed

Thanks, I looked at some of these, but I didn't see one that would in general be a huge upgrade over our current installation method.

AppImageKit is not gearead toward end users at all.

Ok, that wasn't clear to me.

AppImage is designed specifically so that you don't need a package manager! Just go to the download page of the application author, and download the AppImage.

Yes I'm aware that you can just chmod +x them. I was using that word more general for "tool that make appimage integrate into system nicely and do update". And for this I would like to have a solution that I feel comfortable telling people "use this to install noisetorch".

probonopd commented 3 years ago

"use this to install noisetorch".

Well, the whole point of AppImages is that they don't need to be installed, and no extra tools are needed to run them. Best point your users to https://discourse.appimage.org/t/how-to-run-an-appimage/80.

lawl commented 3 years ago

don't need to be != can't

sipaktli commented 3 years ago

AppImage is designed specifically so that you don't need a package manager! Just go to the download page of the application author, and download the AppImage. Like Windows and Mac users are used to.

There are many good reasons to use a package manager. Package managers are not a burden to get rid of. They are very powerful and useful tools that help protect the system, audit it, fix it, deploy it, and keep sane disk space use. They add stability and resiliency to the OS. AppImages are inherently insecure and actually create more hassle. To be able to install something by typing 'pacman -S' or 'yum install' or 'apt get', is faster and more convenient than searching online for whatever stuff assuming you know it exists, then download it, get a console, chmod it, then run it and have an ugly 'folder' sitting around with the executable. Updates also have to be done manually. There is no practical way to integrate MACs and other security models or to even do checksums on contents. How do you even know what software is trusted and by how many without a package manager? How can you even discover new software without a package manager? Googling stuff? No way!

No to mention many of those ask for setuid!! And new users have no clue what that is.

heidiwenger commented 3 years ago

Yes! Indeed the installation should be alot simpler. It's now like overkill for even seasoned Linux user. Life is too short for not supporting one click or simple enough installs .. I don't understand the bashing of flatpak and snap by the developer? Looking at Flathub and the sheer number of apps, it sure does work?

probonopd commented 3 years ago

Never worked for me on Ubuntu Live ISOs. And I cannot keep (and easily backup) a single file that runs on many distributions.

barthalion commented 3 years ago

@probonopd You can, you just need to have flatpak installed. Not sure what you want to achieve by mentioning your self-imposed issues everywhere.

Going back on the subject though, given NoiseTorch requires special capabilities and re-launches itself with pkexec, flatpak is not the tool you want. As it's a static binary already, there's probably not much point in putting into AppImage, and given it notifies user about updates availability, snap likely isn't a win either. I kinda agree with @lawl that there's nothing to gain here.

ghost commented 2 years ago

I would really enjoy to see it packaged as an appimage, as it stands it feels very offputting just downloading a random tar and binary.

AppImages are great, and get integrated super easily into the desktop with AppImageLauncher where it detects your app isn't integrated and just integrates it automatically, but it also gives people the flexibility to just run it as a binary in a location where they put it. So you get integration and simple running.

I would also love to see this application packaged properly in the average package manager, but for now I think a simpler install for users would be best.

It would make recommend NoiseTorch to others incredibly easy, as right now it's a bit hard to do so and I have to explain a fair few intricacies. Most people can follow "download this, run the file" or "run this apt/snap/flatpak" command.

Aschen commented 2 years ago

AppImage, Flatpack and those other packager are not a good idea. Behind the illusion of simplicity, it's just an horrible mess needed to run simple programs. (See https://ludocode.com/blog/flatpak-is-not-the-future)

This program is just a single 2.7Mo executable, with AppImage or another packager, you will need hundreds of Mo to run it.
You can literally just download it and run it from your terminal, I don't see how any kind of packager can make this more easier.

btw, @lawl this comment may just be an excuse to say how much I like your project, simple, easy and light. I'm working remote and often in cafe/restaurant and this is just perfect since I have a lot of meetings :ok_hand:

berglh commented 2 years ago

AppImage, Flatpack and those other packager are not a good idea. Behind the illusion of simplicity, it's just an horrible mess needed to run simple programs. (See https://ludocode.com/blog/flatpak-is-not-the-future)

While I agree with you that things are a bit messy now, surely a more declarative system with increased security and no package conflicts still has merits, even if these technologies are still in their infancy. I'm thinking that with developments in file systems, such as block de-duplication (already available in root ZFS on Linux), some of these capacity issues would be minimised at the expense of block storage performance.

This program is just a single 2.7Mo executable, with AppImage or another packager, you will need hundreds of Mo to run it. You can literally just download it and run it from your terminal, I don't see how any kind of packager can make this more easier.

It makes it much easier for regular users to install and audit what packages are installed on their system. Currently, you need to remember how you installed it to remove it, and if you're only half cluey and go back and find your .local/bin folder, then just delete the binary, then there are other artefacts, like the launcher.desktop file that will persist. For you and I this seems silly, as we're familiar, but most users don't want to have to worry about this stuff. They want to use a Software Centre, or maybe something like APT without needing an intimate knowledge of Gnome, Linux/Unix FS layout or GitHub.

Probably Wrong: I was wondering if it's possible to compile this package without any external library linking? I'm applying Docker image logic here, where it's possible to compile Go binaries that are the only file in the container as a self-contained entry-point. The fact it uses CGO makes me wonder if this even possible at all, it's been some years since I compile Go without external linking, and I'm pretty sure in the past I had to disable CGO for this functionality. So I wonder, if it is possible to compile the binary without the external linking, then the only requirements for the AppImage should be just the binary itself, launcher icons, and any packaging related metadata/permissions? Edit: Looking at the Makefile it's already disabling CGO and appears to be internally-linked if I understand the switches correctly.

Never the less, I still think some kind of option for packaging this up for publishing into a PPA for Ubuntu makes some sense to me. From my perspective, it would be simple to build all of this in Docker containers targeted at each current distribution and push to a PPA using CICD. I certainly have no experience with AppImage/Snap/FlatPak, so I'm really not to say how much better these systems would be than traditional APT/Yum/Pacman for making this excellent project more accessible to the wider Linux community. I could be convinced to put some effort into this, although my experience is only around DEB packaging for Ubuntu, so hardly useful for all users.

lawl commented 2 years ago

Here's a preview of an appimage for noisetorch. Still lacks things like update info etc (zipped otherwise github won't let me attach it): NoiseTorch-x86_64.zip (code: https://github.com/lawl/NoiseTorch/tree/appimage)

So why an AppImage now? Because I got upset enough with packaging on linux that I wrote my own package manager for appimages, it only took minimal yak-shaving such as also writing my own squashfs driver. You can find it here, it's called ayy: https://github.com/lawl/ayy

And because NoiseTorch requires capabilities which doesn't work if you use the default appimagetool, there's also a cusstom build script to create the appimage in the first place. As far as I know. this is the first AppImage produced and consumed with entirely independent tooling.

Yes ayy is a CLI tool. Yes, a GUI version will come too. I can't do everything at once, so I've decided to push ayy out for now to get feedback and fix issues from which the GUI then will be able to profit too.

If you're bored, consider taking a look at it.

probonopd commented 2 years ago

And because NoiseTorch requires capabilities which doesn't work if you use the default appimagetool, there's also a cusstom build script to create the appimage in the first place. As far as I know. this is the first AppImage produced and consumed with entirely independent tooling.

Hi @lawl, that's cool! I've been increasingly growing unhappy with the complexities of C/C++, the libraries used, and the legacy AppImage tooling, and have been thinking to replace everything by a Go based solution. Maybe yours is better? Will definitely check it out! :+1:

ghost commented 2 years ago

@lawl I've been using the appimage build over the past couple days and its really nice! I threw it right in ~/.local/bin and it worked perfectly. Just as nicely as before and slightly simpler to install, all in all Im a big fan. Thank you for your work!

berglh commented 2 years ago

@lawl I've given it a go on Ubuntu 22.04, seems to work OK.

@Slikrick Is there a canonical way to plop AppImage Gnome desktop files and icons for the launcher in Ubuntu? I am happy to just wired this up manually from the existing desktop file. (I think the exiting tar had the files extracted to the user context automatically).

jokeyrhyme commented 2 years ago

@berglh there are some suggestions here: https://docs.appimage.org/user-guide/run-appimages.html#integrating-appimages-into-the-desktop

lawl commented 2 years ago

@berglh

I am happy to just wired this up manually from the existing desktop file.

That's what https://github.com/lawl/ayy is for. as @jokeyrhyme suggests there is also appimaged, but uh... it imo has some reliability issues and is the wrong way to do this. (same goes for appimagelauncher)

berglh commented 2 years ago

@lawl ayy.. I like it, it goes and works good

Twig6943 commented 5 days ago

Any updates on this??? It's 2024 and this project still relies on distro-specific packages

sipaktli commented 5 days ago

Any updates on this??? It's 2024 and this project still relies on distro-specific packages

It is not "distro-specific". There is a tar ball that you can use to compile or to generate a distro-specific package. And if you refer to an appimage or snap or something... iugh...

Twig6943 commented 5 days ago

regardless an appimage would be appreciated