linux, the very weak system for gaming

[gamerk2]

The problem here is the closed-source driver, not the change in kernel API. Do not upgrade your kernel if your closed-source driver supplier does not support it. If you don't want the driver supplier to prevent you from kernel upgrades, convince them to release an open-source driver.

And this is the reason no one develops for Linux: Developers will not constantly upgrade their SW because people like you feel the need to constantly re-write the Kernel API's. Then people are stuck choosing between either an old, underperforming Kernel, or unsupported HW. Then, they give up and go back to Windows.

What if some API function turns out later to be poorly designed / unsafe / not general enough? By never removing any functions you prevent the removal of cruft as well as a good deal of improvement.

Mark it as unsafe. Kernel API calls should RARELY be removed, due to compatability reasons. The only time you can make an argument for doing so is in the case where you re-write the entire API from scratch [which I again note should be done very rarely, with VERY close support from the hardware devs].

[jrch2k8]

And this is the reason no one develops for Linux: Developers will not constantly upgrade their SW because people like you feel the need to constantly re-write the Kernel API's. Then people are stuck choosing between either an old, underperforming Kernel, or unsupported HW. Then, they give up and go back to Windows.



Mark it as unsafe. Kernel API calls should RARELY be removed, due to compatability reasons. The only time you can make an argument for doing so is in the case where you re-write the entire API from scratch [which I again note should be done very rarely, with VERY close support from the hardware devs].

1.) kernel don't drastically change the API every 2 days and this phenomenom normally need 3 major revisions[3.2, 3.3, 3.4, 3.5<this last break api] so is not as extreme as you make it sound.

2.)linux kernel do the same thing than any other kernel API/ABI cycle, linux is just much faster in its release cycle than the others.

3.)thruth be told packaging blob drivers is distro responsability since no one in kernel.org expect ppl to use the great and latest without a very high technical level to begin with.

4.) distros problem is that is really hard to package this blobs correctly[even when using an LTS kernel] due to their alien nature against the OS, so most of the time this frankestein breakage arent actually kernel changes but the packages breaking or users trying to get the latest drivers from external sources due to the distros slow updates for blobs that normally ends badly.

5.) sure there are ways to improve the situation like modularize the kernel [drivers and kernel] and provide an intermediate API between drivers and kernel. in fact you can even fix some issues allowing userspace driver[bluetooth, usb, i2c, pmbus, any low bandwith/latency hardware/sensors]/ kernel drivers[sata/GPU/Raid/scsi/vritualization, the big fat boys] and hybrid drivers[input/dvb/sound/etc] <-- is a titanic job but can be of benefit for stuff like security and stability and if done well drivers API/ABI stability for longer periods of time

[D0pamine]

[TheCycoONE]

let me see you mount a .bin image like that

Pick me!
cdemu load 0 image.cue

Also works with toc's and cue's with isos/mp3s/oggs/etc.

Just had to go through the pain of trying to figure out mixed mode cd images on linux and everyone telling me to just use X windows program, so I thought I'd share.

[gamerk2]

1.) kernel don't drastically change the API every 2 days and this phenomenom normally need 3 major revisions[3.2, 3.3, 3.4, 3.5<this last break api] so is not as extreme as you make it sound.

But it exists. Hardware makers do NOT like to constantly have to update their drivers, especially since a lot of HW is sold for years at a time.

2.)linux kernel do the same thing than any other kernel API/ABI cycle, linux is just much faster in its release cycle than the others.

My question is why the API is in need of constant changes [specifically, removes].

3.)thruth be told packaging blob drivers is distro responsability since no one in kernel.org expect ppl to use the great and latest without a very high technical level to begin with.

So you are basically saying: "Non-geeks do not apply". General users are going to download/install the latest version of SW, period. If they then find their HW doesn't work, guess who's fault that is?

4.) distros problem is that is really hard to package this blobs correctly[even when using an LTS kernel] due to their alien nature against the OS, so most of the time this frankestein breakage arent actually kernel changes but the packages breaking or users trying to get the latest drivers from external sources due to the distros slow updates for blobs that normally ends badly.

