Why?
Not having to deal with Linux's refusal of maintaining a stable driver API and ABI for a start. The number one reason that stops Android from getting updates on smartphones is that hardware manufacturers don't want the burden of constantly making small changes to their proprietary drivers to follow new linux kernel changes, something that they don't have to worry about when they make drivers for, say, Windows PCs.
Even Google's own phones, like the Nexus and Pixel, are stuck because of this. They receive updates faster than non-Google phones, but they do not receive more than 2 years of feature updates (with an additional year of security updates courtesy of Google backporting fixes from newer android builds to the older kernel).
Fuchsia is not going to be burdened by Linux kernel dev policies of constantly breaking APIs and their requirement for driver developers to open source their stuff, obey the kernel coding preferences (like when they rejected AMD's driver because of the HAL) to get them mainlined so that they can finally be kept in a maintained state.
And as a result, its drivers will be far lower quality and much less stable, and the system as a whole will pay the complexity cost of working around the awful code that hardware vendors churn out.
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.
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.
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?
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?
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.
Anyway, what I said is that sandboxing isn't a substitute for open-sourcing. They are complements, not substitutes.
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.
Linux is quite real, I assure you.
[1] https://developer.microsoft.com/en-us/windows/hardware/downl...
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
Just thinking of how painful taking a dependency on guava can be makes me think this claim is satire. :(
If it wasn't in the Java ecosystem, it might not feel weird. But the Java community had maintained backwards compatibility for a long long time. Guava promises, what, a year?
And for internal use, that is fine. I have seen some poor sods introduce it as a dependency of theirs, which can lead to frustrating upgrade cycles.
Edit to add: the Jakarta libraries are also fairly well designed. To the point that most things in guava were already there.
They were the first to do push based email and IM in a context outside of business AFAIK.
When the iPhone was announced in 2007, they realized that on-screen keyboards and multi-touch control were the future, so they did a complete redesign, moving to an interface similar to the iPhone. Here's a quote from one of their engineers talking about the iPhone announcement:
“As a consumer I was blown away. I wanted [an iPhone] immediately. But as a Google engineer I thought ‘We’re going to have to start over’” Chris DeSalvo said. “What we had suddenly looked so… nineties. It’s just one of those things that are obvious when you see it.”
[Every time this story is told, I like to remind - note how fast Google were able to pivot / adapt when Microsoft with their crazy resources and Engineering might took way longer. (Even beyond that MS had to change the way apps were developed for WP.) Fact is Google/Danger/Android were in a fundamentally good position mobile OS design wise way before the iPhone. After the iPhone - they looked at the possibilities of multi touch soft keyboard UI and were able to get there and surpass fairly fast.]
But even adjusting for that it took MS 3-4 years after the iPhone to just get Windows Phone 7 out, and that was also clearly a rushed release, because they had to throw everything out for Windows Phone 8.
I believe after rage from Jobs they left out multitouch zooming at first and did something double tap based, even though MS had done it before Apple (without capacitive) and Minority Report has shown it.
To name a few: UNICOS, NeXTStep, HP-UX, RSTS, ULTRIX, VMS, AIX, SunOS, Solaris, IRIX, A/UX, MacOS, ProDOS, Amiga OS.