It is all a matter of background. Compared to the ex-nerds around her she does look like a babe.
For example see
this.
And frankly I am ready to forgive her a lot after seeing picture number 5 from the avove show.
In btw, these are not a fake. They is real and I think she deserves a lot of credit for puling this one off.
Has anyone ever based a multi-thousand dollar car purchase on a car ad they saw?
First: I will ask the question as: "Has anyone made a multithousand dollar purchase on a car which they never ever saw any ads? Many people do not search reviews the way geeks do. They look only at cars which they recognise.
Second: You are understimating the fact that many car manufacturers are willing to invest into the future. Recently, while waiting at the dentist, I observed the behaviour of two 11-13 year old kids who were looking through automotive magazines. They were obviously 100% brainwashed. Basically repeating adverts to each other and believing it (and adding some banter on top). Some people grow up from that phase after their first or second car. Even so, they are still likely to make at least one purchase based on brainwashing. Some people never grow up. After all someone needs to buy BMWs and those chest of drawers with a jet engine known as Labourgini.
Well, this is still seems to be mostly U.S. problem.
Not really. The most interesting parts of system V have been through an industry standard process where representatives of ATT, Novell and SCO/Caldera were present. If they attempt to put any claims to anything that has gone through that process they are up to the same serious shafting as RamBus(t).
Actually, it is interesting that IBM did not put this in their counterclaims. Possibly they are holding that one in reserve just in case SCO wins. Because, then it will be burried by the entire industry. After all about 10% of the fortune 500 had people in various POSIX groups. Basically, if SCO wins, it will lose because courts will declare the money uncollectable as in the Rambus case.
They SHOULD already have it as a contingent liability. One more SCO press release does not change a thing there as far as institutional investors are concerned. Their analists have all supposedly read and noticed that.
If Google did not put this into the prospectus - well it is a completely different story.
No. Google is pre-IPO. The normal reaction for an american company under the circumstances is "always settle so that the IPO goes through".
All I can say is that I hope that SCO has forgotten that Google is not by any means an average US company. If it was, it would have long gone belly up.
Fairly stupid and will not work. At least with SPAM assassin. It does Bayes on two word combinations (unless you change one of the defaults). So random words will not get into the bayes dictionary anyway.
see the crash in swiss airspace where the pilot went against his TCAS and people died because of it
He did not go against his TCAS out of his own volition. He obeyed orders given by a dimwit dumbfuck from the ground. Which the Swiss air control tried to hide and blame on the pilot.
Just as they usually do. They are the second most famous after the French in Europe about it. Ever heard of a crash in Swiss air space when the pilot is not guilty? Even if he is given instructions to try to land from the hill side in a snow storm in near zero visibility like that CrossAir flight to Zurich three years ago?
The case with UPS and the russian 154 was the most recent in a whole lineup of other ones. Just in those cases the Swiss have been successfull in covering up because the crash occured on Swiss soil and they "investigated" it.
Thanks god the case which you are referring to crashed on German soil and it took their police only 24h to find out that the Swiss Air traffic control is bunch of lieing homicidal twats. As well as the fact that the reason for the crash was that someone gave the pilot orders to do so. Which by the way can be done with the no-fly-zone programming.
5. Here is one I got wrong. I predicted that China would standardize on Linux running on MIPS hardware. OK, so he stopped predicting the sun would rise tomorrow and got on with some original thinking. And failed, though it was a nice idea.
Actually, the process has stalled and was nowhere as fast as people thought, but China is still pretty much moving in that direction. So it is too early to say. So the wrong part here is that he sais that his predicttion failed. Also it is not MIPS(tm). Some parts of the instruction set and paten encumbered parts of the ISA are missing
It is antiship only and cannot be programmed to follow a classic cruise missile "follow the ground" approach. Also the indian one will be possible to be programmed to do an evasive pattern in the last mile. Moskit cannot do that. It has a very high kill probability due to the sheer speed, but it can be taken down by an active defence system which has been brought online on time. For the BrahMos it will be considerably more difficult.
You are mistaking the lethality levels for mildly toxic lithium salts taken orally with the lethality levels for various compounds (including LiOH) coming from combustion of lithium ion batteries. Besides some of them having a much lower LDA50, they will also be considerably more dangerous because they will be inhaled.
Litium is extremely toxic. And the energy density in an average laptop battery is enough to bring more then enough of it in the air.
The scary part is that got allowed on board of airplanes after the FAA got convinced that correctly operating bateries are safe. Well... This brings up the obvious question - what about incorrectly operating ones. And what about ones that have had their short circuit protection removed? Nearly perfect bomb and perfectly legal to bring onboard passing all security checks with flying colours.
I think you are flaimbaiting, but I will still answer.
A lot of people have keyless entry remotes for their car, and I've never heard of one of those being "hacked" to unlock someone's door
Bollocks: Almost all alarms (even the most advertised ones) have been hacked. You simply leave in the wrong country. Just go somewhere east of the ex-iron curtain. When I lived there the neigbours in the same office block used to make a living off it as well as hackig ECUs, trip computers and other similar annoyances that show that the car has been driven for 300000 miles, not 30000 as is written on the fake documents.
Actually, hacking almost all of them is very simple because very few have a real challenge/responce and almost all are transmit only which forces them to have backdoors in the rolling code which allow resetting code sequence. If they did not, you would not have been able to use the spare keys because they are never at the same sequence number as the ones you normally use. Actually do the experiment for yourself. Use only one set of keys for a week and try the other one. You will notice a considerable delay before the alarm turns off. It is due to the keyfob going into reset-sequence mode. The sequence transmitted in the reset sequence mode on all but the most expensive "double rolling code" alarms is almost always the same. All you need is to jam the keyfob while doing normal transmission and record the reset sequence. Bingo. You are in.
But I'm told that if you lose the remotes for your car, the dealer can replace them
Bollocks again. Since 1995-1997 in order to replace keys on almost all cars I can think of, you need to bring both your car and your keys to the dealer. You cannot just ask for new keys if they have a built in key in chip immobilizer. Basically the dealer has to put the ECU into a special learning mode and it has to remember the codes for the keys. It is not secure, but in order to do it you have to have:
1. Same key (mechanically)
2. Tools to switch the ECU into learning mode. For anything besides Daihatsu this requires hooking it up the external diagnostic module that costs a little fortune and is issued only to authorized dealership (Daihatsu sells you a special key with the car that does that).
3. The keys available for programming while the ECU is in learning mode.
I can continue throuh the bollocks you have written, but dude. You seriously need a clue.
Do you have any bloody idea how close you are to the truth?
The first thing to happen with global warming will be a Gulfstream stop. Most of Europe will freeze outright. The current models are for 9-11C lower on year averages in England and around 7-9C around the North Sea - Germany, Denmark, Belgium, etc.
At the same time Central America will get fried as the rainfall band goes north and near desert conditions descend on the Mexico and Panama. Texas will become cooler and more humid, so on so forth.
Ever wandered why Greenland is called Greenland, Iceland is called Iceland and the Maya empire died off in less then a few decades? Well... It is a well known fact that it was "warmer" around 800-1200 before the beginning of the current mini ice age. It is also a well known fact that the north of the Mediteranean Sea froze on multiple occasions in the 8-13 century.
So global warming on average does not mean that some of us will not freeze. It is global warming on average and as an overall yearly average. After all in the middle of Siberia it often gets as warm as +30C in the summer (and -40C in the winter).
What you are missing is that in 1981 the languages in use were flat structured and addressed the database from all over the place. What happened in the 1980-1990es was that the databases got a 1981 level solution - Fortran 77 level like languages with abnoxious syntax (ever tried to look at a full parser for SQL? Try:-)
The difference between 1981 and 2003 (for big projects) is that the database is usually touched only in an object create, store, retrieve and delete methods and in rare cases one or two more application specific methods.
As a result, instead of it being accessed all over the place the access is limited and work is done mostly in the application. Using foreign keys, triggers, stored procedures, so on under these conditions makes sense only under a limited set of circumstances. You are much better off splitting the tasks and doing them at app level. You can also do stuff which is extremely expensive to do at a PSQL/TSQL level. For example foreign key is nothing but an example of a simplistic reference counting with the reference values being limited to zero and non-zero. It is fairly obvious that in many cases where a foreign key has been used on data that is loaded into a list of various objects you actually need a proper reference count (and a proper garbage collector to kill of dead references). So on so forth.
In btw, do not understand me wrong. I have no objection to using foreign keys for the rare cases where you have several trained baboons using MS access or even SQL queries directly. What I have to note that this usage is slowly descending to the red book of endangered species and the usage of interest is the one from an OO language. There you either have to deliver the relevant performance, because 90% of the developers do not give a flying fuck about having their database access optimized. All they care about are abstracted store, load, update, delete.
So you have the choice. You either get involved with the developers process and work with them to get these store, load, update, delete optimized which usually ends up in moving PSQL code to C++ or Java at the client end. Alternatively they tell you to FUCK OFF and move to a persistent object store like prevailer. And they are bloody right.
Err... What you miss is that that foreign key transactions are what it reads on the label - transactions. They are done end to end now, hear and holding the relevant locks. At the same time if you do them by split join/garbage collection you can move the cleanup to idle hours. This quite often is the factor that may push an otherwise out of spec transaction system back into spec.
Of couse this is all valid if you can replace the existing selects by selects with joins. In most nowdays projects where the database access is abstracted and unified as load/store methods for objects this is not a problem.
Do you even know what a foreign key is, or how it's used?
Yes I do. And I have revived and made perform to to spec god knows how many cretinous foreign key designs by a combination of
removing the foreign key
using join for selects to guarantee that only records with valid referential criteria are retrieved. This is equivalent to having a foreign key constraint in the sense that apps do not see any records that do not obey the foreign key contsraint.
garbage collector running in a different thread or often different machine that goes around and kills zombies whose referential integrity has been violated.
The difference between this and a classic foreign key constraint is that this approach always uses efficiently multiple CPUS while a foreignkey is usually a single CPU bound task, it also maintains much less large scope (global or per table) locks and is generally faster for retrieves by a factor of between 10 and 100 times. Due to the TPC vendors have overoptimized join at the expense of many other different things in order to have nice benchmarks..
And in btw, learn the difference between a "real DBA" and a database designer. I mean the one that is the justification for the 20+% salary difference.
A pain in the butt, but in order to have stored procedures you need a procedural language.
MySQL got none and methinks it is a jolly good idea because all SQL procedural languages are somewhere around Fortran 77 level in terms of concepts and syntax. Objects? Inheritance? Code reuse? Loadable Modules? In PSQL or TSQL? Bwahahahah....
And in fact MySQL has always had a loadable object module environment in C++ and recently in Java. Where you have all those concepts. So the people who do not want to get stuck in Fortran77 like syntactic quagmire and who really need a server side transaction extension could have had it since 3.something. And the ones that do not better learn how to do it in proper programming languages at middleware/access library level.
# no triggers
In order to have a trigger you have to have a procedural language. See above. Moot.
# no foreign key constraints
Any foreign key constraint may be expressed as a join and this is usually considerably faster. No point in having them as long as the query environment is controlled and queries that can modify the database are issued through a library which takes care of the relevant joins and locks. This may sound as a constraint, but it is not. Just think how often you are allowed to execute unadulterated SQL when working on a large project?
# no updates on joins
Err... Are you trying to intentionally obfuscate your SQL in order to achieve job security or what?
Overall, MySQL offers a slightly different paradigm from Oracle and Sybase and it has its reasons for doing so. If you have a clue for any of the above tasks you can achieve the same results with it without going through too many hoops. You can also learn how to do things FAST and I have brought this from MySQL back to Oracle and Sybase projects.
This does not mean that MySQL does not have its failings. It does. Try it on a datawarehousing application and you will see why the big guns are big guns.
You may be laughing, but you do not understand their case. They are trying to claim copyright the ABI. If they can do so anything that uses similar calls and has similar return codes is infringing. I have to admit it is interesting, but they are not going to get very far because the ABI itself is standardized and such a defence may end up backfiring with a case for trying to defraud a standards body (see Infineon vs Rambus).
Collaborative effort... Hmm... Grep for F**K and B**GER especially in the sparc tree. In btw, it will be intresting if SCO claims infringment in these files on the basis of similar comments. It will be the biggest possible ROFL of the year.
A not very well known piece of knowledge is that ATI is extremely picky on thermals. I have found it out the hard way and have been extremely careful not to put an ATI card into a case which does not have good cooling. Especially small factor cases and using it on risers (so it is chip down) are a definite no-no. Once you follow on this it is usually more or less OK (depends what you do with it of course).
Why welcome back? For those who have bought C3 motherboards it has hardly been gone. All M and CL series motherboards have S3 derived card on board. I am actually typing this on one of them. It is not a gamer's card, but X is rock solid, 2d accel is very good and that is what I would like from a medium class device. I do not give a flying f*** about 3d as nethack does not really care about it:-)
And you know why - because I know that I control the life and soul of any of them and they will not object and will only say: "Yes Great White Master".
How true it is in reality is another matter. But that is what many little outsourcing minds think. I had one of these brought in into a company I used to work for 3 years ago. And it was fairly obvious because the first time he mentioned outsourcing was after three people during a meeting showed that one of his ideas is complete and utter bulshit.
Slashdot Mirror
In btw, these are not a fake. They is real and I think she deserves a lot of credit for puling this one off.
First: I will ask the question as: "Has anyone made a multithousand dollar purchase on a car which they never ever saw any ads? Many people do not search reviews the way geeks do. They look only at cars which they recognise.
Second: You are understimating the fact that many car manufacturers are willing to invest into the future. Recently, while waiting at the dentist, I observed the behaviour of two 11-13 year old kids who were looking through automotive magazines. They were obviously 100% brainwashed. Basically repeating adverts to each other and believing it (and adding some banter on top). Some people grow up from that phase after their first or second car. Even so, they are still likely to make at least one purchase based on brainwashing. Some people never grow up. After all someone needs to buy BMWs and those chest of drawers with a jet engine known as Labourgini.
Not really. The most interesting parts of system V have been through an industry standard process where representatives of ATT, Novell and SCO/Caldera were present. If they attempt to put any claims to anything that has gone through that process they are up to the same serious shafting as RamBus(t).
Actually, it is interesting that IBM did not put this in their counterclaims. Possibly they are holding that one in reserve just in case SCO wins. Because, then it will be burried by the entire industry. After all about 10% of the fortune 500 had people in various POSIX groups. Basically, if SCO wins, it will lose because courts will declare the money uncollectable as in the Rambus case.
They SHOULD already have it as a contingent liability. One more SCO press release does not change a thing there as far as institutional investors are concerned. Their analists have all supposedly read and noticed that.
If Google did not put this into the prospectus - well it is a completely different story.
No. Google is pre-IPO. The normal reaction for an american company under the circumstances is "always settle so that the IPO goes through".
All I can say is that I hope that SCO has forgotten that Google is not by any means an average US company. If it was, it would have long gone belly up.
Has anyone, but the judiciary really opposed his conentration camp building hobby?
Fairly stupid and will not work. At least with SPAM assassin. It does Bayes on two word combinations (unless you change one of the defaults). So random words will not get into the bayes dictionary anyway.
He did not go against his TCAS out of his own volition. He obeyed orders given by a dimwit dumbfuck from the ground. Which the Swiss air control tried to hide and blame on the pilot. Just as they usually do. They are the second most famous after the French in Europe about it. Ever heard of a crash in Swiss air space when the pilot is not guilty? Even if he is given instructions to try to land from the hill side in a snow storm in near zero visibility like that CrossAir flight to Zurich three years ago?
The case with UPS and the russian 154 was the most recent in a whole lineup of other ones. Just in those cases the Swiss have been successfull in covering up because the crash occured on Swiss soil and they "investigated" it.
Thanks god the case which you are referring to crashed on German soil and it took their police only 24h to find out that the Swiss Air traffic control is bunch of lieing homicidal twats. As well as the fact that the reason for the crash was that someone gave the pilot orders to do so. Which by the way can be done with the no-fly-zone programming.
OK, so he stopped predicting the sun would rise tomorrow and got on with some original thinking. And failed, though it was a nice idea.
Actually, the process has stalled and was nowhere as fast as people thought, but China is still pretty much moving in that direction. So it is too early to say. So the wrong part here is that he sais that his predicttion failed. Also it is not MIPS(tm). Some parts of the instruction set and paten encumbered parts of the ISA are missing
It is antiship only and cannot be programmed to follow a classic cruise missile "follow the ground" approach. Also the indian one will be possible to be programmed to do an evasive pattern in the last mile. Moskit cannot do that. It has a very high kill probability due to the sheer speed, but it can be taken down by an active defence system which has been brought online on time. For the BrahMos it will be considerably more difficult.
Err... I beg to differ sir.
You are mistaking the lethality levels for mildly toxic lithium salts taken orally with the lethality levels for various compounds (including LiOH) coming from combustion of lithium ion batteries. Besides some of them having a much lower LDA50, they will also be considerably more dangerous because they will be inhaled.
Litium is extremely toxic. And the energy density in an average laptop battery is enough to bring more then enough of it in the air.
The scary part is that got allowed on board of airplanes after the FAA got convinced that correctly operating bateries are safe. Well... This brings up the obvious question - what about incorrectly operating ones. And what about ones that have had their short circuit protection removed? Nearly perfect bomb and perfectly legal to bring onboard passing all security checks with flying colours.
Scary...
A lot of people have keyless entry remotes for their car, and I've never heard of one of those being "hacked" to unlock someone's door
Bollocks: Almost all alarms (even the most advertised ones) have been hacked. You simply leave in the wrong country. Just go somewhere east of the ex-iron curtain. When I lived there the neigbours in the same office block used to make a living off it as well as hackig ECUs, trip computers and other similar annoyances that show that the car has been driven for 300000 miles, not 30000 as is written on the fake documents.
Actually, hacking almost all of them is very simple because very few have a real challenge/responce and almost all are transmit only which forces them to have backdoors in the rolling code which allow resetting code sequence. If they did not, you would not have been able to use the spare keys because they are never at the same sequence number as the ones you normally use. Actually do the experiment for yourself. Use only one set of keys for a week and try the other one. You will notice a considerable delay before the alarm turns off. It is due to the keyfob going into reset-sequence mode. The sequence transmitted in the reset sequence mode on all but the most expensive "double rolling code" alarms is almost always the same. All you need is to jam the keyfob while doing normal transmission and record the reset sequence. Bingo. You are in.
But I'm told that if you lose the remotes for your car, the dealer can replace them
Bollocks again. Since 1995-1997 in order to replace keys on almost all cars I can think of, you need to bring both your car and your keys to the dealer. You cannot just ask for new keys if they have a built in key in chip immobilizer. Basically the dealer has to put the ECU into a special learning mode and it has to remember the codes for the keys. It is not secure, but in order to do it you have to have:
1. Same key (mechanically)
2. Tools to switch the ECU into learning mode. For anything besides Daihatsu this requires hooking it up the external diagnostic module that costs a little fortune and is issued only to authorized dealership (Daihatsu sells you a special key with the car that does that).
3. The keys available for programming while the ECU is in learning mode.
I can continue throuh the bollocks you have written, but dude. You seriously need a clue.
Do you have any bloody idea how close you are to the truth?
The first thing to happen with global warming will be a Gulfstream stop. Most of Europe will freeze outright. The current models are for 9-11C lower on year averages in England and around 7-9C around the North Sea - Germany, Denmark, Belgium, etc.
At the same time Central America will get fried as the rainfall band goes north and near desert conditions descend on the Mexico and Panama. Texas will become cooler and more humid, so on so forth.
Ever wandered why Greenland is called Greenland, Iceland is called Iceland and the Maya empire died off in less then a few decades? Well... It is a well known fact that it was "warmer" around 800-1200 before the beginning of the current mini ice age. It is also a well known fact that the north of the Mediteranean Sea froze on multiple occasions in the 8-13 century.
So global warming on average does not mean that some of us will not freeze. It is global warming on average and as an overall yearly average. After all in the middle of Siberia it often gets as warm as +30C in the summer (and -40C in the winter).
What you are missing is that in 1981 the languages in use were flat structured and addressed the database from all over the place. What happened in the 1980-1990es was that the databases got a 1981 level solution - Fortran 77 level like languages with abnoxious syntax (ever tried to look at a full parser for SQL? Try :-)
The difference between 1981 and 2003 (for big projects) is that the database is usually touched only in an object create, store, retrieve and delete methods and in rare cases one or two more application specific methods.
As a result, instead of it being accessed all over the place the access is limited and work is done mostly in the application. Using foreign keys, triggers, stored procedures, so on under these conditions makes sense only under a limited set of circumstances. You are much better off splitting the tasks and doing them at app level. You can also do stuff which is extremely expensive to do at a PSQL/TSQL level. For example foreign key is nothing but an example of a simplistic reference counting with the reference values being limited to zero and non-zero. It is fairly obvious that in many cases where a foreign key has been used on data that is loaded into a list of various objects you actually need a proper reference count (and a proper garbage collector to kill of dead references). So on so forth.
In btw, do not understand me wrong. I have no objection to using foreign keys for the rare cases where you have several trained baboons using MS access or even SQL queries directly. What I have to note that this usage is slowly descending to the red book of endangered species and the usage of interest is the one from an OO language. There you either have to deliver the relevant performance, because 90% of the developers do not give a flying fuck about having their database access optimized. All they care about are abstracted store, load, update, delete.
So you have the choice. You either get involved with the developers process and work with them to get these store, load, update, delete optimized which usually ends up in moving PSQL code to C++ or Java at the client end. Alternatively they tell you to FUCK OFF and move to a persistent object store like prevailer. And they are bloody right.
Err... What you miss is that that foreign key transactions are what it reads on the label - transactions. They are done end to end now, hear and holding the relevant locks. At the same time if you do them by split join/garbage collection you can move the cleanup to idle hours. This quite often is the factor that may push an otherwise out of spec transaction system back into spec.
Of couse this is all valid if you can replace the existing selects by selects with joins. In most nowdays projects where the database access is abstracted and unified as load/store methods for objects this is not a problem.
Yes I do. And I have revived and made perform to to spec god knows how many cretinous foreign key designs by a combination of
The difference between this and a classic foreign key constraint is that this approach always uses efficiently multiple CPUS while a foreignkey is usually a single CPU bound task, it also maintains much less large scope (global or per table) locks and is generally faster for retrieves by a factor of between 10 and 100 times. Due to the TPC vendors have overoptimized join at the expense of many other different things in order to have nice benchmarks..
And in btw, learn the difference between a "real DBA" and a database designer. I mean the one that is the justification for the 20+% salary difference.
Cheers (lessons start at 500 per hour),
# no subqueries
Can be easily worked around. Who cares.
# no stored procedures
A pain in the butt, but in order to have stored procedures you need a procedural language.
MySQL got none and methinks it is a jolly good idea because all SQL procedural languages are somewhere around Fortran 77 level in terms of concepts and syntax. Objects? Inheritance? Code reuse? Loadable Modules? In PSQL or TSQL? Bwahahahah....
And in fact MySQL has always had a loadable object module environment in C++ and recently in Java. Where you have all those concepts. So the people who do not want to get stuck in Fortran77 like syntactic quagmire and who really need a server side transaction extension could have had it since 3.something. And the ones that do not better learn how to do it in proper programming languages at middleware/access library level.
# no triggers
In order to have a trigger you have to have a procedural language. See above. Moot.
# no foreign key constraints
Any foreign key constraint may be expressed as a join and this is usually considerably faster. No point in having them as long as the query environment is controlled and queries that can modify the database are issued through a library which takes care of the relevant joins and locks. This may sound as a constraint, but it is not. Just think how often you are allowed to execute unadulterated SQL when working on a large project?
# no updates on joins
Err... Are you trying to intentionally obfuscate your SQL in order to achieve job security or what?
Overall, MySQL offers a slightly different paradigm from Oracle and Sybase and it has its reasons for doing so. If you have a clue for any of the above tasks you can achieve the same results with it without going through too many hoops. You can also learn how to do things FAST and I have brought this from MySQL back to Oracle and Sybase projects.
This does not mean that MySQL does not have its failings. It does. Try it on a datawarehousing application and you will see why the big guns are big guns.
You may be laughing, but you do not understand their case. They are trying to claim copyright the ABI. If they can do so anything that uses similar calls and has similar return codes is infringing. I have to admit it is interesting, but they are not going to get very far because the ABI itself is standardized and such a defence may end up backfiring with a case for trying to defraud a standards body (see Infineon vs Rambus).
Collaborative effort... Hmm... Grep for F**K and B**GER especially in the sparc tree. In btw, it will be intresting if SCO claims infringment in these files on the basis of similar comments. It will be the biggest possible ROFL of the year.
NOT FUNNY. And too b*** f*** likely to happen unfortunately.
Not just old. Crown survey in the UK (which is the primary source for almost all map data) still does it.
A not very well known piece of knowledge is that ATI is extremely picky on thermals. I have found it out the hard way and have been extremely careful not to put an ATI card into a case which does not have good cooling. Especially small factor cases and using it on risers (so it is chip down) are a definite no-no. Once you follow on this it is usually more or less OK (depends what you do with it of course).
Why welcome back? For those who have bought C3 motherboards it has hardly been gone. All M and CL series motherboards have S3 derived card on board. I am actually typing this on one of them. It is not a gamer's card, but X is rock solid, 2d accel is very good and that is what I would like from a medium class device. I do not give a flying f*** about 3d as nethack does not really care about it :-)
Right on target.
And you know why - because I know that I control the life and soul of any of them and they will not object and will only say: "Yes Great White Master".
How true it is in reality is another matter. But that is what many little outsourcing minds think. I had one of these brought in into a company I used to work for 3 years ago. And it was fairly obvious because the first time he mentioned outsourcing was after three people during a meeting showed that one of his ideas is complete and utter bulshit.