Quoting: const

Quoting: gradyvuckovicBetween Snap, Flatpak and AppImage, I'll admit I think AppImage is my fav. Just because I love the simplicity of it.

"Here's an app, it's in a file, double click it to run it."

Beautiful simplicity. What I'd like to see is more distros improving their support for the format. Stuff like if you try to double click an AppImage file and it doesn't have executable permission, just asking the user, 'Do you want to give this AppImage file executable permission?' and stuff like a place to drag and drop AppImage files to add them to the application list.

I'm ok with the dev to decide between Flatpak and AppImage. Distros may also still decide to provide their own package, but I'm a big fan of flatpak and AppImage for any self-contained application running on top of my DE. SteamDeck only made it more necessary to have these.

Regarding integration with AppImage: For some reason, it works beautiful with my Arch-KDE System. I just double click the appimage and a GUI pops up, asking if I only want to run it once or have it integrated. This is how it should be.

Sounds like you have AppImageLauncher perhaps as I recognize the gui you are describing

View this comment - View article - View full comments

Quoting: gradyvuckovicBetween Snap, Flatpak and AppImage, I'll admit I think AppImage is my fav. Just because I love the simplicity of it.

"Here's an app, it's in a file, double click it to run it."

Beautiful simplicity. What I'd like to see is more distros improving their support for the format. Stuff like if you try to double click an AppImage file and it doesn't have executable permission, just asking the user, 'Do you want to give this AppImage file executable permission?' and stuff like a place to drag and drop AppImage files to add them to the application list.

Yeah, I do like the java approach they employ as well, that's also why I like java, although admittedly java does have the extra step of needing the jre but I think recently they added a way to bundle the jre in the app (think it's jpackage)

View this comment - View article - View full comments

Quoting: M@GOidI wish Appimage became more widespread. So many projects have a Linux port but don't provide a convenient way to use the thing. Meanwhile those same projects don't have a problem providing a Windows executable.

That just contribute to the bad look Linux have among Windows users "I don't use Linux because I don't want to compile a program to use it".

While I think AppImages are good, the devs of it don't help adoption when in the past (idk how long it's been) they said some things about the OBS Project because they only had flatpak and I think tried to say because RedHat became a sponsor of OBS that they then added flatpak, some crazy stuff like that.

View this comment - View article - View full comments

Quoting: Liam Dawe

Quoting: tfkI just use 12345, which is the same code as my luggage... 🧳

For the lock screen maybe but not for the actual login which is the point of this.

You didn't get the reference :( it's from Spaceballs, watch it if you haven't already, it's a great comedy :)

View this comment - View article - View full comments

Quoting: robvvHarmful and Dangerous to the Windows ecosystem, maybe?

Microsoft has YouTube bots on payroll lmao

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: JordanPlayz158

Quoting: PublicNuisanceSo an employee from a company who makes a closed source game store client that hosts a closed source game that uses closed source anticheat software had an issue with an open source library and i'm supposed to side with the employee ? Do I about have that right ? Would it not be an easier issue to fix if more of that equation I listed were open source ?

It wasn't just EAC that broke but a few other applications like Shovel Knight, a game with a native linux port and libstrangle, an fps limiting library, this isn't about open vs closed source software, this is about maintaining backwards compatibility to not only make linux more enticing to port to but also to make it so things like games that do not get maintained forever won't get lost to time.

Well, it 'sort of' is about open vs closed. If it was open (Shovel Knight) someone could have given them a pull request to change to the newer method. That's pretty straight forward.

This wasn't really about backward compatibility, and more about deprecated methods still being used in software. This should be a wake up call for those projects that use old crappy code, and hopefully they'll get updated to be faster.

We'll have to agree to disagree on that front, most of the outrage I've seen is about glibc developers not making it clear they were removing DT_HASH (and that you needed to go to mailing lists and such to know it was depreciated, incremented the patch rather than the major for a breaking change) and I'd say the bigger deal of hurting the prospect of the Linux desktop being ported to or getting more native applications (especially for game developers when games inevitably stop getting maintained and typically do not get their source released once the game is EOL) due to these sort of changes

View this comment - View article - View full comments

Quoting: Tuxee

Quoting: pb> "this is impacting us so heavily"

ok, but what if people who go to such extreme measures are from other poor countries that *don't* have regional pricing and instead are paying "regular" prices in usd or euro? and it's their only realistic alternative to just pirating the game?

No such thing. Humble Bundle registered illegal copies of their one Dollar/one Euro bundles. There might be some "in need" using this "workaround", but I am absolutely convinced that the vast majority are people just feeling good, that they could rip off someone else.

I highly doubt mal-intent, I look at it from the optimistic viewpoint, if people don't get the game for the price they want (by changing regions), they likely wouldn't buy it at all and just pirate it (or use G2A which results in the same amount of money for the developers, 0) in which case rather than the developer getting some money, they get nothing, although I do agree devs deserve a lot more money for those games, if they need to choose between 10% of revenue vs 0% of revenue from their recent sales, they'd probably like the 10%, they should get 100% of the revenue from the region but unfortunately this isn't the world we live in, people are going to pay what they feel the game is worth or not pay for it at all, who knows, now that gas prices are going down to under $4, people might have more spending potential.

View this comment - View article - View full comments

Quoting: PublicNuisanceSo an employee from a company who makes a closed source game store client that hosts a closed source game that uses closed source anticheat software had an issue with an open source library and i'm supposed to side with the employee ? Do I about have that right ? Would it not be an easier issue to fix if more of that equation I listed were open source ?

