Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Expanding Fuchsia's open source model

opensource.googleblog.com

Post reply on HN
Print view View original

151–160 of 334 posts

Re: Expanding Fuchsia's open source model

#151

Post by bun_at_work »

cogman10 wrote: post #46
bun_at_work wrote: post #28

Earlier quoted context omitted.

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 simil…

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 dri…

That's some good insight. Thanks! I hadn't considered that Android issue.

Re: Expanding Fuchsia's open source model

#152

Post by wmf »

evil-olive wrote: post #127
wmf wrote: post #58

Earlier quoted context omitted.

Since you're here, "abarth", it took me several clicks to get to the OWNERS file and all I saw was a list of email addresses. Calling that "governance" is... could we at least get some names and maybe brief bios on these people?

The OWNERS file is typically used, sometimes by automated tooling, to answer the "who should I ask to code review these changes?" question. https://chromium.googlesource.com/chromium/src/+/HEAD/docs/c... https://docs.github.com/en/free-pro-team@latest/github/creat... https://docs.gitlab.com/ee/user/project/code_owners.html It's not meant to be a place for developer bios. If for no other reason than one developer coul…

Let me add some context. I was looking at the governance links on the site and found https://fuchsia.dev/fuchsia-src/contribute/governance/eng_co... which at the bottom simply says "The current members of the Fuchsia Eng Council are listed in this OWNERS file." I think it would improve the transparency/accountability of the project to have more than a list of email addresses here.

Re: Expanding Fuchsia's open source model

#153

Post by brandmeyer »

hollerith wrote: post #92
jononor wrote: post #35

Earlier quoted context omitted.

That is a significant limitation. A considerable amount of open source software is written while people are employed, as part of their work.

Sure, but no open-source project wants contributions by contributors who do not legally own the code because in that case the actual owner of the code can petition the court to issue an injuction on the project preventing further distribution of the code till the offending code is removed from the project. (They can also sue any user of the project for damages.) Wikipedia has to worry about the same thing, BTW: contr…

Copyright attestation is only one small element of a CLA. I have no problem with an attestation of ownership.

Re: Expanding Fuchsia's open source model

#154

Post by flotzam »

mrtranscendence wrote: post #141
flotzam wrote: post #134

Earlier quoted context omitted.

I'd just like to interject for moment. What you're refering to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but sure you can contribute to the Linux kernel pseudonymously. Think of a plausible name, "git commit --signoff", and you're good to go. There's no enforcement of slave names for kernel contributions, it's all just a min…

Slave names, really? You can lie about your name, I suppose, but strictly speaking you're violating the stated rules and could face having your code rejected or removed: "code from anonymous (or pseudonymous) contributors will not be accepted". ( https://www.kernel.org/doc/html/latest/process/1.Intro.html ) And since you mentioned GNU, would you be able to pull the same trick on a GNU project? Don't they require you…

> Slave names, really?

It's a common way that pseudonym aficionados refer to their civil names. Gallows humor.

> You can lie about your name, I suppose, but strictly speaking you're violating the stated rules and could face having your code rejected or removed: "code from anonymous (or pseudonymous) contributors will not be accepted"

And yet it won't be rejected or removed. The preceding sentence is "It is imperative that all code contributed to the kernel be legitimately free software." If you don't betray the project, nobody will make it a problem.

Re: Expanding Fuchsia's open source model

#155

Post by an_opabinia »

jasonvorhe wrote: post #123

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…

> Google were so convinced of the value of open source

It is as black and white as, "Chinese market."

Re: Expanding Fuchsia's open source model

#156

Post by phh »

jasonvorhe wrote: post #123

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…

Project Treble didn't fix anything (I'm very happy with Project Treble, because it lets me hack stuff I couldn't begin to imagine with 4 yrs ago, but that's just hack). It didn't even fix Nexus/Pixels that still have the same upgrade track record as a Samsung 100$ device. (Pixel 1 and Pixel 2 users, feel free to come and use my Generic System Image, I'll keep upgrading you as long as I can with my bare hands!)

ATM OEMs are NOT allowed to use Project Treble. There is only one OEM in the whole world that did an upgrade using Project Treble. What does this OEM have special? Well it's Meizu, they ship only in China, and doesn't care about Google certification. The certification that you say helped prevent Android from being fragmented. Turns out it actually helps fragmentation.

