snapcraft.io
appstream
snapcraft.io | appstream | |
---|---|---|
14 | 5 | |
135 | 201 | |
0.0% | - | |
9.3 | 9.6 | |
9 days ago | 8 days ago | |
JavaScript | C | |
GNU General Public License v3.0 or later | GNU Lesser General Public License v3.0 only |
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.
snapcraft.io
-
I think I may have just managed to piss off the whole community...
https://github.com/canonical/snapcraft.io please, stop spreading misinformation about snaps...
-
snap... please die a slow and painful death
Don't like the "proprietarity" of snapcraft? OK, discard it and put flatpak. It will never be banned by Ubuntu. And yes, snapcraft.io available on github.
-
RSS feeds for updated and new Snap packages?
Probably not, since a feature request for this has been open since 2018.
-
is the software for the server of https://snapcraft.io/ closed or open source?
snapcraft.io - the frontend website, is open source - https://github.com/canonical/snapcraft.io
- what are the advantages and disadvantages of snaps?
-
I've got karma to burn so why not?
What is the server code other than "something that distributes a .snap file"? Given that I can, if I want, take a .snap file to an airgapped machine and install it, it appears pretty trivial to offer alternatives to Canonical's infrastructure if anyone were particularly interested.
- Strong support for Snap, Ubuntu Core at Canonical conference
-
what's really important
Snap store - aka snapcraft.io is already open-sourced under GPLv3., see here. Perhaps, you mean not that the code is closed-source but that Canonical won't relinquish any control to the community and will continue to enforce the snap ecosystem as an Apple-style walled-garden? If so, then I completely agree with that assessment. That IMHO is the core of what makes snap an inferior choice for the community.
-
bro imagine being this bad, Canonical
snapcraft.io (e.g. snap store) has commits going back to Aug 16, 2017. Repo has GPLv3 license.
-
Delicious Pie!
IMO this is mostly due to higher-ups at Canonical no longer giving a fuck about desktop, less so for the boots on the ground. Wimpress and Pope both left Ubuntu and I don't remember which one said it but one of the 2 had a tweet basically saying as much. But even without that, snaps have been around since at least Dec 11, 2014 and likely even earlier than that. But despite being around for over 8 years, there's still a bunch of common complaints and probably about 30-40% don't sound like they'd take a big company more than 6-12 months to address if they actually worked on it. Things like submitting a patch to the util-linux project to make cli tools like mount/blkid/lsblk/fdisk to make loop devices not be displayed by default (after all they effectively only "break" when snap is installed), following normal dot-prefix conventions in the $HOME folder, adding 1st party support for 3rd party repos (given the nature of FOSS, couldn't they even borrow the logic from flatpak?), adding optimizations to consume less disk space in the majority of scenarios. (I would say to also make snapcraft.io open-source, but after seeing this repo, it appears that common complaint may be off-base)
appstream
-
It's this bad?
https://github.com/ximion/appstream/issues/470 ?
-
This open source game is being marked as proprietary
I think this list is used: https://github.com/ximion/appstream/blob/master/data/dfsg-free-licenses.txt
-
I've got karma to burn so why not?
So you want another way to distribute the packages? Such as wrapping the snap file in an rpm like I mentioned earlier? You could even set up appstream metadata for it. But that still doesn't solve the problem of one source getting too much power - just like flatpak doesn't solve that problem.
-
Why is Discover so unresponsive and buggy sometimes?
I could be wrong but for apps to be listed by these software managers (as opposed to plain package managers such as Synaptic or Muon), requires that the apps have to have "appstream" metadata. See https://www.freedesktop.org/wiki/Distributions/AppStream/.
- Looking for help generate python bindings with SIP and PyQt Builder.
What are some alternatives?
flathub - Pull requests for new applications to be added
Il2CppInspector - Powerful automated tool for reverse engineering Unity IL2CPP binaries
reactjs.org - The React documentation website [Moved to: https://github.com/reactjs/react.dev]
flatpak-platform - The elementary OS and AppCenter Flatpak platform
snapcraft - Package, distribute, and update any app for Linux and IoT.
appcenter - Pay-what-you-can app store for elementary OS
vscodium - binary releases of VS Code without MS branding/telemetry/licensing
libQuotient - A Qt library to write cross-platform clients for Matrix
gaming-graphics - Graphics stack useful as a content snap for gaming snaps
build-scripts - All-in-One build/compile scripts repository that aims to simplify the process of manual compilation/installation via automated shellscripts
next-pwa - Zero config PWA plugin for Next.js, with workbox 🧰
flatpak - Linux application sandboxing and distribution framework