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.
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.
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!)
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.
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.)
Radeon firmware is used to program a few special-purpose chips on the board. Up until the HD series, firmware was only needed to start up the DMA engine and get acceleration going; modern cards need a second piece of firmware to enable interrupts, for e.g. low-latency audio and vsync.
If anybody ever wanted to go out and reverse-engineer these blobs, they could, but it's really not worth the trouble since the level of functionality is so small and AMD already gives us bugfixes for the ucode when needed. That time might be better spent figuring out the patented parts of the chipset (video decoding, texture compression) which AMD isn't allowed to document for us.
I don't have an HDMI audio sink (feel free to send me one, BTW!) but HDMI audio should work on just about every Radeon that has it. The driver exposes the I2C controls for the audio to the rest of the kernel, and then the pre-existing ALSA code handles the rest.
Nouveau has working Gallium code for your GPU, but it's not officially supported by the project because it's not stable enough. Fedora and Ubuntu have special experimental DRI packages available that enable nouveau's 3D acceleration.
For h.264 acceleration, you will have to wait for somebody to write it, which likely means waiting until the patents on it run out.
Xorg's exemption comes from libGL, which needs to have text relocations because of the way DRI works. (Long version: DRI has a way to load on older X servers with newer GL versions by dynamically rewriting the API entry point table. Requires text relocations since the data for the entry points needs to be marked executable after the library's already in memory.) It's not going to be fixed because it's not a problem; if you really didn't want people doing questionable things on your system, you would already have disabled DRI. (Yes, this is actual policy. Letting people submit commands directly to your GPU is *always* unsafe.)
Xorg doesn't need to run as root; Moblin already has made the switch, and other distros are getting ready to follow. Running as root is only necessary with input drivers (or some rare video drivers) that don't have the ability to talk to the HW through a normal kernel interface as non-root.
Slashdot Mirror
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
You are just jealous that he made a kickass game that became insanely popular, and you still can't get a real job
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.
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.)
That one commercial where the sumo wrestler uses a voice-activated phone to order pizza.
Radeon firmware is used to program a few special-purpose chips on the board. Up until the HD series, firmware was only needed to start up the DMA engine and get acceleration going; modern cards need a second piece of firmware to enable interrupts, for e.g. low-latency audio and vsync.
If anybody ever wanted to go out and reverse-engineer these blobs, they could, but it's really not worth the trouble since the level of functionality is so small and AMD already gives us bugfixes for the ucode when needed. That time might be better spent figuring out the patented parts of the chipset (video decoding, texture compression) which AMD isn't allowed to document for us.
I don't have an HDMI audio sink (feel free to send me one, BTW!) but HDMI audio should work on just about every Radeon that has it. The driver exposes the I2C controls for the audio to the rest of the kernel, and then the pre-existing ALSA code handles the rest.
Nouveau has working Gallium code for your GPU, but it's not officially supported by the project because it's not stable enough. Fedora and Ubuntu have special experimental DRI packages available that enable nouveau's 3D acceleration.
For h.264 acceleration, you will have to wait for somebody to write it, which likely means waiting until the patents on it run out.
Xorg's exemption comes from libGL, which needs to have text relocations because of the way DRI works. (Long version: DRI has a way to load on older X servers with newer GL versions by dynamically rewriting the API entry point table. Requires text relocations since the data for the entry points needs to be marked executable after the library's already in memory.) It's not going to be fixed because it's not a problem; if you really didn't want people doing questionable things on your system, you would already have disabled DRI. (Yes, this is actual policy. Letting people submit commands directly to your GPU is *always* unsafe.)
Xorg doesn't need to run as root; Moblin already has made the switch, and other distros are getting ready to follow. Running as root is only necessary with input drivers (or some rare video drivers) that don't have the ability to talk to the HW through a normal kernel interface as non-root.