"alien nature"? Drivers are the correct way for devices to talk to the OS; thats how it SHOULD be done. The API is the interface from which they do this, so all devices can code to one standard.

If drivers can't be packaged easily with the OS, then either the packaging system or the OS [or both] is faulty. Stop complaining then and fix it.

5.) sure there are ways to improve the situation like modularize the kernel [drivers and kernel] and provide an intermediate API between drivers and kernel. in fact you can even fix some issues allowing userspace driver[bluetooth, usb, i2c, pmbus, any low bandwith/latency hardware/sensors]/ kernel drivers[sata/GPU/Raid/scsi/vritualization, the big fat boys] and hybrid drivers[input/dvb/sound/etc] <-- is a titanic job but can be of benefit for stuff like security and stability and if done well drivers API/ABI stability for longer periods of time

But doesn't those difficulties prehaps point to more underlying problems with the overall system architecture?

[jrch2k8]

But it exists. Hardware makers do NOT like to constantly have to update their drivers, especially since a lot of HW is sold for years at a time.



My question is why the API is in need of constant changes [specifically, removes].



So you are basically saying: "Non-geeks do not apply". General users are going to download/install the latest version of SW, period. If they then find their HW doesn't work, guess who's fault that is?



"alien nature"? Drivers are the correct way for devices to talk to the OS; thats how it SHOULD be done. The API is the interface from which they do this, so all devices can code to one standard.

If drivers can't be packaged easily with the OS, then either the packaging system or the OS [or both] is faulty. Stop complaining then and fix it.
But doesn't those difficulties prehaps point to more underlying problems with the overall system architecture?

1.) this is the reason most of them send/release/contribute code to the kernel or help kernel developers to integrate their drivers into main tree <--[microsoft, redhat, adaptec, lsi, ibm, hp, atheros,etc], mostly the problem is GPU blobs and BIOS manufacturers[they don't respect in any possible way the ACPI standard and the ongoing ligitations are slow]

2.) Linux has much Unix inheritance that is useless or unstable or terribly outdated from that distance past and after many years of research many new improved technologies are entering in tree to fix or remove the dinos[remove of big lock, VSE, tickless, RT, ASLR, Batman, openswtich,virtio,kvm, numa, etc]

3.) sure but if you upgrade to windows 8 beta and you gpu freezes the PC and you call microsoft or nvidia the answer is? the same apply here ppl just get confused cuz vanilla kernel release cycle is only 6-10 weeks compared to 2-5 years from microsoft or 1-2 years with OS X. so the distro in this case is the one that chooses the kernel [distro == windows aka an product based on X kernel while kernel is just a kernel not an OS]

4.)sadly not nvidia or amd are package friendly and both need to replace a big chunk of your distro[kernel mgmt, libgl,libglx,ddx,etc] it can get pretty messy and they both seem to love their script and refuse any other option[amd is bit better here since they open documentation and r600g is a native driver]

5.)nvidia and fglrx driver code is not linux native code beyond the most basic[0.5% maybe] and the same is true for windows, they use 99% of the code for windows and linux [that is why the nvidia/fglrx drivers has more LOC than nt/linux kernel added togheter] that its what alien means and that 99% is an .o precompiled blackbox that only nvidia know wtf it uses internally<-- this is not the proper way to write a driver in any os is just the cheaper way to do it

[D0pamine]

Does anyone have an example of a game or program that has stopped working due to api changes?

[russofris]

Does anyone have an example of a game or program that has stopped working due to api changes?

Only momentarily. They started working again shortly after when the developers updated the release. All of the programs were network utilities though (Ethereal may have been one of them, and it was many years ago). I also had some GPIB cards that had problems after a kernel subsystem overhaul, and were dropped (never corrected). I'm not pissed off at the kernel devs though. The blame lies with the GPIB mftr who had to choose between updating their kernel drivers, or attempt to charge me for new hardware. They chose the latter. I resolved the situation by purchasing a $100 surplus Optiplex, and installing a distro that was old enough to support the hardware (RedHat 7.2). I heard that the box is still running, and that the GPIB cards are still working a decade later.

