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

How sandboxing works in Fuchsia

fuchsia.googlesource.com

Post reply on HN
Print view View original

81–90 of 172 posts

Re: How sandboxing works in Fuchsia

#81

Post by DannyBee »

catern wrote: post #68
DannyBee wrote: post #55

Earlier quoted context omitted.

The real answer is because the people involved believe the licenses they are using are even more free. IE they do not subscribe to the FSF's ideology. It's their software, so they get to choose. It's like arguing NetBSD should use the GPL license. As for why it generally doesn't make sense to use the GPL for this: Even the FSF doesn't think GPLv2 is the right license for linux? GPL'ing linux hasn't prevented any of t…

Sure. So why not GPL (v3) it anyway, if the GPL is so ineffective? After all, what you're telling me in your posts is that Google wants vendors to contribute back, but it can't force them. I don't want vendors to be able to create proprietary extensions. You claim Google also doesn't want vendors to create proprietary extensions. So: - If the GPL is effective, why not use it? - If the GPL is ineffective, it can't pos…

"- If the GPL is ineffective, it can't possibly hurt and at the very least it sends a positive signal. So why not use it?"

1. Of course it can hurt. that's just silly to say. 2. As for why not use it? Because it's ineffective? You answered your own question?

This seems like a pretty basic GPL zealot argument at this point ("It's completely ineffective but you should do it anyway!") , and i'm pretty uninterested in continuing such arguments.

Re: How sandboxing works in Fuchsia

#82

Post by catern »

DannyBee wrote: post #81
catern wrote: post #68

Earlier quoted context omitted.

Sure. So why not GPL (v3) it anyway, if the GPL is so ineffective? After all, what you're telling me in your posts is that Google wants vendors to contribute back, but it can't force them. I don't want vendors to be able to create proprietary extensions. You claim Google also doesn't want vendors to create proprietary extensions. So: - If the GPL is effective, why not use it? - If the GPL is ineffective, it can't pos…

"- If the GPL is ineffective, it can't possibly hurt and at the very least it sends a positive signal. So why not use it?" 1. Of course it can hurt. that's just silly to say. 2. As for why not use it? Because it's ineffective? You answered your own question? This seems like a pretty basic GPL zealot argument at this point ("It's completely ineffective but you should do it anyway!") , and i'm pretty uninterested in co…

How, exactly, would it hurt? Perhaps by... discouraging use from companies that want to keep their changes private? I am completely fine with that. Proprietary code should not be allowed anywhere near the kernel or hardware support. Would it hurt in any other way?

As a concluding remark, I'll just repost what I posted elsewhere in this thread:

>Consider what happens if you're wrong. What happens if the GPL actually is the reason why Linux has such wide open-source hardware support? Then say goodbye to hacking on Fuschia on your own hardware...

>I'm not willing to take that risk.

"I beseech you, in the bowels of Christ, think it possible you may be mistaken!"

Re: How sandboxing works in Fuchsia

#83

Post by geofft »

DannyBee wrote: post #55
catern wrote: post #30

Earlier quoted context omitted.

Then why is it not licensed under the GPL, like Linux?

The real answer is because the people involved believe the licenses they are using are even more free. IE they do not subscribe to the FSF's ideology. It's their software, so they get to choose. It's like arguing NetBSD should use the GPL license. As for why it generally doesn't make sense to use the GPL for this: Even the FSF doesn't think GPLv2 is the right license for linux? GPL'ing linux hasn't prevented any of t…

