谈谈你的看法

看看这篇文章
http://www.linuxeden.com/edu/doctext.php?docid=1726

谈谈你的认识。

谈谈Linux和Windows的体系结构的优缺点，要客观的，公平的。

有空看看这种文章，这才是分析问题。
April 1999   |   Mark Russinovich   |   Features   |   Instant Doc #5048

Linux and the Enterprise


Is this OS ready for enterprise prime time?
In \"Windows NT vs. UNIX: Is One Substantially Better?\" (December 1998), I included a sidebar titled \"Linux and the Enterprise.\" This sidebar discussed the Linux kernel\'s shortcomings, including the lack of kernel-mode threads and the use of non-reentrant kernel code that affects Linux\'s ability to scale on multiprocessor systems. The Linux community\'s response to the sidebar has been vociferous, and most of the email I received contains two assertions: Linux does have kernel threads, and Linux 2.2 will remove multiprocessor scalability limitations. Although these assertions are true to a certain extent, significant problems with kernel threads and multiprocessor scalability in Linux 2.2 will prevent it from competing head to head with NT and Linux\'s UNIX cousins for enterprise applications. In this article, I\'ll describe several key areas in which Linux lacks maturity. I\'ll also discuss some powerful features that other OSs, including UNIX variants and NT, have adopted to improve scalability.

Let me state clearly at the outset that I don\'t intend to bash Linux in this article, nor do I intend to proclaim NT\'s superiority to Linux. I base the information I present on a thorough study of Linux 2.2, including its source code. I hope that by revealing these problems, I will encourage Linux developers to focus on making Linux ready for the enterprise. I also want to dispel some of the hype that many Linux users have uncritically accepted, which has given them the false impression that Linux is ready for enterprise prime time.

What Does \"Enterprise-Ready\" Mean?
Before an OS can compete in the enterprise, it must deliver performance levels on network server applications that rival or exceed the levels that other OSs achieve. Examples of network server applications include Web servers, database servers, and mail servers. OS and hardware vendors typically use results from industry-standard benchmarks such as Transaction Processing Council (TPC)-C, TPC-D, and Standard Performance Evaluation Corporation (SPEC) SpecWeb to measure proprietary OSs or hardware against other vendors\' products. Vendors spend millions of dollars on benchmark laboratories in which they tune, tweak, and otherwise push state-of-the-art hardware and software technology to the limit. Enterprise customers, in search of a computing infrastructure that provides maximum capacity, often turn to benchmark results for guidance, and OS and hardware vendors holding benchmark leads take great pride in being king of the hill at any given time.

Thus, competing in the enterprise means removing every performance impediment possible. Overlooking even the smallest drag will create an opening that a competitor can drive through to obtain a valuable lead on a benchmark. What complicates the science of engineering an OS for the enterprise is that an OS might have subtle design or implementation problems that don\'t adversely affect performance in casual desktop or workgroup environments. Yet these problems can keep the OS from achieving competitive results in an enterprise-class benchmarking environment. A typical enterprise-application benchmarking environment includes dozens of powerful multiprocessor computers sending requests as fast as they can over gigabit Ethernet to an 8-way server with 4GB of memory and hundreds of gigabytes of disk space.

Efficient Request Processing
Network server applications typically communicate with clients via TCP or UDP. The server application has either a published or well-known port address on which it waits for incoming client requests. When the server establishes a connection with a client or receives a client request, the server must then process the request. When the server application is a Web server, the Web server has to parse the HTTP information in the request and send requested file data back to the client. A database server application must parse the client\'s database query and obtain the desired information from the database.

