"One person who has spoken to Fuchsia staff described the effort simply: "It’s a senior-engineer retention project."
This has been my therory for a while. You see all these different projects competing against each other (multiple messaging apps are a good example) and you think: why is Google so unfocused? But what Google basically wants to do is hoard engineers so they don't leave and go work for competitors and make them stronger (or start their own companies that could compete against Google).
So Google's management figured out that if they give these enginners some cool stuff to work on, they'll stay at the company, even if the stuff they work on is a duplicate of something else the company has already done.
Per the article, Google has over 100 engineers working on Fuchsia. If these are all "senior engineers" that "Google is trying to retain", the cost of keeping them must be at least 50 million per year.
That's a lot of money to pay just for retention of people who are not producing anything of value, consuming many other resources (office space, network, hardware, perks), and deeply committed to a project that supposedly will never benefit their employer.
A rich employer may retain an unproductive employee for a limited amount of time if they expect it to ultimately pay off. It just doesn't make any sense to retain someone indefinitely if they're not going to produce anything of value, and (implicitly) will quit the moment you try to put them on any sort of real-world valuable work. Google is a public company with fiduciary responsibilities to its shareholders and a legally accountable board, it can't just throw tens of millions of dollars away without good reason or explanation.
> You see all these different projects competing against each other (multiple messaging apps are a good example) and you think: why is Google so unfocused?
There are many good reasons to have multiple teams competing against each other, building the same product. Often it will bring a strong drive and pace to all competing projects, as well as cross-pollination, and eventually they often merge to a single deliverable that is better than any of the projects could produce individually.
> what Google basically wants to do is hoard engineers
I'm not sure why all these improbable theories make more sense to you than the plain fact that Android was designed quite a few years ago, has many natural deficiencies, and - like all technologies - will eventually be replaced by a superior successor.
That's exactly what Fuchsia is about. Its existence does not require any elaborate conspiracy theory. On the contrary: given how strategically important the Android market niche is for Google, it would be very surprising if Google was not working on a viable successor. It's as if Sony didn't have a successor for the PS4 in the pipeline, and just expected it to sell forever, with minor patches here and there.
I think Google's self-competition is something they are doing strategically.
If you look at the industry as a whole products wax and wane based on market trends. Market leading products often struggle to innovate under the weight of their own success and are eventually replaced by a new innovator that's doing something right.
Google, by virtue of creating many different types of products in one category somewhat insulates themselves from this effect. They have effectively infinite money, so from their perspective they can somewhat emulate the greater market internally. They can let "startup" style teams form internally so if someone supplants one of Google's products, it's likely to be a Google team.
There are significant downsides to this (eroding consumer trust) which may take their toll on Google with time.
All major OS have gone kernel changes over time. Windows,MacOS,now Android. Simple. Of course, lots of other factors as well like Oracle lawsuit.
Taken from reddit:
I don't think it will be "starting over," just a major platform change. Imagine Fuchsia being Android 13.0. Every OS maker does a major platform rewrite along these lines eventually.
Windows moved from DOS to the NT kernel.
Apple moved from the classic Mac OS nanokernel (is this the right name?) to the Unix-like XNU kernel with OS X.
Google could trade Linux for Fuchsia's kernel.
These projects are always codenamed something else at first. They always come with big compatibility problems that are overcome with time or emulation layers. Sometimes there are major UI changes, sometimes the UI is built to closely replicate the old OS, but everyone does a huge "reboot" transition like this eventually.
Different sources will have different spins. Surely the Fuchsia team wouldn't think they're in glorified daycare, it's unlikely their superiors would tell journalists they are.
> "The company must also settle some internal feuds. Some of the principles that Fuchsia creators are pursuing have already run up against Google’s business model. Google’s ads business relies on an ability to target users based on their location and activity, and Fuchsia’s nascent privacy features would, if implemented, hamstring this important business. There’s already been at least one clash between advertising and engineering over security and privacy features of the fledgling operating system, according to a person familiar with the matter. The ad team prevailed, this person said."
A controversial idea, but you know how much easier this would be for everyone if Google offered an option for users to be paid for volunteering your information to them? It's a precedent most fledgling ad companies wouldn't be able to match... even if it's just a few dollars a month, or maybe 30ish bucks a year. It'd cut into Google's bottom line, but it would eradicate the competition.
And then on top of that, you've got the security and privacy wins by baking the product to be secure by default but allowing consumers to accept a paycheck to disable some of it for Google. That risk calculus works for plenty of people (if not for myself).
Google's wins:
• Security and Privacy by default
• Dismantling start-up competition who can't afford to pay for the data they harvest
• Growing marketshare.
Drawbacks:
• Immediate hit to Google's revenue stream
• Permanent assignment of value to data in the perception of consumers
The only big outstanding risk would be posed by rivals with large warchests able to subsidize a similar payment scheme, but honestly once that's done, the winner is a public which now has the ability to monetize their data.
Would be nice if there were a competitor mobile platform to iOS that wasn't built from the ground up to sell you advertising based on personal data. I guess Blackberry was the last mobile OS that didn't need to know every detail of my pissing habits.
When we are in our nursing homes later in life we will get to hear some interesting stories about the creation of these world changing technologies in a middle of the afternoon radio show.
I often wonder what kind of amazing company Google could be if only their cash cow was not from advertising, but something neutral and profitable like AT&T was to foster Bell Labs.
> "Switching away from Android could provide Google the opportunity to hit the reset button on any mistakes they believe they made a decade ago,". "They might be able to regain some power that they’ve ceded to device manufacturers and telecom carriers."
How making a new OS achive this? What kind of problems Fuchsia could solve when Linux can’t solve?
I personally hope Fuchsia would remain as an experimental project. A new non-GPL OS by a big player like Google is a bad news for hardware dev and enthusiasts from XDA. This will make hardware driver developments more fragmented and closed-source.
Smartphone manufacturers are trying to hide their kernel and device drivers, even they are using Linux. Imagine there are no legal restrictions to hide those.
One of Android's major headaches is that Linux does not have a stable driver interface. Interfaces within linux change regularly, but only drivers that are checked into the main tree are updated. If you maintain a driver outside of that tree, you will experience pain. That's how Android operated and why it's linux kernel rarely changed (and why doing OS updates for phones was so hard).
Android has been trying to fix this with treble[0], which will make many more phones get OS updates going forward. So Android has attempted to work around one of linux major problems.
Another large problem is that Linux was designed for desktop architectures. It's design and focus continues to go that way. This has impact across an entire range of functionality that an OS is supposed to bring.
Fuschia seems to be a research project with a focus on mobile/laptop type devices. It could care less about server type environments, which lets it make different tradeoffs in design.
> How making a new OS achive this? What kind of problems Fuchsia could solve when Linux can’t solve?
The problems they are likely trying to solve are business and legal, not technical. Pesky things like not having to release keys bits of code under a 'free' license (i.e. they have no choice but to release any changes to the Linux kernel under GPL as that's what it requires.) Sure, they'll probably still release large chunks of source code (possibly under MIT/BSD, possibly under a less liberal license) but keep strategic bits closed source. Right now they have to do this via the clunky and somewhat obvious Google Play services layer. And then there's the constant potential exposure to lawsuits. etc.
By being able to decide on what pieces would be released under what licenses, it would allow them to prevent competitors from following in their footsteps as Amazon and various Chinese companies have done with Android. Things like this are the reason Samsung (one of Google's largest problems) keep pushing forward with their Tizen platform so that when the shift comes they have the ability to sidestep it if they want to.
no stable driver interface, they are still learning how to cope with this.
There is a ton of cruft in the APIs, like any large project would have.
One of the engineer in the Android framework team described creating APIs as generating future regrets.
Some of the mistakes are pretty small. Like internally the system reuse drawable instances in order to save memory, but instead of making this process entirely automatic, before calling let's say `setTint(color)`, you need to call `mutate()` so the UI framework spins a copy of the drawable for you.
it would have been easy to integrate this behavior by default without having you know about mutate but since it was done differently, this behavior has been preserved in order to do not break retrocompatibility.
There are many small API issues like this. Big issues of course are corrected but often preserve the old behavior in case you are targetting an old version of the OS.
The View system is incredibly complex. Some of it is due to the inherent complexity of the problem, but some of it is due to the constraints of the time and some decisions that could have been better.
So there are many things you can improve by restarting from scratch and it is often easier than having to deal with the legacy APIs too.
1. "Android and Chrome OS are built on Linux, a widely used open-source programming language."
Here they mix up the Linux kernel with the Java programming language.
2. "Moving from Linux, though, could have upsides for Google. Android’s use of the technology, which is owned by Oracle Corp., is at the center of a lengthy, bitter lawsuit between the two companies. Shifting away from using Linux would help Google’s legal case that its software isn’t reliant on Oracle."
While here they mix up the Java programming language with the Linux kernel.
I'm curious about this kernel, honestly making something new from the ground up doesn't seem like a good idea.
I wonder how much of an advantage it was for android to use linux as a kernel, but I guess it was a gigantic advantage, which let them focus on what mattered in the development of android.
Other question: any kernel/OS developer here to explain if a micro kernel makes his job easier or harder? Having the flexibility of a micro kernel seems good, but I'm not sure it's that much important.
> making something new from the ground up doesn't seem like a good idea.
It isn't actually terribly difficult, the most difficult part being driver support. By using Linux as a base, Google gained a lot of driver support by default, among other things like a well-known base environment.
> explain if a micro kernel makes his job easier or harder
Well, a microkernel usually has well-defined interfaces that allow drivers to communicate with the kernel, instead of these interfaces being decided by the compiler at compile-time. This in turn offers the guarantees of "ABI/API stability" that the Linux kernel usually offers to userspace programs: drivers don't need to be recompiled to work with a new kernel, so you can actually have binary drivers that continue to "work" long after the vendor stopped working on them. This also offers more room for stability guarantees (a driver that crashes can be restarted, as it's not the kernel panicking), and security (drivers don't have access to each other's data).
On the other hand, you trade a bit of performance and flexibility (from the developer's perspective) for this, by committing not to break compatibility. By now, advantages and inconvenient of microkernels vs monolithic ones are well understood and documented.
What's in for Google is mostly licensing-related: since they're making it; they are free to pick their favourite license. And I am pretty sure Google has been uncomfortable with the GPL for a while now. The same could be said about its hardware partners, and manufacturers that have to provide the source code for their drivers (when they comply at all).
Since a GPL kernel is one of the best things that happened to Android so far (allowing custom roms, open source projects, more transparency), I am extremely weary of fuschia, and looking forward to postmarketos as an alternative to android.
I'd like to know how Zircon compares to L4 (implementations).
When I asked Tanenbaum at FOSDEM why he didn't pick L4 for Minix 3, he just got annoyed and seemed to think I was asking why he didn't just use the L4 OS (which doesn't exist) instead of creating Minix 3 - or something. In any case I didn't get a good answer. He could have created his own implementation if he wanted, L4 is just a specification with a few existing high quality implementations that prove the concept...
Eventually it turned into a disadvantage for them, as chip vendors nowadays ship extremely outdated and insecure versions of Linux and the driver model doesn't allow for frequent updates.
They made a step in the right direction with Project Treble though.
Some advantages of the Fuchsia architecture over Linux for Android:
* Capability based system; applications only get access to objects, including files, directories, other processes, etc via capabilities, so they can only affect those objects they have been given access to directly. This is much better for security and isolation of applications.
* Userspace drivers with a stable ABI, or with the possibility of versioned ABIs. This could allow them to ship updates to the underlying system without waiting for vendors, reducing fragmentation.
I wrote a small Flutter app recently and rather enjoyed the experience. I'm reluctant to spend more time on the technology, though, since it seems like it has a high chance of dying out. But as I understand it, Fuchsia would have native apps written using Flutter as well, which would be great, so I really hope it does take off.
I don't think there's been much in the way of announcements, but yes, this has been in progress for a few years. It's being developed in the open, with a public github repo.
I've been wondering why so many Bloomberg articles have been on the front page recently, maybe in the last 3-6 months. This OP seems like a good example because there has been coverage of Fuchsia from more technical sources for awhile and I doubt the Bloomberg article adds much. Or is the change in frequency of Bloomberg posts just a misperception on my part? I don't have any data.
No matter what, We must need a new OS, encompassing big screen devices as well as small IOT devices. No more JAVA and JVM. I had loved it for 15 years but now I hate it most;
I am sick and tired of developing Android because of the huge fragmentation and poor compatibility of different screen sizes. Now is a little bit better than before in terms of that but the fundamental issue cannot be fixed from the root core unless the kernel and android jvm are replaced. Some Googler said "Android system was wrong from the beginning".
I would love to see Fuchsia in real as soon as possible. I've recently learnt Flutter, which is going to become the primary User interface SDK/framework of Fuchsia. I recommend you guys to learn Dart and Flutter if you are a UI developer. Be leaders of them. In a nutshell, Fu[lutter/chsia] is the future for mobile/embedded developers over the next 30 years in this AI/IoT era.
I can already hear professor Tanenbaum's evil laughter, followed by "I told you so" :)
Although for the life of me, I cannot figure out why Google suffers so hard from NIH syndrome and didn't go with something like seL4/Genode. Do they just want control of absolutely everything they touch?
Surely Google are setting themselves up for another $5G EU antitrust fine?
I thought one of the core reasons for the fine was the restriction in the Mobile Applications Distribution Agreement that a company couldn't develop a competing OS...
Yet Google is?
Alternatively they will use it as the core for a new "Nexus" line to compete with Apple, and not licence Fuscia as a platform (avoiding dominance of the mobile "Platform Market" by doing what Apple are doing).
It sounds very unlikely Fuchsia will replace Android or Chrome OS. They list a bunch of Android issues, but which of these can’t be addressed more incrementally through Android?
Google probably needs fewer OSs, not more.
The idea that this is a senior engineer retention project is what actually makes sense. I think it will probably yield some useful results that can be harvested for their other systems, or perhaps it can fill a niche not already well fillled.
They are. The fact that HN doesn't follow it just speaks to the anti-Microsoft bias here. They've had the OneCore project back in 2015-2016 to unify the kernel and core OS pieces, which was a success and is now powering every Windows device out there from Xbox to the PC. They have the UWP, their unified app framework.
They are also working on CShell, which is a unified UI/windowing/compositing system that will work across PC, Xbox, Mobile, etc.
CShell + OneCore + UWP are essentially becoming part of a "brand new" OS they're calling Core OS, which will strip the Win32 backward compatibility requirements and just work with UWP apps, primarily targeted at devices like phones and low power tablets.
You can search Project Polaris for more information
They tried to rewrite the OS in a C# derivative and could never meet the perf needed while still fighting backwards compatibility issues[0].
At this point mobile OS's are a lost cause, but the PC market is stable. Windows server has never been as big as Linux, but all of Azure runs the Windows hypervisor. I'm not sure they're losing at all actually.
[0]: https://en.wikipedia.org/wiki/Midori_(operating_system)
Not really, they are winning the desktop and tablets (2-1) war.
Desktops aren't going away, and Macs are pretty much an US phenomenon, alongside a couple of other countries.
Likewise, Android tablets aren't that good, with most of the apps being phone apps. Google now is playing with ChromeOS for tablets, which also remains to be seen where it goes.
So, most consumer shops around here are now mostly selling iPads and Windows 10 tablets.
If Fushia/Flutter gets adopted, it would be a better outcome than MS botched effort with universal desktop/mobile apps. The fragmented tooling and support was like it was made by sales/marketing types rather than engineers.
[+] [-] remir|7 years ago|reply
This has been my therory for a while. You see all these different projects competing against each other (multiple messaging apps are a good example) and you think: why is Google so unfocused? But what Google basically wants to do is hoard engineers so they don't leave and go work for competitors and make them stronger (or start their own companies that could compete against Google).
So Google's management figured out that if they give these enginners some cool stuff to work on, they'll stay at the company, even if the stuff they work on is a duplicate of something else the company has already done.
[+] [-] _m96l|7 years ago|reply
That's a lot of money to pay just for retention of people who are not producing anything of value, consuming many other resources (office space, network, hardware, perks), and deeply committed to a project that supposedly will never benefit their employer.
A rich employer may retain an unproductive employee for a limited amount of time if they expect it to ultimately pay off. It just doesn't make any sense to retain someone indefinitely if they're not going to produce anything of value, and (implicitly) will quit the moment you try to put them on any sort of real-world valuable work. Google is a public company with fiduciary responsibilities to its shareholders and a legally accountable board, it can't just throw tens of millions of dollars away without good reason or explanation.
> You see all these different projects competing against each other (multiple messaging apps are a good example) and you think: why is Google so unfocused?
There are many good reasons to have multiple teams competing against each other, building the same product. Often it will bring a strong drive and pace to all competing projects, as well as cross-pollination, and eventually they often merge to a single deliverable that is better than any of the projects could produce individually.
> what Google basically wants to do is hoard engineers
I'm not sure why all these improbable theories make more sense to you than the plain fact that Android was designed quite a few years ago, has many natural deficiencies, and - like all technologies - will eventually be replaced by a superior successor.
That's exactly what Fuchsia is about. Its existence does not require any elaborate conspiracy theory. On the contrary: given how strategically important the Android market niche is for Google, it would be very surprising if Google was not working on a viable successor. It's as if Sony didn't have a successor for the PS4 in the pipeline, and just expected it to sell forever, with minor patches here and there.
[+] [-] kettlecorn|7 years ago|reply
If you look at the industry as a whole products wax and wane based on market trends. Market leading products often struggle to innovate under the weight of their own success and are eventually replaced by a new innovator that's doing something right.
Google, by virtue of creating many different types of products in one category somewhat insulates themselves from this effect. They have effectively infinite money, so from their perspective they can somewhat emulate the greater market internally. They can let "startup" style teams form internally so if someone supplants one of Google's products, it's likely to be a Google team.
There are significant downsides to this (eroding consumer trust) which may take their toll on Google with time.
[+] [-] sharcerer|7 years ago|reply
Taken from reddit: I don't think it will be "starting over," just a major platform change. Imagine Fuchsia being Android 13.0. Every OS maker does a major platform rewrite along these lines eventually.
Windows moved from DOS to the NT kernel.
Apple moved from the classic Mac OS nanokernel (is this the right name?) to the Unix-like XNU kernel with OS X.
Google could trade Linux for Fuchsia's kernel.
These projects are always codenamed something else at first. They always come with big compatibility problems that are overcome with time or emulation layers. Sometimes there are major UI changes, sometimes the UI is built to closely replicate the old OS, but everyone does a huge "reboot" transition like this eventually.
[+] [-] refulgentis|7 years ago|reply
[+] [-] AFNobody|7 years ago|reply
[+] [-] debt|7 years ago|reply
First time I've ever heard this phrase. It's funny because it's true.
[+] [-] ashleyn|7 years ago|reply
[+] [-] drewda|7 years ago|reply
[+] [-] eganist|7 years ago|reply
Of course they did.
A controversial idea, but you know how much easier this would be for everyone if Google offered an option for users to be paid for volunteering your information to them? It's a precedent most fledgling ad companies wouldn't be able to match... even if it's just a few dollars a month, or maybe 30ish bucks a year. It'd cut into Google's bottom line, but it would eradicate the competition.
And then on top of that, you've got the security and privacy wins by baking the product to be secure by default but allowing consumers to accept a paycheck to disable some of it for Google. That risk calculus works for plenty of people (if not for myself).
Google's wins:
• Security and Privacy by default
• Dismantling start-up competition who can't afford to pay for the data they harvest
• Growing marketshare.
Drawbacks:
• Immediate hit to Google's revenue stream
• Permanent assignment of value to data in the perception of consumers
The only big outstanding risk would be posed by rivals with large warchests able to subsidize a similar payment scheme, but honestly once that's done, the winner is a public which now has the ability to monetize their data.
[+] [-] ilikehurdles|7 years ago|reply
[+] [-] thinkingemote|7 years ago|reply
[+] [-] foodstances|7 years ago|reply
[+] [-] megy|7 years ago|reply
Sure, don't they make >95% of all google profits.
[+] [-] kbumsik|7 years ago|reply
How making a new OS achive this? What kind of problems Fuchsia could solve when Linux can’t solve?
I personally hope Fuchsia would remain as an experimental project. A new non-GPL OS by a big player like Google is a bad news for hardware dev and enthusiasts from XDA. This will make hardware driver developments more fragmented and closed-source.
Smartphone manufacturers are trying to hide their kernel and device drivers, even they are using Linux. Imagine there are no legal restrictions to hide those.
[+] [-] kyrra|7 years ago|reply
Android has been trying to fix this with treble[0], which will make many more phones get OS updates going forward. So Android has attempted to work around one of linux major problems.
Another large problem is that Linux was designed for desktop architectures. It's design and focus continues to go that way. This has impact across an entire range of functionality that an OS is supposed to bring.
Fuschia seems to be a research project with a focus on mobile/laptop type devices. It could care less about server type environments, which lets it make different tradeoffs in design.
[0] https://source.android.com/devices/architecture/
[+] [-] blihp|7 years ago|reply
The problems they are likely trying to solve are business and legal, not technical. Pesky things like not having to release keys bits of code under a 'free' license (i.e. they have no choice but to release any changes to the Linux kernel under GPL as that's what it requires.) Sure, they'll probably still release large chunks of source code (possibly under MIT/BSD, possibly under a less liberal license) but keep strategic bits closed source. Right now they have to do this via the clunky and somewhat obvious Google Play services layer. And then there's the constant potential exposure to lawsuits. etc.
By being able to decide on what pieces would be released under what licenses, it would allow them to prevent competitors from following in their footsteps as Amazon and various Chinese companies have done with Android. Things like this are the reason Samsung (one of Google's largest problems) keep pushing forward with their Tizen platform so that when the shift comes they have the ability to sidestep it if they want to.
[+] [-] on_and_off|7 years ago|reply
There is a ton of cruft in the APIs, like any large project would have.
One of the engineer in the Android framework team described creating APIs as generating future regrets.
Some of the mistakes are pretty small. Like internally the system reuse drawable instances in order to save memory, but instead of making this process entirely automatic, before calling let's say `setTint(color)`, you need to call `mutate()` so the UI framework spins a copy of the drawable for you. it would have been easy to integrate this behavior by default without having you know about mutate but since it was done differently, this behavior has been preserved in order to do not break retrocompatibility.
There are many small API issues like this. Big issues of course are corrected but often preserve the old behavior in case you are targetting an old version of the OS.
The View system is incredibly complex. Some of it is due to the inherent complexity of the problem, but some of it is due to the constraints of the time and some decisions that could have been better.
So there are many things you can improve by restarting from scratch and it is often easier than having to deal with the legacy APIs too.
[+] [-] AmericanChopper|7 years ago|reply
I doubt this is really a big deal for Google, but a capabilities based OS lends itself a bit better to the mobile OS security model.
[+] [-] simosx|7 years ago|reply
1. "Android and Chrome OS are built on Linux, a widely used open-source programming language."
Here they mix up the Linux kernel with the Java programming language.
2. "Moving from Linux, though, could have upsides for Google. Android’s use of the technology, which is owned by Oracle Corp., is at the center of a lengthy, bitter lawsuit between the two companies. Shifting away from using Linux would help Google’s legal case that its software isn’t reliant on Oracle."
While here they mix up the Java programming language with the Linux kernel.
[+] [-] zapita|7 years ago|reply
So quietly that they pitched a story about it to Bloomberg.
[+] [-] ant6n|7 years ago|reply
[+] [-] zellyn|7 years ago|reply
[+] [-] jokoon|7 years ago|reply
I'm curious about this kernel, honestly making something new from the ground up doesn't seem like a good idea.
I wonder how much of an advantage it was for android to use linux as a kernel, but I guess it was a gigantic advantage, which let them focus on what mattered in the development of android.
Other question: any kernel/OS developer here to explain if a micro kernel makes his job easier or harder? Having the flexibility of a micro kernel seems good, but I'm not sure it's that much important.
[+] [-] MayeulC|7 years ago|reply
It isn't actually terribly difficult, the most difficult part being driver support. By using Linux as a base, Google gained a lot of driver support by default, among other things like a well-known base environment.
> explain if a micro kernel makes his job easier or harder
Well, a microkernel usually has well-defined interfaces that allow drivers to communicate with the kernel, instead of these interfaces being decided by the compiler at compile-time. This in turn offers the guarantees of "ABI/API stability" that the Linux kernel usually offers to userspace programs: drivers don't need to be recompiled to work with a new kernel, so you can actually have binary drivers that continue to "work" long after the vendor stopped working on them. This also offers more room for stability guarantees (a driver that crashes can be restarted, as it's not the kernel panicking), and security (drivers don't have access to each other's data).
On the other hand, you trade a bit of performance and flexibility (from the developer's perspective) for this, by committing not to break compatibility. By now, advantages and inconvenient of microkernels vs monolithic ones are well understood and documented.
What's in for Google is mostly licensing-related: since they're making it; they are free to pick their favourite license. And I am pretty sure Google has been uncomfortable with the GPL for a while now. The same could be said about its hardware partners, and manufacturers that have to provide the source code for their drivers (when they comply at all).
Since a GPL kernel is one of the best things that happened to Android so far (allowing custom roms, open source projects, more transparency), I am extremely weary of fuschia, and looking forward to postmarketos as an alternative to android.
[+] [-] ahartmetz|7 years ago|reply
When I asked Tanenbaum at FOSDEM why he didn't pick L4 for Minix 3, he just got annoyed and seemed to think I was asking why he didn't just use the L4 OS (which doesn't exist) instead of creating Minix 3 - or something. In any case I didn't get a good answer. He could have created his own implementation if he wanted, L4 is just a specification with a few existing high quality implementations that prove the concept...
[+] [-] sergiomattei|7 years ago|reply
They made a step in the right direction with Project Treble though.
[+] [-] lambda|7 years ago|reply
There's some discussion of it already on HN: https://news.ycombinator.com/item?id=16813796
Some advantages of the Fuchsia architecture over Linux for Android:
* Capability based system; applications only get access to objects, including files, directories, other processes, etc via capabilities, so they can only affect those objects they have been given access to directly. This is much better for security and isolation of applications.
* Userspace drivers with a stable ABI, or with the possibility of versioned ABIs. This could allow them to ship updates to the underlying system without waiting for vendors, reducing fragmentation.
[+] [-] Symmetry|7 years ago|reply
[+] [-] losvedir|7 years ago|reply
[+] [-] _bxg1|7 years ago|reply
https://arstechnica.com/gadgets/2018/01/googles-fuchsia-os-o...
[+] [-] caycep|7 years ago|reply
[+] [-] notatoad|7 years ago|reply
[+] [-] forapurpose|7 years ago|reply
[+] [-] c0d3man|7 years ago|reply
[+] [-] martin1975|7 years ago|reply
Although for the life of me, I cannot figure out why Google suffers so hard from NIH syndrome and didn't go with something like seL4/Genode. Do they just want control of absolutely everything they touch?
[+] [-] infinity0|7 years ago|reply
Cargo.toml links to https://fuchsia.googlesource.com/garnet/
[+] [-] techsin101|7 years ago|reply
Fuschia is getting swift support Flutter runs on fuschia Flutter uses dart
Do I learn dart or swift, personally I want to learn swift. Flutter only supports dart??? Fuschia supports swift
Is flutter going to support swift
[+] [-] robocat|7 years ago|reply
I thought one of the core reasons for the fine was the restriction in the Mobile Applications Distribution Agreement that a company couldn't develop a competing OS...
Yet Google is?
Alternatively they will use it as the core for a new "Nexus" line to compete with Apple, and not licence Fuscia as a platform (avoiding dominance of the mobile "Platform Market" by doing what Apple are doing).
[+] [-] jmull|7 years ago|reply
Google probably needs fewer OSs, not more.
The idea that this is a senior engineer retention project is what actually makes sense. I think it will probably yield some useful results that can be harvested for their other systems, or perhaps it can fill a niche not already well fillled.
[+] [-] eej71|7 years ago|reply
[+] [-] endlessvoid94|7 years ago|reply
[+] [-] wpdev_63|7 years ago|reply
[+] [-] 013a|7 years ago|reply
They are also working on CShell, which is a unified UI/windowing/compositing system that will work across PC, Xbox, Mobile, etc.
CShell + OneCore + UWP are essentially becoming part of a "brand new" OS they're calling Core OS, which will strip the Win32 backward compatibility requirements and just work with UWP apps, primarily targeted at devices like phones and low power tablets.
You can search Project Polaris for more information
[+] [-] cptskippy|7 years ago|reply
[+] [-] muricula|7 years ago|reply
[+] [-] pjmlp|7 years ago|reply
Desktops aren't going away, and Macs are pretty much an US phenomenon, alongside a couple of other countries.
Likewise, Android tablets aren't that good, with most of the apps being phone apps. Google now is playing with ChromeOS for tablets, which also remains to be seen where it goes.
So, most consumer shops around here are now mostly selling iPads and Windows 10 tablets.
[+] [-] s73v3r_|7 years ago|reply
[+] [-] coding123|7 years ago|reply
[+] [-] karmakaze|7 years ago|reply