Either that, or they'll start charging you based on the bandwidth you actually get, rather than the fraction of your bandwidth they expect you to use. I think it's likely that a lot of ISPs will start giving you the option of buying exactly the bandwidth you want, and prohibiting sharing on the other plan.
Actually, it's much more likely that they'll go to slightly better accounting. Something like 384kbps 25% of the time, 57kbps the rest of the time. If you use more the 57kbps for 6 hours in a day, you get capped at 57 for the rest of the day. If you don't want to get capped like that, you pay for the whole bandwidth all the time. Billing people according to usage is a pain, but making your network slow if you use too much bandwidth isn't too hard. And sharing isn't really that big a deal-- you can use up 384kbps by yourself if you try, and it's no different.
You're not using fvwm to reduce your use of the mouse? That's the best part! (Changing focus using the windowlist menu)
Hmm... digital xclock, mozilla, emacs, bunch of xterms... that sounds exactly like my desktop.
On the other hand, this desktop has a much clearer interface than Windows: There are a bunch of windows which you just type in, running mostly shells. There's a bunch of windows that you type in editing documents. There's a web browser. There aren't a lot of things that behave in complicated ways, mysterious icons, etc. Everything follows a consistant style.
You're not really disagreeing with the GUI-gurus, who have been saying this sort of thing for a long time. It's just that their examples have a lot more stuff in them. The principles are the same: make any action have a obvious consequence which is as similar as possible in all contexts.
I think the best GUI for most users is actually much closer to your desktop than you think. It probably would involve a few windows you don't have, such as something as straightforward as an xterm, but which was good for showing tables and images, and probably something xterm-like but with a proportional font. It would probably also have a bit more in the way of pretty pictures, but they wouldn't get in the way.
He has nothing against the Itanium (in fact, Linux runs on the Itanium perfectly well). What he's hoping for is that Hammer takes off so the non-Hammer x86 market dries up and Intel goes to an Itanium/Hammer product line instead of Itanium/Pentium. What he's worried about is 32-bit machines with large memory and disk.
But there are relatively few changes which need to be made to make a program run in 64-bit, and those changes don't cause problems with running it 32-bit. So people have the choice of their code running more slowly, but working everywhere, or running more quickly on Hammer, and running everywhere. Unlike with OS/2, you're not making two different versions for the different platforms, at the source level at least.
Of course, you're going to have to have Hammer-specific binaries to use 64-bit. But generating them is just a compiler issue, and software comes out for different processors all the time, when it doesn't require code changes.
MicroSoft pushes forward. Linux pushes forward in a different direction. Sure, sometimes MicroSoft does things that turn out to be worthwhile, like supporting USB 2.0, but just as often, MicroSoft does things which turn out to be really bad ideas, and it's just as well Linux never tried them. And there are plenty of things you can do with Linux you can't do with Windows, and plenty of things where Linux supported it first.
Read the core dump? Ha! Good programmers know what's wrong from when the segfault occured.
But if you're going to use tools, having a tool that tells you when a value gets written somewhere wrong is far better than one that tells you what was going on when the program actually crashed.
This is actually vital for bugs where an uninitialized value is assumed to be zero, and it always is zero in your tests, but...
Linux developers have, in general, had better things to do, aside from the group of people working on it. Until there are devices that use it and machines that support it, there's no reason to have OS support. MicroSoft shipped support a while ago because they're pushing its adoption. Linux developers just want all the devices people have to work; they're generally not pushing particular hardware. Keeping on top of all of the standards which may or may not catch on is generally a waste of time which could be better spent working on any of the other things you mentioned.
Why should a politician give a straight answer to a question? Someone who is going to be endlessly quoted shouldn't be trying to think on their feet, because they're unlikely to pull it off, even if they actually have the necessary information to come up with a good answer. Politicians, ALICE, and Wallace in this interview have responses to certain things, and they don't have anything else suitable to answer with.
I don't think Wallace is actually complaining about politicians in this statement, nor would he say that a scientist would answer differently. A scientist, especially, only knows a limited set of things, and so can only answer certain questions. These questions will get a canned answer, while other questions will be diverted. A scientist absolutely cannot give a straight answer to most questions, because the answer requires doing some research. Questions answered at a scientific lecture are limited to clarifying what's been said, reporting other research, and describing plans that have already been formed.
What is different is that a scientist expects to be asked exclusively about the prepared material, whereas a politician expects to be asked about other topics and to divert those questions.
How about something simpler? What if musicians recorded and released all of their practice sessions? Sure, it would be a huge mess of sound, and not really worth sitting down and listening to. But people would stumble over a bit they really liked, or a song they found catchy, and they'd do post-production on it so they could hear a clean take of it. Then they'd have this thing they created just to hear it, and they'd give it away to other people because, well, why not? Sure, the quality would be somewhat inconsistant, and you'd never find an album's worth of songs that matched each other, but you'd find plenty of good stuff.
There's an entirely different part of behavior which used to not be economically significant. People don't like to just sit there, they like to do things. Writing software can be like playing games and solving puzzles, activities that people actually pay money for. People will put jigsaw puzzles together, look at them for a bit, and then take them apart. There is no reasonable motivation for this behavior except that people get bored otherwise.
Now consider OSS. People play around with it, doing whatever they feel like doing. Getting a program or a feature working is as satisfying as solving a puzzle or winning a game. In fact, more so, because you're probably the first person to solve it in a particular way. Plus, you can show off your results to other people, and they frequently care, even if you're not a professional or anything.
The trick is that digital copying and long-range communication mean that the value created out of staving off boredom actually is significant in market terms. It's as if your grandmother, to keep her hands busy, knit sweaters for the entire country, at no cost to her. Sure, some people want different sweaters and will still buy them from stores, but everyone has the option of chosing a free hand-knit sweater. Your grandmother, of course, doesn't care either way; she's not interested in selling things, and enjoyed knitting. In the real world, of course, your grandmother can knit a sweater for each of her grandkids, and that doesn't affect the economy. But these days, it is possible for hobbyists to generate enough valuable information that it has economic effects.
Server-to-server is really hard, for a number of reasons: other networks don't have exactly same features or underlying concepts, routing between networks and back is tricky to do without introducing the possibility of loops, and it's hard to nail down exactly what everybody's server protocol is going to be forever.
People have problems with email-usenet gateways, and those are far more similar than IM networks. IRC, which was even designed for interoperability, is a number of detatched networks.
In any case, server-to-server requires that the server on the other end be interested in talking to you. The other networks aren't required to interoperate and they probably don't care; people get MSN accounts even if they have AIM accounts, so there's no motivation for MSN to constrain their servers to work with the AIM ones.
Re:while we're at it, let's burn our Makefiles too
on
Subversion Hits Alpha
·
· Score: 2
I believe you're misunderstanding my use of includes. I'm suggesting using them for two purposes: (1) read simple files out of each directory which explain the contents of the directory as a set of readable variable definitions and (2) share code and have loops and subroutines in a tight set of scripts written together.
Build variations should be refactored until they come down to, essentially, "which parts of the code do I build". Then, based on simple cues from the user, you can build the right things.
My non-recursive make is for a project which has about nineteen targets which are either binaries or libraries; the one which is build depends on which directory you invoke make from. There is a make target to make a distribution, which includes everything needed for the target in the current directory and can be build from the root of the distribution.
The scalability issue is not with the number of build variations but with the number of types of build variations. Having a lot of dissimilar build variations is just a mess, regardless of what you're using to build with.
Re:while we're at it, let's burn our Makefiles too
on
Subversion Hits Alpha
·
· Score: 2
I have it at http://iabervon.org/~barkalow/make.tar.gz if you'd like to take a look. Obviously, it's tuned to the way I have my project arranged, but it shouldn't be hard to apply the principles to another project. The "explanation" file is a bit out of date, in that the system actually does some of the wishlist items.
Having a lot of data is a good thing when reconstructing accidents. Being able to determine exactly what the driver was doing to the car will help to distinguish between skids where the driver was making it worse, skids where the driver didn't do much to help, and skids where the driver was doing the right thing and didn't recover control in time, all of which can leave about the same evidence on the road and car.
It's not useful to know everything the driver normally does without having the road conditions in extensive detail. There's no way the box is going to be able to tell what a safe speed is, whether someone is driving erraticly in response to other cars and pedestrians. Someone driving slowly could be driving in fog, following a bicycle, in traffic, reading signs and ignoring the road, or just stoned.
This data is only really useful in conjunction with scene evidence and other witnesses (except that you could easily tell where the kid took the car and when). You can't really use it to measure driving skill.
Optimizing light cycles could definitely help traffic flow. Of course, there are plenty of cities that are trying to make traffic go more slowly in places or have other desireable properties than just moving cars.
It's probably not a good idea, though, to have the system change in response to conditions, because people get used to the behavior of the traffic lights on their commutes, and so it's advantagous to have the lights be consistent.
I also think that you'd need a huge amount of sensors to do anything sensible with timings. Are only a few cars going through the intersection because, while there are a lot of cars coming that way, they don't have time in the cycle to all go through? Is it because they're stuck behind someone trying to turn left? Is it because they're trying to go into a street which is backed up into the intersection during that part of the light cycle? Is it because everyone is stuck at the previous intersection?
Optimizing traffic light cycles can help a lot of problems significantly, but I don't think there's really any substitute for having people actually go to the intersection and see what happens.
It would be very useful if they had tools for making a subversion repository from a CVS repository, keeping all the history, because people who are now using CVS won't want to lose their historical info. Since the features seem to be a superset of CVS's features, the only problem would be that the pre-subversion history would look odd where people did things to work around missing features.
Re:while we're at it, let's burn our Makefiles too
on
Subversion Hits Alpha
·
· Score: 2
Make is actually quite nice if you use a little trick: have only one Makefile. Have that Makefile include a file from each directory that contains variable definitions. That way, you separate the code from the data, meaning that you don't need to automatically generate the Makefiles (since you don't change them for each project and directory), so the Makefiles can be readable.
You can also do some really interesting things with conditionals and what amounts to iterative includes. I have a set of Makefiles totalling 315 lines which will accurately do exactly the steps needed to rebuild a program if any source file changes, regardless of which directory the file is in, and can be run from any directory in the tree. If nothing has changed, make says nothing except "'target' is up to date". It wasn't terribly hard to do.
Re:while we're at it, let's burn our Makefiles too
on
Subversion Hits Alpha
·
· Score: 2
I never figured out a way to get ant to reliably compile a Java project correctly. It uses the javac dependancy engine, which is specified in a broken way (the rules in the specification don't actually mean that compiling the classes it finds as needing recompilation is the same as compiling from scratch).
After using ant for a while at my work, we decided that it was the most common cause of people checking in broken code (which hadn't caused a problem for the author) and incorrect builds, and switched to make (with a python script to find java dependancies correctly).
The other problem with ant was (at the time, at least), there was no way to avoid running a program because it could be determined that it was unnecessary. This made trying to use EJB with a container that required an EJB compiler practically impossible, because we had a 20 minute build cycle, even when the ejbc step wasn't necessary.
Evidently, there is an early and temporary option in the JPEG spec that uses the Forgent-claimed methods. This means that JPEGs can use the patented methods, although people don't actually make such JPEGs in general. To avoid the patent, support for these would have to be removed. But the real point is that people might find it easier to pay Forgent rather than figure out what kind of JPEGs they've got.
If the city wants to modify the traffic pattern, they'd better not do it by changing 10,000 traffic light programs at the same time. What the city actually wants to do is identify trouble spots and change the traffic lights there or near there.
Traffic lights are programmable because they're all different. There is no sensible bulk update possible. If you're tweaking each set individually, you might as well send some guy over to change it.
Those are all different, though: your fridge could have sensors which detect all the things in it by RF tags to tell you what it needs, but the computer problem still wouldn't affect the cooling system, which doesn't have any reason to be connected.
Traffic lights and pacemakers don't need anything except clocks and sensors. You wouldn't want to make a larger-scale system, because that would be too hard to program-- it would be very difficult to avoid messing up the system even without attackers.
Will MicroSoft actually control.NET web services? I think it far more likely that people would stick with Apache (after all, it actually works and does everything you want for free, with a low TCO) than MicroSoft (I could use these features I couldn't use before, so long as I don't mind not being able to use anything I already have or can afford).
MicroSoft can't beat Apache in Apache's market: they can't undersell it, it performs as well, it's more popular, and has a better security record. So the fallback position is to make it desireable to run Apache on Windows and develop Apache web services on Windows. MicroSoft is also more interested in the client-side: if they can make IE integrate better with web services than any of the competitors, they'll maintain browser dominance, even if they don't control the servers. People do serve IE-specific pages on Apache, because those are both the most common applications.
MicroSoft tries to dominate every market they're in. They don't have to be in every market, including the "smart cheap people" market segments.
Slashdot Mirror
One remote hole in the default install, and one in the default update?
I think their catchphrase only actually applies to their code, not their distribution site; the version with the trojan isn't really their software.
Either that, or they'll start charging you based on the bandwidth you actually get, rather than the fraction of your bandwidth they expect you to use. I think it's likely that a lot of ISPs will start giving you the option of buying exactly the bandwidth you want, and prohibiting sharing on the other plan.
Actually, it's much more likely that they'll go to slightly better accounting. Something like 384kbps 25% of the time, 57kbps the rest of the time. If you use more the 57kbps for 6 hours in a day, you get capped at 57 for the rest of the day. If you don't want to get capped like that, you pay for the whole bandwidth all the time. Billing people according to usage is a pain, but making your network slow if you use too much bandwidth isn't too hard. And sharing isn't really that big a deal-- you can use up 384kbps by yourself if you try, and it's no different.
Plus, this'll help tourists by keeping the stations from flipping around when you're not paying attention...
You're not using fvwm to reduce your use of the mouse? That's the best part! (Changing focus using the windowlist menu)
Hmm... digital xclock, mozilla, emacs, bunch of xterms... that sounds exactly like my desktop.
On the other hand, this desktop has a much clearer interface than Windows: There are a bunch of windows which you just type in, running mostly shells. There's a bunch of windows that you type in editing documents. There's a web browser. There aren't a lot of things that behave in complicated ways, mysterious icons, etc. Everything follows a consistant style.
You're not really disagreeing with the GUI-gurus, who have been saying this sort of thing for a long time. It's just that their examples have a lot more stuff in them. The principles are the same: make any action have a obvious consequence which is as similar as possible in all contexts.
I think the best GUI for most users is actually much closer to your desktop than you think. It probably would involve a few windows you don't have, such as something as straightforward as an xterm, but which was good for showing tables and images, and probably something xterm-like but with a proportional font. It would probably also have a bit more in the way of pretty pictures, but they wouldn't get in the way.
He has nothing against the Itanium (in fact, Linux runs on the Itanium perfectly well). What he's hoping for is that Hammer takes off so the non-Hammer x86 market dries up and Intel goes to an Itanium/Hammer product line instead of Itanium/Pentium. What he's worried about is 32-bit machines with large memory and disk.
But there are relatively few changes which need to be made to make a program run in 64-bit, and those changes don't cause problems with running it 32-bit. So people have the choice of their code running more slowly, but working everywhere, or running more quickly on Hammer, and running everywhere. Unlike with OS/2, you're not making two different versions for the different platforms, at the source level at least.
Of course, you're going to have to have Hammer-specific binaries to use 64-bit. But generating them is just a compiler issue, and software comes out for different processors all the time, when it doesn't require code changes.
MicroSoft pushes forward. Linux pushes forward in a different direction. Sure, sometimes MicroSoft does things that turn out to be worthwhile, like supporting USB 2.0, but just as often, MicroSoft does things which turn out to be really bad ideas, and it's just as well Linux never tried them. And there are plenty of things you can do with Linux you can't do with Windows, and plenty of things where Linux supported it first.
Read the core dump? Ha! Good programmers know what's wrong from when the segfault occured.
But if you're going to use tools, having a tool that tells you when a value gets written somewhere wrong is far better than one that tells you what was going on when the program actually crashed.
This is actually vital for bugs where an uninitialized value is assumed to be zero, and it always is zero in your tests, but...
Linux developers have, in general, had better things to do, aside from the group of people working on it. Until there are devices that use it and machines that support it, there's no reason to have OS support. MicroSoft shipped support a while ago because they're pushing its adoption. Linux developers just want all the devices people have to work; they're generally not pushing particular hardware. Keeping on top of all of the standards which may or may not catch on is generally a waste of time which could be better spent working on any of the other things you mentioned.
Why should a politician give a straight answer to a question? Someone who is going to be endlessly quoted shouldn't be trying to think on their feet, because they're unlikely to pull it off, even if they actually have the necessary information to come up with a good answer. Politicians, ALICE, and Wallace in this interview have responses to certain things, and they don't have anything else suitable to answer with.
I don't think Wallace is actually complaining about politicians in this statement, nor would he say that a scientist would answer differently. A scientist, especially, only knows a limited set of things, and so can only answer certain questions. These questions will get a canned answer, while other questions will be diverted. A scientist absolutely cannot give a straight answer to most questions, because the answer requires doing some research. Questions answered at a scientific lecture are limited to clarifying what's been said, reporting other research, and describing plans that have already been formed.
What is different is that a scientist expects to be asked exclusively about the prepared material, whereas a politician expects to be asked about other topics and to divert those questions.
I'd be impressed if your office secretary can do even 50 wpm in her sleep, though...
How about something simpler? What if musicians recorded and released all of their practice sessions? Sure, it would be a huge mess of sound, and not really worth sitting down and listening to. But people would stumble over a bit they really liked, or a song they found catchy, and they'd do post-production on it so they could hear a clean take of it. Then they'd have this thing they created just to hear it, and they'd give it away to other people because, well, why not? Sure, the quality would be somewhat inconsistant, and you'd never find an album's worth of songs that matched each other, but you'd find plenty of good stuff.
There's an entirely different part of behavior which used to not be economically significant. People don't like to just sit there, they like to do things. Writing software can be like playing games and solving puzzles, activities that people actually pay money for. People will put jigsaw puzzles together, look at them for a bit, and then take them apart. There is no reasonable motivation for this behavior except that people get bored otherwise.
Now consider OSS. People play around with it, doing whatever they feel like doing. Getting a program or a feature working is as satisfying as solving a puzzle or winning a game. In fact, more so, because you're probably the first person to solve it in a particular way. Plus, you can show off your results to other people, and they frequently care, even if you're not a professional or anything.
The trick is that digital copying and long-range communication mean that the value created out of staving off boredom actually is significant in market terms. It's as if your grandmother, to keep her hands busy, knit sweaters for the entire country, at no cost to her. Sure, some people want different sweaters and will still buy them from stores, but everyone has the option of chosing a free hand-knit sweater. Your grandmother, of course, doesn't care either way; she's not interested in selling things, and enjoyed knitting. In the real world, of course, your grandmother can knit a sweater for each of her grandkids, and that doesn't affect the economy. But these days, it is possible for hobbyists to generate enough valuable information that it has economic effects.
Server-to-server is really hard, for a number of reasons: other networks don't have exactly same features or underlying concepts, routing between networks and back is tricky to do without introducing the possibility of loops, and it's hard to nail down exactly what everybody's server protocol is going to be forever.
People have problems with email-usenet gateways, and those are far more similar than IM networks. IRC, which was even designed for interoperability, is a number of detatched networks.
In any case, server-to-server requires that the server on the other end be interested in talking to you. The other networks aren't required to interoperate and they probably don't care; people get MSN accounts even if they have AIM accounts, so there's no motivation for MSN to constrain their servers to work with the AIM ones.
I believe you're misunderstanding my use of includes. I'm suggesting using them for two purposes: (1) read simple files out of each directory which explain the contents of the directory as a set of readable variable definitions and (2) share code and have loops and subroutines in a tight set of scripts written together.
Build variations should be refactored until they come down to, essentially, "which parts of the code do I build". Then, based on simple cues from the user, you can build the right things.
My non-recursive make is for a project which has about nineteen targets which are either binaries or libraries; the one which is build depends on which directory you invoke make from. There is a make target to make a distribution, which includes everything needed for the target in the current directory and can be build from the root of the distribution.
The scalability issue is not with the number of build variations but with the number of types of build variations. Having a lot of dissimilar build variations is just a mess, regardless of what you're using to build with.
I have it at http://iabervon.org/~barkalow/make.tar.gz if you'd like to take a look. Obviously, it's tuned to the way I have my project arranged, but it shouldn't be hard to apply the principles to another project. The "explanation" file is a bit out of date, in that the system actually does some of the wishlist items.
Having a lot of data is a good thing when reconstructing accidents. Being able to determine exactly what the driver was doing to the car will help to distinguish between skids where the driver was making it worse, skids where the driver didn't do much to help, and skids where the driver was doing the right thing and didn't recover control in time, all of which can leave about the same evidence on the road and car.
It's not useful to know everything the driver normally does without having the road conditions in extensive detail. There's no way the box is going to be able to tell what a safe speed is, whether someone is driving erraticly in response to other cars and pedestrians. Someone driving slowly could be driving in fog, following a bicycle, in traffic, reading signs and ignoring the road, or just stoned.
This data is only really useful in conjunction with scene evidence and other witnesses (except that you could easily tell where the kid took the car and when). You can't really use it to measure driving skill.
Optimizing light cycles could definitely help traffic flow. Of course, there are plenty of cities that are trying to make traffic go more slowly in places or have other desireable properties than just moving cars.
It's probably not a good idea, though, to have the system change in response to conditions, because people get used to the behavior of the traffic lights on their commutes, and so it's advantagous to have the lights be consistent.
I also think that you'd need a huge amount of sensors to do anything sensible with timings. Are only a few cars going through the intersection because, while there are a lot of cars coming that way, they don't have time in the cycle to all go through? Is it because they're stuck behind someone trying to turn left? Is it because they're trying to go into a street which is backed up into the intersection during that part of the light cycle? Is it because everyone is stuck at the previous intersection?
Optimizing traffic light cycles can help a lot of problems significantly, but I don't think there's really any substitute for having people actually go to the intersection and see what happens.
It would be very useful if they had tools for making a subversion repository from a CVS repository, keeping all the history, because people who are now using CVS won't want to lose their historical info. Since the features seem to be a superset of CVS's features, the only problem would be that the pre-subversion history would look odd where people did things to work around missing features.
Make is actually quite nice if you use a little trick: have only one Makefile. Have that Makefile include a file from each directory that contains variable definitions. That way, you separate the code from the data, meaning that you don't need to automatically generate the Makefiles (since you don't change them for each project and directory), so the Makefiles can be readable.
You can also do some really interesting things with conditionals and what amounts to iterative includes. I have a set of Makefiles totalling 315 lines which will accurately do exactly the steps needed to rebuild a program if any source file changes, regardless of which directory the file is in, and can be run from any directory in the tree. If nothing has changed, make says nothing except "'target' is up to date". It wasn't terribly hard to do.
I never figured out a way to get ant to reliably compile a Java project correctly. It uses the javac dependancy engine, which is specified in a broken way (the rules in the specification don't actually mean that compiling the classes it finds as needing recompilation is the same as compiling from scratch).
After using ant for a while at my work, we decided that it was the most common cause of people checking in broken code (which hadn't caused a problem for the author) and incorrect builds, and switched to make (with a python script to find java dependancies correctly).
The other problem with ant was (at the time, at least), there was no way to avoid running a program because it could be determined that it was unnecessary. This made trying to use EJB with a container that required an EJB compiler practically impossible, because we had a 20 minute build cycle, even when the ejbc step wasn't necessary.
Evidently, there is an early and temporary option in the JPEG spec that uses the Forgent-claimed methods. This means that JPEGs can use the patented methods, although people don't actually make such JPEGs in general. To avoid the patent, support for these would have to be removed. But the real point is that people might find it easier to pay Forgent rather than figure out what kind of JPEGs they've got.
If the city wants to modify the traffic pattern, they'd better not do it by changing 10,000 traffic light programs at the same time. What the city actually wants to do is identify trouble spots and change the traffic lights there or near there.
Traffic lights are programmable because they're all different. There is no sensible bulk update possible. If you're tweaking each set individually, you might as well send some guy over to change it.
Those are all different, though: your fridge could have sensors which detect all the things in it by RF tags to tell you what it needs, but the computer problem still wouldn't affect the cooling system, which doesn't have any reason to be connected.
Traffic lights and pacemakers don't need anything except clocks and sensors. You wouldn't want to make a larger-scale system, because that would be too hard to program-- it would be very difficult to avoid messing up the system even without attackers.
Will MicroSoft actually control .NET web services? I think it far more likely that people would stick with Apache (after all, it actually works and does everything you want for free, with a low TCO) than MicroSoft (I could use these features I couldn't use before, so long as I don't mind not being able to use anything I already have or can afford).
MicroSoft can't beat Apache in Apache's market: they can't undersell it, it performs as well, it's more popular, and has a better security record. So the fallback position is to make it desireable to run Apache on Windows and develop Apache web services on Windows. MicroSoft is also more interested in the client-side: if they can make IE integrate better with web services than any of the competitors, they'll maintain browser dominance, even if they don't control the servers. People do serve IE-specific pages on Apache, because those are both the most common applications.
MicroSoft tries to dominate every market they're in. They don't have to be in every market, including the "smart cheap people" market segments.