Linked by Thom Holwerda on Mon 8th May 2017 17:05 UTC
Google

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.

Order by: Score:
Moochman
Member since:
2005-07-06

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

Reply Score: 4

oiaohm Member since:
2009-05-30

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.

Reply Score: 2

moondevil Member since:
2005-07-08

Except they aren't a lone developer coding on their basement and already have ChromeOS, Android and Android Things to take code from.

Reply Score: 4

oiaohm Member since:
2009-05-30

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.

Reply Score: 2

Kochise Member since:
2006-03-03

Final name will be 'Fuch ia'

Reply Score: 2

Megol Member since:
2011-04-11

Final name will be 'Fuch ia'


Android is mostly at a Fuch IA stage already - ARM is the most common processor architecture.

Reply Score: 2

Kochise Member since:
2006-03-03

I was more thinking about 'Fuc* ya', now they can be evil...

http://vignette4.wikia.nocookie.net/cloudywithachanceofmeatballs/im...

Reply Score: 2

Alfman Member since:
2011-01-28

oiaohm,

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.


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.

Reply Score: 4

oiaohm Member since:
2009-05-30

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.


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.

Reply Score: 2

Alfman Member since:
2011-01-28

oiaohm,

Remember Microsoft, IBM, Google... All basically have the same problem hardware makers set a lot of rules.

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.


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

Reply Score: 3

oiaohm Member since:
2009-05-30

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.


You are presuming a few key problems.
1) that google is not going to stuff it up.
2) the cost of the drivers in the Linux kernel.

100 million users for sure might be worth it. You are talking a few billion dollars to replace what the Linux kernel provides in hardware support.

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.


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.

Reply Score: 2

Alfman Member since:
2011-01-28

oiaohm,

You are presuming a few key problems.
1) that google is not going to stuff it up.
2) the cost of the drivers in the Linux kernel.

100 million users for sure might be worth it. You are talking a few billion dollars to replace what the Linux kernel provides in hardware support.


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 ;)

Reply Score: 2

oiaohm Member since:
2009-05-30

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.

Soc chips are more than 1 vendors parts in most cases.

So you are never dealing with a single manufacturers with SOC chips in most cases. Linux kernel GPLv2 creating a common pool of shared drivers from those who reverse on those who don't release is a interesting effect.

I'd agree with you there's no real money in supporting hardware you don't sell.

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.

Reply Score: 2

Megol Member since:
2011-04-11

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.


If it is ever released as an Android replacement or as the base of a new Android release then hardware vendors will write drivers. Just as they are doing for Android now.

Not doing that would mean losing a huge market.


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.


This isn't a hobby OS. Also supporting a limited range of hardware is possible to do even for hobbyists.

Reply Score: 2

GPL
by nicubunu on Tue 9th May 2017 06:41 UTC
nicubunu
Member since:
2014-01-08

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?

Reply Score: 2

RE: GPL
by moondevil on Tue 9th May 2017 07:42 UTC in reply to "GPL"
moondevil Member since:
2005-07-08

GCC was dropped from Android NDK and replaced by clang, just like Apple did.

https://android.googlesource.com/platform/ndk/+/ndk-r14-release/CHAN...

Reply Score: 2

RE[2]: GPL
by Lobotomik on Tue 9th May 2017 08:06 UTC in reply to "RE: GPL"
Lobotomik Member since:
2006-01-03

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.

Reply Score: 2

RE[2]: GPL
by nicubunu on Tue 9th May 2017 08:40 UTC in reply to "RE: GPL"
nicubunu Member since:
2014-01-08

It looks like that compiler change happened for technical reasons: https://github.com/android-ndk/ndk/issues/26#issuecomment-198067100

Reply Score: 2

RE[2]: GPL
by Megol on Tue 9th May 2017 10:55 UTC in reply to "RE: GPL"
Megol Member since:
2011-04-11

GCC was dropped from Android NDK and replaced by clang, just like Apple did.


Don't see how that have to do with anything.

Reply Score: 2

RE[3]: GPL
by moondevil on Tue 9th May 2017 11:53 UTC in reply to "RE[2]: GPL"
moondevil Member since:
2005-07-08

One GPL dependency less on the Android stack.

Reply Score: 2

Talent needs something interesting to do
by wigry on Tue 9th May 2017 12:24 UTC
wigry
Member since:
2008-10-09

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.

Reply Score: 2

Alfman Member since:
2011-01-28

wigry,

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.


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.

Reply Score: 2

Googles frustration with Linux
by JMcCarthy on Tue 9th May 2017 19:46 UTC
JMcCarthy
Member since:
2005-08-12

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.

Reply Score: 2

RE: Googles frustration with Linux
by wigry on Tue 9th May 2017 20:54 UTC in reply to "Googles frustration with Linux"
wigry Member since:
2008-10-09

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

Reply Score: 2

RE: Googles frustration with Linux
by jgfenix on Wed 10th May 2017 07:25 UTC in reply to "Googles frustration with Linux"
jgfenix Member since:
2006-05-25

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.

Reply Score: 2

Regarding the proprietary drivers
by Lazarus on Tue 9th May 2017 20:05 UTC
Lazarus
Member since:
2005-08-10

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.

Reply Score: 2

oiaohm
Member since:
2009-05-30

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.

Reply Score: 2