The one thing that stood out to me is the name of former Be employee Travis Geiselbrecht. If you are unaware, he created NewOS, which was forked years ago and became the kernel for Haiku.
I didn't realize that he was working for Google.
Fuchsia: a new operating system
181–190 of 324 posts
Re: Fuchsia: a new operating system
#182Earlier quoted context omitted.
offering no alternative but "open source" on Linux is certainly not the most business friendly way to go about it.
Being business-friendly is not a goal, and shouldn't be a goal.
> Being business-friendly is not a goal
Sure, it is, for lots of people. Even, apparently, the FSF, hence the reason non-consumer products are not subject to anti-tivoization rules in GPLv3.
Re: Fuchsia: a new operating system
#183Earlier quoted context omitted.
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.
Fair enough.
Re: Fuchsia: a new operating system
#184Capability-based operating systems must be the future. If they are not, then we are all doomed to continue to exist in a messy world where security problems crop up every minute. Capability-based access controls are one of the best options for getting out of our current mess, but they're also the type of thing that must be implemented very low in the system in order to work. Hopefully, when we start ripping out *nix…
Capabilities? FreeBSD, and other Unix flavors have had caps for decades. No one uses them. Security is useless if no one uses it. Capabilities are too hard, too complex, to manage. Great idea. Horrible implementation.
Unix 'capabilities' (before Capsicum, iirc) were a different thing with the same name. Confusing. Unix actually does have a different construct that is like a classical capability: an open file descriptor that you can send to another process over a Unix domain socket.
Re: Fuchsia: a new operating system
#185Lots of interest in Microkernels since everyone got tired of kernel vulnerabilities. So who won the Tanenbaum–Torvalds debate? It is too soon to say (Zhou Enlai said that of the French revolution - almost 200 years after the fact)
https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
The article says that the focus is on 'PCs, tablets, and high-end phones'. Wouldn't a more secure OS be relevant to server environment? Is the performance cost of a microkernel considered to be too high for a server OS? Is it too difficult to do?
Re: Fuchsia: a new operating system
#186Earlier quoted context omitted.
Not often someone says lean and VS Code in the same statement.
It’s not very fast, but it’s surprisingly easy on the resources, especially memory. Compare using VS Code w/ Typescript Language Service to any type of dev stack that includes the word “Scala.”
> It’s not very fast, but it’s surprisingly easy on the resources, especially memory.
Open VS Code and then Sublime and be amazed.
Atom and VS Code can never be 'easy on the memory' because they have to load an entire Electron instance just to idle.
Re: Fuchsia: a new operating system
#187The memory mapping model is really interesting, since it moves a lot of that out of the kernel and into user-space, but it seems like it has more disadvantages than advantages. What am I missing?
Are you asking about VMOs or VMARs?
In general: it gives a process a huge amount of flexibility in terms of how it sets up its own address space, communicates with other processes, and in how it can communicate with the kernel.
Re: Fuchsia: a new operating system
#188What 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…
Oh they're using Dart. That's really cool. Dart is surprisingly pleasant to work with.
Re: Fuchsia: a new operating system
#189Earlier quoted context omitted.
Not often someone says lean and VS Code in the same statement.
Yeah I used to use Atom. I know Vim is what I should use for "lean" but it's not easy to use. I did see some pretty themes 'space wrap' or something like that.
Vim is well known for its bloated, messy codebase. I'd hardly call it "lean".
Re: Fuchsia: a new operating system
#190Earlier 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…
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 that mainstream virtualisation is slowly reinventing -- in an incremental way -- what various alternative OSes advocated in a radical way. E.g. Linux cgroups and "one process per container" sounds quite a lot like Plan9's per-process view of the system.