It is probably not a bad thing.

Back in the day, I did FreeBSD drivers / platform support for DEC Alphas. I would occasionally get hardware and/or docs under NDA from DEC. The NDA basically said I could write open source drivers, but I could not share the documentation. This is how a lot of Linux / BSD hardware support still works.

Sorry, I have an x86/amd64 + DEC alpha historical bias, and don't really know a lot about ARM.

As a user, having the "southbridge" stuff integrated onto the CPU card means that you're essentially getting a whole new motherboard when you replace this CPU card. I always view a whole new motherboard as a whole new set of problems, in terms of potentially buggy hardware and drivers. At the very least, it is seems problematic in terms of having to upgrade your kernel to support the latest stuff. In the x86 world, as long as the vendor hasn't changed the CPU socket, you can generally drop in a new CPU with just a BIOS upgrade, and you don't need to worry that you might get a whole new set of buggy peripherial chips.. I've often done that with AMD CPUs.

Maybe a dumb question, but why do you put the core peripherals (USB, Sata, ethernet, VGA) on the CPU card, each requiring these pcmcia pins. Why not use a PCIe interface, and leave the peripherals to the tablet / laptop / motherboard / tv / etc vendor? It seems like this would allow for greater differentiation between "system" vendors, and would require less integration efforts from CPU vendors.

Maybe I'm just old and grumpy, but all of this fancy new crap that obfuscates the boot process really ticks me off. If a machine has trouble booting, the last thing I want is some fancy gui with a pretty stop-watch ticking endlessly at me, rather than seeing "NFS server foo not responding" in black and white. So now rather than having just the actual problem to fix, I've got to use a second machine to figure out how to shut off the god damned gui (or how to get into the grub menu) before I can even get a hint what the actual problem might be.

Now get off my lawn.

If you really want to upgrade, you should be able to "hackintosh" your mac. I did this to test 64bit drivers on a macpro1,1. It worked well enough for what I needed it (running 64b kernel), however, I would not use this setup for a daily use machine, as the video card acceleration went away, the power usage increased, etc. I'd keep a separate partition for daily use, and only boot into the "hackintosh" 10.8 setup when you need to work on your project.

If this package is indeed capped, it is just as stupid and sad as the 5GB caps on 4G wireless data plans.

If my sleepy math is right, you reach the old 250GB cap in a little less than 2 hours and the rumored new 300GB cap in a little over 2 hours. If they stick with the proposed 10$ per 50GB overage charge, you can enjoy paying about $25/hr to use your 305Mb/s connection after the first 2 hours.

MOD PARENT UP!

I've been doing the same thing for years with a similar Macpro1,1 that I use as a dev box for 10GbE ethernet drivers. When 10.6 previews offered a 64b kernel, I was majorly pissed that I had a less than 2 year old $3000 machine that I could not use to test my drivers in 64-bit mode. So I did what you did & turned my MacPro into a hackintosh.

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