He could have updated the module to delete and format the contents of every machine it was run on. I'm kind of surprised this hasn't happened before considering how many modern environments have such slapdash dependency systems.
Exactly, this is a tempest in a teapot unless there is more information. One needs to show that the effect of electronic versus hand-counted votes on the election is statistically independent of the composition of the population (race, median income, M/F ratio, etc.) of each district. Probably districts where hand-counting is still used are on average poorer than those with e-voting machines, for instance.
The linked site makes a first stab at this by breaking down the data into "small towns", "medium towns" and "large towns", but that's only a start at making a real convincing argument. As the parent states, a comparison of the difference %(Obama) - %(Clinton) to the same quantity in the exit poll results, in hand-counted vs. e-voting districts, would be much more convincing. (Note, I say this as someone who much prefers Obama over Clinton.)
The latest in-depth discussion I could find on debian-legal is this one from July:
link
The gist of it is that most of the proposed GPL3 seems OK, there are only a few problematic clauses.
This specific message by Francisco Poli has an in-depth analysis:
link
Actually, GNUzilla and IceWeasel are existing GNU projects to make FREE versions of Mozilla and FireFox. The name IceWeasle did not come from the Debian group alone.
Wikipedia says that it was originally coined by Nathanael Nerode in 2004 on the debian-legal mailing list.
And what happens when upstream is no longer interested in supporting the version of Firefox in Debian stable (or even oldstable), as is the case for Firefox 1.0.4 in Sarge? Mozilla stopped supporting the Firefox 1.0.x line in May, about 7 months before the scheduled release of Debian Etch, and 19 months before the expected end of security support for Sarge.
Firefox remains the same, Debian's the one that doesn't come with Firefox. Why they didn't just move it to non-free is beyond me.
The software is completely DFSG-free aside from the icons and trademark. What a waste it would be to move it to non-free just for the sake of these two easily removable things!
There's a related argument (I know you didn't make it) that Debian could at least make Firefox available from non-free in parallel with IceWeasel in main. Unfortunately it would be a nightmare for the security team to have TWO slightly different versions of the browser in Etch, considering the monumental task it is just to support ONE.
The Linux kernel is GPL. Anything linking to it must, as per the 'strict' interpretation that you mention (and that makes the most sense to me) therefore be GPL as well. Yet e.g. GNOME (which I can only assume does lots of calling to kernel functions) is LGPL and not GPL.
(I assume you meant to have the above "not" that I inserted for you.)
Good question, and I had to research this. Fortunately, in the case of the Linux kernel, the copyright holders (at least Linus) have clearly stated that they do not consider user space programs calling the kernel through clearly defined interfaces to be subject to a strict interpretation of the GPL with respect to dynamic linkage. Otherwise I agree that it would be a potential problem.
(This is basically a mirror image of the reverse case in which the GPL specifically permits shipment of GPL'ed applications linked against proprietary libraries that make up part of the OS, e.g. on Windows - but in this case the extra permission is provided by the Linux copyright holders' interpretation rather than the license text itself. The copyright holders' interpretation is always as important as the license, see for instance the case of PINE and U. Washington.)
I also have issues with the whole concept of linking (dynamic or static) and how that translates to languages/platforms which don't work the same way as C. For example, Java doesn't link at all - your code simple asks the classloader to load a class from "somewhere" and if it gets one which it can use, great. The classloader could have got it from anywhere - the filesystem, a web server, a database, whatever. As an application developer you don't really have any control over what the rutime classpath is - you could distribute with a BSD licensed impl of some interface and then have a user switch that for a GPL one. Are you now suddenly in violation of the GPL because your app accidentally "linked" itself to a GPL lib? Even in the traditional C world I can see issues with things like plugins. Imagine the scenario where you create a closed-source app which allows third parties to develop plugins as DLLs (or.so or whatever). If someone creates such a plugin and GPL licenses it, what happens when your non-GPL app links to it dynamically just because it was in the plugins directory at runtime?
These are indeed very hard questions! I'll give my opinion, but IANAL, this isn't intended as legal advice, I don't have any real evidence for my views, and they might even be partly self-contradictory. My personal feeling is that optional plugins that are dlopen()'ed at runtime do not constitute a derived work together with the application binary and any libraries it was linked against at build time. This is because the application can function without the plugin, so app + libraries without plugins can already be looked on as a complete work. (The only place where app + libraries + plugins are ever all combined is in RAM on the user's computer.)
If you are writing a proprietary program that loads optional plugins, perhaps you could work around the issue of a GPL'ed plugin "booby trap" in any case by specifically stating in the EULA that use of the program with GPL code is unacceptable:-)
If the plugin is mandatory (so the question is only of swapping it out for a differently-licensed plugin that does the same thing), it's essentially the same question as with dynamic linking to libraries. In that case, suppose there are a GPL library and a BSD lib that are ABI-compatible. If you compile your app and link dynamically against the BSD library, then distribute the app, I can't see how you could be held responsible for a GPL violation just because the user had the GPL version of the library installed at the time. Similarly for Java, if there's at least one implementation of a class that is legally permissible for your code to use, I think legally you must be in the clear. Don't ask me how complete an implementation needs to be in order to count!
When things are uncomplicated - specifically, in the case of a GPL library linked in dynamically at compile time, for which only the GPL implementation exists - I tend to believe the strict interpretation of the GPL (at least, as a Debian developer, it's legally safest for me to do so). But at some point there's certainly a line beyond which the GPL can no longer "infect" other code.
One question I've wondered about the GPL. If I write a program that links to a shared library that is GPL'd, do I need to GPL my application as well?
There are two schools of thought on this, and the answer to your question is pretty hotly debated.
The "stricter" school of thought, unsurprisingly the one favored by the FSF, is that statically or dynamically linking an executable to a library forms a work which can be considered a derived work of both sets of code. Under this theory, your application's source code doesn't have to be GPL, but its license does have to be compatible with the GPL since the linked work (app + library) taken as a whole is in part derived from the library and hence must be under the GPL. For instance, your app's source code could be licensed as LGPL or two-clause BSD in this situation with no problem, but could not be (for instance) CDDL or 4-clause BSD. Most Linux distributions follow this stricter, more conservative view.
On the other hand, it has been pointed out that this strict interpretation can sometimes lead to a peculiar conclusion. Suppose a work-alike copy of a GPL library is written from scratch and licensed permissively. Then a program linked against the GPL lib could also be used with the permissive library that forms a drop-in replacement. The strict theory of linking then implies that the license of your application is GPL if the GPL library is on your system, but not if the replacement library is instead. If this is not an acceptable conclusion, then it must be that dynamic linking against a GPL library does not make the application be under GPL as well.
This looser interpretation effectively defangs the GPL and makes it essentially equivalent to the LGPL, because anyone could change GPL'ed code they want to use into a shared library, then link their proprietary application against it.
Note that the interpretations differ only in the case of dynamic linking. When an application is linked statically against a GPL library, parts of the library object code end up in the compiled executable and therefore this is indisputably a derived work of both application code and library, hence under GPL. Proponents of the strict interpretation point out that from an end-user's viewpoint, there is no difference between static and dynamic linking other than the "-static" flag given to the linker, so the two methods of linking should not be legally distinguished either.
To the best of my knowledge (IANAL) there isn't any legal precedent favoring either interpretation.
This article reminds me very much of the human cancer cell line
HeLa. I first heard
about it in a biology class in high school, years ago. It is
a cancer cell derived from a single person's cervical cancer around 1950,
which is sufficiently fast-growing that (according to the Wiki article)
it forms a common "weed" in lab cultures. It has even controversially been
named a new species. Thankfully, unlike the dog cells,
the HeLa line doesn't seem to be able to infect living humans (yet...)
He does one choose users, aka developpers on debian?
But seriously, no FUD: How do they work to trust their developpers.
I can't imagine I'm writting a little tiny app, knock on the debian door and they would open it. This is user trust policy.
You raise two different questions: how can Debian Developers be trusted, and how can the code that ends up in Debian be trusted.
For the first case, there is an extensive New Maintainer application process. This includes tests to see whether the applicant knows what s/he is doing, questions to see whether s/he understands and agrees with the philosophies of the Free Software movement, and a GPG key check to make sure that at least one current developer has met and verified the identity of the applicant. Additionally the applicant is supposed to have a history of doing good Debian work. At least two individuals, an Application Manager and one of the Debian Accounts Managers, independently research the applicant. (Only the DAM knows how extensive this research is but I have reason to believe it is quite thorough.)
For a package maintainer who isn't a Debian Developer yet, all his/her work goes through a developer sponsor who reviews it carefully. Only the maintainer's source package is used (not binary.debs), and it is rebuilt into.debs by the sponsor before upload. The sponsor takes particular care to ensure that the upstream source code ("orig.tar.gz" file) used by the maintainer is identical to that available from upstream's web site. Since the sponsor takes the final responsibility of uploading this person's work, s/he has an incentive to make sure everything is OK with it.
This ties into the second question. Even for a package uploaded by a Debian Developer, there is first supposed to be an Intent To Package announcement posted on the debian-devel mailing list (here's an example; notice that this isn't just a rubber-stamp procedure; the example I gave led to a lot of discussion). The developer is expected to review the source code, as much as is reasonable, to make sure there are no trojans built in. With each new revision by upstream, the developer reviews the full diff between versions.
Of course neither procedure is foolproof. Someone with enough dedication, intelligence, and malevolence could manage to get through the New Maintainer procedure and do what you suggest. Or an upstream that was clever enough to write well-disguised trojan code could trick a developer into uploading it into the Debian archive. (There was actually an example of this happening, though the trojanned code wasn't harmful; see this thread. Needless to say this didn't help the upstream author's New Maintainer application.) But these are risks in any software project, not only Debian and not limited to Free/open source software.
License and FAQ about the license under which these packages are made available (note in particular that it permits sublicensing for derived distributions).
Go download mod_security and look at the license, it is GPL.
That's actually the reason it was removed from Debian; from what I gather, it uses Apache headers that are licensed under the Apache License, which is apparently incompatible with the GPL. Here's the relevant bug: #313615
Disclaimer: I haven't done enough research to have an opinion on whether this removal was justified or not.
They should be able to compile this source code on any hardware architecture they choose (assuming they haven't assumed size of variables, etc.: the same stuff that trips up native ports).
Personally, I wouldn't put good odds on commercial Windows-only apps not making assumptions about endianness and pointer size (32-bit vs. 64-bit). Heck, even OpenOffice.org hasn't been completely ported to 64-bit systems yet, and it hasn't been proprietary (in the form of StarOffice) for several years now.
The other thing is that, if I understand correctly, these ports Google makes are still going to be closed-source. For there to be a PowerPC or SPARC version, Google has to explicitly decide to recompile the programs and link against Winelib on those platforms. Since there is less demand for non-x86 Linux apps on the desktop than x86 Linux desktop apps, I don't expect them to go to the trouble—especially now that Apple is switching to Intel chips.
I am a normal user and not a graphic designer. Thus, I do not use complicated features in Photoshop or GIMP, just the low level features. One of these, however, is crop. And crop sucks on GIMP. With Photoshop it is simple, I put a box around what I want to crop to and I crop.
I'm no graphic designer either, so maybe I misunderstand what you mean, but you can do exactly that in GIMP. (I'm not trying to defend GIMP's shortcomings, but I don't think it deserves this particular criticism.) Using the select tool, create a rectangular selection in the image. Then, right-click on the image to get the context menu, and select "Image->Crop Image". Am I missing something here?
On a non-humorous note, there is the old saying "Give a man a fish..." If this project is done well, I can see this being a much better investment to combat poverty in the long run than just giving people free food. A child with a laptop and an internet connection has a chance to learn a lot more about the world, giving him/her much more of an opportunity to escape the cycle of poverty.
ObSlashdot: Since the laptop is running Linux, it can include free development tools and give kids a chance to learn to program at an early age.
I mean, the temperature out there in the orbit of those comets is very high near the sun, if it was an ice ball, then it would melt before it left the the region.
Assuming you are serious...
Water can't exist in a liquid state in a vacuum, so it sublimates rather than melting. Which is the whole idea of comets: as they near the sun, the volatile materials they contain boils away, producing the familiar tail of a comet. Since the comet is a several km^3 ball of ice, it can pass near the sun a large number of times before being reduced to whatever rock is contained in it.
(This may not be precisely correct; it's been a while since I took an astronomy course; but this is the general idea.)
Slashdot Mirror
He could have updated the module to delete and format the contents of every machine it was run on. I'm kind of surprised this hasn't happened before considering how many modern environments have such slapdash dependency systems.
It looks like this is still within the realm of possibility: http://www.drinchev.com/blog/a...
Exactly, this is a tempest in a teapot unless there is more information. One needs to show that the effect of electronic versus hand-counted votes on the election is statistically independent of the composition of the population (race, median income, M/F ratio, etc.) of each district. Probably districts where hand-counting is still used are on average poorer than those with e-voting machines, for instance.
The linked site makes a first stab at this by breaking down the data into "small towns", "medium towns" and "large towns", but that's only a start at making a real convincing argument. As the parent states, a comparison of the difference %(Obama) - %(Clinton) to the same quantity in the exit poll results, in hand-counted vs. e-voting districts, would be much more convincing. (Note, I say this as someone who much prefers Obama over Clinton.)
The latest in-depth discussion I could find on debian-legal is this one from July: link
The gist of it is that most of the proposed GPL3 seems OK, there are only a few problematic clauses. This specific message by Francisco Poli has an in-depth analysis: link
I will be eagerly awaiting the 2100 issue!
On the flip side, I wonder how many people are making money by following the opposite of the spammer's advice?
Isn't it hard to do that unless you already own the stock being recommended by the spam? Or is it possible to sell penny stocks short?
Wikipedia says that it was originally coined by Nathanael Nerode in 2004 on the debian-legal mailing list.
And what happens when upstream is no longer interested in supporting the version of Firefox in Debian stable (or even oldstable), as is the case for Firefox 1.0.4 in Sarge? Mozilla stopped supporting the Firefox 1.0.x line in May, about 7 months before the scheduled release of Debian Etch, and 19 months before the expected end of security support for Sarge.
The software is completely DFSG-free aside from the icons and trademark. What a waste it would be to move it to non-free just for the sake of these two easily removable things!
There's a related argument (I know you didn't make it) that Debian could at least make Firefox available from non-free in parallel with IceWeasel in main. Unfortunately it would be a nightmare for the security team to have TWO slightly different versions of the browser in Etch, considering the monumental task it is just to support ONE.
Why is this typical copy of the "BSD is dying" meme, with a few Debian-specific terms substituted in, modded "+1 Interesting"?
The Linux kernel is GPL. Anything linking to it must, as per the 'strict' interpretation that you mention (and that makes the most sense to me) therefore be GPL as well. Yet e.g. GNOME (which I can only assume does lots of calling to kernel functions) is LGPL and not GPL.
(I assume you meant to have the above "not" that I inserted for you.)
Good question, and I had to research this. Fortunately, in the case of the Linux kernel, the copyright holders (at least Linus) have clearly stated that they do not consider user space programs calling the kernel through clearly defined interfaces to be subject to a strict interpretation of the GPL with respect to dynamic linkage. Otherwise I agree that it would be a potential problem.
(This is basically a mirror image of the reverse case in which the GPL specifically permits shipment of GPL'ed applications linked against proprietary libraries that make up part of the OS, e.g. on Windows - but in this case the extra permission is provided by the Linux copyright holders' interpretation rather than the license text itself. The copyright holders' interpretation is always as important as the license, see for instance the case of PINE and U. Washington.)
I also have issues with the whole concept of linking (dynamic or static) and how that translates to languages/platforms which don't work the same way as C. For example, Java doesn't link at all - your code simple asks the classloader to load a class from "somewhere" and if it gets one which it can use, great. The classloader could have got it from anywhere - the filesystem, a web server, a database, whatever. As an application developer you don't really have any control over what the rutime classpath is - you could distribute with a BSD licensed impl of some interface and then have a user switch that for a GPL one. Are you now suddenly in violation of the GPL because your app accidentally "linked" itself to a GPL lib? Even in the traditional C world I can see issues with things like plugins. Imagine the scenario where you create a closed-source app which allows third parties to develop plugins as DLLs (or .so or whatever). If someone creates such a plugin and GPL licenses it, what happens when your non-GPL app links to it dynamically just because it was in the plugins directory at runtime?
These are indeed very hard questions! I'll give my opinion, but IANAL, this isn't intended as legal advice, I don't have any real evidence for my views, and they might even be partly self-contradictory. My personal feeling is that optional plugins that are dlopen()'ed at runtime do not constitute a derived work together with the application binary and any libraries it was linked against at build time. This is because the application can function without the plugin, so app + libraries without plugins can already be looked on as a complete work. (The only place where app + libraries + plugins are ever all combined is in RAM on the user's computer.)
If you are writing a proprietary program that loads optional plugins, perhaps you could work around the issue of a GPL'ed plugin "booby trap" in any case by specifically stating in the EULA that use of the program with GPL code is unacceptable :-)
If the plugin is mandatory (so the question is only of swapping it out for a differently-licensed plugin that does the same thing), it's essentially the same question as with dynamic linking to libraries. In that case, suppose there are a GPL library and a BSD lib that are ABI-compatible. If you compile your app and link dynamically against the BSD library, then distribute the app, I can't see how you could be held responsible for a GPL violation just because the user had the GPL version of the library installed at the time. Similarly for Java, if there's at least one implementation of a class that is legally permissible for your code to use, I think legally you must be in the clear. Don't ask me how complete an implementation needs to be in order to count!
When things are uncomplicated - specifically, in the case of a GPL library linked in dynamically at compile time, for which only the GPL implementation exists - I tend to believe the strict interpretation of the GPL (at least, as a Debian developer, it's legally safest for me to do so). But at some point there's certainly a line beyond which the GPL can no longer "infect" other code.
One question I've wondered about the GPL. If I write a program that links to a shared library that is GPL'd, do I need to GPL my application as well?
There are two schools of thought on this, and the answer to your question is pretty hotly debated.
The "stricter" school of thought, unsurprisingly the one favored by the FSF, is that statically or dynamically linking an executable to a library forms a work which can be considered a derived work of both sets of code. Under this theory, your application's source code doesn't have to be GPL, but its license does have to be compatible with the GPL since the linked work (app + library) taken as a whole is in part derived from the library and hence must be under the GPL. For instance, your app's source code could be licensed as LGPL or two-clause BSD in this situation with no problem, but could not be (for instance) CDDL or 4-clause BSD. Most Linux distributions follow this stricter, more conservative view.
On the other hand, it has been pointed out that this strict interpretation can sometimes lead to a peculiar conclusion. Suppose a work-alike copy of a GPL library is written from scratch and licensed permissively. Then a program linked against the GPL lib could also be used with the permissive library that forms a drop-in replacement. The strict theory of linking then implies that the license of your application is GPL if the GPL library is on your system, but not if the replacement library is instead. If this is not an acceptable conclusion, then it must be that dynamic linking against a GPL library does not make the application be under GPL as well.
This looser interpretation effectively defangs the GPL and makes it essentially equivalent to the LGPL, because anyone could change GPL'ed code they want to use into a shared library, then link their proprietary application against it.
Note that the interpretations differ only in the case of dynamic linking. When an application is linked statically against a GPL library, parts of the library object code end up in the compiled executable and therefore this is indisputably a derived work of both application code and library, hence under GPL. Proponents of the strict interpretation point out that from an end-user's viewpoint, there is no difference between static and dynamic linking other than the "-static" flag given to the linker, so the two methods of linking should not be legally distinguished either.
To the best of my knowledge (IANAL) there isn't any legal precedent favoring either interpretation.
This article reminds me very much of the human cancer cell line HeLa. I first heard about it in a biology class in high school, years ago. It is a cancer cell derived from a single person's cervical cancer around 1950, which is sufficiently fast-growing that (according to the Wiki article) it forms a common "weed" in lab cultures. It has even controversially been named a new species. Thankfully, unlike the dog cells, the HeLa line doesn't seem to be able to infect living humans (yet...)
Um, since when are there direct commercial flights between Miami and Cuba?
He does one choose users, aka developpers on debian?
But seriously, no FUD: How do they work to trust their developpers. I can't imagine I'm writting a little tiny app, knock on the debian door and they would open it. This is user trust policy.
You raise two different questions: how can Debian Developers be trusted, and how can the code that ends up in Debian be trusted.
For the first case, there is an extensive New Maintainer application process. This includes tests to see whether the applicant knows what s/he is doing, questions to see whether s/he understands and agrees with the philosophies of the Free Software movement, and a GPG key check to make sure that at least one current developer has met and verified the identity of the applicant. Additionally the applicant is supposed to have a history of doing good Debian work. At least two individuals, an Application Manager and one of the Debian Accounts Managers, independently research the applicant. (Only the DAM knows how extensive this research is but I have reason to believe it is quite thorough.)
For a package maintainer who isn't a Debian Developer yet, all his/her work goes through a developer sponsor who reviews it carefully. Only the maintainer's source package is used (not binary .debs), and it is rebuilt into .debs by the sponsor before upload. The sponsor takes particular care to ensure that the upstream source code ("orig.tar.gz" file) used by the maintainer is identical to that available from upstream's web site. Since the sponsor takes the final responsibility of uploading this person's work, s/he has an incentive to make sure everything is OK with it.
This ties into the second question. Even for a package uploaded by a Debian Developer, there is first supposed to be an Intent To Package announcement posted on the debian-devel mailing list (here's an example; notice that this isn't just a rubber-stamp procedure; the example I gave led to a lot of discussion). The developer is expected to review the source code, as much as is reasonable, to make sure there are no trojans built in. With each new revision by upstream, the developer reviews the full diff between versions.
Of course neither procedure is foolproof. Someone with enough dedication, intelligence, and malevolence could manage to get through the New Maintainer procedure and do what you suggest. Or an upstream that was clever enough to write well-disguised trojan code could trick a developer into uploading it into the Debian archive. (There was actually an example of this happening, though the trojanned code wasn't harmful; see this thread. Needless to say this didn't help the upstream author's New Maintainer application.) But these are risks in any software project, not only Debian and not limited to Free/open source software.
DO you know if that includes PPC?
Doesn't appear to, unfortunately - only x86 and AMD64 seem to be supported. (And Itanium via its x86 emulation.)
Done, thanks for the reminder.
Perhaps we'll see a repository for Java .debs at last, eh?
You must have missed the big news: official packages of Sun Java .debs were uploaded into Debian's non-free archive yesterday.
The announcement
Link to the page for the "source" package (I put "source" in quotes since it actually contains tarballs of the binaries, but you can obtain real source code in the sun-java5-source binary Debian package.)
License and FAQ about the license under which these packages are made available (note in particular that it permits sublicensing for derived distributions).
What if the Phishers send email with instructions for stupid customers to go into fake banks and do business with fake tellers?
Maybe happening sooner than we think, given the other Slashdot article...
Go download mod_security and look at the license, it is GPL.
That's actually the reason it was removed from Debian; from what I gather, it uses Apache headers that are licensed under the Apache License, which is apparently incompatible with the GPL. Here's the relevant bug: #313615
Disclaimer: I haven't done enough research to have an opinion on whether this removal was justified or not.
They should be able to compile this source code on any hardware architecture they choose (assuming they haven't assumed size of variables, etc.: the same stuff that trips up native ports).
Personally, I wouldn't put good odds on commercial Windows-only apps not making assumptions about endianness and pointer size (32-bit vs. 64-bit). Heck, even OpenOffice.org hasn't been completely ported to 64-bit systems yet, and it hasn't been proprietary (in the form of StarOffice) for several years now.
The other thing is that, if I understand correctly, these ports Google makes are still going to be closed-source. For there to be a PowerPC or SPARC version, Google has to explicitly decide to recompile the programs and link against Winelib on those platforms. Since there is less demand for non-x86 Linux apps on the desktop than x86 Linux desktop apps, I don't expect them to go to the trouble—especially now that Apple is switching to Intel chips.
I am a normal user and not a graphic designer. Thus, I do not use complicated features in Photoshop or GIMP, just the low level features. One of these, however, is crop. And crop sucks on GIMP. With Photoshop it is simple, I put a box around what I want to crop to and I crop.
I'm no graphic designer either, so maybe I misunderstand what you mean, but you can do exactly that in GIMP. (I'm not trying to defend GIMP's shortcomings, but I don't think it deserves this particular criticism.) Using the select tool, create a rectangular selection in the image. Then, right-click on the image to get the context menu, and select "Image->Crop Image". Am I missing something here?
One full stomach per child.
Full of what? Caviar?
On a non-humorous note, there is the old saying "Give a man a fish..." If this project is done well, I can see this being a much better investment to combat poverty in the long run than just giving people free food. A child with a laptop and an internet connection has a chance to learn a lot more about the world, giving him/her much more of an opportunity to escape the cycle of poverty.
ObSlashdot: Since the laptop is running Linux, it can include free development tools and give kids a chance to learn to program at an early age.
FYI, this article has already been ripped to shreds in the comments at Linux Today:
here
I mean, the temperature out there in the orbit of those comets is very high near the sun, if it was an ice ball, then it would melt before it left the the region.
Assuming you are serious...
Water can't exist in a liquid state in a vacuum, so it sublimates rather than melting. Which is the whole idea of comets: as they near the sun, the volatile materials they contain boils away, producing the familiar tail of a comet. Since the comet is a several km^3 ball of ice, it can pass near the sun a large number of times before being reduced to whatever rock is contained in it.
(This may not be precisely correct; it's been a while since I took an astronomy course; but this is the general idea.)