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

Fuchsia: a new operating system

lwn.net

Post reply on HN
Print view View original

171–180 of 324 posts

Re: Fuchsia: a new operating system

#171

Post by nickpsecurity »

catern wrote: post #145
naasking wrote: post #121

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…

And as an even deeper correspondence: Once your language is memory-safe and capability-secure, you don't even need a kernel, let alone a microkernel. Rather than use hardware address spaces to separate and modularize components (the primary idea behind microkernels), you just pass capabilities around to your components. One component can't crash the whole system, because all it can access is the APIs you pass in to i…

JX Operating System does something like this within a JVM. It runs on a microkernel but I think the mediation is app/language level.

Re: Fuchsia: a new operating system

#172

Post by cobbzilla »

cwyers wrote: post #62
jcoffland wrote: post #12

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.

The first time I saw Linux in a work environment was in '96 as a Samba file server on our office LAN, which was otherwise dominated by Windows NT machines. I think it was set up partly for novelty (someone wanted to play with Linux), and partly to save money on not buying one more Windows license.

Re: Fuchsia: a new operating system

#173

Post by nickpsecurity »

kjksf wrote: post #141
cmrdporcupine wrote: post #70

I don't understand what the value is in writing a new original microkernel from scratch in this day and age when sel4* is free and open source, performance tuned for 20ish years, is security hardened, and is provably correct for both security and features? This doesn't seem like a wise path to take. * See http://sel4.systems/

I know nothing about differences between fuchsia and sel4 but it would be rather strange if something as complicated as a OS kernel wouldn't have many parts where you have to make trade-offs. People compete fiercely in the field of todo applications, I don't see why there shouldn't be competition in microkernel space. Things changed in hardware in last 20 years and maybe we've learned something about software as well…

I think author meant L4 kernels were performance tuned for 20 years to be the fastest. Then, one using applying such lessons was mathematically verified for correctness down to assembly. It's proprietary and open-source depending on what your end product will be. They'd probably even add features to it for a Google-specific version that leveraged as many proven compinents as possible.

Re: Fuchsia: a new operating system

#174

Post by staticassertion »

nickpsecurity wrote: post #170
staticassertion wrote: post #155

Earlier quoted context omitted.

I wouldn't use SEL4 as an argument. It is completely unreasonable to build a production kernel the way they did - it took them ages to get what they had. Google is probably looking to develop features/ move code a lot faster than is possible using their technique. Good coding practices take no time to implement, you learn it once and you write that way. It is not bullet proof, neither are capabilities. Still, at leas…

How about Muen separation kernel in SPARK Ada with automated prover eliminating many classes of undefined behavior? Or C with tools like Frama-C and Astree Analyzer (like SPARK for C)? C++ can't reach the safety of its competition due to more complexity and less tooling.

I'm only commenting on seL4's approach not being very viable. I'm not advocating for C++ in the kernel either.

Re: Fuchsia: a new operating system

#175

Post by tyingq »

techenthusiast wrote: post #60
jasonvorhe wrote: post #46

Earlier quoted context omitted.

Your guess is as good as mine, but there are some clues: https://techspecs.blog/blog/2017/2/14/googles-not-so-secret-... https://techspecs.blog/blog/2017/2/15/proof

Thanks, but would sooner recommend my third article: https://techspecs.blog/blog/2017/3/15/fuchsias-hypervisor .

The link in the bottom of your first article was very helpful, and seems to confirm ChromeOS and Android would be the likely targets.

https://fuchsia.googlesource.com/magenta/+show/master/docs/m...

Re: Fuchsia: a new operating system

#176

Post by cbsmith »

icebraining wrote: post #163
cbsmith wrote: post #105

Earlier quoted context omitted.

No, but pushing that agenda via architectural level changes is not exactly a way to get a good architecture.

An architecture is a structural design made to achieve certain goals. They just happen to have another goal to achieve.

It's even bad by that standard. When you compromise the function of the system to achieve that kind of goal, you end up losing out on both.

Re: Fuchsia: a new operating system

#177

Post by SureshG »

greenhouse_gas wrote: post #124
sethladd wrote: post #96

Earlier quoted context omitted.

(disclaimer: I work on the Flutter team.) You can use Flutter today to write an app that runs on iOS and Android. :)

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…

Dart has strong mode (this is enabled by default for its Angular2 projects) - Check this talk on sound Dart for more details https://www.youtube.com/watch?v=DKG5CMyol9U

Re: Fuchsia: a new operating system

#178

Post by sedachv »

skissane wrote: post #159
sedachv wrote: post #108

Earlier quoted context omitted.

> 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 From the 1980s to 1993 there were: v7 ports: Microsoft Xenix (later became SCO), Venix, Coherent System III ports: PC/IX (later 386/ix) SVR3 ports: official Intel, ESIX from Everex SVR4 ports: Dell UNIX, Novell UnixWare, Microport

Strictly speaking, Coherent wasn't a V7 port – they wrote the code from scratch rather than using any of AT&T's code, and they never paid AT&T any Unix license fees. AT&T was suspicious, but even after a careful investigation by Dennis Ritchie himself, they couldn't prove any of their code had been copied. Given both the V7 source code and Coherent source code have now been released, you can compare them yourself and…

I am actually on the lookout for Coherent 2 or earlier sources. It would be very interesting to see how it worked on the 8088.

Re: Fuchsia: a new operating system

#179

Post by amaranth »

greenhouse_gas wrote: post #134
adrianratnapala wrote: post #45

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.

Just because there's a stable API doesn't mean the manufacturers will actually upgrade. Unless there's some legal requirement, it's going to be the same fragmentation

If they have a stable driver ABI Google can be responsible for the upgrading. They just have to require the OEMs allow them to do so.

Re: Fuchsia: a new operating system

#180

Post by stouset »

ClashTheBunny wrote: post #58
desdiv wrote: post #39

Earlier quoted context omitted.

>They are drawing everything in userspace with fast graphics render... Dumb question, does this mean that it's limited to software rendering only? You need to go through the kernel to talk to the GPU, right?

In addition to the other comments, I would be excited about a graphics driver not being able to take out my system.

Does this actually happen with enough regularity to care?

In the cases where it does, I imagine it's a situation where you're actually doing 3D-accelerated renders of the user interface. In which case, when the graphics subsystem craps out, hasn't your running system been rendered effectively unusable anyway?

I get that this is a nice idea in theory, but does it actually improve anything practical in practice?

Post reply on HN