linux, the very weak system for gaming

[jrch2k8]

well about the video posted by OP there is 1 thing where i agree !!!package management!!!.

debian packages and redhat packages has so many years copying each other that i dare to say they mostly do the same things internally and it just become a religious war for the small details here and there.
[dream]
i think both deb and rpm should get joined into the new package system LSP[as linux software package] that include the best of each and make it part of LSB[i know i know but is an start]or make the FSF put some pressure dunno and code a couple of nice tool for convert the old RPM/DEB into LSP and maybe integrate even something like fatelf concept that allows you to include several binary[or deltas] for the most common cpu settings[i386,i686,x86_64] in 1 package.

as delivery system well apt-get and yum are quite good so either is fine and both can be improved a lot

i think this will make a huge improvement for linux[binary distros OFC, gentoo/arch[nerdcore distros] are just good as they are] and will lower a lot the current packaging mess between distros
[/dream]

[ChrisXY]

well about the video posted by OP there is 1 thing where i agree !!!

You also need to watch the other talk by the same person: "Why Linux Does Not Suck" http://www.youtube.com/watch?v=BfLqLK7VdQY

You should realize that the first talk is not to be taken too seriously. Many slides of the first talk are copypasted into the second talk. It just shows that some of the things that make linux suck are also things that make linux great.

A unified package manager won't solve the too many problems anyway. Example: current Ubuntu has boost 1.48, my Archlinux has boost 1.5. A package depending on some hypothetical function in boost 1.48 that would be removed in boost 1.5 would work fine in ubuntu but break horribly with some cryptic error message (if you had trouble with different boost versions, you'll understand ) on arch. Sure you can encode library versions in your package, but then it just won't install on one of the two.

[jrch2k8]

You also need to watch the other talk by the same person: "Why Linux Does Not Suck" http://www.youtube.com/watch?v=BfLqLK7VdQY

You should realize that the first talk is not to be taken too seriously. Many slides of the first talk are copypasted into the second talk. It just shows that some of the things that make linux suck are also things that make linux great.

A unified package manager won't solve the too many problems anyway. Example: current Ubuntu has boost 1.48, my Archlinux has boost 1.5. A package depending on some hypothetical function in boost 1.48 that would be removed in boost 1.5 would work fine in ubuntu but break horribly with some cryptic error message (if you had trouble with different boost versions, you'll understand ) on arch. Sure you can encode library versions in your package, but then it just won't install on one of the two.

well i didn't meant it as distro independant cuz as you correctly state dependencies are a bitch but more as SLP for ubuntu/debian/fedora/etc like today you have a debian .deb or an ubuntu.deb for X version, my point is an unified package format means 1 format/1 packaging tool/1 learning curve instead of find a way to package .deb then package with rpm then tgz then tar.gz, etc.

sure distros do lot of this work today but nonetheless a common toolset is a much better solution than 5 or more and even if you have do 1 LSP package per distro is just the same tool used again and again that for bussiness is more interesting than have a guy fighting with 5 systems or 5 experts 1 per system, besides if you are careful with dependencies you can even pull off 1 package for most LSP distros of a particular release cycle.

i agree with the fact that distro independant package is feasible but would require more than just a package system[1 package system is a good start tho]

[gamerk2]

edit: PS linux is stable in its (most of) POSIX API

*laughed so hard, I have a sore throat*

POSIX is a joke. No programmer takes that API seriously.

[gamerk2]

I find amazing that many posters forgot 3D games on Microsoft Windows 7 requires third party drivers i.e AMD Catalyst or Nvidia Forceware. Most comments never actually run stock driver from a bare-bone Microsoft Windows 7, they will face the same problem with majority of distribution using mesa. Some benchmarks don't take account of that crucial factor. Mesa driver is amazing despite its lagging from third-parties drivers.

Yes, but the interface to the OS hasn't changed significantly over the years. The biggest change was the WDDM for graphics drivers starting with Vista, which frankly, was a LONG overdue change. But the API calls to the OS are stable over time [no removes], making driver development a non-issue.

Without a stable interface to the Kernel, that works independently of whatever configuration the user happens to be running, you are going to have a lot of really crappy drivers, and won't see developers target the OS.

[jrch2k8]

*laughed so hard, I have a sore throat*

POSIX is a joke. No programmer takes that API seriously.

im laughing hard at you

posix is not meant to be used for regular devs LOL is lot lower lvl than that(wikipedia fail?) and is used a lot[PPPPPPP[as POSIX]threads ring a bell for example] pipes, semaphores, signalling, scheduling, SHM, AIO, etc[i can be all day here]

http://es.wikipedia.org/wiki/POSIX

for reference some big projects using posix you have GLIBC[and variants], Kernel, and basically core GNU stack, most toolkits[Qt, GTK,etc] and many more, ofc some project use more posix functions than others[<--OVBIOUSLY] cuz make no sense link to pthreads if your app isn't threaded for example but you get the idea

[jrch2k8]

Without a stable interface to the Kernel, that works independently of whatever configuration the user happens to be running, you are going to have a lot of really crappy drivers, and won't see developers target the OS.

well this is true to some extent but i can say for sure many drivers are lot better in linux than its windows couterpart [especially server hardware like fiber channels. RAID hW, etc] but yes find a way to maintain the basic subsystem APIs needed to write drivers isolated of the core kernel API [maybe some intermediary library] can be very good idea in the driver development scenario but keeping them OSS[gplX.x forced so you can't link blobs legally or something like that im not a lawyer so no much help here].

OSS drivers > closed blobs[except for GPU for now in performance]

[jrch2k8]

mmm we could agree that linux is not 100%posix but is true that the missing features make no sense to implement them in a modern unless you want to maintain compatibility with ancient unixes system but the important and useful one are all in linux

[Tweenk]

Unfortunately third party development for Linux is difficult due to a lack of stable API's. There are often incompatibilities between different Linux distributions, and between different versions of the same distribution - even if they are released just a few months apart.

100% false. You seem to have little idea what you are talking about.
Link your application statically or bundle it with the libraries it uses, which is a common practice on Windows. Done.

There is also a lack of a standardized way of distributing software that works across different Linux distributions.

This is true, but providing .deb and .rpm covers 99% of Linux users and doesn't take that much time. One guy can figure it out in 2 workdays. Not convenient but not a showstopper either.

If there isn't a package for your specific distribution you'll usually end up with a .tar.gz and a howto. That's why you often need to use various hacks and tricks to get third party software working.

For 90% of games distributed as .tar.gz it's as difficult as:
1. Left click .tar.gz, select 'Extract Here'
2. Double-click the executable or launcher script
3. Play game

Hopefully the situation will improve since both Ubuntu and Gnome is aiming for API stability now.

The situation will stay the same because API stability was never a problem in the first place, unless you did something really stupid.

[Tweenk]

A unified package manager won't solve the too many problems anyway. Example: current Ubuntu has boost 1.48, my Archlinux has boost 1.5. A package depending on some hypothetical function in boost 1.48 that would be removed in boost 1.5 would work fine in ubuntu but break horribly with some cryptic error message (if you had trouble with different boost versions, you'll understand ) on arch. Sure you can encode library versions in your package, but then it just won't install on one of the two.

Include the Boost libraries in your package and the problem is gone. (This is also the solution used on Windows.)
Who says that all programs on Linux must use the system version of all libraries?
If you need your application to work on as many systems as possible, you have only two options
a) bundle libraries with the application
b) release the source and let distribution maintainers package it for you