Menu
▾
▴
sharpos-developers
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 19:23:32
|
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? -- Chad Z. Hower aka Kudzu "Programming is an art form that fights back" http://www.KudzuWorld.com/ http://www.Woo-Hoo.net/ http://www.DelphiToDotNet.com/ |
|
From: Scott B. <sb...@me...> - 2007-08-28 20:08:37
|
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. |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 20:22:39
|
> 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. Im very interested in this as well. Many of the same ideas as Singularity, although I have some others too I haven't seen them mention. > Anyway, that was my overarching idea. Thanks for the detailed post. |
|
From: Pieter M. <pie...@in...> - 2007-08-28 20:51:20
|
Well, I've read Scott's design paper. And it has most of the elements that I would want in a managed operating system. Here are some of the key features I would love to see (just from the top of my head): 1. Execute the kernel, drivers and applications in ring 0. Because we can use software protection through appdomains we don't need the hardware protection of execution rings. This way we can significantly improve performance by not having to do context switches all the time. Compatibility with non-managed/unsafe applications can be achieved by running these in ring 3 as usual. I think we could even emulate other kernels for these non-managed applications by translating their system calls. 2. A microkernel that only handles system resources at the lowest level and manages communication between all other parts. All popular OS's are monolithic because of performance reasons (context switches), a managed system does not have to be. 3. Only managed code. (except maybe the very first boot instructions) 4. The kernel strictly manages system resources. Drivers request everything from the kernel, and the kernel makes sure they don't use anything else. Drivers could have a manifest file (like in Singularity) so the kernel can verify they have everything they need before trying to initialize the driver. 5. Possibility for distributed behavior. My ideas here are almost identical to those of Scott. The microkernel abstractions should make it relatively easy to let applications use remote resources transparently. I also have an idea in this area that I haven't heard mentioned elsewhere. Just like a system can distribute processes between it's cores, it could also distribute them in the same way over the network. If we have for example a cluster of a few servers and one of them is overloaded, it could serialize some processes and send them over to an idle machine that can handle the load. The connections to other resources can simply be changed from local IPC to remote TCP communication. The application wouldn't notice any difference (except a short delay while transferring). You can see that everything in the business world is moving to centralized locations: web applications/services, Citrix, terminal servers, ... This move is inspired by the fact that users want to be able to have access to their data and applications from everywhere in the world. I believe major problems in the future will be: a) distributing these centralized loads over a set of available servers b) letting users transparently access centralized data and applications from everywhere, anytime and without configuring a lot of stuff I think a managed operating system can solve both of these problems if applied correctly. Insite Mees-Delbeke VOF Zomerstraat 29A 9270 Laarne Telefoon: 09 367 96 34 GSM: 0478 44 96 04 E-mail: pie...@in... Site: http://www.insitehosting.be -----Original Message----- From: sha...@li... [mailto:sha...@li...] On Behalf Of Chad Z. Hower aka Kudzu Sent: dinsdag 28 augustus 2007 21:23 To: sha...@li... Subject: [SharpOS Developers] SharpOS vs Singularity 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? -- Chad Z. Hower aka Kudzu "Programming is an art form that fights back" http://www.KudzuWorld.com/ http://www.Woo-Hoo.net/ http://www.DelphiToDotNet.com/ ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list Sha...@li... https://lists.sourceforge.net/lists/listinfo/sharpos-developers |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 21:01:05
|
Which also brings up... Go to the home page. Search for "license". I Cant find anything... rule #1 of any open source project (Darn, cant use OS abbreviation, would be ambiguous) is to prominently display the license. -- Chad Z. Hower aka Kudzu "Programming is an art form that fights back" http://www.KudzuWorld.com/ http://www.Woo-Hoo.net/ http://www.DelphiToDotNet.com/ |
|
From: Scott B. <sb...@me...> - 2007-08-28 21:05:21
|
Chad Z. Hower aka Kudzu wrote: > Which also brings up... > > Go to the home page. Search for "license". I Cant find anything... rule #1 > of any open source project (Darn, cant use OS abbreviation, would be > ambiguous) is to prominently display the license. > Another thing that I have already discussed, but not fully / formally documented. Check the mailing list archives. The general consensus is an LGPL v2 license with commercial dual-licensing for OEM distribution, branding, etc. I can't remember specifics of it all. But I had a rather thorough debate with William about it at the time. I personally like BSD. But LGPL seemed to be okay enough. GPL is out of the question, unless we shoehorned in our own "linking exception" clause. |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 21:10:17
|
> branding, etc. I can't remember specifics of it all. But I had a rather > thorough debate with William about it at the time. I personally like > BSD. But LGPL seemed to be okay enough. GPL is out of the question, > unless we shoehorned in our own "linking exception" clause. I'm a BSD lover. That failing, MPL is basically good. GPL bad. |
|
From: Darx K. <dar...@gm...> - 2007-08-28 22:12:07
|
Hi I would opt for LGPL for the kernel, GPL for the drivers and the rest. A commercial dual-licensing should be ok too. Chriss. Chad Z. Hower aka Kudzu wrote: > Which also brings up... > > Go to the home page. Search for "license". I Cant find anything... rule #1 > of any open source project (Darn, cant use OS abbreviation, would be > ambiguous) is to prominently display the license. > > -- > Chad Z. Hower aka Kudzu > "Programming is an art form that fights back" > http://www.KudzuWorld.com/ > http://www.Woo-Hoo.net/ > http://www.DelphiToDotNet.com/ > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > SharpOS-Developers mailing list > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > > |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 22:15:38
|
> I would opt for LGPL for the kernel, GPL for the drivers and the rest. > A commercial dual-licensing should be ok too. I think this would be an appropriate time to discuss conflict resolution and how its handled on the team again. :) |
|
From: Bruce <ill...@gm...> - 2007-08-28 22:15:43
|
On 8/28/07, Darx Kies <dar...@gm...> wrote: > > Hi > > I would opt for LGPL for the kernel, GPL for the drivers and the rest. > A commercial dual-licensing should be ok too. > > Chriss. I concur with Chriss. -Bruce |
|
From: Scott B. <sb...@me...> - 2007-08-28 22:52:13
|
Darx Kies wrote: > Hi > > I would opt for LGPL for the kernel, GPL for the drivers and the rest. > A commercial dual-licensing should be ok too. > > Chriss. > > Chad Z. Hower aka Kudzu wrote: > >> Which also brings up... >> >> Go to the home page. Search for "license". I Cant find anything... rule #1 >> of any open source project (Darn, cant use OS abbreviation, would be >> ambiguous) is to prominently display the license. >> >> The operable question being what goal is the selected license covering? Or are we selecting LGPL / GPL simply because it's the most popular OSS license? I cannot agree with using GPL, again not without a linking clause. LGPL, for all intents, covers this. The "kernel", runtime, scheduler, driver framework, etc all would be LGPL, allowing for binary closed-source drivers and other apps. Again, personally I would rather go for BSD. But I can understand where people want to force things to remain open source and attributable. Thus the necessity of commercial dual-licensing. So what is GPL covering that LGPL doesn't, in terms of a microkernel architecture? |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 23:05:26
|
> The operable question being what goal is the selected license covering? > Or are we selecting LGPL / GPL simply because it's the most popular OSS > license? I cannot agree with using GPL, again not without a linking > clause. LGPL, for all intents, covers this. The "kernel", runtime, > scheduler, driver framework, etc all would be LGPL, allowing for binary > closed-source drivers and other apps. Again, personally I would rather > go for BSD. But I can understand where people want to force things to > remain open source and attributable. Thus the necessity of commercial > dual-licensing. > > So what is GPL covering that LGPL doesn't, in terms of a microkernel > architecture? +1 on all this - esp the part about GPL. |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 21:14:47
|
> Well, I've read Scott's design paper. And it has most of the elements > that I would want in a managed operating system. Here are some of the > key features I would love to see (just from the top of my head): Well thought out. Im in full agreement, but I also have some big thoughts on verifying code and security. |
|
From: Pieter M. <pie...@in...> - 2007-08-28 21:21:51
|
I agree that verifying code and security are important issues, especially because managed code opens up a lot of possibilities in these areas. But I don't see this as an elementary part of the kernel. My opinion is this could be an optional module that verifies code statically before it gets loaded / executed. It doesn't have to be tightly integrated with the kernel. There could be some security interface that a "security driver" can implement and the kernel then asks the security drivers if some operation is allowed. This gives more flexibility so we can have very thorough security with a performance overhead or a less strict security with less static checks of the code. It could of course be that I am missing something important here why verification and security should be more tightly coupled with the kernel... Insite Mees-Delbeke VOF Zomerstraat 29A 9270 Laarne Telefoon: 09 367 96 34 GSM: 0478 44 96 04 E-mail: pie...@in... Site: http://www.insitehosting.be -----Original Message----- From: sha...@li... [mailto:sha...@li...] On Behalf Of Chad Z. Hower aka Kudzu Sent: dinsdag 28 augustus 2007 23:15 To: sha...@li... Subject: Re: [SharpOS Developers] SharpOS vs Singularity > Well, I've read Scott's design paper. And it has most of the elements > that I would want in a managed operating system. Here are some of the > key features I would love to see (just from the top of my head): Well thought out. Im in full agreement, but I also have some big thoughts on verifying code and security. ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list Sha...@li... https://lists.sourceforge.net/lists/listinfo/sharpos-developers |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 21:32:39
|
> I agree that verifying code and security are important issues, > especially because managed code opens up a lot of possibilities in > these I'll post more on this later - but its essential that they are part of the kernel. > opinion is this could be an optional module that verifies code > statically before it gets loaded / executed. It doesn't have to be Layered and implementations, but certain parts should be part of the kernel. > It could of course be that I am missing something important here why > verification and security should be more tightly coupled with the > kernel... If you don't make certain parts parts of the kernel, the system can be corrupted easily. |
Thanks for helping keep SourceForge clean.
X