> (If you've never read it, i suggest you go read the various threads where linus, etc explain that in practice, the only approach that works is carrot, not stick) [...]

> If you (or others here) dream is of an ecosystem where everyone is forced, under pain of death, to follow the GPL, it's pretty unrealistic. It's not what happens now, it will never happen.

And in response, see Bradley Kuhn's talk at LibrePlanet this year: https://media.libreplanet.org/u/libreplanet/m/understanding-... or the LWN writeup at https://lwn.net/Articles/719610/

Kuhn's argument is that the actual world has involved the stick and not (just) the carrot: GPL enforcement lawsuits have actually existed, and we can't really distinguish people who claim to believe in the carrot from people who would totally have ignored the GPL if it weren't for the realistic threat of lawsuits.

We do live in a world where people are forced under pain of copyright infringement lawsuits to follow the GPL. It is literally what happens now. As you yourself pointed out upthread, Google is quite conscientious about following the GPL, to the point of rewriting proprietary drivers. Even Debian doesn't do that (Nvidia, Broadcom, etc. drivers are available in non-free). Do you think that's because Google thinks the GPL is a great idea? No! Google knows that losing their license to use the Linux kernel is a real possibility under GPLv2 section 4, and would in fact be death for the company.

Re: How sandboxing works in Fuchsia

#84

Post by joshuamorton »

DannyBee wrote: post #81
catern wrote: post #68

Earlier quoted context omitted.

Sure. So why not GPL (v3) it anyway, if the GPL is so ineffective? After all, what you're telling me in your posts is that Google wants vendors to contribute back, but it can't force them. I don't want vendors to be able to create proprietary extensions. You claim Google also doesn't want vendors to create proprietary extensions. So: - If the GPL is effective, why not use it? - If the GPL is ineffective, it can't pos…

"- If the GPL is ineffective, it can't possibly hurt and at the very least it sends a positive signal. So why not use it?" 1. Of course it can hurt. that's just silly to say. 2. As for why not use it? Because it's ineffective? You answered your own question? This seems like a pretty basic GPL zealot argument at this point ("It's completely ineffective but you should do it anyway!") , and i'm pretty uninterested in co…

Your forgetting an important one. The default is a bsd-3 like license. Google prefers to release everything under that single license unless there are strongly compelling reasons to do otherwise, and "it can't hurt", even if it we're true, is not strongly compelling.

Re: How sandboxing works in Fuchsia

#85

Post by vertex-four »

catern wrote: post #82
DannyBee wrote: post #81

Earlier quoted context omitted.

"- If the GPL is ineffective, it can't possibly hurt and at the very least it sends a positive signal. So why not use it?" 1. Of course it can hurt. that's just silly to say. 2. As for why not use it? Because it's ineffective? You answered your own question? This seems like a pretty basic GPL zealot argument at this point ("It's completely ineffective but you should do it anyway!") , and i'm pretty uninterested in co…

How, exactly, would it hurt? Perhaps by... discouraging use from companies that want to keep their changes private? I am completely fine with that. Proprietary code should not be allowed anywhere near the kernel or hardware support. Would it hurt in any other way? As a concluding remark, I'll just repost what I posted elsewhere in this thread: >Consider what happens if you're wrong. What happens if the GPL actually i…

Linux does not have wide open-source hardware support on mobile phones, so that argument simply doesn't work in this space - you're arguing in favour of a supposed status quo that doesn't actually exist in the first place.

Re: How sandboxing works in Fuchsia

#86

Post by catern »

vertex-four wrote: post #79
catern wrote: post #68

Earlier quoted context omitted.

Sure. So why not GPL (v3) it anyway, if the GPL is so ineffective? After all, what you're telling me in your posts is that Google wants vendors to contribute back, but it can't force them. I don't want vendors to be able to create proprietary extensions. You claim Google also doesn't want vendors to create proprietary extensions. So: - If the GPL is effective, why not use it? - If the GPL is ineffective, it can't pos…

It sends a positive signal to a group of people who really don't matter - the very small minority of users who like open source and aren't already placated by AOSP existing - but a negative one to people who do - their vendors. Fuschia is designed so that driver sources don't need to be available, and we can still upgrade the kernel. This is better than doing exactly the same thing as before which didn't work . It so…

Let me restate that: "GPLing Fuschia sends a negative signal to vendors that don't want to release the source for their drivers."

That is fine. Any hardware that is released should come with full source code for its drivers. Vendors that are unwilling to comply, should not be releasing hardware. Since it would be infeasible and restrictive to legally enforce, we can just forbid them to use our popular open source kernels instead.

Please, consider the alternative world you want us to regress to! The present reality is practically utopian, compared to a world where the majority of drivers are proprietary! You want desktop/laptop/server computers to have the same awful, unfixable drivers as Android!? Fuschia will not magically make vendor code any less crap!

And, the "practical problem" here is created by licensing. You said it yourself:

>Fuschia is designed so that driver sources don't need to be available, and we can still upgrade the kernel.

This is a problem of licensing. If we were actually talking about purely technical solutions to purely technical problems, this problem wouldn't even exist. We would never have this bizarre problem of unreproducible binary artifacts sitting on our hardware without the ability to rebuild them.

Here is a thought: Maybe if Google started (threatening to) enforce the GPL against vendors, this would be fixed. Sure, it would also destroy their business relationships. But it would actually fix this security problem, today, immediately.

Re: How sandboxing works in Fuchsia

#87

Post by vertex-four »

catern wrote: post #86
vertex-four wrote: post #79

Earlier quoted context omitted.

It sends a positive signal to a group of people who really don't matter - the very small minority of users who like open source and aren't already placated by AOSP existing - but a negative one to people who do - their vendors. Fuschia is designed so that driver sources don't need to be available, and we can still upgrade the kernel. This is better than doing exactly the same thing as before which didn't work . It so…

Let me restate that: "GPLing Fuschia sends a negative signal to vendors that don't want to release the source for their drivers." That is fine. Any hardware that is released should come with full source code for its drivers. Vendors that are unwilling to comply, should not be releasing hardware. Since it would be infeasible and restrictive to legally enforce, we can just forbid them to use our popular open source ker…

So let me get this straight: your proposed alternative to Android is just... not having Android at all?

Re: How sandboxing works in Fuchsia

#88

Post by pritambaral »

DannyBee wrote: post #25
catern wrote: post #17

Earlier quoted context omitted.

OK, but that's irrelevant. Kernels are an entirely different class of thing. I'm fine with permissive licenses for higher-level software such as clang or GIMP. But I'm not looking forward to a world where I can't get the source code for a kernel that will actually run on real hardware. It's already painful to compile and run Android from source. Fuschia will make it just impossible.

"But I'm not looking forward to a world where I can't get the source code for a kernel that will actually run on real hardware. " You literally live in this world right now. "It's already painful to compile and run Android from source. Fuschia will make it just impossible." You can literally go download and compile the entire fuchsia kernel, right now . How is that "impossible"?

> You can literally go download and compile the entire fuchsia kernel, right now.

Only the kernel Google puts out for the development image. I think the parent meant more in the sense of real devices. It is already quite painful to run custom Android builds from source in real devices, where at least the kernel has copyleft protections. It is quite likely that real hardware running Fuchsia will not come with their sources, since Fuchsia isn't copyleft.

Re: How sandboxing works in Fuchsia

#89

Post by pritambaral »

DannyBee wrote: post #63
nickpsecurity wrote: post #27

Earlier quoted context omitted.

"You can literally go and compile the entire kernel, right now." Android discussions started that way. Things changed after enough time and revenue with a huge gap between ASOP and Android experience. Their security fixes vs Apple are also now abysmal. Might be a hint at the future of Google's next OS.

"Things changed after enough time and revenue with a huge gap between ASOP and Android experience." No, things changed for other vendors and for other parts . You can, AFAIK, still happily compile Google's entire kernels. You are thinking of userspace.

> still happily compile Google's entire kernels

Google's, sure. Some vendors make it painful (and in some cases, even impossible) to compile kernels for their devices.

Google is legally obligated to release kernels for their device. With Fuchsia, neither it nor any of the other hardware makers would be. Google might still continue to release their kernels — say, for developer contributions — but other vendors are quite likely to not do so.

Re: How sandboxing works in Fuchsia

#90

Post by sitkack »

themacguffinman wrote: post #14
pjjhdog wrote: post #2

So I'm not clear what the puropse of fuchsia is. I understand it's an os which may replace android or chomeos but why the move away from linux based systems? Both are open source platforms.

Fuchsia uses a microkernel (Magenta) which is more secure and technically elegant, but usually comes at the cost of performance. Google's position as the primary/sole developer of Fuchsia also gives them the control to build the OS in commercially lucrative ways that don't necessarily earn the approval of the Linux open source community (programming shortcuts, proprietary/non-GPL extensions, etc).

The other way we get separation is run multiple VMs under KVM which also has an overhead. The Microkernel arch that Linus never wanted is in fact, what we have right now. Exokernels and safe languages are necessity for getting having a good lifetime under battery power and having decent level of security.
Post reply on HN