Actually, you do. There's a reason WHY they call it DLL Hell- which still exists on Windows. The only OS I know of that doesn't have issues of this nature is MacOS X and above because of the rigid rules they apply to everything including their runtimes they ship.
The only real reason why you have any problems with Linux deliverables has little to do with the base ABI- which anyone with the right resources can target properly (All it takes is linkage against libraries of the version you want to base off of or use something like apbuild from the Autopackage project for that.). It's the C++ ABI that keeps shifting- and you CAN statically link against it if you don't wish to have issues with it. It's actually smaller than the main one and it's tolerable to statically link it and nothing else.
And I KNOW that the thread didn't discuss this at all.
If you'd read the thread and the similarity to Sage_Svartalf (Bioware's forum software borked up the original handle I had for some bizarre reason and rather than bothering them with it, I modified the original and it stuck the second time...) and this handle, you might realize that I was one of the participants thereof and, to quote myself...
I think Atari's quite surprised and dismayed at the response- they pulled the sticky from the thread, but they don't quite have the guts to lock it. Bad PR if they did that; but they keep hoping the thread will just drop from the view- and it just won't. It keeps getting bumped by more and more people coming in to request the game on Linux. And it's not just people putting a bump post on the thread- it's new registrants putting in their voice. To apparently no avail- no acknowlegement, nothing... Just goes to show what I commented on the thread- someone keeps thinking that "petitions" will get their attention, to whit I replied, what do you think thousands of posts asking for it, spanning over a year and a half, the largest thread and longest running thread on their forums is? They think that a petition is going to be "different". Heh... Go for it, I told 'em- it's not going to make any difference. Thread... Petition...
Which was in response to someone bringing up the thread in the context of probable demand for DA, based on the Atari NWN2 thread.
And to quote myself again later in the thread...
And as for the thread dying- it's not my posts that are doing it. It's that few KNEW about it- and it could also be that people watched the saga of the NWN2 thread play out. Why bother posting "I want this game" when it's pretty obvious to everyone with the Atari thread that just won't die that nobody's willing to take anybody from the Linux community seriously? This is not to say that I feel this way or that this is the cause- but it's a likely culprit.
To which the guy that I was replying to responded when more posts came in that he "sat corrected on that score".
No real discussion of NWN2 being ported- just that there was a probable real demand based on the NWN2 discussion thread and that while it was there, it wasn't a foregone conclusion that Bioware was going to look at any of the figures they're seeing for Linux on their own- just the IDC type figures, etc. This is not to say they're disregarding the Linux/MacOS communities- it's just there's nothing but silence on their parts and now they closed the thread at 10 pages, no further discussion allowed on the subject ever. The tag from Slashdot didn't imply anything else, mind.
It didn't have anything to do with NWN2 getting ported or anything like that.
The game itself is not. The content, storyline, etc. is owned by Neverax and Ryzom itself would have to be "bought" from them to GPL or Creative Commons license it unless the receivers from the bankruptcy allow it (Which is usually unlikely...)
Either it's Splenda, Saccharin, or not at all...things like Xylitol, Malitol, etc., while they're naturally occurring sugar alcohols and sweeten nicely, they have a nasty side effect of causing laxative effects past a certain level of consumption. So, they don't use it as a sweetener at restaurants, in sodas, etc. The only places I've seen these useful sweeteners is in gums and candies- and not all that often (Seems Aspartame's VERY popular compared to the alternatives, even though it doesn't taste as good because it's cheap compared to the allowed alternatives and keeps forever as long as you keep it cool before using it.).
You can't patent a plant, so the FDA won't do what needs to be done for Stevia, which as far as I can tell works just fine and is as sweet as Splenda happens to be- but as you put it, the big pharma companies (who gave us saccharin (which was just fine...the studies were so screwed up that it was hillarious...), Aspartame, Acesulfame, and now Sucralose...) don't want it because they can't gouge for the Patent royalties for the stuff. Sounds paranoid, I know- but go reading between the lines and it isn't so paranoid.
What they don't tell you about Sucralose is that it's chemical formula means that it's not really derived from sucrose completely like they tell you it is- not to mention truly chlorinated sugar is more a pesticide and is rather toxic to humans. It MIGHT be safer than Aspartame, it might not be- but for me, I'm stuck between a rock and a hard place because of all the stupidity.
That's more of the function of the driver not working correctly...supposedly the driver supported the extension or you'd not have gotten very far calling against it. Sounds like more of an ATI driver gripe than anything else- did you log the bug with them?
They do it on a daily basis. They've got a good solid handle on it right now and it's about to be improved even further in a couple of months as I finish the touches on a possible new build environment for them.
Given that I know QUITE a bit on the subject (Heh... I port games over to Linux and right now I'm off that for a little bit doing driver development consulting for one of the two aforementioned players in 3D...), I think I should comment.
Most of the extensions aren't ATI or NVidia specific that are usable. To be sure, they offer those, but most of the extensions are ARB or EXT extensions- they're intended to be used by either player and are typically provided by the same. The reality is that OpenGL 2.1 and DX9/10 are intrinsically identical except for programming style.
Besides, you should abstract out your engine components if you've any aspirations to target the next gen consoles- DX10's NOT on PS3 or Wii, but OpenGL ES 2.0 IS and it's a clean, easy to use subset that ports back to MacOS and Linux.
1) Type I Diabetes patients have equally nasty problems (I know of at least two Type I patients...)- some of which are the same as the Type II patients.
2) Fixing this one would be amazing- it was thought that generally Type I was treatable only with Insulin injections. To be "cured" would be amazing for them.
3) Some of the meds for Type II Diabetes can QUICKLY and VIOLENTLY turn you into a Type I Diabetic if you get exposed to certain other substances. The Avandia type meds and Glyburide type meds that affect utilization and production of Insulin can torch off what's left of the Islet cells in the Pancreas with exposure to things like...oh...alcohol...contrast dyes...handful of other things... When I was taking Avandia and when I was still taking Glyburide I had a list of things that were JUST NOT A VERY GOOD IDEA FOR ME TO TAKE/DO.
4) They have a metabolic switch that they've discovered that turns OFF Type II Diabetes like a light-switch; but you have to take the med for the rest of your life and they're being VERY cautious moving forward with it because it's a genetic based therapy like the Immune System Booster that they screwed up the lives of those poor bastards in the UK earlier this year.
If you've not figured it out by now, I'm a Type II Diabetic. So what if it doesn't help me? It's a fix for the other people out there that don't have the same set of problems I do, but still have serious issues with Sugar- this could free them from every bit of the issues with Insulin shots and needing to manage or avoid sugars. Not everything sugar free is good for you or a diabetic, contrary to the popular belief otherwise- and not everything uses Splenda (nor is it a certainty that it's any better than Nutrasweet, safety-wise...). To not have to worry much ever again... Wow...
In the case of Copyright or Patent, you're not obligated to enforce or completely lose the rights like in Trademark's case.
It WILL, however leave it open for a defense of laches (delay) against which you can reasonably ask for damages and they can say that they don't owe them to you- but you can demand them to stop infringing at any time unless you give the impression that you chose to not enforce against a class of individuals. At that point, while they can still be drug into court and all, they have a positive defense against litigation (may/may not work, mind) that can give them an out all the way around.
You'll note that most businesses won't go the Patent Covenant/Licensing to FOSS projects route without care in what they're doing for that very reason.
Oh, and to the people that say it's all about how many Patents... There is a lot to that- but the right Patent in the right place and right time can be just as problematic to another company and weigh in as if it were the whole of a Patent pool like OIN or IBM have in hand. Just ask Microsoft about that one- they've been burned several times in the last handful of years and their patent pool didn't defend them at all- and this is when they HAD a substantive pool at their disposal.
BSD Won it's COPYRIGHT battles for the ORIGINAL code core. If it infringes on any current Patents or if any of the new code infringes, it will face those battles AGAIN.
Don't need one. He's using an enhanced design of the Farnsworth Fusor, a device that while it doesn't CURRENTLY produce more energy out than in, DOES produce honest to God fusion reactions with a solid neutron flux. Major manufacturers are building the things as reliable, pretty much instant on, instant off, reliable neutron sources for other things. The fact that a kid actually BUILT one out of simple parts is the interesting thing.
However, I don't advocate just ANYONE building these things- the Fusor can produce deadly neutron fluxes readily and with the flip of a switch and a supplying of the Deuterium fuel.
If that were the case, why is NWN2 so inferior to the predecessor in overall performance. Sure it looks nice, but it's framerate sucks compared to the older game. It's all been converted over to DirectX... Heh... You know little of what you speak of- programmer productivity is only one piece and it's debateable that DirectX brings any of that.
Most people associate these with their fixed functionality paths and the coding for the same.
That'd be right for the older games or the older hardware.
It'd not be right for the new hardware or the new games...
The new GPUs use programmable vertex and fragment shaders and the fixed functionality paths go through an emulation of those paths in GLSL or HLSL. There's not much left that isn't merely a simplified computer like a DSP is for signal processing- this is merely one that is designed for graphics and similar operations instead.
The new games use their own shaders, etc. which is why GLSL is such a big deal and a tool to migrate HLSL over is as much of one.
Who can say for certain that this doesn't make sense? I'm not going to venture a yes or no- because I can see where they could pull it clean off and I can see some where it could let them fall flat on their face.
And, how many times does it need to be said that there's alternatives to each piece. In fact, the big studios don't use much of ANY of DirectX' stuff directly- because they're anticipating a port to a console. So they use Miles, FMOD, or OpenAL for sound. They typically have rolled their own network stack code, but now, there's TNL, RakNet, and Grapple (It's not portable yet, but that's on my plate, so it's soon...). There's little reason to be even USING their DirectX APIs because they LIMIT you (And in some cases, MS has deprecated them- DirectPlay, the network layer, for example...)- and in many cases, things like Miles works MUCH better than the DirectFoo equivalent and plugs into the same low-level hooks in the OS.
Unless you're targeting X-Box, there's little need for using DirectX. If you plan on targeting X-Box, you're better off making a rendering abstraction layer that insulates the game from the choice of either, picking other things for sound like Miles or OpenAL, and then grabbing a license for TNL/RakNet or rolling your own or grabbing Grapple and finishing the minimal work to make it run under Windows.
For anyone that thinks Cedega's (or WINE, for that matter...) anything other than a good short-term solution to Linux gaming, all I need do is point them to this as a good example of why it's not so hot of an idea. And it's perfectly within Blizzard's rights to do this action- to the point of ignoring any contact with regards to this whole affair. Doesn't make it good for PR or customer relations, mind- but it's completely within their rights to do so. After all, they only support Windows on this title and don't have plans to provide support to other OS platforms. Again, which is their right.
Native ports wouldn't have as many of these issues.
As for the whole affair... It's Blizzard. They've apparently got a singular attitude about Linux users that started with the period around Starcraft forward. I wouldn't buy any title from them right now and for some while to come- you just don't treat customers or potential customers the way they seem wont to do.
Uh, it's not radioactive isotopes, it's ionizing radiation.
Isotopes go away. Pull the ionizing radiation away and the radiation goes too. Neutron flux is a different story, but in that case, you're altering the atomic structure and causing isotopes to form...
Most coal power plants are primary plants (meaning you're getting at least a fraction of the juice on the grid from them...), running 24x7 because it takes a while to spin one of those up. Those massive tall stacks? They're scrubbers as much as anything else. Yes, they dump pollutants, including CO2 into the air, but nothing like people make them out to. And, there's something else out there- several different processes patented in the late 1800's and early 1900's that cleanly convert coal into coke (clean burning coal solids...), further refineable fuel oil, and natural gas sufficient to maintain the process continuously.
Coal's a good stopgap if we start running short of crude, as is several other sources and processes. To be sure, we need to migrate to something else moving forward- but to what?
TDP'd waste? It's possible to do so, but it's still not there yet- not refined enough. BioDiesel? It's here, it's here now, but not everything is able to run off of B100 or lower- not everything's a Diesel. Wind/Solar? Heh... Sorta usable. Sorta not. And it's a purely electric play. We don't have good enough storage tech to make it apply to vehicles- and what about jets, etc.? Nuclear? Not yet. Had we gotten a little better at that and did a bunch more plants, perhaps- but unless someone goes and develops a usable Migma Fission reactor or a solid state or plasma fusion reaction it's not going to happen yet.
In reality, we have to do something. Coal's a good step as is Biodiesel. TDP can come up as long as people aren't being stupid about it (like the trial plant... it's going to smell off from time to time- it's a type of rendering technology...sheesh... Move the plant away from everything if it's a problem.)- that handles electricity and mobile tech for the short term. Then we can get to improving the other alternatives ASAP. With TDP and Biodiesel, the carbon potential subsides- you're using carbon already in the cycle that hasn't really been sequestered yet like Oil and Coal are. With the others, we're still just a bit too far off yet to do anything with them.
A Geode GX is little more than a core clock-speed increased version of the MediaGX/Geode GXm, that was bought from NatSemi, who bought it from Cyrix when they sold the other half to VIA. It's a weak chip. it has a FSB of 33 MHz so that it could work with PC-66 memory without any L2 cache involvement to raise board or chip pricing. The whole design cripples it out of the gate. If it's a GX design, it stinks on ice except for a few usable embedded/kiosk designs and, yes, the thing stinks compared to your machine. It's biggest selling point was it consumed 1-2 Watts TDP at full speed and didn't need much fansink and could be completely passively cooled. The PIC used THIS CPU in it's design. This destined it to fail out of the gate. Just like every other design using this chip. It looks good on paper, the marketing speak talks a good talk, but when it comes to reality, the rubber meeting the pavement- the 33 MHz FSB dooms the device to mediocre performance every time. They shave pennies off the BOM with this idea, only to have a truly sub-optimal performer, when they could have used a LX or a NX (Or in the case of someone other than AMD, an Eden or C3/C7 design...)
A Geode LX is a reworked version of the chip design, which was slated to be called the Geode G2 by NatSemi, but they never really released it. AMD bought the design and took it to market. It's an improvement, with a 66MHz FSB, etc. It's still underpowered compared to a VIA C3 or a Geode NX, but a decent design. This, I believe, is the CPU choice for the OLPC laptop. It's not the greatest chip in the world, but it burns a little less watts than the VIA answers, so while it performs slower overall, it's cooler overall as well- meaning it needs less juice to operate with.
A Geode NX is a very low-power version of the AthlonXP core with all that entails. You can buy machines at Fry's on the bottom end of the price scale with these on an older style AthonXP motherboard right now- about $250 or so without a monitor.
In reality, C's behavior (and a lot of other languages, really) are governed by behaviors within the CPU hardware they were originally intended for. In the case of C, the machines in question only had one hardware stack, so they intermingled the subroutine return state with the parameters, etc. for speed's sake. Implementing a second stack in software would have been problematic because it would have added extra performance issues and ate into the register store (you want to probably reserve a register for the parameter pointer...). Since most of the Algol derived languages (C's in that bunch...) do this very thing, there's been no need, no desire to change the underlying machine that the language sees, nor has any of the X86 vendors had a reason to "fix" the problem of register store space.
While it's syntax is difficult to initially grasp (esp. if you've been doing Algol based languages...), Forth's machine model is one like you suggested. Obviously, on machines that it has the ability to execute operations against the contents of the artificial data stack or where it actually HAS two data stacks, the code excels in speed. Comparable to C or better than C without as many of the risks (though it WILL cut your throat in other ways- just not that one...). Otherwise, while it makes for very compact code, it does so at the expense of some performance on machines without such support. In those cases, it's best is just at C's peak performance on the same task and something like 10-20% slower otherwise. It's still around because it can fit a high-level programming solution into the smallest space in memory possible without overly sacrificing speed at the same time- obviously a good thing in an embedded system.
In the end, it's more about how careful you code things. Internally, when you know what's going to be passed in and can control things, it's probably "okay" to not check for potential buffer overruns. It's not okay otherwise. Because it's a major performance hit, I know why someone would be inclined to not do any checks or to overdo the avoidance of doing them- it doesn't make it right, but I understand the why behind it and the problem in question.
Fusebox is one place. Power meter's the other. I suspect that most PLC implementations for home have relied on the meter to handle the cross-over between phases, etc. If you've got two meters, I suspect you'd need a bridge of some type like the X10 booster bridge for homes to bridge them all without mixing the power from each feed.
In fact, I do. But relying on HomePlug to "protect you" much better than WiFi is a little bit of folly. No, you can't have the article's attack made on you. But as the parent poster has pointed out, you're not as protected as you think- someone can snoop in on your traffic if they've got their own home plug and can tap into either phase of the two-phase 220v circuit comng into your house. With clever enough hardware they wouldn't even need to do that- it emits enough RF-like signal...
Fixed wiring Ethernet is probably the most secure of the lot- HPNA and HomePlug suffer from people being able to tap in (in the case of HPNA, all someone has to do is splice into your demarc- there's no barriers other than distance that protect you from snooping/attack...). WiFi and other wireless tech...heh...
I'd say it was more of a majority of them were more than $300 in today's dollars. Of worthy note is that the Genesis ALMOST makes it into that club (~$306) and the PSX is bumped out of it by $48 in today's values...
Right now, Sony's making the NeoGeo play (In terms of the then dollars, it was about the same price and had a vast leg-up over the other consoles in terms of power and display capabilities, etc...)- and we all know how well that worked for SNK; while they stayed afloat, it was more due to the Arcade unit sales than the console ones...
Slashdot Mirror
Actually, you do. There's a reason WHY they call it DLL Hell- which still exists on Windows. The only
OS I know of that doesn't have issues of this nature is MacOS X and above because of the rigid rules they
apply to everything including their runtimes they ship.
The only real reason why you have any problems with Linux deliverables has little to do with the base ABI-
which anyone with the right resources can target properly (All it takes is linkage against libraries of the
version you want to base off of or use something like apbuild from the Autopackage project for that.). It's
the C++ ABI that keeps shifting- and you CAN statically link against it if you don't wish to have issues
with it. It's actually smaller than the main one and it's tolerable to statically link it and nothing else.
If you'd read the thread and the similarity to Sage_Svartalf (Bioware's forum software borked up the original handle I had for some bizarre reason and rather than bothering them with it, I modified the original and it stuck the second time...) and this handle, you might realize that I was one of the participants thereof and, to quote myself...
Which was in response to someone bringing up the thread in the context of probable demand for DA, based on the Atari NWN2 thread.
And to quote myself again later in the thread...
To which the guy that I was replying to responded when more posts came in that he "sat corrected on that score".
No real discussion of NWN2 being ported- just that there was a probable real demand based on the NWN2 discussion thread and that while it was there, it wasn't a foregone conclusion that Bioware was going to look at any of the figures they're seeing for Linux on their own- just the IDC type figures, etc. This is not to say they're disregarding the Linux/MacOS communities- it's just there's nothing but silence on their parts and now they closed the thread at 10 pages, no further discussion allowed on the subject ever. The tag from Slashdot didn't imply anything else, mind.
It didn't have anything to do with NWN2 getting ported or anything like that.
The game itself is not. The content, storyline, etc. is owned by Neverax and Ryzom itself
would have to be "bought" from them to GPL or Creative Commons license it unless the
receivers from the bankruptcy allow it (Which is usually unlikely...)
Either it's Splenda, Saccharin, or not at all...things like Xylitol, Malitol, etc., while they're naturally
occurring sugar alcohols and sweeten nicely, they have a nasty side effect of causing laxative effects past a
certain level of consumption. So, they don't use it as a sweetener at restaurants, in sodas, etc. The only
places I've seen these useful sweeteners is in gums and candies- and not all that often (Seems Aspartame's
VERY popular compared to the alternatives, even though it doesn't taste as good because it's cheap compared
to the allowed alternatives and keeps forever as long as you keep it cool before using it.).
You can't patent a plant, so the FDA won't do what needs to be done for Stevia, which as far as I can tell works
just fine and is as sweet as Splenda happens to be- but as you put it, the big pharma companies (who gave us
saccharin (which was just fine...the studies were so screwed up that it was hillarious...), Aspartame, Acesulfame,
and now Sucralose...) don't want it because they can't gouge for the Patent royalties for the stuff. Sounds
paranoid, I know- but go reading between the lines and it isn't so paranoid.
What they don't tell you about Sucralose is that it's chemical formula means that it's not really derived from
sucrose completely like they tell you it is- not to mention truly chlorinated sugar is more a pesticide and is
rather toxic to humans. It MIGHT be safer than Aspartame, it might not be- but for me, I'm stuck between a rock
and a hard place because of all the stupidity.
That's more of the function of the driver not working correctly...supposedly the driver supported
the extension or you'd not have gotten very far calling against it. Sounds like more of an ATI
driver gripe than anything else- did you log the bug with them?
It had everything to do with Dragon Age.
They do it on a daily basis. They've got a good solid handle on it right now and it's
about to be improved even further in a couple of months as I finish the touches on a
possible new build environment for them.
Given that I know QUITE a bit on the subject (Heh... I port games over to Linux and right now I'm off that for a little bit doing driver development consulting for one of the two aforementioned players in 3D...), I think I should comment.
Most of the extensions aren't ATI or NVidia specific that are usable. To be sure, they offer those, but most of the
extensions are ARB or EXT extensions- they're intended to be used by either player and are typically provided by
the same. The reality is that OpenGL 2.1 and DX9/10 are intrinsically identical except for programming style.
Besides, you should abstract out your engine components if you've any aspirations to target the next gen consoles-
DX10's NOT on PS3 or Wii, but OpenGL ES 2.0 IS and it's a clean, easy to use subset that ports back to MacOS and Linux.
1) Type I Diabetes patients have equally nasty problems (I know of at least two Type I patients...)- some of which are the same
as the Type II patients.
2) Fixing this one would be amazing- it was thought that generally Type I was treatable only with Insulin injections. To be "cured" would be amazing for them.
3) Some of the meds for Type II Diabetes can QUICKLY and VIOLENTLY turn you into a Type I Diabetic if you get exposed to certain other substances. The Avandia type meds and Glyburide type meds that affect utilization and production of Insulin can torch off what's left of the Islet cells in the Pancreas with exposure to things like...oh...alcohol...contrast dyes...handful of other things... When I was taking Avandia and when I was still taking Glyburide I had a list of things that were JUST NOT A VERY GOOD IDEA FOR ME TO TAKE/DO .
4) They have a metabolic switch that they've discovered that turns OFF Type II Diabetes like a light-switch; but you have to take the med for the rest of your life and they're being VERY cautious moving forward with it because it's a genetic based therapy like the Immune System Booster that they screwed up the lives of those poor bastards in the UK earlier this year.
If you've not figured it out by now, I'm a Type II Diabetic. So what if it doesn't help me? It's a fix for the other people out there that don't have the same set of problems I do, but still have serious issues with Sugar- this could free them from every bit of the issues with Insulin shots and needing to manage or avoid sugars. Not everything sugar free is good for you or a diabetic, contrary to the popular belief otherwise- and not everything uses Splenda (nor is it a certainty that it's any better than Nutrasweet, safety-wise...). To not have to worry much ever again... Wow...
In the case of Copyright or Patent, you're not obligated to enforce or completely lose the rights like in Trademark's case.
It WILL, however leave it open for a defense of laches (delay) against which you can reasonably ask for damages and they can
say that they don't owe them to you- but you can demand them to stop infringing at any time unless you give the impression
that you chose to not enforce against a class of individuals. At that point, while they can still be drug into court and all,
they have a positive defense against litigation (may/may not work, mind) that can give them an out all the way around.
You'll note that most businesses won't go the Patent Covenant/Licensing to FOSS projects route without care in what they're
doing for that very reason.
Oh, and to the people that say it's all about how many Patents... There is a lot to that- but the right Patent in the right
place and right time can be just as problematic to another company and weigh in as if it were the whole of a Patent pool like
OIN or IBM have in hand. Just ask Microsoft about that one- they've been burned several times in the last handful of years
and their patent pool didn't defend them at all- and this is when they HAD a substantive pool at their disposal.
BSD Won it's COPYRIGHT battles for the ORIGINAL code core. If it infringes on any current Patents or if
any of the new code infringes, it will face those battles AGAIN.
Don't need one. He's using an enhanced design of the Farnsworth Fusor, a device that while it doesn't CURRENTLY produce more energy out than in, DOES produce honest to God fusion reactions with a solid neutron flux. Major manufacturers are building the things as reliable, pretty much instant on, instant off, reliable neutron sources for other things. The fact that a kid actually BUILT one out of simple parts is the interesting thing.
However, I don't advocate just ANYONE building these things- the Fusor can produce deadly neutron fluxes readily and with the flip of a switch and a supplying of the Deuterium fuel.
If that were the case, why is NWN2 so inferior to the predecessor in overall performance. Sure it looks nice, but it's framerate sucks compared to the older game. It's all been converted over to DirectX... Heh... You know little of what you speak of- programmer productivity is only one piece and it's debateable that DirectX brings any of that.
Most people associate these with their fixed functionality paths and the coding for the same.
That'd be right for the older games or the older hardware.
It'd not be right for the new hardware or the new games...
The new GPUs use programmable vertex and fragment shaders and the fixed functionality paths go
through an emulation of those paths in GLSL or HLSL. There's not much left that
isn't merely a simplified computer like a DSP is for signal processing- this is merely one that
is designed for graphics and similar operations instead.
The new games use their own shaders, etc. which is why GLSL is such a big deal and a tool to migrate
HLSL over is as much of one.
Who can say for certain that this doesn't make sense? I'm not going to venture a yes or no- because
I can see where they could pull it clean off and I can see some where it could let them fall flat on
their face.
And, how many times does it need to be said that there's alternatives to each piece. In fact, the big studios don't use much of ANY of DirectX' stuff directly- because they're anticipating a port to a console. So they use Miles, FMOD, or OpenAL for sound. They typically have rolled their own network stack code, but now, there's TNL, RakNet, and Grapple (It's not portable yet, but that's on my plate, so it's soon...). There's little reason to be even USING their DirectX APIs because they LIMIT you (And in some cases, MS has deprecated them- DirectPlay, the network layer, for example...)- and in many cases, things like Miles works MUCH better than the DirectFoo equivalent and plugs into the same low-level hooks in the OS.
Unless you're targeting X-Box, there's little need for using DirectX. If you plan on targeting X-Box, you're better off making a rendering
abstraction layer that insulates the game from the choice of either, picking other things for sound like Miles or OpenAL, and then grabbing
a license for TNL/RakNet or rolling your own or grabbing Grapple and finishing the minimal work to make it run under Windows.
For anyone that thinks Cedega's (or WINE, for that matter...) anything other than a good short-term solution to
Linux gaming, all I need do is point them to this as a good example of why it's not so hot of an idea. And it's
perfectly within Blizzard's rights to do this action- to the point of ignoring any contact with regards to this
whole affair. Doesn't make it good for PR or customer relations, mind- but it's completely within their rights
to do so. After all, they only support Windows on this title and don't have plans to provide support to other
OS platforms. Again, which is their right.
Native ports wouldn't have as many of these issues.
As for the whole affair... It's Blizzard. They've apparently got a singular attitude about Linux users that
started with the period around Starcraft forward. I wouldn't buy any title from them right now and for some
while to come- you just don't treat customers or potential customers the way they seem wont to do.
Must be tired...must find caffeine...
Uh, it's not radioactive isotopes, it's ionizing radiation.
Isotopes go away. Pull the ionizing radiation away and the radiation goes too. Neutron flux is a different
story, but in that case, you're altering the atomic structure and causing isotopes to form...
Most coal power plants are primary plants (meaning you're getting at least a fraction of the juice on the grid from them...), running 24x7 because it takes a while to spin one of those up. Those massive tall stacks? They're scrubbers as much as anything else. Yes, they dump pollutants, including CO2 into the air, but nothing like people make them out to. And, there's something else out there- several different processes patented in the late 1800's and early 1900's that cleanly convert coal into coke (clean burning coal solids...), further refineable fuel oil, and natural gas sufficient to maintain the process continuously.
Coal's a good stopgap if we start running short of crude, as is several other sources and processes. To be sure, we need to migrate
to something else moving forward- but to what?
TDP'd waste? It's possible to do so, but it's still not there yet- not refined enough.
BioDiesel? It's here, it's here now, but not everything is able to run off of B100 or lower- not everything's a Diesel.
Wind/Solar? Heh... Sorta usable. Sorta not. And it's a purely electric play. We don't have good enough
storage tech to make it apply to vehicles- and what about jets, etc.?
Nuclear? Not yet. Had we gotten a little better at that and did a bunch more plants, perhaps- but unless someone
goes and develops a usable Migma Fission reactor or a solid state or plasma fusion reaction it's not going to happen
yet.
In reality, we have to do something. Coal's a good step as is Biodiesel. TDP can come up
as long as people aren't being stupid about it (like the trial plant... it's going to smell
off from time to time- it's a type of rendering technology...sheesh... Move the plant away
from everything if it's a problem.)- that handles electricity and mobile tech for the short
term. Then we can get to improving the other alternatives ASAP. With TDP and Biodiesel, the
carbon potential subsides- you're using carbon already in the cycle that hasn't really been
sequestered yet like Oil and Coal are. With the others, we're still just a bit too far off
yet to do anything with them.
A Geode GX is little more than a core clock-speed increased version of the MediaGX/Geode GXm, that was bought from NatSemi, who
bought it from Cyrix when they sold the other half to VIA. It's a weak chip. it has a FSB of 33 MHz so that
it could work with PC-66 memory without any L2 cache involvement to raise board or chip pricing. The whole design cripples it
out of the gate. If it's a GX design, it stinks on ice except for a few usable embedded/kiosk designs and, yes, the thing
stinks compared to your machine. It's biggest selling point was it consumed 1-2 Watts TDP at full speed and didn't need much
fansink and could be completely passively cooled. The PIC used THIS CPU in it's design. This destined it to fail out of the
gate. Just like every other design using this chip. It looks good on paper, the marketing speak talks a good talk, but when
it comes to reality, the rubber meeting the pavement- the 33 MHz FSB dooms the device to mediocre performance every time.
They shave pennies off the BOM with this idea, only to have a truly sub-optimal performer, when they could have used a LX or
a NX (Or in the case of someone other than AMD, an Eden or C3/C7 design...)
A Geode LX is a reworked version of the chip design, which was slated to be called the Geode G2 by NatSemi, but they never
really released it. AMD bought the design and took it to market. It's an improvement, with a 66MHz FSB, etc. It's still
underpowered compared to a VIA C3 or a Geode NX, but a decent design. This, I believe, is the CPU choice for the OLPC
laptop. It's not the greatest chip in the world, but it burns a little less watts than the VIA answers, so while it performs
slower overall, it's cooler overall as well- meaning it needs less juice to operate with.
A Geode NX is a very low-power version of the AthlonXP core with all that entails. You can buy machines at Fry's on the
bottom end of the price scale with these on an older style AthonXP motherboard right now- about $250 or so without a monitor.
In reality, C's behavior (and a lot of other languages, really) are governed by behaviors within the CPU hardware
they were originally intended for. In the case of C, the machines in question only had one hardware stack, so they
intermingled the subroutine return state with the parameters, etc. for speed's sake. Implementing a second stack
in software would have been problematic because it would have added extra performance issues and ate into the
register store (you want to probably reserve a register for the parameter pointer...). Since most of the Algol derived
languages (C's in that bunch...) do this very thing, there's been no need, no desire to change the underlying machine
that the language sees, nor has any of the X86 vendors had a reason to "fix" the problem of register store space.
While it's syntax is difficult to initially grasp (esp. if you've been doing Algol based languages...), Forth's
machine model is one like you suggested. Obviously, on machines that it has the ability to execute operations
against the contents of the artificial data stack or where it actually HAS two data stacks, the code excels in
speed. Comparable to C or better than C without as many of the risks (though it WILL cut your throat in other
ways- just not that one...). Otherwise, while it makes for very compact code, it does so at the expense of some
performance on machines without such support. In those cases, it's best is just at C's peak performance on the
same task and something like 10-20% slower otherwise. It's still around because it can fit a high-level
programming solution into the smallest space in memory possible without overly sacrificing speed at the same
time- obviously a good thing in an embedded system.
In the end, it's more about how careful you code things. Internally, when you know what's going to be passed in
and can control things, it's probably "okay" to not check for potential buffer overruns. It's not okay otherwise.
Because it's a major performance hit, I know why someone would be inclined to not do any checks or to overdo
the avoidance of doing them- it doesn't make it right, but I understand the why behind it and the problem in question.
Probably at least a DoS attack will be possible since the vector of attack is through
the firmware layer for the device.
Fusebox is one place. Power meter's the other. I suspect that most PLC implementations
for home have relied on the meter to handle the cross-over between phases, etc. If you've
got two meters, I suspect you'd need a bridge of some type like the X10 booster bridge for
homes to bridge them all without mixing the power from each feed.
In fact, I do. But relying on HomePlug to "protect you" much better than WiFi
is a little bit of folly. No, you can't have the article's attack made on you.
But as the parent poster has pointed out, you're not as protected as you think-
someone can snoop in on your traffic if they've got their own home plug and can
tap into either phase of the two-phase 220v circuit comng into your house.
With clever enough hardware they wouldn't even need to do that- it emits enough
RF-like signal...
Fixed wiring Ethernet is probably the most secure of the lot- HPNA and HomePlug
suffer from people being able to tap in (in the case of HPNA, all someone has to
do is splice into your demarc- there's no barriers other than distance that protect
you from snooping/attack...). WiFi and other wireless tech...heh...
Actually, it's more than just the N64.
Atari 7800
SNES
Dreamcast
Gamecube
I'd say it was more of a majority of them were more than $300 in today's dollars.
Of worthy note is that the Genesis ALMOST makes it into that club (~$306) and the
PSX is bumped out of it by $48 in today's values...
Right now, Sony's making the NeoGeo play (In terms of the then dollars, it was about
the same price and had a vast leg-up over the other consoles in terms of power and
display capabilities, etc...)- and we all know how well that worked for SNK;
while they stayed afloat, it was more due to the Arcade unit sales than the
console ones...