Some quick googling revealed that the Vikings RTGs generated 40 watts of power and weighed 26 kg. The Spirit's solar cells generate up to a peak of 140 watts of power. The Viking probes were not mobile, and they weighed about 3X as much as the rovers without rocket fuel. Moreover, the Vikings were not a "low-cost" mission, and they used fuel-hungry retro rockets to do a soft touchdown on the surface (further increasing launch weight). The retro rockets meant that they did not need to be wrapped up in a bunch of balloons for extended periods of time.
It seems that the RTGs did not provide more energy or enable less launch weight than the solar cells. In fact, if high-performance solar cells had been available in the 1970s, perhaps the vikings wouldn't have used RTGs either.
If they don't mind it, then let's send up those dune buggies with RTG and 18-inch wheels and cover a lot more of Mars.
I don't know, but I'd guess that for rovers of this size and weight, it might be easier to use solar panels than to figure out how to dump all of the waste heat that an RTG would produce. These devices are highly inefficient in terms of converting thermal energy to electrical energy, so they are probably spewing kilowatts of thermal energy at all times, and there's no way to shut them off.
That would pose two immediate problems: with the el-cheapo balloon-based reentry system used, how do you keep the rover from frying when it's wrapped up in its airbag cocoon? The only way would seem to be a heat sink, but that would add significant weight to the spacecraft.
The second problem would be how to radiate all of that heat during operation. The outer planet probes have spindly rods that hold the RTG a few meters away from the main body. A rover couldn't do this and maintain balance, so you would need some kind of closely attached radiator with liquid cooling and/or heat shielding to protect the main unit from the intense heat. Once again, this could end up being heavier than simple solar panels.
You need abstractions to basically the whole underlying OS, which is something the Java
class library provides.
However, the generic OS interfaces provided by the Java class library don't cover much more ground than what the POSIX-ish API subset provided by Windows covers. So you can already write relatively portable code in C++ that will run on both *nix and Windows.
At any rate, if you're willing to drink the Qt kool-aid, Qt itself provides a bunch of portable generic utility classes to address this same issue.
However, for every voter who votes against software patents, there are 1000 more logic-impaired voters who will pick whichever candidate who says they'll simultaneously cut taxes and increase government handouts.
Re:I agree with the Foundation, but WTC?
on
FreeBSD 5.2 Review
·
· Score: 1
There is a reason why NASA chose to go with a Motorola chip on the Spirit and Opportunity Mars rovers. That reason is because when billions of dollars are on the line you simply can't trust Intel's architecture to deliver efficiently and reliably.
Well, whatever they used, it's hasn't been behaving much better than Windows 95 running on an early Pentium-I stepping.
But like I said, the robot program could have a 20-year head start on the first astronaut to set foot on mars. Latency or not, you'd get the results sooner.
As for touch and smell, sample return missions could provide that.
Perhaps they should have built a real wireless device rather than taking away CPU time for something that is best handled by a seperate device.
Intel's entire strategy over the last 10 years has been precisely to move as many functions as possible into the CPU. This enables them to justify selling processors with far more horsepower than anybody needs for word processing or browsing, and it lets them assert control and influence over a much larger fraction of the hardware market.
That's why they keep adding more multimedia-oriented units to their architecture; it's also why they designed the P4's memory architecture to be mainly good at streaming blocks of video data.
Their strategy has been relatively successful up to now. There's just no way that they would design a totally stand-alone wireless solution to be tightly marketed with their CPUs.
In fact, just from the Centrino marketing material, you'd get the impression that the CPU itself is handling the wireless functions. Perhaps they plan to move that logic into a future mobile CPU chip.
I disagree. If we were serious about sending probes, we could send hundreds of probes over the next decade. We could set up robotic base stations staffed with remote-controlled assemblers that could reconfigure and service modular probes that wander the surface. The stations could be regularly supplied with shipments of new science experiments and rover parts. All of this would cost a mere fraction of a single human mission, and it could run any experiment a human could.
It may take longer to do any one experiment remotely, but we could get such a program underway in a couple of years, vs. decades and hundreds of $Billions before the first human sets foot on Mars. We would end up getting the results at an earlier date.
It may still be worth it to send humans to Mars, but we need to admit that the only justification for undertaking such a mission is the same as that for climbing mountains: "because it's there".
IIRC, Eno also composed the "Microsoft Sound" played at the startup of Windows95. (Actually, I would still rank that as one of the best efforts in the peculiar genre of OS login sounds.)
They are my works, I should be able to direct how they're used, and allow the transfer of that direction to others. Forever.
You can already do this. Just keep your works secret, and you'll have total control over them forever, and you won't have to foist your ridiculous infinite copyright extensions on the rest of us.
*cough* wider data busses *cough*. 'course this does mean that 64 bit code on systems with 32 bit wide data paths will be slower
By the same token, 32-bit code on systems with 64-bit wide data paths will move twice as many pointers in one bus cycle.
Today's CPUs almost completely decouple buses from ALU-level operations. Buses usually spend most of their time transfering entire cache lines to service cache misses, so if your pointers take up a bigger portion of a cache line, 64-bit code is still consuming more bus clock cycles per instruction on average no matter how wide your buses are.
BTW, 32-bit processors have been using 64-bit external data buses since the days of the Pentium-I.
In the coming days, if communications are not restored, the spacecraft will enter safe modes that cause it to try harder to transmit and will reset subsystems.
Hopefully, that would work. However, it will be pretty annoying if all of the images it sends back after that are 16-color 640x480 GIFs with the words "Safe Mode" overlayed in the four corners.
Slower? There's just one more pass involved (an OR in the letters) which you parse anyways.
It's only an OR operation in English and maybe a few other languages. In general, mapping uppercase to lowercase depends on the language and locale currently in use. Moreover, certain languages don't have a 1-to-1 mapping between uppercase and lowercase letters.
It seems to me that this would mainly be a source of subtle conversion bugs for people who use identifiers that aren't in ASCII english.
But if downloading copyrighted music over P2P isn't "stealing" then this sure as shit isn't "burglary".
The music data was openly offered to the public by a publishing company. The congressional files were private confidential data. No matter what you call it, there is a fundamental difference.
How many embedded devices are running 64-bit processors now?
I believe that the 64-bit capable MIPS architecture found it's biggest success in the embedded processor market. From the wikipedia entry:
In recent years most of technology used in the various MIPS generations has been offered as building-blocks for embedded processor designs. Both 32-bit and 64-bit basic cores are offered, known as the 4K and 5K respectively, and the design itself can be licenced as MIPS32 and MIPS64. These cores can be mixed with add-in units such as FPUs, SIMD systems, various input/output devices, etc.
MIPS cores have been very successful, they form the basis of many newer Cisco routers, cable modems and ADSL modems, smartcards, laser printer engines, set-top boxes, handheld computers, and the Sony PlayStation 2.
If you'd pay proper attention to Sun's marketing machine, you'd remember that Java uses a just-in-time compiler. What does a compiler do? It turns all of your "object-oriented is the only valid programming paradigm" source code into a big bucket of CPU-specific opcodes, numbers and *pointers*.
In fact, it will probably have more pointers than the corresponding C or C++ program would have, due to the plethora of tiny objects you're encouraged to spawn. Naturally, the pointer size would match the CPU architecture on which the program is being run and would consume a corresponding number of cache bytes.
The result can be seen when you try to program a caller frame instance-preserving continuation in Python. The only thing that works is an unportable stack smashing like ole C's longjumps with added occultism with the garbage collector.
This is a bigger problem than you might think, I often see young programmer to use Python at the start of projects because it's good for fast hacking. But when the project advances they suddenly notice that python doesn't provide all necessary features and a whole rewrite is in order.
Yeah, it's really sad how many large projects fail because they're implemented in a language that doesn't properly support continuations....
Wait a minute, I've been in the computer industry for decades, and other than myself, I could probably count on one hand the number of people I've met who even know what a continuation is. Other than as an amusing tool to utterly confuse any but the most advanced developers, continuations are probably only useful for coroutines, and coroutines are mostly useful for iterator generators, which recent versions of Python have generators nicely packaged in an easy-to-understand syntax (the yield statement).
Since few if any other popular languages give you even this much, it must be truly amazing that any software works at all.
Python doesn't have static typing; it has dynamic typing like Lisp, Ruby, Perl, etc. The difference between Python and Perl is that Perl has rather weak dynamic typing. For example, Perl tries to treat strings and numbers as the same type (resulting in the use of strange constructs such as the value "0 but true"). Python and most other dynamically typed languages have stronger typing, with distinctions between strings, integers, floats, etc.
Static typing means that each variable is only allowed to hold values of one type. Usually the variable types are manually declared (as in C or Java), but some languages (like Haskell, IIRC) can infer the types.
The proclaimed trade benefits for the poor countries never happened
Last time I was at Wal-Mart, I was thinking: Gee it's sure a shame that China hasn't benefitted from trade agreements. They only produced a token 80% of the stuff in this store. Clearly, we need to do more.
Slashdot Mirror
Some quick googling revealed that the Vikings RTGs generated 40 watts of power and weighed 26 kg. The Spirit's solar cells generate up to a peak of 140 watts of power. The Viking probes were not mobile, and they weighed about 3X as much as the rovers without rocket fuel. Moreover, the Vikings were not a "low-cost" mission, and they used fuel-hungry retro rockets to do a soft touchdown on the surface (further increasing launch weight). The retro rockets meant that they did not need to be wrapped up in a bunch of balloons for extended periods of time.
It seems that the RTGs did not provide more energy or enable less launch weight than the solar cells. In fact, if high-performance solar cells had been available in the 1970s, perhaps the vikings wouldn't have used RTGs either.
I don't know, but I'd guess that for rovers of this size and weight, it might be easier to use solar panels than to figure out how to dump all of the waste heat that an RTG would produce. These devices are highly inefficient in terms of converting thermal energy to electrical energy, so they are probably spewing kilowatts of thermal energy at all times, and there's no way to shut them off.
That would pose two immediate problems: with the el-cheapo balloon-based reentry system used, how do you keep the rover from frying when it's wrapped up in its airbag cocoon? The only way would seem to be a heat sink, but that would add significant weight to the spacecraft.
The second problem would be how to radiate all of that heat during operation. The outer planet probes have spindly rods that hold the RTG a few meters away from the main body. A rover couldn't do this and maintain balance, so you would need some kind of closely attached radiator with liquid cooling and/or heat shielding to protect the main unit from the intense heat. Once again, this could end up being heavier than simple solar panels.
Sure it contains a lot of stuff, but the issue at hand was OS abstraction APIs. That's only a small fraction of the libraries.
However, the generic OS interfaces provided by the Java class library don't cover much more ground than what the POSIX-ish API subset provided by Windows covers. So you can already write relatively portable code in C++ that will run on both *nix and Windows.
At any rate, if you're willing to drink the Qt kool-aid, Qt itself provides a bunch of portable generic utility classes to address this same issue.
However, for every voter who votes against software patents, there are 1000 more logic-impaired voters who will pick whichever candidate who says they'll simultaneously cut taxes and increase government handouts.
Well, whatever they used, it's hasn't been behaving much better than Windows 95 running on an early Pentium-I stepping.
As for touch and smell, sample return missions could provide that.
As I said, we can find all of those things you're looking for without sending a manned mission.
Intel's entire strategy over the last 10 years has been precisely to move as many functions as possible into the CPU. This enables them to justify selling processors with far more horsepower than anybody needs for word processing or browsing, and it lets them assert control and influence over a much larger fraction of the hardware market.
That's why they keep adding more multimedia-oriented units to their architecture; it's also why they designed the P4's memory architecture to be mainly good at streaming blocks of video data.
Their strategy has been relatively successful up to now. There's just no way that they would design a totally stand-alone wireless solution to be tightly marketed with their CPUs.
In fact, just from the Centrino marketing material, you'd get the impression that the CPU itself is handling the wireless functions. Perhaps they plan to move that logic into a future mobile CPU chip.
It may take longer to do any one experiment remotely, but we could get such a program underway in a couple of years, vs. decades and hundreds of $Billions before the first human sets foot on Mars. We would end up getting the results at an earlier date.
It may still be worth it to send humans to Mars, but we need to admit that the only justification for undertaking such a mission is the same as that for climbing mountains: "because it's there".
The problem with the industry these days is that the filter seems to be clogged.
IIRC, Eno also composed the "Microsoft Sound" played at the startup of Windows95. (Actually, I would still rank that as one of the best efforts in the peculiar genre of OS login sounds.)
You can already do this. Just keep your works secret, and you'll have total control over them forever, and you won't have to foist your ridiculous infinite copyright extensions on the rest of us.
By the same token, 32-bit code on systems with 64-bit wide data paths will move twice as many pointers in one bus cycle.
Today's CPUs almost completely decouple buses from ALU-level operations. Buses usually spend most of their time transfering entire cache lines to service cache misses, so if your pointers take up a bigger portion of a cache line, 64-bit code is still consuming more bus clock cycles per instruction on average no matter how wide your buses are.
BTW, 32-bit processors have been using 64-bit external data buses since the days of the Pentium-I.
At least the hobby guy is learning something while you're sitting on your passive ass watching reruns.
They already can't steal your collection... because it's currently not illegal.
You're proposing solving a problem that doesn't yet exist by creating the problem itself.
Hopefully, that would work. However, it will be pretty annoying if all of the images it sends back after that are 16-color 640x480 GIFs with the words "Safe Mode" overlayed in the four corners.
It's only an OR operation in English and maybe a few other languages. In general, mapping uppercase to lowercase depends on the language and locale currently in use. Moreover, certain languages don't have a 1-to-1 mapping between uppercase and lowercase letters.
It seems to me that this would mainly be a source of subtle conversion bugs for people who use identifiers that aren't in ASCII english.
The music data was openly offered to the public by a publishing company. The congressional files were private confidential data. No matter what you call it, there is a fundamental difference.
I believe that the 64-bit capable MIPS architecture found it's biggest success in the embedded processor market. From the wikipedia entry:
If you'd pay proper attention to Sun's marketing machine, you'd remember that Java uses a just-in-time compiler. What does a compiler do? It turns all of your "object-oriented is the only valid programming paradigm" source code into a big bucket of CPU-specific opcodes, numbers and *pointers*.
In fact, it will probably have more pointers than the corresponding C or C++ program would have, due to the plethora of tiny objects you're encouraged to spawn. Naturally, the pointer size would match the CPU architecture on which the program is being run and would consume a corresponding number of cache bytes.
Here's the business plan for the private exploration and colonization of Mars:
1. ???
...
2. ???
3. ???
4. ???
98. ???
99. ???
100. Profit!!!
Yeah, it's really sad how many large projects fail because they're implemented in a language that doesn't properly support continuations....
Wait a minute, I've been in the computer industry for decades, and other than myself, I could probably count on one hand the number of people I've met who even know what a continuation is. Other than as an amusing tool to utterly confuse any but the most advanced developers, continuations are probably only useful for coroutines, and coroutines are mostly useful for iterator generators, which recent versions of Python have generators nicely packaged in an easy-to-understand syntax (the yield statement).
Since few if any other popular languages give you even this much, it must be truly amazing that any software works at all.
Python doesn't have static typing; it has dynamic typing like Lisp, Ruby, Perl, etc. The difference between Python and Perl is that Perl has rather weak dynamic typing. For example, Perl tries to treat strings and numbers as the same type (resulting in the use of strange constructs such as the value "0 but true"). Python and most other dynamically typed languages have stronger typing, with distinctions between strings, integers, floats, etc.
Static typing means that each variable is only allowed to hold values of one type. Usually the variable types are manually declared (as in C or Java), but some languages (like Haskell, IIRC) can infer the types.
Last time I was at Wal-Mart, I was thinking: Gee it's sure a shame that China hasn't benefitted from trade agreements. They only produced a token 80% of the stuff in this store. Clearly, we need to do more.