(My main source of income is assembly language programming for multiple architectures, primarily PowerPC/Altivec these days.)
Please explain why my post is stupid... the original post that we are all responding to suggested doing static binary translation. I explained why this is extremely difficult. His response showed that he had not considered the case of variable input; if you neglect this case, you can statically compile all programs to a few print statements and a return value, so it's really just as well not to. I gave an example of a program that can not be statically translated this way.
I did. (I use google for everything, even my primary calculator; just waiting for it to do currency conversions.) It suggested my spelling was right, which I didn't quite believe.
It would work for any code which does the exact same thing on every run. However, it would not work any program that (a) depends on user input, (b) depends on input from other hardware, (c) uses a random number generator or is time sensitive, or (d) is not guaranteed to terminate. Oh, come to think of it, it'll fail on any program that (e) uses certain information for both code and data, which is less rare than you might think.
It's the same issue as decompiling, really; binary translation is decompile-recompile, with certain optimizations made if you don't actually need the full source. Play with dissassemblers, let alone decompilers, and you'll see how bad they do in the general case.
It's called binary translation. It's not impossible; search on citeseer. But how do you telll (in the general case) the difference between code and data?
1. Static electricity is a potential problem. However, static electricity is caused by friction between two non-conductive surfaces. Most servers I've worked with have unpainted chassis (okay, all except for a few in bizarre purple cases), so if they are directly against the carpet, it shouldn't be a big deal. Also, once they are in position, they presumably aren't moving much... static should be a total non-issue after the install.
2. Static problems, admittedly, can be caused in the install and not manifest themselves except for a reduced MTBF, although I'm not convinced this is as common as some seem to think. But heat problems, on modern hardware, are a binary condition; either you've got 'em, or you haven't. If the systems have been running on in their production environment, on a real production load, and haven't had any problems, heat is not a problem. The heat produced by a system does not increase over age, nor does the heat sensitivity, and unlike static, heat is not a cumulative problem.
If the carpet will lead to premature failure, which is certainly possible, it would have done so already. The original post was talking about being shown this system installed and running, not about having it done recently.
Oh, and modern hard drives are a lot more tolerant of strange orientations than old ones; still, as both general practice and as proof of a potential lack of imagination, I'd never think of mounting one other than parallel or perpendicular to gravity.
I'm sorry if I came across as trollish, but there seems to be an obsession these days with following the rules for everything and making it pretty. Sometimes working with what you have, and coming up with an ugly solution, is not just a poor compromise but equally good, if the system works to the necessary specs, as the one described here certainly seems to do.
That's okay, I suspect the other employees thought you were dumb because you still think that coke vs. pepsi is a highly polarizing, important debate, rather than because of the can-in-the-freezer thing.
So what? Do you think the servers mind bieng upside down? If there's no evidence of heat problems, does sitting on a carpet make the slightest difference? I suppose a mouse could get caught in the blowers, or something... but it doesn't seem to be broken at all, from what you describe.
Try opening in a sealed environment, coating, and checking for degradation in normal environment? I don't know exactly how they made the polycarb porous (I assume the degrading layer is around where the dye layer would be on a burned disk), but it should be relatively easy to seal with another thin coat of polycarb, and DVD players aren't that sensitive to thickness. The question is how much oxygen can you allow in before sealing without problems later? If the oxygen is being bound up in an organic dye, which is then reflecting too little light to be readable (my guess as to what's going on), then if enough oxygen to take it 90% of the way to 'dead' is caught under the sealant, it'll still be good forever... which may mean you can seal in open air.
I'm as big a fan of the mars missions as the next geek, but don't you think calling Spirit a life critical system is a bit much? Maybe career critical...
Except the current source is licensed under a GPL compatible license... so all you have to is fork the current version and add whatever new stuff you need on your own.
My numbers are not, unfortunately, exaggeration (how the heck do you spell that, anyway?). They are, however, based on a straight compile with no check of optimization or anything. And I assume it would be measurably less bad on a machine that didn't need to do as much byte swizzling.
There's a LOT of reasons that 'all the java tricks' can't be applied; the main one is the different structure of memory. A few of the java tricks (dynamic recompilation, for example) can be; others (instruction reordering) can't be.
Unfortunately, the slow part of Bochs is not the front end, it's the emulator. Admittedly, calls to the WINE api will run at native speed, but I imagine that very few windows programs spend most of their time there. Otherwise, expect slowdown of 99% - 99.9%... my G3/600MHz runs console apps in Bochs at around 900kHz equivalent.
While I'll take your word that DVI works beyond 1600x1200... an electrical specification specifies the tolerances of the connection, yes? Which directly correlates to available bandwidth, yes? Assuming (as you seem to state) that the specification doesn't include any protocol for specifying resolution or timing, there are still essential limits on available resolution imposed by any specification.
Slashdot Mirror
Because Via, Apple, IBM, and others presumably use the same physics without problems?
(My main source of income is assembly language programming for multiple architectures, primarily PowerPC/Altivec these days.)
Please explain why my post is stupid... the original post that we are all responding to suggested doing static binary translation. I explained why this is extremely difficult. His response showed that he had not considered the case of variable input; if you neglect this case, you can statically compile all programs to a few print statements and a return value, so it's really just as well not to. I gave an example of a program that can not be statically translated this way.
Me too!
I did. (I use google for everything, even my primary calculator; just waiting for it to do currency conversions.) It suggested my spelling was right, which I didn't quite believe.
Where are you from that that reaction needs catalysis? Minnesota?
aluminium...
Echo does different things when I call it with the argument "foo" than when I call it with the argument "bar", no?
It would work for any code which does the exact same thing on every run. However, it would not work any program that (a) depends on user input, (b) depends on input from other hardware, (c) uses a random number generator or is time sensitive, or (d) is not guaranteed to terminate. Oh, come to think of it, it'll fail on any program that (e) uses certain information for both code and data, which is less rare than you might think.
It's the same issue as decompiling, really; binary translation is decompile-recompile, with certain optimizations made if you don't actually need the full source. Play with dissassemblers, let alone decompilers, and you'll see how bad they do in the general case.
It's called binary translation. It's not impossible; search on citeseer. But how do you telll (in the general case) the difference between code and data?
1. Static electricity is a potential problem. However, static electricity is caused by friction between two non-conductive surfaces. Most servers I've worked with have unpainted chassis (okay, all except for a few in bizarre purple cases), so if they are directly against the carpet, it shouldn't be a big deal. Also, once they are in position, they presumably aren't moving much... static should be a total non-issue after the install.
2. Static problems, admittedly, can be caused in the install and not manifest themselves except for a reduced MTBF, although I'm not convinced this is as common as some seem to think. But heat problems, on modern hardware, are a binary condition; either you've got 'em, or you haven't. If the systems have been running on in their production environment, on a real production load, and haven't had any problems, heat is not a problem. The heat produced by a system does not increase over age, nor does the heat sensitivity, and unlike static, heat is not a cumulative problem.
If the carpet will lead to premature failure, which is certainly possible, it would have done so already. The original post was talking about being shown this system installed and running, not about having it done recently.
Oh, and modern hard drives are a lot more tolerant of strange orientations than old ones; still, as both general practice and as proof of a potential lack of imagination, I'd never think of mounting one other than parallel or perpendicular to gravity.
I'm sorry if I came across as trollish, but there seems to be an obsession these days with following the rules for everything and making it pretty. Sometimes working with what you have, and coming up with an ugly solution, is not just a poor compromise but equally good, if the system works to the necessary specs, as the one described here certainly seems to do.
Yeah, but you have to pay the parking before the attendants will give you the keys.
That's okay, I suspect the other employees thought you were dumb because you still think that coke vs. pepsi is a highly polarizing, important debate, rather than because of the can-in-the-freezer thing.
Allow that may be an excuse for the Venusians, it's less convincing an argument for those who have lived many years with water in all three states.
So what? Do you think the servers mind bieng upside down? If there's no evidence of heat problems, does sitting on a carpet make the slightest difference? I suppose a mouse could get caught in the blowers, or something... but it doesn't seem to be broken at all, from what you describe.
Try opening in a sealed environment, coating, and checking for degradation in normal environment? I don't know exactly how they made the polycarb porous (I assume the degrading layer is around where the dye layer would be on a burned disk), but it should be relatively easy to seal with another thin coat of polycarb, and DVD players aren't that sensitive to thickness. The question is how much oxygen can you allow in before sealing without problems later? If the oxygen is being bound up in an organic dye, which is then reflecting too little light to be readable (my guess as to what's going on), then if enough oxygen to take it 90% of the way to 'dead' is caught under the sealant, it'll still be good forever... which may mean you can seal in open air.
Then they would walk...
I'm as big a fan of the mars missions as the next geek, but don't you think calling Spirit a life critical system is a bit much? Maybe career critical...
Except the current source is licensed under a GPL compatible license... so all you have to is fork the current version and add whatever new stuff you need on your own.
So recompile without the message... that's the difference; you're allowed.
Firebird also has type ahead searching. A feature which one can't live without.
Unless a large fraction of the world's population finds itself dead tomorrow, I tend to suspect you're exaggerating.
My numbers are not, unfortunately, exaggeration (how the heck do you spell that, anyway?). They are, however, based on a straight compile with no check of optimization or anything. And I assume it would be measurably less bad on a machine that didn't need to do as much byte swizzling.
What do we do now to protect our computer from spyware? Use OS X. What will we do with WinFS? Continue to laugh at those who do not.
There's a LOT of reasons that 'all the java tricks' can't be applied; the main one is the different structure of memory. A few of the java tricks (dynamic recompilation, for example) can be; others (instruction reordering) can't be.
Unfortunately, the slow part of Bochs is not the front end, it's the emulator. Admittedly, calls to the WINE api will run at native speed, but I imagine that very few windows programs spend most of their time there. Otherwise, expect slowdown of 99% - 99.9%... my G3/600MHz runs console apps in Bochs at around 900kHz equivalent.
While I'll take your word that DVI works beyond 1600x1200... an electrical specification specifies the tolerances of the connection, yes? Which directly correlates to available bandwidth, yes? Assuming (as you seem to state) that the specification doesn't include any protocol for specifying resolution or timing, there are still essential limits on available resolution imposed by any specification.