DJA wrote:
http://lxer.com/module/newswire/view/38971/index.html
I discovered the (previously posted) above link through Groklaw as I was
only vaguely aware of the LXer website. Given that, here is a follow-up
post to the post containing the above link. I include it here because
I'm interested in other's opinion on its content, and well, being the
holidays and such, the list is even slower than ever. Enjoy.
-------------------------------------
Read this and decide if Microsoft is still a monopoly
Authored by: artp on Thursday, December 29 2005 @ 10:48 PM EST
Trolls notwithstanding, non-monopolies do not wield this kind of power.
And people call me a Microsoft basher. After seeing this kind of
behavior for the last 23 years, why would someone NOT be a Microsoft
basher ??????
Great headlines (from memory, not guaranteed to be accurate on dates):
1976 - Gates accuses shareware authors of taking bread out of his mouth
1982 - Gates buys Seattle DOS using unethical tactics (common business
procedures)
1984 - Last chance to buy an IBM-compatible with anything but Microsoft
products installed, brief respite in 1992 for OS/2.
1984 - Gates perfects vaporware announcements to preempt competitors
shipping products
1985 - The Good Ship Windows crashes on its first shoal
1987 - Valuing appearance over performance puts Windows in factory and
data acquisition software
1992 - Appearance over performance put Windows in the BBS market
1993 - I am forced to use Microsoft products at work
1994 - Microsoft announces move into medical devices, control systems
and other real-time markets (never happened)
1995 - Large corporations start to enforce "corporate standards"
(Nothing But Windows)
1997 - Microsoft starts to penetrate the Data Center. Mysteriously,
metrics no longer are collected on Data Center performance in the
detail previously mandated.
2000 - Microsoft fails to make older systems Y2K compliant
2001 - Microsoft introduces SAN disintegration by use of its network
protocols, file handling, and registry file design.
2005 - More of the same.
Look at all the design principles that Microsoft has obsoleted by
pushing for their products:
1. Always separate programs and data.
2. Data collection and data display should run on separate processors
for deterministic performance (i. e. you can predict when it will
finish).
3. Display performance doesn't matter if the processor isn't generating
anything
to display.
4. Runaway control processes tend to finish catastrophically, e. g. they
kill
people as they blow up.
5. FDA standards for pharmaceutical and medical devices require that a
validated system can be built from scratch in a repeatable manner
from the documentation alone. All components are defined, and design
documents allow for the system to be rebuilt by any competent group.
[ The engineers blew up with the plant.]
6. Real-time systems require preemption.
7. A multi-tasking system requires that all processes are served fairly,
with provisions for stopping runaway processes that are hogging
resources.
8. Servers should be multi-tasking AND multi-user.
9, Total quality (TQM) requires vendors to be qualified according to
performance and meeting company purchasing standards.
10. Single-sourcing a material makes that vendor your partner. Be sure
you trust them.
Any questions ? Good. It is clear, then, that I am not a Microsoft
basher. I am just facing the facts. If you don't understand this, please
reread this message with an open mind.
If you still don't understand it, then ...
I am used to working in fields where design and implementation mistakes
can end up being either a) extravagantly expensive, or b) cause death
and destruction as they blow up. Things like severe service chemical
applications (ANSI B31.3 ?), nuclear and fossil power plants,
petrochemical plants, high pressure plastics production at 50,000 psi or
better, nerve gas incineration, safety shutdown devices, FDA validation
for pharmaceutical production, large scale UNIX installations, large
scale Data Center installations and so forth.
I like it when things work. Using the principles from the above
applications in smaller scale systems can make them more robust and more
reliable, if the scale is right.
Next question, please.
-------------------------------------
--
Best Regards,
~DJA.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
