The thing is that software can be one-click or autonaming of screenshots. It can also be clever lossy compression or speech recognition or even a strong AI. Lots of research have gone into those and we are certainly not there yet for the latter two. The thing is also that, just like for a diesel engine, or to some degree for a new medicine, it's easy to say "reduce particle emissions" or "target that receptor". It's a pain that popular compression algorithms are covered by patents, but I think it's quite fair to say that advances there are patentworthy, just like advances in analog techniques of bandwidth reduction for broadcast video.
Mining the moon seems like a wise choice, then. The Earth-Luna complex would keep its mass. Mining the asteroids is another thing, though. On the other hand, Earth loses quite a bit of atmosphere, but also gains mini-meteors, so unless we start considering really vast structures, it can safely be ignored.
Well, you would suppose that the limited flexibility in configurations where you can get OS X would mean that those configurations that are supported are tested properly.
Apple machines may be overpriced or not, but it's hard to deny that the company tries to make the argument that it provides an integrated environment.
The world population in 1850 was 1.2 billion. The estimated world population at year 1 AD was 200 million. I think you have some sound points, but your numbers are off by quite a bit, and thus the drama would also be more limited. (And I think fusion or "local" [Earth surface/orbit] solar power are far more feasible than massive transport of hydrocarbons from the outer solar system. The only commodity worth taking from there is water and hydrogen, avoiding the Earth gravity well.)
Pivoting means that ClearType or favorite subpixel rendering of your choice won't work. And I do really prefer ClearType, in the same way I prefer dualmon and high resolution.
If you shrink the size by a factor of 10 and are worried by the number of write, just do wear levelling over a memory ten times the size. As long as it hasn't failed, and you also don't care about speed, write it redundantly with loads of ECC. This is possible if the memory is damn small and damn cheap.
Well, if we are able to go about it in a totally different way, that the dark matter/energy estimates weren't ad hoc-adjusted to fit, and we still see that those estimates fit, it means something. It might be something else, including a weirdness in gravity, but overall the data fits well with something that is quite similar to matter.
Bones are continuously maintained in a way quite different from most of a tooth. This is a trick to give the normal process to replenish bone and repair broken bones to a headstart and some basic structure to get the final layout right. Triggering the growth of a new tooth in situ is a quite different thing, especially to get the outer layers right, without which it would indeed be quite biodegradeable in any mouth.
Nah, damaged bone is rarely a reason for amputation in itself, although you can surely be incapacitated. If you manage to keep bloodflow and avoid infection, you can always try to patch it up somehow later on, with varying degrees of outside intervention to the natural healing process.
Your parent post mentioned solar concentration, i.e. cheap mirrors heating a turbine. The problem with solar panels right now is their cost. If large areas (as in even such a miniscule amount as "most building roofs") were to be covered, it would probably not be with top-efficiency cells.
What about them? You will still need to emit and absorb light at some points, and the basic thesis here is that the number of discrete switches (no matter whether they are semiconductor transistors or something else) will grow much faster than the sequential speedup.
With GBs and GBs of memory, there is no reason that common include files shouldn't get stored in cache. The writes are also miniscule, and contention there would also be a design error. Merging everything in one file is another thing, of course, but that mainly shows how expensive parsing (repeatedly, of include files) is, not the I/O itself.
2. There is no problem in doing single or dual qubits in hardware for desktops. You can simulate all of it far cheaper. After all, that's how we test the algorithms right now, and we could easily handle even 20 or so qubits within realistic time.
That's like saying GPGPU is useless, just because GPUs are not very useful for serving web content, or files, or being used for databases (what fills most datacenters). They are great for some (not all) HPC applications, though. A practically useful quantum computer, even if unbelievably expensive, would still be useful for those things that quantum computers do exceedingly well. In the 50s, a small firm would never get a computer to replace accountants. Government agencies and some companies would still get them for the most demanding computation tasks of the time. As a quantum computer moves us firmly outside the von Neumann paradigm, and to some degree outside Turing as well, we can't just look at the cost and whether large deployments are feasible, because even one machine will be useful for those tasks that no machine, or only a million or more machines, can do within a realistic amount of time today.
And you're doing things really, really wrong if you hard-code Documents and Settings (hey, it's not called that in Vista, it wasn't called that on 9x, it wasn't called that in NT4, it's a 2000-XP-Server2003 thing, and you don't know which drive it will reside on). You should ask the OS to give you the profile folder of the currently logged-in user.
And this is well-documented. It's easy to get the folder name. But there is lots and lots and lots of bad software. And the real problem is that the user never perceived it as bad, unless the user cared.
OOP with virtual and all, yes. OOP with template magic to allow the compiler to do specializations can beat the heck out of even quite tediously hand-written C or FORTRAN, with much superior readability.
A few things: you cannot write a (Mozilla) browser plugin all in managed code, there is simply no interface. You at least need a bridge. Silverlight is also related to WPF/Avalon, which has a native component on Windows. Most importantly, though: Silverlight is not open source. Moonlight is. It is not a port, it is a sanctioned, but independent, rewrite, which is also related to advances in the Mono support for quite a few things that weren't there 2 years ago.
Apparently you don't recognize the scale here. It is the whole planet, wrapping around several times just do have something to display. If you zoom out Google Maps enough and have a large enough display (or zoom out in your browser as well), you will see the same image over and over. I currently have three instances of Eurasia on my Google Maps display (almost full screen 1920x1200).
At some point we have massive evaporation, which would tend to go catastrophic, i.e. Venus (water vapor is extremely potent as a greenhouse gas). A temperature above which proteins in most organisms coagulate would bring us down to archea. Photosynthesis in its current form also prefers lower temperatures. We know very little of what situations complex multicellular life can really adapt to, but we can say that Earth would no longer be within the range that we consider to be habitable when we do armchair analyses of exoplanets.
The sun rotates, although with quit different speeds at the equator and the poles. For a period of 200 days, we will also get to see most of it (independently of the rotation). Unless one poses there is something very different about the side facing the Earth, no matter what "side" that is, the tendency should be quite clear. (I also think there are some space-based probes that are relevant here, but I am not sure whether any of them images the full "opposite side" of the sun regularly.)
But the tests didn't consider context-switching time, I/O response time or anything like that during the encoding. They just ran the test and timed it, so you have no idea of differences in general responsiveness of the systems while doing this. One would even expect a slight tendency of lower single-task performance at the cost of e.g. keeping more general data in the file system cache to remain responsive at the very moment the user decides to do something.
I remember one KLM flight where about half of the seats (including mine, the full pattern was not immediately apparent) had some serious problems where the on-demand video files seem to have been crosslinked. You chose something, but got something else. The indexing didn't work, so no seeking. Suddenly, the video broke up and you were in the middle of another title. The instruction video was replaced by an excerpt from Shrek 2.
And, oh yes, I saw that penguin a number of times before they gave up trying to fix it by rebooting. The sad thing was that this in-flight entertainment system was the very best I had ever used, in the other direction, a week earlier. Responsive, a great selection of movies, seeking, pausing, etc. This was in 2005, and on some later intercontinental KLM they didn't still have the system, but it might simply be a matter of another airplane in the fleet where it hadn't been installed yet.
Slashdot Mirror
The thing is that software can be one-click or autonaming of screenshots. It can also be clever lossy compression or speech recognition or even a strong AI. Lots of research have gone into those and we are certainly not there yet for the latter two. The thing is also that, just like for a diesel engine, or to some degree for a new medicine, it's easy to say "reduce particle emissions" or "target that receptor". It's a pain that popular compression algorithms are covered by patents, but I think it's quite fair to say that advances there are patentworthy, just like advances in analog techniques of bandwidth reduction for broadcast video.
Mining the moon seems like a wise choice, then. The Earth-Luna complex would keep its mass. Mining the asteroids is another thing, though. On the other hand, Earth loses quite a bit of atmosphere, but also gains mini-meteors, so unless we start considering really vast structures, it can safely be ignored.
Well, you would suppose that the limited flexibility in configurations where you can get OS X would mean that those configurations that are supported are tested properly.
Apple machines may be overpriced or not, but it's hard to deny that the company tries to make the argument that it provides an integrated environment.
The world population in 1850 was 1.2 billion. The estimated world population at year 1 AD was 200 million. I think you have some sound points, but your numbers are off by quite a bit, and thus the drama would also be more limited. (And I think fusion or "local" [Earth surface/orbit] solar power are far more feasible than massive transport of hydrocarbons from the outer solar system. The only commodity worth taking from there is water and hydrogen, avoiding the Earth gravity well.)
Pivoting means that ClearType or favorite subpixel rendering of your choice won't work. And I do really prefer ClearType, in the same way I prefer dualmon and high resolution.
If you shrink the size by a factor of 10 and are worried by the number of write, just do wear levelling over a memory ten times the size. As long as it hasn't failed, and you also don't care about speed, write it redundantly with loads of ECC. This is possible if the memory is damn small and damn cheap.
Well, if we are able to go about it in a totally different way, that the dark matter/energy estimates weren't ad hoc-adjusted to fit, and we still see that those estimates fit, it means something. It might be something else, including a weirdness in gravity, but overall the data fits well with something that is quite similar to matter.
Bones are continuously maintained in a way quite different from most of a tooth. This is a trick to give the normal process to replenish bone and repair broken bones to a headstart and some basic structure to get the final layout right. Triggering the growth of a new tooth in situ is a quite different thing, especially to get the outer layers right, without which it would indeed be quite biodegradeable in any mouth.
Nah, damaged bone is rarely a reason for amputation in itself, although you can surely be incapacitated. If you manage to keep bloodflow and avoid infection, you can always try to patch it up somehow later on, with varying degrees of outside intervention to the natural healing process.
Your parent post mentioned solar concentration, i.e. cheap mirrors heating a turbine. The problem with solar panels right now is their cost. If large areas (as in even such a miniscule amount as "most building roofs") were to be covered, it would probably not be with top-efficiency cells.
What about them? You will still need to emit and absorb light at some points, and the basic thesis here is that the number of discrete switches (no matter whether they are semiconductor transistors or something else) will grow much faster than the sequential speedup.
With GBs and GBs of memory, there is no reason that common include files shouldn't get stored in cache. The writes are also miniscule, and contention there would also be a design error. Merging everything in one file is another thing, of course, but that mainly shows how expensive parsing (repeatedly, of include files) is, not the I/O itself.
2. There is no problem in doing single or dual qubits in hardware for desktops. You can simulate all of it far cheaper. After all, that's how we test the algorithms right now, and we could easily handle even 20 or so qubits within realistic time.
That's like saying GPGPU is useless, just because GPUs are not very useful for serving web content, or files, or being used for databases (what fills most datacenters). They are great for some (not all) HPC applications, though. A practically useful quantum computer, even if unbelievably expensive, would still be useful for those things that quantum computers do exceedingly well. In the 50s, a small firm would never get a computer to replace accountants. Government agencies and some companies would still get them for the most demanding computation tasks of the time. As a quantum computer moves us firmly outside the von Neumann paradigm, and to some degree outside Turing as well, we can't just look at the cost and whether large deployments are feasible, because even one machine will be useful for those tasks that no machine, or only a million or more machines, can do within a realistic amount of time today.
And you're doing things really, really wrong if you hard-code Documents and Settings (hey, it's not called that in Vista, it wasn't called that on 9x, it wasn't called that in NT4, it's a 2000-XP-Server2003 thing, and you don't know which drive it will reside on). You should ask the OS to give you the profile folder of the currently logged-in user.
And this is well-documented. It's easy to get the folder name. But there is lots and lots and lots of bad software. And the real problem is that the user never perceived it as bad, unless the user cared.
Well, we're before the 24th century, so it's the n^3 scale, i.e. warp 10 being 1000c.
OOP with virtual and all, yes. OOP with template magic to allow the compiler to do specializations can beat the heck out of even quite tediously hand-written C or FORTRAN, with much superior readability.
A few things: you cannot write a (Mozilla) browser plugin all in managed code, there is simply no interface. You at least need a bridge. Silverlight is also related to WPF/Avalon, which has a native component on Windows. Most importantly, though: Silverlight is not open source. Moonlight is. It is not a port, it is a sanctioned, but independent, rewrite, which is also related to advances in the Mono support for quite a few things that weren't there 2 years ago.
Yes.
Apparently you don't recognize the scale here. It is the whole planet, wrapping around several times just do have something to display. If you zoom out Google Maps enough and have a large enough display (or zoom out in your browser as well), you will see the same image over and over. I currently have three instances of Eurasia on my Google Maps display (almost full screen 1920x1200).
At some point we have massive evaporation, which would tend to go catastrophic, i.e. Venus (water vapor is extremely potent as a greenhouse gas). A temperature above which proteins in most organisms coagulate would bring us down to archea. Photosynthesis in its current form also prefers lower temperatures. We know very little of what situations complex multicellular life can really adapt to, but we can say that Earth would no longer be within the range that we consider to be habitable when we do armchair analyses of exoplanets.
It's not life as we know it, Jim.
The sun rotates, although with quit different speeds at the equator and the poles. For a period of 200 days, we will also get to see most of it (independently of the rotation). Unless one poses there is something very different about the side facing the Earth, no matter what "side" that is, the tendency should be quite clear. (I also think there are some space-based probes that are relevant here, but I am not sure whether any of them images the full "opposite side" of the sun regularly.)
But the tests didn't consider context-switching time, I/O response time or anything like that during the encoding. They just ran the test and timed it, so you have no idea of differences in general responsiveness of the systems while doing this. One would even expect a slight tendency of lower single-task performance at the cost of e.g. keeping more general data in the file system cache to remain responsive at the very moment the user decides to do something.
I remember one KLM flight where about half of the seats (including mine, the full pattern was not immediately apparent) had some serious problems where the on-demand video files seem to have been crosslinked. You chose something, but got something else. The indexing didn't work, so no seeking. Suddenly, the video broke up and you were in the middle of another title. The instruction video was replaced by an excerpt from Shrek 2.
And, oh yes, I saw that penguin a number of times before they gave up trying to fix it by rebooting. The sad thing was that this in-flight entertainment system was the very best I had ever used, in the other direction, a week earlier. Responsive, a great selection of movies, seeking, pausing, etc. This was in 2005, and on some later intercontinental KLM they didn't still have the system, but it might simply be a matter of another airplane in the fleet where it hadn't been installed yet.
No real problem in doing MPEG-1 in an overlay, i.e. good enough for some 320x240 "VHS quality" material. Add to that quality material using WinG!