Meizu, Amazon, and Huawei are not Google certified. I have yet to hear developers say they are specifically worse than other Android devices. Last time I had an Android device with stupidly broken video aspect ratio (I'm a multimedia developer amongst other things), it wasn't a Meizu, Amazon or Huawei device. It was a properly certified Philips TV.

Project Treble is sincerely a superb engineering project. But the truth severely lags behind.

If you don't care about Google certification, you can upgrade an Android 8 device to Android 11 finger in the nose, keeping Android 8. It's bootable in a day, usable in a week, production ready in a month. If you care about Google certification? Well, you need to upgrades your drivers to Android 11 base, which is a non-sense when mentioning Project Treble.

How to upgrade drivers? Well it depends. Usually the first step is to upgrade your build scripts. Because well of course, every two major upgrades Android build system is "upgraded". Well, OEM got the trick, now they are building their drivers out of Android, and their build system is a giant shell script. Way to go! Makes upgrading to newer Android version much better!

Now you've managed to build your Oreo drivers into Android 11, congrats! Now let's start them! Oh, new "security" features have appeared, and now half of your code no longer works. (fdsan I believe is way more annoying that it is meant to be)

Let's not forget about Android 9 Go mess as well. (Hint: The only post-Oreo Samsung devices that didn't get their 2 upgrades are Android Go devices) Basically Google cares about RAM consumption two weeks every 2 year, so only this exact release is usable on low-end devices.

Is Google evil? I don't believe it is. Hell I believe that every Google engineers believe they are working towards a better future. However I do believe that even within Android itself, there are many units, that are (mostly unwillingly) shooting at each other's foot. So yes having AOSP is awesome, Project Treble is beyond any hope I had back then. Still, overall the improvement is far from what has been advertised.

To come back to Fuchsia, I believe it is going to be pushed to Android devices in two years (so Android T). OEMs won't have a word to say in this: Google gave a try at such a big change through GKI, and OEMs have been complying nicely, so going to Fuchsia should be pretty easy too. I'm expecting some Android features to be offloaded to Fuchsia for "security" reasons, like Window Manager, which will constraint OEMs even further down as to what they can change, because the Fuchsia "core" image will be like Google Services, mandatory Google-signed. (There'll be Fuchsia app images as well, which people will be able to do whatever they want with, but that's something else) I hope I'm wrong.

Re: Expanding Fuchsia's open source model

#157

Post by Andrew_nenakhov »

jasonvorhe wrote: post #123

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…

You can easily sideload an app, sure. But recent version of Android restricted background running of the apps, making developers dependent on push notifications, and FCM notifications won't work without Google services.

Re: Expanding Fuchsia's open source model

#158

Post by mrtranscendence »

flotzam wrote: post #154
mrtranscendence wrote: post #141

Earlier quoted context omitted.

Slave names, really? You can lie about your name, I suppose, but strictly speaking you're violating the stated rules and could face having your code rejected or removed: "code from anonymous (or pseudonymous) contributors will not be accepted". ( https://www.kernel.org/doc/html/latest/process/1.Intro.html ) And since you mentioned GNU, would you be able to pull the same trick on a GNU project? Don't they require you…

> Slave names, really? It's a common way that pseudonym aficionados refer to their civil names. Gallows humor. > You can lie about your name, I suppose, but strictly speaking you're violating the stated rules and could face having your code rejected or removed: "code from anonymous (or pseudonymous) contributors will not be accepted" And yet it won't be rejected or removed. The preceding sentence is "It is imperative…

> It's a common way that pseudonym aficionados refer to their civil names.

Fair enough. That verbiage made me think you were a "freeman on the land" or something.

Re: Expanding Fuchsia's open source model

#159

Post by rhencke »

peey wrote: post #145

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 contr…

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/A...

[2] https://github.com/archlinux/svntogit-packages/blob/packages...

[3] https://git.launchpad.net/~chromium-team/chromium-browser/+g...

[4] https://chromium.googlesource.com/chromium/src/+/9a11dadde80...

[5] https://sources.debian.org/patches/chromium/83.0.4103.116-1~...

[6] https://www.chromium.org/developers/how-tos/api-keys

Re: Expanding Fuchsia's open source model

#160

Post by lowdose »

wmf wrote: post #62
bestorworse wrote: post #40

Earlier quoted context omitted.

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 "…

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.

The classical chicken and egg problem every platform has but in this case even more obvious because there are no consumers yet so the number of producers is also small.
Post reply on HN