Re:Why risk your creditibilty? (Score 0, Flamebait)

I agree. I always use the best tool for the job. Linux certainly has its advantages, I find it to be a great server. But Windows also has better tools, like the WinDBG and SoftICE kernel debuggers, it is far far superior to gdb in linux. I also find it interesting that many people talk about how Linux is better than Windows in the absolute sense when they have no idea the internal workings of the O/S. What they see on the outside, meaning the UI, has nothing to do with how it works inside or its design. For example, core boot mode drivers for Linux cannot be loaded on demand, as in it has to be linked to the kernel image itself. That means if you update the driver code you have to recompile the kernel itself. Whereas NT kernel loads them on demand, that you can update your boot mode drivers with OUT recompiling the kernel itself. It is more modular and more portable than the Linux kernel. For the same reason, the HAL.DLL module makes the NT kernel portable in the sense that you do not need to recompile your kernel every time you use a different chipset because the kernel is separated from platform dependent code. You can easily verify the truth of this paragraph by simply looking in your Linux kernel source tree and type make config, you will find that your boot mode drivers, like ext3 or xfs, or whatever you use for your root fs is linked into the kernel. In fact, if you compile that driver as a module, you'll see a kernel panic when you restart with the new kernel. Another design issue I tend to favor Windows is the ability to run subsystem environments. Granted only the Win32 subsystem ships with Windows, you could nevertheless run the POSIX subsystem on Windows if you wish. Unix apps can run on Windows natively, without emulation, whereas Windows apps can never run natively on Linux/Unix, you always need emulation. The Unix services for Windows is NOT an emulator, it contains the updated Posix subsystem server for Windows. So in theory you can have different flavors of environments with radically different APIs for each environment with one common O/S core. To the end user, it would be like having different O/S in a single package. An argument could be made to say that the Posix subsystem acts like a virtual machine, which in that case the Win32 subsystem is also a virtual machine. What many people don't seem to realize is Win32 is not the native system API for Windows NT! Like if a Posix app calls fork() and a Win32 app calls CreateProcess(), both of these actually calls NtCreateProcess(), a native NT API, to do the actual work. Posix apps on Windows do NOT call Win32 functions like an emulator would**. The native NT API is the system service, or a common language for NT O/S, not Win32 like it was on Win 9X based system. (**Although the GUI stuff in Posix does call Win32k.sys so that Microsoft don't have to write separate drivers for different environments. But that is a design choice and doesn't have to be that way) The point about NT's environment subsystems is that you can write many custom subsystems. You can make the system behave like a Windows box, or you can make the system behave like a Unix box, or an OS X box. The default Windows distribution cannot run without the csrss.exe, the Win32 subsystem because Microsoft made it so you can't run without Win32, but that is a choice they made because they want us to use Win32. But in theory, if you have the Windows Source code, you can make it so that your NT box run whatever subsystem you want without the Win32 subsystem running. I want to say here don't confuse implementation with design. The reason Windows still crashes a lot is because of poor implementation, not because of poor design. I'm not saying Linux has bad design or anything, far from it. In fact, the Linux monolithic design has a definite speed advantage over NT's modular design any day. Linux also has a better implementation than that of Windows. In large server environments, Linux wins anyday because in theory, Linux design has the higher end on performance. NT design has the advantages too, because its modular design makes it portable across platforms. One last thing, system crash in NT is likely the result of either a hardware failure, or a device driver. NT can only crash if something in kernel mode is messing things up. NT cannot get a blue screen from user mode. For example, IE is a user mode process running in XP, if a blue screen comes from you clicking on something in IE, it is not IE that crashed your system. Hard as it may for you to believe, it is likely due to a GDI call, which is implemented in Win32k.sys (kernel mode device driver for Win32 subsystem) has somehow caused an unhandled exception somewhere and KeBugCheckEx() was called and crash the system. Unlike Win9X, not user application in Windows NT can crash the system. (Thats not to say they cannot crash themself, just not the whole system) Linux, Unix, OS X, all work the same way. Only kernel mode components can cause them to crash. So if you have a buggy kernel mode Linux driver, you can be sure it will crash your Linux box. You can verify the truth of my statement simply by moving your X server routines that handle graphics into kernel mode in Linux, and then open up firefox or mozilla, and crash your browser severe enough to cause X server to crash, and I guarantee you'll find Linux itself will crash along with the X server. Anyway, thats my 2-cents. I just wanted to inform people to look at the "target" more closely when you criticize something. I actually used Solaris, OpenBSD, FreeBSD, NetBSD, VMS, Slackware, RedHat, Windows on 4 different platforms. (as in Intel, Sparc, Mips, and Dec Alpha) And they all have their ups and downs.