At the same time, /v/ is no longer about video games, /mu/ is useless for talking about real music, etc. The best board is easily /po/.

It's certainly a better place than DA for artists, but that's not saying much.

It bothered me so much that I went out and built an open-source server which uses less RAM and CPU. This is not unlike my burning hatred of fglrx. :3

You sound like a Notch shill. How's that going for you? :3

I work for OSUOSL. Is that not a real job?

http://en.wikipedia.org/wiki/New_I/O

He is a terrible programmer.

He doesn't use Java NIO; instead, he uses threads. Wanna guess how many threads he spawns on startup? How about how many threads he spawns per connected player? (Answer: 12 and 4.)

His wire protocol and disk format are horrible. No delimiters, no seekability, no fixed packet sizes. He invented his own little standards and they are horrible. http://www.minecraft.net/docs/NBT.txt is the disk format; before that, he just serialized the Java classes directly to disk. (And to wire; one of the Alpha wire packets was just a chunk of the disk format!)

His grasp of GL is embarrassingly awful. He pridefully boasts GL 1.1 compatibility, but the fact is that he uses no features or extensions from GL 1.2 or later, including shaders, dynamic lighting, or vertex buffer objects. All of the drawing is done in slow display lists, and the lighting is done through a statically stored light map. (This might not set off alarm bells if you haven't done GL before. Trust me when I say that this is horribly slow.)

I wouldn't mind if it weren't for the fact that he has charged for alpha-quality software, as part of an open alpha test.

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.