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 : How high will Microsoft fly? -- Ignore unavailable to you. Want to Upgrade?

To: keithsha who wrote (12051)	11/4/1998 10:52:00 PM
From: ToySoldier	Read Replies (2) \| Respond to of 74651

Keithsha, Please stop flicking these silly little tidbits on "how to crash a NW server" because a MSFTer should learn not to throw stones when they live in a glass NT house. If you want to bring a production NT server out of production - just make a configuration change of any kind! "Its time for a reboot! Just apply the latest SP4 patch to NT and its time for a system crash. Just let NT sit long enough on its own and its time for a reboot. NW and your SYS volume being full and freezing the server, one must be pretty stupid to have this error occur (oops, I guess you must have accomplished it since you knew all about it). That would be like knowing your crossing a long desert highway and going on an empty tank of gas. NW servers that get abends can trap them and continue operating. NT server that crash - CRASH! BTW - nowhere did I ever say that a protocol constitutes an OS. As for your "NetWareOS remains the same" statement...there is nothing that can be said to change your statement - MSFT has brainwashed you way too deeply on that. So you keep living your little lie. Modesto - NW6 is primarily being developed to be ready as a 64 bit OS when Intel releases the chip. Its got nothing to do with the garbage your spreading. Exactly when will NT7,8,9 have a 64bit OS? It is taking them 2+ years beyond the due date just to get NT5 out the door. And even then it will be a stripped down version in order to get something out the door. Every few weeks the industry reports yet another few services and features that MSFT has admitted they will be removing from the intial NT5. NetWare 4.x is already substantially more efficient than NT4. NW5 is even faster. NW6 which, unlike MSFT, will be ready upon the release of the Merced chip will run circles around NT5 - if its even out by then! LOL (Again NT is named Windows 2000 for a reason - that will be when its finally released). NW5 can allow clients to login using SLP, DNS, or IP-addresses. Active Directory uses nothing because until its actually released onto the market as production - no one knows what Active Directory will or will not have! But if it remains as a DNS as a service locator then thats just another limitation of Active Directory and NT. Its too bad that NT5 will rely on a STATIC name database to locate its servers. That is why NW5 uses and sat on the SLP RFC committee to flesh out its development. SLP is a dynamic service locator protocol. If a Server goes off-line in the NT world, your poor DNS-based system will not know about it. Likewise - if a new NT service goes on-line, no clients will know about it until someone changes the static DNS database. So I am glad you pointed that out for all of us. I also like your statement that IDNS is "compatible with DNS RFCs 1034 and 1035". So why would MSFT not use the straight complete standard RFCs themselves. Why did they have develop a "Compatible" solution? I'm sure many of us know why - another form of a MSFT trap to tie its poor users into some obscure proprietary system. NDS needs to learn absolutely nothing from Domains! Domains are the joke of the computer industry. And if you think otherwise, then look around buddy! Even die-hard NT biggots agree that Domains are a weakness of NT. If they were so great then why is MSFT trying to make sooo many major enhancement in the release of Active Directory? Enhancements that are meant to try to equal the functionality of NDS. You still did not answer how NT4 communicates with each other and its clients. Come on, say it, tell us all how Netbios is required. And tell us how Netbios will be around to plague NT5 as well. Funny that it was MSFT that used to throw stones at NOVL for using chatty RIP/SAP in IPX and yet now the only one that still has to rely on an 70's chatty protocol is NT. Lots of nice talk Keithsha, but NT4 is and NT5 will be based on 80's domain technology and 70's protocols. The most hypocritical statement is to call NT5 Windows 2000 based on the technology that it will be based on. Toy

To: keithsha who wrote (12051)	11/5/1998 12:04:00 AM
From: ToySoldier	Respond to of 74651

Just one clear case study example of why Active Directory WILL NOT WORK for medium to large scale organizations. I know Keithsha that you will just close your eyes and change the topic, but the rest will get an understanding of the severe limitations that Active Directory will encounter... Case Study: Building an Enterprise ACME Corporation requires an enterprise directory service. ACME Corporation is a medium-sized customer, with 5000 users and workstations worldwide. Three thousand users are located in the company's home office, while the remaining 2000 users are spread evenly across 100 remote offices. Each remote office is connected to the home office by a 56kbps WAN link. There are 100 servers located at quarters, and 1 server at each of the 100 remote offices (200 servers total). What are the implications of deploying a single, large Active Directory domain? How would NDS solve this problem? Active Directory Design: Create a single domain that includes all 5000 users. To ensure that users in the remote offices may login when the WAN is unavailable, replicate this domain to all servers in each of the 100 remote offices. Not every server in the home office requires a copy of the domain, so place the domain on 10 servers in the home office. (see figure) Implications of this design: Domain database size - Five thousand users and five thousand workstations will easily create a domain database in excess of 100 megabytes. This domain database is replicated to every domain controller. Every domain controller must have sufficient disk space and backup capacity to handle the large domain requirements. And, since the domain database will continue to grow with day-to-day management, ensure that there is sufficient disk resources to handle future domain database growth. Installation-When Active Directory is installed on the server in the remote office, the entire 100 megabyte database must be copied across the slow, 56kbps WAN link. On average, a 56kbps WAN link can transfer approximately 6.5 kilobytes per second, or 390 kilobytes per minute. Transferring the 100 megabyte domain database will take at least 4.3 hours, assuming that 100% of the link is available for the NT5 server install. Domain replication-For simplicity sake, assume that a simple password change generates 10 kilobytes of domain replication traffic. Since the entire domain is replicated onto 110 servers, every password change must be sent to all 110 servers, resulting in 1.1 megabytes of network traffic per password change. If just 2% of users change their password on any given day (100 users a day), this will generate approximately 110 megabytes of domain replication traffic. NDS DESIGN Create a single NDS tree with organizational units that represent the home office and each of the remote offices. To ensure that users in the remote offices may login when the WAN is unavailable, designate each remote office organizational unit as a NDS partition. Place NDS replicas of the 100 remote offices on two NDS servers in the home office. NDS database size-Each remote office only contains the objects required by the remote office - the twenty users and their workstations. With this efficient design, the NDS database is less than 800 kilobytes in size. Installation-Each remote office directory server only holds the objects required by that remote office. During installation, only 800 kilobytes of data is copied across the WAN link, which takes less than three minutes over a 56kbps WAN link. Directory replication-For simplicity sake, assume that a simple password change generates 10 kilobytes of directory replication traffic. Since there are only three replicas (or copies) of every partition, this change is only sent to three servers. Therefore, changing a password will create as little as (10 kilobytes x 3 server replicas) 30 kilobytes of network traffic. If just 2% of users change their password on any given day (100 users a day), this will generate approximately 3 megabytes of NDS replication traffic. I know Keithsha is banned by MSFT policy from reading competitor whitepapers, but the rest of you might want to read the following web site to get an understanding why Active Directory will not be successful compared to NDS until it bites the bullet and drops the Domains underpinnings... novell.com As for your bragging about Active Directory and the use of DNS. Well read this site to understand in more detail why MSFT' DNS reliance will fail on them and compare it to NDS's current solution that is succussful NOW! novell.com Keithsha, read and study these pages in detail - then tell us all which directory service will be successful. LOL Toy