Live data from Hacker News

Fuchsia: a new operating system

lwn.net

251–260 of 324 posts

Re: Fuchsia: a new operating system

#251
post #224

Earlier quoted context omitted.

Not only Windows, the majority of operating systems are like that, even the old time commercial UNIXEs, only GNU/Linux forces an unstable driver ABI on developers.

Linux and *BSD. FreeBSD will break ABI every major version, roughly every 2 years. https://wiki.freebsd.org/VendorInformation OpenBSD even goes so far as to break the user-space libc ABI in minor releases: http://www.openbsd.org/papers/eurobsdcon_2013_time_t/

Ah ok, I though the *BSDs followed the UNIX old school of stable ABIs.

Besides toying around with FreeBSD in the late 90's, I never used it properly.

Re: Fuchsia: a new operating system

#252
post #195

Earlier quoted context omitted.

Yes? I haven't played games in a while, but when I did, crashes were frequent enough to be annoying, and ~100% of the time it was video drivers.

Right, but that's my point. You're playing a game and the display crashes — I guess it's nice in theory that the rest of your system stayed up, but you're still more than likely just going to reboot, no? If not, how exactly do you plan to restart the graphics process?

If the OS itself doesn't automatically recover the graphics process, you could always fire up your OS's built-in screen reader and use it like a blind person until you can get the graphics back up and running.

Re: Fuchsia: a new operating system

#253

Earlier quoted context omitted.

> Namespaces are really useful, and are probably here to stay. But as long as things can be accessed by names, the access will need to be controlled by something like an ACL. Not necessarily. If your system supports first-class namespaces, then you can just build a namespace consisting of only the objects to which a program should have access. No need for any further access control. A file open dialog from a program…

Hmm, that sounds a bit awkward -- every capability on the system would, at least conceptually need a separate copy of the pruned name-tree. There might be good ways of implementing that, but it's not obvious. On the other hand, I can see how capabilities would mix with ACLed namespaces to improve security. Essentially it would define the semantics of things like cgroups and chroot jails. In fact sometimes I think tha…

> Hmm, that sounds a bit awkward -- every capability on the system would, at least conceptually need a separate copy of the pruned name-tree.

First-class namespaces are an implmentation of capabilities. You wouldn't necessarily need capabilities on top of that. You'd pass around namespaces or perform namespace mappings to grant or revoke authorities.

> On the other hand, I can see how capabilities would mix with ACLed namespaces to improve security.

You can use ACLs to implement capabilities [1], which the capability folks did with Windows XP as a proof of concept with a modern OS [2] (I don't know why Microsoft didn't just adopt Polaris to be frank). But in general you shouldn't use ACLs to try augment capabilities. They restrict the class of expressible security policies without actually adding security (and in fact, they introduce insecurity).

[1] http://www.webstart.com/jed/papers/Managing-Domains/

[2] http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html

Re: Fuchsia: a new operating system

#254
post #245

Earlier quoted context omitted.

And for another beautiful convergence: nowadays most software development is done in languages that naturally express capability patterns, namely memory-safe languages. That is, if you have a reference to an object or value, you have the authority to invoke any of the methods on that object or call any functions that accept such a value. So object references are capabilities. Most such languages only go too far by al…

> To make a memory safe language capability secure, you simply remove all sources of ambient authority. Isn't this more or less what Sun tried to do with Java applets, which in practice turned out not to be so simple while providing a rich API?

> Isn't this more or less what Sun tried to do with Java applets, which in practice turned out not to be so simple while providing a rich API?

I'm not familiar with the Java applet model specifically, but Java's general security model is based on stack inspection, which is nothing like capabilities.

Re: Fuchsia: a new operating system

#255
post #224

Earlier quoted context omitted.

It will go down the Windows model of having a stable kernel ABI (I assume). And suffer/enjoy the same trade-offs as Microsoft. That model is not perfect, but it worked for MS -- and Google is in a similar enough position.

