29 ms·

Expanding Fuchsia's open source model

387 points by tbodt 6y ago

Ericson2314 6y ago
I hope this doesn't mean they are divesting.
kace91 6y ago
I'm still not clear on what fuchsia is trying to be - or more specifically, why is Google developing it. What is the end goal here, from a business perspective?
- claydavisss 6y ago
  an OS Google can control. Open source just like Go is open source - you are free to download and use it, but Google controls it.
- bun_at_work 6y ago
  I remember reading a couple years ago that the goal is IoT devices. It runs on the Zircon kernel, which is a true microkernel (as I remember, haven't been paying attention recently). This is pretty ideal for IoT, since manufacturers should be able to spin up only as much OS as they need on top of the Zircon kernel. Fuchsia specifically is looking to be a full-fledged OS, I think, for devices like Chromebooks or similar. I think they expect to get Fuchsia to a place where it can run Android apps natively, then put out an OS that can run native apps, Android apps, etc, all while being tied in to Google's services. This is definitely some speculation, but that's what I'm seeing so far.
  - cogman10 6y ago
    It gives google the ability to thwart a major security problem that android has. That is, manufacturers choosing to drop support for a device. Because the important parts of Fuchsia are all controlled by google, it means they can theoretically keep devices running and up to date indefinitely. They can control the majority of the software while manufactures only need to supply their drivers. Manufacturers dropping driver support, while bad, isn't the end of the world. It's a much smaller attack vector than the whole kernel never getting updates.
    - bun_at_work 6y ago
      That's some good insight. Thanks! I hadn't considered that Android issue.
- jtsiskin 6y ago
  It’s already running on some of their embedded devices, such as google home. A capability based OS with a micro kernel sounds great to me. Things like the networking stack can run in user space, and be written in memory safe languages like Rust. An OS that “can’t” get viruses or be hacked sounds pretty desirable. Cynically it makes things like “jail breaking” a google home much more difficult.
  - TACIXAT 6y ago
    >An OS that “can’t” get viruses or be hacked sounds pretty desirable. Cynically it makes things like “jail breaking” a google home much more difficult. I don’t think these claims hold. It is still written in a memory unsafe language, so exploitation is totally possible. As well, for malicious software you’re just looking for a process handing out high privilege handles.
    - bestorworse 6y ago
      > for malicious software you’re just looking for a process handing out high privilege handles In the end, that is true. But the thing is the way Fuchsia's implementation of the 'capability security model' is done. The capabilities a process (or, a 'component' in Fuchsia's model) use/consume are explicitly given to it. And this scheme is implemented in a way that is easy to see and account for where/from these capabilities are going to/from. An process can do nothing that is not provided by the capabilities it got during creation. Of course, components might be buggy/malicious and leak capabilities. But the security holes bottleneck in this capability routing scheme, so even with buggy/malicious components, it's much easier to audit and fix. And from an attacker perspective, it's much harder to reach a component given the routing path of capabilities that it's received.
      - TACIXAT 6y ago
        I expect it will be very much the same as drivers we have today, where you have some game anti-cheat rootkit that has a bug in it. In Fuschia's case it will be like that but the exploitation either gives you access to that driver's capabilities, or simply that driver is giving out handles with permissions insufficiently removed from them. It will be cool to see a full system audit of capabilities, but I don't think that analysis exists yet.
- baybal2 6y ago
  > why is Google developing it. They want to get a Linux free OS.
- deleted 6y ago
  [deleted]
- dekhn 6y ago
  the goal is to be a foundation for future embedded devices that doesn't have the many challenges associated with linux-based systems, specifically around security, isolation, and firmware updates while also defining a simple and straightfoward presentation model to app developers.
- swiley 6y ago
  Google thinks the GPL in the kernel is the problem with Android.
mmastrac 6y ago
I've heard Fuchsia referred to as a "principal engineer retention project" at Google. I'd be curious to know if others have heard the same.
- Kinrany 6y ago
  I wonder if this could be turned into a better way to fund public research.
- notatoad 6y ago
  i've definitely heard that said before here on HN. are you hearing it referred to that way internally at google?
  - deleted 6y ago
    [deleted]
- abarth 6y ago
  As a principal software engineer that works on Fuchsia, I can assure you that the project does not exist solely to retain me. :)
  - jacobush 6y ago
    ... but also your colleagues?
  - suchire 6y ago
    Not solely, but in part? ;-)
  - swetland 6y ago
    Congrats on the promo! It didn't retain me (though I didn't get promoted to Principal, so maybe I don't count) but I did enjoy working on Fuchsia. Nice to see much of the syscall design seems to have survived.
    - abarth 6y ago
jsnell 6y ago
I find it kind of hilarious how large a proportion of the roadmap is just migrations of various kinds. If the goal here was to encourage external contributions, I can't imagine a much worse sales pitch.
- bestorworse 6y ago
  I see it as better way of developing a product. Or actually, a foundational system, if Fuchsia really ends up becoming something like that. You see, lots of things that today are fundamental were just "developed organically", and that is OK because people never tought that it would end up being what it is. Besides, a greater part of the cruft we have today is rooted in the development model companies adopt that is "develop it, make it work, and ship so not to delay the schedule/budget so much". And that is OK too given that companies just want to develop a product and don't have lots of time, budget and resources... But, as things are in software engineering, that model doesn't produce as good a piece of software as it would with more iterations and refactoring seeking the best software model and implementation. In the end, that results in greater issues issues than what was really needed and the backward compatibility hinders an actual solution. But Fuchsia being meant as a foundation, cannot be developed like that. Like a product that "just works". It would end up being just another bad designed (and chances are, bad implemented too) system based on concepts of the beginnings of computer industry that doesn't necessarily apply for today's systems. As I've loosely accompanied Fuchsia's development, they've done a lot of early bring up work just so that other parts of the system could be developed. And that is expected because they developed arguably almost everything from scratch. You cant expect ending up with really great system design and implementation just from these first iterations. Then, with the experiences from that, they've done lots of refactorings that refined system's abstractions, APIs and implementation. And, if they are serious about Fuchsia being a good foundational system, they have to solve these left over from the early development.
  - wmf 6y ago
    Sure, but if Fuchsia is 100% grunt work and there's nothing cool to do in the project it's not going to attract outside contributors.
nicoburns 6y ago
Wish they'd use this kind of development model for Android!
deleted 6y ago
[deleted]
brandmeyer 6y ago
Looks like you still cannot contribute without granting copyright ownership to Google. In turn, GOOG licenses it out under a BSD (or BSD-like) license. This is a big difference relative to Linux, and its part of why Linux works so well as a collaboration between competitors. The GPL's copyleft acts as a joint development agreement between equals. IMO, Fuchsia's model only works well for integration partners that are willing to act as sharecroppers in the ecosystem. That certainly does work for some device manufacturers, but it cannot serve as the foundation of a new Free operating system.
- hollerith 6y ago
  ADDED. Looks like this comment and its replies have no relevance to the Fuchsia project: https://news.ycombinator.com/item?id=25348935 https://news.ycombinator.com/item?id=25348935 You used to not be able to contribute to most GNU projects (maybe you still can't) without assigning copyright ownership to the FSF. I don't see what practical difference the assignment to Google will make. Without using the words "equality", "between equals" and "sharecropper", can you give an example of something you or I will not be able to do with the code that you or I would have been able to do if the copyright had remained with the contributors?
  - brandmeyer 6y ago
    Linux itself has never been a GNU project and has never required copyright assignment. It is the combination of features (retain ownership and GPL) together that has enabled collaboration in Linux.
    - hollerith 6y ago
      Are you saying that collaboration on Gnu Compiler Collection, binutils, bash, bison, CLISP, coreutils, etc, has been inhibited by the requirement for copyright assignment to the FSF?
      - brandmeyer 6y ago
        There's a big difference between GNU and Linux in terms of their collaboration. With the exception of GCC, most of the utilities you named have been maintained by a very small group of people. GCC itself has definitely been inhibited by the copyright assignment. There have been a few different ports that were not upstreamed specifically because of the CLA. AVR32 and C6000 come to mind off the top of my head.