For a network server application to scale, the application must use multiple kernel-mode threads to process client requests simultaneously on a multiprocessor\'s CPUs. The obvious way to make a server application take advantage of multiple threads is to program the application to create a large pool of threads when it initializes. A thread from the pool will process each incoming request or series of requests issued over the same client connection, so that each client request has a dedicated thread. This approach is easy to implement but suffers from several drawbacks. First, the server must know at the time it initializes what kind of client load it will be subject to, so that it can create the appropriate number of threads. Another drawback is that large numbers of threads (an enterprise environment can produce thousands of simultaneous client requests) can drain server resources significantly. Sometimes, resources might not be adequate to create all the threads the application wants to create. Furthermore, many threads actively processing requests force the server to divide CPU time among the threads. Managing the threads will consume precious processor time, and switching between competing threads introduces significant overhead.

Because a one-thread-to-one-client-request model is inefficient in enterprise environments, server applications must be able to specify a small number of threads in order to divide among themselves the processing for a large number of client requests. Where this client-multiplexing capability is present, no one-to-one correspondence between a thread and a client request occurs. Neither does a one-to-one correspondence between a client request and a thread occur―one thread might share a client request\'s processing with several other threads. Several OS requirements are necessary for a client-multiplexing server design to be feasible. The first requirement is that a thread must be able to simultaneously wait for multiple events: the arrival of a new client request on a new client connection, and a new client request occurring on an existing client connection. For example, a Web server will keep multiple browser connections open and active while accepting new browser connections as multiple users access a Web site the server manages. Connections between a browser and the server can stay open for several seconds while large files transmit over a connection, or while the browser requests multiple files over the connection.

The second requirement is that the threads must be able to issue asynchronous I/O requests. Asynchronous I/O is an OS-provided feature whereby a thread can initiate I/O and perform other work while the I/O is in progress―the thread can check the I/O result at a later time. For example, if a server thread wants to asynchronously read a file for a client request, the thread can start the read operation and wait for other client requests while the read is in progress. When the read completes, the system notifies a thread (not necessarily the thread that began the read operation) so that the thread can check the I/O\'s status (i.e., success or failure) and whether the I/O is complete.

Without asynchronous I/O, a thread initiating an I/O operation must wait while the operation takes place. This synchronous I/O causes multiple-client-per-thread server designs to perform poorly. Because such server designs designate limited thread pools, taking threads out of commission to perform I/O can lead to a situation in which no threads are available to accept new client requests or connections. In such a case, a multiprocessor\'s CPUs might remain idle while client requests sit backlogged. Worse, the server might never have a chance to service client requests, because the client might stop waiting for the server. Figure 1 contrasts asynchronous and synchronous I/O.

Linux and Request Processing
Unfortunately, Linux 2.2 doesn\'t satisfy either client-multiplexing server-design requirement: Linux 2.2 cannot efficiently wait for multiple events, and it doesn\'t support asynchronous I/O. Let\'s look more closely at each of these concerns.

Linux provides only one general API to server applications that want to wait on multiple requests―the select API. Select is a UNIX system call that has been present in every UNIX release since the OS\'s initial development. Select is one of the OS interface functions that has become part of the POSIX standard for UNIX API compatibility. One reason that the Linux select implementation is not an acceptable function for waiting on multiple events is that the system uses select to notify all threads that are waiting on the same event whenever the event occurs (e.g., the arrival of a request from a new client). Notifying multiple threads in this way degrades server performance: Only one thread can handle the new request or connection, and the other notified threads must return to a state of waiting. In addition, synchronization causes overhead as the threads agree among themselves which one will service the request. Other secondary overhead results when the OS divides CPU time among the threads it has needlessly notified. This kind of limitation forces a network server application to designate only one thread to wait for new incoming client requests. This thread can either process the new request itself, waking up another thread to take over the role of waiting for new requests, or the original thread can hand the request off to a waiting thread. Both alternatives add overhead, because every time a new client request arrives, the waiting thread receives notification and must then notify another thread.

If Linux provided some additional application support, the OS could wake up only one thread. For example, an application could specify that even though multiple threads are waiting for a particular event to occur, the application wants only one of the threads to receive notification for each occurrence of the event. NT provides such support for its waiting functions (NT server applications do not typically use select, although NT implements the select call for compatibility with the POSIX standard) to allow multiple threads to efficiently wait for incoming client requests.

