id Software: Linux Hasn't Produced Positive Results

[gamerk2]

And yes, this includes Linus Torvalds himself. His recent rant against nVidia shows that he doesn't grasp the problem either. nVidia also struggles with the instability of software interfaces in linux. That is Linus' fault, not nVidia's. It's not nVidia who keeps changing the interfaces, it's Linus (and the various other kernel/driver/Xorg/etc developers). He clearly does not understand this, and blames nVidia instead.

Agreed 100% with this.

[Scali]

Assigning blame is counterproductive.

It's not about assigning blame. It is a fact that only Linus and the other kernel/Xorg etc developers can solve this problem (which they also have created themselves). nVidia cannot do anything about it (well yes, in theory they could fork the kernel and all relevant packages and make their own nVidianux distribution, but that's not going be a very practical solution for all the people already using various distributions for various reasons). So it is up to Linus and his team.

Nvidia doesn't support Linux. Nvidia supports it's customers. Linux developers 'try' to support Nvidia (nouveau), and Nvidia is not interested in helping due to some imaginary and contorted notion of "property".

Interesting, and horribly inaccurate way to look at the situation.
nVidia supports its customers yes, also its linux-using customers (and FreeBSD, and Solaris, who else does that? AMD certainly doesn't. Intel sorta does because they outsource their driver development to an open source company in the first place, so they end up in MesaGL directly).
Therefore nVidia supports linux.
In fact, nVidia makes the only linux drivers that are actually competitive in terms of features, performance and stability, with OSes such as Windows and OS X.

Why would nVidia help Nouveau? Firstly it's obviously not an option for a company like nVidia to open source their entire drivers, and give away all their advantages on software (and at least partly hardware, since a lot can be deduced from the drivers) to all competitors for free.
Intel is in a different situation, since firstly their GPUs are not competitive, their technology is a few years behind AMD's and nVidia's, lagging behind both in features and performance. So there is little for competitors to get out of it. And secondly, Intel is not a GPU-company. They make their money from CPUs. Buying an Intel CPU is the only way to get an Intel GPU.
nVidia however sells GPUs primarily. So their GPUs need to have a competitive edge. And by extension, so do their drivers. The obvious way to ensure that your drivers are of the highest possible quality, and supported the best as possible, is to do it yourself, rather than relying on some independent third-party developers.

Secondly, nVidia already develops drivers, so I don't know what the developers of a project like Nouveau are thinking in the first place. They need to reverse-engineer everything, and can not even remotely compete with nVidia's own drivers in terms of compatibility, features, stability and whatnot. It's a fool's errand to try and develop drivers without the support of the IHV itself.
Yes, I know, they do it out of their belief in FOSS and all that... Doesn't make it any less of a fool's errand though.

[Scali]

I didn't think the latter was allowed by the GPL.

I believe it is allowed, as long as you make the source code publicly available (doesn't have to be distributed with the app itself, as long as it can be downloaded somewhere, or ordered on CD against p&p only, or such).

[Scali]

Agreed 100% with this.

Yes, to expand on that... Linus' rant was about nVidia's Optimus technology not working in linux.
Thing is, it doesn't work in Windows either, with the exception of Windows 7.
Why is this? Because Windows 7 has a specific interface in the driver model, which allows drivers from different vendors to work together on a single system (in Vista it is not possible to use cards/drivers from two or more vendors at a time at all).
This interface also allows for hot-switching between adapters.
Linux does not have such an interface. Therefore it is not possible for nVidia to implement this.
They would have to hardcode it in all common display drivers, and include them as part of their own driver, in order to ensure that they cooperate together properly. Not an option.
What is needed is a proper vendor-agnostic interface, something like what Windows 7 implemented.

[johnc]

I believe it is allowed, as long as you make the source code publicly available (doesn't have to be distributed with the app itself, as long as it can be downloaded somewhere, or ordered on CD against p&p only, or such).

Yeah but in the context of a game that's going to be fairly rare. id might take that step (to open source their code), but most publishers won't.

[Scali]

Yeah but in the context of a game that's going to be fairly rare. id might take that step (to open source their code), but most publishers won't.

True, it is only an option if you actually want to open source your game in the first place.
However, I was more concerned about the technical side of things. You can't just distribute your game with a few libraries... because these libraries depend on other libraries etc etc... Before you know it, you'll be packing an entire linux distro in your installer, just to make sure you caught all. And even then, things may not actually work.
For example, you can't just pre-bake audio or video support in your application. These things need to be tuned to the audio/video hardware available on the system.

In short, it's just not the way to do it. Having a stable platform is (and oh the irony that various linux distributions actually have a 'stable' distribution for pretty much that same reason. Problem is, even these stable distributions are generally only supported for a few years at most, and the stable version of one distributor is still not compatible with that of other distributors).

[gamerk2]

Yes, to expand on that... Linus' rant was about nVidia's Optimus technology not working in linux.
Thing is, it doesn't work in Windows either, with the exception of Windows 7.
Why is this? Because Windows 7 has a specific interface in the driver model, which allows drivers from different vendors to work together on a single system (in Vista it is not possible to use cards/drivers from two or more vendors at a time at all).
This interface also allows for hot-switching between adapters.
Linux does not have such an interface. Therefore it is not possible for nVidia to implement this.
They would have to hardcode it in all common display drivers, and include them as part of their own driver, in order to ensure that they cooperate together properly. Not an option.
What is needed is a proper vendor-agnostic interface, something like what Windows 7 implemented.

Exactly. Its up to the OS developer to provide the interface for the device manufacturers to write drivers that can interact with the hardware as desired. Optimus is one example where that interface does not exist. And its up to the developers to provide an interface that will allow it to be implemented.

[crazycheese]

*Bunch of idiotical trolling crap from stoplinux.ru member was here*

Нахуй послан.

You are missing the point! It is not about how many patches and changes are released, it is about how they may or may not break existing software.
Also, .NET is a platform of its own. It has no effect on any native Windows software.

.Net is being more and more tightly integrated into windows, currently it is VERY hard to use windows without .net installed. I don?t think you can draw .net as a "non-native" anymore. But it was just an example. There is VC/VB runtime libraries as another example.

For .net, you need at least 6 different versions - releases and servicepacks.
This is newer approach to "compatibility" dillema - instead of mixing everything together (DLL hell), they are use "isle" approach that - still eats a lot of space, minimizes yet does not solve improvement breakage.

I understand your point quite good. But I don?t like the trade-offs that unavoidably come when you apply your method at all. This is what you have to understand in turn.
From my perspective, it is much better for developer to track changes within the libraries he uses for his applications - and to update them. This is the only single trouble.
In return, he gets "tracking different library versions", "different bugs within", "multiple releases", "exploits", "inter-library compability chaos aka breaking everywhere" spared.
Only software that is MAINTAINED is really ALIVE. This is lesson you learn from using Linux.

This is a problem, if you are a "coder", and not a "programmer". And especially, if your code is closed source - then, you are the only responsible for maintaining it.

I am NOT talking about package management or making packages here - at all.

Aside from Wine not exactly being the most objective source of information... it is common knowledge that Microsoft actually maintains certain quirks for compatibility reasons. I suggest you read some of Raymond Chen's blogs: http://blogs.msdn.com/b/oldnewthing/
Again, the point is: backward compatibility

Wine is free implementation of winapi over unix, so I think it is pretty objective and accurate - as it per definition tries to copy 1:1 winapi behaviour.
Backwards compability is the reason for 95% all problems in windows. And its not really working.
I know that a lot of stuff crashes and breaks within windows upon update - from win2k source code comments.

Oh yea, everyone uses the exact same version of the exact same linux distribution with the exact same updates. Oh wait, they don't!

I repeat, yet again for third time - it is not your job to care what version linux distribution uses.
If you want to package your software for distribution yourself, just package it. If they use outdated library versions - notify them, that they should use lastest stable.
As easy as that.

Of course it is avoidable. Most platforms avoid this. That's the whole point. Linux is a crappy platform to develop for because it is one of the few platforms that doesn't put any effort in compatibility.

It does not put effort in "compatibility", because all software is meant to be compatible by default.
What it does lack, is absence of dog nails. This is advantage, hence Linux is best platform for development.
By the way, you can combine multiple versions to be present at same time - for example, debian uses "update alternatives" and gentoo "slots" for this. This is completely transparent for the end-program and is managed by distribution itself. However, this is never meant to "stabilize" anything, but to soften the "transfer" to newer version, till the software is rewritten.

Changes don't have to break compatibility.

Change by definition is breakage.

Lol, no it's not. Do you actually believe the shit you're saying?

Thanks, quite polite of you.

No, let's talk about how linux advocates can't take any criticism and always start bashing Windows. This isn't about Windows, this is about linux, and how it is not a stable platform to develop for. The Windows registry is completely irrelevant in this discussion.
Windows itself is completely irrelevant in this discussion, aside from the fact that it is an example of a stable platform. But we could easily ignore Windows, and use another example of a stable platform. Such as Android.

In order to critisize, you should at least have major experience in BOTH of the subjects. You lack the experience in one of the subjects and try to stretch one approach on another, painfully (but luckily not too much) reacting to anyone who subjects your own opinion. Get Gentoo, use it as primary OS for at least 2 years straight, then return to the topic. More or less, this would be a good experience for you.

What misunderstanding? That I am a professional developer, and you are just some loudmouth linux fanboy with no professional development experience whatsoever?

I sorry, but I will not tolerate this. If you claim yourself to be a "professional" ain?t you supposed to behave as one?

The point is: you should never even have to make ports for various versions. Write once, run anywhere.
Package once, run anywhere. By your own admission this is not possible.

My own admission is to write once and package anywhere.

The world doesn't have a default, that's the whole point.

Repeat this to yourself 5 times (or more, if needed), please.

Yes you can. Older Android packages can be installed as-is on newer versions of Android. Stop arguing about things you don't even have a clue about.
I have written Android apps myself, and I have installed stuff I developed for 2.3 on 4.0 without making any changes to the package whatsoever.
This is what happens with most Android apps in the Google Play store. They just work. In fact, I wouldn't be surprised if a lot of apps haven't received an update since 2.3 was the current version.

No offence, but if you need an ophthalmologist, I know one. I repeat yet again - my claim was that you can?t call new API on older system. You can?t use functionality within Android 4.0 on old Android 2.2. The reverse is possible even on Linux, but because Linux does not have major "cruft" management (some stability is present, but can be broken as needed) there is certain probability that you will have to rewrite your program to use updated interfaces - or it won?t execute. While you are proud that "most apps in Google Play store. They just work.", I would be ashamed of "most". Those are orphans, and if they are proprietary - they are left to themselves with much higher probability. Its quite quite bad to use such a software.

That's not the same thing.
I 'babysit' my code in the sense that I test it whenever a new platform comes out.
However, that does not mean that I need to make changes. At least, not in the general case. Linux is different.

Linux is exactly same, but you will need to keep an eye a bit closer. Users will thank you for that!

I know you fail to understand it. But I've explained it, so the rest is up to you.

First, you are human (ain?t you?), just like me. Humans make mistakes. Mistakes come out because humans are a) desynced, b)imperfect by design. b) is vital, because otherwise, humans will start nuclear war due to boredom.
Second, the chance to gain experience does not equal in experience gained. The ranks don?t play any role for me, only knowledge.
In the end, we are exchanging knowledge for sake of improvement, and not competing in genetals sizes. So, ones sizes don?t mean anything to me in this scope.