outside1234 6y ago
That is the most hideous source control system ever. Do they really need to be developer hostile just because Github is owned by Microsoft? I mean seriously, who has time to commit to a project with a random set of tooling.
- eropple 6y ago
  I've never worked at Google, but I've used Gerrit not infrequently at jobs and on projects--it isn't "random" even if you've never run into it before. Gitiles is just a hat on top of it; it's not pretty but it is fast. It's not "developer hostile" to not use Github. Git works everywhere. It might mean that to contribute to an operating system a developer may have to learn how to use something that isn't Github, but honestly if that's a bar to contribution for somebody they probably weren't gonna anyway.
  - deleted 6y ago
    [deleted]
- ocdtrekkie 6y ago
  Google uses GitHub for a bunch of things, I suspect it is more that the people working on it want to use Google's internal tooling as much as possible, and public user experience is considered less important than that.
  - bun_at_work 6y ago
    This is the right answer. Google has tons of internal tooling and libraries and frameworks that are all just internal to Google.
    - kerneis 6y ago
      That may be true for Google in general, and internal code in particular, but that's definitely not the case for Fuchsia. We use the tools and interfaces available to the public to work on the code base: code search to browse the code, gerrit for reviews and monorail for tracking bugs.
baybal2 6y ago
Sundar, do you think we will believe you? Google will bait and switch you again, like it did with Android.
- EvilEy3 6y ago
  Can you elaborate on Android part?
  - baybal2 6y ago
    Does it need elaboration? Android too was advertised as a nearly "community driven" OS. Few years down the line, and good sales, and they turn Android into a locked down hell, start to stonewall communications with contributors, throw musings about community governance out of the windows, and break pledge to never block the adblock, nor introduce political censorship on the Android Store.
  - CivBase 6y ago
    I believe he's referring to how Android phones have slowly become more and more dependent on the closed-source Google Play Services to provide essential functionality. Despite Android itself being "open source", many Android devices and apps are useless without Google's proprietary services.
    - bogwog 6y ago
      > many Android devices and apps are useless without Google's proprietary services. And not, in fact, open source. Due to the non-GPL license, every single Android device out there is effectively running a closed-source fork of AOSP. I had an old Samsung device automatically install TikTok when I powered it on after sitting in a drawer for years. TikTok didn't even exist when I bought the phone, yet someone with more control over my device than me sold the remote access (they gave themselves, without my consent) to TikTok. Of course this is not a new development, but the proprietary BS and Google's increasingly evil actions over the past decade really highlight how much of a problem that is. Trusting Fuchsia is just repeating that mistake.
methodsignature 6y ago
So maybe open source, [mostly] closed ecosystem? Add a bunch of Spyware from Google and get every app maker to add a dependency to Google services and they are golden for the collection of data on all your "smart" things Sorry/not sorry for the cynicism; I feel it is warranted given what "open source" means on Android. Google talking like they have noble open source ambitions means nothing. They have a lot of amends to make before they begin to seem like a win for society and the industry and they seem to be going in the opposite direction.
- jmnicolas 6y ago
  yeah the base open sources Android is barely usable. Even simple things like getting a local notification at the right time are not a given. If they do the same with Fuschia, they'd better make it closed sources then.
  - actuator 6y ago
    Sorry, not familiar with Android core. For your example, how would it work without proprietary technologies? AFAIK, Android uses GCM for notifications. Adding integrations for it don't seem to make much sense in core open source Android as that will make you tied to Google's ecosystem.
    - zepto 6y ago
      An open platform would have a framework that supports multiple back ends.
      - actuator 6y ago
        This would be definitely nice to have but why does core Android itself need to have support for every feature? We can have open source OSs on top of Android that build with a specific service set. Sort of how Ubuntu builds over Debian.
        6y ago
swiley 6y ago
The one singular nice thing about android was that the kernel was GPL. This put a (rather high) limit on the stupidity that could go on. Fuchsia changes that.
205g0 6y ago
OT: Just a second ago, I was setting up unattended-upgrades for security updates for a new Ubuntu box and I am once again puzzled why the largest Linux distribution has such an underwhelming UX for an crucial feature. Long story short, I welcome any new contender in the OS space.
- yjftsjthsd-h 6y ago
  > I am once again puzzled why the largest Linux distribution has such an underwhelming UX for an crucial feature Are we talking about Ubuntu, or Android? Because honestly in either case... what would you improve? Ubuntu has updates rolled into GNOME's package management frontend and it's seemed to work well, and Android has decent UX around updates (especially with A/B system partitions) although of course it suffers from vendors not actually releasing updates.
- e12e 6y ago
  What's underwhelming about?: sudo apt install unattended-upgrades
  - deleted 6y ago
    [deleted]
  - 205g0 6y ago
    You have to touch two config files. One is easy but the other one needs a bit of googling, nothing major but yeah why at all this? Auto-updating security updates should be the default if you run servers in the wild.
    - e12e 6y ago
      > You have to touch two config files. Not if you just want automatic security updates? The package is part of the server task, and defaults to installing security updates. It does not install other updates, and does not automatically reboot. > Auto-updating security updates should be the default if you run servers in the wild. It pretty much is (for Ubuntu server)?
- 6y ago
flotzam 6y ago
If contributing to your project requires much more than git commit --signoff — in Fuchsia's case, a full-on Google Account! — this will exclude many pseudonymous developers who conceive of things such as privacy in terms of capabilities (not pinky promises). Which seems relevant for a security-focused OS.
- snazz 6y ago
  I'm guessing that most of these pseudonymous developers—of which there can't possibly be too many—would distrust Google enough not to contribute even if it were easier to do so without a Google Account.
  - flotzam 6y ago
    Uneasy bedfellows but nah. Some pockets inside of Google (like AOSP) are, on balance, still beneficial. What a world.
  - rhn_mk1 6y ago
    As a pseudonymous developer, I fail to see any harm in contributing to projects run by Google in general. Fuchsia is not a monopolist way to exert control over the market (not today at least), it doesn't seem to be explicitly made for evil, and can be forked to let the community steer it.
    - Jnr 6y ago
      I would not be surprised if Google account ToS has some point that complicates things for contributors or people forking the code. I haven't read Google ToS lately so I can't say there is something like this but that document is huge and keeps changing all the time. If I was a pseudonymous developer, I would probably not go through that.
    - zepto 6y ago
      Since Fuschia seems to be a replacement for Android, why would you think it isn’t a way for Google to exert control over the market? As for forking, that option only becomes practical if the community version can muster adequate resources versus the Google controlled version.
bla3 6y ago
> It has support for a limited set of x64-based hardware Did anyone get it to run on a raspberry pi yet? There has to be _some_ arm support...
- dhodell 6y ago
  There is not a RPi port, and that's non-trivial for reasons I vaguely recall to be related to display driver weirdness. The system does run on arm64le.
cute_boi 6y ago
Google and Opensource a joke of century. Chrome -> Make chromium opensource but add spyware that phones home on every second and with new manifest v3 make sure extensions like ublock origin don't work Andriod -> Make tip of iceberg opensource but force every vendor to use Service and lock down whole ecosystem around it. And make sure there is no way to block ads on youtube for andriod. Fuchsia -> Initial Stage make people think they are open they are helping community for first 5-10 years. After that implant spyware etc. Same strategy different form === Modern Polymorphism by Modern Liars.
- actuator 6y ago
  > Make chromium opensource but add spyware that phones home on every second Chromium homes every second? That seems interesting. It has been a long time since I last used Chromium. Does it also come with Google auth now? > Make tip of iceberg opensource but force every vendor to use Service and lock down whole ecosystem around it. If they add Google specific services into core Android is it not worse? Companies like Amazon and a lot of Chinese companies seem to be fine with using just the core Android.
  - aravindet 6y ago
    > If they add Google specific services into core Android is it not worse? Not necessarily. Take for example push notifications - the push notification client could be part of the OS, with build configurations to specify a server or disable this altogether. Or, given OS update issues, Google Play Services could be a separate open source project with the Google URLs and keys supplied as build configs.
