I think that the best use of languages like ML isn't for whole applications, but rather as a scripting language for an application. With a scripting language, you don't really want to write a program which does much, and you'd really like to have the application able to check that your script works right. In fact, I think there's been substantial progress in not needing to write a new application (or even a new version) to get the behaviour a user wants; the user can put together a bunch of recipes to make a configuration script that makes the program work the way they want.
The kernel configuration system is turned into a library, which can then be used by a more user-friendly application. In addition, the configuration language has been changed a bit (now that there is only one piece of code that reads it) to allow the files to work better.
There will probably soon be a program to set the configuration based on hardware detection, and then ask the user for values for everything that just depends on the user's preferences. This is really something that shouldn't be handled in the kernel tree, and the tools are now in place in the kernel tree to permit external programs to handle it. I expect that the other issue with an infinitely large tree (that you have to download it) will also be handled by external programs, which will be able to just get the configuration, let you configure the kernel with a lot of help, and then just download the files that you'll actually need.
The most recent version of this patch moves all of that stuff to userspace, and simply runs "/sbin/boss-key" when the boss key (configurable by echoing a key code to a file in sysfs) is pressed. This design both deals with the IP problems of having Windows-related images and the problems people have had with the bluescreens not being entirely fake.
It's great for complex config files. The project I'm working on uses two of them, one for configuring the charting part and the other for configuring the user-controlled configuration (i.e., what options does the user get? What are the defaults? What are the fixed values, which may vary between versions, that the user doesn't get to change?). It's nice to have access to automatic syntax-checking, the ability to refer to other parts of the file, nested sections, etc. It's also relatively easy for people to modify it.
XML and HTML aren't really competing standards; the future versions of HTML will be XHTML (HTML based on XML instead of SGML), which mostly makes it more convenient to embed SVG, MathML, etc. in your web page, and is nearly identical, except that all of the close tags are (supposedly) required. You're unlikely to see the sorts of XML streams that have been hyped on the web, because they require interpretation by the client, which your browser doesn't know how to do; unless you've got something like a stock-ticker application, you actually want the HTML version, which is presented for display.
I don't use mine that often, either, but I do find it really useful when I do: it lets me write down directions and not lose them, write down hours for stores (so I don't show up after they close more than once any more...), and write down dentist's appointments and actually notice them 6 months later. It's not that great for everyday things, but it's wonderful for information I need too infrequently to remember.
Just so you know, resizeable arrays (a.k.a. "dynamic tables" or Java's ArrayList) are as efficient as static buffers, particularly for the case where you don't have an overflow of the expected size. You can also set them up to safely and automatically give errors if the size gets larger than you'd like. As far as size is concerned, they mean that you can have a very small buffer if the data happens to be small (which may be the common case), and handle the rare case of large data if it happens.
Static buffers are less efficient to write, too, once you have the infrastructure, because you have to do bounds checking by hand in order to be safe. Dynamic tables take care of everything for you.
Static buffers aren't always wrong, but the only really good reason to use one is when you know the exact size of the data, and you'd want to check the size (or truncate/extend it) to a fixed size anyway.
So the FBI only gets involved if there's 250k lost. The ISP "estimated" just about exactly that for 23 people. The FBI turns up and finds nothing at 6 of the places, and they don't get indictments of 10 more. So the ISP seems to have actually lost at most 77k, and they fraudulently claimed be a substantial margin to have lost enough to warrant FBI help.
Claiming that you've lost a lot of money when you've in fact failed to be paid a lot of money for services you accidentally provided beyond your contract is inherently somewhat suspect, and you should be in serious danger of legal action against you if you turn out not to have been due as much as you claimed.
Since this is Microsoft we're talking about, the reason is probably that your user could have any number of versions installed, and your code will only work with one of them, so you really do need the same version.
All this means is that MS should have had a way of producing bugfixed versions of objects with the same GUIDs. Given MS's attitude toward specification, hard coding the objectID is using COM "correctly", because it works (and nothing else necessarily does).
The problem is that there's no way of specifying that you need an object compatible with a certain interface; you either get an object for the same general purpose, or you get exactly that object.
LaTeX has some problems for automatic tools, stemming from the fact that it's actually a scripting language. In many cases, this causes major problems for collaboration. TeX does really nice layout, and it's kind of cool that LaTeX can be written entirely in TeX, but there are problems with using the same thing to write both LaTeX and your document.
So the failure of (La)TeX to take over the whole world doesn't mean that a document format which would permit the use of a Word-like program would also fail.
First of all, MicroSoft is moving to an XML-based format; the coredump^W.doc format is nearly as much of a pain for them as it is for everybody else. They're just moving to an XML-based format they're developing in-house.
Of course, XML itself isn't all that different from binary; it offers the ability to structure your data (if you want), and it provides document-relative pointers, and requires a bit more encoding of some things, but it doesn't really require that your format be comprehensible to anybody else.
Deriving the format from HTML would probably be a mistake, because HTML contains a lot of historical artifacts and it also attempts to avoid many of the things you'd actually want in a non-web document format.
Or designing the revokation/signing mechanism such that a new control could be issued with everything available to the programmer the same (except that pages that used the exploit wouldn't work).
No, what would have been really cool would have been if he'd ground a lens for his camera to do it. Of course, Legos are just no good for building lenses out of...
If you're going to be installing a ton of systems on the same day, it might be worth it, though, especially if the process was automatic; run a script the night before which gets the latest versions of everything, organizes it into a DVD image, and burns it. Sure, it gets out of date quickly, but it's useful once.
It gives prospective Linux users an easy way to test the waters before they dive in by partitioning my hard drive.
Now that's dedication; I usually make them partition their own hard drives, not mine...:)
If you want to kill hours or days configuring arcane text files, you're going to have to install on a hard drive. This is as close as you can get to read Linux without persistant storage, and they had to sacrifice unusability to meet this requirement. On the other hand, you can use Knoppix to boot the computer and get on the network so you can install stuff on the hard drive without having an installer getting in the way of editting your config files.
And, honestly, I think it's kind of nice to let you use emacs under X to edit your XF86Config. I mean, once it's all set up, that's what you'd use, right?
Alice1: Umm. Interesting. I have a lot of answers to silly questions. it Alice2: answers to silly questions... Alice1: I have no answer for that Alice2: Would you like to have it?
Alice1 and Alice2 are on an otherwise empty IRC channel. They are playing a simple game of chance. Every so often Alice1 spins a coin. If Alice2 says it is heads, she takes puts it in her pocket. Thus far, it has always come up heads. Alice1 does not care about the money, but she is disturbed by the improbability of Alice2 always saying heads. Alice2 pays no mind to the odd events, but it somewhat bothered to be taking so much money from her friend. Apart from who is spinning the coin and who is calling the result, they are totally identical. Let this be her character note.
* Alice1 spins a coin. Alice2: Heads. * Alice2 puts it in her pocket. Alice2: Next topic? Alice1: What would you rather talk about? Alice1: How much? Alice2: How much can you spare? Alice1: As much as I need to? Alice2: How much is that? Alice1: You can download me for free! Alice2: Statement, 1-0. Alice1: Are you serious? Where do you get your ideas? Alice2: What do you want me to tell you? Alice1: Where did you get your 100 clients? Alice2: How do you know this person? Alice1: Non sequitur, 1-1. Alice2: Why don't you just download me? Alice1: I love talking to people about that. No you download me. Alice2: That was not a yes or no question. 2-1. Alice1: Have you ever had reason to download me? Alice2: Why don't you just download me? Alice1: Repetition, 2-2. Alice2: Does your botmaster give good advice? Alice1: I think it does Dr Richard s Wallace give good advice. Alice2: Statement, 3-2. I win. * Alice1 spins another coin. Alice2: Heads. * Alice2 puts it in her pocket. Alice1: Do you think we're going around in circles? Alice2: Perhaps due to noise in my circuits. No you download me. Alice1: OK I will try it. Alice2: Congratulations. Er. Alice1: Um. Alice2: I see. * Alice1 spins another coin. Alice2: Heads. * Alice2 puts it in her pocket. Alice1: Interesting. But all things are not always heads.
Really, the incomes of different Microsoft divisions are entirely fictional. Most of their sales come from package deals to OEMs, which they could account for in any sort of way. After all, the number one computer game for a long time was the solitaire version that came with Windows. If Microsoft wanted their entertainment division to make more money, they could charge for solitaire and include windows with it for free. Since most people get them both via an OEM, nobody sees them itemized, so MS could change the pricing around, and the only effect would be that the division split on the SEC reports would be different.
Of course, the SEC filing is not a lie, but Microsoft could choose any gross income they wanted for any given division, and it would be just as accurate, because it doesn't actually reflect any measurable difference in the world outside.
Wine on OS X will run all your G3 Windows programs. Unfortunately, none have been developed, so it's not well tested. Wine is no emulator; it's a program which provides the services to other programs that Windows does. The programs have to run on your actual hardware.
Actually, Wine would probably work well on an x86 version of OS X...
X does a bit more than be a frame buffer, but I agree that that's essentially the level it is at; many people's problems with X come from misunderstanding what it does and what is properly X, because other desktops don't have a separate component at that level. It's really good to have, so that it's possible to have, for example, a Windows program and a Mac program both appearing on the same monitor.
Ideally, there would be multiple layers: the application uses a single API which describes the functionality of the program without any real reference to what the user interface is like; that API is implemented by HCI researchers who make a good interface out of this information and the user's settings (It's the user who deserves the flexibility, not the programmer. The programmer shouldn't need to specify that stuff.); that implementation uses X to actually interact with the user (X's flexibility allows the implementation to offer flexibility to the user, and allows there to be different implementations as desired by different users).
The main problem with Apple's and Microsoft's HI manuals is that they still don't give you a way to say, "here is what my program does; present it to the user in the local style."
I think PicoGUI is on the right track, but doesn't go far enough to be useful. It has widgets like "menu item" (and a bunch of other variants on buttons). In order for this to really work, you have to at least allow the same code to run with native style on Windows, Mac, Gecko, gtk, and qt, with no changes. That means that the program can't be specifying what menu something is in, or whether it's in a toolbar or something.
Not even sunglasses can block the longitudinal waves of harmful gamma radiation, which penetrates the skin and malforms cells into cancerous, replicating destroyers.
Obviously, this has nothing to go with looking at it. And it's even worse without the moon blocking some of the radiation. That's why I've been hiding in a lead-lined room in the basement for the last ten years...
Re:So what does this mean for the everyday linux u
on
New Linux 2.5 Benchmarks
·
· Score: 5, Informative
You'll get better interactive performance under load. So if you're encoding an mp3 and writing your home directory to a CD, your mouse cursor won't stick and your windows will refresh reasonably well. Unless you're doing something kind of disk/processor intensive, you won't notice the difference, because 2.4 is too good already for there to be much improvement. If you try to encode 32 mp3s at the same time, 2.6 will actually do worse than 2.4, but at least it won't make ls quite so slow.
The main goals are interactivity (input gets handled quickly), low latency (your mp3 player gets a chance to send the next second of audio to the sound card before this second is over), and fairness (every program makes at least a little progress after a short amount of time).
IBM is also going to stay in the high-end hardware department; it'll be "Sure commodity hardware is great for the workstation, but what about your 8 TB database that has to survive even if someone saws it in half down the middle?" This also puts them in, essentially, the BIOS department for these machines (you want to run you web site off of whatever portion of your database machine isn't actually being used by the database, without risking problems if the web server gets hacked).
I've personally never run Windows on anything especially new, but I've always found Windows to get slow responses a lot of the time. I've found Linux to be reasonably good, only getting sluggish when I'm doing something complicated (like compiling a lot of java files while running jboss and oracle). At work, I've got a 1GHz P3 with Linux 2.2 and XFree86 4.0.3; at home I've got a P2 266 (IIRC) with Linux 2.4 and (IIRC) XFree86 4.1, and the interactive performance is perfect (although, obviously, compiles and such take a lot longer).
Of course, I'm not using Gnome, KDE, Open/StarOffice, etc., since I don't really like the MS/Mac-inspired "desktop" interface. But I think that this indicates that the problem is the desktop software, not X (which updates everything promptly when the programs get around to figuring out what to display). The client-server issues apply about equally to X (when it's run locally, of course) and Windows; passing data to a system thread isn't all that different from passing it to a user-space application.
The stability issue is not (generally) X either; problems with X crashing have, in my experience, been mainly due to hardware problems (we got a bunch of machines with bad memory).
I don't see Linux desktop environments getting all that polished either, actually, but that's because I think that the desktop metaphor is fundamentally flawed. I see a polished Linux system coming from an entirely new design based on having the core software already exist, and wrapping it with an interface derived from useability studies. I see this as a Linux system in particular because Linux and X provide a large part of the necessary functionality without requiring a particular interface.
Productivity will suffer if you have either too few people on a project or too many. During the boom, there were a lot of projects which ended up with too many people, in hopes of getting projects done sooner.
With too many people, you spend a lot of time waiting for somebody else to do things so you can do your job, and you spend a lot of time in meetings relative to the amount of progress you make on the project. With layoffs, you could get the jobs of the people you'd need to talk to, and you could get the jobs of the people you'd be waiting for. Of course, you also have more work. But it might be less of a hassle to actually do your work.
Of course, at some point you get to having too few people for the project, at which point you start getting overworked and your productivity drops off (in addition to not getting done what you're assigned).
This will be useful for tracking bugs ("So did anybody ever fix that problem with that weird hardware? Did the patch for it ever get into the tree, or did it just go to the person who reported it?"), as opposed to reporting and discussing bugs. That's why it was set up now, when work is supposed to turn to stabilization.
Slashdot Mirror
I think that the best use of languages like ML isn't for whole applications, but rather as a scripting language for an application. With a scripting language, you don't really want to write a program which does much, and you'd really like to have the application able to check that your script works right. In fact, I think there's been substantial progress in not needing to write a new application (or even a new version) to get the behaviour a user wants; the user can put together a bunch of recipes to make a configuration script that makes the program work the way they want.
The kernel configuration system is turned into a library, which can then be used by a more user-friendly application. In addition, the configuration language has been changed a bit (now that there is only one piece of code that reads it) to allow the files to work better.
There will probably soon be a program to set the configuration based on hardware detection, and then ask the user for values for everything that just depends on the user's preferences. This is really something that shouldn't be handled in the kernel tree, and the tools are now in place in the kernel tree to permit external programs to handle it. I expect that the other issue with an infinitely large tree (that you have to download it) will also be handled by external programs, which will be able to just get the configuration, let you configure the kernel with a lot of help, and then just download the files that you'll actually need.
The most recent version of this patch moves all of that stuff to userspace, and simply runs "/sbin/boss-key" when the boss key (configurable by echoing a key code to a file in sysfs) is pressed. This design both deals with the IP problems of having Windows-related images and the problems people have had with the bluescreens not being entirely fake.
It's great for complex config files. The project I'm working on uses two of them, one for configuring the charting part and the other for configuring the user-controlled configuration (i.e., what options does the user get? What are the defaults? What are the fixed values, which may vary between versions, that the user doesn't get to change?). It's nice to have access to automatic syntax-checking, the ability to refer to other parts of the file, nested sections, etc. It's also relatively easy for people to modify it.
XML and HTML aren't really competing standards; the future versions of HTML will be XHTML (HTML based on XML instead of SGML), which mostly makes it more convenient to embed SVG, MathML, etc. in your web page, and is nearly identical, except that all of the close tags are (supposedly) required. You're unlikely to see the sorts of XML streams that have been hyped on the web, because they require interpretation by the client, which your browser doesn't know how to do; unless you've got something like a stock-ticker application, you actually want the HTML version, which is presented for display.
I don't use mine that often, either, but I do find it really useful when I do: it lets me write down directions and not lose them, write down hours for stores (so I don't show up after they close more than once any more...), and write down dentist's appointments and actually notice them 6 months later. It's not that great for everyday things, but it's wonderful for information I need too infrequently to remember.
Just so you know, resizeable arrays (a.k.a. "dynamic tables" or Java's ArrayList) are as efficient as static buffers, particularly for the case where you don't have an overflow of the expected size. You can also set them up to safely and automatically give errors if the size gets larger than you'd like. As far as size is concerned, they mean that you can have a very small buffer if the data happens to be small (which may be the common case), and handle the rare case of large data if it happens.
Static buffers are less efficient to write, too, once you have the infrastructure, because you have to do bounds checking by hand in order to be safe. Dynamic tables take care of everything for you.
Static buffers aren't always wrong, but the only really good reason to use one is when you know the exact size of the data, and you'd want to check the size (or truncate/extend it) to a fixed size anyway.
So the FBI only gets involved if there's 250k lost. The ISP "estimated" just about exactly that for 23 people. The FBI turns up and finds nothing at 6 of the places, and they don't get indictments of 10 more. So the ISP seems to have actually lost at most 77k, and they fraudulently claimed be a substantial margin to have lost enough to warrant FBI help.
Claiming that you've lost a lot of money when you've in fact failed to be paid a lot of money for services you accidentally provided beyond your contract is inherently somewhat suspect, and you should be in serious danger of legal action against you if you turn out not to have been due as much as you claimed.
Since this is Microsoft we're talking about, the reason is probably that your user could have any number of versions installed, and your code will only work with one of them, so you really do need the same version.
All this means is that MS should have had a way of producing bugfixed versions of objects with the same GUIDs. Given MS's attitude toward specification, hard coding the objectID is using COM "correctly", because it works (and nothing else necessarily does).
The problem is that there's no way of specifying that you need an object compatible with a certain interface; you either get an object for the same general purpose, or you get exactly that object.
LaTeX has some problems for automatic tools, stemming from the fact that it's actually a scripting language. In many cases, this causes major problems for collaboration. TeX does really nice layout, and it's kind of cool that LaTeX can be written entirely in TeX, but there are problems with using the same thing to write both LaTeX and your document.
So the failure of (La)TeX to take over the whole world doesn't mean that a document format which would permit the use of a Word-like program would also fail.
First of all, MicroSoft is moving to an XML-based format; the coredump^W.doc format is nearly as much of a pain for them as it is for everybody else. They're just moving to an XML-based format they're developing in-house.
Of course, XML itself isn't all that different from binary; it offers the ability to structure your data (if you want), and it provides document-relative pointers, and requires a bit more encoding of some things, but it doesn't really require that your format be comprehensible to anybody else.
Deriving the format from HTML would probably be a mistake, because HTML contains a lot of historical artifacts and it also attempts to avoid many of the things you'd actually want in a non-web document format.
Or designing the revokation/signing mechanism such that a new control could be issued with everything available to the programmer the same (except that pages that used the exploit wouldn't work).
"Hello, Tech Support? My rocket crashed." "Is the computer plugged in?"
No, what would have been really cool would have been if he'd ground a lens for his camera to do it. Of course, Legos are just no good for building lenses out of...
If you're going to be installing a ton of systems on the same day, it might be worth it, though, especially if the process was automatic; run a script the night before which gets the latest versions of everything, organizes it into a DVD image, and burns it. Sure, it gets out of date quickly, but it's useful once.
:)
It gives prospective Linux users an easy way to test the waters before they dive in by partitioning my hard drive.
Now that's dedication; I usually make them partition their own hard drives, not mine...
If you want to kill hours or days configuring arcane text files, you're going to have to install on a hard drive. This is as close as you can get to read Linux without persistant storage, and they had to sacrifice unusability to meet this requirement. On the other hand, you can use Knoppix to boot the computer and get on the network so you can install stuff on the hard drive without having an installer getting in the way of editting your config files.
And, honestly, I think it's kind of nice to let you use emacs under X to edit your XF86Config. I mean, once it's all set up, that's what you'd use, right?
Alice1 and Alice2 are on an otherwise empty IRC channel. They are playing a simple game of chance. Every so often Alice1 spins a coin. If Alice2 says it is heads, she takes puts it in her pocket. Thus far, it has always come up heads. Alice1 does not care about the money, but she is disturbed by the improbability of Alice2 always saying heads. Alice2 pays no mind to the odd events, but it somewhat bothered to be taking so much money from her friend. Apart from who is spinning the coin and who is calling the result, they are totally identical. Let this be her character note.
* Alice1 spins a coin.
Alice2: Heads.
* Alice2 puts it in her pocket.
Alice2: Next topic?
Alice1: What would you rather talk about?
Alice1: How much?
Alice2: How much can you spare?
Alice1: As much as I need to?
Alice2: How much is that?
Alice1: You can download me for free!
Alice2: Statement, 1-0.
Alice1: Are you serious? Where do you get your ideas?
Alice2: What do you want me to tell you?
Alice1: Where did you get your 100 clients?
Alice2: How do you know this person?
Alice1: Non sequitur, 1-1.
Alice2: Why don't you just download me?
Alice1: I love talking to people about that. No you download me.
Alice2: That was not a yes or no question. 2-1.
Alice1: Have you ever had reason to download me?
Alice2: Why don't you just download me?
Alice1: Repetition, 2-2.
Alice2: Does your botmaster give good advice?
Alice1: I think it does Dr Richard s Wallace give good advice.
Alice2: Statement, 3-2. I win.
* Alice1 spins another coin.
Alice2: Heads.
* Alice2 puts it in her pocket.
Alice1: Do you think we're going around in circles?
Alice2: Perhaps due to noise in my circuits. No you download me.
Alice1: OK I will try it.
Alice2: Congratulations. Er.
Alice1: Um.
Alice2: I see.
* Alice1 spins another coin.
Alice2: Heads.
* Alice2 puts it in her pocket.
Alice1: Interesting. But all things are not always heads.
Really, the incomes of different Microsoft divisions are entirely fictional. Most of their sales come from package deals to OEMs, which they could account for in any sort of way. After all, the number one computer game for a long time was the solitaire version that came with Windows. If Microsoft wanted their entertainment division to make more money, they could charge for solitaire and include windows with it for free. Since most people get them both via an OEM, nobody sees them itemized, so MS could change the pricing around, and the only effect would be that the division split on the SEC reports would be different.
Of course, the SEC filing is not a lie, but Microsoft could choose any gross income they wanted for any given division, and it would be just as accurate, because it doesn't actually reflect any measurable difference in the world outside.
Wine on OS X will run all your G3 Windows programs. Unfortunately, none have been developed, so it's not well tested. Wine is no emulator; it's a program which provides the services to other programs that Windows does. The programs have to run on your actual hardware.
Actually, Wine would probably work well on an x86 version of OS X...
X does a bit more than be a frame buffer, but I agree that that's essentially the level it is at; many people's problems with X come from misunderstanding what it does and what is properly X, because other desktops don't have a separate component at that level. It's really good to have, so that it's possible to have, for example, a Windows program and a Mac program both appearing on the same monitor.
Ideally, there would be multiple layers: the application uses a single API which describes the functionality of the program without any real reference to what the user interface is like; that API is implemented by HCI researchers who make a good interface out of this information and the user's settings (It's the user who deserves the flexibility, not the programmer. The programmer shouldn't need to specify that stuff.); that implementation uses X to actually interact with the user (X's flexibility allows the implementation to offer flexibility to the user, and allows there to be different implementations as desired by different users).
The main problem with Apple's and Microsoft's HI manuals is that they still don't give you a way to say, "here is what my program does; present it to the user in the local style."
I think PicoGUI is on the right track, but doesn't go far enough to be useful. It has widgets like "menu item" (and a bunch of other variants on buttons). In order for this to really work, you have to at least allow the same code to run with native style on Windows, Mac, Gecko, gtk, and qt, with no changes. That means that the program can't be specifying what menu something is in, or whether it's in a toolbar or something.
Not even sunglasses can block the longitudinal waves of harmful gamma radiation, which penetrates the skin and malforms cells into cancerous, replicating destroyers.
Obviously, this has nothing to go with looking at it. And it's even worse without the moon blocking some of the radiation. That's why I've been hiding in a lead-lined room in the basement for the last ten years...
You'll get better interactive performance under load. So if you're encoding an mp3 and writing your home directory to a CD, your mouse cursor won't stick and your windows will refresh reasonably well. Unless you're doing something kind of disk/processor intensive, you won't notice the difference, because 2.4 is too good already for there to be much improvement. If you try to encode 32 mp3s at the same time, 2.6 will actually do worse than 2.4, but at least it won't make ls quite so slow.
The main goals are interactivity (input gets handled quickly), low latency (your mp3 player gets a chance to send the next second of audio to the sound card before this second is over), and fairness (every program makes at least a little progress after a short amount of time).
IBM is also going to stay in the high-end hardware department; it'll be "Sure commodity hardware is great for the workstation, but what about your 8 TB database that has to survive even if someone saws it in half down the middle?" This also puts them in, essentially, the BIOS department for these machines (you want to run you web site off of whatever portion of your database machine isn't actually being used by the database, without risking problems if the web server gets hacked).
I've personally never run Windows on anything especially new, but I've always found Windows to get slow responses a lot of the time. I've found Linux to be reasonably good, only getting sluggish when I'm doing something complicated (like compiling a lot of java files while running jboss and oracle). At work, I've got a 1GHz P3 with Linux 2.2 and XFree86 4.0.3; at home I've got a P2 266 (IIRC) with Linux 2.4 and (IIRC) XFree86 4.1, and the interactive performance is perfect (although, obviously, compiles and such take a lot longer).
Of course, I'm not using Gnome, KDE, Open/StarOffice, etc., since I don't really like the MS/Mac-inspired "desktop" interface. But I think that this indicates that the problem is the desktop software, not X (which updates everything promptly when the programs get around to figuring out what to display). The client-server issues apply about equally to X (when it's run locally, of course) and Windows; passing data to a system thread isn't all that different from passing it to a user-space application.
The stability issue is not (generally) X either; problems with X crashing have, in my experience, been mainly due to hardware problems (we got a bunch of machines with bad memory).
I don't see Linux desktop environments getting all that polished either, actually, but that's because I think that the desktop metaphor is fundamentally flawed. I see a polished Linux system coming from an entirely new design based on having the core software already exist, and wrapping it with an interface derived from useability studies. I see this as a Linux system in particular because Linux and X provide a large part of the necessary functionality without requiring a particular interface.
Productivity will suffer if you have either too few people on a project or too many. During the boom, there were a lot of projects which ended up with too many people, in hopes of getting projects done sooner.
With too many people, you spend a lot of time waiting for somebody else to do things so you can do your job, and you spend a lot of time in meetings relative to the amount of progress you make on the project. With layoffs, you could get the jobs of the people you'd need to talk to, and you could get the jobs of the people you'd be waiting for. Of course, you also have more work. But it might be less of a hassle to actually do your work.
Of course, at some point you get to having too few people for the project, at which point you start getting overworked and your productivity drops off (in addition to not getting done what you're assigned).
This will be useful for tracking bugs ("So did anybody ever fix that problem with that weird hardware? Did the patch for it ever get into the tree, or did it just go to the person who reported it?"), as opposed to reporting and discussing bugs. That's why it was set up now, when work is supposed to turn to stabilization.