Worked pretty well on KDE last time I tried. Except for Payday 2.

I usually drag windows to the correct monitor with alt+click if they show up on the wrong one. Some windows require the Steam overlay to be open for this to work.

Also, I think you have less trouble if your primary monitor is on on the left (which has almost never been the case for me, sadly).

View this comment - View article - View full comments

You had a fair share of valid points (I especially agree with the very last one), but I read your post as being quite aggressive, and it seems that I have been misunderstood multiple times. So there goes the counter-multiquote.

Quoting: devnull

"Bundling" can be interpreted differently form statically linking, though. I usually agree with "bundling"/providing the shared libraries along with the executable (and maybe a LD_LIBRARY_PATH "hack" in a launcher script), but not with static linking.

Shouldn't be required if symbol versions are used.

I don't think I understood this correctly. What shouldn't be required?

Quoting: devnull

The only "valid" reason I can think of for statically linking executables is to distribute your program as only one binary. But even then, there are better options (sfxs, flatpack-like files with an embedded filesystem image or archive), and it only concerns a very nice portion of all applications (usually, portable ones).

Security. How secure depends entirely on the attack surface of course but in general preload is easier then binary editing.

I am not sure statically linking actually reduces risks at all (it doesn't prevent code injection at all, but just raises the difficulty a bit). It can also be a security risk, because you then statically linked libs with CVEs in them, and no mean to upgrade them (especially if the developer doesn't care anymore, which is unfortunately often the case).

Quoting: devnull

But yes, carefully pick the libs you bundle. To me, the general rules are:

• Libs everyone have (double check everyone *is* everyone). Don't bundle them, dynamically link.


• Libraries provided by a third party as part of a special contract with your studio/company: provide them as .so

Redistribution rights may prohibit it.

I didn't mean it that way. What I meant is that you had to provide them (but preferably as shared objects, so that they can be upgraded later by the consumer, if you care about your consumer, that is ;) )

Quoting: devnull

Internal libraries developed by your studio/company: statically link them, perform a monolithic compilation with them or provide them as .so depending on your needs or update/modding/debug policy

Don't quite see the difference between this and above. If it's not public IP, there's no reason not to protect it.

The difference here is that if that's *your* IP, *you* are the one who is going to update it. Contrast this to the case where ex. Valve releases a steamaudio fix. If they do, the customer can upgrade the .so (that's done transparently trough Steam, usually). If that's your lib, you will probably release an update to the game when you update the lib (if you are a good guy). Of course, this is only useful when the company producing the game goes downhill, and that's not the use case most companies care most about.

Quoting: devnull

"wild" libraries that are not very well maintained, or can break the API (early development version, for instance): avoid them, you will probably run into problems a few years down. If you must use them, provide them, don't statically link them but prefer them to the host libraries. That way, you make it possible to tinker with them if it stops working, but they should work the same way regardless of the system.

Invitation to disaster. There are MANY libraries that aren't backward compatible. Pulse for example. Simply including or not including doesn't negate other dependencies elsewhere.

Avoiding poorly maintained libraries is an invitation to disaster? Come on, tell me you didn't say this just to contradict me. Breaking the ABI/API is ok when the library is well versioned. That way, the system can provide the different versions, or compatibility shims.

Quoting: devnull

Prefer open source libraries whenever possible (still avoid the previous case): generally well maintained, people can fix them easily if they are broken a few years down the line, or write wrappers for them in the worst case.

Bit irrelevant. There are quite open source libraries that are not backward compatible and outright refuse to run otherwise. Pulse, dbus, etc.

I must confess that I didn't really get your sentence.

Quoting: devnull

Whenever possible (and that's usually a more general software rule), avoid complex dependencies. Both for the libs you choose (they should depend on a minimum of other libraries) and for your application. Bonus points if you can enable/disable some dependencies via a config file (though you may have to manually load your libraries. It's not *that* complicated, and as a bonus, you can gracefully fallback and disable features)

Also a bit irrelevant. The linker has no problems resolving dependencies. There is a bit of overhead at runtime though.

As far as I know, the linker has to link every dependency at runtime, before even starting to execute the program. You have to dlopen() if you want to handle complex feature toggling.

View this comment - View article - View full comments

"TheSHEEP Likes this article" -- :P

This game looks entertaining, I like the fact that they have to carry the sheep out.

Is there a way to bring the sheep back? (Like dispatching a vehicle to do so, which might get harmed by the incoming troops).

View this comment - View article - View full comments

Quoting: Lakorta

Quoting: MayeulCLooks like some people went all the way to reverse engineer the steam platform: https://github.com/SteamRE/SteamKit [External Link]

