News for hackers. Stuff that matters.
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by windowssuperfi on Wednesday January 07, 2026 @10:01PM (#46536656)
Yeah cause windows is amazing Or maybe macos? Ignore their freebsd parts of course.
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by cosmic_cheese on Wednesday January 07, 2026 @10:23PM (#46536802)
Apple at least has been making a concerted effort to kick more macOS/iOS functionality out into userland in the past several years.
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by pjmlp on Thursday January 08, 2026 @03:33AM (#46538719)
Just like Windows since Vista.
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by DowsingSpoon on Wednesday January 07, 2026 @10:14PM (#46536747)
Yes. As far as kernels go, NT was pretty damn good.

So is Mach, by the way, if you can afford the microkernel performance overhead.

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by johncolanduoni on Wednesday January 07, 2026 @11:08PM (#46537081)
Mach is not a very good microkernel at all, because the overhead is much higher than necessary. The L4 family’s IPC design is substantially more efficient, and that’s why they’re used in actual systems. Fuchsia/Zircon have improved on the model further.

Someone will of course bring up XNU, but the microkernel aspect of it died when they smashed the FreeBSD kernel into the codebase. DriverKit has brought some userspace drivers back, but they use shared memory for all the heavy lifting.

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by saagarjha on Thursday January 08, 2026 @09:54AM (#46541727)
> Mach is not a very good microkernel at all, because the overhead is much higher than necessary. The L4 family’s IPC design is substantially more efficient, and that’s why they’re used in actual systems.

As opposed to Mach, which is not used in any actual systems

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by johncolanduoni on Thursday January 08, 2026 @12:47PM (#46544038)
I mentioned XNU below. It doesn’t really count as a microkernel if you, you know, don’t actually use the microkernel part. At least for the 30 years between the FreeBSD collision and the introduction of DriverKit, which does most of its IPC through shared memory (because the mach ports are not efficient enough, I would assume).
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by saagarjha on Saturday January 10, 2026 @02:24AM (#46563587)
Yes, but a lot of other things use Mach messages.
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by johncolanduoni on Saturday January 10, 2026 @03:01PM (#46569377)
All the major OSes have components of the larger operating system that run in userspace and communicate via IPC, including Linux. But userspace drivers and basic system services (VFS, network stack, etc.) are very limited in their use of userspace/IPC. If macOS is a microkernel in the sense of those built on L4, then so are Windows and Linux, and the word doesn't have any meaning anymore.
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by saagarjha on Tuesday January 13, 2026 @02:28AM (#46598188)
Is that IPC called Mach?
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by johncolanduoni on Tuesday January 13, 2026 @09:17AM (#46601193)
Yes, and it’s quite inefficient compared to L4 or Zircon’s IPC so it isn’t used for anything that wouldn’t work just fine over a SEQPACKET socket using SCM_RIGHTS like Linux does. Is modern Windows a microkernel because ALPC exists?
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by dundarious on Wednesday January 07, 2026 @10:16PM (#46536758)
If you include all the drivers too (which surely makes the comparison more accurate), is that still the case?
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by nobodyandproud on Wednesday January 07, 2026 @10:34PM (#46536888)
Windows NT 3.x was a true microkernel. Microsoft ruined it but the design was quite good and the driver question was irrelevant, until they sidestepped HAL.

The Linux kernel was and is a monstrosity.

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by WalterGR on Wednesday January 07, 2026 @10:55PM (#46537009)
What do you meant by them sidestepping the HAL?
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by avadodin on Thursday January 08, 2026 @12:15AM (#46537457)
I think the biggest one is that the whole GDI library was moved into the Kernel in 3.5x because the performance was terrible at the time.

I don't think they ever intended to keep all drivers strictly userland, though. Just the service side.

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by nobodyandproud on Thursday January 08, 2026 @11:16AM (#46542750)
Mind you I don't have access to Microsoft code, so this is all indirect, and a lot of this knowledge was when I was fledgling developer.

The Windows NT code was engineered to be portable across many different architectures--not just X86--so it has a hardware abstraction layer. The kernel only ever communicated to the device-driver implementation through this abstraction layer; so the kernel code itself was isolated.

That doesn't mean the device drivers were running in user-land privilege, but it does mean that the kernel code is quite stable and easy to reason about.

When Microsoft decided to compromise on this design, I remember senior engineers--when I first started my career--being abuzz about it for Windows NT 4.0 (or apparently earlier?).

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by pjmlp on Thursday January 08, 2026 @03:34AM (#46538726)
This is outdated since Windows Vista, and even more so in Windows 11.
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by nobodyandproud on Thursday January 08, 2026 @11:18AM (#46542802)
Windows Vista isn't Windows NT 3.x. In the internal versioning, it's not even 4.0.
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by pjmlp on Thursday January 08, 2026 @04:30PM (#46546758)
Indeed, it is something better, Windows NT 6.0.

And it is irrelevant anyway, given that this comment was written from 10.0.26100.

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by nobodyandproud on Thursday January 08, 2026 @05:30PM (#46547420)
Oh, I see.

You’re saying they improved the design. I know they added user-privilege device driver support for USB (etc).; did they revert the display compromise/mess as well?

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by pjmlp on Friday January 09, 2026 @12:29PM (#46556386)
Yes, now graphics drivers are mostly in userspace, with only a tiny driver in kernel space, miniport.

Hence why graphics usually no longer crash Windows, after a small black screen pause, everything continues as usual.

https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by heavyset_go on Thursday January 08, 2026 @12:20AM (#46537491)
XNU monolith-ized itself over time, even over some microkernel-esque boundaries.
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by lifetimerubyist on Wednesday January 07, 2026 @10:24PM (#46536810)
NT is actually a pretty good kernel. NTFS and the userland is what is shit.
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by speed_spread on Wednesday January 07, 2026 @10:38PM (#46536910)
NTFS is a beast of a filesystem and has been nothing but solid for 25+ years. The performance grievances ignore the warranties that NTFS offers vs many antiquated POSIX filesystems.
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by johncolanduoni on Wednesday January 07, 2026 @11:12PM (#46537104)
What warranties? I assume you’re comparing it to ext4 and not e.g. ZFS?
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by speed_spread on Thursday January 08, 2026 @08:23AM (#46540669)
Here are a few

- mandatory byte-range locks enforced by the kernel

- explicit sharing modes

- guarantees around write ordering and durability

- safe delete-on-close

- first-class cache coherency contracts for networked access

POSIX aims for portability while NTFS/Win32 aims for explicit contracts and enforced behavior. For apps assuming POSIX semantics (e.g. git) NTFS feels rigid and weird. Coming the other way from NTFS, POSIX looks "optimistic" if not downright sloppy.

Of course ZFS et al. are more theoretically more robust than EXT4 but are still limited by the lowest common denominator POSIX API. Maybe you can detect that you're dealing with a ZFS backed volume and use extra ioctls to improve things but its still a messy business.

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by johncolanduoni on Thursday January 08, 2026 @12:07PM (#46543482)
These are pretty much all about mandatory locking. Which giveth and taketh away in my experience. I’ve had substantially fewer weird file handling bugs in my Linux code than my Windows code. POSIX is very loosey-goosey in general, but Linux’s VFS system + ext4 has a much stronger model than the general POSIX guarantees.

`FILE_FLAG_DELETE_ON_CLOSE`’s equivalent on Posix is just rm. Windows doesn’t let you open new handles to `FILE_FLAG_DELETE_ON_CLOSE`ed files anyway, so it’s effectively the same. The inode will get deleted when the last file description is removed.

NFS is a disaster though, I’ll give you that one. Though mandatory locks on SMB shares hanging is also very aggravating in its own right.

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by pjmlp on Thursday January 08, 2026 @09:52AM (#46541695)
Also to point out that outside UNIX, surviving mainframe and micros, the filesystems are closer to NTFS than UNIX world, in regards to what is enforced.

There is also the note that some of them are more database like, than classical filesystems.

Ah, and modern Windows also has Resilient File System (ReFS), which is used on Dev Drives.

Re:Kernel bugs hide for 2 years on average. Some hide for 20 by edoceo on Wednesday January 07, 2026 @11:02PM (#46537054)
Userland peaked in Windows 2000
Re:Kernel bugs hide for 2 years on average. Some hide for 20 by IcePic on Thursday January 08, 2026 @02:59AM (#46538501)
I think NTFS get a bit of crap from the OS above it adding limitations. If you read up on what NTFS allows, it is far better than what Windows and the explorer allows you to do with it.