SpamAssassin is *awesome*. I have been using it for a week, testing to see what it marks as spam. It has NEVER made a mistake yet - no spam got past it, and it never marked a legitimate message as spam.
So I consider my problems as an end user of email basically solved. The only drawback is I'm still paying for the bandwidth to download all this crud... Now if only the major ISPs ran SpamAssassin themselves...*
*Note: there's probably a big commercial opportunity here for SpamAssassin or a similarly sophisticated "fuzzy logic" spam detector!
Personally I see this OpenGL 2.0 proposal as a wishful me-too effort by a 3D vendor-wannabe. Last time I checked 3DLabs wasn't in shooting range of NVIDIA or even ATI. Why would either of the two leading vendors stop and do a bunch of boring standardization work - initiated by a potential competitor - when they could be developing proprietary extensions to sell more products?</cynic>
I actually think standardizing stuff like vertex and pixel shaders is the wrong thing to do right now - there are too many differences between the major implementations that smoothing them over in a universal API would be costly/inelegant, and the feature sets are changing very rapidly (new texture modes every 6 months!)... It would be smarter to wait a year or two, when things will have settled down a bit, and then write the standard in stone.
khuber may be referring to the work going on at Stanford to develop a Renderman -> OpenGL translator (it takes a Renderman shader as input and outputs code for a sequence of OpenGL rendering passes that produces the same result). This is an attractive alternative to hand-coding calls to OpenGL extensions, which are becoming more fragmented and clumsy to use. (see John Carmack's recent.plan entry - Doom III will use a different shading back end for each family of OpenGL cards - so much for a consistent standard!)
Thankfully Andre Hendrick's IDE patch seems to find the optimal hdparm settings for a drive automatically - once I started using the patch, I got uniformly high transfer rates (20-30 MB/sec) without running hdparm manually.
Linux has been able to do what you describe (many priority levels, selectable real-time policies) for a long time. What Irix does have over Linux currently is scheduling of resources other than the CPU - disk I/O being the most important one.
On Linux, a low-priority process won't take much CPU away from a high-priority process... But if the low-priority process does a lot of disk I/O, it can cause significant delays in the high-priority process's own disk I/O. i.e. the notion of priority does not carry over to disk I/O. Whereas on Irix, you can set up a process to get a guaranteed level of disk bandwidth...
Look for this feature to appear in Linux soon though. The newly-introduced I/O elevator should make it easier to implement prioritization for disk I/O.
1) although network traffic and context switches are not the main problem with X, cutting the window manager out of the loop would probably almost double the speed of handling window move/resize events. (do you *really* want to wake up the WM on every mouse interrupt, when X is perfectly capable of moving windows itself?)
2) it is *hard* to write a good WM. There are lots of little details in event handling/ordering, client communication, etc, that are easy to get wrong or omit. One common codebase, approved by the X developers, could reduce the proliferation of semi-correct WMs.
3) are WMs *really* that different? I've used many of them over the past couple years (sawmill/sawfish, icewm, kwin, enlightenment 16, 4Dwm, the GNUstep one...). Honestly the only reason I've switched WMs is because I saw a neat theme that wasn't available for the one I was using =). Aside from that, I've set them all up to operate almost the same way... So I don't really see the benefit in having 10-20 mediocre WMs rather than 1-2 really good ones... Minor customizations like theming and different window behaviors should be added through small DLL plugins rather than writing a whole new WM...
Just for completeness, I should add that I belive most of X's problems stem from limitations in the hardware it was originally intended to run on (i.e. achingly slow framebuffers on a slow network).
e.g. window resize events are handled asynchronously because back when X was being designed, it was unthinkable for the client and graphics hardware to be able to respond interactively. But today's hardware can handle this with ease - and that's why window resizing feels so much better on MS Windows - because GDI was designed with assumptions that fit modern machines (i.e. fast video hardware, and no network, so synchronous resizing is not a problem).
It's sort of a self-fulfilling prophecy - X thinks of itself as a slow graphics system implemented over a high-latency network, and so that's what it becomes, even though the hardware is capable of so much more...
I've looked at this extensively with kernel tracing tools - the X wire protocol is not the bottleneck. The problems are:
1) X server event loop should be driven by the monitor retrace, not by mouse/keyboard events
2) Resizing windows should be synchronous, not asynchronous (this causes the "lag" effect when resizing a window on X)
3) Toolkits should be double-buffering everything, using client-side layout code (rather than X window objects), and holding all drawing until input events have been handled.
4) (controversial) - get rid of the window manager; incorporate it into the X server.
I remember reading a story about a shareware author who performed an experiment to see just how willing people are to register shareware. He distributed a small but useful program in two ways - half of the users got it as honorware (fully functional; registration is encouraged), and half of the users got it as crippleware (very limited functionality; registration needed to unlock the full problem). The registration rate for the crippleware version was three times higher than the honorware version.
So there is a significant free-rider problem here that can't be ignored... (this is the problem with honor-system and similar payment schemes - there are too many freeloaders out there =)
I agree... The content companies need to realize that it is now impossible to regulate access to copyrighted works. No matter how hard they try, they will not be able to prevent people from giving unauthorized access to others.
But here is the key - access is only part of the value the content companies provide - there are also things like convenience (how easy is it to download one particular song or episode of a TV show?), quality (how good is the download bandwidth?), and atmosphere (you can't download the experience of watching a movie in a theatre, or attending a live concert!). Unlike access, these things can't be transmitted across a P2P network...
Only once companies wake up to the fact that preventing unlicensed access is a lost game, and start focusing on non-replicable sources of value, will they be able to accept and profit from the internet.
What we got from Linux users were not sales, but tons of email demanding that we put up the binary executeables on an ftp site for free so they could download them and use them with their Windows version of the game.
Maybe this is a clue towards a better marketing angle for your services? Linux customers are in this strange situation where the majority of them also run (and buy games for) Windows. So naturally they see a Linux binary as an incremental "nice-to-have" add-on, whereas they won't look twice at a standalone full-price Linux product.
Have you considered giving these people exactly what they ask (for a small fee of course)? I mean, don't produce or ship a full boxed product, just sell downloadable Linux binaries for say 20% the purchase price of the full game (and maybe charge a bit extra for optional tech support hand-holding). This way you get less revenue per sale, but you might make a lot more sales. Of course the economics of this business model might not work out; I just hope it's something you've considered.
I definitely see this too... In fact I'm about to start a full crusade against shitty windowing performance. (long visible lags between exposure and repaint, very jerky moving/resizing, etc). These are very real issues on Linux/XFree86. I plan to go as far as shooting my screen with a 100Hz camera to really see what's going on, retrace by retrace.
There are many links in the GUI chain, any of which can cause a problem. Roughly from top to bottom-
1. Widget toolkit (GTK, QT, etc)
2. Client painting library (GDK, QT, etc)
3. Window manager
4. X protocol
5. context switches
6. X server
7. 2D video card driver
The folklore seems to be that 4, 5, and 7 are the major problems - "the X protocol is badly designed, switching between client, server, and window manager processes is too expensive, and XFree86's video drivers are no good."
In reality though, the problems aren't where most people expect. The X protocol is not generally a bottleneck, especially if the client programmer knows what he's doing (wait until the input queue empties before repainting anything, avoid synchronous behavior, double-buffer windows using server-side pixmaps, etc). The copy-and-context-switch overhead isn't too bad either (keep in mind that context switches are much more expensive on Windows, and Windows is the platform to beat for 2D smoothness!). And finally, many of the 2D drivers really do take advantage of all the hardware offers.
The real culprits are turning out to be 1 and 3 - the tookits and window managers. Many of the Linux toolkits (especially GTK) have very advanced widget alignment/constraint systems that bog down when windows are resized. Some toolkits are doing naughty things with the event loop (painting while events are still in the input queue, or trying to "optimize" by pausing for new events), and most of them aren't fully double-buffered yet (though GTK 2.0 and recent KDE/QT are most of the way there). Window managers are some of the most horrific perpetrators of 2D crappiness. Some of them try too hard to snap or quantize window sizes and positions, resulting in jerky motion. Kwin seems to prolong expose/repaint cycles much more than necessary. And finally, I will make one criticism of X's overall architecture - I don't think separating the window manager from the X server was a good choice. The asynchronous relationship between X and the wm can cause nasty delays in window moving and resizing. (plus, all widely-used wm's have basically the same features these days; what's the use of having a choice?;]).
I used to think that the only way to get perfectly smooth 2D would be to embed the widget toolkit in the X server, so that it could handle repainting all on its own. Now I don't think one needs to go that far; it may just take a well-written window manager, and a similarly carefully-designed widget toolkit. (though it may be helpful for the server to mandatorily double-buffer every window - hey, video RAM is plentiful these days =)
There are lots of issues I haven't investigated yet - for instance, I think Windows may be doing something interesting with vblank; dragging windows around seems to show a lot less tearing compared to X... Also, 3D OpenGL windows seem to cause much worse artifacting on both X and MS Windows. It's almost possible to bring an animating OpenGL program to a complete halt just by resizing the window, or dragging another window in front of it.
It's an interesting problem, and I'm glad to see I'm not the only one who cares about it. I find it apalling that (to my knowledge) not one major 2D GUI system has been able to produce 100% correct results - i.e. every window correctly drawn on every single monitor retrace, even while dragging or resizing. Why should we settle for less than 100%?
That's pretty moot with the latest X releases (4.x is pretty freaking fast, expecially when optimized.) Graphics performance on my box is actually a little better under Linux/X (and FreeBSD/X) than Win2k Pro.
X will always be slower than GDI, because of the client->server copy and context switch (whereas with GDI it's just fill command buffer, then execute). Not that this is a bad thing - network transparency is great, and the speed difference can theoretically be made arbitrarily small, given enough optimization of the X code =). At this point though the basic problem is that the X protocol is too stateless, and so you waste time sending massive amounts of state between the client and the server. (believe me, I've used LTT to make kernel traces of Mozilla redrawing - it's nasty. It's not just a simple expose event->redraw round-trip; it's several round trips...).
It's icky, but often irrelevant (since most Linux programs just fork additional processes, and this is pretty clean. Under Linux, process creation is much less expensive than in Windows).
That's completely true, and all of my own software uses multiple processes for concurrency rather than threads =). But, we are talking about Mozilla here. Mozilla makes extensive use of pthreads:[. (ideally a web browser should just be one thread using async socket I/O; although I might go along with having a second thread for async disk I/O, and/or doing Java garbage collection asynchronously)
does anyone have a reasonable explanation on why the performance is so radically different between linux/win
X is slow (vs. GDI on Windows)
the pthreads implementation on Linux is bloated and nasty
the Linux C++ environment is not quite as efficient as the Windows C++ environment (could be an older version of GCC or std C++ library leading to bloated cache-stomping code...)
So if it's not a big deal, why was there a general call for prior art to overturn Apple's patent?
The big deal with this patent is not its implications for PNG, MNG, or SVG - it's the abundance of *published* prior art, from way earlier than the patent was applied for. It's a blatantly obvious case of the USPTO not doing its homework.
The cool thing about this announcement is that it probably means we will start to see NVIDIA's technology in smaller/lighter notebooks. The -2Go chips were great, but OEMs only packaged them in monstrous, heavy, machines like the Dell 8100. I assume this new chip is something like the low-end "MX" series, so it should be available in lighter notebooks (if not in ultralights).
Finally I will get both my wishes - an easily portable notebook, with graphics hardware by the only company that can engineer a good graphics system. (news flash: ATI doesn't count. Their driver developers couldn't program themselves out of a cardboard box)
One other thing that definitely falls in the "please suck less" category is write caching... Lots of otherwise decent ATA drives lie about data having been written to the platters, when it is really still just in the drive's on-board cache. This inflates benchmark numbers, but it also makes it impossible for the operating system to guarantee filesystem integrity. (journaling filesystems don't work when the drive lies about what data has really made it to the disk...)
As far as I know most SCSI drives don't deceive the OS in this way.
The main reason I am interested in 64-bit platforms today is to take advantage of the bigger address space... People working on high-end graphics and scientific simulations are already needing several GB to run one program. Yes, you can shove up to 64GB in certain x86 machines, but even with 1GB you start running into problems, because you have to enable highmem for the kernel to be able to access all of it, and highmem is probably one of the least stable parts of the Linux kernel today... And then when you reach 3.5GB or so (per process) you are just plain out of address space, and it's game over.
So, in the near future I will definitely be in the market for some 64-bit machines. The problem is, how to put them together cheaply? I can get a top-of-the-line dual Athlon for $2000 these days... But modern Alphas and SPARCs are still in the several-$k range, and basic IA-64 machines are going for $10,000+ today. Hopefully in the next year or two we will start to see much cheaper 64-bit platforms... (I'm mostly counting on x86-64. I think AMD has the right idea to make an incremental enhancement to x86 without throwing it all out the window; and hopefully their price points won't be as astronomical as the other 64-bit options).
"well now that we have all this power, why don't we use it all" and so they end up writing applications and OS's that hog all the newly available extra resources
Your statement is 100% correct but I strongly disagree with its implication... By wasting CPU cycles and disk space, programmers are achieving a higher level of complexity much more quickly and easily than before. e.g. by developing software in garbage-collected or dynamic languages like Java or Python, which dramatically reduce the difficulty of software development, at a moderate cost in efficiency.
Also consider e.g. a program that stores its data in flat or XML text files, versus packed binary files. The binary files are obviously going to waste less space, but you'll sure have a hard time editing them by hand.
If you are using ReiserFS be aware that it does not journal file data, only filesystem metadata - i.e. after a crash your directory tree will always be intact, but files that were open during the crash can and will often have junk or misplaced data written to them.
It is for this reason that I'm switching my machines to ext3. IMHO corrupted files after a crash are just as intolerable as a corrupted filesystem. (ext3 does have a reiserfs-like metadata-only journaling mode, but by default it journals everything - at a small performance cost of course).
I am very happy to see someone else realize that Linux != GNU/Linux. i.e. the Linux kernel is perfectly capable of supporting any user-space environment you care to create, not just the standard glibc + GNU utilities. (yes this particular project is building on glibc/XFree, but you get my point).
I was very disappointed to see a lot of earlier OS projects (including the other BeOS-based ones) starting from scratch with their own kernel. This is nonsense. A startup group is never going to be able to write Ethernet drivers or debug VM code faster than the Linus-led kernel group. Why not just start with the Linux kernel and build up from there? Even if your project does need extra kernel-space functionality, just write a Linux module to provide it.
Don't get bogged down starting from scratch on your own MM system or IDE drivers when working, well-tested code is just waiting for you to reuse! (and if the GPL bothers you, there is this thing called FreeBSD...)
Q3A scores go up, but real-world performance suffers
You have to keep in mind that for a large class of users, Q3A scores are the only measure of real-world performance =).
If by "real-world" performance you mean things like 3D CAD programs, I've got news for you- ATI's drivers are so buggy that no sane person would use them for serious 3D work. Plus a majority of "serious" 3D software is written using dated OpenGL techniques (e.g. glVertex() instead of vertex buffers). These programs are never going to be fast on any hardware or driver.
Slashdot Mirror
SpamAssassin is *awesome*. I have been using it for a week, testing to see what it marks as spam. It has NEVER made a mistake yet - no spam got past it, and it never marked a legitimate message as spam.
So I consider my problems as an end user of email basically solved. The only drawback is I'm still paying for the bandwidth to download all this crud... Now if only the major ISPs ran SpamAssassin themselves...*
*Note: there's probably a big commercial opportunity here for SpamAssassin or a similarly sophisticated "fuzzy logic" spam detector!
I actually think standardizing stuff like vertex and pixel shaders is the wrong thing to do right now - there are too many differences between the major implementations that smoothing them over in a universal API would be costly/inelegant, and the feature sets are changing very rapidly (new texture modes every 6 months!)... It would be smarter to wait a year or two, when things will have settled down a bit, and then write the standard in stone.
khuber may be referring to the work going on at Stanford to develop a Renderman -> OpenGL translator (it takes a Renderman shader as input and outputs code for a sequence of OpenGL rendering passes that produces the same result). This is an attractive alternative to hand-coding calls to OpenGL extensions, which are becoming more fragmented and clumsy to use. (see John Carmack's recent .plan entry - Doom III will use a different shading back end for each family of OpenGL cards - so much for a consistent standard!)
Yep, sounds familiar =).
Thankfully Andre Hendrick's IDE patch seems to find the optimal hdparm settings for a drive automatically - once I started using the patch, I got uniformly high transfer rates (20-30 MB/sec) without running hdparm manually.
Linux has been able to do what you describe (many priority levels, selectable real-time policies) for a long time. What Irix does have over Linux currently is scheduling of resources other than the CPU - disk I/O being the most important one.
On Linux, a low-priority process won't take much CPU away from a high-priority process... But if the low-priority process does a lot of disk I/O, it can cause significant delays in the high-priority process's own disk I/O. i.e. the notion of priority does not carry over to disk I/O. Whereas on Irix, you can set up a process to get a guaranteed level of disk bandwidth...
Look for this feature to appear in Linux soon though. The newly-introduced I/O elevator should make it easier to implement prioritization for disk I/O.
A couple of reasons-
1) although network traffic and context switches are not the main problem with X, cutting the window manager out of the loop would probably almost double the speed of handling window move/resize events. (do you *really* want to wake up the WM on every mouse interrupt, when X is perfectly capable of moving windows itself?)
2) it is *hard* to write a good WM. There are lots of little details in event handling/ordering, client communication, etc, that are easy to get wrong or omit. One common codebase, approved by the X developers, could reduce the proliferation of semi-correct WMs.
3) are WMs *really* that different? I've used many of them over the past couple years (sawmill/sawfish, icewm, kwin, enlightenment 16, 4Dwm, the GNUstep one...). Honestly the only reason I've switched WMs is because I saw a neat theme that wasn't available for the one I was using =). Aside from that, I've set them all up to operate almost the same way... So I don't really see the benefit in having 10-20 mediocre WMs rather than 1-2 really good ones... Minor customizations like theming and different window behaviors should be added through small DLL plugins rather than writing a whole new WM...
Just for completeness, I should add that I belive most of X's problems stem from limitations in the hardware it was originally intended to run on (i.e. achingly slow framebuffers on a slow network).
e.g. window resize events are handled asynchronously because back when X was being designed, it was unthinkable for the client and graphics hardware to be able to respond interactively. But today's hardware can handle this with ease - and that's why window resizing feels so much better on MS Windows - because GDI was designed with assumptions that fit modern machines (i.e. fast video hardware, and no network, so synchronous resizing is not a problem).
It's sort of a self-fulfilling prophecy - X thinks of itself as a slow graphics system implemented over a high-latency network, and so that's what it becomes, even though the hardware is capable of so much more...
I've looked at this extensively with kernel tracing tools - the X wire protocol is not the bottleneck. The problems are:
1) X server event loop should be driven by the monitor retrace, not by mouse/keyboard events
2) Resizing windows should be synchronous, not asynchronous (this causes the "lag" effect when resizing a window on X)
3) Toolkits should be double-buffering everything, using client-side layout code (rather than X window objects), and holding all drawing until input events have been handled.
4) (controversial) - get rid of the window manager; incorporate it into the X server.
Yep. Compile once, run anywhere =).
(well, it won't work if the mod is distributed as a
I remember reading a story about a shareware author who performed an experiment to see just how willing people are to register shareware. He distributed a small but useful program in two ways - half of the users got it as honorware (fully functional; registration is encouraged), and half of the users got it as crippleware (very limited functionality; registration needed to unlock the full problem). The registration rate for the crippleware version was three times higher than the honorware version.
So there is a significant free-rider problem here that can't be ignored... (this is the problem with honor-system and similar payment schemes - there are too many freeloaders out there =)
But here is the key - access is only part of the value the content companies provide - there are also things like convenience (how easy is it to download one particular song or episode of a TV show?), quality (how good is the download bandwidth?), and atmosphere (you can't download the experience of watching a movie in a theatre, or attending a live concert!). Unlike access, these things can't be transmitted across a P2P network...
Only once companies wake up to the fact that preventing unlicensed access is a lost game, and start focusing on non-replicable sources of value, will they be able to accept and profit from the internet.
Escalade originally planned to discontinue their IDE controllers, but due to public demand they decided to continue production...
What we got from Linux users were not sales, but tons of email demanding that we put up the binary executeables on an ftp site for free so they could download them and use them with their Windows version of the game.
Maybe this is a clue towards a better marketing angle for your services? Linux customers are in this strange situation where the majority of them also run (and buy games for) Windows. So naturally they see a Linux binary as an incremental "nice-to-have" add-on, whereas they won't look twice at a standalone full-price Linux product.
Have you considered giving these people exactly what they ask (for a small fee of course)? I mean, don't produce or ship a full boxed product, just sell downloadable Linux binaries for say 20% the purchase price of the full game (and maybe charge a bit extra for optional tech support hand-holding). This way you get less revenue per sale, but you might make a lot more sales. Of course the economics of this business model might not work out; I just hope it's something you've considered.
I definitely see this too... In fact I'm about to start a full crusade against shitty windowing performance. (long visible lags between exposure and repaint, very jerky moving/resizing, etc). These are very real issues on Linux/XFree86. I plan to go as far as shooting my screen with a 100Hz camera to really see what's going on, retrace by retrace.
;]).
There are many links in the GUI chain, any of which can cause a problem. Roughly from top to bottom-
1. Widget toolkit (GTK, QT, etc)
2. Client painting library (GDK, QT, etc)
3. Window manager
4. X protocol
5. context switches
6. X server
7. 2D video card driver
The folklore seems to be that 4, 5, and 7 are the major problems - "the X protocol is badly designed, switching between client, server, and window manager processes is too expensive, and XFree86's video drivers are no good."
In reality though, the problems aren't where most people expect. The X protocol is not generally a bottleneck, especially if the client programmer knows what he's doing (wait until the input queue empties before repainting anything, avoid synchronous behavior, double-buffer windows using server-side pixmaps, etc). The copy-and-context-switch overhead isn't too bad either (keep in mind that context switches are much more expensive on Windows, and Windows is the platform to beat for 2D smoothness!). And finally, many of the 2D drivers really do take advantage of all the hardware offers.
The real culprits are turning out to be 1 and 3 - the tookits and window managers. Many of the Linux toolkits (especially GTK) have very advanced widget alignment/constraint systems that bog down when windows are resized. Some toolkits are doing naughty things with the event loop (painting while events are still in the input queue, or trying to "optimize" by pausing for new events), and most of them aren't fully double-buffered yet (though GTK 2.0 and recent KDE/QT are most of the way there). Window managers are some of the most horrific perpetrators of 2D crappiness. Some of them try too hard to snap or quantize window sizes and positions, resulting in jerky motion. Kwin seems to prolong expose/repaint cycles much more than necessary. And finally, I will make one criticism of X's overall architecture - I don't think separating the window manager from the X server was a good choice. The asynchronous relationship between X and the wm can cause nasty delays in window moving and resizing. (plus, all widely-used wm's have basically the same features these days; what's the use of having a choice?
I used to think that the only way to get perfectly smooth 2D would be to embed the widget toolkit in the X server, so that it could handle repainting all on its own. Now I don't think one needs to go that far; it may just take a well-written window manager, and a similarly carefully-designed widget toolkit. (though it may be helpful for the server to mandatorily double-buffer every window - hey, video RAM is plentiful these days =)
There are lots of issues I haven't investigated yet - for instance, I think Windows may be doing something interesting with vblank; dragging windows around seems to show a lot less tearing compared to X... Also, 3D OpenGL windows seem to cause much worse artifacting on both X and MS Windows. It's almost possible to bring an animating OpenGL program to a complete halt just by resizing the window, or dragging another window in front of it.
It's an interesting problem, and I'm glad to see I'm not the only one who cares about it. I find it apalling that (to my knowledge) not one major 2D GUI system has been able to produce 100% correct results - i.e. every window correctly drawn on every single monitor retrace, even while dragging or resizing. Why should we settle for less than 100%?
X will always be slower than GDI, because of the client->server copy and context switch (whereas with GDI it's just fill command buffer, then execute). Not that this is a bad thing - network transparency is great, and the speed difference can theoretically be made arbitrarily small, given enough optimization of the X code =). At this point though the basic problem is that the X protocol is too stateless, and so you waste time sending massive amounts of state between the client and the server. (believe me, I've used LTT to make kernel traces of Mozilla redrawing - it's nasty. It's not just a simple expose event->redraw round-trip; it's several round trips...).
It's icky, but often irrelevant (since most Linux programs just fork additional processes, and this is pretty clean. Under Linux, process creation is much less expensive than in Windows).
That's completely true, and all of my own software uses multiple processes for concurrency rather than threads =). But, we are talking about Mozilla here. Mozilla makes extensive use of pthreads :[. (ideally a web browser should just be one thread using async socket I/O; although I might go along with having a second thread for async disk I/O, and/or doing Java garbage collection asynchronously)
The big deal with this patent is not its implications for PNG, MNG, or SVG - it's the abundance of *published* prior art, from way earlier than the patent was applied for. It's a blatantly obvious case of the USPTO not doing its homework.
How about an annual list of mis-inventions? i.e. old, widely-published or common-sense ideas that were "rejuvenated" this year by being patented?
The cool thing about this announcement is that it probably means we will start to see NVIDIA's technology in smaller/lighter notebooks. The -2Go chips were great, but OEMs only packaged them in monstrous, heavy, machines like the Dell 8100. I assume this new chip is something like the low-end "MX" series, so it should be available in lighter notebooks (if not in ultralights).
Finally I will get both my wishes - an easily portable notebook, with graphics hardware by the only company that can engineer a good graphics system. (news flash: ATI doesn't count. Their driver developers couldn't program themselves out of a cardboard box)
One other thing that definitely falls in the "please suck less" category is write caching... Lots of otherwise decent ATA drives lie about data having been written to the platters, when it is really still just in the drive's on-board cache. This inflates benchmark numbers, but it also makes it impossible for the operating system to guarantee filesystem integrity. (journaling filesystems don't work when the drive lies about what data has really made it to the disk...)
As far as I know most SCSI drives don't deceive the OS in this way.
The main reason I am interested in 64-bit platforms today is to take advantage of the bigger address space... People working on high-end graphics and scientific simulations are already needing several GB to run one program. Yes, you can shove up to 64GB in certain x86 machines, but even with 1GB you start running into problems, because you have to enable highmem for the kernel to be able to access all of it, and highmem is probably one of the least stable parts of the Linux kernel today... And then when you reach 3.5GB or so (per process) you are just plain out of address space, and it's game over.
So, in the near future I will definitely be in the market for some 64-bit machines. The problem is, how to put them together cheaply? I can get a top-of-the-line dual Athlon for $2000 these days... But modern Alphas and SPARCs are still in the several-$k range, and basic IA-64 machines are going for $10,000+ today. Hopefully in the next year or two we will start to see much cheaper 64-bit platforms... (I'm mostly counting on x86-64. I think AMD has the right idea to make an incremental enhancement to x86 without throwing it all out the window; and hopefully their price points won't be as astronomical as the other 64-bit options).
Your statement is 100% correct but I strongly disagree with its implication... By wasting CPU cycles and disk space, programmers are achieving a higher level of complexity much more quickly and easily than before. e.g. by developing software in garbage-collected or dynamic languages like Java or Python, which dramatically reduce the difficulty of software development, at a moderate cost in efficiency.
Also consider e.g. a program that stores its data in flat or XML text files, versus packed binary files. The binary files are obviously going to waste less space, but you'll sure have a hard time editing them by hand.
It is for this reason that I'm switching my machines to ext3. IMHO corrupted files after a crash are just as intolerable as a corrupted filesystem. (ext3 does have a reiserfs-like metadata-only journaling mode, but by default it journals everything - at a small performance cost of course).
I am very happy to see someone else realize that Linux != GNU/Linux. i.e. the Linux kernel is perfectly capable of supporting any user-space environment you care to create, not just the standard glibc + GNU utilities. (yes this particular project is building on glibc/XFree, but you get my point).
I was very disappointed to see a lot of earlier OS projects (including the other BeOS-based ones) starting from scratch with their own kernel. This is nonsense. A startup group is never going to be able to write Ethernet drivers or debug VM code faster than the Linus-led kernel group. Why not just start with the Linux kernel and build up from there? Even if your project does need extra kernel-space functionality, just write a Linux module to provide it.
Don't get bogged down starting from scratch on your own MM system or IDE drivers when working, well-tested code is just waiting for you to reuse! (and if the GPL bothers you, there is this thing called FreeBSD...)
You have to keep in mind that for a large class of users, Q3A scores are the only measure of real-world performance =).
If by "real-world" performance you mean things like 3D CAD programs, I've got news for you- ATI's drivers are so buggy that no sane person would use them for serious 3D work. Plus a majority of "serious" 3D software is written using dated OpenGL techniques (e.g. glVertex() instead of vertex buffers). These programs are never going to be fast on any hardware or driver.