Indeed, if you choose not to use dropbox, unison is almost certainly the proper choice for the job.

Aren't both iptables/ipchains Linux only? Doesn't NetBSD use pf like OpenBSD?

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).