> The windows nt kernel is better by design (dont crucify me for this, but it really is),
How so? Maybe at least state something, not just put it in like an "undeniable fact".
> we need to pay large sums of money to kernel dev. depart
IIRC, their kernel (core) department is rather small - I really do not think that has anything to do with it.
They also hire already Linux kernel devs, and if they want to shape it for their OS stack, they'd need to do even more so.
And I'm really not sure how the mixed rant about planned obsolesce and replacement of the native clients, which are very hard to maintain for multiple OS, with using a cross platform technology instead, for better or worse, has to do anything with the initial stuff.
> It gets destroyed when complete analphabets drive the decision about progress trough their vision of getting more money.
So using the Linux kernel would be equivalent of the decision of an Illiterate?
Further, as you seem to care about IT progress, how does fare the NT kernel with that compared to the Linux Kernel?
The last time I looked the NT one lacked a lot of features, from control groups, to checkpoint restore whole processes, varying amount of namespaces, scheduling (CPU, IO, realtime, ...), highly sophisticated Filesystems with lots of research going on there and in other areas.
Linux is multiple order of magnitudes more diverse and accepting for research, features, new design approaches, ... in comparison to the NT kernel, so please, don't make yourself look stupid by stating as it would be the other way around.
>> The windows nt kernel is better by design (dont crucify me for this, but it really is),
> How so? Maybe at least state something, not just put it in like an "undeniable fact".
There are two areas where I would say the Linux kernel is obviously inferior:
* Process management. Everything from creating processes, inspecting them, debugging them, querying process status, etc., is just better on NT kernel.
Take process creation. On Linux, to do advanced stuff, you fork() (or clone() if you want to get a couple extra process args) the process, then potentially call several other syscalls in the child process to do things like change security parameters, enable debugging, close file descriptors (!), before calling exec() to actually invoke the new process image. And if any of those things error out for some reason, you need to have a backchannel back to the parent process to inform it of those errors, which you have to set up yourself. And since fork() only forks a single thread but keeps all other non-existent threads in the same state (e.g., held locks), it doesn't really work in multithreaded applications unless you're extremely careful. On Windows, it's CreateProcess() where one of the arguments is essentially a list of all the changes you want to make in the child process for capabilities.
If you want to do stuff like get a process memory map information, inspect remote environment, etc., on Linux, you get to parse procfs (and hope to hell you're not dealing with cross-namespace situations because things start to break down at that point). Procfs consists of a lot of files whose contents are in a textual format that has a lot of parsers which fail to handle edge cases correctly. On Windows, you get to use system calls like GetProcessInformation that returns a nice struct with all the relevant information in it--no parsing necessary!
Debugging is even more of a mess; Linux developers admit that ptrace is a broken API that needs to be gutted and replaced, but no one wants to touch it. Windows has things like CreateRemoteThread and editing remote memory maps without having to inject your code into the debuggee to call mmap.
* Handles. On Windows, everything is a handle, which means you can do things like wait for any relevant event in WaitForMultipleObjects. Linux has eventually gained a facsimile of this with the variety of file descriptors (e.g., signalfd, timerfd, pidfd) to coerce various kernel objects into things you can pass to poll, but this also runs into issues that file descriptors have properties that limit their utility, such as file descriptor exhaustion or their behavior with fork().
I'd also suggest that things like IOCP or the capability system in NT as things that may be superior to Linux, although io_uring may be a compelling alternative to the former, and the cgroup/namespace capabilities to the latter.
How so? Maybe at least state something, not just put it in like an "undeniable fact".
> we need to pay large sums of money to kernel dev. depart
IIRC, their kernel (core) department is rather small - I really do not think that has anything to do with it.
They also hire already Linux kernel devs, and if they want to shape it for their OS stack, they'd need to do even more so.
And I'm really not sure how the mixed rant about planned obsolesce and replacement of the native clients, which are very hard to maintain for multiple OS, with using a cross platform technology instead, for better or worse, has to do anything with the initial stuff.
> It gets destroyed when complete analphabets drive the decision about progress trough their vision of getting more money.
So using the Linux kernel would be equivalent of the decision of an Illiterate?
Further, as you seem to care about IT progress, how does fare the NT kernel with that compared to the Linux Kernel?
The last time I looked the NT one lacked a lot of features, from control groups, to checkpoint restore whole processes, varying amount of namespaces, scheduling (CPU, IO, realtime, ...), highly sophisticated Filesystems with lots of research going on there and in other areas.
Linux is multiple order of magnitudes more diverse and accepting for research, features, new design approaches, ... in comparison to the NT kernel, so please, don't make yourself look stupid by stating as it would be the other way around.