It was gone from day one. Just keep using X.

The X.Org team has been planning X12 for years. http://www.x.org/wiki/Development/X12 is the roadmap. We will probably start X12 development as soon as all X11 bugs are fixed. (Haha, only serious.)

Also, what do you mean by "resources or balls?" Plenty of challengers have shown up over the years. DirectFB, Fresco, Berlin, Y Windows, etc. None of them displaced X because *X is a hell of a lot better than you give it credit for*. Wayland's developer realizes this; he's not trying to replace X, but to work alongside it.

What? X's lack of builtin 3D support in the protocol isn't a bad thing. X's core protocol is dead simple because it was designed to be extended. High-quality font rendering isn't in the core either; is that something to be outraged about as well? Imagine for a moment that X *did* have 3D support in the core. It would be PHIGS all the way (http://en.wikipedia.org/wiki/PHIGS) and you'd be complaining about that instead.

Wayland, compared to X, has *no* core rendering protocol. There's no 3D support, and also no 2D support.

This isn't a fork. Wayland shares no code with X, although it uses the same external xkb library.

We've advocated not directly programming in Xlib for years now, alongside admonishments to authors of new WMs and toolkits. There are mature, well-tested, usable toolkits out there already, and we encourage people to use them.

Intel, AMD, nVidia, Apple, Synaptics, Pluggable, and XGI all contribute to X.org, and all somehow get along.

I'm certainly not Keith or Jim, and they don't really like to talk about this stuff, but as I see and understand it, the straw that broke the camel's back wasn't the licensing change, but the kicking out of Keith and friends from CVS access, which was caused by Mr. Dawes' paranoia about talk of a fork.

Which makes this much more parallel to the XF86/X.org situation than, say, cdrtools/cdrkit. (I have to confess that I completely forgot the old name of cdrkit; that's how effective the fork was at squashing relicensed code!)

Yes, I would imagine that some mixing of positions would certainly result at that point.

Zeno's paradox of movement is reconcilable. For your version, start by addressing the problem as a geometric series with initial step a = 1/2 and ratio r = 1/2. Then the sum s of the series is 1/2 + 1/4 + 1/8 + ..., and since the ratio is less than one, a finite sum may be obtained by the classic formula s = a/(1 - r) = (1/2)/(1 - 1/2) = (1/2)/(1/2) = 1.

If your initial step is 1/9 and your ratio is 1/10, then your series terms are 1/9 + 1/90 + 1/900 + ... = 0.9 + 0.09 + 0.009 + ... = 0.999..., and your sum is, once again, 1.

Didn't even need calculus for this one. :3

As we keep saying, we cannot do anything about the fact that Adobe's Flash Player does not accelerate many operations, and usually ends up going slower when acceleration is enabled and used.

My recommendation is *still* to use youtube-dl or get-flash-videos, save the FLV video locally, and then watch it with a Real Movie Player, like mplayer, VLC, etc.

I attended a talk by one of the technical MS VPs at Oregon State University, where he talked about the challenges of scaling up to massively multi-core machines. His talk basically covered the various SMP/NUMA optimizations that Linux has had for a while, and how Win7's kernel has been adapted to do the same things as Linux in these situations. Notably, a section of the talk was dedicated to NUMA and how massively SMP systems start to have the same kinds of memory access problems as NUMA systems.

Very cool guy; got to chat with him after the talk about Wine and various Windows technologies, etc.

tl;dr Win7 is roughly at the same spot as Linux WRT scheduling and scaling for NUMA/massive SMP systems.

Are you saying that my Core i3 is plotting against me? Well. Good thing I burdened it with continuous recompiles of OpenOffice. Let's see it rise up against me now!

(For added fun, re-read in Adam West's voice. Hell, read all of Slashdot in Adam West's voice. It's great.)

Gallium requires some sort of adapter to interface with hardware. There are no such adapters for any MS kernel, save for the closed-source VMWare stuff.

Those docs were never public; they were only released to Precision Insight for The Weather Channel's r200 driver and never really saw the light of day. To be fair, the PI guys did a *really* great job of writing self-documenting code, which helped r300's DRI driver happen, but the actual docs are long gone AFAIK. Maybe some of the PI guys still have them, but they can't release them.

fglrx support for r500 and earlier (anything before the HD lines) is already delegated to the open-source drivers. We're working on getting r800 (redwood) support for acceleration together, and r600 support is getting better by the day.

Other way around; AMD has always released specs and started releasing ATI specs after ATI was acquired. You may notice that http://www.x.org/docs/AMD/ is lacking docs for the r200 and earlier; that's because AMD made the acquisition during the r400 era, and the docs for older chipsets were more or less lost forever at that point.

Right now, the open-source drivers are called radeon, r300, r600, etc.; one developer committed his code as "amd" instead at one point. (It got changed to avoid end-user confusion.)