...except for the minor detail that 65535 is 0xFFFF...:-)
That said, my 32-bit print routine for a 16-bit CPU actually works by printing two 16 bit numbers, with a slight hack to the 16-bit routine to allow it to print numbers in the range 65536 - 99999 for the lower 5 digits. It does this by dividing the 32-bit number by, you guessed it, 100000. It then prints the quotient and the remainder. It has to do some extra legwork, though, to get the leading zeros right across the two words, and I think it's there that the code went south if they're using a technique similar to mine.
I'm guessing what happened here is that there's an off-by-1 error in a comparison somewhere (i.e. ">= 65535" instead of "> 65535"), and the 32-bit quotient/remainder print routine kicks in. Since the number is already smaller than 100000, it probably hits a fall-thru case where the quotient is assumed to be 1, and there's no remainder, hence it printing 100000.
That actually makes some amount of sense, then. Otherwise, whoever has the most expensive lawyers puts up even a larger barrier to being sued, as so many others have pointed out.
I guess if you just want to weed out frivolous lawsuits, you could go halfway to a plaintiff-pays-if-he-loses type of system.
If I were ever to steal a laptop, the first thing I'd do is take out the HD. Slap the HD in another system as a secondary, so I could scan it for sensitive information (CC#'s, usernames, passwords), and then blast the drive with a squeaky clean install image. I'd do all of this before I even turned the laptop on for the first time. If I were really thinking, I'd probably also take out the laptop batteries until I was ready to flip it.
So how does your boot loader work with that attack vector?
It is extremely difficult and next to pointless to write code that is strictly conforming. It is in fact quite useful, for instance, to use unions to re-interpret bit patterns. (Note that "portable" is something rather different than "strictly conforming," or even "conforming." Many non-conforming programs are still highly portable because of commonalities among implementations.)
For example, suppose you want to bit-reverse an entire array in memory. That is, bit 0 of the first element in the array swaps locations with bit N-1 of the last element of the array, bit 1 swaps locations with bit N-2, etc., all the way down to the middle of the array. How would you implement that as a strictly conforming ANSI C program? It turns out to be rather difficult to do correctly. (Why would you want to? Well, it's a handy way to flip bitmaps for one thing.)
First, you have to know how many bits are in each unsigned char. There could be from 8 to who-knows-how-many bits in an unsigned char. (Yes, 256-bit unsigned char are legal in ANSI C, as long as there's at least as many bits in a short int, int, long int and long long int.) So, you can't rely on any fast, cute implementations such as this ever-popular word-reversal routine:
That code is implementation defined. It cannot be part of a strictly conforming program. It can be part of a conforming program, though it only works as expected on machines whose unsigned int is 32 bits. (That happens to be over 90% of the PCs and *NIX boxes people work with these days, but that wasn't true as recently as 10 years ago.)
What about other undefined things? Well, sometimes an implementation defines them usefully. For example, consider this bit of code:
union { unsigned int word; unsigned char bytes[4]; } foo;
This is useful code. Chances are nearly every compiler you meet (at least, which offers 32-bit ints) will handle this correctly and tell you the endianness of the machine. That means it's reasonably portable. It also happens to be quite undefined.
Sure, it fails miserably on oddball machines with non-standard word sizes, but most programs only care to be portable amongst the vast majority of machines that have 8-bit char, 16-bit short, 32-bit int. (This is part of the reason why LP64 machines are more popular than ILP64 machines.)
In general, compilers implement a superset of the standard by providing reasonable semantics to expressions that the standard leaves undefined. For instance, on most compilers, signed arithmetic wraps around the same as unsigned arithmetic, and the values you get are exactly what you'd expect from 2s complement arithmetic, despite the fact that the standard leaves those results undefined. Heck, until the adoption of C9x, C++ style comments were not technically legal in C programs, but most compilers accepted them.
You might call that a quality of implementation issue.:-)
That said, my point still stands, and in fact is bolstered: Just because the C standard leaves it undefined doesn't stop compiler writers from giving the situation a useful definition. The resulting language is a superset of C, though, and is thus compiler specific. A program which relies on this variant of C is non-conforming.
I guess the beef here is that "implementation defined" means a program could be conforming but not strictly conforming if it relied on implementation defined behavior, eh?
while the person you're responding to *is* a troll, I guess it's worth pointing out that GCC and other highly optimizing compilers will "break" some apps that a simpler compiler won't break. Why?
Many optimizations rely on careful reading of the standard, and explicitly taking the liberties that the standard lets you take. For instance, the following loop terminates on a simple compiler, but becomes infinite on some optimizing compilers:
int i = 1;
while (i > 0)
. . . i = i * 2;
The ANSI C standard states specifically that signed integer overflow behavior is implementation defined. If you were expecting 'i' to go negative after 30 iterations, and for that to terminate the loop, you could be in for a nasty surprise.
Suppose an application relied on this behavior, and now it misbehaves when compiled with GCC. Did GCC "break" that application? In some sense, yes: The app functions correctly with compiler (a) but not with compiler (b), so the app must be compiled with compiler (a). The breakage, however, happened because the application its not strictly conforming. It uses compiler dependent semantics, and that's hardly GCC's fault.
Simpler compilers also don't reorder code as much, and don't optimize away as much "dead code." Stuff that really should have memory barriers, explicit synchronization and perhaps the volatile keyword applied to them run just fine without all those things when compiled with a simple compiler and run on a scalar, in-order CPU. The source code is also easier to read, because in the end the semantics are much more restricted--meaning the compiled output more closely resembles the source input. Give that code to a highly optimizing compiler, though, and run it on a super-scalar, out-of-order machine, and it'll break left, right and center. Is it the compiler's fault? Is it the CPU's fault? It's really the gap between the semantics the programmer thought he had (and happened to have in the simpler environment), and what C actually guarantees.
Simpler compilers implement simpler semantics that are easier to understand, but only because they're compiling a very restricted form of C that offers way more implicit guarantees than the C standard actually does. Personally, unless that's made explicit (and therefore truly guaranteed forevermore by the compiler), I suspect it's actually
a recipe for disaster. If nothing else, it could lead to code that's significantly harder to move to different platforms, since it'll start to rely on these simpler, "easier" semantics. Of course, then again, super-scalar out-of-order CPUs still strip a bunch of that away, so who knows, it might not be that bad.
Even if it were cable, all that means is U-verse needs to provide a digital-to-analog RF modulator at the home. Those have been around for 30 years or so, as some of you who had "home computers" in the 80s might remember. (Hint: Those were digital, but somehow managed to display on an analog screen.)
"Bu..bu..bu..but the source is analog?!" I hear some gasp. So? Films (you know, the kind shot on actual 35mm or 70mm film stock) are analog too... And yet you somehow watch them on your DVD player, quite commonly on an analog TV up until the last couple years. (Hint: DVD stands for Digital Versatile Disc.)
Repeat after me: Just because you gotta carry the local channels and adapt to older endpoints doesn't mean your infrastructure in the middle has to suffer.
This is not entirely true. Although I agree overall with what you're saying, core logic transistors scale much worse than cache as the manufacturing process decreases in size.
Fair enough. That said, it's not the transistors so much as it is the wires that don't scale well. I'll warn you: I'm not a physical designer, I'm just an architect. The one and only cookie I directly designed and baked was in 2 micron. That said, I'm aware of the trends.
There could be a couple reasons AMD throws more logic at the problem than RAM:
At an older technology node, the optimal RAM/logic split may be different.
Their RAM technology may be more susceptible to defects (e.g. less redundancy).
They favor shorter latencies over higher overall capacity.
Related to the previous bullet: They may have higher latency for the same capacity (although their large L1s tend to suggest otherwise).
Indeed, the latency argument is probably the most interesting one. It's seemed to me that the biggest advantage AMD has held over Intel in the previous generation was due to keeping latencies down. The generous L1s, the exclusive cache protocol (where L2 is essentially a ginormous victim buffer and misses allocate directly in L1), and the integrated memory controller are all focused on latency. Lower latencies == more instructions issuing together == more instruction level parallelism. And in branchy code, it means less time branch-to-branch.
Pentium 4 was focused on throughput and bandwidth, and lost on pointer chasing and branching. Huge L2 line sizes, and the high-bandwidth, high-latency RDRAM interface... all that focused on streaming, not on more general workloads. It killed them on the bread and butter generic stuff. Intel finally woke up to that when it shifted over to Pentium M from Pentium 4, and you can see how well they learned by the time you get to Core 2.
Fair enough, but in terms of dollars of revenue per wafer, though, the relative cost of a given defect is generally smaller on a 45nm wafer than a 65nm wafer if the 45nm design is roughly 1/2 the size of the 65nm design. You've taken out a smaller percentage of the devices on the wafer. Note that I say "relative cost." 45nm wafers are still more expensive than 65nm wafers.:-)
Also, with a RAM-heavy design, you can build significant redundancy into your RAM arrays and perform RAM repair (remap columns or rows) to buy back some yield. Thus, you have yet another bulwark against these defects. As asliarun pointed out, Intel favors RAM heavy designs. This could be part of the reason.
It'll be interesting to see how this all plays out. Right now Intel probably does have to eat a bit more cost on the 45nm process as it matures. The raw cost per wafer is probably higher, and the yields not as good, just as a function of immature process. But, that's a relatively fixed expense that will be amortized over the 100s of millions of x86s they'll pump out, so the actual cost per device over the lifetime of that design will be minimal. They've got the volume to support it. Developing a process isn't cheap though. Even my employer, TI, is going to outside foundries for its high speed 45nm logic process.
This is a direct reference to 65nm vs. 45nm geometry. If AMD brings their quad core to a 45nm process, that should help yield, power and performance. If nothing else, it puts them on a level playing field with Intel (who already have product at 45nm) so that it's down to "design vs. design." Being stuck one silicon technology generation back, they need to resort to other tricks to "keep up."
In other words, to be at overall performance parity with Intel, they have to have a more advanced design in 65nm to keep up with Intel's 45nm work.
Another thing worth noting: By being 1 generation back, the quad core setup is a double whammy. The die area of a given chip roughly halves with each technology node. Not only is AMD putting twice as much on one chip, it's also making chips that are twice the size per transistor. (Remember, to double square area, you only increase your linear feature size by sqrt(2). 65/45 = 1.444... which is about sqrt(2).) Each additional sq mm of die area causes greater yield loss than the one before it (driven by defect density in the source silicon). Doubling die size has a huge impact on yield. So, AMD will potentially suffer significantly higher yield loss, and correspondingly higher costs. Even if it can keep its ASP (average selling price) up, the profit margins will suck.
It'll be interesting to see if AMD can quickly shrink this design to 45nm and get closer to parity. The benefits of the quad core design probably become much more apparent at 45nm.
Not really. The more time sources you have, the more precise your estimate of the time will be, since you'll be able to cancel out disparate network jitter better.
Ok, they got the signal, but did they understand what it said? Like as not the decoding software is what runs on that ancient computer the article referred to.
It's probably some crummy old FORTRAN-66 or BLISS code running on an ancient PDP.
You can't ignore air resistance, since it's a much larger force than gravitational acceleration at these speeds. So, sure, the gravitational acceleration seen by two comparable chunks (one foam, one ice) will be pretty much the same, but it's far from the dominant term. In the context of ice and/or foam falling off the orbiter's fuel tanks, the foam develops a high velocity relative to the orbiter much more quickly than ice, because the ice accelerates much more slowly given the same force due to its greater mass.
I count "glancing at the status bar" as "checking my email," personally. I use Mutt for my work email, and Yahoo/GMail for the rest. I'm continually glancing over at the title bars for my Yahoo and GMail windows, and at my Mutt display. Just because you don't have to manually click "reload" doesn't mean it doesn't count as "checking."
Oh, and only 40 times an hour? What rank amateurs! I think I must check mine every 15-20 seconds!
Right, but if the wrong 2 drives fail, you're hosed. You can lose up to N drives (out of a 2*N array) only if you lose 1 drive from each mirror pair. It's possible to hose a RAID 10 array of any size by losing just two drives if they're the two drives that mirror each other.
That's exactly right, because Apple had absolutely no choice of which carrier to go with, nor did it have any influence on that carriers policies with respect to its phone. And I'm never sarcastic.
I thought the iPhone came with "the Internet." You know, not the kinda-sorta Internet, or maybe a little Internet, but, you know, the Internet.
Are you saying that with an unlimited data plan and access to the Internet from the phone itself, the customer might not be able to get to their online bill for lack ofa network connection?
Slashdot Mirror
...except for the minor detail that 65535 is 0xFFFF... :-)
That said, my 32-bit print routine for a 16-bit CPU actually works by printing two 16 bit numbers, with a slight hack to the 16-bit routine to allow it to print numbers in the range 65536 - 99999 for the lower 5 digits. It does this by dividing the 32-bit number by, you guessed it, 100000. It then prints the quotient and the remainder. It has to do some extra legwork, though, to get the leading zeros right across the two words, and I think it's there that the code went south if they're using a technique similar to mine.
I'm guessing what happened here is that there's an off-by-1 error in a comparison somewhere (i.e. ">= 65535" instead of "> 65535"), and the 32-bit quotient/remainder print routine kicks in. Since the number is already smaller than 100000, it probably hits a fall-thru case where the quotient is assumed to be 1, and there's no remainder, hence it printing 100000.
For reference, here's that assembly code I mentioned: prnum32.asm and prnum16.asm
--JoeI know I am not "most users."
$ ps guxww | grep firefox-bin | grep -v grep /usr/lib/firefox/firefox-bin
im14u2c 27191 6.3 13.0 991708 528428 ? Sl Sep09 1381:29
$ uptime
19:03:15 up 86 days, 59 min, 11 users, load average: 0.08, 0.06, 0.01
But, then, I have the RAM for it. I just restart Firefox when it crashes. *shrug* Hell, GAIM needs to go on a diet:
$ ps guxww | grep gaim | grep -v grep
im14u2c 24132 0.0 1.1 650712 46492 ? Sl Sep09 1:01 gaim
650MB for a chat client? Makes Firefox look positively svelt!
--Joe
That actually makes some amount of sense, then. Otherwise, whoever has the most expensive lawyers puts up even a larger barrier to being sued, as so many others have pointed out.
I guess if you just want to weed out frivolous lawsuits, you could go halfway to a plaintiff-pays-if-he-loses type of system.
--JoeYou might check out the Boehm GC.
Those places always seemed kinda fishy...
If I were ever to steal a laptop, the first thing I'd do is take out the HD. Slap the HD in another system as a secondary, so I could scan it for sensitive information (CC#'s, usernames, passwords), and then blast the drive with a squeaky clean install image. I'd do all of this before I even turned the laptop on for the first time. If I were really thinking, I'd probably also take out the laptop batteries until I was ready to flip it.
So how does your boot loader work with that attack vector?
--JoeIt is extremely difficult and next to pointless to write code that is strictly conforming. It is in fact quite useful, for instance, to use unions to re-interpret bit patterns. (Note that "portable" is something rather different than "strictly conforming," or even "conforming." Many non-conforming programs are still highly portable because of commonalities among implementations.)
For example, suppose you want to bit-reverse an entire array in memory. That is, bit 0 of the first element in the array swaps locations with bit N-1 of the last element of the array, bit 1 swaps locations with bit N-2, etc., all the way down to the middle of the array. How would you implement that as a strictly conforming ANSI C program? It turns out to be rather difficult to do correctly. (Why would you want to? Well, it's a handy way to flip bitmaps for one thing.)
First, you have to know how many bits are in each unsigned char. There could be from 8 to who-knows-how-many bits in an unsigned char. (Yes, 256-bit unsigned char are legal in ANSI C, as long as there's at least as many bits in a short int, int, long int and long long int.) So, you can't rely on any fast, cute implementations such as this ever-popular word-reversal routine:
That code is implementation defined. It cannot be part of a strictly conforming program. It can be part of a conforming program, though it only works as expected on machines whose unsigned int is 32 bits. (That happens to be over 90% of the PCs and *NIX boxes people work with these days, but that wasn't true as recently as 10 years ago.)
What about other undefined things? Well, sometimes an implementation defines them usefully. For example, consider this bit of code:
This is useful code. Chances are nearly every compiler you meet (at least, which offers 32-bit ints) will handle this correctly and tell you the endianness of the machine. That means it's reasonably portable. It also happens to be quite undefined.
Sure, it fails miserably on oddball machines with non-standard word sizes, but most programs only care to be portable amongst the vast majority of machines that have 8-bit char, 16-bit short, 32-bit int. (This is part of the reason why LP64 machines are more popular than ILP64 machines.)
In general, compilers implement a superset of the standard by providing reasonable semantics to expressions that the standard leaves undefined. For instance, on most compilers, signed arithmetic wraps around the same as unsigned arithmetic, and the values you get are exactly what you'd expect from 2s complement arithmetic, despite the fact that the standard leaves those results undefined. Heck, until the adoption of C9x, C++ style comments were not technically legal in C programs, but most compilers accepted them.
--JoeYou might call that a quality of implementation issue. :-)
That said, my point still stands, and in fact is bolstered: Just because the C standard leaves it undefined doesn't stop compiler writers from giving the situation a useful definition. The resulting language is a superset of C, though, and is thus compiler specific. A program which relies on this variant of C is non-conforming.
I guess the beef here is that "implementation defined" means a program could be conforming but not strictly conforming if it relied on implementation defined behavior, eh?
--Joewhile the person you're responding to *is* a troll, I guess it's worth pointing out that GCC and other highly optimizing compilers will "break" some apps that a simpler compiler won't break. Why?
Many optimizations rely on careful reading of the standard, and explicitly taking the liberties that the standard lets you take. For instance, the following loop terminates on a simple compiler, but becomes infinite on some optimizing compilers:
int i = 1;
while (i > 0)
. . . i = i * 2;
The ANSI C standard states specifically that signed integer overflow behavior is implementation defined. If you were expecting 'i' to go negative after 30 iterations, and for that to terminate the loop, you could be in for a nasty surprise.
Suppose an application relied on this behavior, and now it misbehaves when compiled with GCC. Did GCC "break" that application? In some sense, yes: The app functions correctly with compiler (a) but not with compiler (b), so the app must be compiled with compiler (a). The breakage, however, happened because the application its not strictly conforming. It uses compiler dependent semantics, and that's hardly GCC's fault.
Simpler compilers also don't reorder code as much, and don't optimize away as much "dead code." Stuff that really should have memory barriers, explicit synchronization and perhaps the volatile keyword applied to them run just fine without all those things when compiled with a simple compiler and run on a scalar, in-order CPU. The source code is also easier to read, because in the end the semantics are much more restricted--meaning the compiled output more closely resembles the source input. Give that code to a highly optimizing compiler, though, and run it on a super-scalar, out-of-order machine, and it'll break left, right and center. Is it the compiler's fault? Is it the CPU's fault? It's really the gap between the semantics the programmer thought he had (and happened to have in the simpler environment), and what C actually guarantees.
Simpler compilers implement simpler semantics that are easier to understand, but only because they're compiling a very restricted form of C that offers way more implicit guarantees than the C standard actually does. Personally, unless that's made explicit (and therefore truly guaranteed forevermore by the compiler), I suspect it's actually a recipe for disaster. If nothing else, it could lead to code that's significantly harder to move to different platforms, since it'll start to rely on these simpler, "easier" semantics. Of course, then again, super-scalar out-of-order CPUs still strip a bunch of that away, so who knows, it might not be that bad.
--JoeI'd lay money on "10x if compiled with GCC" and "5x if compiled with PCC". ;-)
The article says he achieved thrust of 35 uN. 35 micro Newtons? That's a lot of "up" to scale into.
Even if it were cable, all that means is U-verse needs to provide a digital-to-analog RF modulator at the home. Those have been around for 30 years or so, as some of you who had "home computers" in the 80s might remember. (Hint: Those were digital, but somehow managed to display on an analog screen.)
"Bu..bu..bu..but the source is analog?!" I hear some gasp. So? Films (you know, the kind shot on actual 35mm or 70mm film stock) are analog too... And yet you somehow watch them on your DVD player, quite commonly on an analog TV up until the last couple years. (Hint: DVD stands for Digital Versatile Disc.)
Repeat after me: Just because you gotta carry the local channels and adapt to older endpoints doesn't mean your infrastructure in the middle has to suffer.
--JoeFair enough. That said, it's not the transistors so much as it is the wires that don't scale well. I'll warn you: I'm not a physical designer, I'm just an architect. The one and only cookie I directly designed and baked was in 2 micron. That said, I'm aware of the trends.
There could be a couple reasons AMD throws more logic at the problem than RAM:
Indeed, the latency argument is probably the most interesting one. It's seemed to me that the biggest advantage AMD has held over Intel in the previous generation was due to keeping latencies down. The generous L1s, the exclusive cache protocol (where L2 is essentially a ginormous victim buffer and misses allocate directly in L1), and the integrated memory controller are all focused on latency. Lower latencies == more instructions issuing together == more instruction level parallelism. And in branchy code, it means less time branch-to-branch.
Pentium 4 was focused on throughput and bandwidth, and lost on pointer chasing and branching. Huge L2 line sizes, and the high-bandwidth, high-latency RDRAM interface... all that focused on streaming, not on more general workloads. It killed them on the bread and butter generic stuff. Intel finally woke up to that when it shifted over to Pentium M from Pentium 4, and you can see how well they learned by the time you get to Core 2.
Bust out the popcorn, this'll be fun to watch. :-)
--JoeFair enough, but in terms of dollars of revenue per wafer, though, the relative cost of a given defect is generally smaller on a 45nm wafer than a 65nm wafer if the 45nm design is roughly 1/2 the size of the 65nm design. You've taken out a smaller percentage of the devices on the wafer. Note that I say "relative cost." 45nm wafers are still more expensive than 65nm wafers. :-)
Also, with a RAM-heavy design, you can build significant redundancy into your RAM arrays and perform RAM repair (remap columns or rows) to buy back some yield. Thus, you have yet another bulwark against these defects. As asliarun pointed out, Intel favors RAM heavy designs. This could be part of the reason.
It'll be interesting to see how this all plays out. Right now Intel probably does have to eat a bit more cost on the 45nm process as it matures. The raw cost per wafer is probably higher, and the yields not as good, just as a function of immature process. But, that's a relatively fixed expense that will be amortized over the 100s of millions of x86s they'll pump out, so the actual cost per device over the lifetime of that design will be minimal. They've got the volume to support it. Developing a process isn't cheap though. Even my employer, TI, is going to outside foundries for its high speed 45nm logic process.
That could help with leakage power, but that doesn't address the yield and cost issues at all.
This is a direct reference to 65nm vs. 45nm geometry. If AMD brings their quad core to a 45nm process, that should help yield, power and performance. If nothing else, it puts them on a level playing field with Intel (who already have product at 45nm) so that it's down to "design vs. design." Being stuck one silicon technology generation back, they need to resort to other tricks to "keep up."
In other words, to be at overall performance parity with Intel, they have to have a more advanced design in 65nm to keep up with Intel's 45nm work.
Another thing worth noting: By being 1 generation back, the quad core setup is a double whammy. The die area of a given chip roughly halves with each technology node. Not only is AMD putting twice as much on one chip, it's also making chips that are twice the size per transistor. (Remember, to double square area, you only increase your linear feature size by sqrt(2). 65/45 = 1.444... which is about sqrt(2).) Each additional sq mm of die area causes greater yield loss than the one before it (driven by defect density in the source silicon). Doubling die size has a huge impact on yield. So, AMD will potentially suffer significantly higher yield loss, and correspondingly higher costs. Even if it can keep its ASP (average selling price) up, the profit margins will suck.
It'll be interesting to see if AMD can quickly shrink this design to 45nm and get closer to parity. The benefits of the quad core design probably become much more apparent at 45nm.
--JoeNot really. The more time sources you have, the more precise your estimate of the time will be, since you'll be able to cancel out disparate network jitter better.
--Joe"Last" as in "most recent", not "last" as in "ultimate" or "final."
Let me guess. Your approach to debugging is to write bug free code, and your keyboard doesn't even have a backspace key.
;-)
Ok, they got the signal, but did they understand what it said? Like as not the decoding software is what runs on that ancient computer the article referred to.
It's probably some crummy old FORTRAN-66 or BLISS code running on an ancient PDP.
--JoeDon't forget Newton's Second Law: F=ma. It has strong implications on what happens when there's aerodynamic drag.
Air resistance is a force that's proportional to terms like drag coefficient, cross sectional area, and (the square of) relative velocity. It is not dependent on mass. Two objects that have the same profile, drag coefficient and so on will experience the same amount of force due to air resistance. Because they see the same amount of force, the one with less mass will experience more acceleration.
You can't ignore air resistance, since it's a much larger force than gravitational acceleration at these speeds. So, sure, the gravitational acceleration seen by two comparable chunks (one foam, one ice) will be pretty much the same, but it's far from the dominant term. In the context of ice and/or foam falling off the orbiter's fuel tanks, the foam develops a high velocity relative to the orbiter much more quickly than ice, because the ice accelerates much more slowly given the same force due to its greater mass.
--JoeI count "glancing at the status bar" as "checking my email," personally. I use Mutt for my work email, and Yahoo/GMail for the rest. I'm continually glancing over at the title bars for my Yahoo and GMail windows, and at my Mutt display. Just because you don't have to manually click "reload" doesn't mean it doesn't count as "checking."
Oh, and only 40 times an hour? What rank amateurs! I think I must check mine every 15-20 seconds!
--JoeRight, but if the wrong 2 drives fail, you're hosed. You can lose up to N drives (out of a 2*N array) only if you lose 1 drive from each mirror pair. It's possible to hose a RAID 10 array of any size by losing just two drives if they're the two drives that mirror each other.
That's exactly right, because Apple had absolutely no choice of which carrier to go with, nor did it have any influence on that carriers policies with respect to its phone. And I'm never sarcastic.
I thought the iPhone came with "the Internet." You know, not the kinda-sorta Internet, or maybe a little Internet, but, you know, the Internet.
Are you saying that with an unlimited data plan and access to the Internet from the phone itself, the customer might not be able to get to their online bill for lack ofa network connection?
--Joe