RAID is not a very good failover system. It never was, and it never will. Disks on raid often have extremely similar use patterns, leading to very similar drive life. When one drive in a RAID dies, it's not uncommon to see one or two more die at nearly the same time.
I rarely use the word "failover" that way but if you mean "fault-tolerant" then I'd rather like to see some objective data bearing your thesis out. I'd agree that many people assume RAID does more than it does but what you're saying stretches credibility - unless you are talking at either the far left or right side of the curve (not to mention you haven't defined 'not uncommon' - I'd assume you mean that you have a better chance than 1 in a few hundred or 'nearly the same time' which to me would imply 'faster than a service tech could reach the drive' i.e. 72 hrs). It seems more reasonable to assume that premature failure is the result of manufacturing weaknesses and outside of a batch problem will converge to some kind of normal distribution.
1) The figures I gave are rounded the exact figures make your conclusion difficult:
HWL Drive: 1.028 x 4.000 x 5.787
HWL Case: 6.22 x 4.88 x 1.73
Possible configurations of stacking two (with zero space between):
2.056 x 4.000 x 5.787
1.028 x 8.000 x 5.787
1.028 x 4.000 x 11.574
2) Considering that the measurements are all OUTER even if my original measurements were exactly right. It would still preclude placement of the drives. Since something that contains something needs to be at least slightly larger on the inside.
3) If you are stacking two drives together it isn't unreasonable to expect some space between the two for airflow.
What's interesting about your analysis - which turns out to be 100% wrong - ironically . Is that your conclusions weren't based simply on my stated figures - you had to also assume there was some error but you assumed the error was in your favor.
Perhaps so but the dichotomy of fast/slow drives has existed on the bare drive market for a while. I'm not discounting it being a 3TB drive and as seagate said in the other article they are planning on shipping the 3TB drives this year.
One thing it could be doing isn't utilizing "lower expectation" but rather "lower demand". If the USB market is, as I suspect significantly smaller than the bare drive market then it might be a good place to start shipping in order to ramp up production or even work out some bugs. To avoid the problems they had with their other groundbreaking drive the 1.5TB!
I'll comment on my own comment...one thing that is interesting is the physical dimensions of the box:
6 x 5 x 2
considering that seagates 3.5" drives are approximately:
1 x 4 x 6
Which seems to eliminate the possibility that this is two 3.5 drives. It could still be multiple 2.5" drives but without looking at pricing I'm not sure how feasible that is (and I don't think Seagate is shipping 1TB 2.5's yet)
Oh someone at engadget said so...well that can't be in error...
Anyway unless they opened it up or Seagate states somewhere on their web page that it is a single drive. It seems reasonable to remain skeptical. It seems weird that Seagate would release an external drive without trying to capitalize on the drive inside...I would figure the market for internal 3TB drives is bigger than external ones.
No you're not missing anything - most technical questions given in interviews are not very hard. The reason is the same as to why we ask for things like a fizzbuzz program rather than ask people to write a window manager. We're trying to distill some information about problem-solving and technical expertise in a limited amount of time. It would be trivial of course to create a problem that you couldn't do without the aid of Wolfram-Alpha.:-) Here would be my list of acceptable answers and my analysis of them as an interviewer:
i) You could solve it the way you have done. This hints at a persons ability to a step back and refactor the problem into a more easily solved form. This was the rarest case in my last group of co-ops. Only one out of eleven interviewed in my last round even suggested that there was a "math" answer that could "work out nicely".
ii) Write an approximation function with an appropriate error function. This shows a grasp - not only of math but that real-life problems often have inexact solutions. Knowing how to write an error function is good because it recognizes that in making an inexact solution it's good to know just how inexact you are being.
iii) Some kind of "brute force" where you iterate a finite number of times.
After they answer I say "Good, what's another way of solving this" and then "What are the relative merits of each?", "Can you give me general situations where you might use the same approaches you used in this problem"...
Recursion is an implementation technique for self-referential functions. Back to my now thrice mentioned example: f(x) = 1/(1+f(x))
This is a self-referential function but recursion can only implement functions of this form as estimations. You could make some assumptions about implicit exit conditions like the precision of your variables but I could always restate and specify arbitrary precision.
The point of the exercise it go get people to *think* about a problem. You can't just write this with recursion since no exit condition is specified. So then you need to talk about estimations - and what degree of accuracy is adequate or try to re-think the problem as a whole.
I don't think I need worry about applying for a position under you any time soon. You on the other hand....
Wow, that's pretty impressive. If that had come up in an interview I'd be on the floor.
Usually (as I mention above) I've given a specific problem i.e. f(x) = 1/(1+f(x)) but what you describe is a great description of solving the general case. The above function has a shortcut too as I'm sure you will notice.
Just some ambiguity in the term. Sure a factorial can be implemented using recursion but in doing so you need to specify a termination case.
I usually ask candidates to evaluate something like this: f(x) = 1/(1+f(x))
Here we have no explicit termination case. Which is a much more interesting problem to solve as it forces the candidate to work out solutions like various approximations or implicit termination cases or even just re-factoring the whole problem.
It is *NOT* someone teaching you how to program. It is someone teaching you about algorithms, data structures, etc...which you are expected to be able to figure out how to implement...or as one of my CS profs said: "I expect all of your assignments to be written in C. If you don't know C, I suggest you buy a book".
Is not the state of undergrads, sure I'm shocked when I come across one who can't write a simple join in SQL or write the proverbial 'fizzbuzz' program but from the Co-Op students I interviewed most recently the majority seemed competent. I do notice a lack of understanding of theory and hardware. I'm always amazed how these grads know squat about how computers actually work - it reminds me more of mainframe programmers who because of the degree of separation from the actual machine didn't have the slightest idea how their programs actually ran. With regard to theory I've often given applicants the opportunity to describe to me how they would approach implementing a function that is self-referential. The answer everyone gave: Recursion. From there I had to kind of remind them that such a program would recurse infinitely. Even the smartest person I interviewed who tried to go out of their way to convince me that they would write the function "tail recursive" so recursion wouldn't cause the program to fail. Missed the idea that an infinitely recursing program tail-or-non would produce no output. However much of that is excusable as long as this is an entry level job...
What I find insane is the number of people with post-graduate degrees - yes Masters and even PhD's in CS who are just as bad. Mind you some of these people have their undergraduate degree in a completely different discipline e.g. Art. Which is pretty rare in any other science.
It's not "one study" in the sense that we have only one study showing no conclusive evidence. It is merely "one study" in the context of the article (i.e. that they are referring to "not two or more" studies) - http://www.sciencebasedmedicine.org/?p=5207#more-5207
No, you don't "move on" because of one study or maybe even ten studies.
Without any bounding condition (which if you have one, you don't state). You could make the selfsame statement for ten studies, one hundred studies or a million studies.
I could go on and show how you're kind of off-base on the medical cases you're citing too but I doubt you're worth it.
"intrusive: intruding where one is not welcome or invited"
So no, there's nothing intrinsically lazy about it. It's simply unwanted. Sure "laziness" is a potential cause for not wanting something (say "work") but it's incorrect to categorize most or all people who don't want dialog boxes popping up whatever frequency they do as "lazy".
I'm guessing that workload is the deciding factor. You seem to claim the ratio of popups to "detecting something bad" is pretty good. Me, I get these things about ten to fifteen times a day and you are the very first person I have ever conversed with who has actually positively correlated it with avoiding something malevolent.
So although I don't find it a hassle I can certainly see just about any event which one had to do fifteen times a day for a perceived zero benefit might be annoying to some. Especially when you compare it to other preventative measures they may employ. For example in my social context I've met two orders of magnitude more people who have (or could have) benefited from seat belts than people who have or could have (conclusively) benefited from UAC.
First, you *could* argue, etymology/morphology aside that those two questions are semantically identical but I don't really have any large scale data either way on that. Certainly I've experienced cases where it's clear that someone who is asking "What do you like?" is actually asking "What should I like?" instead of say looking for some social touchstone to continue conversation. Conversely when people say "What's popular?" (You'll have to write how they are actually saying it: i.e. jit6 mun4 or is it some HKism. Feel free to use HKCS) it at least seems reasonable that they could be also using it to look for something else to talk about.
Second, you're confusing "collectivism" - the idea that people subscribe to a high value on interdependence with some kind of value on what are social norms for fashion.
I'd argue that's it's pretty apparent that these are different things. i.e. I can be interested in what's popular but have no care for the greater good of the people involved. Heck I could actively plot the downfall of those who say what is popular because I want people to follow me.:-)
Seriously? It's much improved over Vista, and there have been two times where it actually has caught some bad joojoo that otherwise may have caused trouble. I don't mind it at all.
Seriously? You think that security isn't intrusive? Man, talk about naive. When it comes down to it I will always be far, far more surprised at UAC actually stopping something malicious rather than the fact that users complain about it.
That's not to say that UAC might still be the RightThing(tm) but that's a completely different argument.
I really don't know what the mainlands are like but all the HK folk I've met would never pass for collectivist but perhaps that's the (great?) thing about various degrees of consumerism and democracy...it inherently undermines collectivism.
Well I don't know why people put "shopping lists" of "skills" on a resume. When I hire I tear those off or just ignore them. What I do look for is actual work experience in a particular programming language. HR doesn't really look at them because they don't really know what they mean.
While I would agree that for a lot of straightforward work you should expect an intermediate developer to be able to pick it up. Especially for patching existing code since you can often borrow from the surrounding code.
That said, writing or designing a complicated application requires some deeper knowledge. For example, I'm sure if I were to throw a rock out my window I'd hit someone who knows how to write code in PHP. However not everyone - as evidenced by code I see - can recite the casting rules it uses (and this is true for a lot of weakly typed languages). So knowing that you need to test using === when the function can return a mixed datatype (such as in strpos() )
Likewise when you have to do multiple inserts using SQL. Not every engine actually has syntax to handle this and when inserting hundreds of records it can be extremely time consuming. But knowing that you can use an "insert into table select '','... union select '','...... select '','..." approach to send as much data as the interface can hold has more than once change a program that was nearly unmanageable into one that is reasonably efficient.
Ageed however I'm getting closer to 1/3 on either 5Ghz or 2.4Ghz regardless of distance from the basestation seemingly regardless of the basestation or client. Even if Ubiquiti's claims are true it's not really making the point since it requires specific hardware to achieve. Also according to their site it is a 2x2 MIMO device.
True you can't get more than half bandwidth but that's because there's a send and receive happening. However that said the real-world measures I'm getting are closer to 1/3. Even when using the 5Ghz channel which is much less likely to have interference from legacy clients.
That the promise of 100Mb/s over WiFi really isn't realized i.e. 802.11n in every piece of equipment I've had my hands on delivers about 32Mb/s and in the same test with 100Mb Ethernet I get about 64Mb/s. It's kind of hard to take this seriously or that we simply have to take all pronouncements from the WiFi consortium at a severe "discount". Mind you if for some reason this difference was proportional to the other promises (and I can see no reason why it has to be). Even getting 1Gb/s over WiFi would be a drastic improvement. Somehow I doubt that this is the case though.
...but I can buy an actual 10Gb copper adapter for a machine I have now.
Granted that they've come up with some spiffy ways of using fiber in a consumer cable (as opposed to safely ensconcing it in conduit) and a 10Gb copper NIC is prohibitively expensive but that said it's not unreasonable to believe that the price of copper 10Gb NICs will drop before this thing is available in consumer products and although I get that this is essentially a point-to-point connection to replace things like USB. Yet Ethernet still seems - at this point anyway - as viable a choice as some new thing...which we will have to use in addition to Ethernet.
..a clue about how computers work. Even experienced windows professionals.
I mean this guy has 32 bit OS working and moves to 64 bit OS...am I following this ok. The 32 bit install presumably went well on the hardware and the 64 bit install fails.
So I grok his first attempts which are replacing the install media once. Seems like a reasonable assumption (some bit out of the billions on the DVD image just happened to be flipped the wrong way). From there though he starts to lose me. The motherboard is perhaps plausible but you would have to be assuming some rather significant difference in hardware support between the 64bit and 32bit systems. From there? RAM is 64bit how? Or even my HD?
I think the most significant thing to learn here is twofold.
i) People - even experienced computer professionals - treat computers like they are magic. Like there is no real science behind how they work. Clearly this guy was replacing parts based on some "experiential weighted average" with regard to how likely they are to cause a "weird" problem.
ii) When A. C. Doyle said "When you have excluded the impossible" he neglected to state that the *order* in which one does so is significant. Eliminating things in order of their apparent relation to the problem (i.e. all the things for which 64 bits makes a difference) and (in a business environment) with respect to cost (i.e. Replacing a CPU is often a cheaper test than replacing a motherboard wrt labour) will likely fix your problem sooner than just going for the "usual suspects".
Aside: I've had two cases where I found a CPU issue. One was very similar to this - crashing during a Windows 2000 install - often at the same place. The problem I had was actually thermal - the heatsink was reversed leaving the thermal patch making minimal contact with the heat spreader. Somehow I figured that out without replacing everything else first.
RAID is not a very good failover system. It never was, and it never will. Disks on raid often have extremely similar use patterns, leading to very similar drive life. When one drive in a RAID dies, it's not uncommon to see one or two more die at nearly the same time.
I rarely use the word "failover" that way but if you mean "fault-tolerant" then I'd rather like to see some objective data bearing your thesis out. I'd agree that many people assume RAID does more than it does but what you're saying stretches credibility - unless you are talking at either the far left or right side of the curve (not to mention you haven't defined 'not uncommon' - I'd assume you mean that you have a better chance than 1 in a few hundred or 'nearly the same time' which to me would imply 'faster than a service tech could reach the drive' i.e. 72 hrs). It seems more reasonable to assume that premature failure is the result of manufacturing weaknesses and outside of a batch problem will converge to some kind of normal distribution.
Couple of things:
1) The figures I gave are rounded the exact figures make your conclusion difficult:
HWL Drive: 1.028 x 4.000 x 5.787 HWL Case: 6.22 x 4.88 x 1.73
Possible configurations of stacking two (with zero space between):
2.056 x 4.000 x 5.787 1.028 x 8.000 x 5.787 1.028 x 4.000 x 11.574
2) Considering that the measurements are all OUTER even if my original measurements were exactly right. It would still preclude placement of the drives. Since something that contains something needs to be at least slightly larger on the inside.
3) If you are stacking two drives together it isn't unreasonable to expect some space between the two for airflow.
What's interesting about your analysis - which turns out to be 100% wrong - ironically . Is that your conclusions weren't based simply on my stated figures - you had to also assume there was some error but you assumed the error was in your favor.
Perhaps so but the dichotomy of fast/slow drives has existed on the bare drive market for a while. I'm not discounting it being a 3TB drive and as seagate said in the other article they are planning on shipping the 3TB drives this year.
One thing it could be doing isn't utilizing "lower expectation" but rather "lower demand". If the USB market is, as I suspect significantly smaller than the bare drive market then it might be a good place to start shipping in order to ramp up production or even work out some bugs. To avoid the problems they had with their other groundbreaking drive the 1.5TB!
I'll comment on my own comment...one thing that is interesting is the physical dimensions of the box:
6 x 5 x 2
considering that seagates 3.5" drives are approximately:
1 x 4 x 6
Which seems to eliminate the possibility that this is two 3.5 drives. It could still be multiple 2.5" drives but without looking at pricing I'm not sure how feasible that is (and I don't think Seagate is shipping 1TB 2.5's yet)
Oh someone at engadget said so...well that can't be in error... Anyway unless they opened it up or Seagate states somewhere on their web page that it is a single drive. It seems reasonable to remain skeptical. It seems weird that Seagate would release an external drive without trying to capitalize on the drive inside...I would figure the market for internal 3TB drives is bigger than external ones.
No you're not missing anything - most technical questions given in interviews are not very hard. The reason is the same as to why we ask for things like a fizzbuzz program rather than ask people to write a window manager. We're trying to distill some information about problem-solving and technical expertise in a limited amount of time. It would be trivial of course to create a problem that you couldn't do without the aid of Wolfram-Alpha. :-) Here would be my list of acceptable answers and my analysis of them as an interviewer:
i) You could solve it the way you have done. This hints at a persons ability to a step back and refactor the problem into a more easily solved form. This was the rarest case in my last group of co-ops. Only one out of eleven interviewed in my last round even suggested that there was a "math" answer that could "work out nicely".
ii) Write an approximation function with an appropriate error function. This shows a grasp - not only of math but that real-life problems often have inexact solutions. Knowing how to write an error function is good because it recognizes that in making an inexact solution it's good to know just how inexact you are being.
iii) Some kind of "brute force" where you iterate a finite number of times.
After they answer I say "Good, what's another way of solving this" and then "What are the relative merits of each?", "Can you give me general situations where you might use the same approaches you used in this problem"...
and so on...
I would put it another way...
Recursion is an implementation technique for self-referential functions. Back to my now thrice mentioned example: f(x) = 1/(1+f(x))
This is a self-referential function but recursion can only implement functions of this form as estimations. You could make some assumptions about implicit exit conditions like the precision of your variables but I could always restate and specify arbitrary precision.
The point of the exercise it go get people to *think* about a problem. You can't just write this with recursion since no exit condition is specified. So then you need to talk about estimations - and what degree of accuracy is adequate or try to re-think the problem as a whole.
I don't think I need worry about applying for a position under you any time soon. You on the other hand....
Wow, that's pretty impressive. If that had come up in an interview I'd be on the floor.
Usually (as I mention above) I've given a specific problem i.e. f(x) = 1/(1+f(x)) but what you describe is a great description of solving the general case. The above function has a shortcut too as I'm sure you will notice.
Just some ambiguity in the term. Sure a factorial can be implemented using recursion but in doing so you need to specify a termination case.
I usually ask candidates to evaluate something like this: f(x) = 1/(1+f(x))
Here we have no explicit termination case. Which is a much more interesting problem to solve as it forces the candidate to work out solutions like various approximations or implicit termination cases or even just re-factoring the whole problem.
It is *NOT* someone teaching you how to program. It is someone teaching you about algorithms, data structures, etc...which you are expected to be able to figure out how to implement...or as one of my CS profs said: "I expect all of your assignments to be written in C. If you don't know C, I suggest you buy a book".
Is not the state of undergrads, sure I'm shocked when I come across one who can't write a simple join in SQL or write the proverbial 'fizzbuzz' program but from the Co-Op students I interviewed most recently the majority seemed competent. I do notice a lack of understanding of theory and hardware. I'm always amazed how these grads know squat about how computers actually work - it reminds me more of mainframe programmers who because of the degree of separation from the actual machine didn't have the slightest idea how their programs actually ran. With regard to theory I've often given applicants the opportunity to describe to me how they would approach implementing a function that is self-referential. The answer everyone gave: Recursion. From there I had to kind of remind them that such a program would recurse infinitely. Even the smartest person I interviewed who tried to go out of their way to convince me that they would write the function "tail recursive" so recursion wouldn't cause the program to fail. Missed the idea that an infinitely recursing program tail-or-non would produce no output. However much of that is excusable as long as this is an entry level job...
What I find insane is the number of people with post-graduate degrees - yes Masters and even PhD's in CS who are just as bad. Mind you some of these people have their undergraduate degree in a completely different discipline e.g. Art. Which is pretty rare in any other science.
based upon one study
It's not "one study" in the sense that we have only one study showing no conclusive evidence. It is merely "one study" in the context of the article (i.e. that they are referring to "not two or more" studies) - http://www.sciencebasedmedicine.org/?p=5207#more-5207
No, you don't "move on" because of one study or maybe even ten studies.
Without any bounding condition (which if you have one, you don't state). You could make the selfsame statement for ten studies, one hundred studies or a million studies.
I could go on and show how you're kind of off-base on the medical cases you're citing too but I doubt you're worth it.
"intrusive: intruding where one is not welcome or invited"
So no, there's nothing intrinsically lazy about it. It's simply unwanted. Sure "laziness" is a potential cause for not wanting something (say "work") but it's incorrect to categorize most or all people who don't want dialog boxes popping up whatever frequency they do as "lazy".
I'm guessing that workload is the deciding factor. You seem to claim the ratio of popups to "detecting something bad" is pretty good. Me, I get these things about ten to fifteen times a day and you are the very first person I have ever conversed with who has actually positively correlated it with avoiding something malevolent.
So although I don't find it a hassle I can certainly see just about any event which one had to do fifteen times a day for a perceived zero benefit might be annoying to some. Especially when you compare it to other preventative measures they may employ. For example in my social context I've met two orders of magnitude more people who have (or could have) benefited from seat belts than people who have or could have (conclusively) benefited from UAC.
Telling us how technology X gives the music more "Transparency in the mid-range while maintaining the depth of the low-end"?
First, you *could* argue, etymology/morphology aside that those two questions are semantically identical but I don't really have any large scale data either way on that. Certainly I've experienced cases where it's clear that someone who is asking "What do you like?" is actually asking "What should I like?" instead of say looking for some social touchstone to continue conversation. Conversely when people say "What's popular?" (You'll have to write how they are actually saying it: i.e. jit6 mun4 or is it some HKism. Feel free to use HKCS) it at least seems reasonable that they could be also using it to look for something else to talk about.
:-)
Second, you're confusing "collectivism" - the idea that people subscribe to a high value on interdependence with some kind of value on what are social norms for fashion.
I'd argue that's it's pretty apparent that these are different things. i.e. I can be interested in what's popular but have no care for the greater good of the people involved. Heck I could actively plot the downfall of those who say what is popular because I want people to follow me.
Seriously? It's much improved over Vista, and there have been two times where it actually has caught some bad joojoo that otherwise may have caused trouble. I don't mind it at all.
Seriously? You think that security isn't intrusive? Man, talk about naive. When it comes down to it I will always be far, far more surprised at UAC actually stopping something malicious rather than the fact that users complain about it. That's not to say that UAC might still be the RightThing(tm) but that's a completely different argument.
I really don't know what the mainlands are like but all the HK folk I've met would never pass for collectivist but perhaps that's the (great?) thing about various degrees of consumerism and democracy...it inherently undermines collectivism.
Well I don't know why people put "shopping lists" of "skills" on a resume. When I hire I tear those off or just ignore them. What I do look for is actual work experience in a particular programming language. HR doesn't really look at them because they don't really know what they mean.
... select '','..." approach to send as much data as the interface can hold has more than once change a program that was nearly unmanageable into one that is reasonably efficient.
While I would agree that for a lot of straightforward work you should expect an intermediate developer to be able to pick it up. Especially for patching existing code since you can often borrow from the surrounding code.
That said, writing or designing a complicated application requires some deeper knowledge. For example, I'm sure if I were to throw a rock out my window I'd hit someone who knows how to write code in PHP. However not everyone - as evidenced by code I see - can recite the casting rules it uses (and this is true for a lot of weakly typed languages). So knowing that you need to test using === when the function can return a mixed datatype (such as in strpos() )
Likewise when you have to do multiple inserts using SQL. Not every engine actually has syntax to handle this and when inserting hundreds of records it can be extremely time consuming. But knowing that you can use an "insert into table select '','... union select '','...
Ageed however I'm getting closer to 1/3 on either 5Ghz or 2.4Ghz regardless of distance from the basestation seemingly regardless of the basestation or client. Even if Ubiquiti's claims are true it's not really making the point since it requires specific hardware to achieve. Also according to their site it is a 2x2 MIMO device.
True you can't get more than half bandwidth but that's because there's a send and receive happening. However that said the real-world measures I'm getting are closer to 1/3. Even when using the 5Ghz channel which is much less likely to have interference from legacy clients.
That the promise of 100Mb/s over WiFi really isn't realized i.e. 802.11n in every piece of equipment I've had my hands on delivers about 32Mb/s and in the same test with 100Mb Ethernet I get about 64Mb/s. It's kind of hard to take this seriously or that we simply have to take all pronouncements from the WiFi consortium at a severe "discount". Mind you if for some reason this difference was proportional to the other promises (and I can see no reason why it has to be). Even getting 1Gb/s over WiFi would be a drastic improvement. Somehow I doubt that this is the case though.
...and I just checked GigE premiered at $800 per port. Almost double the price of a current 10GBASE-T NIC. Seems like it has a shot.
...but I can buy an actual 10Gb copper adapter for a machine I have now. Granted that they've come up with some spiffy ways of using fiber in a consumer cable (as opposed to safely ensconcing it in conduit) and a 10Gb copper NIC is prohibitively expensive but that said it's not unreasonable to believe that the price of copper 10Gb NICs will drop before this thing is available in consumer products and although I get that this is essentially a point-to-point connection to replace things like USB. Yet Ethernet still seems - at this point anyway - as viable a choice as some new thing...which we will have to use in addition to Ethernet.
...only because e-sports doesn't have much history.
..a clue about how computers work. Even experienced windows professionals.
I mean this guy has 32 bit OS working and moves to 64 bit OS...am I following this ok. The 32 bit install presumably went well on the hardware and the 64 bit install fails.
So I grok his first attempts which are replacing the install media once. Seems like a reasonable assumption (some bit out of the billions on the DVD image just happened to be flipped the wrong way). From there though he starts to lose me. The motherboard is perhaps plausible but you would have to be assuming some rather significant difference in hardware support between the 64bit and 32bit systems. From there? RAM is 64bit how? Or even my HD?
I think the most significant thing to learn here is twofold.
i) People - even experienced computer professionals - treat computers like they are magic. Like there is no real science behind how they work. Clearly this guy was replacing parts based on some "experiential weighted average" with regard to how likely they are to cause a "weird" problem.
ii) When A. C. Doyle said "When you have excluded the impossible" he neglected to state that the *order* in which one does so is significant. Eliminating things in order of their apparent relation to the problem (i.e. all the things for which 64 bits makes a difference) and (in a business environment) with respect to cost (i.e. Replacing a CPU is often a cheaper test than replacing a motherboard wrt labour) will likely fix your problem sooner than just going for the "usual suspects".
Aside: I've had two cases where I found a CPU issue. One was very similar to this - crashing during a Windows 2000 install - often at the same place. The problem I had was actually thermal - the heatsink was reversed leaving the thermal patch making minimal contact with the heat spreader. Somehow I figured that out without replacing everything else first.