I half agree with you. It's not so much that Linux lacks a clean driver interface, it's really that OEMs write shitty software that doesn't belong upstream. Ideally vendors stop writing garbage drivers and distributing hacked up kernels with their "sample code" (but ends up in production) and opaque binary blobs.

Android unified vendors but simultaneously made them even lazier. It's somewhat hard to get non-android code from vendors in the past 5+ years. Which makes me very sad.

Will Fuchsia somehow convince vendors to produce better drivers? I don't see how Fuchsia makes this problem significantly easier. Shitty vendors will continue to be shitty vendors and take the easiest path to making money.

In any case, the Kernel's super power is its community, not the software itself. The LKML is vast and full of knowledge, a strange intersection of open source, research and corporate exploits.

I don't see Fuchsia replacing that anytime soon.

I think OP's point is it doesn't matter if the drivers are crappy, as long as they only use a fixed and we'll defined interface.

If drivers all had a well defined interface, the exact same driver, binary or source, can be used across any OS version, and maybe even on other OS's with the right shims.

Then you don't need driver manufacturers to all collaborate to update the OS.

The point is not to produce better drivers, rather a stable driver interface.

It is no accident that Project Treble drivers follow a similar mikrokernel approach to Fuchsia.

On Android, after Project Treble, classical GNU/Linux drivers are considered legacy mode drivers.

https://source.android.com/devices/architecture/hal

Fuchsia is the next step.

I wonder if a stable driver interface could also result in higher driver quality: if the same driver keeps working across many versions, even with relatively few users it could aggregate incremental improvements from various parties?

> the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed

> In 2018, we got the OS running natively on a Pixelbook. After that, the Fuchsia team stopped doing its work in the open and stripped all UI work out of the public repository.

Linux (AFAIK) still doesn't require the typical CLA paperwork or copyright assignment. The "strict licensing terms" of the Linux kernel ensures that kernel stays open. If openness is a goal of Fuschia, the GPL would not be a problem here.

If anything, Linux needs a harder license, like GPLv3 or similar, to maintain openness in a world of locked bootloaders and not-even-half-baked clone appliances with manufacturers who aren't interested in coughing up the kernel source.

Okay, but having a stable interface doesn't fix vendors shipping bad code, it just decouples it so you can run terrible drivers on a less-terrible kernel. Better yet, Fuchsia removes any obligation for vendors to share code (by both separating drivers from the OS and having the OS itself be permissively licensed), so third parties can't even start from vendor code and try to improve things.

Just like Project Treble,

Binderized HALs => HALs expressed in HAL interface definition language (HIDL) or Android interface definition language (AIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only.

Taken from https://source.android.com/devices/architecture/hal-types

These are two distinct problems. Rather, one is an improvement and another is a problem. The terrible drivers can then be isolated, pinpointed if you want, and the OS can move forward - if you don't use the AMD GPU or the HP printer no need to have it bloating your kernel, so I take this as the improvement (I was always fond of microkernels, so I'm advocating here). On the second problem, I fail seeing how the blame for vendors failing to update their drivers could fall on the OS. With this approach the failing is just much more evident, not any less damaging.

Why can't the vendors just contribute their drivers to the kernel? Why is it so hard? Looks like Intel is doing it and their products just work on Linux as a result. Why can't these shitty mobile hardware manufacturers do the same?

The sad answer is that they can't be bothered to meet the quality standards expected for upstream kernel code. Easier to just throw garbage in a tarball and ship privesc vulnerabilities to millions of users.

Driver supports costs money, vendors make money when they sell chips.

They treat drivers and software as a cost-center, so the software quality is typically horrible. Can't be merged, won't be merged.

Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.

> Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.

I don't remember it that way. I remember buying motherboards and receiving CDs full of drivers for the many Windows versions. I remember having to scour the internet for drivers and finding a different one for each Windows version. I remember failing to find drivers for new versions of Windows because the manufacturer couldn't care less. I remember incredibly shitty manufacturer applications that took over one minute to display a window on the screen. I even managed to reverse engineer one of those into a free software user space driver.

> I remember buying motherboards and receiving CDs full of drivers for the many Windows versions.

There haven't been "many" Windows versions in the entire existence of Windows. I bet you don't remember getting different drivers for every service pack or security update.

> Microsoft knew that, so they made sure to be ABI compatible so they could keep updating the OS.

That's just not true. A lot of hardware support was stranded by OS version updates, especially pre-Vista and Win7. It's reached a point where Linux deals a lot better w/ some older hardware than any currently-supported Windows version.

A small handful of times over many decades when the driver model changed, not after every update.

