Slashdotters think copyright law is wrong and piracy is okay.
I think you have two distinct groups of slashdotters confused. Those of us who support the GPL do not pirate Microsoft Windows (we don't want it or need it) and we do not pirate music.
We're fundies man. Do not make me car bomb your OEM Microsoft Windows CDs.
Obama has to realize, though, that if these loopholes are closed, the tax rates will have to come down a bit to compensate for that, or else we really will have a tax system that's too hostile to corporations.
Don't you kinda sorta think that's the point? Obama is shutting down private industry and that's what he has promised all along.
Raising corporat taxes doesn't affect the consumer as badly as you believe.
Corporate taxes are passed straight through to the consumer, what kind of glue are you sniffing? By raising commodity prices (and lowering gross sales) they also affect how many employees can be hired.
Lower corporate income taxes to 0% and cancel future bailout money and the recession/depression would end almost immediately and we would be rolling in prosperity. It's not as if corporate income isn't taxed already (at least through several different layers).
Then MS and any other supposed 'American' corporation should be charged an 'exit' fee equal to twenty times that too oppressive tax burden - and be barred from ever receiving any Federal contract or subcontract.
Um, reread what you just wrote and look at any convenient definition of tyranny. As for federal contracts, have you been paying any attention to news of late? The only governmental contracts that will matter soon will be with the PRC and perhaps Japan and/or India.
I also read a quote somewhere else of somebody saying "Airplanes might be safer than cars, but I'd rather arrive at my destination with a false sense of security than feel like I've narrowly escaped death."
I've spent vastly fewer hours in an airplane than in a car. My health was pretty much destroyed in 1995 when a speeding car rear ended me (it killed my car). I was not killed because I was wearing my seatbelts, but often I wish I was.
It certainly would have been kinder if that person (likely drunk, since they drove away immediately - unsolved hit and run) had killed me rather than leaving me alive to face a lifetime of pain.
Or you could call me "homophobic". Your way is kinder.
It also disturbs me that between my own machines and my work machines there are only two different CPU architectures x86 and sparc. 20 years ago, I regularly worked on six (maybe more, it's been a long time).
And the easiest way to do it is make Visual Studio (or your compiler and IDE of choice) faster. If Visual Studio is fast, developers won't feel the need to upgrade their machines, and so do not need to perpetuate this cycle.
Pass the bong over here brother Slashdotter. I want some of whatever it is you're smoking.
Development platform != Target platform (though it is better practice to keep the two in sync, it's not always possible)
Vista can aggressively cache *and* leave resources to user programs.
Caching is retaining resources obtained from a slow source medium in a higher speed medium after an initial request.
What Vista does is fill your RAM with stuff it thinks you're likely to use, in a background thread when your computer is idle. Thus it takes none of your (the user) time.
Nope. Not the same thing. That's precaching. A precache patch to Linux was rejected precisely because people noticed the same sorts of things Microsoft Vista users are complaining about.
The issue with precaching is lets say the operating system decides to load/usr/bin/emacs into pagecache, just because I might use it. Now, since I'm an XEmacs user that's all wasted pagecache space and the time it took to load it. Background or not, it consumes system resources.
I do want large data files, particularly obtained via NFS to be cached as long as reasonable. That's a typical work use case.
My two most frequently loaded apps are World of Warcraft and Mail.app. In neither case do I want those loaded at system boot or at any other time that I have not selected them to be loaded. WoW is for play and I want it to reside quietly on disk when I'm doing something else. Mail.app I only use when I'm connected to the company VPN. There's an idiot MSEXCHANGE server behind it, so a few seconds loading time doesn't impact the sync time once its loaded.
I certainly do not want NeoOffice precached because even though it's kind of slow to load, it's usually wasted space because I only ever need to use it once a week or so.
If Microsoft Vista is really doing precaching not caching, then perhaps you should listen to your users screaming out in pain.
The only real crime is that every other OS doesn't do the same thing.
Whatever. Linux doesn't do it because it causes performance issues. Precaching != caching. Linux, Solaris, Mac OS X seem to be pretty good at caching things people want to have cached. Or to put it in other terms, you have "invented" something that has been rejected as inferior technology in the Unix world. Can you guys please take out a software patent on it? Thanks.
Caching something that will never be used again will eventually correct itself. Precaching something that will never be used is a total waste of system resources.
Look at vim. It uses ~7M on a fresh start. That's a bit much for a CLI editor, don't you think? Emacs is worse. Sure, the systems can handle it just fine these days, but it's not insignificant.
That's an apples and oranges comparison. emacs is intended to stay up for months editing dozens if not hundreds or thousands of files in a session. Start up time is insignificant.
Vi (now called nvi) and vim are two different beasties. Vi is great for when you need a quick edit on a machine you just logged into and do not want to create a backup file. At least, that's my use case for vi.
I think vim is bloated and not good at what it does. Traditional vi is quite good at what it does and I, for one, will gladly welcome my nvi overlords to get a useful vi back.
Thanks for pointing that out. The Senior Programmer mentioned above sounds like he spent a lot of years doing embedded design.
Could be. ~15 years is just long enough that he could have been trained by FORTRAN programmers too.
Or it could be that you've run into the guy I used to work with in the 1980s who was the whiz kid (graduated top of his class), fresh out of college, and frankly admitted he couldn't understand anything more complicated than arrays. He then proceeded to implement a complicated naturally graph structured and open-ended data algorithm using fixed sized arrays even after I spent hours explaining to him how to do that with more appropriate data structures.
In some cases any attempt at understanding the underlying metal is going to hurt your project's portability, when someone in the team gets cocky and implements a platform dependent optimization.
Agreed, but to some extent it depends on the application context. In my current job, I am maintaining an application that is a custom database that runs on only one server at a time.
There is certainly some motivation to make machine specific optimizations as performance is always an issue. The wise programmer knows enough about the metal (and the underlying OS) to know which optimizations are portable and which are not.
I've had to make code work on more different versions of Unix (and underlying architecture type) than there exists of different versions of Microsoft Windows, including the "service packs". This also means that I've never written serious code to take specific advantage of Linux-only system calls, as much I like Linux (user since 1995, developer since 1987).
It rather worries me that so many of the younger generation have never truly experienced heterogeneous environments.
One catch in performance is that it sure is faster to use RAM for data, but there is also a lot of useless data floating around in RAM, which is a waste of resources.
RAM is cheap these days.
I thought we were talking about performance? Adding more memory for a slow app does not necessarily make it faster when we're involved with parallel architectures. Maybe that ought to be a law of its own. See http://lwn.net/Articles/250967/
All memory is not created equal. As CPU speeds have risen, it is becoming increasingly expensive to access main memory - you need to keep things in the CPU cache(s). As NUMA architectures increase in importance, that will become even more true. Today's supercomputer is tomorrow's high end server is next week's common desktop box. Anyway, Ulrich Drepper put it better than I can in the link above.
Storage devices are still slow and the most interesting ones have a finite (Though still large) number of writes.
That part is true, however absolute read/write speed may not necessarily have anything to do with absolute performance. The basic idea is that you need to move less rarely accessed data to more expensive (in terms of access time) storage and keep the most actively accessed data in the fastest cache/(on|off node)memory as you can.
This often explains why old languages like C, Cobol etc. are able to do the same thing as a program written in C++, Java or C# at the fraction of the resource cost and at much greater speed.
C is very much "sugar coated assembly language". As a very low level language it allows with dispensing will all unnecessary language features. COBOL was never a language touted for its speed, a better example is Ada. While not quite as low level as C, it has come a remarkably long ways as compiler technology has improved and it *was* designed with performance as a goal.
The disadvantage is that the old languages require more skills from the programmer to avoid the classical problems of deadlocks and race conditions as well as having to implement functionality for linked lists etc.
Those are strange examples. C++ and Java have no special provisions to address deadlocks (out of the languages listed so far, only Ada attempted to address that with its rendezvous based parallelism). Any real world parallel application is prone to race conditions no matter what language it's written in. Linked lists as basic type are common in functional languages and there's no doubt about it, it's a lot more convenient to deal with lists as a basic type not a library.
A lot of object-oriented programming is somewhat like using 18-wheelers for grocery shopping.
Maybe you should have stopped there.
I think the internet would be better off with something more akin to Ada as a base language than anything else. The way the language regards data coming from the outside world with utter contempt and horror is exactly the right kind of attitude you need to develop safe web applications.
That's still about 100 times more memory than is required to edit a text file. How do you think people got by in the 286 days when 640 Kb was standard ? Does vim allocate ridiculously oversized buffers just to show a blank screen ?
Wrong era for vi. How about 64k of address space and separate I & D spaces got you double that? VAX 11/780s, which were about as standard as you could get for the early to mid 80s were expandable up to 1MB. VAX 8600s (VAX 11/790) expandable to 256MB. Of course on multiuser systems, you have to share memory with everyone else...
Vim has plugins. It also has graphics modes that you can compile into it. I find it absolutely fascinating that the vim binary in Mac OS X 10.5.7 is 2.7MB. The XEmacs 21.4.20 binary I'm using is 1.6MB. Empirical evidence would suggest that they're trying to sneak the kitchen sink into vim.
Oh and get off my lawn! i286s and 640k being standard indeed.
It's fast because it is run on machines that are many orders of magnitude more capable than when 'vi' was originally written.
Yes, but...
My first introduction to vi was on the computer science VAX in school. I was fortunate enough to have serial terminal connection in my dorm room (a whopping 1200 BAUD). On the nights when the class using Mathematica had homework due vi was totally unusable. ed was still usable though.
Page's law doesn't apply to vi proper (nvi nowadays). That hasn't had any new features added to it for many years. It does apply to vi -> vim though. If you run the two side by side[1], there is a noticeable difference.
FSF Emacs -> XEmacs could also be considered an application of Page's law. More features, more code, slower.
Of things I have intimate knowledge, the sequence XEmacs 19.12 (regarded by some as the fastest XEmacs ever) to 19.14 (regarded as the slowest of the 19s) is certainly Page's Law. 19.14 to 19.16 bucked Page's law, though 19.16 was largely a maintenance release so it was more or less as fast as 19.15 which improved on 19.14 quite a bit. XEmacs 20.0 to 21.1 was also inverse Page's Law as 21.1 with internationalization compiled out was faster than the 19s were.
Of course Page's Law can be broken. It's very hard work, but it can be broken.
[1] Actually I do. On the infrequent occasions I have use of vi, I get vim on Mac OS X/Linux and classic vi on Solaris.
Say I get prompted to enter a password. I have the password in a text file under the application which has the dialog open. But I can't get to it. Modality for an application is fine but you should still be able to move it around the screen.
Agreed. The whole concept behind modal dialog boxes is broken, but why can't you just switch to another virtual desktop that is not so crowded on the screen?
I find it fascinating that broken GUI can be a defacto standard. I find it interesting that Microsoft is still playing catch up and will get there eventually as it looks like they've been making serious progress over the last few years.
How about making window management not block when a modal dialog is open?
(That's the definition by the way). Modal dialog boxes have always been the work of the devil. It doesn't model the way things work in real life. The phone rings at the same time one of your children starts crying, etc. etc.
I find it fascinating (and probably why I've become so comfortable with Mac OS X, even though the current version has definite stability issues) that Apple learned their lesson on that. The only modal dialog box is the system reboot/shutdown box and there it makes sense.
I first wrote this two decades ago - "a system that cannot do a 100[1] different things at a time is just a toy". It's still true.
Taskbars are a sad joke. When I was doing GUI design back in the mid 80's, I showed a screen with a prototype taskbar to a mentor for review and basically got a NOOOOOOOOOOOO! back. Odd that that ended up capturing mind share. The longer I work with Spaces, the more I agree. Maybe 10.6 will have it better integrated with the system, but even the current implementation beats the pants off the best virtual desktop WM[2] I've ever used.
Now, give me true "focus follows mouse" and I'm your slave forever.
(May I please have the pseudo plain old text style of posting back! That was so much more convenient than this crap).
Slashdot Mirror
Sigh, my name is Steve B. you insensitive clod.
The problem is that the average secretary or even call center worker might have enough access to pass along just enough to allow a breakin like this.
That appears to be the case, if the poster below, who posted T-Mobile passwords is to be believed.
If these hackers are lying, with the sole intent to damage T-Mobile's reputation, then they've already wildly succeeded
T-Mobile is quite capable of damaging their own reputation.
I do not applaud law-breaking, but nobody deserves it more than you do. Worst company I've ever had the displeasure of doing business with.
Where do I sign up for the class action suit? I long-ago canceled my account, but I couldn't delete my private information out of your system.
Slashdotters think copyright law is wrong and piracy is okay.
I think you have two distinct groups of slashdotters confused. Those of us who support the GPL do not pirate Microsoft Windows (we don't want it or need it) and we do not pirate music.
We're fundies man. Do not make me car bomb your OEM Microsoft Windows CDs.
In summation: "CHKDSK-OFF" Balmer.
There, fixed that for you.
Obama has to realize, though, that if these loopholes are closed, the tax rates will have to come down a bit to compensate for that, or else we really will have a tax system that's too hostile to corporations.
Don't you kinda sorta think that's the point? Obama is shutting down private industry and that's what he has promised all along.
Raising corporat taxes doesn't affect the consumer as badly as you believe.
Corporate taxes are passed straight through to the consumer, what kind of glue are you sniffing? By raising commodity prices (and lowering gross sales) they also affect how many employees can be hired.
Lower corporate income taxes to 0% and cancel future bailout money and the recession/depression would end almost immediately and we would be rolling in prosperity. It's not as if corporate income isn't taxed already (at least through several different layers).
Then MS and any other supposed 'American' corporation should be charged an 'exit' fee equal to twenty times that too oppressive tax burden - and be barred from ever receiving any Federal contract or subcontract.
Um, reread what you just wrote and look at any convenient definition of tyranny. As for federal contracts, have you been paying any attention to news of late? The only governmental contracts that will matter soon will be with the PRC and perhaps Japan and/or India.
I also read a quote somewhere else of somebody saying "Airplanes might be safer than cars, but I'd rather arrive at my destination with a false sense of security than feel like I've narrowly escaped death."
I've spent vastly fewer hours in an airplane than in a car. My health was pretty much destroyed in 1995 when a speeding car rear ended me (it killed my car). I was not killed because I was wearing my seatbelts, but often I wish I was.
It certainly would have been kinder if that person (likely drunk, since they drove away immediately - unsolved hit and run) had killed me rather than leaving me alive to face a lifetime of pain.
I think it speaks volumes that our poop can be seen from space. Let us know when Bill Gates or Steve Ballmer poop can be seen too.
<1% market share indeed.
Or you could call me "homophobic". Your way is kinder.
It also disturbs me that between my own machines and my work machines there are only two different CPU architectures x86 and sparc. 20 years ago, I regularly worked on six (maybe more, it's been a long time).
Try running any latest version of KDE on hardware that's several years older than it.
I have. Performance is not an issue, stability is. And your point is?
And the easiest way to do it is make Visual Studio (or your compiler and IDE of choice) faster. If Visual Studio is fast, developers won't feel the need to upgrade their machines, and so do not need to perpetuate this cycle.
Pass the bong over here brother Slashdotter. I want some of whatever it is you're smoking.
Development platform != Target platform (though it is better practice to keep the two in sync, it's not always possible)
Vista can aggressively cache *and* leave resources to user programs.
Caching is retaining resources obtained from a slow source medium in a higher speed medium after an initial request.
What Vista does is fill your RAM with stuff it thinks you're likely to use, in a background thread when your computer is idle. Thus it takes none of your (the user) time.
Nope. Not the same thing. That's precaching. A precache patch to Linux was rejected precisely because people noticed the same sorts of things Microsoft Vista users are complaining about.
The issue with precaching is lets say the operating system decides to load /usr/bin/emacs into pagecache, just because I might use it. Now, since I'm an XEmacs user that's all wasted pagecache space and the time it took to load it. Background or not, it consumes system resources.
I do want large data files, particularly obtained via NFS to be cached as long as reasonable. That's a typical work use case.
My two most frequently loaded apps are World of Warcraft and Mail.app. In neither case do I want those loaded at system boot or at any other time that I have not selected them to be loaded. WoW is for play and I want it to reside quietly on disk when I'm doing something else. Mail.app I only use when I'm connected to the company VPN. There's an idiot MSEXCHANGE server behind it, so a few seconds loading time doesn't impact the sync time once its loaded.
I certainly do not want NeoOffice precached because even though it's kind of slow to load, it's usually wasted space because I only ever need to use it once a week or so.
If Microsoft Vista is really doing precaching not caching, then perhaps you should listen to your users screaming out in pain.
The only real crime is that every other OS doesn't do the same thing.
Whatever. Linux doesn't do it because it causes performance issues. Precaching != caching. Linux, Solaris, Mac OS X seem to be pretty good at caching things people want to have cached. Or to put it in other terms, you have "invented" something that has been rejected as inferior technology in the Unix world. Can you guys please take out a software patent on it? Thanks.
Caching something that will never be used again will eventually correct itself. Precaching something that will never be used is a total waste of system resources.
Look at vim. It uses ~7M on a fresh start. That's a bit much for a CLI editor, don't you think? Emacs is worse. Sure, the systems can handle it just fine these days, but it's not insignificant.
That's an apples and oranges comparison. emacs is intended to stay up for months editing dozens if not hundreds or thousands of files in a session. Start up time is insignificant.
Vi (now called nvi) and vim are two different beasties. Vi is great for when you need a quick edit on a machine you just logged into and do not want to create a backup file. At least, that's my use case for vi.
I think vim is bloated and not good at what it does. Traditional vi is quite good at what it does and I, for one, will gladly welcome my nvi overlords to get a useful vi back.
You mean Symbolics Lisp Machines - http://www.lispmachine.net/
Thanks for pointing that out. The Senior Programmer mentioned above sounds like he spent a lot of years doing embedded design.
Could be. ~15 years is just long enough that he could have been trained by FORTRAN programmers too.
Or it could be that you've run into the guy I used to work with in the 1980s who was the whiz kid (graduated top of his class), fresh out of college, and frankly admitted he couldn't understand anything more complicated than arrays. He then proceeded to implement a complicated naturally graph structured and open-ended data algorithm using fixed sized arrays even after I spent hours explaining to him how to do that with more appropriate data structures.
In some cases any attempt at understanding the underlying metal is going to hurt your project's portability, when someone in the team gets cocky and implements a platform dependent optimization.
Agreed, but to some extent it depends on the application context. In my current job, I am maintaining an application that is a custom database that runs on only one server at a time.
There is certainly some motivation to make machine specific optimizations as performance is always an issue. The wise programmer knows enough about the metal (and the underlying OS) to know which optimizations are portable and which are not.
I've had to make code work on more different versions of Unix (and underlying architecture type) than there exists of different versions of Microsoft Windows, including the "service packs". This also means that I've never written serious code to take specific advantage of Linux-only system calls, as much I like Linux (user since 1995, developer since 1987).
It rather worries me that so many of the younger generation have never truly experienced heterogeneous environments.
One catch in performance is that it sure is faster to use RAM for data, but there is also a lot of useless data floating around in RAM, which is a waste of resources.
RAM is cheap these days.
I thought we were talking about performance? Adding more memory for a slow app does not necessarily make it faster when we're involved with parallel architectures. Maybe that ought to be a law of its own. See http://lwn.net/Articles/250967/
All memory is not created equal. As CPU speeds have risen, it is becoming increasingly expensive to access main memory - you need to keep things in the CPU cache(s). As NUMA architectures increase in importance, that will become even more true. Today's supercomputer is tomorrow's high end server is next week's common desktop box.
Anyway, Ulrich Drepper put it better than I can in the link above.
Storage devices are still slow and the most interesting ones have a finite (Though still large) number of writes.
That part is true, however absolute read/write speed may not necessarily have anything to do with absolute performance. The basic idea is that you need to move less rarely accessed data to more expensive (in terms of access time) storage and keep the most actively accessed data in the fastest cache/(on|off node)memory as you can.
This often explains why old languages like C, Cobol etc. are able to do the same thing as a program written in C++, Java or C# at the fraction of the resource cost and at much greater speed.
C is very much "sugar coated assembly language". As a very low level language it allows with dispensing will all unnecessary language features. COBOL was never a language touted for its speed, a better example is Ada. While not quite as low level as C, it has come a remarkably long ways as compiler technology has improved and it *was* designed with performance as a goal.
The disadvantage is that the old languages require more skills from the programmer to avoid the classical problems of deadlocks and race conditions as well as having to implement functionality for linked lists etc.
Those are strange examples. C++ and Java have no special provisions to address deadlocks (out of the languages listed so far, only Ada attempted to address that with its rendezvous based parallelism). Any real world parallel application is prone to race conditions no matter what language it's written in. Linked lists as basic type are common in functional languages and there's no doubt about it, it's a lot more convenient to deal with lists as a basic type not a library.
A lot of object-oriented programming is somewhat like using 18-wheelers for grocery shopping.
Maybe you should have stopped there.
I think the internet would be better off with something more akin to Ada as a base language than anything else. The way the language regards data coming from the outside world with utter contempt and horror is exactly the right kind of attitude you need to develop safe web applications.
That's still about 100 times more memory than is required to edit a text file. How do you think people got by in the 286 days when 640 Kb was standard ? Does vim allocate ridiculously oversized buffers just to show a blank screen ?
Wrong era for vi. How about 64k of address space and separate I & D spaces got you double that? VAX 11/780s, which were about as standard as you could get for the early to mid 80s were expandable up to 1MB. VAX 8600s (VAX 11/790) expandable to 256MB. Of course on multiuser systems, you have to share memory with everyone else ...
Vim has plugins. It also has graphics modes that you can compile into it. I find it absolutely fascinating that the vim binary in Mac OS X 10.5.7 is 2.7MB. The XEmacs 21.4.20 binary I'm using is 1.6MB. Empirical evidence would suggest that they're trying to sneak the kitchen sink into vim.
Oh and get off my lawn! i286s and 640k being standard indeed.
It's fast because it is run on machines that are many orders of magnitude more capable than when 'vi' was originally written.
Yes, but ...
My first introduction to vi was on the computer science VAX in school. I was fortunate enough to have serial terminal connection in my dorm room (a whopping 1200 BAUD). On the nights when the class using Mathematica had homework due vi was totally unusable. ed was still usable though.
Page's law doesn't apply to vi proper (nvi nowadays). That hasn't had any new features added to it for many years. It does apply to vi -> vim though. If you run the two side by side[1], there is a noticeable difference.
FSF Emacs -> XEmacs could also be considered an application of Page's law. More features, more code, slower.
Of things I have intimate knowledge, the sequence XEmacs 19.12 (regarded by some as the fastest XEmacs ever) to 19.14 (regarded as the slowest of the 19s) is certainly Page's Law. 19.14 to 19.16 bucked Page's law, though 19.16 was largely a maintenance release so it was more or less as fast as 19.15 which improved on 19.14 quite a bit.
XEmacs 20.0 to 21.1 was also inverse Page's Law as 21.1 with internationalization compiled out was faster than the 19s were.
Of course Page's Law can be broken. It's very hard work, but it can be broken.
[1] Actually I do. On the infrequent occasions I have use of vi, I get vim on Mac OS X/Linux and classic vi on Solaris.
Say I get prompted to enter a password. I have the password in a text file under the application which has the dialog open. But I can't get to it. Modality for an application is fine but you should still be able to move it around the screen.
Agreed. The whole concept behind modal dialog boxes is broken, but why can't you just switch to another virtual desktop that is not so crowded on the screen?
I find it fascinating that broken GUI can be a defacto standard. I find it interesting that Microsoft is still playing catch up and will get there eventually as it looks like they've been making serious progress over the last few years.
The whole *point* of a modal dialog is to block the application underneath it. Blame the application developers, for poor use of modal dialogs.
The whole point of morphine to is reduce the feeling of pain. Blame the doctors for prescribing it to you if you get addicted.
Modal dialog boxes rarely have a use. System modal dialog boxes are evil.
Apple popularized them and they have recanted their heresy. Modal dialog boxes are active evil. Microsoft once again, is behind the times.
How about making window management not block when a modal dialog is open?
(That's the definition by the way). Modal dialog boxes have always been the work of the devil. It doesn't model the way things work in real life. The phone rings at the same time one of your children starts crying, etc. etc.
I find it fascinating (and probably why I've become so comfortable with Mac OS X, even though the current version has definite stability issues) that Apple learned their lesson on that. The only modal dialog box is the system reboot/shutdown box and there it makes sense.
I first wrote this two decades ago - "a system that cannot do a 100[1] different things at a time is just a toy". It's still true.
Taskbars are a sad joke. When I was doing GUI design back in the mid 80's, I showed a screen with a prototype taskbar to a mentor for review and basically got a NOOOOOOOOOOOO! back. Odd that that ended up capturing mind share. The longer I work with Spaces, the more I agree. Maybe 10.6 will have it better integrated with the system, but even the current implementation beats the pants off the best virtual desktop WM[2] I've ever used.
Now, give me true "focus follows mouse" and I'm your slave forever.
(May I please have the pseudo plain old text style of posting back! That was so much more convenient than this crap).
[1] The traditional default value of NPROC.
[2] Which would be KDE 3.5.