I've been checking ICC out for awhile (both on Linux and on Windows) and its a dream to use. Its quite fast, generates nice code (20% or so faster than GCC on most things I've tried with it, like ByteMark) and has really, really nice error messages. It isn't as complient with C++ as GCC 3.0, but its really good nonetheless, its just missing some of the eosteric parts of the standard.
Well, 4 clock cycles are required to load a long register,
>>>>>>
I was assuming the code and data were cached.
with the address, 4 are required to perform a long jump
>>>>>
On what proc?
which leaves you with 2 clock cycles to:
Determine if the address is even in memory at the time
>>>>>
Done automatically by MMU during the memory access to get the code. Also, only happens if the instruction pointer crosses misses the TLB.
Load the information from swap, if it isn't
>>>>
Well, swap kills performance on any system. Why do you think KDE and GNOME require so much RAM?
Preserve the state of the calling function
>>>>
There's the bulk of the few clocks. Assuming the write is cached, its a piddly amount of data on x86 procs.
Swap out information as needed, in the event of the called function being swaped in
>>>>>
Again, swap isn't a factor here, since the code is assumed to be in RAM. Swapping will kill even the best code.
Something tells me that your model isn't, umm, 100% complete?
>>>>
Something tells me you should read up on the GCC function calling convention.
Then, we get to the library bit. Yes, much of the GNOME stuff is in libraries. But X is an event-driven model, not a sequential model. Thus, you have multiple threads going through your program, not just one.
>>>>>
I'm going to love the explanation for this one. What exactly are you talking about? You've got event driven, threading, and libraries all messed up. First, events are queued, so the cost of doing a context switch to deliver them is mitigated over several events. Second, threads have nothing to do with event handling. X isn't multithreaded, and neither GNOME nor KDE use threads. GTK+ and Qt aren't even fully thread-safe!
Now, for the lookup bit. Yes, I know about binary trees. Actually, the "correct" implementation would use an n-ary tree, for much faster lookups. Binary trees simply take log2(N) to search. Which seems fine, until you realise just how many damn things X considers an event!
>>>>>
Umm, methinks you're mistaken. If you were doing a lookup to deliver an event, you'd lookup the process ID to deliver the event to, not the ID of the event. (The ID would be even easier. Only 255 X events, you could use an array).
Then, you've got a secondary problem - sending an event to more than one application. It's certainly possible, which means that your check system can't just search the tree for the first hit, it has to search the tree for EVERY hit.
>>>>>>>>
Sending the same event to multiple apps should be rare. X events aren't a general communications protocol. Also, multicasting is rare for any messeging system.
Let's now look at that line-drawing example. 1000 lines get drawn, all get buffered, until there's a sync. Hmmm. That's true, but not typically how it's done.
>>>>
Except that IS how its done. BeOS's app_server does it. QNX's Photon does it. X probably does it too (I would hope so!)
To have smooth graphics, you need to have near-fixed intervals between updates, so you can't just hang around until some coder decides to sync things up. The usual way of coding is to double-buffer and do small amounts of updating at any given time interval.
>>>>>
First, the system can wait for either a number of drawing events, or sync, which ever comes first. Second, while you are right that there must be fixed-intervals, you have to realize that the intervals are REALLY long. The human eye cannot detect changes faster than 60Hz. That's about 16-17 milliseconds per frame, which is an awefully long time. Thus, the graphics server can afford to wait for a large buffer of drawing events and draw them together. Double buffering does something similar. You buffer all the changes to the framebuffer together, and you display them all at once 60 times per second (really slowly for a computer!)
Speed: Won't be a problem in a year or two with faster hardware and 10.1 is already a big improvement.
>>>>>>
A lot of people happen to think that the OS has no business demanding so much system resources. People don't run OSs, they run applications. While I can understand a 3D moderling taking a 128MB machine, I can't understand a desktop environment doing the same. The OS should just get the hell out of the way and leave all of the resources to the apps. MacOS-X is a great example. They use an absolutely brain-dead model for their OS. The pile a monolithic server on a microkernel. Not only does that add bloat, but it takes the disadvantages of a microkernel (speed), and the disadvantages of a macrokernel (vulnerability to bugs in OS) and puts them together.
First, its really not a problem. Business desktops usually use Office very extensively, and something that makes it start faster isn't bad, its good. Also, I never keep stuff in my startup dir, and Office starts almost instantly on my system (about as fast as Konq on KDE 2.2.1).
Visual C++ compile speed is really, really fast. Also, GCC doesn't support precompiled headers, and tries to be correct rather than fast WRT templates. So its quite plausiple that VC++ is that much faster.
Of course, a lot (actually a majority) of the Linux kernel is drivers. A lot of drivers look very similar (cut & paste), so a straight linecount probably isn't the best measurement.
Let's say you have N active processes that are using X. Then, for every event, you must search a table of at least N entries to see which process that event is to go to.
>>>>>>>
Only if the developers are monkeys. Say you have a keypress event. The event automatically goes to the frontmost window, which is O(1). Say you have a timer event. If you keep the timer list sorted (which is pretty easy, its called a binary tree), then the lookup is quite cheap. Rarely should X have to use an O(n) algorithm, unless you want to visit every process anyway.
Then, you have the problem of when one (or more) of those active processes themselves generates an X event. X must then pull that event into its event handler and farm it out appropriately.
>>>>
Again, quite cheap. Say you want to send a message to another app. The destination is embedded in the message, so delivery is again O(1) (not counting copying of the message data!)
Since a microprocessor can only deal with one thing at a time, what you have is the following:
* Process fires event
* X receives event
* X directs event
* Process receives event
Not too bad, you might think. But each of these requires a context switch, and those aren't cheap.
>>>>>>>
Actually, events are buffered. So for every few dozen of these transactions, there are only two context switches. Say a process draws a thousand lines. Each one doesn't get sent to X. Instead, they all get put in a buffer, and when the app asks for sync, the buffer is sent to X as one big transaction. (I don't know if X specifically does it this way, but most window servers do).
Now, when you start throwing in GNOME stuff, it gets worse, as you have to bury your way through Gnome's libraries, the lower-level libraries, gtk/glib to Xlib, or vice versa. Again, each of these requires a context switch.
>>>>>>>
Except it doesn't. Library calls are just indirect function calls, and they are quite cheap. On a PII, an indirect function call takes less than 10 clock cycles.
(One context switch = dump current state of current process; load in new process; set up registers for correct state)
>>>>>>>>
Fortunately, context switches only happen a few hundred times per second (very rarely, by processor standards).
Since, in a logical sense, there is no real difference between GNOME and X, context-wise, all those extra context switches are simply wasted computer resources.
>>>>>>>
Except that GNOME is a library and X is a seperate process!
Actually what you're thinking of is already here: E17. A hardware accelerated desktop. Runs fast, looks pretty. Mostly only the graphics routines need acceleration, since the other stuff doesn't take much processing. (If it does, you're using bad algorithms, and bad algorithms suck software or hardware rendered!) I only wish all apps could some how take advantage of E17's features. Raster should really think about maybe forking GNOME or something to create a E17 DE.
So does QNX. Yea, it is bad that Be died. What really would have been cool would have been a mixture of the Linux kernel (which has gotten pretty nice these days) and the BeOS GUI. BeOS has problems with VM and networking, Linux has problems with GUI. A match made in heaven. Well, here's hoping that QNX open sources Photon...
Usually I do (like I said!) but there is no difference between Mandrake's settings and mine in terms of performance. If I'm that obsessed about performance, don't you think I'd check? Besides, its all a moot point anyhow. The problem got much better as soon as I applied the preempt patches, and I hadn't changed any other config options.
I'm (not the original poster) using AA in Linux right now, and it looks great. I nuked the crappy Linux distro (X, urw, Abiword, Mandrake, etc) fonts that came installed and copied over the.ttfs from my WIndows partition. Edited my XftCache, and voila, awesome!
However, the significant performance degradation in any feature from one version of Windows to the next is a pretty damning result. It would seem to legitimize the feeling that many Windows users have that XP is a big downgrade from 2K.
>>>>>
Not necessarily. OS design consists of lots of tradeoffs. If one feature isn't used often, it is quite possible that its performance would be sacrified to make something else faster.
1) You have you no idea what you're talking about.
>>>>>>>
Care to elaborate?
2) You run mandrake and think that it is doing the appropriate thing with your computer.
>>>>>>>>
First, I run Mandrake because it is a reasonable compromise distro. I have used Slack (since 3.5), RedHat, SuSE, and Gentoo for awhile. I like Gentoo best, but can't stand having to compile all my apps myself. Second, I saw that Mandrake was running HDParm when I looked through the initscripts!
Yes, you need to install both sets of libraries. No, it isn't the end of the world to do so.
>>>>>>>>>
There are two types of people in the world. Those that hate bloat, and GNOME/KDE users...
Seriously, though, there are more problems to loading GTK+ AND Qt than just bloat (which is still a terrible sin IMO). GNOME and KDE apps don't look the same. Some people (like me) just like everything to be nice and homogenous. My desk is perfectly neat and all my pens are in the perfect places. My tabletop has marks on it showing exactly where my speakers should go. Second, the two types of apps don't interoperate that well. In Windows, I'm used to embedding graphics in Word documents that are embedded in spreadsheets. In Linux, it just doesn't work that way (yet).
Overhead will be worthwhile for more flexiblity and power. And when the machines are there, Berlin will not have to be rewritten to take advantage of them.
>>>>>>
Its that idea that makes Linux GUIs suck performance-wise. Power is rarely worth the tradeoff in speed and effieciency, since very little software ever exposes more power. Don't get fooled into equating features with power BTW. Power is being able to quickly do the work you need to do without the system getting in the way. Most of the stuff that these desktop environment developers think is power (network transparency, CORBA, etc) are really just mental masturbation and have little significance on the desktop.
Pipes are what they used before proper IPC methods like messaging were created...
I'm just kidding. Pipes are a mechanism to allow applications to send data to each other. An app at one end can stuff date into the pipe by pretending its writing to a file, and the app at the other end can read the pipe just like a file and get the data out. In Windows, pipes are rarely used. More often, people will use messaging or implement a COM or OLE component.
Why to Linux-types always think I have my software configured wrong? First of all, Mandrake automatically optimizes the hard drive at bootup. Second, the first thing I do when I setup a Linux distro is to optimize it. I get rid of the cruft in XftConfig, delete all the antiquated X fonts (and install nice, pretty Windows truetype fonts in their place), and set X to run at nice -1. The real reason the mouse sticks is two-fold. First, the standard (non-preemptible) Linux kernel can have terrible latencies during heavy disk I/O (look at the latency graphs on kpreempt.sourceforge.net) Second, UNIX scheduling algorithms aren't designed for desktop use and thus use the artificial distinction between CPU-bound and I/O-bound processes to distinguish background an interactive tasks. This works for the most part, but in complex (single-threaded) programs like Konq, which can use lots of CPU time, this is less than ideal. (BTW, BeOS solves this by giving higher priority to threads that are attached to windows, rather than monitoring CPU and I/O usage.)
Doesn't fit in with the "native" feel at all, but is fast and easy to use, because the UI fits the application, rather than having the application shoehorned into some ill-fitting paradigm.
>>>>>>>>>
Intellectual types are so into paradigms its funny. Here are some facts from reality:
1) Developers are lazy. If not forced to standardize UIs, they'll simply make crappy UIs that look different. At least by standardizing the look, you get crappy UIs that look the same.
2) Developers are lazy. If they have some UI guidelines in front of them, then they might be coaxed into using them, and maybe have the hope of making a good UI. If they have no guidelines, they'll not bother to come up with their own, they'll just make a crappy UI. If you don't believe me, take a look at Mac-Land. Most Mac apps look and behave similarly, but the Mac is the home of such great UIs as Adobe's.
3) Developers are lazy. If they are given the freedom to do whatever they want with the UI, they'll go through the path of least resistance, or of personal preferences.
No, I do not mean to *all* characterize developers as lazy (just most). Some of them do work quite hard to come up with good user interfaces and applications by these developers stand out, even when those apps look exactly like all the other apps on the desktop. The fundemental error that most of the "developer UI freedom" people make is that the *look* of the UI has very little to do with its efficiency/ease of use. There are many UIs on Windows (3D Studio MAX, for example, or Maya) that look like standard Windows apps, but have incredible workflow. Take StarOffice or Mozilla, for an opposing example. There is nothing special in their UIs that makes them more functional than Word or IE. They simply *look* different.
First, MS doesn't have as many people as the Pentagon in a single installation. Second, MS is actually pretty open about what software people use for their work.
They comple cross platform and their toolkits make it all look the same cross platforms.
>>>>>>>
That's really brain-dead. People tend to use one platform consistantly, and like it when a particular app looks like the other apps on their system. Eg. no-one cares if a program looks the same on Linux and Windows, as long as all the Linux apps look the same and all the Windows apps look the same.
Please note that Office (any flavor) does not take "scant amounts of ram". Rather, it hides ram used in the system memory used column, and actually preloads many if not most of the Office specific DLL's on boot up, whether you want them or not. The memory that appears to be used by Office, is only the glue code that links the DLL/OLE/NET components together.
The reason that Office appears to launch almost instantanously, is that most of it was already loaded on bootup.
Just a clarification...
>>>>>>>>
Its all a moot point. On my computer (300MHz, 256MB), Office loads faster than KOffice, Office + Win2K uses about the same amount of RAM as KDE-2 + Linux, and Office runs a *lot* faster than KOffice. In KSpread, selecting multiple cells gets annoying because the system has to struggle to keep up with the selected area. In Excel, I can whip the selection area around all I want without the slightest "stickyness." I can resize Word or Excel as fast as I can move my mouse and the toolbars adjust to their new sizes with nary a hiccup. In KOffice (or any KDE app for that matter) I get an ugly rubber-band effect until the stupid widget set can catch up to my pointer. It drives me f**king INSANE!
BTW> While KDE-2 might be trash (speed-wise), has anyone switched to kernel 2.4.10 (with preempt patch)? It is AMAZING. Before, my mouse pointer used to stick whenever the disk was accessed or whenever Mozilla or Konq displayed a page. Now, not even compiling in the background can make it stick. Very, very nice. Props to the guys who worked on the AA patch, and also some kudos to AA for the new VM stuff!
And what is the world's largest installed base of Windows computers?
>>>>>>
Most likely the Pentagon. Its the largest employment site, and almost all desk jobs these days require the use of a PC.
Slashdot Mirror
I've been checking ICC out for awhile (both on Linux and on Windows) and its a dream to use. Its quite fast, generates nice code (20% or so faster than GCC on most things I've tried with it, like ByteMark) and has really, really nice error messages. It isn't as complient with C++ as GCC 3.0, but its really good nonetheless, its just missing some of the eosteric parts of the standard.
Well, 4 clock cycles are required to load a long register,
>>>>>>
I was assuming the code and data were cached.
with the address, 4 are required to perform a long jump
>>>>>
On what proc?
which leaves you with 2 clock cycles to:
Determine if the address is even in memory at the time
>>>>>
Done automatically by MMU during the memory access to get the code. Also, only happens if the instruction pointer crosses misses the TLB.
Load the information from swap, if it isn't
>>>>
Well, swap kills performance on any system. Why do you think KDE and GNOME require so much RAM?
Preserve the state of the calling function
>>>>
There's the bulk of the few clocks. Assuming the write is cached, its a piddly amount of data on x86 procs.
Swap out information as needed, in the event of the called function being swaped in
>>>>>
Again, swap isn't a factor here, since the code is assumed to be in RAM. Swapping will kill even the best code.
Something tells me that your model isn't, umm, 100% complete?
>>>>
Something tells me you should read up on the GCC function calling convention.
Then, we get to the library bit. Yes, much of the GNOME stuff is in libraries. But X is an event-driven model, not a sequential model. Thus, you have multiple threads going through your program, not just one.
>>>>>
I'm going to love the explanation for this one. What exactly are you talking about? You've got event driven, threading, and libraries all messed up. First, events are queued, so the cost of doing a context switch to deliver them is mitigated over several events. Second, threads have nothing to do with event handling. X isn't multithreaded, and neither GNOME nor KDE use threads. GTK+ and Qt aren't even fully thread-safe!
Now, for the lookup bit. Yes, I know about binary trees. Actually, the "correct" implementation would use an n-ary tree, for much faster lookups. Binary trees simply take log2(N) to search. Which seems fine, until you realise just how many damn things X considers an event!
>>>>>
Umm, methinks you're mistaken. If you were doing a lookup to deliver an event, you'd lookup the process ID to deliver the event to, not the ID of the event. (The ID would be even easier. Only 255 X events, you could use an array).
Then, you've got a secondary problem - sending an event to more than one application. It's certainly possible, which means that your check system can't just search the tree for the first hit, it has to search the tree for EVERY hit.
>>>>>>>>
Sending the same event to multiple apps should be rare. X events aren't a general communications protocol. Also, multicasting is rare for any messeging system.
Let's now look at that line-drawing example. 1000 lines get drawn, all get buffered, until there's a sync. Hmmm. That's true, but not typically how it's done.
>>>>
Except that IS how its done. BeOS's app_server does it. QNX's Photon does it. X probably does it too (I would hope so!)
To have smooth graphics, you need to have near-fixed intervals between updates, so you can't just hang around until some coder decides to sync things up. The usual way of coding is to double-buffer and do small amounts of updating at any given time interval.
>>>>>
First, the system can wait for either a number of drawing events, or sync, which ever comes first. Second, while you are right that there must be fixed-intervals, you have to realize that the intervals are REALLY long. The human eye cannot detect changes faster than 60Hz. That's about 16-17 milliseconds per frame, which is an awefully long time. Thus, the graphics server can afford to wait for a large buffer of drawing events and draw them together. Double buffering does something similar. You buffer all the changes to the framebuffer together, and you display them all at once 60 times per second (really slowly for a computer!)
Speed: Won't be a problem in a year or two with faster hardware and 10.1 is already a big improvement.
>>>>>>
A lot of people happen to think that the OS has no business demanding so much system resources. People don't run OSs, they run applications. While I can understand a 3D moderling taking a 128MB machine, I can't understand a desktop environment doing the same. The OS should just get the hell out of the way and leave all of the resources to the apps. MacOS-X is a great example. They use an absolutely brain-dead model for their OS. The pile a monolithic server on a microkernel. Not only does that add bloat, but it takes the disadvantages of a microkernel (speed), and the disadvantages of a macrokernel (vulnerability to bugs in OS) and puts them together.
Closer to 70%. While the Windows TT fonts made a huge difference, I can still see aliasing. AA makes it look a little nicer.
First, its really not a problem. Business desktops usually use Office very extensively, and something that makes it start faster isn't bad, its good. Also, I never keep stuff in my startup dir, and Office starts almost instantly on my system (about as fast as Konq on KDE 2.2.1).
Visual C++ compile speed is really, really fast. Also, GCC doesn't support precompiled headers, and tries to be correct rather than fast WRT templates. So its quite plausiple that VC++ is that much faster.
Of course, a lot (actually a majority) of the Linux kernel is drivers. A lot of drivers look very similar (cut & paste), so a straight linecount probably isn't the best measurement.
Please learn how a computer works...
Let's say you have N active processes that are using X. Then, for every event, you must search a table of at least N entries to see which process that event is to go to.
>>>>>>>
Only if the developers are monkeys. Say you have a keypress event. The event automatically goes to the frontmost window, which is O(1). Say you have a timer event. If you keep the timer list sorted (which is pretty easy, its called a binary tree), then the lookup is quite cheap. Rarely should X have to use an O(n) algorithm, unless you want to visit every process anyway.
Then, you have the problem of when one (or more) of those active processes themselves generates an X event. X must then pull that event into its event handler and farm it out appropriately.
>>>>
Again, quite cheap. Say you want to send a message to another app. The destination is embedded in the message, so delivery is again O(1) (not counting copying of the message data!)
Since a microprocessor can only deal with one thing at a time, what you have is the following:
* Process fires event
* X receives event
* X directs event
* Process receives event
Not too bad, you might think. But each of these requires a context switch, and those aren't cheap.
>>>>>>>
Actually, events are buffered. So for every few dozen of these transactions, there are only two context switches. Say a process draws a thousand lines. Each one doesn't get sent to X. Instead, they all get put in a buffer, and when the app asks for sync, the buffer is sent to X as one big transaction. (I don't know if X specifically does it this way, but most window servers do).
Now, when you start throwing in GNOME stuff, it gets worse, as you have to bury your way through Gnome's libraries, the lower-level libraries, gtk/glib to Xlib, or vice versa. Again, each of these requires a context switch.
>>>>>>>
Except it doesn't. Library calls are just indirect function calls, and they are quite cheap. On a PII, an indirect function call takes less than 10 clock cycles.
(One context switch = dump current state of current process; load in new process; set up registers for correct state)
>>>>>>>>
Fortunately, context switches only happen a few hundred times per second (very rarely, by processor standards).
Since, in a logical sense, there is no real difference between GNOME and X, context-wise, all those extra context switches are simply wasted computer resources.
>>>>>>>
Except that GNOME is a library and X is a seperate process!
Actually what you're thinking of is already here: E17. A hardware accelerated desktop. Runs fast, looks pretty. Mostly only the graphics routines need acceleration, since the other stuff doesn't take much processing. (If it does, you're using bad algorithms, and bad algorithms suck software or hardware rendered!) I only wish all apps could some how take advantage of E17's features. Raster should really think about maybe forking GNOME or something to create a E17 DE.
So does QNX. Yea, it is bad that Be died. What really would have been cool would have been a mixture of the Linux kernel (which has gotten pretty nice these days) and the BeOS GUI. BeOS has problems with VM and networking, Linux has problems with GUI. A match made in heaven. Well, here's hoping that QNX open sources Photon...
Usually I do (like I said!) but there is no difference between Mandrake's settings and mine in terms of performance. If I'm that obsessed about performance, don't you think I'd check? Besides, its all a moot point anyhow. The problem got much better as soon as I applied the preempt patches, and I hadn't changed any other config options.
Performance usually the least of my considerations
>>>>>>>
You must be a KDE-2 developer!
I'm (not the original poster) using AA in Linux right now, and it looks great. I nuked the crappy Linux distro (X, urw, Abiword, Mandrake, etc) fonts that came installed and copied over the .ttfs from my WIndows partition. Edited my XftCache, and voila, awesome!
However, the significant performance degradation in any feature from one version of Windows to the next is a pretty damning result. It would seem to legitimize the feeling that many Windows users have that XP is a big downgrade from 2K.
>>>>>
Not necessarily. OS design consists of lots of tradeoffs. If one feature isn't used often, it is quite possible that its performance would be sacrified to make something else faster.
1) You have you no idea what you're talking about.
>>>>>>>
Care to elaborate?
2) You run mandrake and think that it is doing the appropriate thing with your computer.
>>>>>>>>
First, I run Mandrake because it is a reasonable compromise distro. I have used Slack (since 3.5), RedHat, SuSE, and Gentoo for awhile. I like Gentoo best, but can't stand having to compile all my apps myself. Second, I saw that Mandrake was running HDParm when I looked through the initscripts!
Yes, you need to install both sets of libraries. No, it isn't the end of the world to do so.
>>>>>>>>>
There are two types of people in the world. Those that hate bloat, and GNOME/KDE users...
Seriously, though, there are more problems to loading GTK+ AND Qt than just bloat (which is still a terrible sin IMO). GNOME and KDE apps don't look the same. Some people (like me) just like everything to be nice and homogenous. My desk is perfectly neat and all my pens are in the perfect places. My tabletop has marks on it showing exactly where my speakers should go. Second, the two types of apps don't interoperate that well. In Windows, I'm used to embedding graphics in Word documents that are embedded in spreadsheets. In Linux, it just doesn't work that way (yet).
Overhead will be worthwhile for more flexiblity and power. And when the machines are there, Berlin will not have to be rewritten to take advantage of them.
>>>>>>
Its that idea that makes Linux GUIs suck performance-wise. Power is rarely worth the tradeoff in speed and effieciency, since very little software ever exposes more power. Don't get fooled into equating features with power BTW. Power is being able to quickly do the work you need to do without the system getting in the way. Most of the stuff that these desktop environment developers think is power (network transparency, CORBA, etc) are really just mental masturbation and have little significance on the desktop.
Pipes are what they used before proper IPC methods like messaging were created...
I'm just kidding. Pipes are a mechanism to allow applications to send data to each other. An app at one end can stuff date into the pipe by pretending its writing to a file, and the app at the other end can read the pipe just like a file and get the data out. In Windows, pipes are rarely used. More often, people will use messaging or implement a COM or OLE component.
Why to Linux-types always think I have my software configured wrong? First of all, Mandrake automatically optimizes the hard drive at bootup. Second, the first thing I do when I setup a Linux distro is to optimize it. I get rid of the cruft in XftConfig, delete all the antiquated X fonts (and install nice, pretty Windows truetype fonts in their place), and set X to run at nice -1. The real reason the mouse sticks is two-fold. First, the standard (non-preemptible) Linux kernel can have terrible latencies during heavy disk I/O (look at the latency graphs on kpreempt.sourceforge.net) Second, UNIX scheduling algorithms aren't designed for desktop use and thus use the artificial distinction between CPU-bound and I/O-bound processes to distinguish background an interactive tasks. This works for the most part, but in complex (single-threaded) programs like Konq, which can use lots of CPU time, this is less than ideal. (BTW, BeOS solves this by giving higher priority to threads that are attached to windows, rather than monitoring CPU and I/O usage.)
Doesn't fit in with the "native" feel at all, but is fast and easy to use, because the UI fits the application, rather than having the application shoehorned into some ill-fitting paradigm.
>>>>>>>>>
Intellectual types are so into paradigms its funny. Here are some facts from reality:
1) Developers are lazy. If not forced to standardize UIs, they'll simply make crappy UIs that look different. At least by standardizing the look, you get crappy UIs that look the same.
2) Developers are lazy. If they have some UI guidelines in front of them, then they might be coaxed into using them, and maybe have the hope of making a good UI. If they have no guidelines, they'll not bother to come up with their own, they'll just make a crappy UI. If you don't believe me, take a look at Mac-Land. Most Mac apps look and behave similarly, but the Mac is the home of such great UIs as Adobe's.
3) Developers are lazy. If they are given the freedom to do whatever they want with the UI, they'll go through the path of least resistance, or of personal preferences.
No, I do not mean to *all* characterize developers as lazy (just most). Some of them do work quite hard to come up with good user interfaces and applications by these developers stand out, even when those apps look exactly like all the other apps on the desktop. The fundemental error that most of the "developer UI freedom" people make is that the *look* of the UI has very little to do with its efficiency/ease of use. There are many UIs on Windows (3D Studio MAX, for example, or Maya) that look like standard Windows apps, but have incredible workflow. Take StarOffice or Mozilla, for an opposing example. There is nothing special in their UIs that makes them more functional than Word or IE. They simply *look* different.
First, MS doesn't have as many people as the Pentagon in a single installation. Second, MS is actually pretty open about what software people use for their work.
They comple cross platform and their toolkits make it all look the same cross platforms.
>>>>>>>
That's really brain-dead. People tend to use one platform consistantly, and like it when a particular app looks like the other apps on their system. Eg. no-one cares if a program looks the same on Linux and Windows, as long as all the Linux apps look the same and all the Windows apps look the same.
Try comparing like to like? The closest comaprison to Outlook would be Evolution. How'd you like *that* for slow and bloated?
Please note that Office (any flavor) does not take "scant amounts of ram". Rather, it hides ram used in the system memory used column, and actually preloads many if not most of the Office specific DLL's on boot up, whether you want them or not. The memory that appears to be used by Office, is only the glue code that links the DLL/OLE/NET components together.
The reason that Office appears to launch almost instantanously, is that most of it was already loaded on bootup.
Just a clarification...
>>>>>>>>
Its all a moot point. On my computer (300MHz, 256MB), Office loads faster than KOffice, Office + Win2K uses about the same amount of RAM as KDE-2 + Linux, and Office runs a *lot* faster than KOffice. In KSpread, selecting multiple cells gets annoying because the system has to struggle to keep up with the selected area. In Excel, I can whip the selection area around all I want without the slightest "stickyness." I can resize Word or Excel as fast as I can move my mouse and the toolbars adjust to their new sizes with nary a hiccup. In KOffice (or any KDE app for that matter) I get an ugly rubber-band effect until the stupid widget set can catch up to my pointer. It drives me f**king INSANE!
BTW> While KDE-2 might be trash (speed-wise), has anyone switched to kernel 2.4.10 (with preempt patch)? It is AMAZING. Before, my mouse pointer used to stick whenever the disk was accessed or whenever Mozilla or Konq displayed a page. Now, not even compiling in the background can make it stick. Very, very nice. Props to the guys who worked on the AA patch, and also some kudos to AA for the new VM stuff!
And what is the world's largest installed base of Windows computers?
>>>>>>
Most likely the Pentagon. Its the largest employment site, and almost all desk jobs these days require the use of a PC.