points are all valid, but you only specified the largest DRAM manufacturer (samsung), and the 4th largest (micron) by market share, but missed #2 (hynix) and #3 (elpida).

Palladium is ASIC-based, not FPGA-based (the way older IKOS boxes were; yes FPGAs are ASICs...). So far as I'm aware, the ASICs used are basically "verilog accelerator" chips, supporting a limited subset of the language (mainly just synthesizeable constructs, with some exceptions). The verilog is compiled into a bytecode that the processors handle natively. It's analogous to the "java accelerator" ASICs that have been discussed here off and on. That grossly understates the complexity of the system, but from my exposure to it, that's basically what it is.

Yeah, but pretty sure Win7 Aero (and OSX quartz extreme, and maybe compiz too) are different. This was the first thing I found along those lines with a simple search:

http://www.anandtech.com/show/2760/5

Well, yeah, could maybe be swapping. But the system can't use the video card framebuffer as general-purpose memory. So swapping the contents to disk would really only make sense if the usage of the framebuffer is at a very high percentage. Hence my (untested) belief that having a larger framebuffer would help. But, maybe they're using the same memory management/swap code as for the normal system VM, that tends to page out to disk earlier than absolutely necessary. So it could be that the "swapiness" of data in the framebuffer is unnecessarily high. Disabling the swapfile might be a good test for this... Thanks for that suggestion. :)

It's anecdotal, to be sure... All I can tell you is that when I have tons of windows open on Win7, then switching to old ones takes a while to repaint (and it's quite noticeable). With few windows open, it's effectively instantaneous (i.e presumably within a few VSYNCs). And, no offense taken, but I absolutely do want high-performance tab/window switching in my desktop applications. If I don't have to wait for contents to be repainted, then I don't want to.

And yes, I'm quite well aware that transfers from system memory to the GPU (or any other device) over PCIe are plenty fast for desktop normal operations. That's why I suspect the framebuffer size, rather than bandwidth to/from system memory, is the limiting factor. It's the only resource that would be approaching its limit with a huge number of windows open.

Other anecdotal point, WinXP doesn't show this same behavior with similar numbers of windows. Haven't had a chance to play with compiz or OSX, so I cannot comment on those. My *nix usage is generally limited to remote connections over NX, VNC, or just a remote xterm.

2GB for visualization is just too small. 8GB would be a good start, even if it was DDR3 and not DDR5.

Maybe. I've only somewhat-recently found myself occasionally wanting more than 512MB on a graphics card; perhaps I am just insufficiently hardcore (I can live with that).

That said: If 512MB is adequate for my not-so-special wants and needs, and 2GB is "just too small" for some other folks' needs, then a target of 8GB seems to be rather near-sighted.

I may be misinformed, but I'm pretty certain systems like Win7 with Aero keep normal 2D window contents (like firefox opened to /.) as textures stored exclusively in the framebuffer. A 1600*1200 window is going to be a little under 8MB, which means you can probably only keep about 70 such window textures resident in a 512MB framebuffer, assuming there's no other data stored there.

I wouldn't call myself hardcore, but others might. At work I usually have upwards of 30+ windows open at a time, with multiple web browsers (each with multiple tabs), xterms, emails, documents, etc. I don't really randomly switch between all of them, the work-flow is very much like a stack with an occasional flush/purge of really old stuff. When I've got a seriously deep stack building, it's easy to have twice as many windows open. And in such scenarios, switching to an older window results in it being a blank, gray rectangle for several seconds. I assume this is because the texture that was that window was forced out of the framebuffer per an LRU policy, and has to be rerendered before it can be displayed.

I have long suspected, but haven't made an effort to prove, that moving to a video card with a 2GB framebuffer would dramatically improve my desktop experience under such heavy-usage scenarios.

Spot on for at least the first four points... seems like the break happened fairly recently too (this week?).

Lenovo L220X, by any chance? I love mine, and off and on do an ebay search for another one. Wish I'd bought several when they were still available...

Not positive, but I'm pretty sure I registered sometime in '97; September or October, maybe. You old-timers must have me beat by maybe a day or two... I don't even remember how I found the site. Was probably an altavista search for "linux", or something similar...

Obviously there are implementation hurdles, and those may be high enough that it's not worth the effort (or cost). But, if such a scheme were implemented, your ISP might track your ratio, but subsequent networks would track the ratio of your ISP, or the backbone connections, etc. So you'd need some sort of wide-scale peering agreement that the network will tolerate X% of high priority packets, and that X applies to all users, and everyone on the network can effectively enforce that. You may be right though, that from a practical standpoint, it may be easier or more fair (for everyone) to not bother with such a scheme.

I've made this point before (seems more recent than 2009... where did the time go...?), but there's no reason to give an infinite amount of high-priority bandwidth to anyone. That is to say, customers could promote/demote their packets based on whatever criteria they choose, but once the monthly quota of high-priority data has been reached, everything is auto-demoted to whatever level is appropriate to ensure minimal interference to those who are playing fairly.

On pain of torture + death...?

Actually, as far as amazon is concerned, you'd set it to "PASSWORD". Sort of a "tr '[a-z]' '[A-Z]' | crypt" thing.

Freedom doesn't have to be zero-sum, does it?

Simple: People talk... Or HR does something stupid, like accidentally send a copy of someone's offer letter to the whole office... Or send a copy of the promotion package worksheet to a "public" printer, not bothering to use the PIN-to-print function (and not even just walking to the printer after hitting 'print'). I could go on and on... And of course, none of these things have ever happened where I work.