- ceras 6y ago
  I don't know, I think there's a couple examples of these open source projects gaining non-Google traction: - The new Edge, Opera, and Brave are based on Chromium - China has a huge ecosystem of non-Google Android devices Google does exert strong control of their open source code, and Google is clearly the prime beneficiary of them, but the external world has still leveraged these projects nonetheless
hortense 6y ago
Anyone else bothered by the black banner saying "Google is committed to advancing racial equity for Black communities" in technical documentation (https://fuchsia.dev/fuchsia-src/contribute/roadmap https://fuchsia.dev/fuchsia-src/contribute/roadmap) ? This is simply an advertisement for Google, and just like any other advertisement it has nothing to do in technical documentation, especially in a project where they want other companies to contribute.
- mushufasa 6y ago
  I'm not bothered -- I like it. I would like it even more if they acted upon the claim.
- SquareWheel 6y ago
  Not bothered in the least.
- garaetjjte 6y ago
  I didn't even notice it. My brain filtered it out as some another ad..
outworlder 6y ago
> Fuchsia is a long-term project to create a general-purpose, open source operating system Why do we need this? We have Linux. It works. It is open-source, general purpose. It needs more support to become more mainstream (like what Valve has done with Proton). Don't like Linux? Start with one of the BSDs. Heck, start with Haiku. Any of these projects are lightyears ahead of anything that's just starting. The most likely explanation is that _we_ don't need this, but Google does, for some strategic purpose. It must be for some pretty compelling use-case, because we know how happy they are to kill projects.
- asadawadia 6y ago
  They need work to give their thousands of devs
- vondur 6y ago
  Is there anything in Fuchsia that may be usable in Linux? I'm specifically thinking of something like a window manager?
- endymi0n 6y ago
  Why do we need Krita when we have GIMP? Because every once in a while, it‘s easier to free yourself from the shackles of architectural decisions that were made because of the hardware and constraints of their time that are obsolete now but are supported for legacy reasons. A security model that is designed from scratch into such a deep OS concern as with Fuchsia is one of the aspects that would be next to impossible to bolt onto such a conplex project such as Linux or BSD. I‘m not saying it will play out, but it certainly brings a wave of fresh and radical new ideas into open source operating systems I haven‘t seen since the times of BeOS and Plan 9.
  - bayindirh 6y ago
    For me, OS research is always good. Experimenting from ground up is even better. But Minix, the hero of the Microkernel research, became the guardian of Intel systems and preventer of tinkering and exploration. Can we certainly say that Fuschia will be Free and mild natured like BSD and Linux or will it become another silent "hard-layer" like Minix? GP (and I) certainly fear about the latter. Given Google's transformation to Modern day Microsoft of the 90s, it's not too far-fetched it seems.
jasonvorhe 6y ago
I don't understand the cynicism here. Android's fragmentation was the original sin that lead to fragmentation and the new that we've seen for years, until Google semi-fixed the mess with a) Play Services (short term) and b) Project Treble. Google were so convinced of the value of open source that they didn't anticipate that almost all OEM's would rather ship their Android forks than to stay close to upstream. If they hadn't intervened, Android as a platform would be useless by now and app developers would need to implement various ways of handling notifications, storage access, etc just to ship their apps to a broad audience of device owners, Samsung would've never upped their update game and there wouldn't be 2-3 versions of Android on the majority of devices, but more like 5-10, depending on how many manufacturers would've survived in the market. Android still allows for easy side loading of applications, there are still major independent after market Android versions out there, you can develop for Android in various languages, using a huge selection of IDEs and there's open source alternatives to Play Services that Google neither litigates against nor seems to actively fight against. Google didn't even manage to gain any relevant market share with their Pixel line of devices, of which most run Android. They could've done a lot of nefarious things by keeping newer Android versions Pixel exclusive until they publish the source code to OEMs, for example. Instead, they are making it easier to quickly move an existing Android code base to the latest version by abstracting away a lot of the complexity (project treble). Is Google still primarily am advertising company that tracks its users? Of course. Do they have their own motives to keep Android at the top of the mobile OS market? Of course. But a lot of the comments see evil scheming where Google probably had to act quickly to ensure that Android has a future and that developers didn't lose interest in the platform in favor of iOS.
- peey 6y ago
  > there's open source alternatives to Play Services that Google neither litigates against nor seems to actively fight against AFAIK these are reverse-engineered. Do you sincerely believe that developers' time is best spent reverse engineering and maintaining play services alts to undo a blockade that Google put in, just to be able to get full freedom over their android derivative? Wouldn't it be better spent in playing with cool new tech (as Google engineers seem to be doing)?
deleted 6y ago
[deleted]
peey 6y ago
AOSP is an open source project, which is impractical for any business to run because of apps' reliance on proprietary google play services. Chromium is an open source project, but proprietary chrome has the largest browser market share and they like to abuse their position to not play well with standards bodies. Google can develop Fuchsia. It'll even be cool piece of tech, but I do not for a second believe that contributing to the project would benefit anyone but Google.
- rhencke 6y ago
  Chromium, as built in many open-source distributions, uses a per-distribution Google API key for service access. [1] [2] [3] If built without API keys, Chromium warns 'Google API keys are missing. Some functionality of Google Chrome will be disabled.' [4] [5] The APIs used include [6]: * Calendar API * Contacts API * Drive API (Optional) * Chrome Remote Desktop API * Chrome Spelling API * Chrome Suggest API * Chrome Sync API * Chrome Translate Element * Chrome Web Store API * Chrome OS Hardware ID API (Optional, Chrome OS) * Device Registration API (Optional, Chrome OS) * Google Cloud DNS API * Google Cloud Storage * Google Cloud Storage JSON API * Google Maps Geolocation API (Optional) * Google Maps Time Zone API * Google Now For Chrome API (Optional) * Nearby Messages API * Safe Browsing API * Speech API [1] https://git.alpinelinux.org/aports/tree/community/chromium/APKBUILD?id=24fcf2cf771de488a261f8c4ad06e31b61402ed1#n192 https://git.alpinelinux.org/aports/tree/community/chromium/A... [2] https://github.com/archlinux/svntogit-packages/blob/packages/chromium/trunk/PKGBUILD#L62 https://github.com/archlinux/svntogit-packages/blob/packages... [3] https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/tree/build/args.gn?h=stable#n1 https://git.launchpad.net/~chromium-team/chromium-browser/+g... [4] https://chromium.googlesource.com/chromium/src/+/9a11dadde80a2e309445f1f33b75a95fe51358d9/chrome/app/google_chrome_strings.grd#491 https://chromium.googlesource.com/chromium/src/+/9a11dadde80... [5] https://sources.debian.org/patches/chromium/83.0.4103.116-1~deb10u3/disable/google-api-warning.patch/ https://sources.debian.org/patches/chromium/83.0.4103.116-1~... [6] https://www.chromium.org/developers/how-tos/api-keys https://www.chromium.org/developers/how-tos/api-keys
  - rhencke 6y ago
    To elaborate, the following distributions of Chromium are violating the Google API terms of service [1] [2] by publishing the API secret key publicly in the build source code responsible for building Chromium: * Alpine Linux (community port) - https://git.alpinelinux.org/aports/tree/community/chromium/APKBUILD?id=7f866234e512a34d9758a6cee5b8edfba2147c4f#n192 https://git.alpinelinux.org/aports/tree/community/chromium/A... * Arch Linux (svntogit, AUR) - https://github.com/archlinux/svntogit-packages/blob/1e8f3fe75e060ea70553b32926185bec84561e32/trunk/PKGBUILD#L67 https://github.com/archlinux/svntogit-packages/blob/1e8f3fe7... - https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=chromium-dev&id=0ea1e1fad209a7ca2552fbe6efaf9e49c732b8d8#n111 https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=chrom... * Fedora Linux - https://src.fedoraproject.org/rpms/chromium/blob/e78656ce58dd9e7417433461df24e191eaf41b29/f/chromium.spec#_171 https://src.fedoraproject.org/rpms/chromium/blob/e78656ce58d... * Gentoo - https://github.com/gentoo/gentoo/blob/9acf51b665b6f4b5b97edb871da588c4e870e9b3/www-client/chromium/chromium-89.0.4343.0.ebuild#L624 https://github.com/gentoo/gentoo/blob/9acf51b665b6f4b5b97edb... * OpenSuSE - https://build.opensuse.org/package/view_file/openSUSE:Factory/chromium/chromium.spec https://build.opensuse.org/package/view_file/openSUSE:Factor... * Slackware - http://www.slackware.com/~alien/slackbuilds/chromium/build/chromium_apikeys http://www.slackware.com/~alien/slackbuilds/chromium/build/c... * Ubuntu, Linux Mint (Canonincal Chromium Snap) - https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/tree/build/args.gn?h=stable&id=af9ed0cec8cdfcc2972b8a3e13a750516b358211#n3 https://git.launchpad.net/~chromium-team/chromium-browser/+g... [1] https://developers.google.com/terms https://developers.google.com/terms (specifically: "You will only access (or attempt to access) an API by the means described in the documentation of that API. If Google assigns you developer credentials (e.g. client IDs), you must use them with the applicable APIs. You will not misrepresent or mask either your identity or your API Client's identity when using the APIs or developer accounts." and "Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects.") [2] https://www.chromium.org/developers/how-tos/api-keys https://www.chromium.org/developers/how-tos/api-keys (specifically: "Note that the keys you have now acquired are not for distribution purposes and must not be shared with other users.")
twh270 6y ago
Is there any comparison between Fuchsia and the Genode OS, which is also capability-based? I'm wondering what one has/does that the other doesn't?
- snvzz 6y ago
  Fuchsia is an OS. Genode's a framework for creating operating systems. It's not comparable. What's interesting imho is to compare seL4 with zircon. The former is a third generation microkernel. The latter is still a first generation microkernel or, according to google, not a microkernel at all. It's thus not very interesting from a computer science perspective. In practical terms, I'm sure it'll be better than Linux and IOS/OSX, but that's a very low bar to meet.
  - mlinksva 6y ago
    How about an OS using the Genode framework, Sculpt OS https://genode.org/download/sculpt https://genode.org/download/sculpt IIUC, compared to Fuchsia? Apart from their kernels, which you've addressed.
barnacled 6y ago
I am a Linux kernel contributor and former golang and chromium contributor and to be honest the latter experiences makes me leary about contributing to another Google project. There generally tends to be an insular 'cathedral' rather than 'bazaar' approach to Google projects where those working for the company get considerably more say and control than outside contributors. The whole issue I have with it is that they pretend otherwise. With go many people laboured under the misapprehension that they could have more input than was actually possible. Not so different with chromium. The cathedral model is fine but be honest about it. With the Linux kernel if you have a good idea and can defend it you have a genuine chance of contributing. So I know my limited spare time efforts aren't wasted. With fuchsia I couldn't be so sure. I hope I am wrong but the fact they are only now taking potential contributions suggests otherwise.
- jeffrallen 6y ago
  I'm a longtime Go watcher, and sometime Go contributor and I agree with this, 100%. Go has benefitted from having a BDFL employed by Google. But outsiders will always be outsiders.
  - barnacled 6y ago
    While I think Russ is brilliant and deeply qualified for that role, his BDFL position differs considerably from that of e.g. Guido (well pre resignation) or Linus in that he is considerably more 'D' than either of them. And probably that works well for go and keeps a very clear philosophy and style for the language. It is just the fact they very blatantly misled the community on the scope of possible contributions that frustrates me. Fuschia does, in all fairness, appear to be considerably more honest on these issues.
- dhodell 6y ago
  It's kind of unfortunate because existing developers have the privilege of experience with the systems and where they're going that external contributors simply don't have, and it will take a non-trivial amount time for interested parties to develop that knowledge. At the same time, it is an active project with active development that are informed by goals and processes not all of which are open. And really, while the development has been "in the open", it hasn't engaged the public until now. To that end, it's not possible to engage in a "bazaar" approach off the bat, whether or not that's a goal of the project. Having been active in Go development and seeing some of the issues there, I understand what you mean. I don't think we state anywhere "this is clearly a cathedral model of development", but I think we're pretty clear on it: * We have a section of documentation on project governance https://fuchsia.dev/fuchsia-src/contribute/governance https://fuchsia.dev/fuchsia-src/contribute/governance * We have a section of documentation detailing different kinds of contributors, acknowledging that there are kinds of contributors with special powers, and also reserving the right to revoke contribution privileges in some cases: https://fuchsia.dev/fuchsia-src/contribute/community/contributor-roles#specialized-roles https://fuchsia.dev/fuchsia-src/contribute/community/contrib... To the extent that you can look at these as a set of policies, follow all the policies, submit a change, and have that change rejected, I think that is unfortunate. I think this is much less likely if you first engage with the stakeholders, and having opened up mailing lists, we've made it simpler to do that. However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion. I can fork the repo, but that's also already the case with Fuchsia. > the fact they are only now taking potential contributions We were honest about this too, and our documentation used to explicitly say that we did not accept external contributions.
mtgx 6y ago
Still seems like a wasted opportunity not to have Fuchsia or at least Zircon developed in Rust. Who knows how many development man hours and security bugs and data breaches will that single decision saved over the next several decades.
ender7 6y ago
I'm a little sad that there aren't any comments describing what is technically novel around Fuchsia and why it is/why it isn't interesting from an OS design standpoint. I get the sense that its advances are probably too low-level for most app developers to care, but that's kind of precisely why I'd love a comment elucidating them a bit. Edit: For example, the Fuchsia docs list the primary talking points as secure, updatable, inclusive, and pragmatic. How well does it live up to those principles? Will they bring practical benefits? What's exciting/new about what's being done here?
- abarth 6y ago
  https://fuchsia.dev/fuchsia-src/concepts https://fuchsia.dev/fuchsia-src/concepts has an overview and links deeper into the site for more detailed information.
- sanxiyn 6y ago
  Fuchsia is a capability OS. I think that's enough to interest anyone interested in secure OS.
owaislone 6y ago
Fuchsia will e to Android and ChromeOS what Servo is/was to Firefox. Eventually the guts of Android and ChromeOS will be replaced with Fuchsia while end users won't see a radical change. It might feel like moving from XP to Vista or OS 9 to OS X.
- pier25 6y ago
  Hopefully not to Vista :)
