It sounds like Rincon will basically be a clone of Mozilla Firefox and/or Konqueror. Frankly, why do they bother? Why do they keep wasting money on this?
It's pretty clear at this point that attempts to make the web a Microsoft-proprietary space have failed. The freely available rendering engines does everything they need, and they can put some of them into whatever products they like under liberal licenses. Microsoft could do what Apple did with Safari.
I think for Microsoft, pride has long clouded their judgement. Not-invented-here perhaps works as a business strategy for a software company if you are in complete control of a market, but that is less and less the case with Microsoft.
BitTorrent is nice and decentralized but doesn't do much to protect the privacy of those using it - unlike, say, FreeNet.
Bittorrent is explicitly non-anonymous in order to make it less attractive for people interested in violating copyrights. Finding out who is hosting what is actually quite easy with Bittorrent. I fail to see a problem with that.
5. $$$ Profit $$$
If you don't like their business model or product, there is a simple solution for you: you don't download their stuff illegally and you also don't buy it. Sooner or later, one of those companies will figure out that they need to change their business model.
Distribution costs already are only a tiny fraction of the price of a DVD, and that's only going down even with non-P2P distribution models.
So, yes, I don't mind paying the few cents more for the cost of a direct download; I do mind my upstream connectivity being blocked for hours on time with movie uploads to other people.
I installed Azureus and started downloading things, and nothing warned me about leeching or tried to help me avoid it.
Bittorrent clients, and perhaps the protocol, need to ensure that (1) users are aware of how they are expected to behave, and (2) they help them (or even enforce) such behavior.
Right now, clients like Azureus are overly complex, hard to configure (in particular, behind firewalls, where I have not been able to get them to work at all), and don't address such important issues.
BitTorrent is a really big change, because with it we can finally upload data directly to "the network".
BitTorrent would be a very poor choice for that purpose because there is no distributed representation of the data--it's a simple "tit-for-tat" distribution service.
Even good, old, 30 year old USENET is more of a distributed representation of content than Bittorrent.
Grid computing and Internet-based data replication will happen when (1) people need it and (2) after they design good protocols for it. Bittorrent is not relevant to the process; bittorrent is just good at what it is.
Just as you have NO legal right to access movies or shows that are not currently available for view or purchase in your region.
Of course you do have that legal right: you can buy and sell books and DVDs as much as you like. Furthermore, as far as copyright law is concerned, you can import and export DVDs as much as you like.
I ended up buying a bootleg copy off of eBay.
That is illegal, not because it came from China, but because it was a copy that violated copyright.
But you only get economies of scale after you have found a large population of initial adopters willing to pay a premium for this kind of hardware. Their money is then used to build the large, efficient factories and amortize the development costs. I don't see that happening with FPGAs.
I think the cell architecture has a better shot at this (it's a bit more parallelism and configurability than a regular chip, but already a lot harder to program), but even with that, I remain doubtful that it makes the right tradeoffs.
Re:give us cheap Linux-based PPC machines
on
LinuxPPC64 Contest
·
· Score: 1
Because they are still more expensive than comparable x86 hardware.
Linux on PPC is not a good deal right now for anything other than to breathe some life into old Macintosh hardware that is too slow to run current Macintosh software.
Sun Dome sells this. They have been around for a number of years.
Re:give us cheap Linux-based PPC machines
on
LinuxPPC64 Contest
·
· Score: 1
Apple's PPC hardware is the cheapest available
Yes, Apple's PPC hardware is some of the cheapest PPC hardware available, which is a problem for the PPC chip because Apple's PPC machines are not particularly good deals as far as desktop machines go.
The really sad thing is that you're not much of an outside the box thinker for such a gung ho linux maniac. Here's a hint, buy a second hand mac and nobody will ever know except you and ebay.
I don't need to buy a second-hand Mac, I own a bunch of first-hand Macs (mostly for porting and out of curiosity), in addition to lots of PCs and some workstations, so I can make first-hand comparisons of both the hardware, the performance, and the software.
And my experience is that the Macintosh hardware is more expensive than x86 hardware of comparable quality and performance. That isn't particularly surprising: Apple uses the same contract manufacturers that make PCs, but their volumes are smaller and they have to pay their software developers something.
As I was saying: until we get PPC hardware that is actually cost-competitive with x86 hardware of comparable quality and performance, Linux on PPC just won't catch on. And that isn't even taking into account the fact that the PPC processor doesn't run a lot of software (hence the porting contest).
give us cheap Linux-based PPC machines
on
LinuxPPC64 Contest
·
· Score: 1, Insightful
I would be much more inclined to use PPC machines if there were cheap PPC-based machines. And, no, Apple's OSX machines don't count: they have proprietary devices that Apple doesn't release the necessary specs for, Apple will count everybody who buys such a machine as a Macintosh sale (thereby inflating their sales numbers and hurting Linux in market share comparisons), and I don't want to pay an "Apple tax" on PPC machines any more than I want to pay a "Microsoft tax" on PCs.
So, give us the cheap, open PPC-based desktop and server machines, something with better price/performance ratios than x86-based machines, and then we can talk.
You need about an order of magnitude more transistors to do something with an FPGA than to design a special chip for some task. That makes it an order of magnitude more expensive, too, and consume much more power. And even then, it won't run as fast as an equivalent hard-wired chip.
People build special-purpose chips for the mass market because it's the cheapest way of getting the functionality out.
And as general purpose computational devices, FPGAs are just too hard to program and too inflexible.
There are many places where C is still used. There are many API's that are still in C. There's plenty of embedded systems programming that is done in C. So on and so forth.
True, which is why I also still use C occasionally. But being widely used doesn't make it a good design.
A couple of years ago I was using C for embedded systems, due to the fact that the overhead incurred by C++ was just too large.
That has always been a myth. C++ has been designed from the start not to impose any overhead above and beyond C: you only pay for what you use.
I still prefer C++ to the newer languages, along with the occasional assembler block for super critical performance code.
Well, unlike C, in C++, at least it is possible to write reasonably safe code if you are meticulous about data abstraction. That's an OK trade-off for small, single programmer projects, but it introduces lots of extra management hassles for larger projects--you have to be constantly alert that developers don't start using unsafe or dangerous constructs.
I'd like one of the newer languages to have the power of assembly/C/C++ while still maintaining all their grace of memory saftey and management.
There have been many such languages. Look at Modula-3, Sather, or Oberon, for example. Modula-2, Ada, CLU, Cedar, Mesa, and Object Pascal also were far safer than C (although they had some other problems/limitations).
Java, in many ways, was a step back, because, while it supports safety, it fails to support systems programming. C# as a language combines runtime safety with the ability to perform low-level manipulations; unfortunately, its CLR/CLI-based implementations are bloated and complex. Let's keep our fingers crossed for a gccsharp compiler.
I just googled for mudflap performance hit and got nothing
You don't need to Google, you just need to follow the links at the top of the story!
How does the C sematnics make it hard for the complier to iperform checks on buffers?
Because, for practical purposes, C pointers have to be naked memory addresses that can point into the middle of an arbitrary sized chunk of memory. That means that, unlike implementations of other languages, a C implementation cannot simply get information about bounds or types by looking up data at a fixed offset relative to the pointer.
There are plenty ways to prevent buffer over-runs these days.
Yes, like using a decent language with a minimum of built-in error checking and a sensible type system. We have had them, oh, for about half a century. And nowadays, you can even choose among a bunch of mainstream languages like that: Java, C#, VisualBasic, OCAML, and Python, to name just a few.
Do you have any links at all to contribute?
I have no idea what your background is; you might high school kid that writes viruses in C in his spare time and thinks that C is the k00lest thing since Britney Spears. But if you seriously want to learn about this sort of thing, look at the Cyclone papers (you can find them on Google) and check their references, as well as references to them in the literature. You'll reach a large collection of papers on trying to make C safe. Pick and choose according to your interests.
Use your mouse, follow the links in the Slashdot story, and you will come to a web site and a paper describing the Mudflap implementation. I know it's pretty uncommon to actually follow the links from a Slashdot story before commenting, but you can do it.
C doesn't have a screwed up pointer semantics. It is perfect for what it does. You probably just don't understand it. Where are you getting the 3 to 5 factor? Anything to back that up? And the few percent is from what language?
I have been using C since 1980. I have seen dozens of attempts to fix C semantics since then. I published some papers on it myself. It can't be done efficiently. The best you can do is something like Mudflap, Purify, Cyclone, or Valgrind.
Where does the factor of 3-5 come from? From the Mudflap paper on the Mudflap web site--it has benchmarks.
Where do the "few percent overhead" come from? From comparing the performance of Pascal, Java, and Eiffel code compiled with safety on and off.
And you know what the real kicker is? Not only do C pointer semantics make it impossible to generate efficient runtime safety checks, they even inhibit important optimizations when no safety features are enabled. And because C programmers then have to jump through all sorts of hoops to achieve some kind of safety in the midst of this chaos, the software ends up being bloated, too. So, C is not only bad for efficient safe code, it is bad for efficient code of any form.
I am getting sick when C-hating posts like this one get modded up. Seems to be happening all the time lately.
I'm getting sick of the fact that ignorant fools like you have been holding back progress in software systems for a quarter of a century. It's even more annoying that you try to portray your ignorance and inexperience as some kind of principled stance. C was good for what it was 30 years ago: an on-board compiler for writing small, low-level programs on machines with very limited memory. C made a decent PDP-11 compiler for V7 UNIX, and it was usable on CP/M and MS-DOS. I have fond memories of it in those environments.
I'm starting to meta-mod again.
You do that. If you join forces with enough other idiots, you will probably be able to condemn us to another quarter century of bad pointers, buffer overruns, and bloat.
My only concern is that some devs will think running it all the time is OK (read: "Mudflap slows a program's performance"), so hopefully that's not the case.
I'll agree with you on this much: C+Mudflap is not the way to fix buffer overrun problems. The problem isn't that runtime safety is costly--it isn't--the problem is that adding runtime safety to the C programming language post hoc is costly because of C's screwed up pointer semantics. That's why Mudflap costs you a factor of 3-5 in terms of performance on benchmarks, when runtime safety in another language really should only cost you a few percent overhead at most.
Mudflap will probably not be used much for testing (people already have good tools for that they don't use) and it has too much overhead for most production use. The biggest thing Mudflap will do is perpetuate the myth that runtime safety is costly.
I'm not trying to troll, but I really don't understand the fascination with Knuth and his work. Knuth clearly is an important computer scientist and some of his work has had a big impact, but he wouldn't be my choice for computer science hero.
I don't find "The Art" to be a particularly well written book--the verbal presentation is great, but I consider the selection unfocused and approach questionable. I have rarely come across anything actually useful in one of Knuth's papers. And have a look at his recent publications; is there really anything interesting in there? The one piece of software that I use of which I know that it is related to Knuth, I have a love-hate relationship with: TeX does something very useful and it does it technically well, but as a piece of modern software development or language design, I think it deserves a failing grade.
So, the question is: why are you so fascinated by Knuth? Which of his papers or results are you really fond of? And which of his results are you actually using? What examples of practical impact of Knuth's results can you actually give.
Re:The responses to this post are fascinating
on
Donald Knuth On NPR
·
· Score: 1
The OP wasn't ridiculing unbelievers, he was ridiculing the intolerance and arrogant condescension of some unbelievers.
You are trying to portray religious faith and atheism as being two equivalent positions, but that is ludicrious.
A serious, mainstream Christian believes that some unseen, all-powerful intelligence acts in the physical world. For a scientist, that kind of belief system is at best irrational superstition. The only reason why we don't lock people up that are afflicted by this sort of thing is because, as a biological problem, predisposition to these kinds of irrational behaviors is so pervasive that it can't be called "abnormal" (even if it is dysfunctional).
The situation is made worse by the fact that the many people who hold such superstitions, i.e., many Christians, historically and currently don't just stop at "arrogance and condescension", but actively engage to this day in discrimination, political manipulation, restraint of speech, murder, and genocide, not just "in the name of Christianity" (which could simply be an unfortunate misuse of the religion), but supported by Christian religious and political institutions. And this is not a one-time occurrence but something that has happened consistently for two millennia.
The absolute best of the bunch, though, has to be the one who claimed that the fact that Knuth is Christian places his computer science research in question!
It does not place Knuth's computer science research in question because Knuth's work in computer science isn't scientific, it is mathematical and theoretical. If he were actually engaging in observational science, one might (however briefly) have to consider whether his religious beliefs affected his work; for example, the science of a fundamentalist Christian archaeologer or palaeontologist is indeed, a priori in doubt.
This must make many people on Slashdot very happy. I have seen many posts claiming that only an idiot would believe in God. Think of how many people now have proof that they are smarter than Donald Knuth.
You are falsely conceptualizing intelligence as something one-dimensional. Knuth is the best in the world at writting little gem-like computer science papers about random topics algorithms and discrete structures. That doesn't mean that he is an authority on anything else. Newton was a nut and a crank, but his physics was good.
Now, let's just wonder for a moment how the world could look like if he had been less a scientist and artist but more a businessman and decided early on to charge for TeX...
Actually, we'd probably have a better open source type setting language by now. TeX sort of works, but it really is a god-awful mess.
Or patent his works.
First of all, he couldn't have because software patents weren't around. Second, if he could have, many of the patents would have expired by now and the inventions would be in the public domain. Third, most of his work is academic curiosities, not practically relevant (although, given his volume of publications, there are quite a few important publications, of course).
I forgot to add: make any such device look like a gigantic Christian cross, not like a sniper rifle. People have a hard time banning crosses and you have a God-given right to point crosses anywhere you please. If it has a Bluetooth antenna at its tip, well, that's just an expression of your religious commitment to communicating with God and your fellow man.
And, whatever you do, don't make it shaped like a 4ft dildo. With sniper rifles, at least the powerful gun lobby will stand behind you. When someone stands behind you while you are pointing a 4ft dildo off a rooftop, it's probably not to protect your civil liberties.
Guys, don't be stupid. When you call something like this a "sniper rifle" or "bluetooth sniping", then politicians will have an easy time walking all over our civil liberties and banning anything other than government or Microsoft-approved hardware and software. Names like "sniping" and "wardriving" just make political rhetoric too easy.
Call it a "security enforcement sensor" or a "privacy alert device" or "child protection wand" and politicians will have a much harder time banning it and throwing you in jail for using it.
Slashdot Mirror
It sounds like Rincon will basically be a clone of Mozilla Firefox and/or Konqueror. Frankly, why do they bother? Why do they keep wasting money on this?
It's pretty clear at this point that attempts to make the web a Microsoft-proprietary space have failed. The freely available rendering engines does everything they need, and they can put some of them into whatever products they like under liberal licenses. Microsoft could do what Apple did with Safari.
I think for Microsoft, pride has long clouded their judgement. Not-invented-here perhaps works as a business strategy for a software company if you are in complete control of a market, but that is less and less the case with Microsoft.
BitTorrent is nice and decentralized but doesn't do much to protect the privacy of those using it - unlike, say, FreeNet.
Bittorrent is explicitly non-anonymous in order to make it less attractive for people interested in violating copyrights. Finding out who is hosting what is actually quite easy with Bittorrent. I fail to see a problem with that.
5. $$$ Profit $$$
If you don't like their business model or product, there is a simple solution for you: you don't download their stuff illegally and you also don't buy it. Sooner or later, one of those companies will figure out that they need to change their business model.
Distribution costs already are only a tiny fraction of the price of a DVD, and that's only going down even with non-P2P distribution models.
So, yes, I don't mind paying the few cents more for the cost of a direct download; I do mind my upstream connectivity being blocked for hours on time with movie uploads to other people.
I installed Azureus and started downloading things, and nothing warned me about leeching or tried to help me avoid it.
Bittorrent clients, and perhaps the protocol, need to ensure that (1) users are aware of how they are expected to behave, and (2) they help them (or even enforce) such behavior.
Right now, clients like Azureus are overly complex, hard to configure (in particular, behind firewalls, where I have not been able to get them to work at all), and don't address such important issues.
BitTorrent is a really big change, because with it we can finally upload data directly to "the network".
BitTorrent would be a very poor choice for that purpose because there is no distributed representation of the data--it's a simple "tit-for-tat" distribution service.
Even good, old, 30 year old USENET is more of a distributed representation of content than Bittorrent.
Grid computing and Internet-based data replication will happen when (1) people need it and (2) after they design good protocols for it. Bittorrent is not relevant to the process; bittorrent is just good at what it is.
Just as you have NO legal right to access movies or shows that are not currently available for view or purchase in your region.
Of course you do have that legal right: you can buy and sell books and DVDs as much as you like. Furthermore, as far as copyright law is concerned, you can import and export DVDs as much as you like.
I ended up buying a bootleg copy off of eBay.
That is illegal, not because it came from China, but because it was a copy that violated copyright.
But you only get economies of scale after you have found a large population of initial adopters willing to pay a premium for this kind of hardware. Their money is then used to build the large, efficient factories and amortize the development costs. I don't see that happening with FPGAs.
I think the cell architecture has a better shot at this (it's a bit more parallelism and configurability than a regular chip, but already a lot harder to program), but even with that, I remain doubtful that it makes the right tradeoffs.
Because they are still more expensive than comparable x86 hardware.
Linux on PPC is not a good deal right now for anything other than to breathe some life into old Macintosh hardware that is too slow to run current Macintosh software.
Sun Dome sells this. They have been around for a number of years.
Apple's PPC hardware is the cheapest available
Yes, Apple's PPC hardware is some of the cheapest PPC hardware available, which is a problem for the PPC chip because Apple's PPC machines are not particularly good deals as far as desktop machines go.
The really sad thing is that you're not much of an outside the box thinker for such a gung ho linux maniac. Here's a hint, buy a second hand mac and nobody will ever know except you and ebay.
I don't need to buy a second-hand Mac, I own a bunch of first-hand Macs (mostly for porting and out of curiosity), in addition to lots of PCs and some workstations, so I can make first-hand comparisons of both the hardware, the performance, and the software.
And my experience is that the Macintosh hardware is more expensive than x86 hardware of comparable quality and performance. That isn't particularly surprising: Apple uses the same contract manufacturers that make PCs, but their volumes are smaller and they have to pay their software developers something.
As I was saying: until we get PPC hardware that is actually cost-competitive with x86 hardware of comparable quality and performance, Linux on PPC just won't catch on. And that isn't even taking into account the fact that the PPC processor doesn't run a lot of software (hence the porting contest).
I would be much more inclined to use PPC machines if there were cheap PPC-based machines. And, no, Apple's OSX machines don't count: they have proprietary devices that Apple doesn't release the necessary specs for, Apple will count everybody who buys such a machine as a Macintosh sale (thereby inflating their sales numbers and hurting Linux in market share comparisons), and I don't want to pay an "Apple tax" on PPC machines any more than I want to pay a "Microsoft tax" on PCs.
So, give us the cheap, open PPC-based desktop and server machines, something with better price/performance ratios than x86-based machines, and then we can talk.
You need about an order of magnitude more transistors to do something with an FPGA than to design a special chip for some task. That makes it an order of magnitude more expensive, too, and consume much more power. And even then, it won't run as fast as an equivalent hard-wired chip.
People build special-purpose chips for the mass market because it's the cheapest way of getting the functionality out.
And as general purpose computational devices, FPGAs are just too hard to program and too inflexible.
There are many places where C is still used. There are many API's that are still in C. There's plenty of embedded systems programming that is done in C. So on and so forth.
True, which is why I also still use C occasionally. But being widely used doesn't make it a good design.
A couple of years ago I was using C for embedded systems, due to the fact that the overhead incurred by C++ was just too large.
That has always been a myth. C++ has been designed from the start not to impose any overhead above and beyond C: you only pay for what you use.
I still prefer C++ to the newer languages, along with the occasional assembler block for super critical performance code.
Well, unlike C, in C++, at least it is possible to write reasonably safe code if you are meticulous about data abstraction. That's an OK trade-off for small, single programmer projects, but it introduces lots of extra management hassles for larger projects--you have to be constantly alert that developers don't start using unsafe or dangerous constructs.
I'd like one of the newer languages to have the power of assembly/C/C++ while still maintaining all their grace of memory saftey and management.
There have been many such languages. Look at Modula-3, Sather, or Oberon, for example. Modula-2, Ada, CLU, Cedar, Mesa, and Object Pascal also were far safer than C (although they had some other problems/limitations).
Java, in many ways, was a step back, because, while it supports safety, it fails to support systems programming. C# as a language combines runtime safety with the ability to perform low-level manipulations; unfortunately, its CLR/CLI-based implementations are bloated and complex. Let's keep our fingers crossed for a gccsharp compiler.
I just googled for mudflap performance hit and got nothing
You don't need to Google, you just need to follow the links at the top of the story!
How does the C sematnics make it hard for the complier to iperform checks on buffers?
Because, for practical purposes, C pointers have to be naked memory addresses that can point into the middle of an arbitrary sized chunk of memory. That means that, unlike implementations of other languages, a C implementation cannot simply get information about bounds or types by looking up data at a fixed offset relative to the pointer.
There are plenty ways to prevent buffer over-runs these days.
Yes, like using a decent language with a minimum of built-in error checking and a sensible type system. We have had them, oh, for about half a century. And nowadays, you can even choose among a bunch of mainstream languages like that: Java, C#, VisualBasic, OCAML, and Python, to name just a few.
Do you have any links at all to contribute?
I have no idea what your background is; you might high school kid that writes viruses in C in his spare time and thinks that C is the k00lest thing since Britney Spears. But if you seriously want to learn about this sort of thing, look at the Cyclone papers (you can find them on Google) and check their references, as well as references to them in the literature. You'll reach a large collection of papers on trying to make C safe. Pick and choose according to your interests.
Use your mouse, follow the links in the Slashdot story, and you will come to a web site and a paper describing the Mudflap implementation. I know it's pretty uncommon to actually follow the links from a Slashdot story before commenting, but you can do it.
C doesn't have a screwed up pointer semantics. It is perfect for what it does. You probably just don't understand it. Where are you getting the 3 to 5 factor? Anything to back that up? And the few percent is from what language?
I have been using C since 1980. I have seen dozens of attempts to fix C semantics since then. I published some papers on it myself. It can't be done efficiently. The best you can do is something like Mudflap, Purify, Cyclone, or Valgrind.
Where does the factor of 3-5 come from? From the Mudflap paper on the Mudflap web site--it has benchmarks.
Where do the "few percent overhead" come from? From comparing the performance of Pascal, Java, and Eiffel code compiled with safety on and off.
And you know what the real kicker is? Not only do C pointer semantics make it impossible to generate efficient runtime safety checks, they even inhibit important optimizations when no safety features are enabled. And because C programmers then have to jump through all sorts of hoops to achieve some kind of safety in the midst of this chaos, the software ends up being bloated, too. So, C is not only bad for efficient safe code, it is bad for efficient code of any form.
I am getting sick when C-hating posts like this one get modded up. Seems to be happening all the time lately.
I'm getting sick of the fact that ignorant fools like you have been holding back progress in software systems for a quarter of a century. It's even more annoying that you try to portray your ignorance and inexperience as some kind of principled stance. C was good for what it was 30 years ago: an on-board compiler for writing small, low-level programs on machines with very limited memory. C made a decent PDP-11 compiler for V7 UNIX, and it was usable on CP/M and MS-DOS. I have fond memories of it in those environments.
I'm starting to meta-mod again.
You do that. If you join forces with enough other idiots, you will probably be able to condemn us to another quarter century of bad pointers, buffer overruns, and bloat.
My only concern is that some devs will think running it all the time is OK (read: "Mudflap slows a program's performance"), so hopefully that's not the case.
I'll agree with you on this much: C+Mudflap is not the way to fix buffer overrun problems. The problem isn't that runtime safety is costly--it isn't--the problem is that adding runtime safety to the C programming language post hoc is costly because of C's screwed up pointer semantics. That's why Mudflap costs you a factor of 3-5 in terms of performance on benchmarks, when runtime safety in another language really should only cost you a few percent overhead at most.
Mudflap will probably not be used much for testing (people already have good tools for that they don't use) and it has too much overhead for most production use. The biggest thing Mudflap will do is perpetuate the myth that runtime safety is costly.
I'm not trying to troll, but I really don't understand the fascination with Knuth and his work. Knuth clearly is an important computer scientist and some of his work has had a big impact, but he wouldn't be my choice for computer science hero.
I don't find "The Art" to be a particularly well written book--the verbal presentation is great, but I consider the selection unfocused and approach questionable. I have rarely come across anything actually useful in one of Knuth's papers. And have a look at his recent publications; is there really anything interesting in there? The one piece of software that I use of which I know that it is related to Knuth, I have a love-hate relationship with: TeX does something very useful and it does it technically well, but as a piece of modern software development or language design, I think it deserves a failing grade.
So, the question is: why are you so fascinated by Knuth? Which of his papers or results are you really fond of? And which of his results are you actually using? What examples of practical impact of Knuth's results can you actually give.
The OP wasn't ridiculing unbelievers, he was ridiculing the intolerance and arrogant condescension of some unbelievers.
You are trying to portray religious faith and atheism as being two equivalent positions, but that is ludicrious.
A serious, mainstream Christian believes that some unseen, all-powerful intelligence acts in the physical world. For a scientist, that kind of belief system is at best irrational superstition. The only reason why we don't lock people up that are afflicted by this sort of thing is because, as a biological problem, predisposition to these kinds of irrational behaviors is so pervasive that it can't be called "abnormal" (even if it is dysfunctional).
The situation is made worse by the fact that the many people who hold such superstitions, i.e., many Christians, historically and currently don't just stop at "arrogance and condescension", but actively engage to this day in discrimination, political manipulation, restraint of speech, murder, and genocide, not just "in the name of Christianity" (which could simply be an unfortunate misuse of the religion), but supported by Christian religious and political institutions. And this is not a one-time occurrence but something that has happened consistently for two millennia.
The absolute best of the bunch, though, has to be the one who claimed that the fact that Knuth is Christian places his computer science research in question!
It does not place Knuth's computer science research in question because Knuth's work in computer science isn't scientific, it is mathematical and theoretical. If he were actually engaging in observational science, one might (however briefly) have to consider whether his religious beliefs affected his work; for example, the science of a fundamentalist Christian archaeologer or palaeontologist is indeed, a priori in doubt.
This must make many people on Slashdot very happy. I have seen many posts claiming that only an idiot would believe in God. Think of how many people now have proof that they are smarter than Donald Knuth.
You are falsely conceptualizing intelligence as something one-dimensional. Knuth is the best in the world at writting little gem-like computer science papers about random topics algorithms and discrete structures. That doesn't mean that he is an authority on anything else. Newton was a nut and a crank, but his physics was good.
Now, let's just wonder for a moment how the world could look like if he had been less a scientist and artist but more a businessman and decided early on to charge for TeX...
Actually, we'd probably have a better open source type setting language by now. TeX sort of works, but it really is a god-awful mess.
Or patent his works.
First of all, he couldn't have because software patents weren't around. Second, if he could have, many of the patents would have expired by now and the inventions would be in the public domain. Third, most of his work is academic curiosities, not practically relevant (although, given his volume of publications, there are quite a few important publications, of course).
I forgot to add: make any such device look like a gigantic Christian cross, not like a sniper rifle. People have a hard time banning crosses and you have a God-given right to point crosses anywhere you please. If it has a Bluetooth antenna at its tip, well, that's just an expression of your religious commitment to communicating with God and your fellow man.
And, whatever you do, don't make it shaped like a 4ft dildo. With sniper rifles, at least the powerful gun lobby will stand behind you. When someone stands behind you while you are pointing a 4ft dildo off a rooftop, it's probably not to protect your civil liberties.
Guys, don't be stupid. When you call something like this a "sniper rifle" or "bluetooth sniping", then politicians will have an easy time walking all over our civil liberties and banning anything other than government or Microsoft-approved hardware and software. Names like "sniping" and "wardriving" just make political rhetoric too easy.
Call it a "security enforcement sensor" or a "privacy alert device" or "child protection wand" and politicians will have a much harder time banning it and throwing you in jail for using it.
3D scene reconstruction from images has been the subject of research for decades, with some impressive successes even in the 1980's.
With newer hardware, much higher resolutions, and more training data, these systems were bound to get better, and they are going to get better still.
Frost on Mars had already been observed by Viking in 1979 (e.g., here).