Re: [SharpOS Developers] SharpOS vs Singularity

[Scott B. <sb...@me...>]

Chad Z. Hower aka Kudzu wrote:
> I looked at Singularity about 2 years back. I haven't looked at it since
> then. I spent the last 2 years developing a lot of ideas etc. Today I
> reviewed newer info on Singularity. Its pretty much 100% inline with what
> I've designed. There are some differences of course, but the major parts are
> pretty identical.
>
> That being said - moving forward how do you guys see SharpOS being
> different?
>   

Personally, our goals aren't *too* different, AFAICT. We both are 
writing an OS running under a bare-metal CLR, with a microkernel design. 
However, Singularity's singular goal (sorry the pun) is to be 
research-oriented towards mathematically verifiable formal security. 
This includes creating a subset of C# with formal-verification language 
constructs.

Whereas with SharpOS, I would see a general purpose operating system, 
written in pure C#, C++/CLI, or really any CLR-compliant source 
language, without any new compiler-level language constructs necessary. 
Obviously custom attributes and a custom compiler are okay here. But the 
source language itself is the same general-purpose C# that "everyone 
else" knows.

On a further level, in my design for Ensemble that I would be advocating 
in the future for SharpOS, I see a more interactive text-based console 
working at the object level (Monad / Powershell on steroids), with more 
interactivity than just a Unix prompt. I take the inspiration and 
initial ideas for this from a series of IRC chats I had years back with 
Slava Pestov, the author of jEdit and the Factor programming language. 
See the interactive console of Factor for more information.

Afterwards, elements of distributed processing from Plan9 would be 
integrated. As this is a microkernel design, communication between apps 
and microkernel services would be through the same basic form of in-VM 
.Net Remoting as would be needed for physically-distributed services. 
One uses an in-memory protocol, while the other uses an over-the-network 
protocol. But to the app, it is transparently distributable. This goes 
along with a resurgence of the "home / department app server with 
partially-run-locally apps running on semi-dumb terminals" physical 
computing idea that was from a few years back, and is coming back lately.

Filesystem wise, an object pool variant of ZFS would be appropriate. 
Data moves away from being a named file into a persisted object (still a 
file in the end, but more OO), with tagged attributes and relations 
between objects, rather than hierarchical directories. That's in my 
design paper, IIRC.

Anyway, that was my overarching idea.