Yes. It is awesome. I got mine 2 months ago, and could not be happier. My wife has my old Nexus One.

The one thing you need to be a aware of is that this phone is HUGE!. Make sure to get a case that has some kind of belt-clip built in, as the phone + case will not fit comfortably in any stand-alone phone holster or most pants/shirt pockets. I'm probably going to have to just throw away the case I bought for it, or try to jury-rig some kind of belt clip into it.

I've run X11 since 1989. I started with TWM, then CTWM, then KDE.

KDE2. was great, KDE3 was fine, KDE4 is bloated. I don't care about eye candy. I don't care about UI guidelines thought up by some hipsters. I don't want widgets. I don't want spinning 3d cubes when I change workspaces. All I want is a desktop env. that works. What I care about:

- The ability to customize window the window manager enough to map Alt-mouse-1 to move, Alt-mouse-2 to resize and Alt-mouse-3 to iconify. These are hardwired in my brain after 23 years.

- The ability for the icon manager to work vertically, so I can stick it on the side of my workspace, rather than the top or bottom. Today's stupid widescreen monitors are too cramped vertically, and I begrudge any pixels taken away from my applications

- multiple desktops

- multiple monitor support

- no fancy GL stuff that screws up VLC or mplayer playing hardware accelerated video.

That's it. That's all. I could give a flying you now what about file managers, widgets, etc.

When my then 4yr old son "moved up" to a new classroom in the co-op daycare we used at the time, I was pleasantly surprised to see they had a real workbench at child height with hammers, nails, a saw, screwdrivers, etc as one of their play "centers". My son enjoyed this, and was never injured.

I'm still surprised they were able to do that & not get sued by some moron. This was 2 years ago, though so they may have changed things..

Nvidia's "half baked" support is actually better, since their drivers are backported to older stable distros. Stuff that requires kernel or bleeding-edge X.org is a royal pain to make work on a box running an older distro.

+1 I had an ATI in my last Linux desktop. Never again.

The proprietary fglrx drivers tend to have weird bugs and as you say, they drop chips that are old enough to have decent support. On the flip-side, the open-source radeon drivers tend to require various bleeding edge bits and pieces to work correctly, so they are nearly impossible to run on stable distros, like an Ubuntu LTS or a RHEL.

Nividia's proprietary drivers just work, once you finally figure out how to blacklist nouveau hard enough that it doesn't get loaded via the initrd. Plus they support VDPAU for projects like MythTV and XBMC.

I do NIC drivers for pretty much all popular *nix OSes. Linux is, by far, the biggest PITA to develop for. Developing for a particular version of Linux is fine, but keeping a driver compatible with all commonly used variants is murder.

Almost every other OS, even open source OSes like FreeBSD, maintain a stable binary device driver interface (DDI). That means that a module compiled for one kernel will work on any other in that major release series (and, depending on the OS, in future releases). For example, my company's NIC drivers compiled for S10 work just fine on both OpenSolaris and Solaris11.

Linux does not do this. Heck, they don't even maintain a stable DDI between the same kernel version compiled with different options. Worse, they change their APIs for no sane reason, adding and removing function arguments, struct elements, etc, just because somebody looking for name recognition wants to "clean up" something.

So if Linux had some kind of stable DDI like,. well, everybody else, a lot of these problems would just go away.

Before somebody whines "Well, just get your driver into the kernel" --- it is. But our customers tend to want the latest version *without* updating to the bleeding edge 3.x kernels. Which means that we have to maintain compile shims all the way back to 2.6.9 (RHEL4). The last I checked, the compile shims alone were ~2000 lines of code, which is nearly the size of the *ENTIRE* driver on some other OSes.

I use ZFS on Ubuntu 11.10 in "production" for my main workstation and fileserver with a 3x3TB raidz pool with an L2 ARC. I/O is blindingly fast, and it has been rock solid. It serves about 10 machines, and feels an order of magnitude faster than the md/lvm based xfs array it replaced.

I write 10GbE drivers for Linux, MacOSX, FreeBSD and Solaris. I make heavy use of Dtrace for both debugging and performance analysis. I feel naked without Dtrace, and I've used the linux dtrace a few times for debugging. Unfortunately, I've never had dtrace run on linux for more than a few minutes without crashing a machine. This is not necessarily bad, and often just a few seconds is all I need. But I would never run linux Dtrace on any production machine, whereas I use it all the time under Solaris / FreeBSD and MacOSX and often have customers run Dtrace probes on those OSes to diagnose issues.