Well, they were trying to adopt the Direct3D approach: new hardware us newer interfaces.
However, they messed it up, and in the end they just continued using the old interface, but with various functionality taken out.
Which is indeed similar to the linux approach: a very poor one. The OpenGL API has become a monstrosity.

One can?t satisfy everyone. One will overfill and explode. I like this OpenGL approach, but lets see if this works out and be better than a previous one.

[russofris]

It's not about assigning blame. I

But that's exactly what you did, and what you are continuing to do in your post. You then make statements that are contrary to reality and use them as a base for your arguments. Nvidia 'could' open source their drivers. The only thing that prevents them from doing so is the imaginary spaghetti monster that they have told you about.

I know, and respect, Nvidia's choice. I just won't pretend that they didn't have, or make one. Especially when we have living examples of companies making the opposite choice (intel).

F

[crazycheese]

What reversed implication? Be specific.

Fact 1: [Carmack saying: "Not nearly as many people are interested in paying for games on the platform."]

Fact 2: [Josh Walrath allows himself, in interpret Carmack as: "Linux development is another story altogether. Even though Valve is now actively pursuing the Linux market, iD has been there before, and just has not seen positive results. Remember how many past titles from iD actually ran on Linux, and for how long these were supported? John says that Linux development simply does not pay the bills. It creates goodwill among the Linux crowd, but that is about it."]

Fact 3: [Phoronix & other websites cite Josh Walrath opinion as that of Carmack]

Fact 4: [Linux users get angry, because everything cited by Fact 2 is false].

What you have done is:

Fact 2 -> Fact 4, which is correct, but origin is false.
But then: Fact 4 -> Fact 2, which is invalid implication.

Fact 4 & Fact 1 will, however, very probably catalyse themself now. This was started by Carmack and is his choice, nothing to be done here.