I even happen to know that. Sleep, I need more of.

    OG.

Out of the $20, there's approximatively $6-8 for the library (amazon being the worst there, they want $10 iirc), $3-4 for printing, $2-4 for shipping and the distributor if there is one (and in NG's case, I'm sure there is). So that's $4-9 left, i.e. $2-7 for the publisher (and closer to $2 than to $7). The publisher is definitively not ripping him off.

    OG.

That's because the high-end server world accepts level of single-core performance the consumer world doesn't. These processors are not something you want on your PC. You want something with better memory management, way faster I/O with ram and GPU, etc. OTOH, you usually don't care about multi-processor.

But faster I/O usually means putting more things on the die (hence amd's integrated memory controllers, now followed by Intel) and having larger busses/more efficient protocols, and acting on that means changing the socket. And the north bridge, if one is left. And the memory, for a faster one. You wouldn't get enough speedup from changing the cpu alone with everything else pin-compatible to make it worth it.

Meanwhile, the itanic spends its time waiting for the ram to answer... but since you put a lot of them in the box, in aggregate they can be useful.

    OG.

Niiiiiiice. $19 trillions just for the wind turbines (around 5M each), $100 trillions for the rooftop PV systems (around 60K each), but there is no economic issue. Right.

Only $135 billions for the dams (around 500M each)... if you can find 270 new places in where to put them...

    OG.

X11 the protocol was very good 20 years ago, but by now shows its age. A new X12 could use some cleanups such as removing colors, palettes and visuals (truecolor is the only relevant one nowadays), adding explicit gamma support, removing every drawing primitive except unaliased points, horizontal/vertical lines and image handling, adding alpha support, adding efficient image transfer mechanisms by mapping video-card accessible buffers in the application (XShmPutImage and glTexSubImage2D are sad jokes, performance-wise), adding blending/compositing support, etc. And that's just graphics, don't get me started about multi-screne handler, internationalization, window management or inter-process communications.

As for the "specific add-ons", I was talking about 2D X rendering, you know, the thing that draws your windows, 3D rendering, which you may have heard about, and video decoding, the thing linux users do in software because less that one "standard" per video card vendor would be unacceptable. Vaapi happens to be intel's (vdpau is nvidia's, xvba is amd's). Nothing obscure there. And if you think they're independant you either haven't looked at the problem and the hardware or your blood level is too high in your coffee stream.

At first sight, the opengl 3 level intel cards have three beautifully separated subsystems, 2D blitter, 3D renderer, media decoder. Then you find out that only one can be used at a given time, and you have to explicitely switch between them. And, in addition, things like glClear are better handled with the 2D blitter, compositing, frame filtering and deinterlacing with the 3D hardware, etc. And in practice you want to unify pixmaps, textures and movie frame buffers, otherwise pain ensues when you want to use the damn things. So the interdependance level is actually high. As a result it is *very* wrong to have these pieces in separate projects, because communication layers and version issues multiply exponentially.

Finally, I don't know about OS X, but the Windows architecture for video drivers is actually superior than the current linux ones. You have one kernel-level driver and one userspace driver, and that's it. The API is not the best possible by far, with way too many functions, communication paths and a somewhat obsolete shader microcode. But the unification of all the hardware functions in two drivers with the kernel boundary in between is the best you can have.

And, the point you missed, is that the refactoring *will* *not* *happen* for political and social reasons. Even before patches, the first step would be to unify all that stuff under one tree, and the pushback against that is demented.

    OG.

Oh please, when you bitch about something use real facts. Mesa is at OpenGL 2.1, and the, I think, hardest part for reaching 3.x, a full featured optimizing GLSL compiler, is well on its way. As for Windows, the DE hits the 2D and 3D parts of the DirectX driver, obviously.

    OG.

Graphics drivers are all over the place. For instance, the intel stack, to be complete, requires:
- the xserver tree
- the protocols tree
- the libdrm tree
- the intel 2d video driver (includes separated DDX driver and XvMC driver)
- the kernel (drm tree)
- mesa with its integrated drivers
- libva (for vaapi)

That's 5 hardware-accessing drivers (internal kernel, DDX, XvMC, internal Mesa, libva) in 4 trees linked together with libraries and applications coming from 3 more trees. And they call each other through layers and layers of function arrays with no real documentation at any level. It's always fun when trying to understand a function to see it calling another one through a function pointer which after two more indirections finally ends up in another function a paragraph after the original one. And you have to trace everything, because the just as innocuous call after that one is in fact going to send a message through a drm connection and the X server to the DDX driver. And will be as documented as the previous one. Add to that a (failed, but present) tentative in the code to support almost any combination of versions in this dreadful house of cards, and you end up with an astounding amount of added complexity that does not make debugging easy.

And fixing that is probably not going to ever happen until X/Mesa is dead under its own weight. The bitching when the n protocol trees became the one protocols tree was incredible, I don't see the poor soul who managed that one doing it ever again.

    OG.

You may consider the editor to be a middle man, but real editors are *way* much more than that.

    OG.

There is one "secret" key tucked into an apple-specific chip on the motherboard (smc) which is used to decrypt critical files of the system.

      OG.

You have a strange definition of efficiency. In my universe it's [money used on medical stuff by medicaid]/[money given to medicaid]. Doesn't matter if there is any relationship between the person giving and the person recieving. Or charities would be awfully close to 0%.

    OG.

And medicaid seems to be around 94-96%.

I wonder how smart it is to design a spec now with the upper boundary in size equivalent to a normal hard drive. Why stop at 32bits addressing when 48 probably doesn't make much of a difference (the 16 extra will be all zero for a while after all, close to no cost on the card and negligible on the controller) and would match (s)ata that way with its far more future-proof 128PB limit.

Flash cards seem to move as fast as HDDs, they only started later.

    OG.

You missed that one Watt Balance.

The lump of platinum is precise at around 5e-8, the watt balance has reached 3.6e-8 at that point, but they expect to do better than that. The Nist, while holding the record right now, does not seem to have chosen the best path to reach better precisions than that. 1e-9 is expected (hoped? ;-) in some of the french experiments in a handful of years.

    OG.

No we don't. This is not the crawler you're looking for.

    OG.

Gas turbines (no water) are fast to start and stop, and they're very good when you need power *now*. They're used in France a lot for peaks. Civilian nuclear takes 2-3 days to change power levels significantly. I suspect that, compared to submarines, size matters.

    OG.