AM
bread
AM | bread | |
---|---|---|
76 | 10 | |
321 | 32 | |
- | - | |
9.9 | 0.0 | |
3 days ago | about 1 month ago | |
Shell | Go | |
GNU General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
AM
-
How do you (yes, you specifically) work with appimages?
I recently discovered AM App Manager, it's app manager for appimages that have system integration and you can update all your apps with one command. Take a look at it's catalog to see if your app is supported.
-
Install issue on PopOS using appImage
I use https://github.com/ivan-hc/AM-Application-Manager to install App image, to include Neovim. By default it currently installs Version 10.0 and creates the symlinks.
-
I'm sick of reading that among the disadvantages of AppImage is the lack of updates and a centralized repository!
I have been working on two CLI tools to install AppImage packages system wide and locall (they are AM and AppMan respectively). I've also written a website that acts as a catalog and a better source for downloading them all for real, https://portable-linux-apps.github.io !
-
ArchImage: my (experimental) side-project to convert Arch Linux programs to AppImages that really work on any distro, old or young... powered by Junest
In conclusion, I feel really confortable with docker/podman/distrobox/junest... but I also like a lot AppImage packages, so I'm trying to merge both. Something I learned all this time I use Linux is that there is no distro, no package format, no software... that can really satisfy my needs. The best hing I can do to solve this situation is to built it by myself (this is my main project, I named it "AM"). I spent two years to create what I like, after a decade as a common Linux user that uses what distro/package mantainers had to give, and this make me feel better. This last point is the main reason because all these distros and software solutions exists in GNU/Linux.
-
Ventoy Installation
This is one of the 1700 installation scripts of my project.
-
After two years of development on "AM", AppMan and many Appimage packages... I'm seriously considering giving it all up
I started writing AM/AppMan two years ago, it was just a custom script to install and always keep any Appimage package I needed updated to the latest version. Then become something much bigger.
-
I have developed my own Appimage package manager in full BASH, here are 3 different approuches to install the apps: xterm (1, the default one, allows to interact when prompted questions), less (2, clean but non interactive) or nothing (not clean). What is better? Have you got suggestions?
Sure https://github.com/ivan-hc/AM-Application-Manager I have already tried with lowercases words but I don't like that, that's why I've chosen uppercased text. "De gustibus non est disputandum", Romans said.
-
Portable Arch Linux packed into a single executable
I like containers, I've tried Junest and docker/podman/distrobox... also I work a lot with portable apps (see here) and I've also published a website for them (here) so I'm amazed on how you've built something that can merge them! I'll include it on my catalog (also I'm writing an installation script for it). Thank you!
- Portable-Linux-apps.github.io reached 1608 applications (about 1570 are Appimage packages), all with descriptions and links to the authors, sources... and installation scripts I wrote one by one.
-
After a long waiting and big cleaning of the code... "AM" Application Manager is back: 1596 installation scripts (i.e. about 1550 Appimage packages, all installable and updatable). And the uploading is not finished yet!
Learn more at https://portable-linux-apps.github.io
bread
-
It's time to fork some good projects
NOTE: I don't know when and if to add new AppImages from the main catalog, also because a part of them is mostly broken and out of control. The AppImage packages compiled and managed by "AM"/AppMan are new AppImages that use scripts that also allow constant updating and recompilation from scratch, as if they were installed from AUR, using more reliable sources (official repositories for Debian and derivatives) . If you are interested more to the applications made available officially from the official AppImage.GitHub.io catalog, I suggest you to use Zap, Bread or the aforementioned Appimagedl. All these amazing utilities can be quickly installed via "AM" or AppMan.
-
"AM" and AppMan - that's why they don't include support for AppImageHub and similar sites
The preferred sources for downloading packages in AppImage format via "AM" / AppMan are GitHub and Sourceforge, however, writing installation scripts that are compatible with one or more programs is a difficult task. Just think that many developers add multiple versions of the same product in the same tag (I have to include also commands to find the exact name of the latest version to avoid the download of other packages), or include more complex links that require an equally complex function to obtain the latest version of a program, and this slows down the loading of these programs on the "AM" repository I manage. I have therefore included excellent AppImage package managers such as "Bread" and "Zap" among the downloadable programs, but also "AppimagePool" and "bauh" are available among the graphics applications (not counting a "Pacstall" AppImage versionI made). These tools should compensate the lack of support for certain sources that I have not included in the "AM" repository.
-
Idea for Appimages: AppImage Repositories! (Automatic Updates, Secure Downloads)
My project bread or AppMan by Ivan are basically package managers for AppImages, I use GitHub release & the Above given appimage.github.io API to get the information related to AppImages stored in this repository, and AppMan has it's own repository maintained by Ivan.
- Bread v0.4.4 released
- You can learn better while practicing, it took that to another level (I am intermediate in go),
- Install, Update, Remove & Run AppImages From CLI
-
Install, update, remove & run appimages from CLI
Bread 🍞: https://github.com/DEVLOPRR/bread
- Bread 🍞
- Go - A Simple Tool To Install, update and remove AppImage from your CLI
What are some alternatives?
firedragon-browser - A Floorp fork with custom branding 🐉 (mirrored from GitLab)
appimage-cli-tool - AppImage package manager
AppMan - Manage 1900+ AppImage packages and official standalone apps for GNU/Linux without root privileges using the extensible and ever-growing AUR-inspired database of "AM Application Manager". Easy to use like APT and powerful like PacMan.
go-appimage - Go implementation of AppImage tools
Spotify-appimage - Unofficial AppImage for Spotify
zap - :zap: Delightful AppImage package manager
gimp-appimage
lust - A fast, auto-optimizing image server designed for high throughput and caching; Now that is hot.
GIMP-x86_64.AppImage - GNU Image Manipulation Program, cross-platform image and photo editor, AppImages for x86 and x64 architectures built from the more recent PPA (supports GLIBC 2.27 or later). [Moved to: https://github.com/ivan-hc/GIMP-64bit-and-32bit.AppImage]
nyxt - Nyxt - the hacker's browser.
goget - 📦 A simple, good looking, go modules TUI! No more looking for the right "go get" command!