markdog12 6y ago
Would love to see what it looks like: https://fuchsia.dev/fuchsia-src/concepts/graphics/scenic/scenic https://fuchsia.dev/fuchsia-src/concepts/graphics/scenic/sce...
Schnitz 6y ago
Remember Android? It’s a trap!
tgerdin 6y ago
Let's hope Fuchsia fares better than Hurd. Also, I guess the adoption of Fuchsia will be a litmus test of the GPL. Will its possibly technical merits outweight the strength of GPL to avoid fragmentation? I suspect the GPL has served Linux very well in this regard. Given Google's muscles it will most likely have an impact in the mobile world, but whether it will reach beyond into the area of general computing is less certain.

387 points by tbodt 6y ago

I hope this doesn't mean they are divesting.

I'm still not clear on what fuchsia is trying to be - or more specifically, why is Google developing it. What is the end goal here, from a business perspective?

claydavisss 6y ago
an OS Google can control. Open source just like Go is open source - you are free to download and use it, but Google controls it.
bun_at_work 6y ago
I remember reading a couple years ago that the goal is IoT devices. It runs on the Zircon kernel, which is a true microkernel (as I remember, haven't been paying attention recently). This is pretty ideal for IoT, since manufacturers should be able to spin up only as much OS as they need on top of the Zircon kernel. Fuchsia specifically is looking to be a full-fledged OS, I think, for devices like Chromebooks or similar. I think they expect to get Fuchsia to a place where it can run Android apps natively, then put out an OS that can run native apps, Android apps, etc, all while being tied in to Google's services. This is definitely some speculation, but that's what I'm seeing so far.
- cogman10 6y ago
  It gives google the ability to thwart a major security problem that android has. That is, manufacturers choosing to drop support for a device. Because the important parts of Fuchsia are all controlled by google, it means they can theoretically keep devices running and up to date indefinitely. They can control the majority of the software while manufactures only need to supply their drivers. Manufacturers dropping driver support, while bad, isn't the end of the world. It's a much smaller attack vector than the whole kernel never getting updates.
  - bun_at_work 6y ago
    That's some good insight. Thanks! I hadn't considered that Android issue.
jtsiskin 6y ago
It’s already running on some of their embedded devices, such as google home. A capability based OS with a micro kernel sounds great to me. Things like the networking stack can run in user space, and be written in memory safe languages like Rust. An OS that “can’t” get viruses or be hacked sounds pretty desirable. Cynically it makes things like “jail breaking” a google home much more difficult.
- TACIXAT 6y ago
  >An OS that “can’t” get viruses or be hacked sounds pretty desirable. Cynically it makes things like “jail breaking” a google home much more difficult. I don’t think these claims hold. It is still written in a memory unsafe language, so exploitation is totally possible. As well, for malicious software you’re just looking for a process handing out high privilege handles.
  - bestorworse 6y ago
    > for malicious software you’re just looking for a process handing out high privilege handles In the end, that is true. But the thing is the way Fuchsia's implementation of the 'capability security model' is done. The capabilities a process (or, a 'component' in Fuchsia's model) use/consume are explicitly given to it. And this scheme is implemented in a way that is easy to see and account for where/from these capabilities are going to/from. An process can do nothing that is not provided by the capabilities it got during creation. Of course, components might be buggy/malicious and leak capabilities. But the security holes bottleneck in this capability routing scheme, so even with buggy/malicious components, it's much easier to audit and fix. And from an attacker perspective, it's much harder to reach a component given the routing path of capabilities that it's received.
    - TACIXAT 6y ago
      I expect it will be very much the same as drivers we have today, where you have some game anti-cheat rootkit that has a bug in it. In Fuschia's case it will be like that but the exploitation either gives you access to that driver's capabilities, or simply that driver is giving out handles with permissions insufficiently removed from them. It will be cool to see a full system audit of capabilities, but I don't think that analysis exists yet.
