Anyone has more info about:
"Update file distribution method to save disk space."?

View this comment - View article - View full comments

Quoting: Geppeto35I don't understand how it's such a mess to package something in linux. From a beginner point of view, the fact that each distro proposes its own packaging method looks like old proprietary OS trying to keep captive their pools of users and exclude the possibility to change.
Like for phone cables, we need a clear, stable common basement so that the free (like in freedom) exists, and at a level beginners can handle, not at a level that only kernel pros can manage.

From what I know by using arch, packaging a software is not a mess at all.
If by mess you mean the fact that there are more package managers, well it is about choice/user tastes.
What you seem not to consider is that even if there was only a package manager, the packages would not be interchangeable between distros (you can't just take a package from arch, put it into manjaro and be sure it will work, even if both packages have the same format), this is because -say- the executable X contained in package P could have been built to use library L at version 3 while the executable P contained in package P2 could have been built to use library L at version 2 which is not compatible with version 3.
For the same reason, you can hardly hope to pick an updated package built for ubuntu 33 and make it run on ubuntu 10, same package manager, same distro, different dependancies. Nobody is

Quoting: Geppeto35trying to keep captive their pools of users and exclude the possibility to change.

If there is interest in a sofware, users are expected to ask their distro mantainers to package it, this is the saner way to use it.

View this comment - View article - View full comments

Quoting: Kithop

Quoting: kokoko3kI never said that.

Apologies - I must have fumbled trying to trim down the quote on my phone :p Meant to be a reply to this one further up I think? https://www.gamingonlinux.com/2022/02/retro-x86-based-machine-emulator-86box-32-brings-linux-support/comment_id=220331

Either way - more just general info for anyone who might think their AppImage is the only route.

You quoted right, no need to apologies, but thank you anyway
What i didn't said is that a dev deciding to offer a package type doesn't prevent everyone from packaging it differently.
Like many, I think one of the advantages of linux is the centralization of the packages mantainance and I thank everyone involved in keeping the AUR alive (I use arch and mantain a bunch of PKGBUILDS there too).
But the fact that appimages and similar containers are surely handy and quick and, in the short term, appealing for users, may pose a threat to the established packaging ecosystem.
When an user sees an appimage and think: "Yay!", it means it prefers it over his distro package or, worse, it means there is no package for his distro or that the package for his distro have problems.
Appimages are not only the indication of the problem they try to patch, but the possibility that the patch itself will become its solution; they are (should be) not.
So my concern is not about the appimage itself, of course, but about more users starting to use them -> less interest versus distro packages -> less distro packages.

I hope to be too pessimistic here.

View this comment - View article - View full comments

Quoting: Kithop

Quoting: kokoko3kNope.
At least, not for me,thanks.
This is GPL 2.0 code that can be packaged by your distribution and installed and uninstalled by your package manager.
I can understand that for proprietary apps, or if you just need to test the software.
More appimages mean more bloat/useless duplication, more memory use.

Someone's already got a PKGBUILD in AUR (and -git version) I might try later; just because the 86box team offers a distro-agnostic AppImage doesn't prevent everyone else from doing the 'right' thing with their distro of choice. I'm sure someone'll have a PPA for Ubuntu users, too, in time, etc.

I never said that.

View this comment - View article - View full comments

Quoting: whizseDev: Hey, take a look at this new interesting software I just released.
Linux users: Screw that! Let's argue about how the software is packaged and distributed instead!

Of course, because there are Linux users more concerned about the proliferation of appimages than interested in a particular software.

View this comment - View article - View full comments

Quoting: M@GOid

QuoteThey went with AppImage for Linux so it should run across most major distributions.

I wished more devs wold opt for this for their software. Some things shouldn't need you to plug a new repository, compile code or anything that requires a admin password. Just run it from the Download folder without much fuss.

I can hear the security minded folks furiously typing right now, but remember, I said "some things", not all apps.

Nope.
At least, not for me,thanks.
This is GPL 2.0 code that can be packaged by your distribution and installed and uninstalled by your package manager.
I can understand that for proprietary apps, or if you just need to test the software.
More appimages mean more bloat/useless duplication, more memory use.

View this comment - View article - View full comments

QuoteOpenGL 3.2+, Vulkan capable

Just in case ?

View this comment - View article - View full comments

Quotelocal decoding of H264 videos

I'm a bit puzzled on the meaning of this, why is "local" specified?

View this comment - View article - View full comments

They don't have a clue about Linux ecosystem, so from their point of view a radioactive alien can jump in and make everything explode.
Obviously, they don't support that.

View this comment - View article - View full comments

So basically you can expect 10% of your games totally unsupported and more than 50% fully enjoyable.
Not bad!

View this comment - View article - View full comments