Not only Windows, the majority of operating systems are like that, even the old time commercial UNIXEs, only GNU/Linux forces an unstable driver ABI on developers.

Except that the "stable ABI" thing doesn't work in practice. Look at all the people who have to throw away perfectly good hardware every time a new Windows version comes out, because the hardware maker doesn't care about updating their drivers and just tells customers to buy a new version.

Re: Fuchsia: a new operating system

#256
post #225

Earlier quoted context omitted.

And for another beautiful convergence: nowadays most software development is done in languages that naturally express capability patterns, namely memory-safe languages. That is, if you have a reference to an object or value, you have the authority to invoke any of the methods on that object or call any functions that accept such a value. So object references are capabilities. Most such languages only go too far by al…

> That is, if you have a reference to an object or value, you have the authority to invoke any of the methods on that object or call any functions that accept such a value. Except private methods, right? That's where I feel that this analogy breaks down

Yes, you can only invoke the publicly interface of an object. It's not an analogy, object references really are capabilities.

Re: Fuchsia: a new operating system

#257
post #127

Earlier quoted context omitted.

>C++. Oh lord. Why are you writing a microkernel in C++? If there was anything they learned from L4 (Xen, Linux, ...) it is that C is sufficient. Why do you want to implement something small with something that is large? This one is a real head scratcher. Because if there was anything proven from years and years of using C, it's that it is woefully insecure and should not be trusted to write a kernel with. You can st…

"folks it's ok, we're using shared_ptr's. We're safe. Problem solved."

Shared_ptr is slow. It has an atomic variable for reference counter - it is supposed to be thread safe...

Re: Fuchsia: a new operating system

#258
post #209

Earlier quoted context omitted.

Right, but that's my point. You're playing a game and the display crashes — I guess it's nice in theory that the rest of your system stayed up, but you're still more than likely just going to reboot, no? If not, how exactly do you plan to restart the graphics process?

Windows automatically restarts the GPU driver after a crash; the screen goes black for a few seconds and then all the windows come back up. It can also upgrade the GPU driver without a reboot. It's not used often but it's pretty handy.

I think that was the moment I realised I liked Windows 7 more than XP. Installed new graphics drivers, expected "you must reboot your system", instead the screen went black (I had a moment of 'oh crap') and then came back up with 'installation complete.' Very impressive if you're used to XP.

Re: Fuchsia: a new operating system

#259
post #62

Earlier quoted context omitted.

> Linux essentially sucked all the air out of the UNIX development space by killing off all the commercial UNIXes. Only because they have done a really good job.

Eh. The biggest thing Linux had going for it in terms of winning market share was running on commodity x86 parts in a time period when the commercial Unices weren't touching it, and x86 made really strong gains in beating everybody else at performance per dollar.

You make it sound like Linux was the only option on x86.

Re: Fuchsia: a new operating system

#260

Earlier quoted context omitted.

How is it in turns of speed? On one hand, the website says that it's compiled to native code (so it can be same speed/faster than Java), but on the other hand, it's based on a soft-type language, which makes optimization difficult (even with V8, JS is still slower than native code). Side question: I understand that Dart was soft-typed because it was supposed to replace/compile to JS, but what advantage does soft-type…

You might want to watch this talk on AOT compiling Dart, I'll link right to the perf benchmarks: https://youtu.be/lqE4u8s8Iik?t=9m28s I think it's a work in progress, but main benefit at least at the time was faster startup.

AOT compiling was initially all about iOS (where JIT isn't allowed), but you can now do that everywhere with "application snapshots" which were recently added with Dart 1.21.

Unlike the script snapshots, application snapshots also include CPU-specific native code in addition to the serialized token stream of the source code.

So, you don't just skip the parsing stage, you also skip the warmup phase. Your application starts instantly and it runs at full speed from the get-go.

https://github.com/dart-lang/sdk/wiki/Snapshots

Post reply on HN