baybal2 6y ago
> why is Google developing it. They want to get a Linux free OS.
deleted 6y ago
[deleted]
dekhn 6y ago
the goal is to be a foundation for future embedded devices that doesn't have the many challenges associated with linux-based systems, specifically around security, isolation, and firmware updates while also defining a simple and straightfoward presentation model to app developers.
swiley 6y ago
Google thinks the GPL in the kernel is the problem with Android.

mmastrac 6y ago

I've heard Fuchsia referred to as a "principal engineer retention project" at Google. I'd be curious to know if others have heard the same.

Kinrany 6y ago
I wonder if this could be turned into a better way to fund public research.
notatoad 6y ago
i've definitely heard that said before here on HN. are you hearing it referred to that way internally at google?
- deleted 6y ago
  [deleted]
abarth 6y ago
As a principal software engineer that works on Fuchsia, I can assure you that the project does not exist solely to retain me. :)
- jacobush 6y ago
  ... but also your colleagues?
- suchire 6y ago
  Not solely, but in part? ;-)
- swetland 6y ago
  Congrats on the promo! It didn't retain me (though I didn't get promoted to Principal, so maybe I don't count) but I did enjoy working on Fuchsia. Nice to see much of the syscall design seems to have survived.
  - abarth 6y ago

jsnell 6y ago

I find it kind of hilarious how large a proportion of the roadmap is just migrations of various kinds. If the goal here was to encourage external contributions, I can't imagine a much worse sales pitch.

bestorworse 6y ago
I see it as better way of developing a product. Or actually, a foundational system, if Fuchsia really ends up becoming something like that. You see, lots of things that today are fundamental were just "developed organically", and that is OK because people never tought that it would end up being what it is. Besides, a greater part of the cruft we have today is rooted in the development model companies adopt that is "develop it, make it work, and ship so not to delay the schedule/budget so much". And that is OK too given that companies just want to develop a product and don't have lots of time, budget and resources... But, as things are in software engineering, that model doesn't produce as good a piece of software as it would with more iterations and refactoring seeking the best software model and implementation. In the end, that results in greater issues issues than what was really needed and the backward compatibility hinders an actual solution. But Fuchsia being meant as a foundation, cannot be developed like that. Like a product that "just works". It would end up being just another bad designed (and chances are, bad implemented too) system based on concepts of the beginnings of computer industry that doesn't necessarily apply for today's systems. As I've loosely accompanied Fuchsia's development, they've done a lot of early bring up work just so that other parts of the system could be developed. And that is expected because they developed arguably almost everything from scratch. You cant expect ending up with really great system design and implementation just from these first iterations. Then, with the experiences from that, they've done lots of refactorings that refined system's abstractions, APIs and implementation. And, if they are serious about Fuchsia being a good foundational system, they have to solve these left over from the early development.
- wmf 6y ago
  Sure, but if Fuchsia is 100% grunt work and there's nothing cool to do in the project it's not going to attract outside contributors.

nicoburns 6y ago

Wish they'd use this kind of development model for Android!

deleted 6y ago

[deleted]

brandmeyer 6y ago

Looks like you still cannot contribute without granting copyright ownership to Google. In turn, GOOG licenses it out under a BSD (or BSD-like) license. This is a big difference relative to Linux, and its part of why Linux works so well as a collaboration between competitors. The GPL's copyleft acts as a joint development agreement between equals. IMO, Fuchsia's model only works well for integration partners that are willing to act as sharecroppers in the ecosystem. That certainly does work for some device manufacturers, but it cannot serve as the foundation of a new Free operating system.

hollerith 6y ago
ADDED. Looks like this comment and its replies have no relevance to the Fuchsia project: https://news.ycombinator.com/item?id=25348935 https://news.ycombinator.com/item?id=25348935 You used to not be able to contribute to most GNU projects (maybe you still can't) without assigning copyright ownership to the FSF. I don't see what practical difference the assignment to Google will make. Without using the words "equality", "between equals" and "sharecropper", can you give an example of something you or I will not be able to do with the code that you or I would have been able to do if the copyright had remained with the contributors?
- brandmeyer 6y ago
  Linux itself has never been a GNU project and has never required copyright assignment. It is the combination of features (retain ownership and GPL) together that has enabled collaboration in Linux.
  - hollerith 6y ago
    Are you saying that collaboration on Gnu Compiler Collection, binutils, bash, bison, CLISP, coreutils, etc, has been inhibited by the requirement for copyright assignment to the FSF?
    - brandmeyer 6y ago
      There's a big difference between GNU and Linux in terms of their collaboration. With the exception of GCC, most of the utilities you named have been maintained by a very small group of people. GCC itself has definitely been inhibited by the copyright assignment. There have been a few different ports that were not upstreamed specifically because of the CLA. AVR32 and C6000 come to mind off the top of my head.

