How come so many people rant and rant about how clockspeed isn't everything, then they go and use the same argument in a different way to establish the "clear superiority" of the Athlon?
That is exactly my point--people see these huge numbers but they do not translate to beter performance, hence, clockspeed isn't everything. Price/performance ratio is. For those who can buy without consideration of price, which is few of us indeed, AMD and Intel leapfrog each-other all the time. Right now, the 2.2GHz P4 is slightly faster overall thanthe Athlon XP 2000+. AMD will release the.13u version and it will likely leapfrom Intel, who will up the clockspeed again (and FSB) and leapfrog AMD, who will release the Hammer series... Ad infinitum.
"Essentially overclocked" Pentium 4? It's not a new Pentium 4 chip, it's a new motherboard. Of course it's an "essentially overclocked" Pentium 4. Why add in the negative connotations?
Negative connotations weren't really intended per se, but the fact that a platform which has not been released is being compared to one that is available right now needed some good, strong contrast. Just in case. (I may be wrong, it's happened before no doubt)
I dunno, looking at these benchmarks I'd say the Pentium 4's architecture is damn fast. It's scaling up incredibly fast. Remember when it was first released and everybody called it a disaster?
It is certainly scaling in clockspeed, but its inefficient design is holding it back in actual performance. Not its 8k L1 cache--the same size as that of a 486. Note its three execution units, only two of which can possibly be fed by the instruction scheduler at any one time. Note its use of FSB bandwidth being terribly inefficient, noteable in that the 3GHz P4 with a 100MHz bus *4 is slower than the 2.666GHz P4 with a 133MHz * 4 bus. The Athlon is still scaling almost linearly with its 133MHz * 2 bus. The P4's FSB timings need to be more exact (higher frequency devices dictate this) thus making the bus less scaleable--one reason that it was initially launched at 100MHz*4 instead of 133*4. The performance figures indicate that the P4 is very highly dependant on a huge amount of FSB bandwidth, and how that the FSB must scale almost linearly at a very early point to be able to keep up. I guess we'll see what happens when the P4 exceeds 3GHz and saturates its 133MHz bus. (Of course, Intel has some damn good engineers so they will surely think of something).
How many modules does this assume?
As I said, "Similarly to a series electrical circuit, versus a parallel circuit, the data being requested from an RDRAM RIMM must pass through each and every one of a RIMM's chips. Likewise, when a second RIMM is added, the signal must pass not only through the first RIMM, but through each chip on the second RIMM as well. "
Anyway, your quote does not conflict with mine in that it is likely assuming a single module. THink about it--Rambust IS a SERIAL technology. By definition, it cannot access in parallel, and each transaction must go through the same serial bus--hence--each chip.
Quoting one website with information that actually agrees with my conclusion (but for different reasons) is not grounds to say that my statement is BS, particularly when it is not.
As your sig says, a little knowledge is dangerous.
Of course a not-yet-released equivalent of an overclocked P4 is going to beat the competition vs. AMD's AthlonXP which is out and available NOW.
I would like to note that while the P4 did pounce the AthlonXP, take a look at the numbers (and i'm not talking about price, as I don't even want to know how much that P4 will cost!)
AthlonXP 2000+ runs at 1,666MHz at a bus which is the equivalent of 266MHz.
The P4 is running at 2666MHz (a full Gigahertz higher frequency) with a bus at the equivalent of 533MHz.
The (essentiually overclocked) Pentium 4 has a full SIXTY PERCENT CPU clockspeed advantage and a ONE HUNDRED PERCENT front side bus (FSB) advantage, yet look at its real-world performance:
MP3 encoding: 6.2% faster than the Athlon. (woop)
DivX encoding: 30% (note that the program is highly optimized, by Intel themselves, for the P4. How many programmers have an Intel engineer handy?)
Xinema 4D: 12.8%
3DMark 2001: 4.9%
Note that that Lightwave was not included--the only common test that runs faster on the P4 is the raytracing test. Guess which one Tom's Hardware used?
I just thought I'd point out that the only conclusion that you can really draw from these tests is that, as many in the hardware community know, the P4's architecture is designed for high clockspeed, with zero regard to actual real-world performance. Which matters more to you?
To access data in a Rambus module, the request must pass through all modules in sequence up to the module that has the data and then must pass back through those modules to deliver the data to the northbridge. This is, BTW, why continuity RIMMs are required. As one can derive, this greatly increases latency as the number of modules increases. Servers, being systems that generally have lots of RAM, often have at least 8 modules available. Due to this increased latency as a function of the number of modules (and other factors), Rambus is therefore poor memory for servers. Note that this is per channel, meaning a dual channel Rambus system with eight modules has the memory latency of a four module system because the modules are split between the Rambus channels.
Sometimes amazing what certain groups/companies will try to get away with, sometimes even being fairly sure that they will fail. If you try to get away with 100 absurd ideas, like certain patents for example, if even one or two of them fall through the cracks it ends up being worth it. "I Think ICANN, I think ICANN." (yes, I know, that was horrible)
Not exactly scientific.;-) Those could be people finding a bug (which isn't necessarily a security bug" and asking "Does Windows have a bug like this OpenBSD bug?" Possible, but unlikely.
Here the code copies the input string to the destination, regardless of what size the input string is.
if (strlen(dest) => MAXLEN) {}
Here the code checks to see if the input data is larger than the buffer that it is being copied to, which is great and all except that it is being done AFTER the cpy took place. It's like drinking a bottle of clear liquid in a chemistry lab and THEN checking the label to see if it's sulfuric acid. I'm no C expert either, so I may have missed something.
It isn't paranoia if these companies really are trying to 'take over the world', but still, I think that Mr. Barlow could have chosen some more conservative wording to avoid looking like a member of the archetype "paranoid anticorporate radicalist." Hopefully his many, many accomplishments and reputation will help the more skeptical to realize that there is some real meat to what is being said.
An Echostar/DTV merger would allow satellite to compete better with cable, and would allow more people the ability to get SatTV (If you don't have a place on your house to mound a south-facing dish, you're SOL with DirecTV) because Echostar uses a satellite array with very different placing. Echostar owns Dish Network for those who do not know. The add'l capacity, if not used for increasing customer base, could be used for extra bandwidth for HDTV channels and such (which DirecTV is lacking in terribly--they have like two total) I'm not so sure how feasible it is, though, as they use completely different equipment and even a completely different business model for equipment. Echostar makes almost all of theirs (even DVR units, i.e. they make tivo clones) while DirecTV relies on such companies as RCA, Sony, Panasonic, and their own parent Hughes Networks to make equipment. Oddly, despite Echostar having about half the customers of DTV, they have more money, possibly because of the equipment sales. They also have very different business models, especially now with recent changes in DTV. DTV will basically kiss the customer's butt to keep them around whereas Echostar seems to make insane offers to grab them, then kindof leaves them hanging after that. Echostar has the advantage that their equipment doesn't suck, whereas some manufacturers (most noteably Panasonic and Sony) make real crap for DTV. In short, the merger would be chaos but would probably be a good thing--ironically the larger company would be good BECAUSE it could fight other, larger companies. They need this--remember, DirecTV owns no channels of their own. They have to pay their competition royalties to show programming (CNN, CABLE news network, on satellite. Heh.) so being bigger could definitely help them keep AT&T, Comcast, Cox and AOLTW in check.
"First off, it's quite easy to see that the dual Athlon MP setup simply rules the roost when it comes to raw CPU performance. Even with the Athlon MP chips at 1.6 GHz, it's easily able to outpace the dual Xeon 2.0 GHz processors, with or without Hyperthreading enabled. Even the highest performing Xeon setup still trails the dual Athlon MP 1900+ by roughly 30%."
As an owner of an SMP system, I can say with confidence that even having two/real/ processors, which is better than one hyperthreading processor, isn't of any great benefit to Windows users anyway (see comments above about HT on Win2K) other than for servers (shudder) and for running several very CPU intensive apps at once, which very few people do. In *nix, however, I have improved my buildworld times for thirty percent. *That's* useful.
Apache 2.0 is quite a bit like Linux 1.0 and, to a lesser degree, Linux 2.4. It keeps getting closer and closer--so amazingly close--but it never seems to actually be final. It gets tweaked and patched and asymptotically approaches 2.0, but doesn't seem to get there. I'm not bashing the Apache developers, quite the opposite as I am very happy that they are absolutely not releasing it until it is ready--and we all know (I hope) that Linux 1.0 was eventually released. And 2.4. If only some other server apps used were put under such intense scrutiny before release.
As much as I like Slackware (It and Debian are the only Linux distros that I can stand), the reason distros like RH are so popular in servers is because of their tools. When you need to fix a problem "REALQUICK" or need to setup several servers each with a different configuration, it is often quite handy to have such tools.
For those who do not know where to look for every needed option, they are quite handy for configuring now and figuring out later (when needed)
While I definitely agree that manually editing the text files is, in the long run, better--sometimes time constraints make it impractical for all but the most knowledgeable Linux admins. Which I am not.:-)
My mother uses SuSE 7.2. I switched the video card from a Matrox G200 to a G400 and SuSE didn't so much as mention it. It just worked, immediately. (upon reboot, of course)
It may not have better or equal hardware detection compared to RH (I don't know, I don't use RH. Or Linux for that matter) but its hardware detection is there and seems to work pretty well in my experience.
My preferred OS FreeBSD, OTOH, could definitely use some work in the automatic hardware detection front.
Re:Job hunting is a full-time job
on
The Laid-off Techie
·
· Score: 3, Funny
You are quite good at peacekeeping and preventing situations from elevating--by keeping a cool head. Excellent qualities for a suit.
-Joe Random Slashdot user
(Please don't OT this post, just wanted to encourage intelligent posting)
Thankyou for this info, you and the previous post. I was not aware of that. Open source software moves so damn fast, it's all but impossible to keep up. Maybe that's why many people prefer the Windows world. They know that they'll have at least a month before worrying about the patch to fix the latest bug.:-)
However, Yahoo is not a typical business. As the Yahoo article says, "Finance managed its database needs through homegrown flat files and Berkeley DB databases. But those solutions proved to be inflexible and not scalable enough for their needs..."
Homebrew flat files will be wooped by any decent DB server, especially a blazing fast one like MySQL, any day of the week. Yahoo also tends to embrace open source and new technologies more readily. Most of their servers, for example, run FreeBSD and have since the beginning.
This is a slightly bad example considering that FreeBSD is unquestionably a product that you can trust your mission critical data to, but it illustrates to a degree the type of company that Yahoo is.
I, myself, would trust MySQL with anything that didn't matter to someone else. In the end--it's politics, and "nobody ever got fired for using an ACID compliant database.";-)
PostgreSQL is an ACID compliant database. MySQL is not (unless that has changed recently--if so please let me know).
ACID (an acronymn for Atomicity Consistency Isolation Durability) is a 'keyword' that business professionals generally look for when evaluating databases. Frankly, non-ACID databases aren't taken very seriously, even if they are used by the likes of Yahoo and Slashdot (like MySQL is).
Here is a quick description of what it means to be ACID compliant:
1. Atomicity is an all-or-none proposition. Suppose you define a transaction that contains an UPDATE, an INSERT, and a DELETE statement. With atomicity, these statements are treated as a single unit, and thanks to consistency (the C in ACID) there are only two possible outcomes: either they all change the database or none of them do. This is important in situations like bank transactions where transferring money between accounts could result in disaster if the server were to go down after a DELETE statement but before the corresponding INSERT statement.
2. Consistency guarantees that a transaction never leaves your database in a half-finished state. If one part of the transaction fails, all of the pending changes are rolled back, leaving the database as it was before you initiated the transaction. For instance, when you delete a customer record, you should also delete all of that customer's records from associated tables (such as invoices and line items). A properly configured database wouldn't let you delete the customer record, if that meant leaving its invoices, and other associated records stranded.
3. Isolation keeps transactions separated from each other until they're finished. Transaction isolation is generally configurable in a variety of modes. For example, in one mode, a transaction blocks until the other transaction finishes. In a different mode, a transaction sees obsolete data (from the state the database was in before the previous transaction started). Suppose a user deletes a customer, and before the customer's invoices are deleted, a second user updates one of those invoices. In a blocking transaction scenario, the second user would have to wait for the first user's deletions to complete before issuing the update. The second user would then find out that the customer had been deleted, which is much better than losing changes without knowing about it.
4. Durability guarantees that the database will keep track of pending changes in such a way that the server can recover from an abnormal termination. Hence, even if the database server is unplugged in the middle of a transaction, it will return to a consistent state when it's restarted. The database handles this by storing uncommitted transactions in a transaction log. By virtue of consistency (explained above), a partially completed transaction won't be written to the database in the event of an abnormal termination. However, when the database is restarted after such a termination, it examines the transaction log for completed transactions that had not been committed, and applies them.
It is difficult to trust mission critical data to a database that does not guarantee that it will complete not screw up (short of a bug, of course), this such compliance--even when it is more political than technical--is very important.
HDD reader heads hover above the platters at about 1/50 the width of a human hair. If one spectral of dust lands on the platter and gets in-between the head and the platter, that could be bad. As Taco said, "That ladies and gentlemen, takes balls."
Mozilla has been in beta, where developers traditionally work on features and bugfixes, and performance isn't even an afterthought.
They are just now beginning to work on performance, and they are doing a pretty good job if you read the comments above hear, such as this comment by PlaysWithMatches:
"Everything in the GUI seems to be noticeably faster though, in 0.9.8. This alone makes it worth the upgrade.:)"
One can hope that its performance will improve at the same pace, but it is unlikely to ever be as fast as the minimalist Opera browser.
It is, however, open source and much more functional than Opera.
Slashdot Mirror
How come so many people rant and rant about how clockspeed isn't everything, then they go and use the same argument in a different way to establish the "clear superiority" of the Athlon?
.13u version and it will likely leapfrom Intel, who will up the clockspeed again (and FSB) and leapfrog AMD, who will release the Hammer series... Ad infinitum.
That is exactly my point--people see these huge numbers but they do not translate to beter performance, hence, clockspeed isn't everything. Price/performance ratio is. For those who can buy without consideration of price, which is few of us indeed, AMD and Intel leapfrog each-other all the time. Right now, the 2.2GHz P4 is slightly faster overall thanthe Athlon XP 2000+. AMD will release the
"Essentially overclocked" Pentium 4? It's not a new Pentium 4 chip, it's a new motherboard. Of course it's an "essentially overclocked" Pentium 4. Why add in the negative connotations? Negative connotations weren't really intended per se, but the fact that a platform which has not been released is being compared to one that is available right now needed some good, strong contrast. Just in case. (I may be wrong, it's happened before no doubt)
I dunno, looking at these benchmarks I'd say the Pentium 4's architecture is damn fast. It's scaling up incredibly fast. Remember when it was first released and everybody called it a disaster? It is certainly scaling in clockspeed, but its inefficient design is holding it back in actual performance. Not its 8k L1 cache--the same size as that of a 486. Note its three execution units, only two of which can possibly be fed by the instruction scheduler at any one time. Note its use of FSB bandwidth being terribly inefficient, noteable in that the 3GHz P4 with a 100MHz bus *4 is slower than the 2.666GHz P4 with a 133MHz * 4 bus. The Athlon is still scaling almost linearly with its 133MHz * 2 bus. The P4's FSB timings need to be more exact (higher frequency devices dictate this) thus making the bus less scaleable--one reason that it was initially launched at 100MHz*4 instead of 133*4. The performance figures indicate that the P4 is very highly dependant on a huge amount of FSB bandwidth, and how that the FSB must scale almost linearly at a very early point to be able to keep up. I guess we'll see what happens when the P4 exceeds 3GHz and saturates its 133MHz bus. (Of course, Intel has some damn good engineers so they will surely think of something).
How many modules does this assume? As I said, "Similarly to a series electrical circuit, versus a parallel circuit, the data being requested from an RDRAM RIMM must pass through each and every one of a RIMM's chips. Likewise, when a second RIMM is added, the signal must pass not only through the first RIMM, but through each chip on the second RIMM as well. " Anyway, your quote does not conflict with mine in that it is likely assuming a single module. THink about it--Rambust IS a SERIAL technology. By definition, it cannot access in parallel, and each transaction must go through the same serial bus--hence--each chip. Quoting one website with information that actually agrees with my conclusion (but for different reasons) is not grounds to say that my statement is BS, particularly when it is not. As your sig says, a little knowledge is dangerous.
Of course a not-yet-released equivalent of an overclocked P4 is going to beat the competition vs. AMD's AthlonXP which is out and available NOW.
I would like to note that while the P4 did pounce the AthlonXP, take a look at the numbers (and i'm not talking about price, as I don't even want to know how much that P4 will cost!)
AthlonXP 2000+ runs at 1,666MHz at a bus which is the equivalent of 266MHz.
The P4 is running at 2666MHz (a full Gigahertz higher frequency) with a bus at the equivalent of 533MHz.
The (essentiually overclocked) Pentium 4 has a full SIXTY PERCENT CPU clockspeed advantage and a ONE HUNDRED PERCENT front side bus (FSB) advantage, yet look at its real-world performance:
MP3 encoding: 6.2% faster than the Athlon. (woop)
DivX encoding: 30% (note that the program is highly optimized, by Intel themselves, for the P4. How many programmers have an Intel engineer handy?)
Xinema 4D: 12.8%
3DMark 2001: 4.9%
Note that that Lightwave was not included--the only common test that runs faster on the P4 is the raytracing test. Guess which one Tom's Hardware used?
I just thought I'd point out that the only conclusion that you can really draw from these tests is that, as many in the hardware community know, the P4's architecture is designed for high clockspeed, with zero regard to actual real-world performance. Which matters more to you?
To access data in a Rambus module, the request must pass through all modules in sequence up to the module that has the data and then must pass back through those modules to deliver the data to the northbridge. This is, BTW, why continuity RIMMs are required.
As one can derive, this greatly increases latency as the number of modules increases. Servers, being systems that generally have lots of RAM, often have at least 8 modules available.
Due to this increased latency as a function of the number of modules (and other factors), Rambus is therefore poor memory for servers.
Note that this is per channel, meaning a dual channel Rambus system with eight modules has the memory latency of a four module system because the modules are split between the Rambus channels.
Sometimes amazing what certain groups/companies will try to get away with, sometimes even being fairly sure that they will fail. If you try to get away with 100 absurd ideas, like certain patents for example, if even one or two of them fall through the cracks it ends up being worth it.
"I Think ICANN, I think ICANN."
(yes, I know, that was horrible)
Not exactly scientific. ;-) Those could be people finding a bug (which isn't necessarily a security bug" and asking "Does Windows have a bug like this OpenBSD bug?"
Possible, but unlikely.
strcpy (dest, input); /***WHAM!***/
Here the code copies the input string to the destination, regardless of what size the input string is.
if (strlen(dest) => MAXLEN) {}
Here the code checks to see if the input data is larger than the buffer that it is being copied to, which is great and all except that it is being done AFTER the cpy took place. It's like drinking a bottle of clear liquid in a chemistry lab and THEN checking the label to see if it's sulfuric acid.
I'm no C expert either, so I may have missed something.
It isn't paranoia if these companies really are trying to 'take over the world', but still, I think that Mr. Barlow could have chosen some more conservative wording to avoid looking like a member of the archetype "paranoid anticorporate radicalist." Hopefully his many, many accomplishments and reputation will help the more skeptical to realize that there is some real meat to what is being said.
Japan is lit mor brightly than Las Vegas, or anywhere else in the word for that matter. Talk about population density.
An Echostar/DTV merger would allow satellite to compete better with cable, and would allow more people the ability to get SatTV (If you don't have a place on your house to mound a south-facing dish, you're SOL with DirecTV) because Echostar uses a satellite array with very different placing. Echostar owns Dish Network for those who do not know.
The add'l capacity, if not used for increasing customer base, could be used for extra bandwidth for HDTV channels and such (which DirecTV is lacking in terribly--they have like two total)
I'm not so sure how feasible it is, though, as they use completely different equipment and even a completely different business model for equipment. Echostar makes almost all of theirs (even DVR units, i.e. they make tivo clones) while DirecTV relies on such companies as RCA, Sony, Panasonic, and their own parent Hughes Networks to make equipment.
Oddly, despite Echostar having about half the customers of DTV, they have more money, possibly because of the equipment sales.
They also have very different business models, especially now with recent changes in DTV. DTV will basically kiss the customer's butt to keep them around whereas Echostar seems to make insane offers to grab them, then kindof leaves them hanging after that.
Echostar has the advantage that their equipment doesn't suck, whereas some manufacturers (most noteably Panasonic and Sony) make real crap for DTV.
In short, the merger would be chaos but would probably be a good thing--ironically the larger company would be good BECAUSE it could fight other, larger companies. They need this--remember, DirecTV owns no channels of their own. They have to pay their competition royalties to show programming (CNN, CABLE news network, on satellite. Heh.) so being bigger could definitely help them keep AT&T, Comcast, Cox and AOLTW in check.
"First off, it's quite easy to see that the dual Athlon MP setup simply rules the roost when it comes to raw CPU performance. Even with the Athlon MP chips at 1.6 GHz, it's easily able to outpace the dual Xeon 2.0 GHz processors, with or without Hyperthreading enabled. Even the highest performing Xeon setup still trails the dual Athlon MP 1900+ by roughly 30%."
DirecTV has only gone up once in the entire company history, and that was by $2.00 for all packages. Who needs cable?
As an owner of an SMP system, I can say with confidence that even having two /real/ processors, which is better than one hyperthreading processor, isn't of any great benefit to Windows users anyway (see comments above about HT on Win2K) other than for servers (shudder) and for running several very CPU intensive apps at once, which very few people do.
In *nix, however, I have improved my buildworld times for thirty percent. *That's* useful.
One can access Hotmail using MS Outlook Express.
Apache 2.0 is quite a bit like Linux 1.0 and, to a lesser degree, Linux 2.4.
It keeps getting closer and closer--so amazingly close--but it never seems to actually be final. It gets tweaked and patched and asymptotically approaches 2.0, but doesn't seem to get there.
I'm not bashing the Apache developers, quite the opposite as I am very happy that they are absolutely not releasing it until it is ready--and we all know (I hope) that Linux 1.0 was eventually released. And 2.4. If only some other server apps used were put under such intense scrutiny before release.
As much as I like Slackware (It and Debian are the only Linux distros that I can stand), the reason distros like RH are so popular in servers is because of their tools. When you need to fix a problem "REALQUICK" or need to setup several servers each with a different configuration, it is often quite handy to have such tools. :-)
For those who do not know where to look for every needed option, they are quite handy for configuring now and figuring out later (when needed)
While I definitely agree that manually editing the text files is, in the long run, better--sometimes time constraints make it impractical for all but the most knowledgeable Linux admins. Which I am not.
My mother uses SuSE 7.2. I switched the video card from a Matrox G200 to a G400 and SuSE didn't so much as mention it. It just worked, immediately. (upon reboot, of course)
It may not have better or equal hardware detection compared to RH (I don't know, I don't use RH. Or Linux for that matter) but its hardware detection is there and seems to work pretty well in my experience.
My preferred OS FreeBSD, OTOH, could definitely use some work in the automatic hardware detection front.
Wyould your last name be Shifman? ;-)
You are quite good at peacekeeping and preventing situations from elevating--by keeping a cool head. Excellent qualities for a suit.
-Joe Random Slashdot user
(Please don't OT this post, just wanted to encourage intelligent posting)
Ya, all sorts of horrible things happen to me when companies can't sell my personal information. :)
Thankyou for this info, you and the previous post. I was not aware of that. Open source software moves so damn fast, it's all but impossible to keep up. Maybe that's why many people prefer the Windows world. They know that they'll have at least a month before worrying about the patch to fix the latest bug. :-)
Fair enough.
;-)
However, Yahoo is not a typical business. As the Yahoo article says, "Finance managed its database needs through homegrown flat files and Berkeley DB databases. But those solutions proved to be inflexible and not scalable enough for their needs..."
Homebrew flat files will be wooped by any decent DB server, especially a blazing fast one like MySQL, any day of the week. Yahoo also tends to embrace open source and new technologies more readily. Most of their servers, for example, run FreeBSD and have since the beginning.
This is a slightly bad example considering that FreeBSD is unquestionably a product that you can trust your mission critical data to, but it illustrates to a degree the type of company that Yahoo is.
I, myself, would trust MySQL with anything that didn't matter to someone else. In the end--it's politics, and "nobody ever got fired for using an ACID compliant database."
PostgreSQL is an ACID compliant database. MySQL is not (unless that has changed recently--if so please let me know).
ACID (an acronymn for Atomicity Consistency Isolation Durability) is a 'keyword' that business professionals generally look for when evaluating databases. Frankly, non-ACID databases aren't taken very seriously, even if they are used by the likes of Yahoo and Slashdot (like MySQL is).
Here is a quick description of what it means to be ACID compliant:
1. Atomicity is an all-or-none proposition. Suppose you define a transaction that contains an UPDATE, an INSERT, and a DELETE statement. With atomicity, these statements are treated as a single unit, and thanks to consistency (the C in ACID) there are only two possible outcomes: either they all change the database or none of them do. This is important in situations like bank transactions where transferring money between accounts could result in disaster if the server were to go down after a DELETE statement but before the corresponding INSERT statement.
2. Consistency guarantees that a transaction never leaves your database in a half-finished state. If one part of the transaction fails, all of the pending changes are rolled back, leaving the database as it was before you initiated the transaction. For instance, when you delete a customer record, you should also delete all of that customer's records from associated tables (such as invoices and line items). A properly configured database wouldn't let you delete the customer record, if that meant leaving its invoices, and other associated records stranded.
3. Isolation keeps transactions separated from each other until they're finished. Transaction isolation is generally configurable in a variety of modes. For example, in one mode, a transaction blocks until the other transaction finishes. In a different mode, a transaction sees obsolete data (from the state the database was in before the previous transaction started). Suppose a user deletes a customer, and before the customer's invoices are deleted, a second user updates one of those invoices. In a blocking transaction scenario, the second user would have to wait for the first user's deletions to complete before issuing the update. The second user would then find out that the customer had been deleted, which is much better than losing changes without knowing about it.
4. Durability guarantees that the database will keep track of pending changes in such a way that the server can recover from an abnormal termination. Hence, even if the database server is unplugged in the middle of a transaction, it will return to a consistent state when it's restarted. The database handles this by storing uncommitted transactions in a transaction log. By virtue of consistency (explained above), a partially completed transaction won't be written to the database in the event of an abnormal termination. However, when the database is restarted after such a termination, it examines the transaction log for completed transactions that had not been committed, and applies them.
It is difficult to trust mission critical data to a database that does not guarantee that it will complete not screw up (short of a bug, of course), this such compliance--even when it is more political than technical--is very important.
HDD reader heads hover above the platters at about 1/50 the width of a human hair. If one spectral of dust lands on the platter and gets in-between the head and the platter, that could be bad. As Taco said, "That ladies and gentlemen, takes balls."
Mozilla has been in beta, where developers traditionally work on features and bugfixes, and performance isn't even an afterthought. :)"
They are just now beginning to work on performance, and they are doing a pretty good job if you read the comments above hear, such as this comment by PlaysWithMatches:
"Everything in the GUI seems to be noticeably faster though, in 0.9.8. This alone makes it worth the upgrade.
One can hope that its performance will improve at the same pace, but it is unlikely to ever be as fast as the minimalist Opera browser.
It is, however, open source and much more functional than Opera.