Okay, I can agree that a file format can be as stable as an API, and I can agree that the API would likely change in the case of a file format change. I can even agree that the API might break in some ways. I just think that an API is likely to be more stable. I think we just disagree here. Probably for valid reasons though. In some ways a file format can be more portable, and it might be easier to change the information in it. On more benefit an API has is that it can allow that change to always take effect immediately without causing the server to reload its config data during every loop.
I hate the registry too. Everyone does. No one likes the registry. Even Microsoft has come around to agreeing with that now. The registry is really a database that offers up a single point of failure for everything. Ooops. It's kind of an example of how to do to much in one place. The registry does have some advantage, but it was long ago lost to its numerous disadvantages.
The shared library aspect does not much matter nowadays, but in previous years it mattered a lot. The system memory could only hold so much of an executable in memory at a time. It was nice to be able to unload and reload parts of your app so you could offer more features to the end user. I assume that history will likely repeat itself as everything in the Software Industry seems to be cyclical. This may become an issue again some day (maybe for embedded systems), though I hope not.
There are major problems with the existing databases. They don't offer the control I needed. They don't offer the speed or reliability I need. They would consume oceans of memory (in my scenario). They don't offer the ability to tightly couple load balancing, backup, and fail over. They don't support the number of users and transactions per clustered machine that I need. Those jerks break portability fairly often. Even while prototyping out the database, upgrading the database caused things to break. (Nothing spectacular going on, in that database... no reason for it... reminds me of Microsoft in a way) They don't install into a small enough foot print. They take dependencies that I don't need to worry about now. I would be a slave to porting that code which I don't care about everytime that I needed to do an upgrade. My experience is that I or my team gets stuck with portability and maintenaince. One of my requirements is that installation needs to be a dream. Meaning not inducing pain on my users asking them to install 15 dependencies like Biztalk Server does. The worst one being the database. I've read through the source code (and modified it to add some constructs) for postgresql. The code is good (actually quite good), but the limits reached based on the tools they were using at the time... specifically the version of Yacc...did not fill me with confidence. No space left in the parser, to add another key word. Ridiculous. No support for modern sql standards. Also ridiculous. Oh, it was fixable, after two days of installing other libraries from code and compiling them with the correct switches, so that the new version of Yacc would work.
The pay-for-use databases suffered from some of the same problems too.
Turns out in the end, that PostgreSql was way too slow. I expected speed on par with Sql server, and it was orders of magnitude slower. (I did have indexes and queries setup correctly... it really was just slower)
I've also used and looked at the other databases that you mentioned. I would loved to have used, and or modified the existing solutions if they would have filled those requirements for me. Then I thought, screw this. I'll just make a new database based on XML.
Anyway, thanks for the dialog, I had a great time talking about these subjects, and I really enjoyed your point of view.
Crazy optimizations are the life blood of programmers everywhere!
I for one welcome my "Crazy Optimization OverLords"
Really though, only about 6% of code is non-portable code. Those optimizations are usually a big deal for those systems, and rewriting 6% of your code if you new what you were doing in the first place, is not going to be that big of a deal.
Thank you to whoever reformatted my post for me. I really appreciate it.
Wrong on pretty much every account here, at least in theory:
* An API is not necessarily more stable than a config file schema.
* You could just as easily use some sort of API on Linux, or a config file schema (.INI files, anyone?) on Windows.
* It's not only possible, but often easy, to implement some sort of API that uses config files as a backend. That's basically how/etc/passwd (and group, and shadow) works on Linux -- no one edits it by hand, even though it is, technically, a text-based config file.
Hmm, I think that I either posted my statement in a confusing way, or you misunderstood. Basically I was trying to say that editing the file directly is usually bad. Editing it through a layer of inderection such as an API is good.
Though API, do sometimes change... good API should not change. They can be added to, but existing API should remain the same, or at least be provided for backwards compatibility.
Typically, files change frequently, and their formats should not be restricted. This would allow for files to be optimized, and for additional data to be added. It would allow for them to be made more complex without the user of the API to be bothered.
* Less portable code makes heavy use of API that is already written and tested inside the OS.
* Less portable code can therefore be less expensive and quicker to produce. Depending on the circumstance this can be a long term and/or short term benefit.
For example not all systems supported shared libraries in the past. I worked on some code that tied itself to an OS that supported that one time. For example there is a new Speech API that Microsoft provides. If I cared about Speech and voice recognition, then I would use that. For example Linux has a great thing called ssh. Though it is available minimally on other OS, I would use the Linux variant. Databases typically are also geared towards taking advantage of one OS. CAD software typically tries to take advantage of one OS. There are a lot of 3d graphics applications tied to the Mac platform. The reasons are that it was easier/better/cheaper to go that route. Windows has a great set of tools to access the system in a unified way. That technology is called WMI and I can automate anything and everything on Windows with it. On Linux, I can do the same thing, but it takes a lot more work. In some ways linux is far superior to WMI, but mostly WMI is better because there was some unification in the whole process.
These ideas are not always the case, and personally I would always try to avoid tying myself to a platform where possible. At the very least, moving off all OS, and hardware specific calls to a single library called lowlevel. The at least I can target different OS and hardware for the same application without sifting through literally a million lines of code. That is not fun.
Okay, and I agree with most of your other points.
As far as languages go, I have to say that although people can and do write stupid code, there is some measure that can be taken to avoid that code.
One example is perl. I love perl. I think it is a great and fabulous language. As a side note, I am at least an intermediate level programmer in about 12 programming languages, and an expert in 3.
Anyway, back to my point. I love perl... but since perl allows so much flexibility, it becomes difficult to maintain. Especially when you take over the project after some idiot was working on it. Some of the more restrictive languages don't allow you to do things that are impossible to figure out.
I've seen stupid code, in every language that I've ever worked with. (Most of the time it was others who wrote the stupid code, though everyone has probably written something that yells "Look at me, the super idiot" before:) All, I'm trying to say is that I thi
Basically, some people will say things like "Portability issues only happpen on Windows because of the use of Windows specific API.... and Linux somehow magically escapes this problem."
I'm sure you are already aware that it is not true, because your code is portable and uses readily available libraries that do not vary in version, or in any major way at all from OS to OS.
A buch of other people will say "All, code should be portable, because there is no reason for it to not be portable."
And, I'm sure that from your post, this is the reasoning behind your question.
So, here is a list of reasons that might help formulate an understanding of why some code is not portable... (bear in mind that a lot of my code is portable too, as that is usually indicative of good software practice)
* Less portable code makes heavy use of API that is already written and tested inside the OS.
* Less portable code can therefore be less expensive and quicker to produce. Depending on the circumstance this can be a long term and/or short term benefit.
* Less portable code can be made to execute faster than portable code
* Less portable code can be made to take advantage of hardware features that are only exposed through a specific API
* Typically the most popular OS in the world is easier to program for by most programmers, thereby allowing everyone that is hired to get up to speed on the project more quickly. (Not a concern for a team of one)
* Typically large projects need to make every advantage in efficiency that is readily available. This might or might not be dependant on the OS
* Anything that has to do a lot of work with filesystems will need operating system dependant code to be written. There are faster file operation system calls for each specific OS.
* Less portable code can be made smaller in size, by depending on libraries that are only available on a target OS. (As long as they are actually there!!!)
For example in Windows you can take advantage of a bunch of API to change system settings like IIS settings, and smtp settings.
In Linux you have to write code to manually change text files. Of course API are better here because then there is less chance messing up the format of the text file. And your code will work in the next version of the OS too. Your code will not work in the next version if you change the config files manually. In your case, you don't care because you are just writing little free utilities. In bigger enterprise level applications you need to care about things like this. There are many examples of needing to use API where-ever possible. More experience with bigger applications is the best way to get to this knowledge.
Also, one final note. C is getting to be an old language now, and it is sad that any code written in C is not portable. Things that have been around that long, have workaround after workaround to make them keep from breaking. It almost requires effort to write C code that is not portable nowadays. Bad C code is still prevelant though. This is mostly due to the #define conditional that was included to make C a lasting language. It worked. Now let's be done with it.
Moving forward, I would suggest a language that makes use of garbage collection as your next choice. Also, one with clean syntax and no workarounds already in place would be a good plan. These criterea make for a langauge that is more difficult to write stupid code in. If you ever have to maintain code, then these are good considerations.
Here are some examples (in no specific oreder)
Java, C#, PHP
Here is a bad example
C++
Engineering: I don't like pretty or neat stuff. Marketing: Do you like to get money? Engineering: Do whatever it takes, I'll make it work. Marketing: Okay, Thanks.
That is not a good thing if you already have code written. Besides, the languages you mention might (read do) have pitfalls that others don't share.
I don't want to port 100k or 200k lines of code to Python. It would be quicker and shorter to write my own compiler or in this case... use one that someone else wrote for that operating system.
I've noticed that most open source projects are the way that you describe, with the culture you describe.
If I were you I would stick with big companies that produce commercial software. They tend to be motivated by cash, and hire real engineers to make sure things get done correctly as much of the time as is possible.
While Microsoft has its flaws and might be deteriorating in their practice of engineering as of late, they still outshine everyone in the areas that you are complaining about.
Maybe you used to work there, and just miss that goodness in those areas?
Additionally, if our national product was cut in half, we'd be living like they did in the 1984
Hey, that sounds like a valid and meaningful statistic. Where did you learn that? Could you give us a topic, a link, or a book title, or a book subject? I find this topic really interesting, and I'd like to look this up and learn more about how these statistic predictions are made.
Wikipedia would likely have a poll or a forum for a subject. "Which book do you guys think is best in subject X?" type of thing.
For that matter, I think wikipedia already has a great formula for history in its encyclopic format. The subject of history can probably just get skipped over entirely for this idea.
I've learned multiple trades and applied them in careers through self learning.... And although I agree that universities are fairly over-rated, I can say that not having the money (because I didn't want the debt that goes with it) has an impact on the speed at which some skills can be aquired.
I just want to be fair to universities here, so please don't interpret this as my being in favor of them over a motivated individuals ability to learn (after all, its the individual that is learning at the university too)
Also, some skills can require equipment that might be cost prohibitive to use for a single person learning something themselves. Universities often have a lot of equipment for student usage. For example I would like to do fusion research, but I lack a supercollider.:)
Some skills can be picked up from a good teacher at a university much quicker than trying to figure it out yourself.
All that I was trying to point out was the idea. The subjects were just illustrative of the idea and not meant necessarily as the subjects. $100,000,000 at 20k per copyright would be 5000 works hopefully spanning many subjects.
One book per academic subject.
One for each kind of math.
One for each kind of music.
One for each kind of computer science.
One for masonry, or automotive, or other trades.
and so on...
So, someone can go to the "tutorial" section of wikipedia and learn how to do whatever they would normally need textbooks or college to learn.
Granted that you could likely only reach an ametuer level this way most of the time, it would be a great starting point for a lot of people into business and hobby.
If they have nuclear scientists, it's hard to imagine them watching the news for tips about how to make nuclear weapons. They probably have an education in nuclear physics. The test results that they gathered are enough to improve thier next text.
I've noticed that login times vary wildly based on hardware and OS. I've seen Linux boxes boot immediately and I've seen them take 7 minutes. I've seen Windows boxes boot immediately, and I've seen them take 5 minutes.
I don't really mind either way, since I just leave the computer on most of the time.
Honestly, it is good for me as long as it boots up somewhere less than the time it takes me to take off my coat, and shoes, and throw something in the Microwave.
That's probably 3 minutes and is usually about right.
I don't care about syntax highlighting when I just want to open up an editor to view a file quickly, or take a note quickly.
I like syntax highlighting however, and I use VS.Net for that. It takes about 2 seconds to load (the way I've got it setup) and does way more than Kate.
The point here is that if Syntax highlighting or folding slow it down, then let me optionally turn them off (without recompling) so that it loads faster. Besides that, the thing ought to just load in an instant, no matter what. Things that load slowly should put off their time consuming operations until after the window pops up. I might be done with it before it gets to those instructions anyways.
Even MS Word (the overweight beast of lore) loads as fast as Kate.
Do you have some stats to show XP is slower than a KDE Linux distro?
Mostly I'm conncerned with application startup times, which are typically double on Linux as opposed to Windows for the same app.
Get a stopwatch and time opening up notepad in XP as opposed to your favorite note editor in Linux (gedit in gnome, kate in kde)
Do the same thing for FireFox.
Do the same thing for Open Office.
Linux is slower. I don't like to wait. I'll use Linux when it is faster, or when there is only a negligable difference in speed due to the increasing speed of hardware.
And what is the "seven levels of dialogs" that you are complaining about? Is that something that is Windows only? I'd really like to know, so I can keep it from happening when I write programs.
Slashdot Mirror
A priest, a rabii, and a dog walk into a .... zrrruhhh, thump, clunk, ... please replace batterrry....
You forgot...
6. ????
7. Profit!
I just don't understand why that indefinite article is so important. The meaning of the sentence is the same.
Did you lose your house, wife, dog, cars, and boat, to another man? Stop waisting time on slashdot, and get your life back in order then.
Okay, I can agree that a file format can be as stable as an API, and I can agree that the API would likely change in the case of a file format change. I can even agree that the API might break in some ways. I just think that an API is likely to be more stable. I think we just disagree here. Probably for valid reasons though. In some ways a file format can be more portable, and it might be easier to change the information in it. On more benefit an API has is that it can allow that change to always take effect immediately without causing the server to reload its config data during every loop.
...did not fill me with confidence. No space left in the parser, to add another key word. Ridiculous. No support for modern sql standards. Also ridiculous. Oh, it was fixable, after two days of installing other libraries from code and compiling them with the correct switches, so that the new version of Yacc would work.
I hate the registry too. Everyone does. No one likes the registry. Even Microsoft has come around to agreeing with that now. The registry is really a database that offers up a single point of failure for everything. Ooops. It's kind of an example of how to do to much in one place. The registry does have some advantage, but it was long ago lost to its numerous disadvantages.
The shared library aspect does not much matter nowadays, but in previous years it mattered a lot. The system memory could only hold so much of an executable in memory at a time. It was nice to be able to unload and reload parts of your app so you could offer more features to the end user. I assume that history will likely repeat itself as everything in the Software Industry seems to be cyclical. This may become an issue again some day (maybe for embedded systems), though I hope not.
There are major problems with the existing databases. They don't offer the control I needed. They don't offer the speed or reliability I need. They would consume oceans of memory (in my scenario). They don't offer the ability to tightly couple load balancing, backup, and fail over. They don't support the number of users and transactions per clustered machine that I need. Those jerks break portability fairly often. Even while prototyping out the database, upgrading the database caused things to break. (Nothing spectacular going on, in that database... no reason for it... reminds me of Microsoft in a way) They don't install into a small enough foot print. They take dependencies that I don't need to worry about now. I would be a slave to porting that code which I don't care about everytime that I needed to do an upgrade. My experience is that I or my team gets stuck with portability and maintenaince. One of my requirements is that installation needs to be a dream. Meaning not inducing pain on my users asking them to install 15 dependencies like Biztalk Server does. The worst one being the database. I've read through the source code (and modified it to add some constructs) for postgresql. The code is good (actually quite good), but the limits reached based on the tools they were using at the time... specifically the version of Yacc
The pay-for-use databases suffered from some of the same problems too.
Turns out in the end, that PostgreSql was way too slow. I expected speed on par with Sql server, and it was orders of magnitude slower. (I did have indexes and queries setup correctly... it really was just slower)
I've also used and looked at the other databases that you mentioned. I would loved to have used, and or modified the existing solutions if they would have filled those requirements for me. Then I thought, screw this. I'll just make a new database based on XML.
Anyway, thanks for the dialog, I had a great time talking about these subjects, and I really enjoyed your point of view.
Crazy optimizations are the life blood of programmers everywhere!
I for one welcome my "Crazy Optimization OverLords"
Really though, only about 6% of code is non-portable code. Those optimizations are usually a big deal for those systems, and rewriting 6% of your code if you new what you were doing in the first place, is not going to be that big of a deal.
Thank you to whoever reformatted my post for me. I really appreciate it.
Wrong on pretty much every account here, at least in theory:
* An API is not necessarily more stable than a config file schema.
* You could just as easily use some sort of API on Linux, or a config file schema (.INI files, anyone?) on Windows.
* It's not only possible, but often easy, to implement some sort of API that uses config files as a backend. That's basically how
Hmm, I think that I either posted my statement in a confusing way, or you misunderstood. Basically I was trying to say that editing the file directly is usually bad. Editing it through a layer of inderection such as an API is good.
Though API, do sometimes change... good API should not change. They can be added to, but existing API should remain the same, or at least be provided for backwards compatibility.
Typically, files change frequently, and their formats should not be restricted. This would allow for files to be optimized, and for additional data to be added. It would allow for them to be made more complex without the user of the API to be bothered.
* Less portable code makes heavy use of API that is already written and tested inside the OS.
* Less portable code can therefore be less expensive and quicker to produce. Depending on the circumstance this can be a long term and/or short term benefit. For example not all systems supported shared libraries in the past. I worked on some code that tied itself to an OS that supported that one time. For example there is a new Speech API that Microsoft provides. If I cared about Speech and voice recognition, then I would use that. For example Linux has a great thing called ssh. Though it is available minimally on other OS, I would use the Linux variant. Databases typically are also geared towards taking advantage of one OS. CAD software typically tries to take advantage of one OS. There are a lot of 3d graphics applications tied to the Mac platform. The reasons are that it was easier/better/cheaper to go that route. Windows has a great set of tools to access the system in a unified way. That technology is called WMI and I can automate anything and everything on Windows with it. On Linux, I can do the same thing, but it takes a lot more work. In some ways linux is far superior to WMI, but mostly WMI is better because there was some unification in the whole process.
These ideas are not always the case, and personally I would always try to avoid tying myself to a platform where possible. At the very least, moving off all OS, and hardware specific calls to a single library called lowlevel. The at least I can target different OS and hardware for the same application without sifting through literally a million lines of code. That is not fun.
Okay, and I agree with most of your other points.
As far as languages go, I have to say that although people can and do write stupid code, there is some measure that can be taken to avoid that code.
One example is perl. I love perl. I think it is a great and fabulous language. As a side note, I am at least an intermediate level programmer in about 12 programming languages, and an expert in 3.
Anyway, back to my point. I love perl... but since perl allows so much flexibility, it becomes difficult to maintain. Especially when you take over the project after some idiot was working on it. Some of the more restrictive languages don't allow you to do things that are impossible to figure out.
I've seen stupid code, in every language that I've ever worked with. (Most of the time it was others who wrote the stupid code, though everyone has probably written something that yells "Look at me, the super idiot" before
I did break my text into paragraphs. I had just forgotten that slashdot is so screwed up, that I need to put the html tags in it.
Basically, some people will say things like "Portability issues only happpen on Windows because of the use of Windows specific API.... and Linux somehow magically escapes this problem." I'm sure you are already aware that it is not true, because your code is portable and uses readily available libraries that do not vary in version, or in any major way at all from OS to OS. A buch of other people will say "All, code should be portable, because there is no reason for it to not be portable." And, I'm sure that from your post, this is the reasoning behind your question. So, here is a list of reasons that might help formulate an understanding of why some code is not portable... (bear in mind that a lot of my code is portable too, as that is usually indicative of good software practice) * Less portable code makes heavy use of API that is already written and tested inside the OS. * Less portable code can therefore be less expensive and quicker to produce. Depending on the circumstance this can be a long term and/or short term benefit. * Less portable code can be made to execute faster than portable code * Less portable code can be made to take advantage of hardware features that are only exposed through a specific API * Typically the most popular OS in the world is easier to program for by most programmers, thereby allowing everyone that is hired to get up to speed on the project more quickly. (Not a concern for a team of one) * Typically large projects need to make every advantage in efficiency that is readily available. This might or might not be dependant on the OS * Anything that has to do a lot of work with filesystems will need operating system dependant code to be written. There are faster file operation system calls for each specific OS. * Less portable code can be made smaller in size, by depending on libraries that are only available on a target OS. (As long as they are actually there!!!) For example in Windows you can take advantage of a bunch of API to change system settings like IIS settings, and smtp settings. In Linux you have to write code to manually change text files. Of course API are better here because then there is less chance messing up the format of the text file. And your code will work in the next version of the OS too. Your code will not work in the next version if you change the config files manually. In your case, you don't care because you are just writing little free utilities. In bigger enterprise level applications you need to care about things like this. There are many examples of needing to use API where-ever possible. More experience with bigger applications is the best way to get to this knowledge. Also, one final note. C is getting to be an old language now, and it is sad that any code written in C is not portable. Things that have been around that long, have workaround after workaround to make them keep from breaking. It almost requires effort to write C code that is not portable nowadays. Bad C code is still prevelant though. This is mostly due to the #define conditional that was included to make C a lasting language. It worked. Now let's be done with it. Moving forward, I would suggest a language that makes use of garbage collection as your next choice. Also, one with clean syntax and no workarounds already in place would be a good plan. These criterea make for a langauge that is more difficult to write stupid code in. If you ever have to maintain code, then these are good considerations. Here are some examples (in no specific oreder) Java, C#, PHP Here is a bad example C++
Engineering: I don't like pretty or neat stuff.
Marketing: Do you like to get money?
Engineering: Do whatever it takes, I'll make it work.
Marketing: Okay, Thanks.
That is not a good thing if you already have code written. Besides, the languages you mention might (read do) have pitfalls that others don't share. I don't want to port 100k or 200k lines of code to Python. It would be quicker and shorter to write my own compiler or in this case... use one that someone else wrote for that operating system.
You are an idiot. Because some1 spells something wrng you thnk that you R smart. They had valid pointz and you are just an idiot.
I don't think he intended that book to be taken seriously. Maybe it was just for fun too?
I've noticed that most open source projects are the way that you describe, with the culture you describe.
If I were you I would stick with big companies that produce commercial software. They tend to be motivated by cash, and hire real engineers to make sure things get done correctly as much of the time as is possible.
While Microsoft has its flaws and might be deteriorating in their practice of engineering as of late, they still outshine everyone in the areas that you are complaining about.
Maybe you used to work there, and just miss that goodness in those areas?
Additionally, if our national product was cut in half, we'd be living like they did in the 1984
Hey, that sounds like a valid and meaningful statistic. Where did you learn that? Could you give us a topic, a link, or a book title, or a book subject? I find this topic really interesting, and I'd like to look this up and learn more about how these statistic predictions are made.
I think a shovel would work well at mining a dump. ;) What tech do we need to mine a dump that we don't already have?
This isn't really a valid point.
Wikipedia would likely have a poll or a forum for a subject. "Which book do you guys think is best in subject X?" type of thing.
For that matter, I think wikipedia already has a great formula for history in its encyclopic format. The subject of history can probably just get skipped over entirely for this idea.
Agreed.
... And although I agree that universities are fairly over-rated, I can say that not having the money (because I didn't want the debt that goes with it) has an impact on the speed at which some skills can be aquired.
:)
I've learned multiple trades and applied them in careers through self learning.
I just want to be fair to universities here, so please don't interpret this as my being in favor of them over a motivated individuals ability to learn (after all, its the individual that is learning at the university too)
Also, some skills can require equipment that might be cost prohibitive to use for a single person learning something themselves. Universities often have a lot of equipment for student usage. For example I would like to do fusion research, but I lack a supercollider.
Some skills can be picked up from a good teacher at a university much quicker than trying to figure it out yourself.
All that I was trying to point out was the idea. The subjects were just illustrative of the idea and not meant necessarily as the subjects. $100,000,000 at 20k per copyright would be 5000 works hopefully spanning many subjects.
One book per academic subject.
One for each kind of math.
One for each kind of music.
One for each kind of computer science.
One for masonry, or automotive, or other trades.
and so on...
So, someone can go to the "tutorial" section of wikipedia and learn how to do whatever they would normally need textbooks or college to learn.
Granted that you could likely only reach an ametuer level this way most of the time, it would be a great starting point for a lot of people into business and hobby.
If they have nuclear scientists, it's hard to imagine them watching the news for tips about how to make nuclear weapons. They probably have an education in nuclear physics. The test results that they gathered are enough to improve thier next text.
I've noticed that login times vary wildly based on hardware and OS. I've seen Linux boxes boot immediately and I've seen them take 7 minutes. I've seen Windows boxes boot immediately, and I've seen them take 5 minutes.
I don't really mind either way, since I just leave the computer on most of the time.
Honestly, it is good for me as long as it boots up somewhere less than the time it takes me to take off my coat, and shoes, and throw something in the Microwave.
That's probably 3 minutes and is usually about right.
I don't care about syntax highlighting when I just want to open up an editor to view a file quickly, or take a note quickly.
I like syntax highlighting however, and I use VS.Net for that. It takes about 2 seconds to load (the way I've got it setup) and does way more than Kate.
The point here is that if Syntax highlighting or folding slow it down, then let me optionally turn them off (without recompling) so that it loads faster. Besides that, the thing ought to just load in an instant, no matter what. Things that load slowly should put off their time consuming operations until after the window pops up. I might be done with it before it gets to those instructions anyways.
Even MS Word (the overweight beast of lore) loads as fast as Kate.
The cached startup time is nearly the same on both. Maybe that is what you are noticing?
But, the uncached startup time is significantly different. So much so, that you can use a stopwatch to measure seconds of difference.
Do you have some stats to show XP is slower than a KDE Linux distro? Mostly I'm conncerned with application startup times, which are typically double on Linux as opposed to Windows for the same app. Get a stopwatch and time opening up notepad in XP as opposed to your favorite note editor in Linux (gedit in gnome, kate in kde) Do the same thing for FireFox. Do the same thing for Open Office. Linux is slower. I don't like to wait. I'll use Linux when it is faster, or when there is only a negligable difference in speed due to the increasing speed of hardware. And what is the "seven levels of dialogs" that you are complaining about? Is that something that is Windows only? I'd really like to know, so I can keep it from happening when I write programs.