I guess my point is... Yes, stuff breaks. It's not a complete myth, and it's not as bad as the pooh-pooh'ers make it out to be. It sucks when you're the odd man out and an application's developers or mftr chooses not to stay with the times. Applications and chips that you spent real money on end up on a legacy box with an older kernel. You can often extend their lifetime by a few years this way. I have trouble imagining scenarios where someone would blame Linux for the situation though, and in a number of scenarios, mitigation is trivial enough to forgive the misgivings of any responsible party.

F

[D0pamine]

I do understand especially when it comes to various expansion cards - I tried to get a scsi card working on winxp sp3 for a scanner once which worked with no effort form me in debian. I've never used ethereal although I know of it - a guy at work was talking about it once but he was using wireshark which he was trying to get me to use instead of tcpdump however i was thinking more of non-free games ( its understandable that a program that uses libpcap breaks if libpcap is updated or any other library for that matter ) I have few games for GNU/Linux but they all work still from unreal tournament (99) to postal 2 to quake wars - they all work without issue on ~amd64 gentoo and postal 2 works on debian squeeze for sure

really i cant find a game that doesn't work...

why has wine been built for windows i wonder? is it because this is more of a windows problem than a GNU/Linux problem or does someone out there love mingw enough to compile wine for windows for no good reason

i'd love to see some evidence of GNU/Linux being an inferior gaming platform to any OS not just win

[gamerk2]

1.) this is the reason most of them send/release/contribute code to the kernel or help kernel developers to integrate their drivers into main tree <--[microsoft, redhat, adaptec, lsi, ibm, hp, atheros,etc], mostly the problem is GPU blobs and BIOS manufacturers[they don't respect in any possible way the ACPI standard and the ongoing ligitations are slow]

And yet, not a problem on other platforms. And GPU manufacturers are NOT going to contribute much to open source, if for no other reason then company coding standards are typically confidential. Nevermind you don't want the competitors to see what you did, and decide to "borrow" a few ideas.

2.) Linux has much Unix inheritance that is useless or unstable or terribly outdated from that distance past and after many years of research many new improved technologies are entering in tree to fix or remove the dinos[remove of big lock, VSE, tickless, RT, ASLR, Batman, openswtich,virtio,kvm, numa, etc]

...And? Feel free to change to backend. Do NOT change the underlying API calls. If I have an API call that my program uses, you are free to do whatever you want to the IMPLEMENTATION of said API call, but if you remove the call entirely and break my program, you are going to have one really ticked off developer.

My point being, if you have an API call to create a thread [we'll just call it CreateThread for simplicities sake] that takes a number of parameters, that API call better remain supported, forever, and as long as you provide the proper output, I'm happy. The rest is all implementation, which should be done independent of the underlying API. So if you end up with a new model for creating threads, feel free to implement it. Just make sure the call that creates said thread remains CreateThread.

So yes, deletes of API calls should be exceedingly rare.

4.)sadly not nvidia or amd are package friendly and both need to replace a big chunk of your distro[kernel mgmt, libgl,libglx,ddx,etc] it can get pretty messy and they both seem to love their script and refuse any other option[amd is bit better here since they open documentation and r600g is a native driver]

Probably because AMD/NVIDIA has a unified driver architecture that is mostly OS independent. Point being, they aren't going to change. Although I'd "love" to hear your definition of "package unfriendly".

5.)nvidia and fglrx driver code is not linux native code beyond the most basic[0.5% maybe] and the same is true for windows, they use 99% of the code for windows and linux [that is why the nvidia/fglrx drivers has more LOC than nt/linux kernel added togheter] that its what alien means and that 99% is an .o precompiled blackbox that only nvidia know wtf it uses internally<-- this is not the proper way to write a driver in any os is just the cheaper way to do it

Unified code is cheaper to maintain, and should be mostly OS independent. With the exception of any OS API calls, there really shouldn't be any reason to not use a unified code architecture.