Select suffers another serious problem: It doesn\'t scale. A Linux application can use select to wait for up to 1024 client connections or request endpoints. However, when an application receives notification of an event, the select call must determine which event occurred, before reporting the event to the application. Select uses a linear search to determine the first triggered event in the set the application is waiting for. In a linear search, select checks events sequentially until it arrives at the event responsible for the notification. Furthermore, the network server application must go through a similar search to determine which event select reports. As the number of events a thread waits for grows, so does the overhead of these two searches. The resulting CPU cost can significantly degrade a server\'s performance in an enterprise environment.

NT incorporates a unique feature known as completion ports to avoid the overhead of searching. A completion port represents a group of events. To wait on multiple events, a server associates the events with a completion port and waits for the completion port event. No hard upper limit exists on the number of events a server can associate with a completion port, and the server application need not search for which event occurred―when the server receives notification of a completion port event, the server also receives information about which event occurred. Similarly, the kernel doesn\'t perform searches, because the kernel knows which events the system associates with specific completion ports. Completion ports simplify the design and implementation of highly scalable server applications, and most enterprise-class NT network server applications use completion ports.

Linux 2.2 introduces a new mechanism that lets network server applications request notification of certain events in a more efficient way than select. A Linux server thread marks a communications endpoint as a notification endpoint; any new connections a client establishes through that endpoint cause the system to notify the application―the thread doesn\'t wait for the event. Furthermore, when such an event occurs, the kernel tells the application precisely which event is occurring, thus eliminating the searching that select requires. Unfortunately, this feature has two major limitations. First, the feature applies only to particular communications endpoints (TCP/IP and TTY devices) and events related to a new client connection―this mechanism does not notify a server thread of new requests over existing connections. Second, just as for select, the kernel wakes up all threads waiting for a new client request event―not just one thread, as efficient server applications require.

Linux fails to meet the second requirement for supporting scalable server applications because the OS currently has no asynchronous APIs. If a Linux server thread initiates an I/O request, the thread can\'t perform any useful work while the I/O is in progress. Instead, the thread waits.

Many Linux developers mistakenly believe that the existence of a form of I/O in Linux known as nonblocking I/O means that Linux supports asynchronous I/O. An application that requests nonblocking I/O can attempt to read from a network connection, for example, and the application doesn\'t wait until data is available on the connection before the application continues executing. A major difference exists between Linux nonblocking I/O and true asynchronous I/O, however: An application performing a nonblocking I/O call does not initiate an I/O operation if the I/O cannot be immediately satisfied. If the application wants to initiate I/O, the application must issue the I/O request when I/O is possible.

A quick example illustrates nonblocking I/O. If a server thread performs a nonblocking read from a network connection and no client data is ready on the connection, the server thread will not wait for data to become available. Instead, the thread can perform other work. However, the thread must issue further read operations until data is ready on the connection. By contrast, a server thread that issues an asynchronous read actually initiates a read I/O but can also perform other work without issuing additional reads. The OS notifies the thread when client data arriving at the connection can satisfy the issued request.

Overscheduling
Even in a network server implementation that has a small pool of threads that share the processing of new client connections and client requests, the syndrome overscheduling can adversely affect server performance. If a server thread takes a client request and actively uses a CPU to process the request, and the server starts processing another client request on the same CPU, both threads will compete for CPU time. This situation introduces overhead when the OS switches between the threads to give each access to the processor. The higher the number of threads that actively compete for CPU time, the worse the overhead problem becomes. The goal of a high-performance server application is therefore to have as few threads competing for the CPU as possible. To achieve this goal, the application requires OS support.

The OS must make it likely that only one thread will process a request at a time, and that when that thread finishes with the request, the OS will choose the same thread to process the next request. Such support prevents a situation in which the thread finishing a request goes back to waiting while the OS launches another thread to handle the next request. A network server application that achieves this support will almost never have overhead that the OS scheduler causes when it switches the CPU among multiple threads.

