You state that MS was "convicted" (your expertise is slipping) of leveraging their desktop OS to gain an advantage in the server OS space but you don't provide any evidence that indeed they did. How much market share did competing products lose? Is MS now the market leader in Sever OS's? Have they ever been?
This is about preserving the status quo in the server space, to reduce competition by holding back MS. It's not about increasing competition it's about decreasing it.
Nice attempt to deflect based on the idea that I'm not qualified to speak.
"gaining an advantage" against a competing product is quite different than "eliminating" one. But in some cases there isn't much evidence even for the lesser charge. What server OS's have MS gained an advantage over because they dominate the desktop and how was it done?
"Which is wholly beside the point. Having gained a monopoly in one field (nominally) legally, they then used that monopoly to eliminate competition in other areas."
OK, so they are dominant in one area - the desktop OS market. Now which competitors have they eliminated and what specific MS actions caused that elimination?
Why is there this implicit assumption that it is the engineers that lack the communication skills and not the decision makers?
Further, it is well understood that managers are more sensitive to political pressure than engineers and thus have a tendency to be biased against an unpopular decision.
This communication defense just smells like an excuse to blame the Indians and spare the Chiefs.
Actually part of the reason for NASA's problems is that they politicized their risk calculations to show that the Shuttle was several orders of magnitude safer than the data actually indicated.
They also had pressure from the Reagan Administration to keep on schedule.
The communication skills of the engineers were not a factor in these causes. Also note that if there had not been public hearings we would most likely never learned what the real problems were. If the engineers concerns had been aired in public before the flight, it is likely that the launch wouldn't have taken place.
Communication skills in engineers can be important, but it wasn't a factor in the Challenger disaster.
Wikipedia isn't always the best source. Real time isn't really about latencies - it's about operating within timing windows. In real time systems being early is no better than being late.
Although there's no absolute criteria, hard real time software has to consistently operate within timing windows that are approaching the accuracy limits of the CPU. The hardest real time software is that which must be accurate and consistent down to a single CPU cycle.
That's pretty much impossible on a PC unless you can turn off all the caching etc that make the behavior time-varying rather that consistent.
Fortunately early processors like the 6507 (6502 variant) were predictable and thus some Atari 2600 games could (and had to) be controlled to a single CPU cycle.
The fact that they are buying the company just underscores the financial motivation. Sounds like a great deal for the Sir Lankan owners too - if the project fails it's the new owner's problem - their money is already in the bank.
Yeah, I don't get the lens flare fetish. If there's a lens flare they should show some poor sucker floating in space with a camera. External shots are to move the story along, they shouldn't make you think about how it would be filmed if it were real.
You mean that if a character doesn't proclaim he's gay in the pilot, he can't be one? Something like "Wait, I'll use my gay powers to repair the life support".
Why is it in a discussion of shared code that the value of fixing a bug in only one place is always mentioned but not the impact of creating a bug in one place and having it screw up a lot of different applications?
If you want to discuss "sound programming practices" than by all means begin.
Perhaps you could start with explaining how the optimizing feature of dlls outweigh the risks of coupling unrelated applications in light of the significant memory and disk resources that are available in modern computer systems.
Slashdot Mirror
It's like you can't answer the question.
You state that MS was "convicted" (your expertise is slipping) of leveraging their desktop OS to gain an advantage in the server OS space but you don't provide any evidence that indeed they did. How much market share did competing products lose? Is MS now the market leader in Sever OS's? Have they ever been?
This is about preserving the status quo in the server space, to reduce competition by holding back MS. It's not about increasing competition it's about decreasing it.
Nice attempt to deflect based on the idea that I'm not qualified to speak.
"gaining an advantage" against a competing product is quite different than "eliminating" one. But in some cases there isn't much evidence even for the lesser charge. What server OS's have MS gained an advantage over because they dominate the desktop and how was it done?
"Find someone who understands what you're about, and use their service instead."
Probably Google since they know more about you than any other web entity.
"Which is wholly beside the point. Having gained a monopoly in one field (nominally) legally, they then used that monopoly to eliminate competition in other areas."
OK, so they are dominant in one area - the desktop OS market. Now which competitors have they eliminated and what specific MS actions caused that elimination?
Why is there this implicit assumption that it is the engineers that lack the communication skills and not the decision makers?
Further, it is well understood that managers are more sensitive to political pressure than engineers and thus have a tendency to be biased against an unpopular decision.
This communication defense just smells like an excuse to blame the Indians and spare the Chiefs.
Actually part of the reason for NASA's problems is that they politicized their risk calculations to show that the Shuttle was several orders of magnitude safer than the data actually indicated.
They also had pressure from the Reagan Administration to keep on schedule.
The communication skills of the engineers were not a factor in these causes. Also note that if there had not been public hearings we would most likely never learned what the real problems were. If the engineers concerns had been aired in public before the flight, it is likely that the launch wouldn't have taken place.
Communication skills in engineers can be important, but it wasn't a factor in the Challenger disaster.
Well, it's nicely symmetric since we don't know the whole story on how this all started either.
They're losing out on a lot of free money from MS. Perhaps they can suck from Intel's teat now.
In such a scenario which is more useful, the ability to write a good essay in English or good knowledge of mathematics?
Gee, and I thought the primary communications medium in science and engineering was mathematics.
As in a job interview, the criteria for accepting an applicant for college isn't going to reliably measure potential, ability, or intelligence.
It's really a crap shoot hidden behind a facade of plausible but ineffective practices.
Wikipedia isn't always the best source. Real time isn't really about latencies - it's about operating within timing windows. In real time systems being early is no better than being late.
Although there's no absolute criteria, hard real time software has to consistently operate within timing windows that are approaching the accuracy limits of the CPU. The hardest real time software is that which must be accurate and consistent down to a single CPU cycle.
That's pretty much impossible on a PC unless you can turn off all the caching etc that make the behavior time-varying rather that consistent.
Fortunately early processors like the 6507 (6502 variant) were predictable and thus some Atari 2600 games could (and had to) be controlled to a single CPU cycle.
If you think applications like this are examples of "hard RT", then the "RT" you refer to doesn't stand for "Real Time".
The fact that they are buying the company just underscores the financial motivation. Sounds like a great deal for the Sir Lankan owners too - if the project fails it's the new owner's problem - their money is already in the bank.
It sounds to me like the change was due to a lower bid from a particular Sri Lankan company and not really about technology primarily.
Yeah, I don't get the lens flare fetish. If there's a lens flare they should show some poor sucker floating in space with a camera. External shots are to move the story along, they shouldn't make you think about how it would be filmed if it were real.
You mean that if a character doesn't proclaim he's gay in the pilot, he can't be one? Something like "Wait, I'll use my gay powers to repair the life support".
At least Eli looks like a real geek unlike Dr. Jackson who looks like a leading man when he takes off his glasses.
No, but it is as annoying as people who use "he" as a gender-neutral pronoun in a desperate act to appear manly.
iTunes is great if you're watching the video on some kind of iPod, but the quality isn't competitive for desktop viewing.
Yes, but if it's only copied and pasted 299 times..
Seriously, sharing or not sharing code is always a trade-off. If you don't see that I really can help you - I just did.
Why is it in a discussion of shared code that the value of fixing a bug in only one place is always mentioned but not the impact of creating a bug in one place and having it screw up a lot of different applications?
"The very fact that you're here reading Slashdot means it's likely that you do not suck."
I see it more like this: "The very fact that you're here reading Slashdot means it's likely that you think most programmers suck."
One's personal suckness is still an open question.
If you want to discuss "sound programming practices" than by all means begin.
Perhaps you could start with explaining how the optimizing feature of dlls outweigh the risks of coupling unrelated applications in light of the significant memory and disk resources that are available in modern computer systems.