1.) Framebuffer device and X fighting
It just means you aren't configuring your system properly. Commodity/PC hardware doesn't require a framebuffer device. If you're planning on using X and you have a native X video driver you are not supposed to enable framebuffer at all.
You should only be building framebuffer into your kernel if you're planning on using the fbdev X driver. The kernel documentation states, very clearly, that using X in conjunction with framebuffer can lead to unexpected results.

2.) UNIX was made before the "video age" and graphical user interfaces are hackish kludges
Yes and no.
NetBSD incorporates an X server into its kernel. This is no different than what Windows XP does. Both use pre-empted graphics models based on an IPC model (with Windows XP using pipes, and X using a TCP/IP loopback).
Windows Vista is moving the graphics server out of the kernel and into user space, to increase security and stability. This will make it almost identical to MacOS X or Linux.

Furthermore, now that Xorg has released X11R7 development will accelerate, and we'll be getting all of those fancy features from OSX and Java Desktop (like OpenGL composition).

3.) Desktop Environments hide the user from UNIX
Yes, they do. Wanna know why?
It's because the POSIX userspace sucks. The only advantage to it is that it's fairly well-documented and it's easy to build applications that use it.

I have it on good faith from multiple members of the Windows team that Windows, itself, has a backend similar to that of UNIX. NT could be every bit as flexible as UNIX is - right down to removing the GUI or replacing it with X or whatever - but it was a design decision not to make this functionality available to the end user.
Know why? Because the average Windows user is as dumb as a rock. Microsoft could include all of the advanced options and the base command console, but then your network would be destroyed by some idiot CEO who thinks he's hot **** because he can use Excel.

Windows hides way more from the end user than KDE does. And every release of Windows brings NT closer and closer to modern UNIX, too.

Thanks for the info... you seem to know a lot about software! (not being a smantass here...)

I use NetBSD, and I think it's great... but over the years, I've noticed that Unix in general has a lot of warts due to so much growth beyond it's humble beginnings. What do you think of Plan 9, which doesn't have the archaic "tty" device for example, as it was acually made for modern PC's with bitmap displays?

I think it's amazing that Unix has gone so far, but I think you have to admit that the age of it's design must be holding it back in some ways. (although I doubt that any other OS designed in 1969 would have survived this long!)

As far as layering software to hide underlying problems... well, it just seems ugly to me to add complexity to the system... but I suppose it's necessary as to work with the old system in new ways in a situation where an obsolete system is entrenched. But that's why I like Plan 9.

You know, the UNIX userspace was made for programmers. I think that has something to do with being hard to use.

Ahh crap, I'm being idealistic again... better start learning lojban again.

UNIX is no more backwards than Windows is. The only parts of modern UNIX that are similar to the original AT&T UNIX are the userland tools. The Linux and Mach kernels and underlying APIs have been revised thoroughly.
In fact, this is the big advantage of having an opensource monolithic kernel: when an API is revised or rendered obsolete, the software and drivers which depend upon that API can be rewritten, or the new API can be wrapped with a legacy interface (OSS->ALSA, APM->ACPI).

Windows has a more explicit API but that's partially to compensate for its shortcomings. Under Windows, for instance, you can provide memory allocation hinting and manipulate DEP flags. This is cool, but you don't need to do it under Linux. It's also much easier to perform asynchronous I/O under Windows, but that's because every stream operation is asynchronous with automatic blocking (HACK).

New Linux interfaces are striving to implement what benefits are left in the Windows world. EVMS is going to be the default partitioning option in the next major release of Ubuntu. Soon X is going to handle audio, and DRI is going to become standard (so graphics drivers are moved back into the kernel, which will improve power management support).

We mainly owe these improvements to the support of a few companies and individuals, sadly. Google's Summer of Code project improved things dramatically; Ubuntu was funded by a millionaire philanthropist. HP is contributing heavily on the image acquisition and printing front (to support its own product lines), IBM and Novell are doing it to kill each other,..... sigh.

No, the userspace was made for ancient machines. "cp" instead of "copy", "mv" instead of "move".
At the time they were using printer terminals. It was half to save paper, and half because the keys took about 2 pounds of force to depress.

Visual Studio was made for programmers but it's easy to use. Convoluted =/= Software Development. Convoluted = Poor Design.

Just wondering... what is the Windows equivilant of Unix pipes for building programs out of little prgrams?

You'll never find a decent analogue because Windows and UNIX treat data differently. Microsoft is developing a UNIX-like shell for Windows, but instead of passing data through character streams it passes data through .NET objects (Monad). MS-DOS had very limited support for it - mainly just for redirecting output to a text file and stuff.

Windows has other mechanisms for modularization: COM and .NET, for instance. DirectShow is a good example: it's the same basic concept as a system of UNIX pipes, except it's object-oriented and designed for handling video.

In the larger context of an operating system, a 'pipe' is an IPC mechanism. That's what I mean when I talk about pipes, not UNIX pipes.

This **** hurts my god damn head.