It wasn't just EAC that broke but a few other applications like Shovel Knight, a game with a native linux port and libstrangle, an fps limiting library, this isn't about open vs closed source software, this is about maintaining backwards compatibility to not only make linux more enticing to port to but also to make it so things like games that do not get maintained forever won't get lost to time.

View this comment - View article - View full comments

Quoting: F.Ultra

Quoting: JordanPlayz158

Quoting: F.Ultra

Quoting: JordanPlayz158

Quoting: ShabbyXIt's made exactly so that libraries *can* break ABI if they have to, without the world imploding. glibc made a breaking change, and no matter how small, they should have made an incompatible version change. Yes that would still be inconvenient, but at least it's detectable and fixable. Imagine if python3 did all its backward incompatible things but still called itself python2.

Yes, that's exactly the point we were making, they didn't treat it as a breaking change as they just incremented the patch number by 1 rather than the major. Not to mention a lot of people have said it wasn't very clear and I could buy that as documentation doesn't seem to be a strong point in either linux or c in general (or I could be wrong (or xdg-desktop-portal could be a bad example of a c library) but when I attempted to make an application using xdg-desktop-portal they had the equivalent of a javadoc but that was about it, there are no examples provided in the repo for how to use any of the objects (or it wasn't clearly labeled or findable), there were no tutorials online and I looked into other repos (that are flatpaks as they must use xdg-desktop-portal to my knowledge) and it was a mess because different applications use different languages or sometimes used a middle man library or some combination of the two which made it difficult to know how to use the interface)

glibc is very well documented, as is most C libraries on Linux (don't know where this misconception comes from), they didn't see the ELF sections as part of the glibc ABI/API though which is why this went under the radar for developers that isn't on the glibc mailing lists.

This was not a code change, it was a change in the automake configure script to no longer pass in the argument to ld to include the old hash section when building glibc.

Normally no library/application dev ever sees a change like this as a ABI/API change, but it looks like the glibc devs will do from now on.

Well I just had one example experience (with xdg-desktop-portal, apologizes if they are an exception and not the norm for the standards of C libraries), I try to stay away from languages like C just as it doesn't really seem to click with me like a lot of other languages have (not to mention there are languages like Rust that some say will replace C and while I don't like rust either, it is leagues better for clicking with me). Also yeah, that makes a lot more sense as I was very confused by DT_HASH being in a build config file and not a function in the code when I saw the commit so again, thank you for clearing that up.

no probs, xdg-desktop-portal looks to be a 3d party tool for flatpak and unfortunately many such well intended extra tools are very rarely well documented.

To experience the glibc documentation just open a terminal and type in say "man dlopen" and see just how much information they have on that single function.

Yeah, I tried that then I thought `man elf` and there is a page, is this from glibc's documentation or something else as if they have control over that man page then they should definitely change this portion
 
       d_tag  This member may have any of the following values:

              DT_NULL     Marks end of dynamic section

              DT_NEEDED   String table offset to name of a needed library

              DT_PLTRELSZ Size in bytes of PLT relocation entries

              DT_PLTGOT   Address of PLT and/or GOT

              DT_HASH     Address of symbol hash table
to
       d_tag  This member may have any of the following values:
              ...
              DT_HASH     [s]Address of symbol hash table[/s] PLEASE FOR THE LOVE OF GOD DO NOT USE THIS AND INSTEAD USE DT_GNU_HASH IN THE FUTURE, PLEASE USE ANYTHING OTHER THAN THIS
and then problem solved but it is possible this man page is not in their control but if it is, I propose to add my addition to it lol

View this comment - View article - View full comments

Quoting: F.Ultra

Quoting: JordanPlayz158

Quoting: ShabbyXIt's made exactly so that libraries *can* break ABI if they have to, without the world imploding. glibc made a breaking change, and no matter how small, they should have made an incompatible version change. Yes that would still be inconvenient, but at least it's detectable and fixable. Imagine if python3 did all its backward incompatible things but still called itself python2.

Yes, that's exactly the point we were making, they didn't treat it as a breaking change as they just incremented the patch number by 1 rather than the major. Not to mention a lot of people have said it wasn't very clear and I could buy that as documentation doesn't seem to be a strong point in either linux or c in general (or I could be wrong (or xdg-desktop-portal could be a bad example of a c library) but when I attempted to make an application using xdg-desktop-portal they had the equivalent of a javadoc but that was about it, there are no examples provided in the repo for how to use any of the objects (or it wasn't clearly labeled or findable), there were no tutorials online and I looked into other repos (that are flatpaks as they must use xdg-desktop-portal to my knowledge) and it was a mess because different applications use different languages or sometimes used a middle man library or some combination of the two which made it difficult to know how to use the interface)

glibc is very well documented, as is most C libraries on Linux (don't know where this misconception comes from), they didn't see the ELF sections as part of the glibc ABI/API though which is why this went under the radar for developers that isn't on the glibc mailing lists.

This was not a code change, it was a change in the automake configure script to no longer pass in the argument to ld to include the old hash section when building glibc.

Normally no library/application dev ever sees a change like this as a ABI/API change, but it looks like the glibc devs will do from now on.

Well I just had one example experience (with xdg-desktop-portal, apologizes if they are an exception and not the norm for the standards of C libraries), I try to stay away from languages like C just as it doesn't really seem to click with me like a lot of other languages have (not to mention there are languages like Rust that some say will replace C and while I don't like rust either, it is leagues better for clicking with me). Also yeah, that makes a lot more sense as I was very confused by DT_HASH being in a build config file and not a function in the code when I saw the commit so again, thank you for clearing that up.

View this comment - View article - View full comments