I wasn't aware that the Tamil Tigers had attacked the United States, or the IRA, or Aum Shinrikyo, Nazis, et cetera. The homegrown groups you list haven't ever been linked to air travel disasters as far as I know either.
You should slow down on calling him a racist, the person is problem just careless in their thinking and wording.
I mean, the hierarchical menu based upon any series of choices is totally obvious. The only thing valuable about it is that it is *proven* through the popularity of the iPod to be a good choice amongst the millions of ways you *could* have done it.
It's almost like they're patenting the success of something obvious, if it wasn't successful, there'd be no lawsuit and people would say "that's a dumb patent, OBVIOUSLY you should be able to select artist, then album, then song..."
I don't understand what you are referring to. Who was talking about the sleep[sic] call? The driver, in the case of DX9 versus DX10 has quite a bit to do with the driver actually. You should understand that pre-DX10, DirectX operating under the assumption that when DirectX Graphics (formerly Direct3D) was being used, it was most likely being used as a game or for a very demanding application; ergo, the idea of resource sharing, management of pooling, video memory usage, et cetera, were not nearly as important as they are going to be in Vista where each desktop window may be run by a multi-head card, multiple cards, or multiple multi-head cards. Saying this is skimming over a huge area of architectural concerns, but fundamentally DX10 and DX9 have different architectural goals in order to achieve their API goals. The re-factoring of DX10 was possible because the DirectX team was allowed to break away from the WDDM model.
The problem is the driver model for DX10 does not work well for the XP WDDM. I assure you they, and all the game publishers, wanted 10 to be available for as many Windows versions as possible. The break with the driver model was fundamental to several things but especially multi-head/multi-device hardware acceleration, changes to the cooperative nature of the 2D and 3D aspects of the video cards (both for fundamental re-factoring of the nature of DirectX Graphics and for the needs of advanced rendering systems like the Vista UI layer.) There's a bunch of great things about DX10 that could have been put into XP but there are other, more fundamental, architectural moves which have great performance benefits and future design benefits going forward.
Personally, I can't wait to see how well displacement mapping will make real-time terrain generation vastly simpler and adaptive to level of detail (doing this now is a fair amount of work.)
X-rays are a form of radiation, but I was under the impression that her direct experimentation (not sure at what stage) with radiological materials was the most likely cause of her untimely death.
...funny how when he talks about things they're always absolutes. This is crap, that is crap, this is good, that is crap. LOL. He sure loves the sound of his own typing... What's he really done worth making him the oracle he seems to think he is.
Yeah, all the other video services are flawed, there are no flaws in youtube...
I had RealiZm and Wildcat boards that did this but it was multi-head not multi-device and only two monitors. It was one 'pseudo desktop' and one context.
This and the ridiculous nature of the extension mechanism are the only two things I have against OGL. I prefer its C-like usage because I like to introduce my own OO based abstractions without having to contend with the inherent structural rigidities of the D3D approach (this is purely subjective though.)
On Windows 2000 drivers it was because you could not have more than one hardware accelerated OpenGL context although you could have more than one context. It was sort of like "Yeah, you can have two ferraris, but one of them doesn't have an engine in it..."
There was an nVidia driver hack that existed for a while where you could have two identical cards in a system and they could 'share' an OpenGL context intelligently (I use that term very loosely here) and thereby give you hardware acceleration. This was when the ARB was supposedly reviewing a multi-device/head acceleration addition. Sadly they left it to the card vendors who, of course, spend 99% of their time on worrying about games and single monitor applications.
You can do some forms of multi-monitor on OpenGL, I didn't say you could not. I do it on my Ubuntu and SUSE systems. What you cannot do is multi-device with hardware accleration. Something necessary for many professional 3D products. As an example, I recently re-wrote an OpenGL client application that renders geographic locations in 3D in order to monitor real-time events from the 'engine side' of things.
It was re-written for two reasons, first because you couldn't currently have more than one geographic location behing shown at a particular time or even two views on the same location. This I could have kept using OpenGL for (which would have been nice.) The second reason was because our customers spend six figures or more (rarely 7 figures) on our enterprise system and as a result they end up with these hideously expensive client machines with ridiculous monitor configurations. I.e., 4 monitors connected to two PCIe cards not running in SLI/Crossfire mode. They want to be able to drag the client anywhere and not worry about whether or not the display freezes, or becomes unusable. My biggest gripe about OpenGL is that I cannot do multi-device HW Acceleration. I have written the ARB about it for the past 4 years. Ever since it was introduced in, iirc, DX7, I have wanted to see it in OpenGL. There are lots of reasons why it hasn't happened, and none of them have to do with Microsoft, but that's another story. Basically, "Applications which need features like that tend to be run on SGI which already has a mechanism for this" was what I got back early on. So, here I am needing to use DX9. Not a big deal because I know both APIs well, and don't really care subjectively about one over the other. OpenGL is more nostalgic for me, but DX9 is easy to use (unlike DX3, how I don't miss execute buffers) as well.
Now, for a short while, there was a driver hack for nVidia cards where you could have two nVidia cards of the EXACT same type in your machine and set this little driver level switch and the two cards could share the OpenGL context (thereby getting you multi-device acceleration) but this went away, iirc, a few years ago. I looked for it before re-writing our display client hoping that I could do less work, but to no avail.
I probably came off in the earlier article as anti-OpenGL but I'm not. I'm anti-FUD whether that's some idiot bashing *nix/nux, or some idiot bashing D3D or OpenGL.
Oh, wait, now it's "retail XP", would that be XP Pro or another version of XP. Is that first edition XP or any of the versions that shipped up to XP Pro SP2? Would that be for ATI or for an nVidia based hardware?
"I could care less about the pirated XP Home disk your Packard Bell came with..." LOL.
(1)Ironically, you yourself appear to "not know a whole lot." There are several reasons that developers use D3D over OpenGL. Personally, if I need cross platform, for example Sense8's WorldToolKit back when I used to work there, I used OpenGL. If I need multi-monitor and/or multi-device hardware acceleration on anything other than an upper end SGI, like what I currently work on, I HAVE to use DirectX9/10 and Win32. There are other reasons to prefer D3D over OpenGL but they are somewhat subjective (i.e. some people absolutely detest the extensions mechanism in OpenGL for example while others don't really care.) Some people like to write simpler code to support multiple rendering paths, et cetera. There are subjective reasons to use OpenGL as well, but this is unimportant, what is important is pointing out that "If given a choice no developer would ever use Direct3d for anything" is a ridiculous and biased statement. Also, if your hardware doesn't support OpenGL 2.0, and your application uses OpenGL 2.0, your application isn't going to run either, so the statements:
"Also DirectX/Direct3d is tied directly to the hardware. If your card doesn't support DirectX 9 your not going to be able to run DirectX 9 application. For OpenGL it doesn't work that way. It's a programming API that can be accelerated. If you have a card that was designed to accelerate OpenGL 1.x you can still run OpenGL 2.x. It just won't all be hardware accelerated."
This is VERY misleading. Presuming scenario 1 where the developer (for either D3D or OpenGL) has coded a support for only a particular version of the API, neither API will run partially in software if the driver does not support that level of the API. D3D9 will not run in software unless you're going to use a debugging rasterizer (highly unlikely), and OpenGL 2.0 WILL NOT RUN on a card with a 1.0, 1.1, 1.2, 1.4 driver. Now, there are some 1.4 drivers which were written so that people like myself could write 2.0 code and execute before the hardware was available, in which case the 2.0 distinctions were supported via software emulation, but this was for developers. You're confusing the ability of a specific OpenGL implementation supporting a specification to the maximum of its ability. For example, if a I have an OpenGL 1.4 driver but the card I'm running on doesn't have Hardware T&L, OpenGL's pipeline is quite capable of transparently deciding whether or not it should offload the lighting to the card or doing it in software. This is not the same as some future version of OpenGL running on my old OpenGL card with an old driver.
"If your programming a 3d application and it's not a game and your not Microsoft.. Then your using OpenGL or OpenGL-based system. Period, end of story" - I certainly hope you're not in a decision making capacity at your job (or that your job is doing something other than writing rendering code) because you're screwing your company over. Right tool for the right job, every time. It's a toolbox not a religious jihad.
(2)"OpenGL has a much more formal review system then DirectX/3D has" - No it doesn't. Crimony. Do you know what the specification process for DirectX is? You can say they're different, but it certainly isn't less "formal." You could say it is less open, but that's because it isn't an open API.
I'm sorry but the OpenGL model on Windows is an ICD. The default Windows XP for my system shipped with a WHQL nVidia driver (my machine had an nVidia card) that installed and I had OpenGL via the ICD immediately. I didn't have to go anywhere and download anything. This was an install right off the Microsoft CD. Microsoft provides a spec for D3D9 (for example) and hardware vendors implement that themselves, NOT Microsoft. Microsoft does NOT provide the spec for OpenGL, and hardware vendors implement that themselves, NOT Microsoft.
There's enough wrong with Microsoft to avoid FUD like that.
Polyheme's advantage over regular blood is that is does not require blood type matching. It requires blood to manufacture it. Interesting but not quite as interesting as being able to expand your own blood you carry around in a Nescafe 'instant AB-' jar;).
...the course of a *different* route than if the ship is entirely under power; ergo, use the sails and you need to chart a different, likely less direct, course for the ship. I wonder what the average increase in distance for a route is?
Likely this will still have value even if just used when the wind is positioned conveniently. Certain legs of round trips are certainly likely to benefit greatly from sail power.
Very cool. I'd certainly love to see that out on the ocean.
One nice thing about Mozilla is that you can easily disseminate who is or is not vulnerable based upon a simple to understand version number. Not so with IE.
"Incorrect about identical radar and IR sigs... this I cannot elaborate on (I admit this is convienient but it is also true)." - It is indeed VERY convenient especially given that information regarding Soviet plans for loading warhead buses with inert warheads is not exactly secret. This is also why the radar and IR signatures ARE identical. Perhaps you're confused about something a less technically competent country such as China or India would use, ergo your reference to 'balloons' and other stupid obfuscation plans.
"Spend the money on a booster and RV that looks like a real RV... then you may as well put a warhed in it. Simple economics. If such an target is detected them it must be considered a threat." - Ridiculous. Late Soviet SLBM missile technology programs, i.e. post SS-N-25 (cancelled by the way) systems, utilized refabricated fissile material taken from older class systems typically deployed on Delta class submarines. The Delta's were not disarmed, nor were they decommissioned, this led to a DOD report (which you may be able to find) speculating that the Soviet Union was retrofitting the buses with inert warheads. This very same DOD report speculated that several SLBM tests in the mid 90's were specifically for the purpose of evaluating the 'worthiness' of decoying given that the systems in question had been tested and approved previously and generated the identical telemetry to test observers.
"Additionally decoys are unguided" - Uh, you do realize that valid MIRVs are also unguided? LOL.
"Also... they TUMBLE" No, they don't, ignoring the fact that you earlier declared these items to be 'balloons', I wonder as to why you suddenly believe that balloons 'tumble'?
"and I work on the Navy's Aegis BMD program" - Interestingly enough, I spent 16 months writing code to simulate SLBMs for a not to be mentioned party; however, I can mention that this took place at the NASA Ames Research center in the late 90's. BTW, the Aegis BMD program is not intended to deal with ICBMs, ergo, perhaps you were referring to short or medium ranged ballistic threats, ergo the differences in what we're talking about.
Slashdot Mirror
I wasn't aware that the Tamil Tigers had attacked the United States, or the IRA, or Aum Shinrikyo, Nazis, et cetera. The homegrown groups you list haven't ever been linked to air travel disasters as far as I know either.
You should slow down on calling him a racist, the person is problem just careless in their thinking and wording.
I mean, the hierarchical menu based upon any series of choices is totally obvious. The only thing valuable about it is that it is *proven* through the popularity of the iPod to be a good choice amongst the millions of ways you *could* have done it.
It's almost like they're patenting the success of something obvious, if it wasn't successful, there'd be no lawsuit and people would say "that's a dumb patent, OBVIOUSLY you should be able to select artist, then album, then song..."
I don't understand what you are referring to. Who was talking about the sleep[sic] call?
The driver, in the case of DX9 versus DX10 has quite a bit to do with the driver actually. You should understand that pre-DX10, DirectX operating under the assumption that when DirectX Graphics (formerly Direct3D) was being used, it was most likely being used as a game or for a very demanding application; ergo, the idea of resource sharing, management of pooling, video memory usage, et cetera, were not nearly as important as they are going to be in Vista where each desktop window may be run by a multi-head card, multiple cards, or multiple multi-head cards. Saying this is skimming over a huge area of architectural concerns, but fundamentally DX10 and DX9 have different architectural goals in order to achieve their API goals. The re-factoring of DX10 was possible because the DirectX team was allowed to break away from the WDDM model.
The problem is the driver model for DX10 does not work well for the XP WDDM. I assure you they, and all the game publishers, wanted 10 to be available for as many Windows versions as possible. The break with the driver model was fundamental to several things but especially multi-head/multi-device hardware acceleration, changes to the cooperative nature of the 2D and 3D aspects of the video cards (both for fundamental re-factoring of the nature of DirectX Graphics and for the needs of advanced rendering systems like the Vista UI layer.) There's a bunch of great things about DX10 that could have been put into XP but there are other, more fundamental, architectural moves which have great performance benefits and future design benefits going forward.
Personally, I can't wait to see how well displacement mapping will make real-time terrain generation vastly simpler and adaptive to level of detail (doing this now is a fair amount of work.)
X-rays are a form of radiation, but I was under the impression that her direct experimentation (not sure at what stage) with radiological materials was the most likely cause of her untimely death.
...in certain bands aggregates as totally random. Use that. You know how Madam Curie died, don't you? ;)
...funny how when he talks about things they're always absolutes. This is crap, that is crap, this is good, that is crap. LOL. He sure loves the sound of his own typing... What's he really done worth making him the oracle he seems to think he is.
Yeah, all the other video services are flawed, there are no flaws in youtube...
Did you even read my reply? LOL...
I had RealiZm and Wildcat boards that did this but it was multi-head not multi-device and only two monitors. It was one 'pseudo desktop' and one context.
This and the ridiculous nature of the extension mechanism are the only two things I have against OGL. I prefer its C-like usage because I like to introduce my own OO based abstractions without having to contend with the inherent structural rigidities of the D3D approach (this is purely subjective though.)
The ARB was just sooooooo damn slow...
On Windows 2000 drivers it was because you could not have more than one hardware accelerated OpenGL context although you could have more than one context. It was sort of like "Yeah, you can have two ferraris, but one of them doesn't have an engine in it..."
There was an nVidia driver hack that existed for a while where you could have two identical cards in a system and they could 'share' an OpenGL context intelligently (I use that term very loosely here) and thereby give you hardware acceleration. This was when the ARB was supposedly reviewing a multi-device/head acceleration addition. Sadly they left it to the card vendors who, of course, spend 99% of their time on worrying about games and single monitor applications.
You can do some forms of multi-monitor on OpenGL, I didn't say you could not. I do it on my Ubuntu and SUSE systems. What you cannot do is multi-device with hardware accleration. Something necessary for many professional 3D products. As an example, I recently re-wrote an OpenGL client application that renders geographic locations in 3D in order to monitor real-time events from the 'engine side' of things.
It was re-written for two reasons, first because you couldn't currently have more than one geographic location behing shown at a particular time or even two views on the same location. This I could have kept using OpenGL for (which would have been nice.) The second reason was because our customers spend six figures or more (rarely 7 figures) on our enterprise system and as a result they end up with these hideously expensive client machines with ridiculous monitor configurations. I.e., 4 monitors connected to two PCIe cards not running in SLI/Crossfire mode. They want to be able to drag the client anywhere and not worry about whether or not the display freezes, or becomes unusable. My biggest gripe about OpenGL is that I cannot do multi-device HW Acceleration. I have written the ARB about it for the past 4 years. Ever since it was introduced in, iirc, DX7, I have wanted to see it in OpenGL. There are lots of reasons why it hasn't happened, and none of them have to do with Microsoft, but that's another story. Basically, "Applications which need features like that tend to be run on SGI which already has a mechanism for this" was what I got back early on. So, here I am needing to use DX9. Not a big deal because I know both APIs well, and don't really care subjectively about one over the other. OpenGL is more nostalgic for me, but DX9 is easy to use (unlike DX3, how I don't miss execute buffers) as well.
Now, for a short while, there was a driver hack for nVidia cards where you could have two nVidia cards of the EXACT same type in your machine and set this little driver level switch and the two cards could share the OpenGL context (thereby getting you multi-device acceleration) but this went away, iirc, a few years ago. I looked for it before re-writing our display client hoping that I could do less work, but to no avail.
I probably came off in the earlier article as anti-OpenGL but I'm not. I'm anti-FUD whether that's some idiot bashing *nix/nux, or some idiot bashing D3D or OpenGL.
Oh, wait, now it's "retail XP", would that be XP Pro or another version of XP. Is that first edition XP or any of the versions that shipped up to XP Pro SP2? Would that be for ATI or for an nVidia based hardware?
"I could care less about the pirated XP Home disk your Packard Bell came with..." LOL.
(1)Ironically, you yourself appear to "not know a whole lot." There are several reasons that developers use D3D over OpenGL. Personally, if I need cross platform, for example Sense8's WorldToolKit back when I used to work there, I used OpenGL. If I need multi-monitor and/or multi-device hardware acceleration on anything other than an upper end SGI, like what I currently work on, I HAVE to use DirectX9/10 and Win32. There are other reasons to prefer D3D over OpenGL but they are somewhat subjective (i.e. some people absolutely detest the extensions mechanism in OpenGL for example while others don't really care.) Some people like to write simpler code to support multiple rendering paths, et cetera. There are subjective reasons to use OpenGL as well, but this is unimportant, what is important is pointing out that "If given a choice no developer would ever use Direct3d for anything" is a ridiculous and biased statement. Also, if your hardware doesn't support OpenGL 2.0, and your application uses OpenGL 2.0, your application isn't going to run either, so the statements:
"Also DirectX/Direct3d is tied directly to the hardware. If your card doesn't support DirectX 9 your not going to be able to run DirectX 9 application. For OpenGL it doesn't work that way. It's a programming API that can be accelerated. If you have a card that was designed to accelerate OpenGL 1.x you can still run OpenGL 2.x. It just won't all be hardware accelerated."
This is VERY misleading. Presuming scenario 1 where the developer (for either D3D or OpenGL) has coded a support for only a particular version of the API, neither API will run partially in software if the driver does not support that level of the API. D3D9 will not run in software unless you're going to use a debugging rasterizer (highly unlikely), and OpenGL 2.0 WILL NOT RUN on a card with a 1.0, 1.1, 1.2, 1.4 driver. Now, there are some 1.4 drivers which were written so that people like myself could write 2.0 code and execute before the hardware was available, in which case the 2.0 distinctions were supported via software emulation, but this was for developers. You're confusing the ability of a specific OpenGL implementation supporting a specification to the maximum of its ability. For example, if a I have an OpenGL 1.4 driver but the card I'm running on doesn't have Hardware T&L, OpenGL's pipeline is quite capable of transparently deciding whether or not it should offload the lighting to the card or doing it in software. This is not the same as some future version of OpenGL running on my old OpenGL card with an old driver.
"If your programming a 3d application and it's not a game and your not Microsoft.. Then your using OpenGL or OpenGL-based system. Period, end of story" - I certainly hope you're not in a decision making capacity at your job (or that your job is doing something other than writing rendering code) because you're screwing your company over. Right tool for the right job, every time. It's a toolbox not a religious jihad.
(2)"OpenGL has a much more formal review system then DirectX/3D has" - No it doesn't. Crimony. Do you know what the specification process for DirectX is? You can say they're different, but it certainly isn't less "formal." You could say it is less open, but that's because it isn't an open API.
I'm sorry but the OpenGL model on Windows is an ICD. The default Windows XP for my system shipped with a WHQL nVidia driver (my machine had an nVidia card) that installed and I had OpenGL via the ICD immediately. I didn't have to go anywhere and download anything. This was an install right off the Microsoft CD. Microsoft provides a spec for D3D9 (for example) and hardware vendors implement that themselves, NOT Microsoft. Microsoft does NOT provide the spec for OpenGL, and hardware vendors implement that themselves, NOT Microsoft.
There's enough wrong with Microsoft to avoid FUD like that.
I'll take an 0+ half-caf vente sanguinae with a twist...
Polyheme's advantage over regular blood is that is does not require blood type matching. It requires blood to manufacture it. Interesting but not quite as interesting as being able to expand your own blood you carry around in a Nescafe 'instant AB-' jar ;).
...the course of a *different* route than if the ship is entirely under power; ergo, use the sails and you need to chart a different, likely less direct, course for the ship. I wonder what the average increase in distance for a route is?
Likely this will still have value even if just used when the wind is positioned conveniently. Certain legs of round trips are certainly likely to benefit greatly from sail power.
Very cool. I'd certainly love to see that out on the ocean.
It was up a loooong time ago with the same info about wiping library tags, reading a security manager's badge and gaining entry as a test, yadda ^ 3.
...Google floated their IPO?
...not.
The Gartner group are just a tad (to say the least) biased against Micro$oft.
They're not as patently biased as some of the companies used by M$ in older 'we are better than Linux for reason (n)' were, but they're not far off.
Stupid inter-web
Sorry but I disagree. ANY numbering scheme is better than discerning what is or isn't installed on your XP machine for IE or any other code point.
...surprisingly.
One nice thing about Mozilla is that you can easily disseminate who is or is not vulnerable based upon a simple to understand version number. Not so with IE.
"Incorrect about identical radar and IR sigs... this I cannot elaborate on (I admit this is convienient but it is also true)." - It is indeed VERY convenient especially given that information regarding Soviet plans for loading warhead buses with inert warheads is not exactly secret. This is also why the radar and IR signatures ARE identical. Perhaps you're confused about something a less technically competent country such as China or India would use, ergo your reference to 'balloons' and other stupid obfuscation plans.
"Spend the money on a booster and RV that looks like a real RV... then you may as well put a warhed in it. Simple economics. If such an target is detected them it must be considered a threat." - Ridiculous. Late Soviet SLBM missile technology programs, i.e. post SS-N-25 (cancelled by the way) systems, utilized refabricated fissile material taken from older class systems typically deployed on Delta class submarines. The Delta's were not disarmed, nor were they decommissioned, this led to a DOD report (which you may be able to find) speculating that the Soviet Union was retrofitting the buses with inert warheads. This very same DOD report speculated that several SLBM tests in the mid 90's were specifically for the purpose of evaluating the 'worthiness' of decoying given that the systems in question had been tested and approved previously and generated the identical telemetry to test observers.
"Additionally decoys are unguided" - Uh, you do realize that valid MIRVs are also unguided? LOL.
"Also... they TUMBLE" No, they don't, ignoring the fact that you earlier declared these items to be 'balloons', I wonder as to why you suddenly believe that balloons 'tumble'?
"and I work on the Navy's Aegis BMD program" - Interestingly enough, I spent 16 months writing code to simulate SLBMs for a not to be mentioned party; however, I can mention that this took place at the NASA Ames Research center in the late 90's. BTW, the Aegis BMD program is not intended to deal with ICBMs, ergo, perhaps you were referring to short or medium ranged ballistic threats, ergo the differences in what we're talking about.
...folders so that only your inbox is taking up corporate space.
;)
This solved the problem for us from a 'server' point of view. Now we just get users who say they're out of disk space.