IMO, the Linux desktop problem is due partially to relying on the antiquated X Windows system, but mostly a lack of funding a good vision, e.g. Unity.
After growing up with OpenLook, then Motif, the plethora of Linux window managers, and unhappy years with Windows, I noticed most of the elegant apps were being written for OSX. I’m not sure how much of this is due to the devs or the OS/libraries, but probably both.
The solution I want is a Linux OS, a WM with a good, cohesive, long term vision, and an easy way to build apps within at vision — something like a native Electron minus the memory and CPU overhead. I believe Google could do this.
Security on Android is a joke for 80%+ of users. They can't run on the latest version of Android, because various vendors' drivers are in out-of-tree kernel patches that are un-upstreamable for non-technical reasons.
(By comparison, Chrome OS is also Linux-based, but, IIRC, it requires all shipping devices to have drivers upstreamed.)
Owning an OS with a stable device driver ABI would allow Google to fix the Android fragmentation problem, and make sure all devices stay up-to-date ala Chrome OS.
1. Zircon, the kernel, is entirely capabilities based. No users, no groups. Those are higher abstractions built on the capabilities system. This is all around a win for security from executing 3rd party drivers to building a sandboxed multi-user system, not to mention is just generally more flexible and less error prone at the kernel boundaries and internally.
2. The WM is scene based. Applications draw to a scene which the WM composites and renders. This means a single draw list is sent to the GPU for each pass instead of many apps spamming their own updates. Also you can do cool things like have objects from one app cast shadows on another app.
3. The kernel API is not a bloated mess and will not become one. Keeping the number of syscalls on the order of 10s not 100s is a design goal. You can see the commitment to this in the way the project is structured. Which brings up:
4. Testability. The project was designed with testability in mind. Not Enterprise Java mock and verify the world shit. Just good practice separation of responsibility between the different layers and enforcement of a sane unidirectional dependency relationship from lower to higher layers. Good luck testing the Linux kernel.
5. The system will update from a single image rather than relying on N parties to pull new patches into their distro and update and test everything N times before releasing to people. Again layers.
This isn't all new by any means, but it's a pretty practical approach to an OS in 2017. This isn't an "academic microkernel", and also decidedly not *nix.
Enough evangelism. Point is, the project is not solely designed to give the big G more control over a platform. Not saying that is not one goal, but technically this thing checks out.
It was my understanding that it was almost completely technical reason, i.e., vendors write drivers that mostly work but are completely terrible from a quality perspective.
Are they actually doing that though? I haven't read anything along those lines, not that I have looked at Fuchsia in depth.
I think you don't understand how much Google works to have security from design. Windows, Linux, OS X can all be fine "traditional" desktop systems (though the lack of a unified vision on Linux hurts it incredibly).
I see Fuchsia as a desktop system that (a) has a native, fundamental concept of graphical desktop and (b) has deep sandboxing on a level similar to Chrome, but for the entire OS, meaning -> it could become an all purpose platform for thick client applications that isn't reliant or the web and still unable to be exploited.
I suspect they are not satisfied with any of their desktop options. I doubt this has anything to do with Android or Chrome OS within the next 10 years. They just want a desktop that sucks less and they can guarantee follows their own security practices (not FIPS, but process isolation and capability injection).
I wish it had more adoption. Right now there are not a lot of apps written using it's UI guidelines/framework as most projects are worried about portability and/or have moved to Electron. It is slowly getting better though, and seems to be developing an ecosystem geared towards quality as OSX used to be: https://medium.com/elementaryos/appcenter-spotlight-2017-wra...
(I also don’t see Linux developers flocking to it in droves, which is sad because it is a lot cleaner and easier to use than Gnome and KDE, IMHO, but then again Linux has always been more about diverging choices than unity—and I don’t mean the desktop environment here).
The only thing Elementary needs to do is allow for disabling all animations, to get rid of the perceived latency issues some folk complain about...
But I digress. It isn’t an OS, and you get all the Linux legacy underneath, so it’s understandable that Fuchsia is happening. Google seems to be attempting to lay a new foundation here, and I think it’s actually a good idea to do so, although the number of third-party packages and run times they’re bringing in makes it hard to peg it as “legacy-free”.
Time will tell, I guess.
Honestly, I think the multi-user assumptions that *nix started with are largely irrelevant now. Most people don’t have multi-user needs on their devices (you can’t even do it on iOS), and even servers are moving towards single-user constructs with containers, etc. I think the an operating system built around a multi-user model will be viewed as the edge case in the coming decades rather than the norm.
For example, with Linux I can choose GNOME, KDE, a selection of other desktop environments, or I can choose a simple window manager like twm and sort of roll my own environment. Or maybe I could set my system up so that it runs without a window manager and just gives me a full-screen emacs environment.
With Mac OS, for example, someone else made all of the choices and I have to live with them.
What Google is doing will probably end up getting pretty close to your vision, but I suspect that the end result will be very similar to Android - a system that's technically Linux at its core, but where all of the choices have been made for you.
God, I've just recently have to downgrade to Gnome 3.24, because the latest 3.26 version kept crashing with the segfault error few times a day.
It's a difference but not necessarily a feature if, as a user, you don't have the background to make informed and safe decisions about those choices.
I use Linux again since this year after working almost only on OS X for 5 years or so. It has been more setup work than I wished but I'm really satisfied now. OS X just lacks the transparency and customizability that Linux easily provides.
Not sure how Fuchsia will evolve. There are more Operating Systems than Window Managers. But only 2 Operating Systems with good driver support. Their names are Linux and Windows - OS X runs only on a handful of configurations. Android's Hardware support is a mess.
Either they will support running Linux or Android drivers, or otherwise their system will be just useful for Marketing demos.
> something like a native Electron minus the memory and CPU overhead
I guess this is exactly what Chrome OS does. Or just use Firefox/Chrome on Linux. At least Firefox still has a working Marketplace...
Are you just saying that, or do you actually believe it? You think all of the phone vendors that write custom closed source drivers for Android will abandon Android if the core is no longer Linux? Seriously? And what, move to tizen? Windows phone?
Be reasonable... Google can and will move to a different core, and all of their partners will move with them.
https://fuchsia.googlesource.com/zircon/+/master/docs/syscal...
https://fuchsia.googlesource.com/zircon/+/master/docs/concep...
This is literally MacOS/Cocoa/AppKit minus Linux plus BSD
Also, the first thing I do on non-GNU/Linux systems is install GNU tools :)
They support Developer Centric Opensource, they do not support User Centric Free Software
Smartphones are one thing, but I think the recent trend of using the Linux kernel in self-driving cars is a terrible idea that we'll only start regretting 10-15 years from now.
More software (eventually) for end users? And maybe since it's a RTOS, perhaps this is also to be used by Waymo?
I keep seeing people day this, and yet: Is there any evidence at all that Google can pull off designing something like this?
[0] https://www.theregister.co.uk/2016/08/15/googles_new_os_coul...
What is funny is that Linux on the desktop was closest to actually happen when KDE was happy emulating Windows rather than being its own thing, and doing so quite well on top of X.
As for X being antiquated, F that.
https://github.com/fuchsia-mirror/docs/commit/520ed01fd6f258...
If the general public starts to believe that there is an Android successor in the works, many people will stop buying Android devices until further notice. This could be absolutely catastrophic for the Android device market.
If I were Google, I would bury the name Fuchsia, call the thing Android 10, and let it be known that it's years out.
There is also no reason they can't replace Linux underneath Chrome OS with new Foundations. After all Linux internals were never exposed to the consumers in Chrome OS. As long as they port Chrome, they should be able to do it at least theoretically. Same theory could apply to Android but that would be much harder to do I think.
I doubt anything non-Linux based is ever becoming popular within the next 100 years. ;)
Do you mean their product vision? If so, why does it matter when it already exists?
OK so why not Google Chrome web browser on top of Fuchsia, instead of Linux kernel and the usual user space stuff? Google can call that retrofit anything they want, so it could still be Chrome OS.
Besides this of course, Fuchsia shared many other components with chrome (the use of Skia for example). If we look at the direction for Flutter, Fuchsia and Chrome, it is clear that this is not some casual side-show but a very well thought out strategy.
It is although true that Google could replace the low layers of Chrome OS as long as it replicates most of the user facing features.
If Google intends to make Fuchsia some kind of Android successor (we have no way to know if that's the plan though), this feature is utterly needed anyway : an Android VM for 'legacy' apps and Flutter for the future.
