what kind of latency do you get with AAC? Do you know? (I'm trying to find out now via google)

But, to reply more to the parent than to you: it's not like you're just going to be using this over wireless internet; some people actually have DSL or better connections with less then 40ms of latency; at rates like that a codec latency of 4ms is still 20% of the total latency. At that kind of latency 45ms you could play music with someone without driving yourself crazy because you both sound like your lagging behind the beat (you WILL both appear to be lagging to each other, but 45ms is a small enough amount of latency that it won't completely destroy the performance). In fact, even 100ms of total latency is probably survivable in a mid-tempo song (but will be very noticable), anything you can do at the codec level to chop that down improves the experience.

Wasn't the whole point of IPv6 being essentially independent of IPv4 so that you COULD run dual stacks? Because it would be completely un-reasonable to be able to cut-over from one addressing protocol to another world wide in any reasonable fashion? So ... yes, dual stacks for the next 20 years on main-stream devices, maybe 70-80 years for niche needs sounds reasonable to me.

Then how can they know they don't like them?

The thing is you can't necessarily fix a bad gui, unless you're working with something where you have access to the source and can replace the code; with cli, you can alway's script your way around a problem. Your programs doesn't validate input? Write an input validater and pipe it through that. Obviously, cli is great for batch operations and automation, as well. Even if it's a black box, proprietary system. Even if you can change the code, which is easier to do? Spend 15 minutes or less working in your favorite scripting language or source the application source, patch it, re-compile if necessary, test, then apply the operation? (Especially if this is a one-off operation).

Development is not happenning in the open, only google partners like motorola and samsung have access to honeycomb source.

According to the article, blaze customers can get "up to 10mbs" of bandwidth, though they don't specifiy if that's up/down or split symmetrically. This probably reflects an improvement in the technology over the past decade. As long as the latency isn't horrible, this sounds quite competitive vs. aDSL, although aDSL is also much, much cheaper (at least in areas with a reasonably dense population). Of course, the whole point is that there's really no other option besides dial-up.

Not to mention that many CS and IT students, who will encounter Unix/Linux for the first time at their university, might be exposed to Solaris and be convinced that it's the best Unix, simply because it's the one that they are most familiar with. (I'll bet this sort-of reasoning plays a bigger role in people's OS preferences than most would care to admit).

I think you underestimate how much that would hurt Google themselves. If Google stops returning IBM-hosted pages how fast do you think they're going to start losing users who care at all about IBM to Bing? "Search neutrality" advocates will, of course, get up in arms over this, if Google was stupid enough to block a major company's sites, but this shouldn't even make it that far, since screwing up it's search results in a way noticeable by an appreciable number of users is bad enough for Google on it's own, even without a public and/or regulatory body outcry.

In your example though, it's proprietary software vs. proprietary software. What your example really seems to suggest is that "fat clients" aren't always better than "thin clients", and that you should've just renewed the license on your original, proprietary software.

There are two major technical issues obstructing IPv6 adoption for home users:

1. Your ISP doesn't provide you with an IPv6 address.
2. Your network equipment's firmware can't handle IPv6, even though IPv6 has been standardized for over a decade. It's not particularly easy even to buy a new wireless/wired router and/or cable/dsl modem that supports IPv6.

Now you're router is probably physically cable of handling IPv6 routing, a linksys wrt54g from 5 years ago can do it if you flash OpenWRT firmware onto it... so you just need a firmware update to add software support for IPv6 ... but good luck getting revised firmware from your manufacturer.

So, in my opinion, basically no blame rests with network node users, because even if they wanted to enable IPv6 connectivity for their home network, they can't. Some amount of blame rests with your ISP (but I do think Comcast, at least, is exploring the possibility of offering IPv6 connectivity), and alot of blame rests with SOHO networking device manufacturers. Now, if equipment manufacturers and ISPs get their act together and offer IPv6 capable devices and service, then you can start blaming network node users for not getting onboard (and I'm sure, at that point, plenty of people will drag their feet about it).

I don't think there's anyway to reasonalby expect this to work. First off, you'd need to root the device first, second stock android might not even fully support your phone's hardware.

I think if the issue is that, even if there are no royalties paid, h.264 isn't really "free" in that it takes developer time away from other projects that they might work on, nobody at Mozilla is interested enough in h.264 to develop a playback plugin; besides, h.264 plugins sort of defeat the point of , since the idea was to enable video playback WITHOUT plugins. Also, note that Opera, which is a proprietary project doesn't want to support h.264 either. presumably because of malaise regarding royalties (Opera's creators aren't exactly rolling in dough). I think that Microsoft, Opera, and Firefox are all sort-of waiting for the dust to settle in the codec dispute. If it becomes clear that h.264 is the future, Opera and Firefox will have to find some way to support it; if vp8 or, less likely, theora, goes somewhere Microsoft will support it in new versions of IE. Apple, to some degree has a vested interest in opposing anything but h.264, so they might hold out even if it's clear the tide is changing toward another codec.

Firefox doesn't bundle flash, do you mean chrome?

How can an OS level bug cause firmware/BIOS level problems? And or tell me what hardware I can reproduce this bug on.