Quoting: StalePopcornDamn that looks good, only missing volume keys [for me].

IIRC with my Launch, volume is mapped to Left-Fn + PgUp/PgDn.

I.E. The Launch Keyboard software is for mapping such things.

View this comment - View article - View full comments

Quoting: slembckeWorth pointing out that their licensing basically allowed this: https://github.com/0ad/0ad/blob/master/LICENSE.txt
The source is GPL which specifically allows commercial redistribution, and the art is CC-by-sa3 which also specifically allows commercial redistribution. I can understand how the dev maybe missed that the GPL allows it since it's a wall of text, but the CC license is like 2 lines of text and half of it is devoted to saying this was fine. :-\ They could have just used a different CC variation that didn't allow redistribution.

I've been asked many times if I'm worried that someone could do this to my open source stuff, and I always tell them no. Like I didn't pick the licenses I do because it allows this, but I also... don't really care. Like sure, you can totally get a sucker to pay for something that's free, but reselling pirated stuff totally happens too. (shrug)

Open source users often have a certain attitude about how great it is that people make free stuff that they just give away from the warmth of their heart. Sometimes that's true, but it's usually much more nuanced than that. Sometimes you've got people that just want to give back and share what they learned, and sometimes you've got folks that openness as a moral imperative separate from the monetary aspects. Sometimes devs get caught up in the feelings too and forget what the legalese actually says. :(

edit: My point being: Open source is great, but make sure you know what you are getting yourself into!

You're missing that the Steamworks SDK, which is required to distribute a game on Steam, and since the Steamworks License is incompatible with "copyleft" licenses, any exceptions to the GPL to allow a piece of software to be distributed on Steam must be agreed to/decided on by the Software Authors, not just anybody.

Source: https://partner.steamgames.com/doc/sdk/uploading/distributing_opensource

View this comment - View article - View full comments

Quoting: BlackBloodRumIt's all on usage case. For a server, stable is better.

What is the definition of "stable" here? For things like RHEL, CentOS, Debian Stable, SLES, sometimes even Ubuntu Server "stable" generally means very, very old versions of software that many times is no longer maintained by the upstream developers. In many cases when I was a SysAdmin, that meant we had to install external YUM or APT repos to install the software that the project or company "supported" because what was included in the distribution was no longer supported by the community or the company behind the FOSS project and as such, support was entirely on us to manage.

As for enterprise, the advent of patterns like containerization (Docker, containerd, Flatpak, etc) has enabled the ability to have a stable OS with newer (or older) libraries running inside the application "container". However, in the case of glibc, I'm not sure that's an option. Especially on Desktops. glibc is so core to the OS that the container would have to ship GFX drivers as well that are built on the shipped glibc version separate from the host OS and anything else that entails.

When it comes to core system functionality, compatibility will always win out from the non-technical customers/users. There's a reason Microsoft has not successfully moved away from win32 yet, despite the amount of times they've wanted to and tried.

View this comment - View article - View full comments

Quoting: dibzPersonally I still prefer how Debian labels things with stable / testing / unstable. It's clear what it is and isn't, I would consider unstable to be their bleeding edge. I'm not personally advocating using Debian or anything, it's just a good example.

The problem with that is that, as great as Debian is, "stable" runs a LOT of software that the upstream developers no longer support at all and haven't for years.

Which, IMO, is very different than what's happening here. glibc accidentally broke some software and games, but refuse to revert the change. Most projects don't take that kind of stance. They will revert breaking changes and work on a future resolution to the problem instead of pointing blame at someone else.

As for comments on Valve using an Arch-base. That's needed for what they do as fixes for gaming specifically are only found in newer software, drivers, and Linux kernels. Running something like Debian stable would be a nightmare for gaming as things are out of date and unusable for a lot of games really fast. Especially newer games and especially of those games (or WINE/DXVK/etc) rely on newer driver features that may require newer kernel features to function, etc.

Which is where part of the issue lies with gaming and Linux. A lot of "vocal" linux users and devs want GameDevs to develop for Linux, but ALSO to conform to what those "vocal" users/devs think is the "right way" and People don't work like that. Linux has to go to THEM and make their lives easy/easier when working with Linux and do so in a way that THEY are familiar with or they will just nope out and not care. And that will happen because the perception is that we, the linux community, don't care about their perspective.... so why should they care about us?

View this comment - View article - View full comments

Quoting: minidouNothing got broken. A two decade of depcrecation function got removed, but nothing broken. Or do we just expect everything to be forever maintained ?

As was mentioned by Arek Hiler in his blog post, that "Two Decade deprecation" was very poorly documented and warnings were not easily seen/found/displayed.

 
For those 16 years, it was Glibc who provided the compatibility and overrode the defaults for everyone and there never were any easy-to-spot deprecation warnings. 
It’s also unrealistic to expect every ELF consumer to keep up with undocumented developments of the format.

QuoteI don't expect anyone to check, I expect a CI or a quality gate to stop them from shipping.

Can't have a CI check if the change is poorly documented and not made glaringly obvious to the developer. Working as a software dev myself, I generally do not go to project pages and discussions to find out more about the library I'm using. I rely on the documentation and any output the library gives me. I don't care if it was deprecated for almost 20 years. If it wasn't well documented where developers could see AND warnings were obviously placed, then I'm probably not going to see it.

Even then, glibc made a breaking change without bumping the major version. That's a big break in protocol. In most versioning schemes, the major version is used to denote breaking changes. Regardless if those changes will actually break anything, if it breaks any existing functionality, it's a breaking change.

QuoteI'll call it bad practice, or just not being up to 2022 standards.

I'm sorry, but my terminal generally doesn't have enough scroll back to see all deprecation warnings in the compilation, let alone an easy way to highlight them well. Not to mention, there are a LOT of deprecation warnings in compiled software to the point where developers get so overloaded by warnings that end up amounting to nothing that they just start ignoring them.

A better solution is to update the documentation and put out a big notification ahead of releasing a breaking change.

View this comment - View article - View full comments

Quoting: dibz

Quote...on more bleeding-edge Linux distributions...

To protect your privacy, external media requires approval to load. Source: pics.me.me
View cookie preferences.
Accept & Show Accept All & Don't show this again   Direct Link

Rarely do I run into issues on "bleeding edge" distributions. It's also important to note that "Bleeding Edge" distributions aren't generally using "Bleeding edge" versions of software. Latest upstream stable versions? yes

Granted, when I think bleeding edge, I think software in beta stage (complete but still testing). There is a HUGE HUGE HUGE problem with certain distributions still using versions of upstream software that the upstream project has made end of life (Python 2.x anyone?)..... which is not a good practice in today's security environment.

View this comment - View article - View full comments

Quoting: kokoko3kstatically linking wouldn't help here, at least not forever.
glibc stands between the kernel and userspace.
So if you don't plan to stay with an outdated kernel forever, a statically linked executable will face the issue sooner or later.
We are talking about a deprecated feature since 16 years, while the new feature replacing it has been available since 2 decades.
Somebody, please, explain me WHY on earth one should still rely on it with a software written today.
This is not a glibc fault.

Good blog post about the problem: https://blog.hiler.eu/win32-the-only-stable-abi/

TL;DR -

* DT_GNU_HASH has been around for 16 years, but has very little documentation associated with it. Especially compared to DT_HASH.
* For those 16 years, it was Glibc who provided the compatibility and overrode the defaults for everyone and there never were any easy-to-spot deprecation warnings.
* The constant changing of libraries in Linux with all disregard for applications targeting them is why for most GameDevs, Win32 is a far more stable ABI to target than anything provided in Linux.

And my personal opinion (from experience) - you are not going to get GameDevs to conform to the "Linux" way or the "Right" way of doing these things. If you want gaming on Linux, we have to go to the GameDevs.

View this comment - View article - View full comments

Quoting: RustyTo be fair to glibc, this is a problem on the part of Epic using the deprecated DT_HASH instead of DT_GNU_HASH. EAC's Linux implementation is frustratingly half-baked. It really feels like Epic is the biggest barrier to gaming on Linux now.

While I can understand that attitude, the issue isn't just EAC. Other Linux native games are also broken as well as some other tools. Regardless, non-service based games generally don't keep their games updated and good luck trying to get the industry to change. Microsoft has been fighting this battle with Windows for a couple of decades. Simple fact is that users want their old software, especially games, to continue working. So if we want Linux gaming to succeed, we have to be willing to meet the game devs where they are and not require them to come to us (hint: they won't come to us).

For those that make comments about Debian "Stable" - I work in the tech space, security issues come in on a fairly daily basis and if things aren't updated almost constantly, they will sadly be vulnerable.

View this comment - View article - View full comments

Quoting: Eike

Quoting: EagleDelta

Quoting: elmapulbecause they dont want to fix it if anything breaks on wine.
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.

This drives me nuts as a programmer. As WINE/Proton is not emulation, but an implementation of Windows/DX/other APIs in Linux/UNIX-based systems, as such things running in WINE are running natively as all WINE does is map APIs to native APIs/calls (well, for the most part).

That's why it's not native. It has to map to native, during runtime. You're running EXEs and DLLs on Linux. Don't know about you, but that wasn't my goal when switching to Linux.

That's the definition of what APIs do - they map calls to something else so that the programmer doesn't need to know all the details under the surface. Hence why web APIs are so popular because they are so ubiquitous.

It seems the Linux Gaming community wants to change the definition of APIs for WINE/Gaming vs everything else. A Web application isn't "native" either, but the reality is that JS/Electron APIs are mapping to System Calls. Which is what C, Python, Ruby, Go, Rust, etc APIs do as well for desktop/CLI applications.

In reality, DXVK is a DX API for Vulkan, WINE is a Windows API for all platforms, faudio is an xaudio API for all platforms, so on and so forth

View this comment - View article - View full comments

Quoting: elmapulbecause they dont want to fix it if anything breaks on wine.
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.

This drives me nuts as a programmer. As WINE/Proton is not emulation, but an implementation of Windows/DX/other APIs in Linux/UNIX-based systems, as such things running in WINE are running natively as all WINE does is map APIs to native APIs/calls (well, for the most part).

View this comment - View article - View full comments