To achieve this support, the OS scheduler must keep track of which server threads are active and which threads are waiting for events. NT integrates this knowledge into its completion ports and uses completion ports as gateways for threads to use the CPU. (Figure 2 shows an example of a completion port.) If a server thread begins processing a request after receiving notification from a completion port, the scheduler will not notify any other threads waiting on that completion port for client requests until the processing thread voluntarily gives up the CPU, usually by blocking on I/O. If the active thread finishes its processing without giving up the CPU and waits for another event at the completion port, the scheduler will immediately notify that thread of the next waiting request, and the thread will continue running. If a thread gives up the CPU while processing a request―for example, while it waits for some other event not associated with the completion port (such as transmitting a very large Web response)―the scheduler will notify another thread waiting at the completion port of the next client request. This thread-throttling mechanism helps the server application minimize the number of actively scheduled threads and get the most out of a CPU.

Without thread-throttling support in the Linux scheduler, Linux server applications must rely on less-precise methods in their application code to try to achieve the same goal. However, these Linux applications will not realize performance benefits to the extent that NT applications do with NT scheduler support.

Kernel Reentrancy
The Linux community heralded Linux 2.2\'s recent release as Linux\'s coming of age in the multiprocessing world. One big reason for this jubilation is that in Linux 2.2, parts of the kernel are reentrant. A reentrant kernel function is a function that can simultaneously execute on multiple CPUs in a multiprocessor. If one CPU is executing a non-reentrant function, another CPU wanting to execute the same function must wait until the first CPU is finished. This effect is known as serialization, because the two CPUs\' execution of the function is sequential if viewed on a timeline, as Figure 3, page 98, shows. Serialized execution defeats the advantages of multiprocessor execution, because the non-reentrant functions execute as if they were on a uniprocessor.

Linux 2.2 is more reentrant than previous versions of Linux were. However, several major Linux functions are still not reentrant. These functions include read and write, the two most common functions network server applications use. A Linux server application will read client requests from a communication endpoint, read data from a file (such as a Web file or email database) to respond to the requests, and write the file to the client via the communications endpoint. Even if the data requested from the client is in a memory cache and a read from a file is not necessary, the write paths still serialize.

Figure 3 demonstrates the difference between the execution of a non-reentrant function and that of a reentrant function. In the top half of the figure, the kernel spends time waiting for both CPUs to execute the non-reentrant function; in the bottom half of the figure, the kernel doesn\'t spend time waiting for the reentrant function. The OS in the bottom half of the figure finishes executing the same code sooner than the OS in the top half of the figure does.

Many members of the Linux development community believe this kernel-waiting-time difference to be an insignificant performance problem. This belief comes about almost certainly because no performance studies of Linux 2.2 on enterprise workloads have yet taken place. To glimpse how serious a problem kernel waiting time will be for Linux, look at recent developments in NT. NT\'s write function for network I/O was reentrant except for the part of the function that NIC drivers (network device interface specification―NDIS―drivers) handled, wherein they transfer data to their network hardware. Making this small part of the entire write function non-reentrant was enough to prevent NT from competing effectively with Sun\'s Solaris OS on enterprise applications executing on 4-way multiprocessors. To remedy the situation, Microsoft let NDIS drivers have deserialized, or reentrant, write paths in NT 4.0 Service Pack 4 (SP4) and Windows 2000 (Win2K). In Linux 2.2, several functions, in addition to read and write, are still not reentrant, and each time a Linux server application uses such a function, the function\'s non-reentrancy hampers multiprocessor scalability.

Sendfile
A final area in which Linux is at a disadvantage is its implementation of the sendfile API. Sendfile is an API that Microsoft introduced to NT several years ago as a feature that network server applications can use to enhance their performance. Obvious candidates for the API are Web servers. Without sendfile, a Web server that receives a request from a browser for an HTML file must first read the contents of the file into its memory and then send the contents to the client via a communications endpoint. The process of reading the file into private application memory is wasteful, because the server application doesn\'t want the contents of the file―it merely wants to send the contents to the client.

