I and most Christians I know do not have a problem with condoms, and we probably wouldn't even recommend prayer as the most effective way to prevent HIV. What we'd probably recommend instead is to only have sex with the person you're married to. Sure, this doesn't work too well against rape and blood transfusions, but then again, condoms don't really work there either.

(warning, shameless plug)

I've been working on a similar program for a while called libgis. The main difference is that libgis is built as a library instead of an application and uses OpenGL for rendering, which allows it to render terrain. It also uses GTK+ instead of Qt, but that's just due to my personal preferences. Unfortunately, it's not (yet!) as complete as Marble/WorldWind/Google Earth.

I'm not sure this is a terribly stable equilibrium though. Consider what's been happening with cell phone companies lately. They were all charging about the same price, but a few months ago tmobile basically cut their prices in half. I just noticed that Verizon recently lowered their prices, and presumably at&t will or has too.

Actually, you're pretty close there. Most of the projects I've checked out I only look though, or only make very small changes or bug fixes. In the past I've used cvs, svn, git, hg, and mtn. There's a bit of learning curve with each of these. Conceptually it's not too hard, but I have a hard time keeping track of whether it's `foo checkout --head' or `foo revert', `foo log --max-count' or `foo log --limit', etc. If you can keep track of all of these, then good for you, but I can't and would rather not try.

I've noticed this as well, at least using git against other repos (git-svn, git-cvsimport), but it's always seemed like a kludge to me. I haven't looked into it, but I've always assumed that git-svn/git-cvsimport/git-* were specific to git, which means they would need to be reimplemented in hg, mtn, etc. A common format for pulling changes would mean you'd only have to implement one other protocol besides the native protocol.

Most projects let you pick your editor, filesystem, distribution, etc. It would be nice to add version control to that list. That doesn't seem like it would be all that hard to do. There are already tools to migrate a repository between different version control systems and they mostly use similar concepts.

Git, mercurial, monotone, etc. are all ready nice, and do pretty much the same thing, but it's annoying to have to use the one that the project leader decides on. It would be nice (if it's possible) to be able to pick which one you want to use as a client, and have it work with whatever the project manager wants to use for the upstream repository. I'm not sure what all this would encompass, probably some common distribution (push/pull) protocol would need to be implemented by all the different SCMs..

I haven't actually written any Android software (although I have a myTouch now, so I might give it a try one of these days), so I'm not speaking from experience here. One advantage Android has over the iPhone as far as development goes is that it's Java-based. Pretty much every practicing software developer now learned Java at some point in their life, so chances are they could pick up the Android API pretty quickly. Android also has an Eclipse plugin, letting developers use familiar tools that work on Mac, Windows and Linux. It looks like there's also a C-based API for writing native code.

For the iPhone, on the other hand, you have to use Objective-C. While Objective-C seems like a nice language in a lot of ways, pretty much the only people who know it are Mac developers. You've also got to use XCode, which is Mac-only. Clearly this isn't preventing a huge number of apps from being written anyway (probably even more than are written for Mac OS X), but it does seem to me like it's at least somewhat of a disadvantage for the ease of developing apps.

Microsoft actually does have some experience with this. The XBox 360 is PowerPC-based, but it's able to run games from the original XBox, which was x64-based. I'm not sure, but this is quite possibly done using the very software you mentioned from Connectix.

At any rate, if Microsoft were to release an ARM port of Windows, it'd very likely be some kind of Windows Netbook Edition, and application providers would release versions of their apps for the netbook edition. It seems like the trend is largely towards smaller computers, and software companies would be stupid not to make sure they support this space too.

It's probably a lot easier to convince application makers to port their application from Windows (x86) to Windows (ARM) than from Windows (x86) to Linux (x86). There's a pretty good chance that switching architectures for most applications just requires a recompile, like porting from x86 to amd64. It's not always that simple, but in this case you'll still have all your Win32 APIs available, whereas porting to Linux will often times mean rewriting the whole thing in GTK or QT.

ARM processors still aren't being targeted at desktop machines either, but mostly Netbooks. I could see application makers being convinced that writing a netbook edition would be worth porting architectures, but maybe not being worth the full cost of porting to Linux.

It's not really that absurd. It sounds a lot like how the world was around the time I first got online. Back then, everyone had Compuserve, AOL, Prodigy, or any other online services that were around. I don't remember there being any interoperability at the time, so in effect they said "Let them build their own free internet if they want to complete." That's exactly what they did, and now these companies are all either out of business or they have morphed into just another ISP.

True, the Internet was developed long before I got online through these non-Internet services, but in the early 90s, I recall a world where the Internet was not something targeted at normal people. Researchers, businesses, the military, etc., all used the Internet. Regular people used closed services. Ultimately, openness won.

You were modded funny, and I'm not sure if you meant it as such, but this is really a pretty good point. People encourage you to come up with a password that's easy to remember. The problem is, these usually make passwords a lot easier to guess. Instead, you should just use a randomly generated string of 8 characters. If you type the password often enough, it'll be stored in muscle memory with about as much effort in my experience as trying to remember an easy to remember password.

One benefit I can see is that it gives you a single place to go get books from. I don't have to remember the web sites for 100 authors, or 50 publishers. Instead, I can just remember a single site which aggregates all the books together. Sure, I'll end up paying a higher monetary cost due to the middleman, but presumably the time cost savings is enough to me that it is worthwhile.

It's sort like having an iPhone App Store instead of hundreds of independent software publishers to download from. Another benefit is that the App Store provides common payment processing infrastructure, which keeps the cost of implementing this from being duplicated for every software publisher.

If the problem is the oxygen, clearly we need to produce a vacuum between the transmitter and the receiver. I propose a long cylinder of some rigid material, with a smaller cylinder bored out through the middle. Once this long pipe, or "tube," if you will, is connected to the transmitter and receiver, you could suck the air out of the inside of the tube and extend the wireless range. Several such transmitting and listening stations could be combined to form a series of tubes.

Maybe my sarcasm detector failed miserably, but isn't the point of a multiprocess Firefox so that you can encapsulate Flash in its own process?