[quotemstr]

> And as a result, its drivers will be far lower quality and much less stable

I don't buy it. Windows provides stable driver ABIs and works just fine. A lot of the changes to the Linux driver API are gratuitous, and isolating driver development from the whims of the core won't actually hurt.

If anything, a stable ABI will help, since a smaller, well-defined boundary between the kernel core and drivers allows for things like Vulkan-like validation layers, better debugging, better sandboxing, and even transparent thunking to userspace.

Will some drivers be shitty? Of course. But many drivers won't be, and drivers will be less shitty overall when they can spend more time on being good drivers and less time dealing with GFP_FOOBAR becoming GFP_BARFOO.

Conventional wisdom is that backward binary compatibility i some huge unreasonable burden. This conventional wisdom is wrong; if anything, maintaining a stable ABI imposes some discipline that focuses development effort and that forces you to modularize your system.

[lamlam]

I've always thought that one of the things that gives Windows drivers the edge over Linux ones is the fact that Microsoft provides a testing and validation suite for drivers [1].

[1] https://developer.microsoft.com/en-us/windows/hardware/downl...

[quotemstr]

SAL/PreFAST are _awesome_ too. I haven't seen anything close in the free world.

[flukus]

> I don't buy it. Windows provides stable driver ABIs and works just fine.

Depends on the driver, but often they are buggy and will never be updated for the life of a device. Once a device has been sold the manufacturer doesn't care about support. Most linux CVE's are in drivers, imagine how many are lurking in the binary blobs of random third parties?

[quotemstr]

> Most linux CVE's are in drivers, imagine how many are lurking in the binary blobs of random third parties?

That's why we should sandbox drivers as much as possible! I'm a big fan of punting a lot of driver work to userspace. How are we supposed to do that if drivers are allowed to use the entire Linux kernel internal API and do whatever they want? How can we possibly isolate a driver that thinks it has the right to take mmap_sem and twiddle PTE bits?

[catern]

Sandboxing isn't a substitute for having your drivers be open source. Even if all drivers were written in safe languages, you'd still have CVEs and still want to fix those CVEs.

[quotemstr]

Closed source Linux drivers exist. Open source Windows drivers exist. An unstable kernel ABI is neither necessary nor sufficient a condition for open sourcing drivers.

[catern]

True but irrelevant.

The key new "feature" of Fuschia is that its stable ABI makes closed-source drivers easier to write in the short term, relative to Linux. As a result, the vast majority of Fuschia drivers will be closed-source. Don't you agree?

I believe supporting a stable API and closed-source drivers will result in a technically inferior, more complex, less stable kernel. The Linux model of including all the drivers in a single open source codebase, where the drivers can be refactored and improved along with the rest of the kernel, is a genuinely superior way to develop a kernel, which produces a genuinely technically superior product. I just hope Google realizes this before they sink too many millions into Fuschia.

[quotemstr]

I think we can at least agree that the proof is in the pudding.

[naasking]

You seriously think that open source drivers would have fewer CVEs than sandboxed drivers?

[catern]

How exactly are you going to sandbox your drivers? Run them in user-mode, perhaps? But then you've constructed a microkernel, and no-one uses your system because it's slow.

Anyway, what I said is that sandboxing isn't a substitute for open-sourcing. They are complements, not substitutes.

[naasking]

> But then you've constructed a microkernel, and no-one uses your system because it's slow.

FUD. L4 is the most widely deployed kernel in the world.

> Anyway, what I said is that sandboxing isn't a substitute for open-sourcing.

Given reality, something must substitute for open source drivers. Sandboxing is certainly the obvious choice.

[X86BSD]

As do the BSDs. That's what vendors need is stability regarding drivers.

[mangix]

I've seen a larger amount of instability in Windows than in Linux. Having a stable ABI doesn't help much.

[Lutia]

I've personally never had any problem stemming from the lower levels of the system ever since Windows 7. Whenever I've seen major bugs on Windows, it was on user space stuff like the profile corruption that breaks the start menu and metro/UAP apps in Windows 10 after the major updates which can be fixed by deleting the user and creating a new one.

Windows also has a more robust architecture where it matters, like the fact that a GPU driver crash doesn't kill the user session (windows can reload that subsystem while keeping the user session running since Vista), whereas it can either kill Xorg or just outright freeze the system on linux. A very useful way to architect the OS, although I've only experienced it on Vista and had more stable GPU drivers from 7 onward.

[quotemstr]

Windows, at least for me, has been exceptionally stable since Windows 7 or so.

[zamalek]

Software stability isn't the core point - how is the stability/instability of Windows relevant to the disadvantages of a driver ABI that changes continuously?

[baybal2]

>I don't buy it. Windows provides stable driver ABIs and works just fine.

I strongly disagree with this statement. Windows is a buggy mess on all levels from GUI down to kernel. It is a consensus of technically enlightened people

[slededit]

Do you have an example that's not from user32? Usually people extrapolate that subsystem to the entire kernel.