> "port" Windows services and applications to the Linux kernel.
In every category imaginable, the NT kernel is better designed. Async IO, better power management, pageable kernel memory, stable driver API. I'd much rather KDE shell on NT kernel.
I get that Linux is popular, but no objective evaluation would claim that Linux kernel is better in any metric other than "how open source is it?" Spend some time to read the NT docs and get familiar with the design and you'll see.
This may be a hard pill to swallow, but in many areas linux's design is still very much "my first kernel" (I will give credit where it is due though, it is slowly being patched piece by piece, slowly). Whereas NT was written by a team who's done it a few times and avoided a lot of pitfalls (eg: synchronous by default IO, really??)
> In every category imaginable, the NT kernel is better designed. Async IO, better power management, pageable kernel memory, stable driver API.
I can't comment on most of these things since I don't know much coding about them, but I will definitely grant you the stable driver API. Drivers are a huge pain in the ass in Linux, and until DKMS it was pretty common for upgrading my kernel to break my wifi card, which was really annoying.
> I get that Linux is popular, but no objective evaluation would claim that Linux kernel is better in any metric other than "how open source is it?"
I mean, that's a pretty big feature. Didn't Linux get multicore support well before Windows almost entirely because Linux was open source and popular on servers? When something is open source, companies (or people) don't have to wait for a specific monolithic company to decide that a certain feature is worthy.
> synchronous by default IO, really??
I will totally admit a lot of ignorance as I don't work in kernel spaces, but hasn't Linux had Async IO in the form of `epoll` for like 20 years? It's not the default but I feel like it's pretty commonly used.
-----
Of the things I do like about Linux (outside of open source), it follows the "everything's a file" mantra from Unix. It makes it fairly fun and easy to arbitrarily glue applications together (admittedly at the cost of performance sometimes).
Also, I like that you can choose different filesystems more or less arbitrarily. I don't have a Linux laptop anymore (I run macOS), but I when I did I was running ZFS on root with Ubuntu, and ZFS is pretty awesome. As far as I'm aware, with Windows you're basically stuck with NTFS.
>I will totally admit a lot of ignorance as I don't work in kernel spaces, but hasn't Linux had Async IO in the form of `epoll` for like 20 years? It's not the default but I feel like it's pretty commonly used.
As an API, epoll is kind of... suboptimal. Of course, lots of great things have been built with it, but there's a reason it's being replaced with io-uring, which is a lot more similar to Windows iocp.
From a high level, the philosphy of doing i/o with IOCP, posix AIO, and io-uring are the same. All of those are true async i/o rather than a readiness model like epoll/kqueue/etc.
The novel thing of io-uring is using a new data structure to do it with fewer syscalls, thus less syscall overhead.
NT was multicore much earlier (1994 [1]). Linux had SOMEWHAT working SMP support in 2.0 in 1996 [2]. But really I would hardly count it as real, what with BKL.
epoll() was introduced in Linux 2.5.44 [1], which was released in 2002 [2]. Epoll is not a wonderful API. Linux's real reply to NT's anync io is io_uring, which only appeared in Linux 5.1 [4] in 2019(!!) [2], and is still wildly evolving
I mean, I don’t think you’re wrong; I think the main reason that people haven’t complained that much about being stuck with epoll is that a lot of this is somewhat abstracted nowadays. I’ve only used epoll once to play with it, and most of the time when I need nonblocking IO, I use Java NIO or Netty or something. I generally do not care about how pretty the underlying code powering these things is as long as it works and as long as my code is pretty.
Granted, that’s not really a good excuse for Linux having a crappy system, just why I think there wasn’t ever a ton of urgency for it.
epoll is not an asyncio implementation, it really doesn’t belong in any discussion about aio, it’s a relatively better poll/select. Apparently less well known is that Linux had an async io interface also introduced around the same time in 2.5 (see io_setup, io_submit, and libaio). Initially extremely limited and generally not widely used (limitations include only working on certain disk files opened O_DIRECT), however it was incrementally improved over the years until io_uring came around. glibc has had a POSIX AIO implementation for years, implemented with userspace threads since the kernel implementation was originally not suitable.
In begin of AMD64 a lot of Windows software was single threaded 32 bit still, while on Debian with APT you had a working 64 bit environment. It was mostly userland which could not handle the amount of max cores found in even consumer grade multicore AMD64.
Even recently many games did not take advantage of multiple cores, while AMD has been strong performance wise multiple cores, Intel was best single core until Zen 3 recently. Windows would be unable to perform well (use max cores) on AMD64 by AMD.
You can see it now too. Intel gets slight performance boost with Windows 11 compared to 10 while AMD loses performance. Which AMD said they will address in October.
This is a dishonest take on my post. I was talking about 64 bit in the context of AMD64. Not 64 bit in general. Alpha is irrelevant in this discussion.
When I first used Interix back in the late 90s I had this dream that someday I'd see a version of NT that booted into text mode and ran an all-POSIX userland. That's never going to happen now but, architecturally, NT could totally pull it off.
Edit:
Microsoft wouldn't ever open-source NT but, damn, GNU/Windows NT would be a sweet OS to use. (Make it license-compatible with ZFS and it'd be awesome.)
I wouldn't say never. I think the chance of that happening is ever so slightly increasing every year. The benefits of open source NT kernel will some day outweigh Microsoft keeping it close. Its strategic value is decreasing. ( The whole OS on the other hand is a different question though. )
Not necessarily private; Windows Server (without year-number) is GUI-less. Windows Server (with year-number) you can choose right in the installer, if you want "Desktop experience" or not.
Not particularly. I'd rather have seen Interix hang around.
Interix was implemented in more of a pure "NT" manner, being a subsystem, as compared w/ WSL1. WSL1 just shims Linux syscalls. I'd rather build software from source targeting Interix (as just another "Unix"-flavored build target) than running native Linux binaries.
Microsoft bought Hotmail in 1997. Hotmail was programmed in C++ and Perl--both of these programming languages had already been ported to NT at that time.
It took them 7 years to get it stable enough to run on Windows Server, and they had to rewrite the entire stack to do it.
Until then, they were running the service on Unix.
I think the parent comment is talking about the NT kernel rather than the Win32 subsystem that is Windows. Today NT really only has 1 subsystem (Windows) but it definitely can support multiple ones, it even had one for Unix (really more a POSIX layer) back in the day.
Two subsystems for POSIX, really. There was the original POSIX subsystem[0] that shipped in NT 3.1 thru 4.0, and the third-party OpenNT that became Interix[1] after Microsoft purchased it.
Even Windows doesn't agree with that. They started with a syscall wrapper for running Linux binaries, and ended up running a full Linux kernel next to the NT one because that was faster.
There are absolutely parts of Linux with all the architecture and engineering rigor of a favela. Real big "I want a new room and have two sheets of corrugated steel, a neighbor's wall, and an afternoon" energy.
There are also major parts of it that have benefited from decades of 'this tweak that won't be driver ABI compatible increases efficiency in this use case by measurable but single digit perf'. And yes, there's politics to getting that merged, but the barrier is way lower in Linux. You try a lot of that in how Microsoft builds software and at best you put a target on your back because you just made a lot of work for another team. At worst that amount of differently siloed work just kills the idea in the first place.
windows is idling at less than half the power! Idle power matters since most laptops spend most of their time idle waiting for the comparatively-slow humans to press keys
> And did you come back here an hour later to get another quip in?
And "quip" is a questionable (bordering on implied ad-hominem) word choice given that my only fault is disagreeing with you.
> windows is idling at less than half the power! Idle power matters since most laptops spend most of their time idle waiting for the comparatively-slow humans to press keys
The min use under Windows is slightly lower, the average is higher, and most importantly of all, the battery life (the metric we actually care about) appears about the same.
As the article says "Overall, the power use between Windows 10 and the four tested Linux distributions was basically on-par with each other." and "Beyond this data, the battery life of this Dell XPS laptop has been about the same as seen under Windows 10 with the testing thus far. So overall it's a pleasant surprise with not having tested any other Kabylake-R laptops and wasn't quite sure if the Linux power efficiency would be able to run on-par with Windows 10 at this point."
So it would appear that your new claim (that Windows gets twice the battery life) is without merit.
I wish laptops were like a phones, where race to idle is key, but they're not. The upper levels of the software stacks both on Windows and Linux aren't there yet.
No, it's not NTFS versus ext in the sense you mean. The Microsoft messaging on this is misleading at best.
It's that the NT filesystem stack puts the FS cache between user space and the FS driver, whereas on Linux it sits between FS driver and the block device driver. What that means is that on Linux, you get caching of blocks containing FS metadata for free, but on NT it has to be manually performed. That kills perf when looking at a lot of metadata.
When they say NTFS is to blame, they mean the NT FileSystem stack.
> I get that Linux is popular, but no objective evaluation would claim that Linux kernel is better in any metric other than "how open source is it?"
There's probably many areas where Linux comes strongly ahead - a much wider array of supported architectures, and even on the windows supported ones Linux scales much better by the virtue of being deployed from the smallest embedded computers to (all of) the largest supercomputers.
Linux supports a larger number of architectures than NT ever did, but NT was originally implemented on a non-x86 processor to insure portability. The MIPS, PowerPC, Alpha, and IA64 ports of NT are all dead, but they were all supported in the past. The speed that Microsoft brought up NT on ARM illustrates the portability too.
Yeah one of the features of NT is its hardware abstraction. Even though those other platforms have fallen by the wayside I would presume that abstraction layer is still there.
In every category imaginable, the NT kernel is better designed. Async IO, better power management, pageable kernel memory, stable driver API. I'd much rather KDE shell on NT kernel.
I get that Linux is popular, but no objective evaluation would claim that Linux kernel is better in any metric other than "how open source is it?" Spend some time to read the NT docs and get familiar with the design and you'll see.
This may be a hard pill to swallow, but in many areas linux's design is still very much "my first kernel" (I will give credit where it is due though, it is slowly being patched piece by piece, slowly). Whereas NT was written by a team who's done it a few times and avoided a lot of pitfalls (eg: synchronous by default IO, really??)