Live data from Hacker News

Fuchsia overview

fuchsia.dev

141–150 of 235 posts

Re: Fuchsia overview

#141
post #124

Earlier quoted context omitted.

Doesn’t look that good to me. The Vortex is not a GPU. They call it GPGPU, meant purely for running OpenCL kernels, doesn’t have a graphics pipeline at all, which is kinda important part of a GPU.

I am not so sure about that. GPU has been slowly moving away from having a fixed graphics pipline at all in the past a few years. See the recent Nanite technology from Unreal 5: http://c0de517e.blogspot.com/2020/05/some-thoughts-on-unreal...

They use compute shaders for triangles that cover 1 pixel as rasterization always does 2x2 due to derivative calculations etc so there is overhead. For larger triangles they do go trough the rasterization pipeline as usual because it is so much faster.

Another crucial thing is texture mapper. That thing is really fast and usable even in the compute pipeline. Image support is (was?) largely optional in OpenCL.

Also I remember the last time people talked about this. PS3 was not originally supposed to have a GPU at all because the Cell processor was so powerful. In the end they had to ram in an actual GPU. While the Cell was just fine for vertex processing it did choke terribly in rasterization due to lack of TMU and dedicated HW rasterizer.

EDIT: I also want to emphasize the difference of target markets. On AMD one can go to the Nanite path for some of the rasterization. One must remember that it is a non battery powered device.

Memory bandwidth is really power hungry. For mobile, the likely target market for the Vortex and similar, one really wants to do tile based rendering. Ideally the way IMG does it. Even though theoretical flops of modern mobile GPU’s is higher than some old discrete ones their memory bandwidths are way lower, so no running Crysis on modern mobile even though flops would indicate it would match a good discrete GPU back in the days.

Re: Fuchsia overview

#142
post #139

Earlier quoted context omitted.

In what way does software "clash" on *nix? The isolation provided by snaps and flatpaks is 99% about isolating devs from having to worry about deps and different platforms.

flatpak/snap applications can run on its own confined sanboxes

Which are complete and total garbage insofar as actual isolation. If you think you can run malware in a snap and not be pwned you are kidding yourself.

Re: Fuchsia overview

#143

Earlier quoted context omitted.

The point is that when a non-Googler contributes code, it’s non-proprietary since the non-Googler is by definition a non-Googler. What the CLA does not prohibit is proprietary use—- your lengthy answer. The OP makes the point that Google will find a way to use public contributions for Google’s own profit. The sheer size of the response above, let alone content, is what creates the tone of “talking past the customer”…

Disclaimer: I'm not a lawyer and this is not legal advice. I've added a clarification separately, please take a look there first: https://news.ycombinator.com/item?id=23365469 > The point is that when a non-Googler contributes code, it’s non-proprietary since the non-Googler is by definition a non-Googler. I think we are using different definitions of "proprietary". I'm using it to mean "non-open-source" [1], and you…

I think a nice example that could help clarify the situation is the CLA that Canonical uses; if I remember correctly they reserve to themselves the right to change the license of community contributions.

Re: Fuchsia overview

#144

Earlier quoted context omitted.

> An open source driver Lost you already. Since Fuchsia uses a pushover license instead of a copyleft license, the vendors' drivers aren't going to be open source. Look how many companies today don't open-source their Linux drivers, and they're breaking the law by not doing so. It's going to be so much worse when there's "nothing" wrong with keeping them proprietary.

> Since Fuchsia uses a pushover license instead of a copyleft license [emph. add.] This is great term for it, thank you.

I can't claim credit for coming up with it: that honor goes to RMS and the FSF. See https://www.gnu.org/licenses/license-compatibility.html and https://www.gnu.org/licenses/license-recommendations.html#sm...

Re: Fuchsia overview

#145

Earlier quoted context omitted.

There exists hardware that you are screwed by. How is that Fuschia's fault? How is that anyone in the open source operating system world's fault? Given the fact that some hardware is completely impenetrable, why would someone wish harm upon Fuschia?

A multi billion dollar company doesn't need you to shield its efforts from criticism. You have somehow anthropomorphized an OS project and are treating it like a frail animal in need of your protection. It's composed of actual adults who presumably can read critical comments without coming to "harm". Hardware running software that is either proprietary or based on permissively licensed software is everywhere. It's us…