There were a lot of drivers who will not work with new windows versions. Due for examples of changes in things expectedv in the inf file or the registry. Installing drivers in windows was a lot of pain.

Ok, but again when you talk about "new windows versions" you're talking about an event that happens very infrequently, and most drivers do continue to work for decades without needing to be updated across multiple major versions. Windows 7 drivers from 11 years ago generally speaking still work in Windows 10 today. Hell, even Vista drivers (14 years ago!) often still work. Contrast that with the Linux kernel where you have to recompile external drivers, what, every few weeks?

A couple of times since 1995, not every year.

Some of that is just getting rid of compatibility code for misbehaving drivers.

Not just hardware but even older Windows applications run way better on WINE than on Windows 10. Microsoft doesn't care about reverse compatibility or long-term support for consumers.

you made my day, now i have to stop trolling and get a job. Do the same ;)

I feel this must explain why every Android device I've owned has felt janky in some way, while with an Apple phone it just seems to work.

I second others: it is horrible, low quality code.

I spent lots of time looking at released drivers for things like wifi dongles and cheap Linux sticks/tablets, and there are all sorts of horrors. The wifi cards do not fully implement scanning or ad-hoc mode. Existing ioctls are ignored or implemented wrong. Sleep is used for thread synchronization. Android device drivers hardcode specific app names and apply fixups for them, presumably to prevent crashes.

Intel has much better code, at least in wireless drivers, but to be fair their jobs is easier, because most of the logic runs in the embedded processor, and you only get the binary blob for its code.

> Why can't the vendors just contribute their drivers to the kernel?

What makes you think they want to? They want you to buy the next chip and the next and the next, not keep using the previous one with a new OS.

> What makes you think they want to?

Do they not care about having a high quality product?

They do have a high quality product. And then you have to buy their next high quality product instead of continuing to use the old one. Their products are hardware, not drivers, and they get more money by selling more hardware rather than letting old hardware get updated.

Can't use the hardware without the drivers. If the driver is low quality proprietary code that can't be fixed or updated, they don't have a high quality product.

