Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Microsoft - The Evil empire -- Ignore unavailable to you. Want to Upgrade?

To: Tom Kearney who wrote (385)	12/4/1997 1:25:00 PM
From: Kal	Read Replies (1) \| Respond to of 1600

a wildass, out-on-a-limb opinion: if they re-write NT from scratch, the might have hope. Unix will stay there for quite some time.

To: Tom Kearney who wrote (385)	12/4/1997 1:46:00 PM
From: Robert Winchell	Respond to of 1600

Any MICROSOFT techies out there? What I'm interested in is: can MSFT solve the NT scability problem, and if so, when? The people that are working the hardest on this are Digital, I think. NT is supposed to run on machines with up to 32 processors, and while 3.51 was horrible and NT4 a bit better, it still isn't great. NT5 is supposed to be more scalable, but still not large scale (64+ processors). I think UNIX is quite safe for large scale (64+ processors) applications for the next couple years.

To: Tom Kearney who wrote (385)	12/4/1997 6:59:00 PM
From: cheryl williamson	Read Replies (3) \| Respond to of 1600

Tom, In my opinion, the real problem w/NT is that it is not optimized to work on a specific set of hardware. Those in marketing think that is just great, but we're talking about OS software, here, not applications. NT scales poorly because of their locking scheme. In addition, their thread libraries are not the exclusive property of user space, so new pid's have to be allocated whenever a new thread is opened. That requires a software trap into kernel space, which is relatively expensive. Check out Solaris if you want to know how locking should be done in mp systems. One thing to remember: when locking data you have to be absolutely certain that two separate threads do not write to the same data at the same time. In computing environments, latencies that are measured in micro-seconds are too indeterminate. Most locking, that is really effective, like mutex, relies on the hardware, which includes atomic instructions that won't allow data corruption on a write request. MSFT can't do that, because they don't write NT for any specific machine. However, NT is written to run mostly on PC's. PC's aren't powerful enough for enterprise systems. The point is, the only companies that have any business writing operating systems software for enterprise systems are those who manufacture the hardware to go with it. The assemblers, compilers, and OS's can be designed specifically to work with the hardware it runs on, and nothing else. Hardware design and implementation is the real key to optimal performance, not software, and as the hardware gets more and more sophisticated, you need software engineers to optimize your OS to take full advantage of it. Small differences in kernel design can make huge price/performance diferrences. MSFT doesn't really have the engineering talent to bring it off. That's why NT 5.0 completion dates have slipped again. They have a significant learning curve up in Redmond and it will take some time before they come up to speed. cheers, cherylw

To: Tom Kearney who wrote (385)	12/4/1997 9:46:00 PM
From: ahhaha	Respond to of 1600

I don't agree with your view about VMS. The market determines winners or losers, not DEC or anybody else. If you knew what VMS requires, you wouldn't be displeased with DEC for not pumping money into a archane OS. VMS took lots of overhead and had software incompatabilities that were mind boggling. Conversely, with certain dedicated tasks you couldn't find a better way to fly. I'm no fan of NT having gone through the vers. 3.xy - 3.51,and then ending up with 4.0 which I threw out for WIN95! I was developing standalones in the envs. of VC++ and VJ++. 3.51 had the best chance of convergence with Windows-DOS for local writes. For my applications 3.51 was appropriate and much better than alternatives. I have to admit that the registry in WIN95 is inferior. The 4.0 strategy is obviously going in a different direction---server. NT 4.x is a good server, and the right strategy with this antiquating architecture. The process/data independence or kernel isolation aspect of it, surely isn't antiquating. I don't agree about the dual processor mode or lack of scalability. This was kicked around years ago. Processor scalability is significant if you're computation intensive, but then you use UNIX. That use is very narrow, not a business issue. On-board microprocessor solutions to computing muscle problems are too complex to coordinate efficiently. There really is no need to processor scale NT for its intended markets. I'm sure you're aware of roomfulls of servers interacting with the outside and with each other. It's cheaper and easier to scale in such a distributed manner even if it isn't optimal.