No, I mean, you are blaming one project, Fuschia, for something no project can fix.

Therefore, your criticism is completely without merit, and should be ignored entirely.

1) Fuschia doesn't have a property. (It doesn't compel hardware vendors to provide open source drivers.)

2) No other operating system can possibly have that property either.

3) Therefore Fuschia should die, to help one of those other operating systems succeed.

Do you not see the flaw in this argument?

Re: Fuchsia overview

#146

Earlier quoted context omitted.

A multi billion dollar company doesn't need you to shield its efforts from criticism. You have somehow anthropomorphized an OS project and are treating it like a frail animal in need of your protection. It's composed of actual adults who presumably can read critical comments without coming to "harm". Hardware running software that is either proprietary or based on permissively licensed software is everywhere. It's us…

No, I mean, you are blaming one project, Fuschia, for something no project can fix. Therefore, your criticism is completely without merit, and should be ignored entirely. 1) Fuschia doesn't have a property. (It doesn't compel hardware vendors to provide open source drivers.) 2) No other operating system can possibly have that property either. 3) Therefore Fuschia should die, to help one of those other operating syste…

Fuchsia could have fixed it by being copyleft licensed. That doesn't preclude in any way having a stable interface for drivers.

Re: Fuchsia overview

#147
post #35

>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers. This is a massive step back for open source. The fa…

> We already have a high quality kernel: Linux. Linux is full of security bugs. It is ludicrous to suggest Linux is high quality. OpenBSD, maybe. Not Linux.

Citation needed :)

Seriously, all software has bugs, how do you judge the quality of an operating system that is not finished?

Re: Fuchsia overview

#148

Earlier quoted context omitted.

No, I mean, you are blaming one project, Fuschia, for something no project can fix. Therefore, your criticism is completely without merit, and should be ignored entirely. 1) Fuschia doesn't have a property. (It doesn't compel hardware vendors to provide open source drivers.) 2) No other operating system can possibly have that property either. 3) Therefore Fuschia should die, to help one of those other operating syste…

Fuchsia could have fixed it by being copyleft licensed. That doesn't preclude in any way having a stable interface for drivers.

Hardware vendors are under no obligation to use Fuschia. Therefore, you have still not compelled hardware vendors to provide open source drivers.

Linux has not compelled Nvidia to produce good OpenGL drivers.

No, really, walk me through this.

Re: Fuchsia overview

#149
post #35

>Fuchsia aims to provide drivers with a binary-stable interface. In the future, drivers compiled for one version of Fuchsia will continue to work in future versions of Fuchsia without needing to be modified or even recompiled. This approach means that Fuchsia devices will be able to update to newer versions of Fuchsia seamlessly while keeping their existing drivers. This is a massive step back for open source. The fa…

While I understand why you want open source drivers, the situation hasnt improved for 10 years, and this is one of the major reasons many phones end up not getting Android updates, which makes Google/Android look bad.

I believe the situation is a bit better now that there are LTS releases of the Linux kernel.

Re: Fuchsia overview

#150

Earlier quoted context omitted.

A multi billion dollar company doesn't need you to shield its efforts from criticism. You have somehow anthropomorphized an OS project and are treating it like a frail animal in need of your protection. It's composed of actual adults who presumably can read critical comments without coming to "harm". Hardware running software that is either proprietary or based on permissively licensed software is everywhere. It's us…

No, I mean, you are blaming one project, Fuschia, for something no project can fix. Therefore, your criticism is completely without merit, and should be ignored entirely. 1) Fuschia doesn't have a property. (It doesn't compel hardware vendors to provide open source drivers.) 2) No other operating system can possibly have that property either. 3) Therefore Fuschia should die, to help one of those other operating syste…

As the owners of the platform Google logically they COULD require all oems to ship open drivers as a condition of using the software. My criticism lays out legitimate concerns as a potential user to a potential user. I don't think it has to have an actionable solution by a third party to be valid. It merely has to connect with objective reality and have a well supported line of reasoning. If you are looking for an actionable item I suggest waiting and seeing how open the platform is and not investing development time or dollars in it if its even less so than android.

As an alternative I suggest you look at actual Linux devices even if they are objectively worse if they are more open.

Post reply on HN