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

Fuchsia overview

fuchsia.dev

Post reply on HN
Print view View original

121–130 of 235 posts

Re: Fuchsia overview

#121

Post by dang »

phreack wrote: post #111
dang wrote: post #54

Please don't editorialize titles. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html . Lots of explanation here: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... (Submitted title was 'Fuchsia overview – “Fuchsia is not a science experiment”')

I'm sorry if this isn't the place to ask (and please let me know), but how should we correctly title something like a tweet, that has no obvious title?

I'd use the text of the tweet or the most representative substring of it that will fit the 80 char limit.

Re: Fuchsia overview

#122

Post by exged »

entha_saava wrote: post #106
zozbot234 wrote: post #64

Earlier quoted context omitted.

"Isolation" of driver code that can talk to on-SoC hardware is just not very meaningful. You can only have real driver isolation if it's enforced on the hardware side via some IOMMU mechanism (or by keeping the hardware isolated on the USB bus, etc.), otherwise you're just adding pointless overhead for no real benefit.

I didn't get it. Don't we want, for example, wifi driver not to be able to access and corrupt (due to some bug) GPU driver's memory?

It's desirable, but typically hardware devices have DMA-capable buses that can read / write to arbitrary physical memory. So a buggy or malicious WiFi driver may be able to use the WiFi DMA hardware to write into the GPU driver's memory, and no pure software mechanism can stop it from doing so.

IOMMUs solve this problem by giving hardware devices their own virtual address spaces.

Re: Fuchsia overview

#123

Post by mkl »

AnthonyMouse wrote: post #91
ReactiveJelly wrote: post #55

Earlier quoted context omitted.

It's a negotiation, and the hardware vendors seem to be 100% happy stepping away from the table and letting old hardware suffer. They have a lot more leverage than we FOSS supporters do.

What this is really about is Qualcomm. They have inadequate competition and that allows them to abuse everybody else. In a competitive market, open source drivers win. Look at the desktop market -- nearly everything is open source, and the biggest holdout is nVidia, because for a while there nobody was challenging them on performance. Now that AMD has competitive GPUs again, not only does that provide a competitive o…

> Android is an open source system with apps that run on the JVM, so the architectural difference shouldn't matter much.

Android apps run on ART, not the JVM (different bytecode, similar idea): https://en.wikipedia.org/wiki/Android_Runtime

Many apps have native code as well, and Intel put a lot of time and money into automatic binary translation some years ago to make such apps work on x86 Android: https://www.anandtech.com/show/5770/lava-xolo-x900-review-th...

AMD might be able to build on that, but it was probably specific to Intel's mobile CPUs of the time (which didn't really succeed), and I don't know what's happened since.

Re: Fuchsia overview

#124

Post by liuliu »

sharpneli wrote: post #118
pabs3 wrote: post #110

Earlier quoted context omitted.

The RISC-V community is already working on GPUs, some of them open: https://github.com/felsabbagh3/Vortex https://news.ycombinator.com/item?id=22492902 https://libre-riscv.org/3d_gpu/

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

Re: Fuchsia overview

#125

Post by thayne »

catern wrote: 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…

I'm torn on the subject of a binary-stable driver interface. The idealist in me likes that it forces vendors to open source their driver code, but the pragmatist in me knows that some vendors (like a certain graphics card manufacturer in the desktop and server world) probably never will open source their drivers, and if they do, they may not be as high of quality as the proprietary version for other OSes. I wonder if there is some middle ground. Also, even with open source drivers, the lack of stability has downsides, such as requiring you to recompile all drivers whenever the kernel updates. Maybe where a subset of the ABI is stable, so it's possible to build driver binaries that work across kernel versions, but there is still some incentive for keeping drivers open source?

> any improvement that could be added to Fuschia could be added to Linux

This is not necessarily true. Some things certainly. But linux is constrained by keeping a backwards compatible user-space interface, and being mostly posix-compliant. For example, fuchsia doesn't have fork or exec (it has a single spawn function/syscall instead). Linux could add a new spawn syscall, but has to keep fork, clone, execv, etc. forever. And even if most new code moves to use the new syscall, the complexity around the old ones will be around forever.

Re: Fuchsia overview

#126

Post by gigatexal »

michaelmrose wrote: post #113
entha_saava wrote: post #106

Earlier quoted context omitted.

I didn't get it. Don't we want, for example, wifi driver not to be able to access and corrupt (due to some bug) GPU driver's memory?

Does this actually happen?

I’m sure it does when used to exploit devices.

Re: Fuchsia overview

#127

Post by naasking »

ptomato wrote: post #50
catern wrote: 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…

> For various reasons, but nothing fundamental. "Hardware vendors being unwilling to make the drivers they write open source" is a pretty fundamental reason. Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option. The open source community is not, for example, going to…

> Which is worse, a phone where you can't update kernel because of the closed drivers or a phone where you can update the kernel, with closed drivers? I don't think that realistically there's a third option

A phone in which the kernel never needs to be updated, like with the seL4 microkernel.

Re: Fuchsia overview

#128

Post by combatentropy »

catern wrote: 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…

> any improvement that could be added to Fuschia could be added to Linux

Not easily. If Linux has gone down a path far enough, it may be hard to reverse, especially if it is of fundamental design. For example, the separation of kernel space and user space is different. I am not an operating system engineer, but I would bet that certain things would be hard to change --- deep structural decisions mentioned in the article, like:

- the kernel primitives are exposed to applications as object-capabilities

- applications can interact only with the objects to which they have been granted access explicitly

- applications interact with each other and the system using message passing

> use proven ideas

I would say in the realm of software there are still competing ideas, even if you narrow it to the subset of ideas that are good (secure, maintainable, fast, etc.). Linux chose some good ideas, but if you want to try out different ones, you may have to start from a clean slate.

Re: Fuchsia overview

#129

Post by dang »

dilandau wrote: post #95
mbrukman wrote: post #30

Earlier quoted context omitted.

Disclosure: I work at Google (but not on Fuchsia), and I contribute quite a bit to open-source projects. Disclaimer: I'm not a lawyer, this is not legal advice, etc. I'm not sure what you mean by "you grant a license to Google to use it in non-proprietary code" — was that a typo and did you mean "proprietary"? In any case, Apache/BSD/MIT licensed code can already be used in proprietary code, the CLA does not change t…

You're talking out your ass, Google. Everyone knows how much Google cares about open source and open platforms...

Given the comment you're replying to, this counts as a personal attack. We ban accounts that do that, so please don't.

Even as a top-level post this is a bad comment for HN, regardless of how one feels about Google. Please don't post unsubstantive comments here.

https://news.ycombinator.com/newsguidelines.html

Re: Fuchsia overview

#130

Post by a1369209993 »

josephcsible wrote: post #104
VikingCoder wrote: post #103

Earlier quoted context omitted.

I think your take on this is very wrong. An open source driver written once will work for all future versions of Fuschia. Right? That reduces the effort for open source developers enormously. Most security flaws come in above the driver level. Right? Being able to update the OS, despite the hardware manufacturer's laziness , is a huge boon for everyone. Fuschia is open source. Drivers written for one Fuschia (say, th…

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

Post reply on HN