``If your organization used Paypal and they froze your assets once, and you "struggled for more than half a year" to resolve it, why the fuck would you STILL be using Paypal?''
Network effects. They use PayPal because many other people use PayPal. This makes it easy for people to donate. Had Wikileaks not used PayPal, many people who would otherwise donate through PayPal would be forced to find another way, and decide not to bother.
I also use PayPal, but (1) I live in Europe, where PayPal is more strictly regulated, and (2) I make sure to keep my PayPal balance low, so I don't lose a lot if it becomes inaccessible.
One of the problems concerning biofuels is that there is so much misinformation, half-truths, and FUD going around.
A lot of it is actually overgeneralization. E.g. a study finds that producing ethanol from corn using a specific process in the US is not energy efficient, and then people conclude that producing ethanol from any source anywhere in the world is not energy efficient.
Another common claim is "step X of the process uses fossil fuel, therefore, the process is not carbon neutral". This is usually based on the mistaken assumption that the step _necessarily_ uses fossil fuel. In this thread, many people are assuming that we feed fertilizer to the algae and that the fertilizer is produced from or using fossil fuel.
All this makes it very difficult to have a sensible discussion, because many people (on both sides, I'm sure) make assumptions that often turn out to be unnecessary or false. Perhaps we could use something like the spam solutions form to capture some of the common pitfalls, so that we don't have to waste a lot of time countering the mistaken assumptions that keep cropping up.
Billions lost on failed UK IT projects by the 'adults' with developers receiving very fat paycheques shows it guarantees neither success of the project nor accountability within it.
That, and if you look at Unix-like systems, you will see that all of them are dead or dying, except for those that are being carried by volunteers (BSD, GNU, Darwin (mostly BSD), and perhaps OpenSolaris). If "the kind of professional accountability in its developers that only a paycheck can engender" is what a software project needs to "sit at the adults' table", then maybe sitting at the adults' table is not what you really want for your project. After all, all those adults are now either dead or on life support.
To stay with the analogy, perhaps what a project needs to thrive is not to become an adult, but to stay a child.
And it makes sense, too: projects supported by the flow of money will wither when the money flow stops. This in addition to the argument that it always worth keeping in mind: profit-driven companies will do what maximizes profits, not necessarily what is best for the world. These two things often align, but not always and never completely.
``The problem with this story is while a lot of companies are working on Linux, none of them are focused on usability and none of them are focused on the desktop-- the thing Linux is worst at.... At this rate, it'll never improve.''
It's kind of funny we keep hearing this. If you compare pre-1995 Linux distros with, say, current Ubuntu, most people would agree there has been improvement. Also, Canonical has done a lot to improve the Linux desktop experience, and they are not alone. As far as I can see, all of the claims that "none of them are focused on usability", "none of them are focused on the desktop", and "it'll never improve" are all completely false. The desktop being the thing that Linux is worst at is an opinion you are welcome to have, but I'll point out that several people use Linux on the desktop because they see it as their best choice.
All in all, I have to wonder why you want to paint Linux with a dark brush so badly that you resort to outright lies to accomplish it.
In other news, users of Google News click through to the aggregated news outlets an outstanding 50% of the time. It is estimated that this brings more traffic to these outlets than any other single website.
It would also be interesting to see benchmarks of functionality actually provided by the respective kernels. E.g. performance of fork, fork+exec, socket, accept, reads and writes on IPC, multiprocessor/multicore/hyperthreading performance, etc. Past benchmarks have shown that there can be dramatic differences between operating systems especially when large numbers of something (processes, filehandles, CPUs, etc.) are being used simultaneously.
Also, I am missing a description of exactly how they measured. Did they recompile the benchmark suite from scratch on each platform? Which compiler was used, and with which settings? Are they running the same binaries on both? How exactly did they arrive at the presented values? Is each bar the result of a single run, or did they run each benchmark multiple times and account for any variation in observed scores somehow?
As others have already mentioned, it would also be interesting to see how a regular FreeBSD system would fare.
All in all, interesting benchmarks. My conclusion: there isn't that much of a difference between the tested versions of Linux and kFreeBSD in there benchmarks. The difference between 32-bit and 64-bit is usually more pronounced. If you need the highest performance for your application, you'll still have to run your own tests.
It's good to have choices. Even if Linux is the best choice for you today, you can never know that it will be the best choice for you forever. Providing Debian GNU/kFreeBSD not only offers Debian users the option of using the FreeBSD kernel instead of Linux, but also offers FreeBSD users a way to use the GNU userland instead of FreeBSD's.
Moreover, in making different kernels and userlands work together, areas where this is problematic are identified and improved, so that other projects besides Debian can benefit, too.
The end result is that you gain more options to mix and match parts to build the system exactly the way you want it.
``I'll stick with my stage 1 Gentoo which is fast, optimized and ready to go.''
Help me out here. They are dropping DivX because AVI is obsolete? Aren't these two different things? As in: DivX is a codec, and AVI is a container format. So you can encode your video using DivX and store in in an AVI file. Or you could encode using DivX and store in an Ogg file. Or even a raw MPEG4 file. Could someone explain what is _really_ going on here?
``Imagine that, a software design decsision that worked. It's almost like the people who designed Unix were smart guys who knew what they were doing.''
That, but not only that. The programmers who came before them were smart, too.
But the creators of Unix had to work with severely underpowered hardware. This is what has motivated the simplicity of early Unix and early C. And this is why software that follows those ideas works so well on embedded devices, mobile devices, and, heck, everything that is underpowered compared to what other software is built for. This is why we have Linux on everything from wrist watches to supercomputers.
``I guess the point is that the Java you're coding on Android, for performance critical apps at least, feels a lot more low level, takes more time to write and get right than normal desktop or server Java.''
Actually, I rather think that the effort to get the Java code right is probably about the same for Android as it is for "normal desktop or server Java". The difference, though, is that the effect of not getting it right is much more noticeable on a mobile device than on a computer with vast processing power and memory, and practically unlimited electric power.
Also, I suspect that the Java compiler and runtime used on desktop and server systems do a better job of optimizing away inefficiencies than the runtime in Android in its current state.
``You may care about xvid and x264 and whatever other codec or container you want. But your average media consumer is more than likely not even aware of such things in any meaningful way. Convenience and ease of use are the name of the game for your average person.''
And how convenient is it when you can't play the material that you paid for anymore? How convenient is it if you can play it, but only by using one of a handful of approved products? How convenient is it when you can play it only when you have an Internet connection? Only at home, but not in your car?
When it's about convenience, widely supported, non-DRMed formats win.
``This is why I have to run 6 different scanners: because there isn't one that detects all the threats. I currently run 2 antivirus programs along with SpyBot, SuperAntiSpyware, Windows Defender, and Malwarebyte's Anti-Malware.''
And yet, people insist that Windows is user friendly. More so than other operating systems, even.
``# Ivory-tower egghead academics want to keep all their science locked away behind paywalls! How are we supposed to evaluate this if we can't read the paper?!?''
Actually, it's not the academics who want to keep their science locked away behind paywalls. It's the publishing industry.
Perhaps I should point out at this point that Intel has, in fact, made severalnon-x86processors.
In fact, the 64-bit variant of x86 that the world seems to be migrating towards isn't even from Intel, but from AMD. I think it's fair to say that, had it been up to Intel, we'd be moving away from x86.
You seem to be saying that Intel doesn't innovate. I beg to differ. I see a fair bit of innovation coming from Intel, even if not all of it ends up taking the market by storm.
I never did think Mozilla was headed in the right direction. I've long shunned their browsers because, to me, they were bloatware, overly complex and bug-prone and not even offering the features I'd come to love in the competition.
But that didn't prevent Mozilla from making a very successful browser.
So, if now I say that I don't think they are headed in the right direction, what does that really tell anyone? Obviously, their success depends on other things than what I think about it. I wish them all the best, I hope they'll enjoy working on their products, and we'll see how they pan out in practice.
``Even mplayer/mencoder, the best of the bunch imho, has many, many options that won't work together, and can produce output that itself cannot read.''
Woah, there is something that mplayer cannot read?? It has worked for me on so many things, both good and horribly broken, that I half expect that, one day, I'm going to accidentally point it at the wrong file and it's still going to somehow give me the video that I wanted. Hats off to the mplayer contributors, it's truly an amazing program.
``This thread made me read up on video compression, and I can now articulate more precisely why my favorite video codec is Motion-JPEG - It uses 100% I-frames, which makes editing easy, and which makes fast motion scenes look better than codecs which use P and B frames. The only downside is that Motion JPEG doesn't offer the best compression, but it's still reasonably sized.''
For some value of "reasonably sized", I'm sure. But you are including a lot of redundant information in your stream if you represent each frame independently (which is what I frames do). By storing only the differences between frames (which is what B and P frames do), you can reduce the amount of data without losing any information. To achieve the same reduction using MJPEG, you would have to reduce the quality of your frames a lot. In short: if you use only I frames, you get larger files, reduced quality, or both.
The reason you observe that fast motion scenes look better using MJPEG than using other codecs you have tried is not that the other codecs use B and/or P frames, but that they are throwing away too much information. What is likely happening is that they have a limited bit budget per frame, which is enough to encode scenes with few changes between frames, but not enough to encode scenes with many changes between frames. The solution, then, isn't to use only I frames (that would probably make the problem even worse!), but to allow more bits per frame for frames that require it.
A little thought experiment to make it all a little easier to understand: suppose you have two frames that are very similar. Given the choice between storing each frame independently (I frames) or storing one frame completely (I frame) and the other as a diff against it (B or P frame), I think it should be clear that the latter will allow for a better bits:quality ratio. If you are only allowed to store full frames, you will have to sacrifice quality, increase the number of bits, or both. So allowing frames to be encoded as B or P frames is always a good idea. In those cases where it isn't beneficial, you can always still use I frames.
``anyway modern game development means licensing an engine. engine developers worry about supporting open gl or direct x.''
Exactly. That makes me wonder why they actually bother supporting DirectX, though, seeing as DirectX really only works on Windows, which is also supported by the APIs that the other platforms use.
``Plus, like others said, direct x is a whole game api. it's not just graphics. it's input, it's networking, it's sound. the whole platform is very cohesive. I'd rather just keep up with one api, one download, etc than have to follow open gl, open al, etc.''
But you don't; you just use the engine and let the engine developers worry about platform specific APIs. You even said as much yourself.
Also, I don't know to what extent DirectX is "one api". The way I understand it, DirectX is, first of all, made up of several different APIs for different purposes, e.g. Direct3D, DirectSound, and DirectInput. So there isn't really just one API. As for keeping up with it, to what extent is DirectX actually backward and forward compatible? I have never coded for it, so I don't know, but I got the impression that compatibility is often broken between releases. OpenGL seems (again, this is just my uninformed impression) to be rather stable, favoring extensions over completely changing things. Given these things, I find your argument that, with DirectX, you have to only keep up with one API hard to follow. To reiterate, I don't think it's one API, and I don't think it's easier to keep up with than its competing APIs.
``1) completely bogus: OpenGL has an both a good documentation and extremely good literature''
Have links? I had a hard time finding good documentation on OpenGL. A lot of what I did find either uses lots of Windows-specific things, or introduced a lot of code with little explanation. Eventually, I did learn, but I wouldn't say the documentation I used was great. The opengl.org website, in particular, could be more navigable... Also, I've found virtually no introduction to programming OpenGL ES, especially version 2.0.
The question is if this is actually a bug that testing would have caught. The problem is that you can't test _everything_. So what you do is come up with a few scenarios, and you try to at least test the happy flow and the corner cases that you think might cause problems. For numbers, that's usually things like 0, 1, -1, 2^n for various values of n, -2^n for various values of n, and, in the case of years, probably things like 2000, 2100, and past dates if your system has to deal with those (1979, 1969, and 1899 might be interesting). The numbers 2010 and 10 are not usually problematic and not usually tested. Perhaps that will change now, but, really, who would have thought 2010 would be a problem?
What would have caught this bug, I think, is not testing, but code review. For this bug to occur at all, the code must have done some pretty funky year handling. That would definitely have raised my eyebrows and prompted further investigation, especially with Y2K still in mind. I can't guarantee that the bug would have been found by code review (after all, it's easy to overlook bugs in code), but I do give more of a chance to code review than to testing, in this case.
The question is, with all your arguments favoring OpenGL over Direct3D, why are developers still using the latter?
And why do the developers of many portable 3D libraries and game development libraries (Crystal Space, OGRE, etc.) support Direct3D, even though they already have OpenGL support, which would supposedly work just fine?
``However, in this case the reference is to features of the card. See OpenGL is really bad about staying up to date with hardware.''
How can that be, when it allows vendors to add their own extensions? Add a feature to your hardware, add an extension to OpenGL so programmers can use it. No need for delays.
``They are always playing catchup and often their "support" is just to have the vendors implement their own extensions.''
Is there a problem with that? I mean, yes, it would be nicer if features were immediately also included into a standard that was also supported by other vendors, but you can't have it both ways. If progress comes from the vendors, the standard is going to be behind. If progress comes from the standard, the vendors are going to be behind. At least OpenGL defines an extension mechanism that is used by vendors to provide access to new features, while otherwise remanining compatible with standard OpenGL.
``So when a new card comes out, talking about it in terms of OpenGL features isn't useful.''
Perhaps, but, personally, "DirectX 11.0" doesn't tell me anything, either. I suppose it's great to know the DirectX level if you code to DirectX, though. For me, it would be more useful to know which OpenGL version and extensions were supported.
Now, don't get me wrong. I think Microsoft is doing some great work with Direct3D. I doubt there would be as much progress and coherence if it wasn't for Direct3D. It's just a pity they had to go and make their own, incompatible API when an open standard already existed.
Slashdot Mirror
``If your organization used Paypal and they froze your assets once, and you "struggled for more than half a year" to resolve it, why the fuck would you STILL be using Paypal?''
Network effects. They use PayPal because many other people use PayPal. This makes it easy for people to donate. Had Wikileaks not used PayPal, many people who would otherwise donate through PayPal would be forced to find another way, and decide not to bother.
I also use PayPal, but (1) I live in Europe, where PayPal is more strictly regulated, and (2) I make sure to keep my PayPal balance low, so I don't lose a lot if it becomes inaccessible.
One of the problems concerning biofuels is that there is so much misinformation, half-truths, and FUD going around.
A lot of it is actually overgeneralization. E.g. a study finds that producing ethanol from corn using a specific process in the US is not energy efficient, and then people conclude that producing ethanol from any source anywhere in the world is not energy efficient.
Another common claim is "step X of the process uses fossil fuel, therefore, the process is not carbon neutral". This is usually based on the mistaken assumption that the step _necessarily_ uses fossil fuel. In this thread, many people are assuming that we feed fertilizer to the algae and that the fertilizer is produced from or using fossil fuel.
All this makes it very difficult to have a sensible discussion, because many people (on both sides, I'm sure) make assumptions that often turn out to be unnecessary or false. Perhaps we could use something like the spam solutions form to capture some of the common pitfalls, so that we don't have to waste a lot of time countering the mistaken assumptions that keep cropping up.
``But it is true that fertilizer (both phosphates and nitrogen) require a lot of fossil fuel to produce -- usually natural gas.''
And here I thought that
1. Algae grow just fine without us going out of our ways to add fertilizer to them
2. There are plenty of ways to produce fertilizer that don't involve fossil fuels
Your turn again.
Billions lost on failed UK IT projects by the 'adults' with developers receiving very fat paycheques shows it guarantees neither success of the project nor accountability within it.
That, and if you look at Unix-like systems, you will see that all of them are dead or dying, except for those that are being carried by volunteers (BSD, GNU, Darwin (mostly BSD), and perhaps OpenSolaris). If "the kind of professional accountability in its developers that only a paycheck can engender" is what a software project needs to "sit at the adults' table", then maybe sitting at the adults' table is not what you really want for your project. After all, all those adults are now either dead or on life support.
To stay with the analogy, perhaps what a project needs to thrive is not to become an adult, but to stay a child.
And it makes sense, too: projects supported by the flow of money will wither when the money flow stops. This in addition to the argument that it always worth keeping in mind: profit-driven companies will do what maximizes profits, not necessarily what is best for the world. These two things often align, but not always and never completely.
``The problem with this story is while a lot of companies are working on Linux, none of them are focused on usability and none of them are focused on the desktop-- the thing Linux is worst at. ... At this rate, it'll never improve.''
It's kind of funny we keep hearing this. If you compare pre-1995 Linux distros with, say, current Ubuntu, most people would agree there has been improvement. Also, Canonical has done a lot to improve the Linux desktop experience, and they are not alone. As far as I can see, all of the claims that "none of them are focused on usability", "none of them are focused on the desktop", and "it'll never improve" are all completely false. The desktop being the thing that Linux is worst at is an opinion you are welcome to have, but I'll point out that several people use Linux on the desktop because they see it as their best choice.
All in all, I have to wonder why you want to paint Linux with a dark brush so badly that you resort to outright lies to accomplish it.
In other news, users of Google News click through to the aggregated news outlets an outstanding 50% of the time. It is estimated that this brings more traffic to these outlets than any other single website.
It would also be interesting to see benchmarks of functionality actually provided by the respective kernels. E.g. performance of fork, fork+exec, socket, accept, reads and writes on IPC, multiprocessor/multicore/hyperthreading performance, etc. Past benchmarks have shown that there can be dramatic differences between operating systems especially when large numbers of something (processes, filehandles, CPUs, etc.) are being used simultaneously.
Also, I am missing a description of exactly how they measured. Did they recompile the benchmark suite from scratch on each platform? Which compiler was used, and with which settings? Are they running the same binaries on both? How exactly did they arrive at the presented values? Is each bar the result of a single run, or did they run each benchmark multiple times and account for any variation in observed scores somehow?
As others have already mentioned, it would also be interesting to see how a regular FreeBSD system would fare.
All in all, interesting benchmarks. My conclusion: there isn't that much of a difference between the tested versions of Linux and kFreeBSD in there benchmarks. The difference between 32-bit and 64-bit is usually more pronounced. If you need the highest performance for your application, you'll still have to run your own tests.
``Why even swap the kernel out?''
It's good to have choices. Even if Linux is the best choice for you today, you can never know that it will be the best choice for you forever. Providing Debian GNU/kFreeBSD not only offers Debian users the option of using the FreeBSD kernel instead of Linux, but also offers FreeBSD users a way to use the GNU userland instead of FreeBSD's.
Moreover, in making different kernels and userlands work together, areas where this is problematic are identified and improved, so that other projects besides Debian can benefit, too.
The end result is that you gain more options to mix and match parts to build the system exactly the way you want it.
``I'll stick with my stage 1 Gentoo which is fast, optimized and ready to go.''
And you still have that option, too, of course.
Help me out here. They are dropping DivX because AVI is obsolete? Aren't these two different things? As in: DivX is a codec, and AVI is a container format. So you can encode your video using DivX and store in in an AVI file. Or you could encode using DivX and store in an Ogg file. Or even a raw MPEG4 file. Could someone explain what is _really_ going on here?
``Imagine that, a software design decsision that worked. It's almost like the people who designed Unix were smart guys who knew what they were doing.''
That, but not only that. The programmers who came before them were smart, too.
But the creators of Unix had to work with severely underpowered hardware. This is what has motivated the simplicity of early Unix and early C. And this is why software that follows those ideas works so well on embedded devices, mobile devices, and, heck, everything that is underpowered compared to what other software is built for. This is why we have Linux on everything from wrist watches to supercomputers.
``I guess the point is that the Java you're coding on Android, for performance critical apps at least, feels a lot more low level, takes more time to write and get right than normal desktop or server Java.''
Actually, I rather think that the effort to get the Java code right is probably about the same for Android as it is for "normal desktop or server Java". The difference, though, is that the effect of not getting it right is much more noticeable on a mobile device than on a computer with vast processing power and memory, and practically unlimited electric power.
Also, I suspect that the Java compiler and runtime used on desktop and server systems do a better job of optimizing away inefficiencies than the runtime in Android in its current state.
``You may care about xvid and x264 and whatever other codec or container you want. But your average media consumer is more than likely not even aware of such things in any meaningful way. Convenience and ease of use are the name of the game for your average person.''
And how convenient is it when you can't play the material that you paid for anymore? How convenient is it if you can play it, but only by using one of a handful of approved products? How convenient is it when you can play it only when you have an Internet connection? Only at home, but not in your car?
When it's about convenience, widely supported, non-DRMed formats win.
``This is why I have to run 6 different scanners: because there isn't one that detects all the threats. I currently run 2 antivirus programs along with SpyBot, SuperAntiSpyware, Windows Defender, and Malwarebyte's Anti-Malware.''
And yet, people insist that Windows is user friendly. More so than other operating systems, even.
``# Ivory-tower egghead academics want to keep all their science locked away behind paywalls! How are we supposed to evaluate this if we can't read the paper?!?''
Actually, it's not the academics who want to keep their science locked away behind paywalls. It's the publishing industry.
Perhaps I should point out at this point that Intel has, in fact, made several non-x86 processors.
In fact, the 64-bit variant of x86 that the world seems to be migrating towards isn't even from Intel, but from AMD. I think it's fair to say that, had it been up to Intel, we'd be moving away from x86.
``I didn't think you could run the flash player at all on ARM chips.''
Think again: Adobe and ARM Accelerate Flash and AIR for ARM Platforms
You seem to be saying that Intel doesn't innovate. I beg to differ. I see a fair bit of innovation coming from Intel, even if not all of it ends up taking the market by storm.
I never did think Mozilla was headed in the right direction. I've long shunned their browsers because, to me, they were bloatware, overly complex and bug-prone and not even offering the features I'd come to love in the competition.
But that didn't prevent Mozilla from making a very successful browser.
So, if now I say that I don't think they are headed in the right direction, what does that really tell anyone? Obviously, their success depends on other things than what I think about it. I wish them all the best, I hope they'll enjoy working on their products, and we'll see how they pan out in practice.
``Even mplayer/mencoder, the best of the bunch imho, has many, many options that won't work together, and can produce output that itself cannot read.''
Woah, there is something that mplayer cannot read?? It has worked for me on so many things, both good and horribly broken, that I half expect that, one day, I'm going to accidentally point it at the wrong file and it's still going to somehow give me the video that I wanted. Hats off to the mplayer contributors, it's truly an amazing program.
``This thread made me read up on video compression, and I can now articulate more precisely why my favorite video codec is Motion-JPEG - It uses 100% I-frames, which makes editing easy, and which makes fast motion scenes look better than codecs which use P and B frames. The only downside is that Motion JPEG doesn't offer the best compression, but it's still reasonably sized.''
For some value of "reasonably sized", I'm sure. But you are including a lot of redundant information in your stream if you represent each frame independently (which is what I frames do). By storing only the differences between frames (which is what B and P frames do), you can reduce the amount of data without losing any information. To achieve the same reduction using MJPEG, you would have to reduce the quality of your frames a lot. In short: if you use only I frames, you get larger files, reduced quality, or both.
The reason you observe that fast motion scenes look better using MJPEG than using other codecs you have tried is not that the other codecs use B and/or P frames, but that they are throwing away too much information. What is likely happening is that they have a limited bit budget per frame, which is enough to encode scenes with few changes between frames, but not enough to encode scenes with many changes between frames. The solution, then, isn't to use only I frames (that would probably make the problem even worse!), but to allow more bits per frame for frames that require it.
A little thought experiment to make it all a little easier to understand: suppose you have two frames that are very similar. Given the choice between storing each frame independently (I frames) or storing one frame completely (I frame) and the other as a diff against it (B or P frame), I think it should be clear that the latter will allow for a better bits:quality ratio. If you are only allowed to store full frames, you will have to sacrifice quality, increase the number of bits, or both. So allowing frames to be encoded as B or P frames is always a good idea. In those cases where it isn't beneficial, you can always still use I frames.
``anyway modern game development means licensing an engine. engine developers worry about supporting open gl or direct x.''
Exactly. That makes me wonder why they actually bother supporting DirectX, though, seeing as DirectX really only works on Windows, which is also supported by the APIs that the other platforms use.
``Plus, like others said, direct x is a whole game api. it's not just graphics. it's input, it's networking, it's sound. the whole platform is very cohesive. I'd rather just keep up with one api, one download, etc than have to follow open gl, open al, etc.''
But you don't; you just use the engine and let the engine developers worry about platform specific APIs. You even said as much yourself.
Also, I don't know to what extent DirectX is "one api". The way I understand it, DirectX is, first of all, made up of several different APIs for different purposes, e.g. Direct3D, DirectSound, and DirectInput. So there isn't really just one API. As for keeping up with it, to what extent is DirectX actually backward and forward compatible? I have never coded for it, so I don't know, but I got the impression that compatibility is often broken between releases. OpenGL seems (again, this is just my uninformed impression) to be rather stable, favoring extensions over completely changing things. Given these things, I find your argument that, with DirectX, you have to only keep up with one API hard to follow. To reiterate, I don't think it's one API, and I don't think it's easier to keep up with than its competing APIs.
``1) completely bogus: OpenGL has an both a good documentation and extremely good literature''
Have links? I had a hard time finding good documentation on OpenGL. A lot of what I did find either uses lots of Windows-specific things, or introduced a lot of code with little explanation. Eventually, I did learn, but I wouldn't say the documentation I used was great. The opengl.org website, in particular, could be more navigable... Also, I've found virtually no introduction to programming OpenGL ES, especially version 2.0.
The question is if this is actually a bug that testing would have caught. The problem is that you can't test _everything_. So what you do is come up with a few scenarios, and you try to at least test the happy flow and the corner cases that you think might cause problems. For numbers, that's usually things like 0, 1, -1, 2^n for various values of n, -2^n for various values of n, and, in the case of years, probably things like 2000, 2100, and past dates if your system has to deal with those (1979, 1969, and 1899 might be interesting). The numbers 2010 and 10 are not usually problematic and not usually tested. Perhaps that will change now, but, really, who would have thought 2010 would be a problem?
What would have caught this bug, I think, is not testing, but code review. For this bug to occur at all, the code must have done some pretty funky year handling. That would definitely have raised my eyebrows and prompted further investigation, especially with Y2K still in mind. I can't guarantee that the bug would have been found by code review (after all, it's easy to overlook bugs in code), but I do give more of a chance to code review than to testing, in this case.
The question is, with all your arguments favoring OpenGL over Direct3D, why are developers still using the latter?
And why do the developers of many portable 3D libraries and game development libraries (Crystal Space, OGRE, etc.) support Direct3D, even though they already have OpenGL support, which would supposedly work just fine?
``However, in this case the reference is to features of the card. See OpenGL is really bad about staying up to date with hardware.''
How can that be, when it allows vendors to add their own extensions? Add a feature to your hardware, add an extension to OpenGL so programmers can use it. No need for delays.
``They are always playing catchup and often their "support" is just to have the vendors implement their own extensions.''
Is there a problem with that? I mean, yes, it would be nicer if features were immediately also included into a standard that was also supported by other vendors, but you can't have it both ways. If progress comes from the vendors, the standard is going to be behind. If progress comes from the standard, the vendors are going to be behind. At least OpenGL defines an extension mechanism that is used by vendors to provide access to new features, while otherwise remanining compatible with standard OpenGL.
``So when a new card comes out, talking about it in terms of OpenGL features isn't useful.''
Perhaps, but, personally, "DirectX 11.0" doesn't tell me anything, either. I suppose it's great to know the DirectX level if you code to DirectX, though. For me, it would be more useful to know which OpenGL version and extensions were supported.
Now, don't get me wrong. I think Microsoft is doing some great work with Direct3D. I doubt there would be as much progress and coherence if it wasn't for Direct3D. It's just a pity they had to go and make their own, incompatible API when an open standard already existed.