There are far too many BD audio formats already, AC3, DTS, DCA, DTS-master, etc, etc, etc. With a decent ($3000) surround-sound HT setup and 40 year old ears, I cannot tell much difference between any of them. I wish the BD producers focused more on doing better video transfers. I'd much rather they use the space wasted by these new audio formats on higher bitrate video (and the same goes for the useless, space-wasting extra features).

As far as I'm concerned, the only thing these extra audio formats do is make ripping the files & playing them back via an embedded streaming device more complex. My oldest device cannot handle any of these new fancy formats beyond AC3, so I need to remux newer BDs to add an AC3 sound track to the MKV.

Sigh

Besides spotty hardware supprt, AFAIK it is also missing VDPAU (HD video decoding) support, which is the main reason a lot of HTPC types use Nvidia cards in their linux machines. It is also fairly hard to remove. I think it took me 1/2 hour of re-booting before I finally purged nouveau from my system to clear the way so that the Nvidia driver could attach.

As a Linux (and other *nix) driver guy, I have tons of respect for how Nvidia deals with the constant, gratuitous changes in the Linux kernel APIs.

The telco (unless it is third world) will have massive diesel generators

I guess suburban USA counts as "3rd world" then.

I live roughly 100 miles from Washington DC just outside of Richmond, VA. Our power was restored a few days after hurricane Irene last summer. After our power was restored, our internet (and voip phone) was still out. After a while, I realized that it would come on for a few hours, then go off.

After meeting some neighbors (we'd just moved in 2 weeks before the storm and knew nobody in town), we finally realized that the telcom's local headend was located across a major highway in an area that did not yet have power. The times when we had power were when our neighbors, at their own expense, filled up the tanks on Comcast's diesel generator.

I agree that this is a very important feature, and very rare outside of full-on PC based media centers.

My current box (SageTV HD300 media extender) does this. It is very sad that SageTV was purchased by Google, and you can no longer purchase this hardware. This is the exact same Sigma tango3 hardware as the WDTV Live Plus (and probably a few others), so we know that low-end STB hardware is capable of it.

I'm not a ports tree committer. I maintain a few device drivers in the src tree. I'm much less active than I was 10-12 years ago.

And yes, I do know that there are packages. The problem with packages is that the packages are generally updated infrequently (like every point release), and when they are updated, they have new versions & dependencies, and not just bugfixes. So even if you (try to) do a binary update, you run into the same sort of unintended consequence where picking up a bugfix for package A hoses some unrelated package B.

Back when I ran FreeBSD on the desktop, I used linux versions of web browsers, just so I could go outside the ports tree to get something I needed the latest version of & not have to worry about the newer dependancies for a browser causing me to have to update ports & possibly break something.

IMHO, ports are the single biggest problem with FreeBSD.

.... Because a rolling release, build-it-yourself based software package model is too big of a hassle (ports tree, I'm looking at you).

I've been a FreeBSD committer for over 10 years. I ran FreeBSD on the desktop for many years, but I switched to running Ubuntu Linux 4 years ago on my desktop because "apt-get install foo" and "apt-get update" are about 10x simpler and faster than doing the same things using the FreeBSD ports tree, and I don't have time to deal with broken dependancies, unfetchable files, etc.

For those who don't know, FreeBSD base system is maintained directly by the FreeBSD "src" team, and is what constitutes a FreeBSD release. This is the "basic" stuff like the kernel, a few shells, fs utilities, ls, cron, a customized system compiler, etc. This stuff is rock solid, and security updates fix bugs.

The "interesting" stuff (X server, web browser, most shells, perl, python, IDEs, etc) are provided by a rolling-release based "ports tree". The big problem is that the FreeBSD ports tree is a "rolling" release. If you need to update your X server due to a bug, you risk breaking some totally unrelated piece of software which has had a version update. Worse, you have to compile all ports yourself when you update, so updates are unnecessarily time consuming and complex.

Compare this to say, an Ubuntu/Debian/Mint or RHEL/Centos/Fedora release where there are no huge surprises when updating. Every apt-get update or (or yum equivalent) fixes bugs, and you don't have to worry about an update to fix program "A" totally hosing program "B"

This is the same reason why Debian or Red Hat based distros are so much more popular than "rolling release" distros like Arch or Gentoo.

I have hope that the new PC-BSD might be as easy to deal with as Linux. I love their "PBI" concept, where every every package contains all of its dependencies. I'm planning to replace an older Fedora on my laptop with PC-BSD 9.

I've used this ... it has been very helpul for development, but I would not run it on a production machine. In most cases when I've run it, it has managed to eventually crash the machine, usually just after obtaining the information I was after. For driver development, that is fine. But not for production.

I'm running with this version, and it is working great for me on my first test machine (8T raid-z with an L2-ARC)