outside1234 6y ago

That is the most hideous source control system ever. Do they really need to be developer hostile just because Github is owned by Microsoft? I mean seriously, who has time to commit to a project with a random set of tooling.

eropple 6y ago
I've never worked at Google, but I've used Gerrit not infrequently at jobs and on projects--it isn't "random" even if you've never run into it before. Gitiles is just a hat on top of it; it's not pretty but it is fast. It's not "developer hostile" to not use Github. Git works everywhere. It might mean that to contribute to an operating system a developer may have to learn how to use something that isn't Github, but honestly if that's a bar to contribution for somebody they probably weren't gonna anyway.
- deleted 6y ago
  [deleted]
ocdtrekkie 6y ago
Google uses GitHub for a bunch of things, I suspect it is more that the people working on it want to use Google's internal tooling as much as possible, and public user experience is considered less important than that.
- bun_at_work 6y ago
  This is the right answer. Google has tons of internal tooling and libraries and frameworks that are all just internal to Google.
  - kerneis 6y ago
    That may be true for Google in general, and internal code in particular, but that's definitely not the case for Fuchsia. We use the tools and interfaces available to the public to work on the code base: code search to browse the code, gerrit for reviews and monorail for tracking bugs.

baybal2 6y ago

Sundar, do you think we will believe you? Google will bait and switch you again, like it did with Android.

EvilEy3 6y ago
Can you elaborate on Android part?
- baybal2 6y ago
  Does it need elaboration? Android too was advertised as a nearly "community driven" OS. Few years down the line, and good sales, and they turn Android into a locked down hell, start to stonewall communications with contributors, throw musings about community governance out of the windows, and break pledge to never block the adblock, nor introduce political censorship on the Android Store.
- CivBase 6y ago
  I believe he's referring to how Android phones have slowly become more and more dependent on the closed-source Google Play Services to provide essential functionality. Despite Android itself being "open source", many Android devices and apps are useless without Google's proprietary services.
  - bogwog 6y ago
    > many Android devices and apps are useless without Google's proprietary services. And not, in fact, open source. Due to the non-GPL license, every single Android device out there is effectively running a closed-source fork of AOSP. I had an old Samsung device automatically install TikTok when I powered it on after sitting in a drawer for years. TikTok didn't even exist when I bought the phone, yet someone with more control over my device than me sold the remote access (they gave themselves, without my consent) to TikTok. Of course this is not a new development, but the proprietary BS and Google's increasingly evil actions over the past decade really highlight how much of a problem that is. Trusting Fuchsia is just repeating that mistake.

methodsignature 6y ago

So maybe open source, [mostly] closed ecosystem? Add a bunch of Spyware from Google and get every app maker to add a dependency to Google services and they are golden for the collection of data on all your "smart" things Sorry/not sorry for the cynicism; I feel it is warranted given what "open source" means on Android. Google talking like they have noble open source ambitions means nothing. They have a lot of amends to make before they begin to seem like a win for society and the industry and they seem to be going in the opposite direction.

jmnicolas 6y ago
yeah the base open sources Android is barely usable. Even simple things like getting a local notification at the right time are not a given. If they do the same with Fuschia, they'd better make it closed sources then.
- actuator 6y ago
  Sorry, not familiar with Android core. For your example, how would it work without proprietary technologies? AFAIK, Android uses GCM for notifications. Adding integrations for it don't seem to make much sense in core open source Android as that will make you tied to Google's ecosystem.
  - zepto 6y ago
    An open platform would have a framework that supports multiple back ends.
    - actuator 6y ago
      This would be definitely nice to have but why does core Android itself need to have support for every feature? We can have open source OSs on top of Android that build with a specific service set. Sort of how Ubuntu builds over Debian.
      - 6y ago

swiley 6y ago

The one singular nice thing about android was that the kernel was GPL. This put a (rather high) limit on the stupidity that could go on. Fuchsia changes that.

205g0 6y ago

OT: Just a second ago, I was setting up unattended-upgrades for security updates for a new Ubuntu box and I am once again puzzled why the largest Linux distribution has such an underwhelming UX for an crucial feature. Long story short, I welcome any new contender in the OS space.

yjftsjthsd-h 6y ago
> I am once again puzzled why the largest Linux distribution has such an underwhelming UX for an crucial feature Are we talking about Ubuntu, or Android? Because honestly in either case... what would you improve? Ubuntu has updates rolled into GNOME's package management frontend and it's seemed to work well, and Android has decent UX around updates (especially with A/B system partitions) although of course it suffers from vendors not actually releasing updates.
e12e 6y ago
What's underwhelming about?: sudo apt install unattended-upgrades
- deleted 6y ago
  [deleted]
- 205g0 6y ago
  You have to touch two config files. One is easy but the other one needs a bit of googling, nothing major but yeah why at all this? Auto-updating security updates should be the default if you run servers in the wild.
  - e12e 6y ago
    > You have to touch two config files. Not if you just want automatic security updates? The package is part of the server task, and defaults to installing security updates. It does not install other updates, and does not automatically reboot. > Auto-updating security updates should be the default if you run servers in the wild. It pretty much is (for Ubuntu server)?
6y ago

flotzam 6y ago

If contributing to your project requires much more than git commit --signoff — in Fuchsia's case, a full-on Google Account! — this will exclude many pseudonymous developers who conceive of things such as privacy in terms of capabilities (not pinky promises). Which seems relevant for a security-focused OS.

snazz 6y ago
I'm guessing that most of these pseudonymous developers—of which there can't possibly be too many—would distrust Google enough not to contribute even if it were easier to do so without a Google Account.
- flotzam 6y ago
  Uneasy bedfellows but nah. Some pockets inside of Google (like AOSP) are, on balance, still beneficial. What a world.
- rhn_mk1 6y ago
  As a pseudonymous developer, I fail to see any harm in contributing to projects run by Google in general. Fuchsia is not a monopolist way to exert control over the market (not today at least), it doesn't seem to be explicitly made for evil, and can be forked to let the community steer it.
  - Jnr 6y ago
    I would not be surprised if Google account ToS has some point that complicates things for contributors or people forking the code. I haven't read Google ToS lately so I can't say there is something like this but that document is huge and keeps changing all the time. If I was a pseudonymous developer, I would probably not go through that.
  - zepto 6y ago
    Since Fuschia seems to be a replacement for Android, why would you think it isn’t a way for Google to exert control over the market? As for forking, that option only becomes practical if the community version can muster adequate resources versus the Google controlled version.

bla3 6y ago

> It has support for a limited set of x64-based hardware Did anyone get it to run on a raspberry pi yet? There has to be _some_ arm support...

dhodell 6y ago
There is not a RPi port, and that's non-trivial for reasons I vaguely recall to be related to display driver weirdness. The system does run on arm64le.

cute_boi 6y ago

Google and Opensource a joke of century. Chrome -> Make chromium opensource but add spyware that phones home on every second and with new manifest v3 make sure extensions like ublock origin don't work Andriod -> Make tip of iceberg opensource but force every vendor to use Service and lock down whole ecosystem around it. And make sure there is no way to block ads on youtube for andriod. Fuchsia -> Initial Stage make people think they are open they are helping community for first 5-10 years. After that implant spyware etc. Same strategy different form === Modern Polymorphism by Modern Liars.

