Last time I checked, OpenAL was pretty incomplete. It may be enough for some games, but you aren't getting a lot out of it. The first thing that comes to my mind is direct output to certain speakers, useful e.g. for playing a video with a premixed audio track. Sure, there's the hack that stereo samples in OpenAL get no spatial processing and will always end up on front left/front right. But there's no way to directly address other speakers, if they are present. In DirectSound, on the other hand, you can create a hardware buffer with 4 to 8 channels (one for each speaker) and there are existing audio engines out there that do just that.
If you want to compare OpenAL to something that MS created, you should rather look at DirectSound3D, which sits on top of DirectSound and also concerns itself only with the 3D mixdown.
There is one thing missing for real on Linux: an audio interface that works as reliably as DirectSound on Windows. As it is, your choices on Linux are pretty much OSS or alsa if you want to do real-time audio output across distos and then there are those distros out there that in their default installation block direct access to the audio interface in favor of the audio routing daemon of the day. Add to the mix the fact that either alsa (with or without OSS emulation) or OSS, but not both could be present in the kernel, this stuff truely isn't pretty.
A similar ugliness arises around OpenGL: there are a bunch of implementations out there and you are pretty much guaranteed to have one on the system. But that's where the guarantees stop. OpenGL has changed a lot in the last 10 years and you're in for a mixed bag of versions and extensions. This is especially bad because the open source drivers many distros default are just crappy. The only really decent driver that I'd want to code a game against on Linux is the binary blob from nVidia. Just imagine talking a noob through an update of the graphics driver on Linux through a phone line once he/she discovers that the game doesn't run properly... it ain't pretty.
(If you want to counter with "my OpenGL desktop compositing runs fine, so the driver must be fine, too", don't - games demand a heck of a lot more from the video hardware than some simple textured quad rendering nowadays)
I don't believe it. I experienced it. They learn just what they need to get their particular problem solved, when they need it. Remember, these people are lab rats, not coders. And most probably coders wouldn't understand what the scientist actually want to get done. So it's a catch-22 here.
If you really have to handle all that languages correctly, then you are of course right. But when your files only store digits, 7 bit ASCII is indistinguishable from UTF-8;-).
As a matter of fact, I am German and I still try to avoid writing Umlauts and stuff in text files for the reasons that you cite. Ah, the cruelties of 8 bit code page incompatibilities...
I hereby humbly suggest that you are, instead, wrong. Here is why:
Scientists are not software developers and never want to be that. They want to run their experiments and analyse their data. The latter requires recording and processing of numerical data. This is where computers enter their workflow - as number crunching tools that have to be easy to use and utterly flexible.
At times, my work consisted of writing lots of one-off C and Python program to process data in ever new ways in order to get an idea what I was actually looking at. And I had to write them myself because these weren't your run of the mill analysis steps. Many of these programs were not run again once I had their results. During all this time, I as a scientist was looking to get the data in and out of the programs in ways that are easy to code without getting distracted from what I wanted to achieve scientifically. My head was full of theory and formulas, not data structures and good software design.
In that particular state of mind, writing SQL isn't one of the things that I would have wanted to spend any time on. The inherent complexities are a distraction and a big one at that. And, hell, I'm one of the guys who actually *know* SQL. Most scientists actually don't. Hell, many of them barely know how to use their favorite language's core libs to their advantage. They don't care and - may I say - rightly so.
Besides, the code would get more bloated. If I want to output three values that belong together I write a print statement that places them on the same line of text in the output file and I'm done. That's a one-liner that takes me about 20 seconds to type in. In the worst case, I need to open a file beforehand and close it afterwards instead of piping it into stdout. That's maybe 3 lines of code. Now tell me: how many lines of code do I need to write to place these values in a database? That is, provided that a table already exists to hold that data.
My point is: relational databases don't do the job for scientists. Instead, they get in the way. And you and anyone else here who is arguing in favor of them probably lack the related experience to understand that - no offense intended. The points you make are derived from pure theory. Respect the needs of the users as well, please.
Maybe there is a middle ground here: hire a software developer who builds and maintains the DB and a nice, convenient to use wrapper library around it for you. That'll take a while and someone will have to foot the bill for it.
To everybody here suggesting relational databases: you are on the wrong track here, I'm afraid to tell you. Relational databases handle large sets of completely homogenious data well if you can be bothered to write software for all the I/O around them. This is where it all falls apart:
1. Many lab experiments don't give you the exact same data every time. You often don't do the same experiment over and over. You vary it and the data handling tools have to be flexible enough to cope with that. Relational databases aren't the answer to that.
2. Storing and fetching data through database interfaces is vastly more difficult than just using the standard input/ouput or plain text files. I've written hundreds of programs for processing experimental data and I can tell you: nothing beats plain old ASCII text files! The biggest boon is that they are compatible to almost any scientific software you can get your hands on. Your custom database likely is not. Or how would you load the contents your database table into gnuplot, Xmgrace or Origin, just to name a few tools that come to my mind right now?
I wish I had a good answer to the problem. At times I wished for one myself, but I fear the best reply might still be "shut up and cope with it".
Python isn't ready in the same way that Java is. There is no really stable just in time compiler that I'm aware of (I might miss something here, though). Then there is the hampered threading support in CPython because of the nasty Global Interpreter Lock. At least on multicore CPUs you can't expect to get much out of a single Python process, even if you're doing multithreaded programming. And the CPython VM is sloooow compared to Java. Most of that comes from the extreme extreme dynamics that Python allows at runtime - they incur a huge overhead because any kind of static analysis on Python code is basically impossible and therefore optimizations are extremely hard to do.
I wish I wouldn't have to say any of this. I like Python.
... this could give some better numbers as to how many Linux systems are actually out there. As long as this package isn't installed automatically without prompting, this is great and very useful.
Tire sensors are built to run on battery for years. You can't easily get to them and change the battery, so these things are extreme low power devices. Each line of code for these controllers costs real world battery lifetime and shortens maintenance cycles. The same goes for extra crypto hardware: every transistor costs. So I'm not surprised that the protocol is not secured to oblivion. There simply isn't room for that unless battery storage capacities rise by an order of magnitude or two. So, a part of me wonders whether this researcher has had a look at the constraints of these systems and understood them before he tried to make the news.
Still, this is no excuse for being able to corrupt the receiving controller irreparably by some protocol error. These errors can occur normally as transmission errors, not just through deliberate attacks. This is where the sloppy engineering exists and the only part of the story that is actually newsworthy.
Eclipse isn't strictly breaking the Java memory model - only by being such a huge application. The permanent generation is used for constant values/objects and Java class bytecode. The latter turns out to be the critical issue here: With a couple of plugins installed, Eclipse can easily grow to such a huge binary code size that the default permgen size is not sufficient, which leads to weird out of memory crashes of Eclipse once the permgen is full. And the permgen has a fixed size that does not depend on stack and heap size.
Making the code available for scrutiny is a double-edged sword. Sure, it might help to catch critical bugs in the software faster. But with some devices, it really raises a host of new issues. Some pacemakers out there are configurable wirelessly once they are in the patient's body. This is actually a very critical feature. But do you want to risk everyone being able to reverse-engineer the protocol used for adjusting the settings for such a device? A wrongly configured pacemaker can be deadly. Right now these things are fairly secure because they are rather rare and not interesting enough as targets for hacking.
Besides, proving that some piece of code works as intended (or at least fails gracefully in all circumstances) in an essentially uncontrolled environment is quite a feat. Embedded equipment is hard to service, has to have a longer hardware lifespan than normal hardware, is often custom designed for a single application and thus may have subtle hardware defects not reproducible on similar test systems... oh, and who says that the compiler or even the CPU is bug free? This is all common knowledge around here, but I just want to give the full list. What this means is that just opening the source code might not cut it. The validation would have to be performed on the hardware it was designed to run. So, where's the call to open up the hardware design and documentation to public scrutiny as well?
For moving images it doesn't matter how many times the same frame is projected onto the screen. What matters is the number of *different* frames per second per eye. If that gets to low, you get stuttering and have to compensate by artificially blurring the image. I am not sure how the 3D projection works on a frame-by-frame level, but I'd like to get some pointers to information on that.
The term "4096p" is a term that the journalist copying from the original blog post came up with. It's clearly wrong: the video does not have 4k rows of pixels. The the term "4k" for the resolution comes from the 4k pixels horizontally. The digital big screen film formats have been classified into "2k" and "4k" categories because of their horizontal numbers of pixels for some 10 years or so now. The 1080p HDTV format is slightly below the 2k big screen resolutions. But in television, the people are counting lines, not columns, probably because it was hard to get additional scanlines back when the analogue TV standards were developed. Thus the confusion.
You can do all of the compositing and some of the vector rendering in OpenGL, too. Take the new OpenGL cairo backend as an example. And if there's something you can't do directly in OpenGL, you can still upload a texture and do a final compositing pass on that including the video texture. I think Flash even does some of that in the OpenGL accellerated rendering they have. So yes, maybe Adobe is bitching a bit too much here.
nVidia is still far from becoming unimportant, even with them having basically botched their new generation of chips. Besides the obviously huge game market, there is a maket for business and research applications that rely on GPGPU power. And this is a market that is flat-out dominated by CUDA. My guess is that a lot of desktop workstations are bought with nVidia cards because of the sheer possibility to run GPU accelerated code, no matter if it (a) ever implemented and (b) actually implemented in CUDA. I'm extrapolating from my work environment here.
I don't know if nVidia has the money to make a solid comeback with a (massivly) revised/improved Fermi chip that they will desperately need to jump ahead of AMD once more. Even if not, they won't just vanish from the face of the earth. At worst, they have made themselves only second to AMD and still way ahead of Intel when considering product capabilities. Intel caters to a mass market of business machines with low end 3D requirements, which is a high volume market with much simpler and cheaper chips, leaving plenty of room for higher graphics performance.
I remember having read the pages that you link to a long time ago. Tone mapping issues are very real and noticable on rendered images - but in subtle way. The lighting just tends to look wrong, as you showed so nicely. I'm trying to get it right in my software, but it's not so trivial. Even if you know you handle it correctly internally, you have to be sure to handle input and output correctly as well. And it's very easy to make a mistake there.
Still, I'm quite surprised that software like Photoshop that ought to be awfully aware of color spaces does not convert to/from linear automatically. This would be the right thing to do in my opinion. Or does this "loophole" leave some sort of artist control that I'm not aware of?
My interpretation is simply that they want to reach the density and temperature required to start fusion within the plasma. This only means that the fusion reaction is starting to happen. Only after that can one start to ask the interesting questions (can enough energy be extracted to have a net surplus? can the energy output be improved? is this economically viable?). So they aren't done for several years yet.
It hasn't been entirely spotless. There were some major technical difficulties during reentry a while ago (in 2008 or so). I don't remember any details and don't have time to look up sources, though.
All I remember is that the capsule is designed to be separated into 3 parts in early reentry with only the middle part (the crew cabin) actually returning. There was a problem with a revised design of the explosive bolts that separated the upper part causing a less than smooth separation which ended up rotating the craft. And I think this happened on two occasions and could have been fatal to the crew.
The URL appending when cutting and pasting is easily defeated by pasting using the middle mouse button. That script still sends selection information, though. Can anybody tell me what this data is collected for? I don't see any value in it.
What I see in this video is "just" a state of the art game engine renderer. The current generation of games only expoits a subset of the features of current generation hardware. Were it not for the strict realtime requirements that are present in games, which push the available CPU time for rendering in the range of 3 to 6ms for 60FPS (the rest of the time is taken up by other parts of the game), the visuals could be immensely more impressive. And none of that is something that can be done in DirectX exclusively.
Hardware tesselation is demoed in the video you mentioned, but this is only available on highest end ATI hardware at the moment and AMD published extension specifications for that as early as March 2009 (see for example http://www.opengl.org/registry/specs/AMD/vertex_shader_tessellator.txt)! When did Windows 7 hit the market? October?
Although I can see your point you should not forget that gaming is a huge market with a volume in the billions of dollars. I highly doublt that the market for CAD type software is even half as big. Any manufacturer caring solely for the later would be concentrating on a niche market only, which does not make any sense economically.
You are missing much, much more important points here:
1. There is an SDK with literally hundreds of really, *really* cool top-notch high-end/highest-end demos for DirectX. Some of these come straight out of Microsoft Research. Nothing says "Use me! I'm cool!" like that set of demos. The closest thing on the OpenGL side of things that I know of is the demo gallery that nVidia has, but it's not as cool IMO.
2. There are debugging tools like PIX available for free. This thing has its restrictions, but seeing my colleagues analyzing textures, vertex buffers and draw calls graphically to figure out what they're doing wrong sometimes makes me envy them. And it turns out to be a real time saver. On the OpenGL side I find myself writing lots of this stuff from scratch just for my app. Sure, there are tools like bugle, but they are far inferior to what MS has to offer.
Having said that, I still feel more comfortable with OpenGL on Linux. This is what I'm used to and it works for me - not that this will ever make a difference, though.
As part of my work, I do some very advanced things in OpenGL and I have yet to find a hardware feature that is available in DirectX, but not OpenGL. Can you please point me to a particular feature that is missing in OpenGL?
Slashdot Mirror
Last time I checked, OpenAL was pretty incomplete. It may be enough for some games, but you aren't getting a lot out of it. The first thing that comes to my mind is direct output to certain speakers, useful e.g. for playing a video with a premixed audio track. Sure, there's the hack that stereo samples in OpenAL get no spatial processing and will always end up on front left/front right. But there's no way to directly address other speakers, if they are present. In DirectSound, on the other hand, you can create a hardware buffer with 4 to 8 channels (one for each speaker) and there are existing audio engines out there that do just that.
If you want to compare OpenAL to something that MS created, you should rather look at DirectSound3D, which sits on top of DirectSound and also concerns itself only with the 3D mixdown.
There is one thing missing for real on Linux: an audio interface that works as reliably as DirectSound on Windows. As it is, your choices on Linux are pretty much OSS or alsa if you want to do real-time audio output across distos and then there are those distros out there that in their default installation block direct access to the audio interface in favor of the audio routing daemon of the day. Add to the mix the fact that either alsa (with or without OSS emulation) or OSS, but not both could be present in the kernel, this stuff truely isn't pretty.
A similar ugliness arises around OpenGL: there are a bunch of implementations out there and you are pretty much guaranteed to have one on the system. But that's where the guarantees stop. OpenGL has changed a lot in the last 10 years and you're in for a mixed bag of versions and extensions. This is especially bad because the open source drivers many distros default are just crappy. The only really decent driver that I'd want to code a game against on Linux is the binary blob from nVidia. Just imagine talking a noob through an update of the graphics driver on Linux through a phone line once he/she discovers that the game doesn't run properly... it ain't pretty.
(If you want to counter with "my OpenGL desktop compositing runs fine, so the driver must be fine, too", don't - games demand a heck of a lot more from the video hardware than some simple textured quad rendering nowadays)
I don't believe it. I experienced it. They learn just what they need to get their particular problem solved, when they need it. Remember, these people are lab rats, not coders. And most probably coders wouldn't understand what the scientist actually want to get done. So it's a catch-22 here.
If you really have to handle all that languages correctly, then you are of course right. But when your files only store digits, 7 bit ASCII is indistinguishable from UTF-8 ;-).
As a matter of fact, I am German and I still try to avoid writing Umlauts and stuff in text files for the reasons that you cite. Ah, the cruelties of 8 bit code page incompatibilities...
I hereby humbly suggest that you are, instead, wrong. Here is why:
Scientists are not software developers and never want to be that. They want to run their experiments and analyse their data. The latter requires recording and processing of numerical data. This is where computers enter their workflow - as number crunching tools that have to be easy to use and utterly flexible.
At times, my work consisted of writing lots of one-off C and Python program to process data in ever new ways in order to get an idea what I was actually looking at. And I had to write them myself because these weren't your run of the mill analysis steps. Many of these programs were not run again once I had their results. During all this time, I as a scientist was looking to get the data in and out of the programs in ways that are easy to code without getting distracted from what I wanted to achieve scientifically. My head was full of theory and formulas, not data structures and good software design.
In that particular state of mind, writing SQL isn't one of the things that I would have wanted to spend any time on. The inherent complexities are a distraction and a big one at that. And, hell, I'm one of the guys who actually *know* SQL. Most scientists actually don't. Hell, many of them barely know how to use their favorite language's core libs to their advantage. They don't care and - may I say - rightly so.
Besides, the code would get more bloated. If I want to output three values that belong together I write a print statement that places them on the same line of text in the output file and I'm done. That's a one-liner that takes me about 20 seconds to type in. In the worst case, I need to open a file beforehand and close it afterwards instead of piping it into stdout. That's maybe 3 lines of code. Now tell me: how many lines of code do I need to write to place these values in a database? That is, provided that a table already exists to hold that data.
My point is: relational databases don't do the job for scientists. Instead, they get in the way. And you and anyone else here who is arguing in favor of them probably lack the related experience to understand that - no offense intended. The points you make are derived from pure theory. Respect the needs of the users as well, please.
Maybe there is a middle ground here: hire a software developer who builds and maintains the DB and a nice, convenient to use wrapper library around it for you. That'll take a while and someone will have to foot the bill for it.
To everybody here suggesting relational databases: you are on the wrong track here, I'm afraid to tell you. Relational databases handle large sets of completely homogenious data well if you can be bothered to write software for all the I/O around them. This is where it all falls apart:
1. Many lab experiments don't give you the exact same data every time. You often don't do the same experiment over and over. You vary it and the data handling tools have to be flexible enough to cope with that. Relational databases aren't the answer to that.
2. Storing and fetching data through database interfaces is vastly more difficult than just using the standard input/ouput or plain text files. I've written hundreds of programs for processing experimental data and I can tell you: nothing beats plain old ASCII text files! The biggest boon is that they are compatible to almost any scientific software you can get your hands on. Your custom database likely is not. Or how would you load the contents your database table into gnuplot, Xmgrace or Origin, just to name a few tools that come to my mind right now?
I wish I had a good answer to the problem. At times I wished for one myself, but I fear the best reply might still be "shut up and cope with it".
Python isn't ready in the same way that Java is. There is no really stable just in time compiler that I'm aware of (I might miss something here, though). Then there is the hampered threading support in CPython because of the nasty Global Interpreter Lock. At least on multicore CPUs you can't expect to get much out of a single Python process, even if you're doing multithreaded programming. And the CPython VM is sloooow compared to Java. Most of that comes from the extreme extreme dynamics that Python allows at runtime - they incur a huge overhead because any kind of static analysis on Python code is basically impossible and therefore optimizations are extremely hard to do.
I wish I wouldn't have to say any of this. I like Python.
There already is such an institution: it's called Supreme Court.
Or maybe there isn't. It's hard to tell these days.
There already is such an institution: I believe it's called Supreme Court.
Or maybe there isn't. It's hard to tell these days.
... this could give some better numbers as to how many Linux systems are actually out there. As long as this package isn't installed automatically without prompting, this is great and very useful.
Tire sensors are built to run on battery for years. You can't easily get to them and change the battery, so these things are extreme low power devices. Each line of code for these controllers costs real world battery lifetime and shortens maintenance cycles. The same goes for extra crypto hardware: every transistor costs. So I'm not surprised that the protocol is not secured to oblivion. There simply isn't room for that unless battery storage capacities rise by an order of magnitude or two. So, a part of me wonders whether this researcher has had a look at the constraints of these systems and understood them before he tried to make the news.
Still, this is no excuse for being able to corrupt the receiving controller irreparably by some protocol error. These errors can occur normally as transmission errors, not just through deliberate attacks. This is where the sloppy engineering exists and the only part of the story that is actually newsworthy.
Eclipse isn't strictly breaking the Java memory model - only by being such a huge application. The permanent generation is used for constant values/objects and Java class bytecode. The latter turns out to be the critical issue here: With a couple of plugins installed, Eclipse can easily grow to such a huge binary code size that the default permgen size is not sufficient, which leads to weird out of memory crashes of Eclipse once the permgen is full. And the permgen has a fixed size that does not depend on stack and heap size.
Making the code available for scrutiny is a double-edged sword. Sure, it might help to catch critical bugs in the software faster. But with some devices, it really raises a host of new issues. Some pacemakers out there are configurable wirelessly once they are in the patient's body. This is actually a very critical feature. But do you want to risk everyone being able to reverse-engineer the protocol used for adjusting the settings for such a device? A wrongly configured pacemaker can be deadly. Right now these things are fairly secure because they are rather rare and not interesting enough as targets for hacking.
Besides, proving that some piece of code works as intended (or at least fails gracefully in all circumstances) in an essentially uncontrolled environment is quite a feat. Embedded equipment is hard to service, has to have a longer hardware lifespan than normal hardware, is often custom designed for a single application and thus may have subtle hardware defects not reproducible on similar test systems... oh, and who says that the compiler or even the CPU is bug free? This is all common knowledge around here, but I just want to give the full list. What this means is that just opening the source code might not cut it. The validation would have to be performed on the hardware it was designed to run. So, where's the call to open up the hardware design and documentation to public scrutiny as well?
Score one for the marketing department ;-)
For moving images it doesn't matter how many times the same frame is projected onto the screen. What matters is the number of *different* frames per second per eye. If that gets to low, you get stuttering and have to compensate by artificially blurring the image. I am not sure how the 3D projection works on a frame-by-frame level, but I'd like to get some pointers to information on that.
The term "4096p" is a term that the journalist copying from the original blog post came up with. It's clearly wrong: the video does not have 4k rows of pixels. The the term "4k" for the resolution comes from the 4k pixels horizontally. The digital big screen film formats have been classified into "2k" and "4k" categories because of their horizontal numbers of pixels for some 10 years or so now. The 1080p HDTV format is slightly below the 2k big screen resolutions. But in television, the people are counting lines, not columns, probably because it was hard to get additional scanlines back when the analogue TV standards were developed. Thus the confusion.
You can do all of the compositing and some of the vector rendering in OpenGL, too. Take the new OpenGL cairo backend as an example. And if there's something you can't do directly in OpenGL, you can still upload a texture and do a final compositing pass on that including the video texture. I think Flash even does some of that in the OpenGL accellerated rendering they have. So yes, maybe Adobe is bitching a bit too much here.
nVidia is still far from becoming unimportant, even with them having basically botched their new generation of chips. Besides the obviously huge game market, there is a maket for business and research applications that rely on GPGPU power. And this is a market that is flat-out dominated by CUDA. My guess is that a lot of desktop workstations are bought with nVidia cards because of the sheer possibility to run GPU accelerated code, no matter if it (a) ever implemented and (b) actually implemented in CUDA. I'm extrapolating from my work environment here.
I don't know if nVidia has the money to make a solid comeback with a (massivly) revised/improved Fermi chip that they will desperately need to jump ahead of AMD once more. Even if not, they won't just vanish from the face of the earth. At worst, they have made themselves only second to AMD and still way ahead of Intel when considering product capabilities. Intel caters to a mass market of business machines with low end 3D requirements, which is a high volume market with much simpler and cheaper chips, leaving plenty of room for higher graphics performance.
I remember having read the pages that you link to a long time ago. Tone mapping issues are very real and noticable on rendered images - but in subtle way. The lighting just tends to look wrong, as you showed so nicely. I'm trying to get it right in my software, but it's not so trivial. Even if you know you handle it correctly internally, you have to be sure to handle input and output correctly as well. And it's very easy to make a mistake there.
Still, I'm quite surprised that software like Photoshop that ought to be awfully aware of color spaces does not convert to/from linear automatically. This would be the right thing to do in my opinion. Or does this "loophole" leave some sort of artist control that I'm not aware of?
My interpretation is simply that they want to reach the density and temperature required to start fusion within the plasma. This only means that the fusion reaction is starting to happen. Only after that can one start to ask the interesting questions (can enough energy be extracted to have a net surplus? can the energy output be improved? is this economically viable?). So they aren't done for several years yet.
It hasn't been entirely spotless. There were some major technical difficulties during reentry a while ago (in 2008 or so). I don't remember any details and don't have time to look up sources, though.
All I remember is that the capsule is designed to be separated into 3 parts in early reentry with only the middle part (the crew cabin) actually returning. There was a problem with a revised design of the explosive bolts that separated the upper part causing a less than smooth separation which ended up rotating the craft. And I think this happened on two occasions and could have been fatal to the crew.
The URL appending when cutting and pasting is easily defeated by pasting using the middle mouse button. That script still sends selection information, though. Can anybody tell me what this data is collected for? I don't see any value in it.
What I see in this video is "just" a state of the art game engine renderer. The current generation of games only expoits a subset of the features of current generation hardware. Were it not for the strict realtime requirements that are present in games, which push the available CPU time for rendering in the range of 3 to 6ms for 60FPS (the rest of the time is taken up by other parts of the game), the visuals could be immensely more impressive. And none of that is something that can be done in DirectX exclusively.
Hardware tesselation is demoed in the video you mentioned, but this is only available on highest end ATI hardware at the moment and AMD published extension specifications for that as early as March 2009 (see for example http://www.opengl.org/registry/specs/AMD/vertex_shader_tessellator.txt)! When did Windows 7 hit the market? October?
Although I can see your point you should not forget that gaming is a huge market with a volume in the billions of dollars. I highly doublt that the market for CAD type software is even half as big. Any manufacturer caring solely for the later would be concentrating on a niche market only, which does not make any sense economically.
You are missing much, much more important points here:
1. There is an SDK with literally hundreds of really, *really* cool top-notch high-end/highest-end demos for DirectX. Some of these come straight out of Microsoft Research. Nothing says "Use me! I'm cool!" like that set of demos. The closest thing on the OpenGL side of things that I know of is the demo gallery that nVidia has, but it's not as cool IMO.
2. There are debugging tools like PIX available for free. This thing has its restrictions, but seeing my colleagues analyzing textures, vertex buffers and draw calls graphically to figure out what they're doing wrong sometimes makes me envy them. And it turns out to be a real time saver. On the OpenGL side I find myself writing lots of this stuff from scratch just for my app. Sure, there are tools like bugle, but they are far inferior to what MS has to offer.
Having said that, I still feel more comfortable with OpenGL on Linux. This is what I'm used to and it works for me - not that this will ever make a difference, though.
As part of my work, I do some very advanced things in OpenGL and I have yet to find a hardware feature that is available in DirectX, but not OpenGL. Can you please point me to a particular feature that is missing in OpenGL?