Sendfile eliminates the necessity that a server application read a file before sending it. With sendfile, the server application specifies the file to send and the communications endpoint in the sendfile API, and the OS reads and sends the file. Thus, the server doesn\'t have to issue a read API or dedicate memory for the file contents, and the OS can use its file system cache to efficiently cache files that clients request. Soon after Microsoft implemented sendfile in NT, UNIX vendors implemented sendfile in their OSs.

Linux has a sendfile implementation, but the Linux sendfile has several problems that developers must fix before Web servers (and other applications that can use the sendfile API) on Linux can achieve the same benefits that UNIX variants and NT obtain from their sendfile implementations. On NT, sendfile doesn\'t incur a copy operation if the file being sent is in the NT file system cache. In other words, the network software can send the data directly from the cache. But on Linux, sendfile copies the file data into buffers that sendfile hands to the networking code. This extra copy operation consumes CPU time and creates a larger memory footprint for the server application, both of which adversely affect performance. Another problem with Linux\'s sendfile is that it is non-reentrant. Thus, using Linux\'s sendfile leads to the serialized execution of part of a server application, which inhibits the application\'s ability to scale on a multiprocessor. A final problem with Linux\'s sendfile is that it doesn\'t let the system preappend a data buffer to the front of the file sendfile is sending. In the case of Web servers, this limitation necessitates another system call to request an HTTP header before the server can send the file.

Linux Isn\'t There―Yet
The limitations I\'ve cited are most of the major shortcomings in Linux\'s support for enterprise applications. However, other limitations might lurk beneath those I\'ve pointed out. Despite the Linux community\'s claims to the contrary, Linux 2.2 is not ready for the enterprise or for multiprocessors. Linux is not engineered with enterprise computing in mind, nor has the OS been present in enterprise environments where administrators, programmers, and users can notice its limitations. Consequently, Linux\'s kernel threads are ineffective at supporting enterprise applications, and the Linux kernel is unable to scale applications on multiprocessors as well as other OSs can. Certainly over the next year or two, as Linux\'s momentum pushes it into the enterprise, Linux will face its shortcomings. When that happens, and Linux\'s developers address the OS\'s problems, UNIX variants and NT will feel a compelling threat to their enterprise dominance from this open-source OS.


Figure 1
Figure 2
Figure 3

linux与windows各有特点
看你出于那种考虑，linus不是说linux还要二十年才能赶上windows吗？

  其实第一篇文章写的不好。
1）内核发布，并不是有了内核就能够做其他的事情么？还需要额外的软件包。感觉现在的linux的包装大的比windows还恐怖，动不动就几张盘，当然那也是可选的。拿linux的裁减和桌面windows比，当然更没有可比性了，应该拿wince比，应该可以说在embedded os上，ce比linux要成熟。Windows没有明确的内核概念？这就太诧异了。
(2) 内核的任务管理
  我敢肯定是程序设计的问题而并不是系统的问题。
...
  不想写了，没意思。

linux与windows各有特点
看你出于那种考虑，linus不是说linux还要二十年才能赶上windows吗？

就从架构上说，linux比NT优秀吗？

Linux是模块式结构，NT是分层结构，怎么比较？

我认为还是NT的结构更科学一些。

Linux地模块结构虽然整合在一起，看上去杂乱无章，但这都是为了内核更加高效地运行，一个高效稳定的内核对操作系统来说是很重要地，所以即使linux公开源代码，还是很难理解的！

就从架构上说，linux比NT优秀吗？

Linux是模块式结构，NT是分层结构，怎么比较？

我认为还是NT的结构更科学一些。

把第一篇贴出来


