For people new to Linux dealing with dependencies can be a pain in the neck. Then there are those who want their games to "just work" without having go into the terminal to suss out the problem.

You can always remove the packed in libs anyway so better to include them by default.

When you require a different ABI version which is not available on the system that counts more towards the last resort. Not ideal, but at least somewhat tolerable. In an ideal world the application would be ported, but we are in the real world. ;)

Exactly this kind of "convenience" is the source of many problems on the Internet. And dealing with dependencies does not have to be a problem or have to require the use of a terminal. But of course the current switch from .deb packages (with proper dependency handling) to a generic installer (without dependency handling) doesn't make things better.

There are two major issues with libraries. First is keeping the ABI compatible, and second is security. Bundling improves the first, but degrades the second. I.e. even if underlying distro libraries are updated with security patches, your bundled ones will remain stale, unless you'll patch them on your own. So it's a trade-off and there is no clear cut "best" solution really.

Most games are for entertainment, and most people don't like to do any extra work just to be entertained.

Imagine the new user has installed Ubuntu 14.04 64-bit and wants to test run some games from their library. Lets say he picks Volgarr: The Viking and installs the game...Guess what! Volgarr dose not run out of the box on 14.04 64-bit. Why? Because, it does not include the 32-bit libsdl2.so.

So what is a newbie going to think about this? The game worked fine on Windows after installing from the .exe like every other game from GOG, but Ubuntu refuses to run the game. If they come here for help, the first thing they are going to get is instructions to run in the terminal. Even if it solves their problem, they will likely say "Forget this Linux crap! I'm going back to Windows where running games is less of a hassle" or something along that line...

You know how to suss out these issues and fix them. GREAT! Delete the old libs from the games directory and run the game with the fresh ones installed in your distro!

For now, including some of the needed libraries with games is a necessary evil.

That's a question of proper dependency handling. When the game depends on that library and the library is available on the system it should automatically be installed when you install the game. Bundling the library with the game is not the solution.

The problem is not my installation, I know how to handle that. The problem is the number of systems of users which do not know how to handle it and which are not provided with security updates of these bundled libraries and then work as spam relays, members of bot nets, whatever ...

Which is the lesser evil: Having to do a bit of extra work to keep your Linux gaming PC secure or doing a bit of extra work more often just to get a game to run? Most developers think its the former and I'm inclined to agree. Experienced users know how to replace unneeded old libs and nothing stops them from doing so.

It's NEW and less experienced users who just want the game to run and usually don't care about "bloat" or "security" (they learn about and appreciate these things latter) its for their sake that the Steam runtime and bundled libraries are a thing, and until something better AND convenient comes along it's a minor annoyance were going to have to deal with if we want Linux gaming to go anywhere.

For the record I don't LIKE it either, but I see why its the current way of doing things.

That assumes that the packages are available at all.

For example, I've encountered various Mono and node-webkit games where, on Ubuntu 12.04, they worked out of the box perfectly but, on 14.04, you had to do non-trivial stuff to get them to work because they depended on system libraries with ABI versions which simply weren't in the package repository anymore.

For example, many games built on proprietary node-webkit/nw.js-based engines now depend on libudev.so.0 due to the engine developers being slow to release updated builds.

However, Ubuntu 14.04 only offers libudev.so.1 and many indie devs are instructing people to make a symlink to libudev.so.1 since, in whatever they've tested, the ABI mismatch hasn't caused a crash.

(I'm not sure why they don't just bundle a build of libudev.so.0. It's LGPLed, they're not statically linking to it, and the source is something on the order of 150KiB. Trivial to bundle to ensure they'll always be satisfying their LGPL obligations.)

Again, it's not about my system (or the systems of experienced users), but about the systems of users which are not experienced enough or do not care. Delivering software to their systems without proper security support is supporting Internet crime. And no, Internet crime is not a "minor annoyance", sorry.

To say including some musty old 32-bit libraries with games is "supporting internet crime" is a bit far fetched and it does not get around the problem of frustrated new users after failing or having some degree of difficulty getting said 32-bit games running on a 64-bit 'buntu or Mint install returning to Windows, where they are far, far worse off.

As I wrote above, there are better methods to handle missing dependencies than to bundle copies of system libraries with an application. But I give up, I'm tired of these convenience over security discussions.

PS: I dare to disagree about Windows security, it's maintained quite well these days. And I'm really not a Windows fan. Windows suffers from the same problem which is coming to Linux now, 3rd party software developers which do not care about security and deliver unmaintained copies of system libraries.

I'm only talking about libraries which are available on the system. When you need a library which is not available on the target system you don't have a choice, you have to bundle it. You still have to provide security support for it, though. :)

