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
Slashdot Mirror
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