本人在Unix SYS5,DOS,Windows3.x,windows9.x/NT 和Linux几个不同时
期流行的OS上写过程序.在Linux和windows的对比中,我主要是从一个程
序员的角度来看的

一 系统架构的对比
1 内核
(1) 内核的弹性
Linux的内核表现出了高度的可配置性和独立性,主要是完成:IO驱动设
备管理,TCP/IP,以及任务调度.Linux的标准内核发布版本有40~50MB,而我
现在在一些评估板上试验的嵌入式Linux系统(使用Arm或M68K系列的CPU)
只用到了2MB,同样实现了网络功能和完整的任务调度,这使得Linux可以适
用于从高端服务器到嵌入式应用的各个等级的计算平台上,与之相比,windows 没有明确的内核概念.windows只适合台式机,NT从未真正的打入高端服务器,WinCE也遇到了一些结构性的困难.
(2) 内核的任务管理
衡量一个内核的重要指标是多任务环境下的安全性和任务调度的效率.
Linux在这方面继承了Unix的优点.而win9.x(包括winme)从来就没有实现过安全的多任务环境,NT/2K 勉强做到了安全性,但是效率还是不敢恭维,我曾今将一个多串口并发驱动的应用程序改写成多线程的方式,原本希望提高处理速度,实际上速度降低了2到3倍.这也就不难理解为什么同样的企业级应用在低硬件的机器上跑得比高硬件配置的NT/2k快.
2 系统的可增值性与历史兼容性
一个设计优良的操作系统应该有一个精简和一致的构造,在添加新的功能时不必破坏原有的结构,而且在后继发展中能够保持前后一致性.Unix由于当初设计时的科学性,以致于20多年的时间内,没有在设计思想上做过大的变动.虽然Unix有很多的版本,但是通过Posix标准,这些系统在源代码上保持高度的兼容.
与之相比,windows的几乎每个操作系统的框架设计都显得十分的随意,几乎不考虑硬件有了新的发展后,会出现什么问题.windown16位和32位两个时期的操作系统出现明显的\"代沟\",作为一个好的os,这种硬件上的差异是应该由其本身来考虑的,而不是把问题交给二次开发者,比如定义一堆PSZ,LPSZ的指针,将来64位时代, 大概要出现LLPSZ了:)
3 GUI 图形用户界面
Linux的GUI建立在X-WINDOWS的基础,这是与windows的GUI完全不同的一种架构windows的GUI是通过应用程序直接调用winows底层的GUI函数.或者说这是一种垂直的关系.而Linux的GUI是应用程序通过socket向X-WINDOW server发送请求实现的，只有X server在真正的写屏幕．或者说这是一种平行的关系．后者的方式带来更高的系统稳定性,因为图形显示系统崩溃，对于Linux来说，只不过是死掉一个进程而已，而对windows来说会导致整个系统的崩溃．当然X-window的开销要比windows的方式大，但是由于硬件的发展X-window在稳定性上的优点会将会弥补速度上微不足道的差异．
　4 应用开发环境
　Linux上的开发工具没有windows的容易入门，并不代表Linux上的开发环境比windows 差，其实linux编程入门慢，但是一旦熟悉了，以后就很少需要补充新的概念，与之相比，微软用一些很“简便”的编程概念吸引你，然后很快的淘汰这些概念，强迫你学习新的概念，你发现很多时间花费在气喘嘘嘘的跟着微软后面跑．你在这方面花费的时间远远超过你去学习linux编程的时间．　
　另一方面，Linux上IDE的开发工具也在成长，最终会吸引更多的应用开发工程师

　5 技术上的发展潜力
windows现在的技术架构基本上走进了一个死胡同，很难有大的创新．除非提出一个完全不同的系统，然后在里面做个win32子系统，以兼容现有的程序．就像在nt上搞win16子系统一样：）,并且体积再扩大一倍.
　对于linux来说，一个很好的架构放在哪里，现在主要是填充内容，丰富应用.在可以预见的时间内，windows无法在架构上超过Linux．