And I'm talking about how indie developers often don't have the time (and may not even have the skills, if they're depending on 3rd-party tooling) to watch for when "included with the system" becomes "not included with the system" and release an update.

As on Windows, their answer is to bundle anything they've seen anyone been burned by to pre-emptively avoid that risk. The Steam Runtime is basically "ape Microsoft by bundling an entire runtime environment with Steam itself which we can use to guarantee library availability in the face of security updates."

(In essence, you're taking the idealist view and I'm taking the pragmatist view.)

I'd say that the best compromise between those two without either depending on Valve or somehow forcing distros to maintain old ABIs would be to take something like the AppStream standard in development over at FreeDesktop (which aims to standardize package metadata such as dependencies across distros) and then tie it to some "Try to pull in these packages from the system repository. If they're not available, fall back to bundled copies" logic.

And how do you expect these developers to provide security support for their bundled libraries when they do not even have the time or the skills to check if that library is included with the system? Seriously, then they should do another job.

No. Doing software development that way is criminal and should be treated as that. Imagine a car manufacturer which does not "have the time" or the skills to check if their built-in seat belts work ...

Edit: Software is more and more getting a critical part of our infrastructure, of our lives. It's about time software manufacturers have the same responsibility for their products as any other manufacturer already has.

Obviously we're not going to see eye-to-eye on this. If I'd designed the system of laws, attempting to enforce your viewpoint on games and other digital forms of artistic expression would have a name like "criminal suppression of cultural exchange".

Besides, even if it were possible to enforce that politically on a global scale (Which it isn't. Just look at how the movie industry failed to stamp out code like DeCSS and at the ongoing failures to block access to sites like The Pirate Bay. In fact, there are good arguments to be made that attempting to do so is a human rights violation.), it's impossible to enforce on a technical level.

I'm a Computer Information Science major and one academic paper I read on the subject summarized its findings by analogizing the inherent fragility of software to the golden gate bridge collapsing to dust because not enough force was applied when tightening one single bolt. (And we can't fix that in the near future because the only reason the world is so robust is because it's unimaginably, massively redundant. A bolt is a cooperating collection of countless sub-microscopic bonds and we don't even have the processing power to add "just turn it on" support for soft-body physics and fluid dynamics to the full ecosystem of ready-to-run physics engines yet.)

I firmly believe that the solution is better sandboxing, better support infrastructure for developers, and a push to make as much of the game code as possible commonly maintained.

1. Microsoft, Apple, and the Linux ecosystem are all working toward OS-level sandboxing for applications, which should provide a first layer of protection.
2. The various Linux desktop projects which work together via FreeDesktop.org are working on a cross-distro solution for package metadata.
3. The Rust programming language looks very promising as a C/C++ replacement which can rule out entire classes of bugs across wide swathes of code.
4. As the games industry matures, more and more code is becoming open-source, which sets the foundation for something like "Game engines can update independently from the games that are built on them. On Linux, games depend on a system-provided engine" to become feasible.

(Think "system-provided ScummVM/DOSBox/etc." on a massive scale.)

If you're not familiar with Rust, it's a Mozilla-developed language intended to replace C++ for writing programs like web browsers which must be both high-performance and high-security. It gives you VM-like safety guarantees without the overhead of a VM by verifying safety invariants at compile-time and Cargo, its combination package manager and build automation tool beats every other language I've tried for making it easy to publish as much of your program as you want in the form of small, cooperating components.

Rust is specifically designed so it can call C code easily and you can generate a C-compatible library in it, so you can upgrade your program piecemeal. (The Firefox source has already gained experimental support for opting into URL and MP4 parsing using Rust.) They're also designing an API for exchanging memory management information with a garbage collector so the interface between Rust libraries and garbage-collected languages doesn't have to be a point of friction and potential bugs.

UPDATE: Here are a couple of links that help to make clear why Rust is such a big deal:
https://cmcenroe.me/2015/08/08/why-rust.html
http://blog.skylight.io/rust-means-never-having-to-close-a-socket/

I just downloaded the latest .sh package of the Witcher 2 from GOG, and it crashes at startup (current Debian testing, KDE Plasma 5 with Nvidia 355.06 driver). The reason I'm using Nvidia beta driver is that their latest stable driver doesn't work with Debian at all (something is messed up there).

I'm not sure if it's the GOG update that's causing it, or the fact that Debian testing recently switched to KDE Plasma 5 (I didn't play the previous version in Plasma 5). Did anyone encounter this?

I think we are not talking about the same thing. I do not mean people which make mistakes which always will happen, especially in the high complexity of software systems. I talk about the attitude to intentionally and deliberately ignore security aspects only because it requires less effort ("have no time") and is cheaper. Software manufacturers should be responsible for such kind of misconduct as every other manufacturer already is. That has nothing to do with cultural exchange, human rights or restricting free speech. I'm the last one who wants to restrict that. Its about commercial activity. When you sell a software product or service (it doesn't matter if it's a game or any other software) you are responsible for its security. Maybe software vendor would have fit better for that than software manufacturer.

No technical means will help anything if nobody feels responsible and will be made responsible for the security of the final software product. There's no reason why software vendors should be treated differently to any other vendors.