They also have a "Depot Downloader [External Link]". Which makes it a fully open-source (afaik) way to download steam games. Now, if only we could get a shim to make wine games work with the Linux client, that would be great :)

Someone tried to do something like that once (https://github.com/sirnuke/steambridge [External Link]. Unfortunately that project is dead (also I never tried it out so I don't know how well it worked).

Ah, thanks, I've been trying to find again the name of that project for quite some time. Starred it. It's a shame the project has been discontinued, though.

View this comment - View article - View full comments

Glad to see some progress on this.

To VP: How can we apologize to CD Projekt Red for our initial reaction regarding The Witcher 2 port? I am longing for TW3, and you have proven that eon has come a long way in terms of performance/playability :)

View this comment - View article - View full comments

As a heads up: steam keys can now be activated here [External Link].

I also found this a few minutes ago to download steam depots without the steam client nor SteamCMD.

View this comment - View article - View full comments

Looks like some people went all the way to reverse engineer the steam platform: https://github.com/SteamRE/SteamKit [External Link]

They also have a "Depot Downloader [External Link]". Which makes it a fully open-source (afaik) way to download steam games. Now, if only we could get a shim to make wine games work with the Linux client, that would be great :)

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: MblackwellI hate to get into the weeds a bit but at a certain point it's just semantics since you could copy the files out if there's no DRM on them and back them up yourself. GOG also isn't DRM free by your logic because it requires you to have a valid account with a purchase license and to log in to their servers to download the game and any patches.

You use some limited definition of DRM that doesn't include installation (why so?), also you confuse DRM with authentication i.e. an account. Both of those are wrong. Account doesn't make it DRM, but lack of installer / package that you can legally back up, does. To put it very shortly, DRM is an artificial restriction on what you can with your digital goods do after purchase. So let's make it clear, backing up something from Steam to work around their lack of DRM-free package, violates their TOS already.

While I agree that the lack of a standard gateway to get the product (no webpage) is a bit concerning, some of the games offered on Steam have no DRM mechanisms whatsoever. You can just copy the files and run them somewhere else, and the game will not perform any further authentication to check whether you have the right to play it (which makes it DRM-free in my book).
I am not sure it violates Steam's TOS, I would have to read those again. But I am pretty sure they stated that it was up to the developer to include DRM in their products. Plus, if I am not mistaken, VALVe clearly allows you to backup your games from the Steam client (they even provide some functionality to this effect).

SteamCMD can also be used to download the games (or servers) without the fully-fledged client. It was bothering me to download a non-free tool to do so; but in essence, your goal is to download a proprietary game, so it isn't too annoying in the end.

View this comment - View article - View full comments

Quoting: CorbenAs N30N mentioned in his post [External Link] on the Steam forums, it might be easier to just set this launch option of Everspace, instead of editing the start script:

ignore="%command%" ./RSG/Binaries/Linux/RSG-Linux-Shipping

Didn't know about the "ignore" option so far. Learning never stops! :)

Well, that's not really an option, you just declare a new environment variable that will contain the original command, and then proceed to launch the executable directly :)

I guess it could work as well with echo "%command%"; ./RSG/Binaries/Linux/RSG-Linux-Shipping 
What I like to do to debug games that won't accept being launched directly is to have Steam launch a terminal emulator, with the original command as an environment variable. Then, I just launch $ignore (or whatever I assigned) in the terminal.

Quoting: ShmerlI didn't really follow the whole thread. So does it work with Mesa git or not?

Some people are saying that it requires LLVM 5.0, I am inclined to believe them.

View this comment - View article - View full comments

Quoting: appetrosyanI keep wondering, why is Nvidia, being an aggressively competitive and For profit company dishing out better drivers than the pro-FOSS AMD?

Short answer: they don't.
AMD always had the more compliant drivers. They will complain when a game does something that shouldn't work according to the spec; while that's not the case with nVidia's.
It is also a matter of optimization: different code-paths provide different performance on the two brands, so the code running when you have an nVidia card is different from the one running when you use an AMD one. This can lead to some issues, as it seems to be the case here. Generally speaking, doing enough testing on both sides avoids these kind of problems, but developers who use an nVidia card are more likely to see bugs on AMD.
Some commenters pointed out that this issue seems to be fixed in the latest UE. This isn't really the devs'fault in this case, as the engine they used had this issue.

And now, regarding user experience, I've personally had it much better on AMD. Your mileage will vary, of course.

Whoops, looks like I was ninja'ed. Well, that will teach me to read all the comments before writing a reply.

Liam, could you update the article with the workaround a lot of people seem to need? (Delete LD_LIBRARY_PATH from the launcher script). Thanks!

View this comment - View article - View full comments