Ars Technica has an article with screenshots about a new development in Fuchsia, Google’s research (maybe?) operating system. The project has a very basic and barebones graphical user interface now.
The home screen is a giant vertically scrolling list. In the center you’ll see a (placeholder) profile picture, the date, a city name, and a battery icon. Above the are “Story” cards – basically Recent Apps – and below it is a scrolling list of suggestions, sort of like a Google Now placeholder. Leave the main screen and you’ll see a Fuchsia “home” button pop up on the bottom of the screen, which is just a single white circle.
The GUI is called Armadillo, and Hotfixit.net has instructions on how to build it, and a video of it in action.
Google still hasn’t said anything about Fuchsia’s purpose or intended goal, but Travis Geiselbrecht did state in IRC that it isn’t a toy, and it isn’t a 20% project. At this point, the safest bet is to just call it a research operating system, but of course, it’s exciting to imagine this brand new open source operating system having a bigger role to play.
Just this morning I read this article:
http://www.androidpolice.com/2017/02/15/speculation-around-googles-…
Now it seems that the speculation is true after all! Even if it does take until 2020 for a Fuchsia phone to come to market, the Flutter SDK alone looks like a really interesting new option for building apps. I am a bit of a UI-toolkit aficionado, having developed various apps over the years with Swing, JavaFX Script, Adobe Flex, WPF, Apple UIKit, Android UI toolkit, Polymer and Angular. I’m curious to see what Flutter (
https://flutter.io
) brings to the table in terms of ease of development, customizability, UI performance and of course fun with Dart.
Edited 2017-05-08 17:57 UTC
Does not matter the reality is google will still need to get hardware vendors on board for drivers. Like 90 percent of the audio driver abi for it is not even designed yet.
Its really simple to get a hobby OS to the point it can show pretty pictures. Its a lot harder to get it where it usable on real hardware.
Except they aren’t a lone developer coding on their basement and already have ChromeOS, Android and Android Things to take code from.
But what the need for hardware support they mostly cannot take from the Linux kernel without ending up with major problems. Linux kernel drivers are design that they have ring 0 in lots of cases and this new kernel need the drivers to run in userspace.
A lone coder in their basement is not much different. 11 developers who are working on other projects along with Fuchsia. That is about equal to one developer focused on a single project.
You need Fuchsia developer count to cross 50 be sure it going somewhere.
I see Fuchsia being another Tizen looks good until someone looked under the hood and does a security audit.
sel4 exists and provides a very good model on how to write a OS from scratch and be secure from the ground up. Fuchsia does not follow this model.
Linux kernel is doing a lot of work to attempt to go in the sel4 direction.
Final name will be ‘Fuch ia’
Android is mostly at a Fuch IA stage already – ARM is the most common processor architecture.
I was more thinking about ‘Fuc* ya’, now they can be evil…
http://vignette4.wikia.nocookie.net/cloudywithachanceofmeatballs/im…
oiaohm,
I agree with you in principal, but google couldn’t be further from a hobby os developer. They carry enough weight in the industry that many manufacturers can’t afford to be left out and so are likely to go out of their way to make sure google’s latest and greatest products work on their hardware.
It’s totally unfair, but google gets a lot of advantages for being google whereas independent hobby OS developers can’t even get the time of day from manufacturers.
Really it does not make very much difference google market presence. Google still has to win over the hardware vendors. The Linux kernel contains a lot of support for different IP blocks that vendors use in their SOC chips that will have to be rewritten for Fuchsia.
Fuchsia could be the same as Microsoft singularity. Prototypes made work and then got no hardware vendors because most of their hardware vendors were interested in the existing OS.
Until we see hardware vendors doing drivers for Fuchsia is pie in sky stuff. Besides it important to remember the libhybris as well.
For lot of hardware libhybris was required to use Linux so you could use android userspace graphics drivers. More and more android is going dri3 driver design that is in ring0 kernel driver to reduce overhead.
Fuchsia is a Micro-kernel. Hardware vendors care about benchmarks if Fuchsia end up benching slower than Android with a Linux kernel its going to be dead in the water.
Remember Microsoft, IBM, Google… All basically have the same problem hardware makers set a lot of rules.
Yes the performance overhead problems of userspace graphics drivers with stable ABI is shown by androids userspace graphics drivers.
oiaohm,
I think you are underestimating the influence that google has.
Google > manufacturer > hobby os dev/lone coder working in basement.
All google has to do is brand fuchsia as an android upgrade and as long as they don’t commit any microsoftian blunders they’ll easily be able to get hundreds of millions of users on board. Manufacturers know this and they could even end up in a bidding war to sweeten the pot for google just to get a piece of the action. Refusing to play ball with google could cost billions of dollars in lost sales versus manufacturers who are courting google.
Look, I’m well aware of the difficulties caused by proprietary drivers, you are right about the problem and I’ll stand right there with you in advocating for more accessibility. However we still have to acknowledge that when you are the big fish like google, you carry a lot of weight in the industry. We don’t know what google’s plans are for the OS, but realistically the google connection puts fuchsia well above the struggles that an independent hobby OS would face. This may not be fair, but that’s how business works.
Edited 2017-05-09 14:36 UTC
This will be a very hard for a lot of people to hear.
Hardware vendors are very happy with the Linux breaking their closed source drivers all the time. This means the OEM vendor has to pay the hardware vendor every time they want top update.
If Fuchsia has a stable driver ABI with stable drivers this means hardware vendors make less cash.
You are aware of difficulties caused with proprietary drivers you are not aware that the ones that release their drivers open source Fuchsia will have not trouble getting the ones that keep there drivers closed source are not interested in a stable driver ABI as this will mean less income for them.
So Fuchsia design equals head to head with hardware vendors.
Microsoft end up with Windows phone being restricted to a single hardware vendor and Fuchsia could face the same problem.
Having the Fuchsia kernel MIT license I see it only a matter of time until a hardware vendor makes a customised version so creating unstable driver ABI all over again because that is a feature they want.
oiaohm,
1) that’s what I meant by “microsoftian blunders”.
2) it’s likely a non-issue because google/manufacturers would only need to support the hardware they actually plan on shipping, not every single device supported by linux.
I’d agree with you there’s no real money in supporting hardware you don’t sell. This is especially tough on indy OS developers, who don’t sell any hardware, yet are chastised when it doesn’t work
The Linux world does it run Linux motto means the Linux kernel runs with old ball hardware include hardware like playstation 4 where the vendor totally does not want Linux there.
So there are a few odd things about Linux kernel that has made it such a great choice.
MIT license you are not going to have the culture the Linux world has. Yes the very culture of wanting drivers open source is the very reason why Linux supports so many different soc chips and vendors who have used third party options have a reasonable time.
So the very thing that makes Linux world argue with closed source drivers is the very thing that give Linux cost effective SoC chip support.
If you cannot make your hardware work right because 1 driver is missing is a brick.
The billions in cost in drivers happens as soon as you want to support a pack of soc chips like the current android phone is. Windows Phone that is a restricted soc list in is over 100 million in driver development.
So basically your arguments still don’t stack up.
The scary part is the few billion in Linux kernel development could explode out to a few trillion if each OEM/hardware vendor makes their drivers uniquely for the SOC chips used in mobile phones.
The idea that each hardware vendor individually can write the drivers for their hardware is in fact unworkable.
Understanding the driver side means you understand how much of a up hill battle Fuchsia is in for.
Note it would be a different matter if we were seeing ARM or other major IP block providers taking a direct interest in Fuchsia. Please do note you see Arm, Intel… and other core IP block vendors taking part in Linux kernel development. You even have documented cases of the major IP block vendors directly working with Microsoft and Apple.
Fuchsia without the hardware IP block vendors is possible dead man walking. Can google win those vendors over? That is the question. No matter how good the OS if you have not won the IP block vendors over its in for a hard and costly development process.
oiaohm,
Whoa man you’re trying waaay too hard to disagree for no good reason. This is like the conflict between batman and superman. I’m going step back and say “Martha”
QNX and VXWorks are running into the same problem.
So my point here: The idea that each hardware vendor individually can write the drivers for their hardware is in fact unworkable. is based on what has happened to other Closed source OSs.
Is based on costs.
The result of having the core drivers that are shared is slowly but surely being more expensive per unit to recover the price of driver production. So be less and less competitive.
Individual hardware vendors making drivers will not make Fuchsia a viable option. You need a core of hardware vendors sharing the development cost this is very hard to build and is required to bring the per unit cost down of the final product.
Death of Windows CE, reduced usage of QNX, reduced usage of vxworks. This is all writing on the wall. Ignore in your for-castings of the future at your forecasts at your own risks.
The result of having the core drivers that are not shared is slowly but surely being more expensive per unit to recover the price of driver production. So be less and less competitive.
Sorry typo.
This isn’t a hobby OS. Also supporting a limited range of hardware is possible to do even for hobbyists.
In the article, the author says a couple of times how one of the benefits of moving from Android to Fuchsia would be for Google that it get to “dump the GPL”. Is there a public statement from Google about they being unhappy with GPL or is the author projecting?
GCC was dropped from Android NDK and replaced by clang, just like Apple did.
https://android.googlesource.com/platform/ndk/+/ndk-r14-release/CHAN…
But that particular choice may be due (may) to CLANG seemingly being a much more lively project than GCC, and (also seemingly) a much easier platform onto which you can build a high-quality compiler for a new language.
It looks like that compiler change happened for technical reasons: https://github.com/android-ndk/ndk/issues/26#issuecomment-198067100
Don’t see how that have to do with anything.
One GPL dependency less on the Android stack.
Perhaps the inhouse custom OS development is just a way to keep talented people occupied with something interesting until their talent will be required in another project instead of keeping them idle and giving them reason to think about leaving.
wigry,
Haha, what an interesting thought.
I’ve heard accounts of what it’s like to work at google: many employees there are way overqualified for what it is they do because google can get the top candidates even for positions that don’t really warrant it. There are so many applicants competing to get into the doors, but it’s not particularly more challenging than other jobs. So it might make sense that they would be bored. I’ve heard that one of the worst aspects of working at google is that you feel like a cog working in a huge machine with little opportunity to make a difference. Well in small companies we have far more influence, but pay is worse.
I keep hearing this is being developed because Google is frustrated with the nature of Linux kernel development. The lack of stable (in-kernel) API/ABI, lack of control, the update problem.
..Except they get nothing they couldn’t get by simply forking the kernel. The problem is they’re trying to keep one foot in the door and the other out. Almost none of the problems they’ve faced are the result of any sort of technical limitation.
The kernel doesn’t have a stable driver API because the people in charge don’t want one. Fork the kernel and you’re the one in charge.
Even if Google would fork the Linux kernel, they would be forced to use GPL license which I guess they are desperately trying to get rid of by licensing their own creation with BSD/MIT/Apache
But it would be more difficult to take advantage of others´s work in the kernel. Android invented their own stuff for its needs but that was/is being replaced with generic kernel code.
Regarding the proprietary drivers, you have that problem now with Android, especially in the GPU area. The GPL has done fuck-all to fix that for us.
What employing a non-GPL’d microkernel could allow is a stable driver API/ABI in userspace, allowing you to swap out the rest of the OS for an updated version while still being able to use that exact same GPU driver binary regardless of the vendors desire to keep it updated.
Not something you could ever reliably do on Android due to the Linux kernel being such a fast moving, ever mutating target.
https://android-developers.googleblog.com/2017/05/here-comes-treble-…
Treble idea is going to be interesting to follow.
Remember Linux kernel could not be the one design universal interface. If outside party such as google designs it then documents and allows other operating systems to use it.
Also note they will be working to mainline more Android drivers into the Linux kernel so to avoid using Treble as much as possible.
Treble is going to have all the performance issues of stable driver ABI ever made.