actuator 6y ago
> Make chromium opensource but add spyware that phones home on every second Chromium homes every second? That seems interesting. It has been a long time since I last used Chromium. Does it also come with Google auth now? > Make tip of iceberg opensource but force every vendor to use Service and lock down whole ecosystem around it. If they add Google specific services into core Android is it not worse? Companies like Amazon and a lot of Chinese companies seem to be fine with using just the core Android.
- aravindet 6y ago
  > If they add Google specific services into core Android is it not worse? Not necessarily. Take for example push notifications - the push notification client could be part of the OS, with build configurations to specify a server or disable this altogether. Or, given OS update issues, Google Play Services could be a separate open source project with the Google URLs and keys supplied as build configs.
ceras 6y ago
I don't know, I think there's a couple examples of these open source projects gaining non-Google traction: - The new Edge, Opera, and Brave are based on Chromium - China has a huge ecosystem of non-Google Android devices Google does exert strong control of their open source code, and Google is clearly the prime beneficiary of them, but the external world has still leveraged these projects nonetheless

hortense 6y ago

Anyone else bothered by the black banner saying "Google is committed to advancing racial equity for Black communities" in technical documentation (https://fuchsia.dev/fuchsia-src/contribute/roadmap https://fuchsia.dev/fuchsia-src/contribute/roadmap) ? This is simply an advertisement for Google, and just like any other advertisement it has nothing to do in technical documentation, especially in a project where they want other companies to contribute.

mushufasa 6y ago
I'm not bothered -- I like it. I would like it even more if they acted upon the claim.
SquareWheel 6y ago
Not bothered in the least.
garaetjjte 6y ago
I didn't even notice it. My brain filtered it out as some another ad..

outworlder 6y ago

> Fuchsia is a long-term project to create a general-purpose, open source operating system Why do we need this? We have Linux. It works. It is open-source, general purpose. It needs more support to become more mainstream (like what Valve has done with Proton). Don't like Linux? Start with one of the BSDs. Heck, start with Haiku. Any of these projects are lightyears ahead of anything that's just starting. The most likely explanation is that _we_ don't need this, but Google does, for some strategic purpose. It must be for some pretty compelling use-case, because we know how happy they are to kill projects.

asadawadia 6y ago
They need work to give their thousands of devs
vondur 6y ago
Is there anything in Fuchsia that may be usable in Linux? I'm specifically thinking of something like a window manager?
endymi0n 6y ago
Why do we need Krita when we have GIMP? Because every once in a while, it‘s easier to free yourself from the shackles of architectural decisions that were made because of the hardware and constraints of their time that are obsolete now but are supported for legacy reasons. A security model that is designed from scratch into such a deep OS concern as with Fuchsia is one of the aspects that would be next to impossible to bolt onto such a conplex project such as Linux or BSD. I‘m not saying it will play out, but it certainly brings a wave of fresh and radical new ideas into open source operating systems I haven‘t seen since the times of BeOS and Plan 9.
- bayindirh 6y ago
  For me, OS research is always good. Experimenting from ground up is even better. But Minix, the hero of the Microkernel research, became the guardian of Intel systems and preventer of tinkering and exploration. Can we certainly say that Fuschia will be Free and mild natured like BSD and Linux or will it become another silent "hard-layer" like Minix? GP (and I) certainly fear about the latter. Given Google's transformation to Modern day Microsoft of the 90s, it's not too far-fetched it seems.

jasonvorhe 6y ago

I don't understand the cynicism here. Android's fragmentation was the original sin that lead to fragmentation and the new that we've seen for years, until Google semi-fixed the mess with a) Play Services (short term) and b) Project Treble. Google were so convinced of the value of open source that they didn't anticipate that almost all OEM's would rather ship their Android forks than to stay close to upstream. If they hadn't intervened, Android as a platform would be useless by now and app developers would need to implement various ways of handling notifications, storage access, etc just to ship their apps to a broad audience of device owners, Samsung would've never upped their update game and there wouldn't be 2-3 versions of Android on the majority of devices, but more like 5-10, depending on how many manufacturers would've survived in the market. Android still allows for easy side loading of applications, there are still major independent after market Android versions out there, you can develop for Android in various languages, using a huge selection of IDEs and there's open source alternatives to Play Services that Google neither litigates against nor seems to actively fight against. Google didn't even manage to gain any relevant market share with their Pixel line of devices, of which most run Android. They could've done a lot of nefarious things by keeping newer Android versions Pixel exclusive until they publish the source code to OEMs, for example. Instead, they are making it easier to quickly move an existing Android code base to the latest version by abstracting away a lot of the complexity (project treble). Is Google still primarily am advertising company that tracks its users? Of course. Do they have their own motives to keep Android at the top of the mobile OS market? Of course. But a lot of the comments see evil scheming where Google probably had to act quickly to ensure that Android has a future and that developers didn't lose interest in the platform in favor of iOS.

peey 6y ago
> there's open source alternatives to Play Services that Google neither litigates against nor seems to actively fight against AFAIK these are reverse-engineered. Do you sincerely believe that developers' time is best spent reverse engineering and maintaining play services alts to undo a blockade that Google put in, just to be able to get full freedom over their android derivative? Wouldn't it be better spent in playing with cool new tech (as Google engineers seem to be doing)?

deleted 6y ago

[deleted]

peey 6y ago

AOSP is an open source project, which is impractical for any business to run because of apps' reliance on proprietary google play services. Chromium is an open source project, but proprietary chrome has the largest browser market share and they like to abuse their position to not play well with standards bodies. Google can develop Fuchsia. It'll even be cool piece of tech, but I do not for a second believe that contributing to the project would benefit anyone but Google.

rhencke 6y ago
Chromium, as built in many open-source distributions, uses a per-distribution Google API key for service access. [1] [2] [3] If built without API keys, Chromium warns 'Google API keys are missing. Some functionality of Google Chrome will be disabled.' [4] [5] The APIs used include [6]: * Calendar API * Contacts API * Drive API (Optional) * Chrome Remote Desktop API * Chrome Spelling API * Chrome Suggest API * Chrome Sync API * Chrome Translate Element * Chrome Web Store API * Chrome OS Hardware ID API (Optional, Chrome OS) * Device Registration API (Optional, Chrome OS) * Google Cloud DNS API * Google Cloud Storage * Google Cloud Storage JSON API * Google Maps Geolocation API (Optional) * Google Maps Time Zone API * Google Now For Chrome API (Optional) * Nearby Messages API * Safe Browsing API * Speech API [1] https://git.alpinelinux.org/aports/tree/community/chromium/APKBUILD?id=24fcf2cf771de488a261f8c4ad06e31b61402ed1#n192 https://git.alpinelinux.org/aports/tree/community/chromium/A... [2] https://github.com/archlinux/svntogit-packages/blob/packages/chromium/trunk/PKGBUILD#L62 https://github.com/archlinux/svntogit-packages/blob/packages... [3] https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/tree/build/args.gn?h=stable#n1 https://git.launchpad.net/~chromium-team/chromium-browser/+g... [4] https://chromium.googlesource.com/chromium/src/+/9a11dadde80a2e309445f1f33b75a95fe51358d9/chrome/app/google_chrome_strings.grd#491 https://chromium.googlesource.com/chromium/src/+/9a11dadde80... [5] https://sources.debian.org/patches/chromium/83.0.4103.116-1~deb10u3/disable/google-api-warning.patch/ https://sources.debian.org/patches/chromium/83.0.4103.116-1~... [6] https://www.chromium.org/developers/how-tos/api-keys https://www.chromium.org/developers/how-tos/api-keys
- rhencke 6y ago
  To elaborate, the following distributions of Chromium are violating the Google API terms of service [1] [2] by publishing the API secret key publicly in the build source code responsible for building Chromium: * Alpine Linux (community port) - https://git.alpinelinux.org/aports/tree/community/chromium/APKBUILD?id=7f866234e512a34d9758a6cee5b8edfba2147c4f#n192 https://git.alpinelinux.org/aports/tree/community/chromium/A... * Arch Linux (svntogit, AUR) - https://github.com/archlinux/svntogit-packages/blob/1e8f3fe75e060ea70553b32926185bec84561e32/trunk/PKGBUILD#L67 https://github.com/archlinux/svntogit-packages/blob/1e8f3fe7... - https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=chromium-dev&id=0ea1e1fad209a7ca2552fbe6efaf9e49c732b8d8#n111 https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=chrom... * Fedora Linux - https://src.fedoraproject.org/rpms/chromium/blob/e78656ce58dd9e7417433461df24e191eaf41b29/f/chromium.spec#_171 https://src.fedoraproject.org/rpms/chromium/blob/e78656ce58d... * Gentoo - https://github.com/gentoo/gentoo/blob/9acf51b665b6f4b5b97edb871da588c4e870e9b3/www-client/chromium/chromium-89.0.4343.0.ebuild#L624 https://github.com/gentoo/gentoo/blob/9acf51b665b6f4b5b97edb... * OpenSuSE - https://build.opensuse.org/package/view_file/openSUSE:Factory/chromium/chromium.spec https://build.opensuse.org/package/view_file/openSUSE:Factor... * Slackware - http://www.slackware.com/~alien/slackbuilds/chromium/build/chromium_apikeys http://www.slackware.com/~alien/slackbuilds/chromium/build/c... * Ubuntu, Linux Mint (Canonincal Chromium Snap) - https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/tree/build/args.gn?h=stable&id=af9ed0cec8cdfcc2972b8a3e13a750516b358211#n3 https://git.launchpad.net/~chromium-team/chromium-browser/+g... [1] https://developers.google.com/terms https://developers.google.com/terms (specifically: "You will only access (or attempt to access) an API by the means described in the documentation of that API. If Google assigns you developer credentials (e.g. client IDs), you must use them with the applicable APIs. You will not misrepresent or mask either your identity or your API Client's identity when using the APIs or developer accounts." and "Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects.") [2] https://www.chromium.org/developers/how-tos/api-keys https://www.chromium.org/developers/how-tos/api-keys (specifically: "Note that the keys you have now acquired are not for distribution purposes and must not be shared with other users.")

twh270 6y ago

Is there any comparison between Fuchsia and the Genode OS, which is also capability-based? I'm wondering what one has/does that the other doesn't?

snvzz 6y ago
Fuchsia is an OS. Genode's a framework for creating operating systems. It's not comparable. What's interesting imho is to compare seL4 with zircon. The former is a third generation microkernel. The latter is still a first generation microkernel or, according to google, not a microkernel at all. It's thus not very interesting from a computer science perspective. In practical terms, I'm sure it'll be better than Linux and IOS/OSX, but that's a very low bar to meet.
- mlinksva 6y ago
  How about an OS using the Genode framework, Sculpt OS https://genode.org/download/sculpt https://genode.org/download/sculpt IIUC, compared to Fuchsia? Apart from their kernels, which you've addressed.

barnacled 6y ago

I am a Linux kernel contributor and former golang and chromium contributor and to be honest the latter experiences makes me leary about contributing to another Google project. There generally tends to be an insular 'cathedral' rather than 'bazaar' approach to Google projects where those working for the company get considerably more say and control than outside contributors. The whole issue I have with it is that they pretend otherwise. With go many people laboured under the misapprehension that they could have more input than was actually possible. Not so different with chromium. The cathedral model is fine but be honest about it. With the Linux kernel if you have a good idea and can defend it you have a genuine chance of contributing. So I know my limited spare time efforts aren't wasted. With fuchsia I couldn't be so sure. I hope I am wrong but the fact they are only now taking potential contributions suggests otherwise.

jeffrallen 6y ago
I'm a longtime Go watcher, and sometime Go contributor and I agree with this, 100%. Go has benefitted from having a BDFL employed by Google. But outsiders will always be outsiders.
- barnacled 6y ago
  While I think Russ is brilliant and deeply qualified for that role, his BDFL position differs considerably from that of e.g. Guido (well pre resignation) or Linus in that he is considerably more 'D' than either of them. And probably that works well for go and keeps a very clear philosophy and style for the language. It is just the fact they very blatantly misled the community on the scope of possible contributions that frustrates me. Fuschia does, in all fairness, appear to be considerably more honest on these issues.
dhodell 6y ago
It's kind of unfortunate because existing developers have the privilege of experience with the systems and where they're going that external contributors simply don't have, and it will take a non-trivial amount time for interested parties to develop that knowledge. At the same time, it is an active project with active development that are informed by goals and processes not all of which are open. And really, while the development has been "in the open", it hasn't engaged the public until now. To that end, it's not possible to engage in a "bazaar" approach off the bat, whether or not that's a goal of the project. Having been active in Go development and seeing some of the issues there, I understand what you mean. I don't think we state anywhere "this is clearly a cathedral model of development", but I think we're pretty clear on it: * We have a section of documentation on project governance https://fuchsia.dev/fuchsia-src/contribute/governance https://fuchsia.dev/fuchsia-src/contribute/governance * We have a section of documentation detailing different kinds of contributors, acknowledging that there are kinds of contributors with special powers, and also reserving the right to revoke contribution privileges in some cases: https://fuchsia.dev/fuchsia-src/contribute/community/contributor-roles#specialized-roles https://fuchsia.dev/fuchsia-src/contribute/community/contrib... To the extent that you can look at these as a set of policies, follow all the policies, submit a change, and have that change rejected, I think that is unfortunate. I think this is much less likely if you first engage with the stakeholders, and having opened up mailing lists, we've made it simpler to do that. However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion. I can fork the repo, but that's also already the case with Fuchsia. > the fact they are only now taking potential contributions We were honest about this too, and our documentation used to explicitly say that we did not accept external contributions.

mtgx 6y ago

Still seems like a wasted opportunity not to have Fuchsia or at least Zircon developed in Rust. Who knows how many development man hours and security bugs and data breaches will that single decision saved over the next several decades.

ender7 6y ago

I'm a little sad that there aren't any comments describing what is technically novel around Fuchsia and why it is/why it isn't interesting from an OS design standpoint. I get the sense that its advances are probably too low-level for most app developers to care, but that's kind of precisely why I'd love a comment elucidating them a bit. Edit: For example, the Fuchsia docs list the primary talking points as secure, updatable, inclusive, and pragmatic. How well does it live up to those principles? Will they bring practical benefits? What's exciting/new about what's being done here?

abarth 6y ago
https://fuchsia.dev/fuchsia-src/concepts https://fuchsia.dev/fuchsia-src/concepts has an overview and links deeper into the site for more detailed information.
sanxiyn 6y ago
Fuchsia is a capability OS. I think that's enough to interest anyone interested in secure OS.

owaislone 6y ago

Fuchsia will e to Android and ChromeOS what Servo is/was to Firefox. Eventually the guts of Android and ChromeOS will be replaced with Fuchsia while end users won't see a radical change. It might feel like moving from XP to Vista or OS 9 to OS X.

pier25 6y ago
Hopefully not to Vista :)

markdog12 6y ago

Would love to see what it looks like: https://fuchsia.dev/fuchsia-src/concepts/graphics/scenic/scenic https://fuchsia.dev/fuchsia-src/concepts/graphics/scenic/sce...

Schnitz 6y ago

Remember Android? It’s a trap!

tgerdin 6y ago

Let's hope Fuchsia fares better than Hurd. Also, I guess the adoption of Fuchsia will be a litmus test of the GPL. Will its possibly technical merits outweight the strength of GPL to avoid fragmentation? I suspect the GPL has served Linux very well in this regard. Given Google's muscles it will most likely have an impact in the mobile world, but whether it will reach beyond into the area of general computing is less certain.