Currently if you want to do the kind of 3D we're talking about you can buy a Lytro and get low resolution with a lot of data and processing, or you can buy one of the commonly available compact cameras that include two lenses (like this one) and get instant, high res results.
To be fair, that gives you stereography, not 3D. From stereography, you can compute, tada, something resembling 3D along a short baseline, i.e. not only showing the image through one of the lenses, but a theoretical image from anywhere close to where they were located. The Lytro is a much more solid way of achieveing that, though, if they can create sensors that are both wide enough and carry enough resolution. Currently, they are a long way off. I would even think that you could put to Lytros in kind of a stereographic configuration and get a baseline extension, kind of like astronomical interferometry arrays. You don't need the light field at all locations and having it some distance away is far more valuable than having each and every pixel in between.
And yet, from my observations, all the iPhone is ever used for is cutting virtual rope and tweeting (low-res) pictures of food. Seems like quite a waste by comparison.
If Curiosity would ever send back even a low-res picture containing anything resembling food, it would be deemed a tremendous success. How unfair to our dear Apple gadget friends.
Off the shelf junk works in space all the time. Processing power is unrelated to radiation shielding.
Lack of processor power has to do with qualification processes and lead times. Your pitiful opinion is misdirected and uninformed.
Well, there are sound arguments for why smaller manufacturing proceses would inherently be more radiation sensitive, so saying that the two are unrelated is a bit misleading.
Indeed, I kept laughing at the MHz / GHz wars in the smartphone arena the last 18 months and couldn't help but nearly choke when I looked at solid integer / floating point performance and saw most of this wiz-bang 1 GHz Dual core stuff still getting stomped by stuff in the PII-450 / PIII-600 range (as I recall Atom started as more or less a process shrunk and trimmed down PIII with some of the Core series improvements and modularity grafted in).
Atom is not a PIII. It is closer to the original P54C (Pentium), but not very close (Larrabee is far closer, but still heavily modified). The main argument for this is that the PIII, as a descendent of the Pentium Pro, was out of order. All released Atoms so far are in-order, but they are on the other hand both wider, far more well-cached and better at branch prediction than the original Pentium. Basically, they do a lot to bring down the latencies that can arise from an in-order architecture.
Note "has been". Since this is more due to the way the API is managed and developed, I would expect it to happen again whenever serious new functionality is introduced. I would also believe that this will happen. The ever increasing performance, with different constraints on computation power versus bandwidth versus expected quality makes it hard to believe that either current OpenGL or current Direct3D are fully mature and will now not change.
OpenGL has been far more fragmented in terms of the numer of vendor extensions you needed to use for a long time to get access to recent functionality. However, I think that the theory in the article, that this actually refers to DirectSound/DirectInput/DirectDraw etc, is quite credible. Direct3D has changed quite a bit in recent years, including grafting Direct2D onto the 3D-style framework.
FAT16 handled 32-bit files sizes. There are probably hard-coded RAM limits in the (32-bit) virtual memory code in Win 3.1 that are more serious, not exceeding more than a certain number of pages and some address space restrictions.
The address Space of 64 bit processes is vast compared to available memory. The process will run out of memory before the address Space could be filled.
Every 64-bit OS I know of uses delayed allocation: when a program asks the OS for memory, the OS assigns a chunk of address space, but doesn't assign memory (physical, virtual, or otherwise) until the program actually tries to use it. It's quite possible for a program to exhaust the available address space without actually using very much memory.
True, but just the data structures for the OS heap could also become a serious burden when we start approaching actually filling the address space. On the other hand, x64 CPUs cannot handle fully arbitrary addresses, so it's all a complicated story. Suffice to say that any method using Javascript or most other "simple" ways to trigger memory allocation will also trigger memory writes into the newly allocated pages. You have to be rather careful not to write or init allocated pages in most languages and environments.
There are plenty of kernel improvements. Memory page deduplication seems kind of nice (no, not only COW, but detecting copy-on-write from pages that were not allocated with the explicit intent of being identical). Some of the revamping of Explorer could also be kept, depending on the actual intent.
'cause Trusted Computing is eeeeevil. But I start to think that even as a guy using a compiler with a frequency thousands of percent over the mean, it would make sense for most binaries I compile to run in a very limited jail.
Yes, they are on the same level, but the point in healthy competition is that you do not rely on the benevolent actions of the parties involved. A Microsoft and an Apple, with the same inherent company values and attitudes, are far better for the marketplace than just having either of them.
Well, if you want that kind of resource, Amazon is very happy to sell it to you these days. In 2008, it was still a novel concept. Assuming that a government project should be able to spearhead such a development, especially with a huge one-time investment in hardware, that's the real stupidity.
You still need fair power and cooling facilities to make any use of them, as well as some sysadmin staff to set up and maintain the queuing system. If an outdated cluster was kept intact, you could possibly benefit from already solving the utilities and system setup issue, but if they are dividing it into pieces, those benefits are also lost.
Several techniques have been used, but e.g. Kepler is relying on observing repeated dimming. Considering the massive-throughput approach of Kepler, you can hardly say that it represents an outdated method.
For Kepler among others, time itself is of the essence. To get a sure signal, they need several occlusion events (in the plane towards us). If a planet has a long orbital period (year-like), it will take a few... years before a really strong signal of several repeated events is recorded.
All current input hardware uses fairly rectangular input grids. However, this is often far from the truth. A digital camera contains pixels, but each pixel is covered by a color filter. In a JPEG from the camera, all pixels are represented (and compressed), but some information is already only a result of interpolation. This is one reason for why RAW is preferable, no lying about the information around. One could make hexagonal sensors or sensors with varying pixel density for a greater and more affordable field of view, or weird lens designs where the projection is not rectangular. If you have vector or mesh-free image data you have much greater freedom in designing both input and output methodology.
The main problem of the experiments of the Watson-Crick era was that the diffraction pattern was created by the average along the helix, so you could not really discern individual nucleotides. Considering diffraction by itself to somehow be inferior to transmission techniques is not very convincing, in my opinion. It's not even like the scientists can visually see this with their own eyes - and even if they could, the interpretation would be totally dependent on the design of the equipment, just like reconstruction of diffraction data is dependent on a number of assumptions.
What's relevant and interesting is the fact that we get close to observing individual molecules of DNA in detail, but that could be done with techniques for single-molecule diffraction as well.
Programming, in this sense, is applied method calling into your supporting libraries and framework. It has more similarities to designing a nice-looking Word template or using Excel in not overly creative ways. If a programmer of this kind ends up designing her own algorithms or even worse a full class hierarchy, it will surely end up on thedayilywtf. The thing is, they should not need to. You don't expect a household electrician to rewire stuff with a new transformer design just because it seemed fun to do for one specific customer and maybe 10% more efficient. You do standard stuff in standard ways. It's not trivial, but it's all done within well-defined bounds.
I would never want this kind of a job, but if you consider how many things that are still done manually in one way or another by people having GFLOPS on their desktops, it's also obvious that cheaper and more plentiful access to people able to just crank out code to do stuff has a tremendous value.
600 000 000 meters making 50 000 000 meters peanuts. Sure, they are different, but not that different. For an effective energy weapon, you are probably not fine with say 1 % efficiency, so beam collimation becomes crucial. If the energy you are hitting the enemy with is a mere fraction of the energy you need to dump off safely from your own ship, you are in trouble. (Incidentally, that makes big defensive weapons based on atmosphere-devoid planetary bodies all the more realistic.)
No 2.5" 120 GB existed in 2001 either. 60 GB was a high-end laptop option in 2004. The first 1 TB desktop drive was released in 2007. And according to an old Engadget posting, the 120 GB Momentus was a big deal in 2005. Now, 7 years is of course a long time, but it's almost half of what you claimed. The minimum storage need for a modern OS has barely increased in that time, with the exception that you might to some extent have dual userspaces if you used to do only 32-bit and now support 64 as well as 32.
Similar to some devices here on Earth, the rover should have an automatic revert solution. For instance, a non-updatable software running on a separate processor detects specific conditions (like no signal from Earth for a while) and flashes back the updatable software to its original version when that condition occurs.
Such things tend to be present, but how many times have they tested the automatic revert in actual conditions? An alternative codepath is always a risk.
Updating the software can have great advantages. Only a slightly more reliable connection would allow vast amounts of more science to be done. Adapting the algorithms for autonomous functions such as simple navigation or sample processing also makes a great difference when your lag time for a single command is measured in terms of minutes and you don't even have that level of "real-time" access most of the time.
From your link: "What is the evidence, then, that QDOS was a derivative work – a rip-off? The answer lies in the API, which describes how software can call up the underlying operating system and make it work for the user. The first 26 system calls of MS-DOS 1.0 are identical to the first 26 system calls of CP/M."
Yeah, just like Linux and WINE are rip-offs. The need to map system calls by number and not only name was of course due to the fact that the actual calling mechanism worked by number. However, the IEEE article is still strange, since the matters described are already settled. On the other hand, the legend of DOS being stolen and not only a clone lives on, in some places.
Slashdot Mirror
Currently if you want to do the kind of 3D we're talking about you can buy a Lytro and get low resolution with a lot of data and processing, or you can buy one of the commonly available compact cameras that include two lenses (like this one) and get instant, high res results.
To be fair, that gives you stereography, not 3D. From stereography, you can compute, tada, something resembling 3D along a short baseline, i.e. not only showing the image through one of the lenses, but a theoretical image from anywhere close to where they were located. The Lytro is a much more solid way of achieveing that, though, if they can create sensors that are both wide enough and carry enough resolution. Currently, they are a long way off. I would even think that you could put to Lytros in kind of a stereographic configuration and get a baseline extension, kind of like astronomical interferometry arrays. You don't need the light field at all locations and having it some distance away is far more valuable than having each and every pixel in between.
And yet, from my observations, all the iPhone is ever used for is cutting virtual rope and tweeting (low-res) pictures of food. Seems like quite a waste by comparison.
If Curiosity would ever send back even a low-res picture containing anything resembling food, it would be deemed a tremendous success. How unfair to our dear Apple gadget friends.
Off the shelf junk works in space all the time. Processing power is unrelated to radiation shielding.
Lack of processor power has to do with qualification processes and lead times. Your pitiful opinion is misdirected and uninformed.
Well, there are sound arguments for why smaller manufacturing proceses would inherently be more radiation sensitive, so saying that the two are unrelated is a bit misleading.
Indeed, I kept laughing at the MHz / GHz wars in the smartphone arena the last 18 months and couldn't help but nearly choke when I looked at solid integer / floating point performance and saw most of this wiz-bang 1 GHz Dual core stuff still getting stomped by stuff in the PII-450 / PIII-600 range (as I recall Atom started as more or less a process shrunk and trimmed down PIII with some of the Core series improvements and modularity grafted in).
Atom is not a PIII. It is closer to the original P54C (Pentium), but not very close (Larrabee is far closer, but still heavily modified). The main argument for this is that the PIII, as a descendent of the Pentium Pro, was out of order. All released Atoms so far are in-order, but they are on the other hand both wider, far more well-cached and better at branch prediction than the original Pentium. Basically, they do a lot to bring down the latencies that can arise from an in-order architecture.
Note "has been". Since this is more due to the way the API is managed and developed, I would expect it to happen again whenever serious new functionality is introduced. I would also believe that this will happen. The ever increasing performance, with different constraints on computation power versus bandwidth versus expected quality makes it hard to believe that either current OpenGL or current Direct3D are fully mature and will now not change.
OpenGL has been far more fragmented in terms of the numer of vendor extensions you needed to use for a long time to get access to recent functionality. However, I think that the theory in the article, that this actually refers to DirectSound/DirectInput/DirectDraw etc, is quite credible. Direct3D has changed quite a bit in recent years, including grafting Direct2D onto the 3D-style framework.
FAT16 handled 32-bit files sizes. There are probably hard-coded RAM limits in the (32-bit) virtual memory code in Win 3.1 that are more serious, not exceeding more than a certain number of pages and some address space restrictions.
The problem for 32-bit is where you put sane, since filling your address space to 75 % or more is suddenly a rather real prospect for real use cases.
Every 64-bit OS I know of uses delayed allocation: when a program asks the OS for memory, the OS assigns a chunk of address space, but doesn't assign memory (physical, virtual, or otherwise) until the program actually tries to use it. It's quite possible for a program to exhaust the available address space without actually using very much memory.
True, but just the data structures for the OS heap could also become a serious burden when we start approaching actually filling the address space. On the other hand, x64 CPUs cannot handle fully arbitrary addresses, so it's all a complicated story. Suffice to say that any method using Javascript or most other "simple" ways to trigger memory allocation will also trigger memory writes into the newly allocated pages. You have to be rather careful not to write or init allocated pages in most languages and environments.
There are plenty of kernel improvements. Memory page deduplication seems kind of nice (no, not only COW, but detecting copy-on-write from pages that were not allocated with the explicit intent of being identical). Some of the revamping of Explorer could also be kept, depending on the actual intent.
'cause Trusted Computing is eeeeevil. But I start to think that even as a guy using a compiler with a frequency thousands of percent over the mean, it would make sense for most binaries I compile to run in a very limited jail.
Yes, they are on the same level, but the point in healthy competition is that you do not rely on the benevolent actions of the parties involved. A Microsoft and an Apple, with the same inherent company values and attitudes, are far better for the marketplace than just having either of them.
Well, if you want that kind of resource, Amazon is very happy to sell it to you these days. In 2008, it was still a novel concept. Assuming that a government project should be able to spearhead such a development, especially with a huge one-time investment in hardware, that's the real stupidity.
You still need fair power and cooling facilities to make any use of them, as well as some sysadmin staff to set up and maintain the queuing system. If an outdated cluster was kept intact, you could possibly benefit from already solving the utilities and system setup issue, but if they are dividing it into pieces, those benefits are also lost.
A dollar sign in international text is frequently assumed to be USD. It's certainly not "[mentioning] no currency".
Several techniques have been used, but e.g. Kepler is relying on observing repeated dimming. Considering the massive-throughput approach of Kepler, you can hardly say that it represents an outdated method.
For Kepler among others, time itself is of the essence. To get a sure signal, they need several occlusion events (in the plane towards us). If a planet has a long orbital period (year-like), it will take a few... years before a really strong signal of several repeated events is recorded.
All current input hardware uses fairly rectangular input grids. However, this is often far from the truth. A digital camera contains pixels, but each pixel is covered by a color filter. In a JPEG from the camera, all pixels are represented (and compressed), but some information is already only a result of interpolation. This is one reason for why RAW is preferable, no lying about the information around. One could make hexagonal sensors or sensors with varying pixel density for a greater and more affordable field of view, or weird lens designs where the projection is not rectangular. If you have vector or mesh-free image data you have much greater freedom in designing both input and output methodology.
The main problem of the experiments of the Watson-Crick era was that the diffraction pattern was created by the average along the helix, so you could not really discern individual nucleotides. Considering diffraction by itself to somehow be inferior to transmission techniques is not very convincing, in my opinion. It's not even like the scientists can visually see this with their own eyes - and even if they could, the interpretation would be totally dependent on the design of the equipment, just like reconstruction of diffraction data is dependent on a number of assumptions.
What's relevant and interesting is the fact that we get close to observing individual molecules of DNA in detail, but that could be done with techniques for single-molecule diffraction as well.
It's the Shadows! Stop Clark before it's too late!
Programming, in this sense, is applied method calling into your supporting libraries and framework. It has more similarities to designing a nice-looking Word template or using Excel in not overly creative ways. If a programmer of this kind ends up designing her own algorithms or even worse a full class hierarchy, it will surely end up on thedayilywtf. The thing is, they should not need to. You don't expect a household electrician to rewire stuff with a new transformer design just because it seemed fun to do for one specific customer and maybe 10% more efficient. You do standard stuff in standard ways. It's not trivial, but it's all done within well-defined bounds.
I would never want this kind of a job, but if you consider how many things that are still done manually in one way or another by people having GFLOPS on their desktops, it's also obvious that cheaper and more plentiful access to people able to just crank out code to do stuff has a tremendous value.
600 000 000 meters making 50 000 000 meters peanuts. Sure, they are different, but not that different. For an effective energy weapon, you are probably not fine with say 1 % efficiency, so beam collimation becomes crucial. If the energy you are hitting the enemy with is a mere fraction of the energy you need to dump off safely from your own ship, you are in trouble. (Incidentally, that makes big defensive weapons based on atmosphere-devoid planetary bodies all the more realistic.)
No 2.5" 120 GB existed in 2001 either. 60 GB was a high-end laptop option in 2004. The first 1 TB desktop drive was released in 2007. And according to an old Engadget posting, the 120 GB Momentus was a big deal in 2005. Now, 7 years is of course a long time, but it's almost half of what you claimed. The minimum storage need for a modern OS has barely increased in that time, with the exception that you might to some extent have dual userspaces if you used to do only 32-bit and now support 64 as well as 32.
why the NASA engineers want to take such a risk
Similar to some devices here on Earth, the rover should have an automatic revert solution. For instance, a non-updatable software running on a separate processor detects specific conditions (like no signal from Earth for a while) and flashes back the updatable software to its original version when that condition occurs.
Such things tend to be present, but how many times have they tested the automatic revert in actual conditions? An alternative codepath is always a risk.
Updating the software can have great advantages. Only a slightly more reliable connection would allow vast amounts of more science to be done. Adapting the algorithms for autonomous functions such as simple navigation or sample processing also makes a great difference when your lag time for a single command is measured in terms of minutes and you don't even have that level of "real-time" access most of the time.
From your link: "What is the evidence, then, that QDOS was a derivative work – a rip-off? The answer lies in the API, which describes how software can call up the underlying operating system and make it work for the user. The first 26 system calls of MS-DOS 1.0 are identical to the first 26 system calls of CP/M."
Yeah, just like Linux and WINE are rip-offs. The need to map system calls by number and not only name was of course due to the fact that the actual calling mechanism worked by number. However, the IEEE article is still strange, since the matters described are already settled. On the other hand, the legend of DOS being stolen and not only a clone lives on, in some places.