It apears that you are set in finding a "windows installer" type installing program that if it varies, won't fit the bill. I'm not saying that the mandrake urpmi is perfect but, I am saying that it has solved most if not all the problems being spouted as whats holding linux back. The refusal to except the fact that there are viable solutions availible is what is really holding linux back on the desktop. there is no need to cater to 100 users in a world of 1,000,000 users that will never need the stuff. linux will just work for 99% of the users using microsoft right now that yuo would call grandma.
A Windows installer would be the least desired, but workable solution. The best solution is something like Apple where the application is entirely self-contained (including most dependencies). I've heard a few people complain about this idea as it could potentially result in duplicated code. However, the reality is that you'll never need many of these code files more than once. i.e. I have one video player, one music player, one office suite, and one web browser. While you may double up some of those, you are unlikely to run both applications at the same time. Thus I may have two copies of libogg, but only one gets loaded at a time. This results in only minor amounts of disk space being "wasted" in exchange for a cohesive, easy to use experience.
URPMI/YaST/RedCarpet/apt-get is great for updating your open source software. But regular, run of mill users will want to install their commercial games, recipe programs, database software, etc. that they may not want to OS alternative of. Linux *has* to support that if it wants to be a Desktop system rather than a Workstation OS.
FWIW, I am well versed in different OSes and much prefer BSD over Linux. I started my experiment to see if Linux had really reached the "easy to use desktop" level that has been recently advertised. My conclusion is that Linux is getting close, but the "compile from source" mantra has to be abandoned if Linux wishes to be a true desktop competitor. Of course, I wouldn't have to repeat all of this if you had just *read* my journal.
And YES, doing the same thing in c/c++ requires more discipline, but then, when did this become about lowering the bar constantly?
It's not really about lowering the bar. Managers try to make it about lowering the bar, but it's really about better structure, reliability, and security. Unfortunately, those same features can be used for a short term gain, while spelling a long term system collapse.
A decent c/c++ programmer will get you the same result, and it'll be leaner in its resource requirements, faster in execution, etc..
Let's be honest here. The dynamic code loading abilities alone would take a tremendous number of resources, even for an experienced developer. A security framework like Java's simply couldn't be forced upon the system, and exception trapping in C++ still can manage to allow things like general protection faults which will kill the program dead. (e.g. Null pointers are a common source of GPFs.) Java does not suffer from these issues. A null pointer will put one user of the system out of commission, but the rest of the system will continue on. And hot-deploy capabilities can be used to fix the faulty code without impacting users. This leads to higher availability than a C++ system could easily offer.
Where are the apprenticeships? Back in the day, you were an apprentice for a long time BEFORE you got to touch production-level code.
When the people paying for code believe that it's just a matter of throwing more people at the problem, you end up with issues like the DotCOM boom and the Indian outsourcing. It *looks* cheaper on paper, but it will easily kill the company in the long run. I think that a lot of large companies are going to have to die or reach near death before the message will get through. In the meantime, I fear for the US and world economies.
More and more, complex ideas will be made obsolete by new programming techniques, developers will get lazier and lazier. Knowledge will be forgotten.
Thankfully, there will still be people like you and I left. As the large companies enter collapse, we'll be right there starting or supporting small companies who will fill the vacuum.
Apparently sir, it is easier for you to spout off at the mouth rather than take 5-10 minutes to read through a very involved review of the various Linux OSes. In doing so, you have gone on to make a fool of yourself.
Please explain to me how one would go about doing a "urpmi --install Microsoft Office" ? Or a "urpmi --install Oracle"? Are you attempting to tell me that the source code for third party applications are available under urpmi? That's one impressive system!
The specific example I used was VLC. I found a site that had (supposedly) a prebuilt RPM, plus all the dependencies. However, I found that a great deal of the dependencies were missing (e.g. libtheora, w32codecs, etc) that I have little reason to believe would be in urpmi either. (A quick check of Mandrake's RPM list confirms that w32codecs is missing).
Even if we assume that we can build the missing packages from source, how do you expect Grandma to figure out 'rpm --build'? This is NOT ease of use. If you have deluded yourself into thinking it is, then I fear that the Linux Desktop may be DOA.
Many of the developers who pushed Java early on (myself included) did so because they would rather have developed in a clean language like Java instead of the overly complex C++ language. C has been kept around for hardware interfacing and systems programming (where it always worked best anyway) but many programmers prefer Java for all high-level work.
Just because you happen to disagree with that statement does not make it bogus. If you have something to say, you can say it without attack. I am most ready to listen to other's opinions.
I DIDN'T drop c/c++, because I found Java to be a toy language and really bad at interfacing with the real world. Hardware, real-time algos, etc...
Java is hardly a "toy" on the server side. Developing a scalable, error trapping and isolating, run-time dynamic, secure C++ server would be difficult to say the least. Java provides all these features out of the box. C++ developers would have to define a framework, then walk around with a stick to make sure that everyone stays within the framework. The first idiot junior programmer to touch your system (and you know the type I'm talking about) will cause your system to have a hard down condition every time his code is executed.
I don't think "someone" should decide to make Linux one or the other. The beauty of Linux is that it can do both, and more.
"Someone" should decide. Because if no one decides, none of the distros will ever be ready for the desktop. That "someone" could be me, or it could be you, or it could be someone we've never heard of before. All that matters is that they are able to support easy to install third party software.
And at the other end of the spectrum, the HomeBase Desktop from OEone is IMHO a wonderful example of integrated, functional and easy to use Linux desktop. I wonder how many people have ever heard of HomeBase -- not many apparently if they still say "no Linux for the desktop".
Correct me if I'm wrong, but OEone is nothing more than another window manager combined with a standard set of tools. What does it do to ease third party software installation?
So this brings me to ask "just what the hell do people want?"
At the very least, I want to be able to double click on an installer and have all dependencies automagically taken care of. I don't want any RPM conflicts, and I don't want to have to track down packages myself. Even better would be like OS X. Download a DMG, it automounts, then you drag the application to whatever "Applications" folder you want to use. THAT is what I want.
1. D is not new. If this D is new, then we've got about 50 of them floating around by now.
2. Java and.Net are successful because they protect the program from complete failure. (i.e. error recovery ability) Making a C compatible language isn't going to help anything.
3. If a new popular language does come on the scene, you won't notice it until it has nearly taken over the world. Oh, and developers will love it so much they'll drop everything else (like what happened with Java).
You didn't read my journal, did you? Of course not. Otherwise you would have known that the core problem is that users often want more software than is in the auto-install programs. My perfect example is VLC. It's been out forever, but it still wasn't in SuSE's YaST library. The sheer number of dependencies I had to track down to install it was hell.
I think you'll find my recent review of Linux to be interesting and insightful. The biggest problem tends to be less of configuration. While Linux still sucks hind teat at detecting hardware, OEM machines would help solve that problem. (Anyone remember trying to get Windows 95 running?) The real problem comes down to software and dependencies. The Linux groups still think that binary is somehow evil. Therefore they go out of their way to make kernel modules kernel dependent, glibc and libc incompatible between versions, and make you track down "standard" dependencies yourself. (I'm sorry, Linux distro X doesn't have package Y standard. Deal with it.)
In any case, the core of the problem is that just because you know when and when not to use pointers, doesn't mean that the junior programmer next to you knows the same thing. In fact, he's probably writing absolute crap for what he perceives as "1337 performance". In Java, at least the idiot would be contained to his own code. (Exception trapping and all that.) In C++, he'll quite handily take down the entire system.
Even with Objects you can get in trouble. As the code gets more complex, it gets more and more difficult to decide when to release an object. Release it too soon, and you have a null pointer (sure to crash the entire daemon). Release it too late, and you have a memory leak. (Even worse as it will cause odd behavior as mallocs begin to fail.) In a perfect world, everything should be able to be released by the deconstructor, or automatically let go at the end of a method. Unfortunately, this is not a perfect world.
Sorry to burst your bubble, but that is a very real email. I myself have gotten it once or twice. There's another, more elaborate, follow-up email that explains that the guy is from the future and is trying to get back. The scary part is, he was almost convincing!
Why would we need crewed spaceships to establish new wormholes? There are robots running around on Mars now, don't you think by the time C-Ships are feasible AI will be on par (perhaps superior) with human capabilities?
While robots may be a feasible option, I have my doubts as to their intelligence and problem solving abilities. AI has primarily achieved recognition to date. Very little has been achieved in true intelligence. Most "intelligent" robots are nothing more than very sophisticated computer programs written by a highly experienced developer.
The problem with the Alcubierre Drive is that the ship inside the distortion would be unable to control its flight. It would simply be carried along ad-infinitum, or until some external force collapses the field. A wormhole OTOH, could be powered by a massive nearby fusion source that just so happens to be expending the type of energies required...;-)
Also, the Wormhole is instantaneous, while the Alcubierre drive is not. By creating a network of wormholes through the universe, humans would be able to expand outward at slightly slower than light speed. Imagine being able to take trip to the Andromeda galaxy by hopping through a wormhole network over the course of a day! With the Alcubierre drive, the ships would take years (perhaps hundreds of them) to reach the Andromeda galaxy, then take just as long to get back.
Of course, this is all academic until someone can find a way to distort space-time enough to make these concepts a reality.
The good news is that if the Universe is really shaped like a horn, then there may be more locations that can establish a wormhole than previously believed. Of course, we haven't quite worked out the physics of *building* a wormhole yet, but once C-Ships (ships that can travel at large percentages of light speed) come into service, wormholes will be a requirement to circumvent the time dilation issues inherent in light speed travel.
Just imagine, a C-Ship travels to Alpha Cetauri at near light speeds. To the people on the ship, the trip takes only a few days to weeks as from their perspective they are traveling significantly faster than light. (Of course, light seems to speed up so that to the ship occupants, light is still traveling faster than they are. If they were to measure it, they'd find that light is passing them by at the same speed it does observers on Earth! If it weren't for the stars, they wouldn't even know they were moving.) Then they get there, establish the wormhole back to Earth, and find that about 5 years have passed back home! I imagine that most crews would get payed handsomely for establishing a new wormhole, but would be unlikely to perform the procedure more than once or twice.
You actually just gave the solution. As you said, Lithium Ion and NiCad batteries are usually just AA or AAA type batteries packed inside a non-standard casing. All you need is a standard battery form, and then a bunch of non-standard plastic casings. Given the size of a 1.5 watt SRG (tiny) It should be simple to make a battery that fits any cell phone.
I wonder how much Pu-238 costs per gram? Americanium for smoke detectors is about $1500 per gram, IIRC.
I know you're being funny, but I'd like to point out something implicit in the 4 year old article: The four year old didn't install anything. All the installation and management work was done by her parents. The article's point that the GUI is easy to use is difficult to dispute. But part of using a computer as a self-sufficient adult is being able to plug in new hardware, and install your preferred software.
As my recent results showed, Grandma's only going to be okay if you're willing to come over and handle all hardware changed, and software installations. Good luck.
IANAL, but I can answer that just fine. No precedent will be set until the case reaches completion. Right now the GPL licenser feels they have a case against the licensee. The judge happens to agree with them and has ordered temporary relief. But if the case doesn't play out in the licenser's favor, then the licenser could face a suit for lose of profits and goodwill.
BTW, the cases are "SCO vs. IBM", "IBM vs. SCO", and "RedHat vs. SCO". There is no "SCO vs. Linux" or "SCO vs. BSD". A decision in this case in favor of the licenser would probably not affect the above cases as they are about claims of contract infringement and loss of goodwill.
My thoughts are that they'd make a great way to distribute data through printed media. Remember those Big Mac song "records" that McD's put in the newspapers about 10 years ago? You were supposed to play the record (and the Big Mac song) to see if you were a winner. While not quite as screwed up as that, a company could easily distribute videos, demos, music, and other interesting data elements all from the advertising section of your favorite newspaper or magazine.
all plutonium (except Pu-238 of isotopic purity greater than 80%) is regarded as equally hazardous from the point of view of diversion to nuclear weaponry.
Pu-238 is great stuff. It's only mildly hazardous, it's hot enough to generate power, and it can't be used as a fissionable material.
Not quite. Any Pu-238 taken into space is encased in an indestructable outer casing. Several launches carrying RTGs have failed, and in every case the RTG was recovered intact.
Actually, swallowing the stuff won't kill you. (All of you who believe Ralph Nader's opinion check here.) The lining of your stomach is pretty thick, and the stuff is too dense to digest. As a result, it passes through without harm. The real problem is plutonium dust that gets inhaled. It can embed itself in your soft lung tissue and increase your risk of cancer. Not to worry, pretty much the only source of such dust is machining of the material. Even when an unprotected Russian RTG burned up in the atmosphere, the smallest particles where the size of a grain of sand. Far too large to cause problems.
Keep in mind that RTGs are passive devices, not reactors. As such, the radiation dosage will never exceed that of a pound of Plutonium-238. Plutonium-238 gives off a significant amount of radiation (half life of 87 years), but it's all Alpha particles. Since the Pu-238 is emitting Alpha particles, the radiation tends not to even make it through a piece of paper, much less the indestructible casing they pack these things in. Besides, the heat generated by the Alpha particles is what gives the RTG power. Doesn't make a whole lot of sense to let your power escape.:-)
I'm still waiting for the first mission where they use SRGs (Stirling Radioisotope Generators). Those little stirling engines are far more efficient than the heat differential of RTGs. If the tech works out, it could even be a boon for lower powered devices on Earth. I figure that a tiny SRG with about 5-10 grams of Pu-238 or Sr-90 could power your cell phone for 50 years. A laptop (depending on the design) could be powered by 100-600 grams.
It apears that you are set in finding a "windows installer" type installing program that if it varies, won't fit the bill. I'm not saying that the mandrake urpmi is perfect but, I am saying that it has solved most if not all the problems being spouted as whats holding linux back. The refusal to except the fact that there are viable solutions availible is what is really holding linux back on the desktop. there is no need to cater to 100 users in a world of 1,000,000 users that will never need the stuff. linux will just work for 99% of the users using microsoft right now that yuo would call grandma.
A Windows installer would be the least desired, but workable solution. The best solution is something like Apple where the application is entirely self-contained (including most dependencies). I've heard a few people complain about this idea as it could potentially result in duplicated code. However, the reality is that you'll never need many of these code files more than once. i.e. I have one video player, one music player, one office suite, and one web browser. While you may double up some of those, you are unlikely to run both applications at the same time. Thus I may have two copies of libogg, but only one gets loaded at a time. This results in only minor amounts of disk space being "wasted" in exchange for a cohesive, easy to use experience.
URPMI/YaST/RedCarpet/apt-get is great for updating your open source software. But regular, run of mill users will want to install their commercial games, recipe programs, database software, etc. that they may not want to OS alternative of. Linux *has* to support that if it wants to be a Desktop system rather than a Workstation OS.
FWIW, I am well versed in different OSes and much prefer BSD over Linux. I started my experiment to see if Linux had really reached the "easy to use desktop" level that has been recently advertised. My conclusion is that Linux is getting close, but the "compile from source" mantra has to be abandoned if Linux wishes to be a true desktop competitor. Of course, I wouldn't have to repeat all of this if you had just *read* my journal.
*sigh*
And YES, doing the same thing in c/c++ requires more discipline, but then, when did this become about lowering the bar constantly?
It's not really about lowering the bar. Managers try to make it about lowering the bar, but it's really about better structure, reliability, and security. Unfortunately, those same features can be used for a short term gain, while spelling a long term system collapse.
A decent c/c++ programmer will get you the same result, and it'll be leaner in its resource requirements, faster in execution, etc..
Let's be honest here. The dynamic code loading abilities alone would take a tremendous number of resources, even for an experienced developer. A security framework like Java's simply couldn't be forced upon the system, and exception trapping in C++ still can manage to allow things like general protection faults which will kill the program dead. (e.g. Null pointers are a common source of GPFs.) Java does not suffer from these issues. A null pointer will put one user of the system out of commission, but the rest of the system will continue on. And hot-deploy capabilities can be used to fix the faulty code without impacting users. This leads to higher availability than a C++ system could easily offer.
Where are the apprenticeships? Back in the day, you were an apprentice for a long time BEFORE you got to touch production-level code.
When the people paying for code believe that it's just a matter of throwing more people at the problem, you end up with issues like the DotCOM boom and the Indian outsourcing. It *looks* cheaper on paper, but it will easily kill the company in the long run. I think that a lot of large companies are going to have to die or reach near death before the message will get through. In the meantime, I fear for the US and world economies.
More and more, complex ideas will be made obsolete by new programming techniques, developers will get lazier and lazier. Knowledge will be forgotten.
Thankfully, there will still be people like you and I left. As the large companies enter collapse, we'll be right there starting or supporting small companies who will fill the vacuum.
Apparently sir, it is easier for you to spout off at the mouth rather than take 5-10 minutes to read through a very involved review of the various Linux OSes. In doing so, you have gone on to make a fool of yourself.
Please explain to me how one would go about doing a "urpmi --install Microsoft Office" ? Or a "urpmi --install Oracle"? Are you attempting to tell me that the source code for third party applications are available under urpmi? That's one impressive system!
The specific example I used was VLC. I found a site that had (supposedly) a prebuilt RPM, plus all the dependencies. However, I found that a great deal of the dependencies were missing (e.g. libtheora, w32codecs, etc) that I have little reason to believe would be in urpmi either. (A quick check of Mandrake's RPM list confirms that w32codecs is missing).
Even if we assume that we can build the missing packages from source, how do you expect Grandma to figure out 'rpm --build'? This is NOT ease of use. If you have deluded yourself into thinking it is, then I fear that the Linux Desktop may be DOA.
Many of the developers who pushed Java early on (myself included) did so because they would rather have developed in a clean language like Java instead of the overly complex C++ language. C has been kept around for hardware interfacing and systems programming (where it always worked best anyway) but many programmers prefer Java for all high-level work.
Just because you happen to disagree with that statement does not make it bogus. If you have something to say, you can say it without attack. I am most ready to listen to other's opinions.
I DIDN'T drop c/c++, because I found Java to be a toy language and really bad at interfacing with the real world. Hardware, real-time algos, etc...
Java is hardly a "toy" on the server side. Developing a scalable, error trapping and isolating, run-time dynamic, secure C++ server would be difficult to say the least. Java provides all these features out of the box. C++ developers would have to define a framework, then walk around with a stick to make sure that everyone stays within the framework. The first idiot junior programmer to touch your system (and you know the type I'm talking about) will cause your system to have a hard down condition every time his code is executed.
I don't think "someone" should decide to make Linux one or the other. The beauty of Linux is that it can do both, and more.
"Someone" should decide. Because if no one decides, none of the distros will ever be ready for the desktop. That "someone" could be me, or it could be you, or it could be someone we've never heard of before. All that matters is that they are able to support easy to install third party software.
And at the other end of the spectrum, the HomeBase Desktop from OEone is IMHO a wonderful example of integrated, functional and easy to use Linux desktop. I wonder how many people have ever heard of HomeBase -- not many apparently if they still say "no Linux for the desktop".
Correct me if I'm wrong, but OEone is nothing more than another window manager combined with a standard set of tools. What does it do to ease third party software installation?
So this brings me to ask "just what the hell do people want?"
At the very least, I want to be able to double click on an installer and have all dependencies automagically taken care of. I don't want any RPM conflicts, and I don't want to have to track down packages myself. Even better would be like OS X. Download a DMG, it automounts, then you drag the application to whatever "Applications" folder you want to use. THAT is what I want.
1. D is not new. If this D is new, then we've got about 50 of them floating around by now.
.Net are successful because they protect the program from complete failure. (i.e. error recovery ability) Making a C compatible language isn't going to help anything.
2. Java and
3. If a new popular language does come on the scene, you won't notice it until it has nearly taken over the world. Oh, and developers will love it so much they'll drop everything else (like what happened with Java).
You didn't read my journal, did you? Of course not. Otherwise you would have known that the core problem is that users often want more software than is in the auto-install programs. My perfect example is VLC. It's been out forever, but it still wasn't in SuSE's YaST library. The sheer number of dependencies I had to track down to install it was hell.
I think you'll find my recent review of Linux to be interesting and insightful. The biggest problem tends to be less of configuration. While Linux still sucks hind teat at detecting hardware, OEM machines would help solve that problem. (Anyone remember trying to get Windows 95 running?) The real problem comes down to software and dependencies. The Linux groups still think that binary is somehow evil. Therefore they go out of their way to make kernel modules kernel dependent, glibc and libc incompatible between versions, and make you track down "standard" dependencies yourself. (I'm sorry, Linux distro X doesn't have package Y standard. Deal with it.)
Talk about reviving a dead thread.
In any case, the core of the problem is that just because you know when and when not to use pointers, doesn't mean that the junior programmer next to you knows the same thing. In fact, he's probably writing absolute crap for what he perceives as "1337 performance". In Java, at least the idiot would be contained to his own code. (Exception trapping and all that.) In C++, he'll quite handily take down the entire system.
Even with Objects you can get in trouble. As the code gets more complex, it gets more and more difficult to decide when to release an object. Release it too soon, and you have a null pointer (sure to crash the entire daemon). Release it too late, and you have a memory leak. (Even worse as it will cause odd behavior as mallocs begin to fail.) In a perfect world, everything should be able to be released by the deconstructor, or automatically let go at the end of a method. Unfortunately, this is not a perfect world.
Sorry to burst your bubble, but that is a very real email. I myself have gotten it once or twice. There's another, more elaborate, follow-up email that explains that the guy is from the future and is trying to get back. The scary part is, he was almost convincing!
Ah, here we are: http://www.museumofhoaxes.com/timetravelspam.html
Why would we need crewed spaceships to establish new wormholes? There are robots running around on Mars now, don't you think by the time C-Ships are feasible AI will be on par (perhaps superior) with human capabilities?
While robots may be a feasible option, I have my doubts as to their intelligence and problem solving abilities. AI has primarily achieved recognition to date. Very little has been achieved in true intelligence. Most "intelligent" robots are nothing more than very sophisticated computer programs written by a highly experienced developer.
The problem with the Alcubierre Drive is that the ship inside the distortion would be unable to control its flight. It would simply be carried along ad-infinitum, or until some external force collapses the field. A wormhole OTOH, could be powered by a massive nearby fusion source that just so happens to be expending the type of energies required... ;-)
Also, the Wormhole is instantaneous, while the Alcubierre drive is not. By creating a network of wormholes through the universe, humans would be able to expand outward at slightly slower than light speed. Imagine being able to take trip to the Andromeda galaxy by hopping through a wormhole network over the course of a day! With the Alcubierre drive, the ships would take years (perhaps hundreds of them) to reach the Andromeda galaxy, then take just as long to get back.
Of course, this is all academic until someone can find a way to distort space-time enough to make these concepts a reality.
The good news is that if the Universe is really shaped like a horn, then there may be more locations that can establish a wormhole than previously believed. Of course, we haven't quite worked out the physics of *building* a wormhole yet, but once C-Ships (ships that can travel at large percentages of light speed) come into service, wormholes will be a requirement to circumvent the time dilation issues inherent in light speed travel.
Just imagine, a C-Ship travels to Alpha Cetauri at near light speeds. To the people on the ship, the trip takes only a few days to weeks as from their perspective they are traveling significantly faster than light. (Of course, light seems to speed up so that to the ship occupants, light is still traveling faster than they are. If they were to measure it, they'd find that light is passing them by at the same speed it does observers on Earth! If it weren't for the stars, they wouldn't even know they were moving.) Then they get there, establish the wormhole back to Earth, and find that about 5 years have passed back home! I imagine that most crews would get payed handsomely for establishing a new wormhole, but would be unlikely to perform the procedure more than once or twice.
You actually just gave the solution. As you said, Lithium Ion and NiCad batteries are usually just AA or AAA type batteries packed inside a non-standard casing. All you need is a standard battery form, and then a bunch of non-standard plastic casings. Given the size of a 1.5 watt SRG (tiny) It should be simple to make a battery that fits any cell phone.
I wonder how much Pu-238 costs per gram? Americanium for smoke detectors is about $1500 per gram, IIRC.
I know you're being funny, but I'd like to point out something implicit in the 4 year old article: The four year old didn't install anything. All the installation and management work was done by her parents. The article's point that the GUI is easy to use is difficult to dispute. But part of using a computer as a self-sufficient adult is being able to plug in new hardware, and install your preferred software.
As my recent results showed, Grandma's only going to be okay if you're willing to come over and handle all hardware changed, and software installations. Good luck.
IANAL, but I can answer that just fine. No precedent will be set until the case reaches completion. Right now the GPL licenser feels they have a case against the licensee. The judge happens to agree with them and has ordered temporary relief. But if the case doesn't play out in the licenser's favor, then the licenser could face a suit for lose of profits and goodwill.
BTW, the cases are "SCO vs. IBM", "IBM vs. SCO", and "RedHat vs. SCO". There is no "SCO vs. Linux" or "SCO vs. BSD". A decision in this case in favor of the licenser would probably not affect the above cases as they are about claims of contract infringement and loss of goodwill.
Am I missing something here?
Yes. Just about every response to the original poster. *sigh*
My thoughts are that they'd make a great way to distribute data through printed media. Remember those Big Mac song "records" that McD's put in the newspapers about 10 years ago? You were supposed to play the record (and the Big Mac song) to see if you were a winner. While not quite as screwed up as that, a company could easily distribute videos, demos, music, and other interesting data elements all from the advertising section of your favorite newspaper or magazine.
I answered this question here.
:-)
Not all plutonium is created equally.
You might want to read your own link there slick:
all plutonium (except Pu-238 of isotopic purity greater than 80%) is regarded as equally hazardous from the point of view of diversion to nuclear weaponry.
Pu-238 is great stuff. It's only mildly hazardous, it's hot enough to generate power, and it can't be used as a fissionable material.
Not quite. Any Pu-238 taken into space is encased in an indestructable outer casing. Several launches carrying RTGs have failed, and in every case the RTG was recovered intact.
You have to swallow the stuff for it to kill you.
Actually, swallowing the stuff won't kill you. (All of you who believe Ralph Nader's opinion check here.) The lining of your stomach is pretty thick, and the stuff is too dense to digest. As a result, it passes through without harm. The real problem is plutonium dust that gets inhaled. It can embed itself in your soft lung tissue and increase your risk of cancer. Not to worry, pretty much the only source of such dust is machining of the material. Even when an unprotected Russian RTG burned up in the atmosphere, the smallest particles where the size of a grain of sand. Far too large to cause problems.
You can't delete files on the Mac without them first going to the Trash can. So it would be pretty hard for junior to delete anything.
Keep in mind that RTGs are passive devices, not reactors. As such, the radiation dosage will never exceed that of a pound of Plutonium-238. Plutonium-238 gives off a significant amount of radiation (half life of 87 years), but it's all Alpha particles. Since the Pu-238 is emitting Alpha particles, the radiation tends not to even make it through a piece of paper, much less the indestructible casing they pack these things in. Besides, the heat generated by the Alpha particles is what gives the RTG power. Doesn't make a whole lot of sense to let your power escape. :-)
I'm still waiting for the first mission where they use SRGs (Stirling Radioisotope Generators). Those little stirling engines are far more efficient than the heat differential of RTGs. If the tech works out, it could even be a boon for lower powered devices on Earth. I figure that a tiny SRG with about 5-10 grams of Pu-238 or Sr-90 could power your cell phone for 50 years. A laptop (depending on the design) could be powered by 100-600 grams.