Live data from Hacker News

How sandboxing works in Fuchsia

fuchsia.googlesource.com

141–150 of 172 posts

Re: How sandboxing works in Fuchsia

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

GoboLinux had an amazingly awesome alternative file system layout https://en.m.wikipedia.org/wiki/GoboLinux

Re: How sandboxing works in Fuchsia

#142
post #126
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'm hoping Fuchsia isn't being designed as an OS where you constantly have to type file paths.

Also you rarely need to type full paths even on Linux. I'm nearly all shells you can press tab to autocomplete them. I.e. you press "/d" and it will change it to /dev. That's exactly the same for dev and devices.

There's really no reason for short confusing names other than laziness and jargon-based egotism.

Re: How sandboxing works in Fuchsia

#143
post #122
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.

Does it have creat?

Given how they named everything else it's probable 'cre'.

Re: How sandboxing works in Fuchsia

#145
post #122
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.

Does it have creat?

skng th mprtnt qstns n mssng vwl t a tm

Re: How sandboxing works in Fuchsia

#146

Earlier quoted context omitted.

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?

It is, depending on how often it's used and how cohesive the implementation is. Anyway "service" is one of these terrible non-descriptive names. Is this some kind of abstract datatype? A reference to a system daemon? Or just a data value processed by business logic? You need context anyway.

Re: How sandboxing works in Fuchsia

#147

Earlier quoted context omitted.

This is definitely true, and I have a lot of issues with Google and their lip service to open source. (People reading my history will attest, I'm sure.) But at the very least, Fuchsia will be a lot more secure by design than Android, and Android is the dominant OS platform on earth. The state we are right now, where 85% of mobile devices run Android, and 0.7% of them are actually up to date, is a terrifying place to…

Why am I not surprised that you can't even get your percentages correct.

Did you mean he was exaggerating? Because it's actually 0.6%.

Re: How sandboxing works in Fuchsia

#148

Earlier quoted context omitted.

This is definitely true, and I have a lot of issues with Google and their lip service to open source. (People reading my history will attest, I'm sure.) But at the very least, Fuchsia will be a lot more secure by design than Android, and Android is the dominant OS platform on earth. The state we are right now, where 85% of mobile devices run Android, and 0.7% of them are actually up to date, is a terrifying place to…

Why am I not surprised that you can't even get your percentages correct.

Sorry, unfortunately I did get my numbers wrong. Based on a chart of Android versions taken from the Google site, it will probably be at least a month or two before 0.7% of Androids are running the latest version. My bad!

I keep a running copy of the stats here: https://oasis.sandstorm.io/shared/UtPbpOAW2OaV4QpkgwIclqGeGC...

Re: How sandboxing works in Fuchsia

#149

How to request capabilities at run time? Android has shown that the approach of asking for a list of capabilities while installing does not work for user-facing applications. Apps will grab just as much as capabilities as possible and users will blindly accept the long list without reading.

If the only options available are granting all requested permissions at once or not installing at all, they'll often blindly accept, yes.

Re: How sandboxing works in Fuchsia

#150
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?)

> You still have to read the names or process them otherwise.

And how long does it take you to parse "svc" vs. "service" in average microseconds per day? With old unix there was at least a need to keep memory use low, today we are only limited by Microsofts MAX_PATH.

Post reply on HN