　6 多种平台互连的影响
　　如果linux在嵌入式应用中取得了成功，那么将来就会对台式机市场形成外围的压力.随着PC机的控制与网络能力逐步融合到家电和传统设备中去，这一天一定会出现的．微软以下压上的策略（用win9x的市场优势推win nt)会在Linux上重演　

结束语
手也打酸了，最后我用最近看到的一段评论结束这篇文章，好像是这么说的
　　　linux就像internet一样，在开始的时候发展较慢，一旦过了起步阶段，就会取得惊人的发展．　

　
----
道路就在脚下 时间自在心中
Email: makeidea@21cn.com
HomePage www.makeidea.com
OICQ 13242879

还有这个

Linux vs Windows 2000
      
 
By Leslie Ayers
  Printer-friendly format
 Email this story
 
 
 
Every time your PC crashes, you can\'t resolve a hardware conflict, or that accursed Blue Screen of Death stares you in the face, you wonder: Is it time to switch operating systems? Specifically, is it time to make the move to Linux? You\'ve heard how great it is-- a free operating system that never crashes and only needs the barest-bones configuration of a 386 processor and 16MB of RAM.


Many of the stories about Linux\'s iron-clad reliability are true. But before you abandon Windows 95, 98, or NT-- or abandon hope that Windows 2000 will fix its predecessors\' problems-- consider some key points. PC Computing compared Windows 2000 and the most current version of Red Hat Linux in four crucial areas: installation and setup, reliability, applications, and support. Here\'s a rundown.

 
Installation and setup

Linux setup-- even on the commercial versions such as those from Red Hat and Caldera-- is getting easier. But it\'s still much more complex than Windows. With each version of its OS, Microsoft keeps making installation and administration easier. Plus, with Windows 2000 you get self-repairing files and automated software setup over a network.


Winner: Windows



Reliability

Anyone who\'s ever experienced several Windows crashes in a day knows that it probably can\'t win on reliability. Linux\'s reliability is already rock solid and should only improve. Many users report systems that run for months-- even years-- without crashing. Windows 2000 must still prove that it can overcome Windows\' crash-prone history.


Winner: Linux


Applications

Linux apps keep coming (PC Computing collected the best on page 198 of the June issue), but even more mainstream software vendors must climb aboard. Corel now has a Linux version of WordPerfect, and it\'s poised to release its entire productivity suite for Linux. But Microsoft doesn\'t plan to develop Linux versions of Office, which means you\'re still stuck with Windows if you want Word, Excel, or Access. If you write software and want to get rich, you write it for Windows.

Winner: Windows


Support

Microsoft\'s name carries weight in the boardroom, and with home users too. With a huge support staff, plus thousands of trained Windows pros and resellers, Microsoft has the edge (which is not to say you can always get through when you call Microsoft tech support). Although there are increasing support options for Linux-- such as Linuxcare-- by next year, enterprise-level support for the OS will still be spotty.

Winner: Windows

If Windows 2000 meets its goals, it will be a big step forward for operating systems. But development delays have put it months away from hitting the shelves.


Meanwhile, Linux is reliable and available now-- although usability snags and limited support make it a better server than desktop OS. As big-name software vendors and support continue to emerge, Linux will remain a serious contender.


Linux is best for:

Small business owners or IS professionals who need email, Web, file sharing, or other types of servers but can\'t afford to spend a bundle on hardware (or Windows NT for that matter) are the best candidates for Linux. The OS is perfect for basic server tasks, and the latest packages (such as those from Red Hat and Caldera) make installation more painless with each new version.


If you\'re considering Linux for use on your home PC, make sure you know what you\'re getting into. Installing Linux-- even the commercial versions that arrive on CD-ROM with a manual-- is not for the faint of heart. And using it is not always headache-free. But if you understand technology and insist on switching from Windows to something more stable and more flexible, Linux may be the best option.

怎么没人接茬？？？