And yet here we all are with umpty billion Qualcomm SoCs floating around and nobody complaining about how Qualcomm's chips don't work well (except, of course, in comparison to Apple's).

The hard reality that Linux kernel driver model stalwarts must face is that the only measure that matters to these companies is profit margin, and the economics just are not in favor of upstreaming their drivers. So knowing that, do we continue to yell into the night or do we implement a solution that doesn't leave umpty billion devices without kernel security updates?

> So knowing that, do we continue to yell into the night or do we implement a solution that doesn't leave umpty billion devices without kernel security updates?

Absolutely. Google has more than enough power and leverage to solve this problem. Why doesn't it require manufacturers to upstream their drivers instead of enabling their shitty industry practices? Literally just make it a requirement for Google Play services licensing or something. The phone manufacturers will be forced to require it from the chip manufacturers as well.

Google already does a lot of good work getting open source firmware into chromebooks. It should do even more. Use all that intellectual property for good for once.

> Google has more than enough power and leverage to solve this problem.

Yep. They are using their power and leverage to stabilize the kernel driver interface so that this just stops being a problem.

> Literally just make it a requirement for Google Play services licensing or something.

Google already has enough trouble keeping manufacturers on Google Play without giving them even more incentive to develop alternatives like microG.

https://wccftech.com/oppo-vivo-xiaomi-and-huawei-band-togeth...

https://wccftech.com/huawei-executive-says-the-company-wont-...

Android really needs the chip makers more than the chip makers need Android.

> Do they not care about having a high quality product?

No.

They care about maximizing shareholder value. If shipping lots of hardware with barely functional drivers integrators need to beat up into shape makes the most profit, that's what they'll do.

If you spend $20K more on making the software work, then it pays off paying $1 less for a part with a crappy driver than buying one from a vendor who also provides great software for anything you intend to sell more than 20K units.

Nowadays, a lot of products go out of production and are replaced by the next model before they have time to settle and get a consumer reputation. It sometimes feels like they do only 1 production run per model and then bye-bye. So, quick and "good enough", "as good" or "not worse than others" is good enough :-/

AMD already does and that creates a lot of friction both due to the bloat of the kernel the majority of which is now the AMD driver and the issue with code conventions and quality.

Unless hardware vendors agree to support a generic driver for each device type which can be maintained by the Linux kernel team it’s going to be a total nightmare and even then you need an easy model to extend the generic driver with a device specific one through an easy interface.

The AMD driver bloat is the register definitions. They have like 100+ MB of autogenerated register defines, some duplicated 8 times for each unit instance, for every chip generation and variant.

It's not real code, though it is ugly as heck and I have no idea why AMD can't do it a saber way.

They might want to keep their driver source closed, and even if they don't upstreaming code into the kernel is simply a ton of extra work.

> Overall, the monolithic natural of Linux Kernel and its strict licensing terms made it hard to get code upstreamed back or to write properly modularized driver extensions.

The postmarketOS folks are doing it, starting from downstream OEM Linux kernels, and the patches are being accepted on LKML. It's a lot of work because so much ARM hardware is its own weird mixture of long-supported basic IP blocks and newer stuff with its own quirks, and ARM has nothing like the plug-and-play hardware enumeration of modern x86 systems. So untangling all of this just takes a lot of time and effort. But this has nothing to do with Linux per se; it's all about the ARM system architecture itself and the SoC-based industry that has sprung up around it.

And no, running a microkernel-based system won't help at all, because any hardware that's part of the SoC can read or write arbitrary memory hence your driver can (perhaps unwittingly) subvert the very same security mechanisms you're supposedly relying on. Not to mention that some of these drivers handle, e.g. voltage regulators that will happily fry your hardware irreversibly if poked the wrong way. All of this stuff is inherently part of the trusted base of your system, so you're not going to do any better than what Linux already gives you.

> strict licensing terms made it hard to get code upstreamed back

How come?

Right now, the phone ecosystem isn't perfect. It's hard to update phones. Why is that? Because manufacturers don't care about long-term support. But at least you could ask them for kernel source, fix their drivers and eventually upstream everything, like postmarketos does.

Now, with a stable driver ABI and permissive license, drivers won't get released. Hardware vendors still have no incentive to support old hardware, so bugs will remain unfixed, and hardware will decay as usual... Oh, sure, maybe you'll get one more update before reaching an edge-case in some driver? I also expect manufacturers to put all kind of ugly things in the kernel if no agreement with google prevents them to do so. Cue "branded" kernels, with drivers incompatible with each other due to some extra or removed APIs. And back to square one, but with only binaries and no source this time around.

Will we see GNU/Fucshia someday maybe then? :P

The Kernel is an MIT license, and the user space is BSD [1]

> The Fuchsia kernel is released under the following MIT-style license: /zircon/kernel/LICENSE.

> All Fuchsia user space components are released under a BSD-style license: /LICENSE or an Apache 2.0 license: https://fuchsia.googlesource.com/infra/+/main/LICENSE.

> All code that is BSD-licensed has an additional IP grant: /PATENTS.

[1] https://fuchsia.dev/fuchsia-src/contribute/governance/policy...

GNU/Fucsia would probably end up similar to GNU/Hurd in that case, or Apple's MkLinux.

I'm guessing that depends on how big the pile of Fuchsia-compatible device drivers grows and how badly people running open source OSes want to use that hardware.

Where there's a demand for a particular class of device, maybe someone will create a shim? Then the kernel folks can have a debate.

Currently though, I think Linux has a big head start.

"But Fuschia's goal is NOT to build another Android, but mainly to replace the Linux kernel."

"BPF will replace the Linux kernel" - Linux kernel developer

Funny that the B in BPF stands for Berkeley, as in "BSD".

I bet it will be renamed at some point.

"BPF will replace the Linux kernel" is a quote from Steven Rostedt.

> The term of OS is heavily overloaded. But Fuchsia's goal is NOT to build other Android, but mainly to replace the Linux kernel.

To paraphrase a popular saying, "the driver interface apparently has an abstraction problem, so Google created Fuchsia - and now we have two problems."

It's a pet project. If you want to solve the kernel ABI problem, you can easily hard-fork and maintain that ABI indefinitely from any Linux kernel.

And if that sounds like it's too hard, imagine how hard it is to maintain your own kernel, and all the associated user space you now have to reinvent.

In fact, you don't even need to hard fork. You could have your own rolling tree with a stable "Android ABI" interface that vendors can write drivers against, optionally.

In any case, no company in their right mind would use this project. Google has proven repeatedly they will enforce a monopoly on their platform one way or another.

It accomplishes much more than just solving the kernel ABI problem.

It doesn't accomplish anything because nobody's going to use it.

May the best software win.

Anyway, if they succeed in integrating it into Android then that will be a lot of users :P

Seeing as how this is like the 5th or 6th year there has been some sort of press coverage about "Google's new OS" I'm not going to hold my breath.

Android already uses a similar model since Project Treble was introduced, with version 8 all drivers must use Android IPC instead of being Linux drivers.

Treble driver model is quite similar to Fuchsia, so it already happened, no need to prove anything.