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

131–140 of 172 posts

Re: How sandboxing works in Fuchsia

#131

Post by snarfy »

lucb1e wrote: post #126
negus wrote: post #100

"dev, gn, /svc, /pkg, PA_VMAR_ROOT" Hate this old unix approach for name shortening, what makes them unreadable and non intuitive. If they break compatibility anyway, they could name things in a way, that people can read like a book.

When programming, variables should be self-explanatory. However, things you re-type constantly (copy -> cp, remove -> rm, variable data -> /var) are fine to abbreviate with logical abbreviations. I don't have trouble understanding dev, /svc and /pkg because they're already common abbreviations. The gn and PA_VMAR_ROOT I'd have to look up, but if I'm using it constantly, I don't mind needing to learn. I mean, I needed…

I'd rather have typing assist than abbreviated names. To be self-explanatory, it's called ISingletonComponentFactory, but that doesn't mean I type all of that out.

Re: How sandboxing works in Fuchsia

#132

Post by dingo_bat »

bitmapbrother wrote: post #40
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.

I think it's pretty clear. They want an OS that can scale to any device. Whether Fuchsia replaces Android is unclear, but having their own PC OS in which Android can seamlessly integrate with much like iOS and MacOS can is very appealing.

Integration between iOS and Mac OS may just be because Apple controls both of them tightly. It doesn't tell us much about OS similarity or any deeply shared code. You can make two very different OSes integrate seamlessly with each other given full control over the OS code.

Re: How sandboxing works in Fuchsia

#133

Post by mikegerwitz »

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…

> Even the FSF doesn't think GPLv2 is the right license for linux?

Yes, they want a stronger license---GPLv3.

(Edit: I read your statement as "GPL is the right license"; I corrected my post.)

> GPL'ing the kernel or not does not change that some people don't follow the rules. You can have them sign it in blood if you want. They'll just work around you or ignore you, as long as there is money to be made. Also, once you are big enough, cutting them off will just attract regulators.

Your argument could extend to the entire free software movement---to all software written under the GPL. Your argument could be extended to _any_ license! It's dismissive of the impact of the free software movement and the successes of the GPL, and it's dismissive of the legal system as a whole.

Re: How sandboxing works in Fuchsia

#134

Post by Matumio »

alexvoda wrote: post #106
jhasse wrote: post #102

Earlier quoted context omitted.

Which means they can fork it anytime into a proprietary one.

They can do that regardless of the license since they own the copyright. As long as they do not accept external contributions or require a CLA it does not matter what license they offer, they can still make future versions proprietary.

Even if they accept contributions normally (e.g. under the same license), the above licences will allow them (or anyone else) to make a proprietary fork.

Re: How sandboxing works in Fuchsia

#135

Post by kiriakasis »

catern wrote: post #80
pgeorgi wrote: post #75

Earlier quoted context omitted.

It's a microkernel, somewhere in the middle of the spectrum. Not as extremly reduced as L4, but not the heavyweight that Mach is, either. The kernel will probably be the one component vendors (chipset or OEM) won't ever feel the need to touch (except for new architectures), since they can put everything in userland processes that they want to keep hidden. Not even the GPLv3 would help there.

Yes, indeed, that makes it even more distressing that they didn't bother to license even the core of the system with the GPL. It sends a signal that they really completely don't care about the freedom for users to modify the software and run it on their own hardware.

the "users" of fuchsia most likely will not be developers only, if GPL is just a symbol, a golden star to show you are a good kid then it does not look so foundamental to me.

as other have said the driver API should actually make that easier (in intents).

Re: How sandboxing works in Fuchsia

#136

Post by [deleted] »

tonfa wrote: post #127
geofft wrote: post #78

Earlier quoted context omitted.

> If you were to bug the SFLC/others, you'd see Google is, in fact, quite happy releasing kernel changes, and is pretty much one of the only companies that has either pushed vendors to open source drivers, or, in a number of cases, rewritten proprietary android drivers as open source just so it can release them! "Happy" is a funny word though. Google is legally obligated to release kernel changes and legally forbidde…

> "Happy" is a funny word though. Google is legally obligated to release kernel changes and legally forbidden from shipping kernels that incorporate other people's GPL-incompatible drivers. I suppose the OP was also talking about the changes done to improve linux for datacenter workflows, afaik there is no obligation to release the changes there.

[deleted]

Re: How sandboxing works in Fuchsia

#137

Post by willvarfar »

nickpsecurity wrote: post #4
DonbunEf7 wrote: post #3

If you're going to have capability-based security, please be louder and prouder about it.

Maybe. They start with names. However, the description looks more like access control lists than what I saw in KeyKOS, LOCK, EROS, E, or Combex's work.

In Unix, rights - even POSIX "cpabilities" - belong to the process. In Magenta, the rights are attached to the handle.

Re: How sandboxing works in Fuchsia

#138

Post by jstimpfle »

snarfy wrote: post #131
lucb1e wrote: post #126

Earlier quoted context omitted.

When programming, variables should be self-explanatory. However, things you re-type constantly (copy -> cp, remove -> rm, variable data -> /var) are fine to abbreviate with logical abbreviations. I don't have trouble understanding dev, /svc and /pkg because they're already common abbreviations. The gn and PA_VMAR_ROOT I'd have to look up, but if I'm using it constantly, I don't mind needing to learn. I mean, I needed…

I'd rather have typing assist than abbreviated names. To be self-explanatory, it's called ISingletonComponentFactory, but that doesn't mean I type all of that out.

Typing assistants mostly suck. And it's not only about the typing. You still have to read the names or process them otherwise.

"Self-explanatory": That doesn't exist. You always need context. The art is to use just enough verbosity. Say the interesting and distinctive things. Not the boring things that can be easily figured out (Singleton, Factory, boring. What kind of component?)

Re: How sandboxing works in Fuchsia

#139

Post by pgeorgi »

catern wrote: post #80
pgeorgi wrote: post #75

Earlier quoted context omitted.

It's a microkernel, somewhere in the middle of the spectrum. Not as extremly reduced as L4, but not the heavyweight that Mach is, either. The kernel will probably be the one component vendors (chipset or OEM) won't ever feel the need to touch (except for new architectures), since they can put everything in userland processes that they want to keep hidden. Not even the GPLv3 would help there.

Yes, indeed, that makes it even more distressing that they didn't bother to license even the core of the system with the GPL. It sends a signal that they really completely don't care about the freedom for users to modify the software and run it on their own hardware.

Why license the kernel GPL if it doesn't matter any because every vendor would be totally willing to put it up in any case (or defer to the official repo because they made no changes anyway)?

Such an approach smells of virtue signalling, and IMNSHO we have way too much of that already.

Re: How sandboxing works in Fuchsia

#140

Post by IshKebab »

jstimpfle wrote: post #138
snarfy wrote: post #131

Earlier quoted context omitted.

I'd rather have typing assist than abbreviated names. To be self-explanatory, it's called ISingletonComponentFactory, but that doesn't mean I type all of that out.

Typing assistants mostly suck. And it's not only about the typing. You still have to read the names or process them otherwise. "Self-explanatory": That doesn't exist. You always need context. The art is to use just enough verbosity. Say the interesting and distinctive things. Not the boring things that can be easily figured out (Singleton, Factory, boring. What kind of component?)

Wait so you think "svc" is easier to read & process than "service"? What planet are you on?
Post reply on HN