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

131–140 of 324 posts

Re: Fuchsia: a new operating system

#131

Post by kjksf »

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…

Even the original, untyped, Dart was designed to be easier to optimize that JavaScript (e.g. it's class based, not prototype based, so the runtime doesn't have t work as much to optimize object access).

Recently Dart has added a strong mode (https://github.com/dart-archive/dev_compiler/blob/master/STR..., http://news.dartlang.org/2017/01/sound-dart-and-strong-mode....).

One of the reasons for strong mode is to enable better optimizations (https://www.dartlang.org/guides/language/sound-faq#why-stron...).

Re: Fuchsia: a new operating system

#132

Post by cwyers »

sedachv wrote: post #108
cwyers wrote: post #62

Earlier quoted context omitted.

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 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

Okay? Red Hat Enterprise Linux wasn't released until 2000, so I don't know what Microsoft's late-80s UNIX distribution has to do with it. Google was running Linux from the early days, and they launched in 1998, which is nearly a decade after Xenix stopped being updated.

EDIT: Yes, Linux has its origins sooner, and if you want to know why Linux beat the BSDs to mindshare, what was going on in 1993 is very important. But Linux wasn't competing for mindshare with Xenix, it was stuff like Solaris (which did have an x86 port, but was mostly running on SPARC), AIX (which was mostly IBM big-iron and POWER), HP-UX (which was PA-RISC and IA-64), etc.

Re: Fuchsia: a new operating system

#133

Post by bitmapbrother »

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 supports strong typing.

Re: Fuchsia: a new operating system

#134

Post by greenhouse_gas »

adrianratnapala wrote: post #45
monocasa wrote: post #38

Earlier quoted context omitted.

> won't publish their sources for the various device drivers needed. And how is Fuchsia supposed to help that?

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

Re: Fuchsia: a new operating system

#135

Post by deaddodo »

desdiv wrote: post #39
kardianos wrote: post #5

What makes Fuchsia different then so many other attempts at writing a new OS? They aren't writing a new OS, at least, not in the complete sense. They are using the IPC system developed in and extracted from Chrome. They are drawing everything in userspace with fast graphics render but the logic for all system components written in Dart from the Flutter project. They use musl for the libc. They are using the little ke…

>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?

Depends on the OS design. It's really not a good design, but you could run everything in ring0 (x86), supervisor mode (ARM), etc. However, now any fault (user or OS) could halt your system and you have no memory protection or process separation.

Re: Fuchsia: a new operating system

#136

Post by rwmj »

makomk wrote: post #110
mankash666 wrote: post #49

Earlier quoted context omitted.

No. GPUs typically work over the PCIE bus, and one can talk to PCIE via user space as well. In legacy systems like Linux the mapping of virtual to physical address and generation of scatter-gather-lists (SGLs) resided in the kernel. If one moves the same functionality to the user space without loss in performance (which is what magenta seems to do), there's no benefit to kernel GPU drivers. Then there's the whole "GP…

Having control over the virtual to physical address mapping and scatter-gather lists for GPUs is effectively equivalent to kernel-level access anyway, though, because it lets you carry out DMA to and from arbitrary physical memory addresses. Some proprietary drivers for mobile GPUs have even given this level of access to untrusted user processes in the past leading to privilege escalation to root.

Not with IOMMU (Intel VT-d and similar).

Re: Fuchsia: a new operating system

#137

Post by catern »

naasking wrote: post #123
adrianratnapala wrote: post #43

Earlier quoted context omitted.

I'm no Windows expert, so I didn't know that windows handles were used as security primitives. I thought they were just a bit like file-descriptors or X11 window ids, or indeed pointers. Such handles do have a kind of role in authorization: once a process has convinced the system to give it some resource, then the (handle, processid) pair is all the system needs to check access. However you typically gain the handle…

> 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…

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

Unfortunately this is usually quite heavyweight. In Unix-like systems, and in Plan 9, the canonical way to do this is to implement a filesystem. "Filesystem" is the universal IPC layer. But implementing a filesystem usually takes quite a lot of effort.

Do you know of any systems where this can be done easily enough for it to be used ubiquitously?

One would much prefer to just put together a hierarchy of objects at the language level and automatically expose it... or something like that anyway.

Re: Fuchsia: a new operating system

#138

Post by pjmlp »

protomyth wrote: post #107
puzzle wrote: post #66

Earlier quoted context omitted.

The future? The System/38 (aka AS/400 aka iSeries aka System i) had capabilities from the beginning, almost 40 years ago.

I sometimes wonder if addition to a Ethics class, Computer Science students need to take a Computer Archaeology class. It might not be a bad thing to bring up a lot of the concepts that aren't in the main stream anymore that have been tried.

Surely, then younger generations would learn how Algol and PL/I were used to write OSes, how Xerox PARC and EHTZ managed to write OSes without a single line of C code and that UNIX wasn't the genesis of operating systems.

Re: Fuchsia: a new operating system

#139

Post by sedachv »

cwyers wrote: post #132
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

Okay? Red Hat Enterprise Linux wasn't released until 2000, so I don't know what Microsoft's late-80s UNIX distribution has to do with it. Google was running Linux from the early days, and they launched in 1998, which is nearly a decade after Xenix stopped being updated. EDIT: Yes, Linux has its origins sooner, and if you want to know why Linux beat the BSDs to mindshare, what was going on in 1993 is very important. B…

If you want to talk about post-1993, saying that Linux won because there weren't any commercial x86 Unices makes even less sense. Xenix did not stop being updated, it became SCO UNIX. SCO bought and continued to sell UnixWare from Novell in 1995. x86 Solaris came out in 1993, but Sun actually had an x86 Unix since 1991 when they bought ISC.

Re: Fuchsia: a new operating system

#140

Post by ndesaulniers »

pikzen wrote: post #127
CalChris wrote: post #90

I've been waiting for this to be released. I suppose everyone has been. Capabilities . Like fine grain locks, these are very powerful and very hard to get right. That's the lesson from Hydra, the 432, .... No, it's not a hard mechanism for the microkernel to get right; it's a hard policy for the application programmer to get right. However, that's probably more of an opportunity rather than meant as a criticism. Our…

>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."
Post reply on HN