You too are welcome.
My opinion on the NC thing is this: NCs are *not* designed to replace PCs. NCs are designed to replace VT220 and 3278 (and the like) dumb terminals. However, for some time, PCs themselves commonly have been (mis)used as VT220 and 3278 terminal replacements, in part because there wasn't any other viable alternative that provided a somewhat graphical interface. Thus, to the extent that NCs wind up being used for these kinds of functions, then they would in a sense be taking sales away from the PC marketplace. But those are the sales that PCs had the most tenuous hold on anyway. Those were opportunistic sales, and were ripe to be plucked by someone with a more cost-effective solution.
There is no good reason, when you think about it, that a cashier at a bookstore needs a PC. An NC would be a much better solution. Similarly for shipping clearks, librarians, etc. If the device is only serving to update and/or query back-end databases, then a PC is probably overkill. However, if a PC is being used to crank out a 1000-cell spreadsheat recalc, or render 3D images, then an NC does not seem a reasonable replacement.
As for the NT server question, we use NT servers only to the extent that we have to; generally, they are a pain in the behind and not worth their cost... I would hesitate to say, at least in the context of my particular situation, that they pull their own weight, especially when you toss in the support costs.
The reasons that we *have* to use NT servers is so that we can run the NT Workstations without extensive modification to the operating system. In particular, our NT Servers are used for authentication services (we use NT Domain Controllers) file storage services, print services, etc. We run a couple of SQL servers, but no one uses them much. We also run an SMS server to help in software distribution and hardware inventory.
The SMS server is a prime example of pain-in-the-behindness. We set it up for the first time in early 1996 on a Dell P90, when we were first setting things up. By late 1997, we needed to upgrade the server to NT 4.0, SMS 1.2 and SQL Server 6.5. In the process, we wanted to upgrade to a new hardware platform -- we are assembling our own PCs, both desktop and server, from COTS FRU-level parts [since our NT Server requirements are pretty limited, there is no need for things like 6x6 ALRs], and we were building all of our servers out of Intel 82430HX-based dual-processor Pentium boards from Giga-Byte. As it turns out, SMS was not designed to allow for a hardware upgrade (!?#%$). The *only official way* to build an NT system is to start from the setup CD. And when you start from the setup CD, NT gets built with a uniqe system identifier ("SID"). SMS codes that SID for its server platform somewhere deep in its bowels, and it will not work correctly if you dump the database and reload it to a new machine. We had three senior Microsoft engineers on a conference call with us to tell us in explicit, non-negotiable terms that this was true. The problem was exacerbated by the fact that we were moving from a uniprocessor to a dual-processor system; these use a different hardware abstraction layer underneath the NT kernel, and thus even if we reloaded the OS (against Microsoft's policy anyway) to the new hardware platform, it would never recognize the additional CPU (there used to be a way to swap HALs after install, but that was lost in the upgrade to 4.0). Thus, we had to completely de-install all vestigages of SMS from every NT machine on our network (over 100 systems at that point) and then re-install SMS on the new platform. Given that I had previously concluded that every ounce of Microsoft's being was dedicated to forcing constant hardware upgrades, this came as a tremendous shock.
Another big trouble I have with NT is that it is not just obscure, it seems *deliberately* obscure. There are things that seem perfectly obvious for someone to want to do that are impossible only because either Microsoft hasn't provided an interface, or because they haven't documented the interface that exists. You go looking through the knowledge base for a solution to your problem. The solution to the problem turns out to be to "edit the registry". Then there's this multi-paragraph disclaimer about how you really shouldn't ever mess with the registry and that if you do so it is at your own risk. We pay for a support contract and call them with a question about the registry, and they tell us that they don't answer those questions.
I'm typing this on an NT workstation in my home, where I use IE 4.01 (despite everything I've ever said about MS, I still think that IE 4.0x is the best browser I've ever used, and Outlook 97 -- the version that comes with Exchange Server 5.5 -- is the best mail client; at work, they won't let IE through our firewall, so I use Netscape), and I recently wanted to rebuild the OS on this machine. So I started with the NT 4.0 install. Then I wanted to get IE 4.01 up. IE 4.01 won't install without service pack 3. So I tried to download the 128-bit version of service pack 3 from www.microsoft.com, but IE 2.0 (which installs as part of NT 4.0) was too broken to handle those web pages. So I installed the 40-bit service pack 3 and IE 4.0 from CD and tried again. I downloaded the 128-bit SP3 and installed it, but it gave me grief about files that were newer, so I told it not to overwrite. Then I installed 4.01, and allowed it to update "only files that are newer". Needless to say, everything was at that point hopelessly broken; it simply refused to browse to any https:// URL, even though Schannel.dll was the right rev. In the end, I had to go back to re-install the 128-bit SP3, force it to replace everything, and then re-install IE 4.01, again telling it to replace everything. Now it works fine. If you look at the readmes, SP3 says that you have to reinstall the service pack if you add any componants, and IE 4.01 says to never install SP3 over IE 4.01. I do this stuff for a living, and I seriously wonder how anyone who doesn't ever figures this stuff out.
So clearly, in my mind, the entire NT thing must be fundamentally and hopelessly broken. Microsoft is moving so fast and is so distracted by all the fireballs being lobbed in their direction that the bondage and discipline approach to system configuration seems to be the only way that they can keep the whole thing from total and utter collapse. NT 5.0 is supposed to be bigger (in a measure I don't recall) than OS/MVS. It is something like 30 million lines of code, the majority of which are new since NT 4.0. Maybe 90% of NT 4.0 works the way it is supposed to (my estimate) and here they are more than doubling its size?
We have about 150 Sun machines, and most of them only ever have to be shut down and restarted because our building people need to shut the power off. I would much rather just continue to use these and the NT workstations. But as clueless as Microsoft seems to be about the needs of an organization like ours, Sun remains just as blind as to how PCs are used and why people want to use them. It is possible to trash the NT servers and just use either PC-NFS or TotalNet. But those products cost piles of money, and they are anything but unobtrusive from the NT perspective. We use Samba (a free SMB server for Unix) for sharing Unix files to NT clients. Samba is a fantasticly functional product and does almost everything we need. But what it doesn't do is allow users to directly control the access control list for a Unix file from the NT platform... you have to go to a Unix shell to change the permissions on the file. If the files are on an NT server, then you can change the access control list from Explorer or from File Manager. Also, if you define printer shares on an NT server, then when an NT Workstation client prints through that share, the printer driver is automatically downloaded to the workstation. There is no way, at present, to do that without an NT Server.
So we have to run these NT servers if we want our NT workstations to be reasonably functional and to have lives outside of work. But among the most frustrating aspects of NT servers is that they provide no general purpose command-line. Thus, when a server isn't dumping files or authentication credentials or whatever out onto the wire, it just sits there. I know that this isn't the case for a lot of more NT-centric organizations, but for us it is an issue; remember that we have CPU-hungry economists ready to pounce on a computer system any time it slows down enough to be caught (an overstatement, but...).
But it does drive our users nuts when they see a machine that isn't doing much of anything. I have toyed with the idea of using IIS as a command line; the users could copy the executable code up to the NT server along with an html page that calls it. Then they could browse to the URL and the NT server would run the code. It seems worth a try, anyway. :-) |
