You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(29) |
Aug
(214) |
Sep
(148) |
Oct
(7) |
Nov
(117) |
Dec
(220) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(202) |
Feb
(96) |
Mar
(106) |
Apr
(90) |
May
(10) |
Jun
(13) |
Jul
(99) |
Aug
(76) |
Sep
(17) |
Oct
(6) |
Nov
|
Dec
(1) |
2009 |
Jan
(1) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2011 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 21:40:27
|
> Austria. :) So far Europe is tipping the scales. :) |
From: Darx K. <dar...@gm...> - 2007-08-28 21:35:20
|
Hi. Chad Z. Hower aka Kudzu wrote: > Also again. :) > > Could everyone enumerate where they are located? :) > > Austria. :) Chriss. |
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. |
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: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: 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: 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: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: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 20:59:15
|
> The biggest thing is whether William and Chriss would agree to stop > kernel and compiler development until we have a chance to look back > over > the architecture, agree and document said new architecture, and look > back over existing code to massage it accordingly. Considering there are only 6 of us, if they don't, sounds like the other 4 might be interested in forking. :) |
From: Scott B. <sb...@me...> - 2007-08-28 20:56:15
|
Chad Z. Hower aka Kudzu wrote: >> Someone will probably say this already exists. I don't know. My major >> recommendation right now is establishment of a build master, who owns >> > > Where is it documented? :) What is the process of conflict resolution? I > don't just mean build team vs doc team type things. > > >> check, and the build master normalizes the code to a coding standard >> before committing it to the trunk. Trying to get rid of William >> > > We can use code formatters for such items in many places. > > >> I've been kicking for this for awhile. Currently it's more a code- >> write-architecture-later. The largest part of the system, the compiler, >> is AOT-only, and only one person knows its architecture. I've been very >> vocal about that. Don't know if Chriss has gotten anywhere with >> documenting the architecture. >> > > The problem is that docs get too far behind too quickly and people forget > why/what. I can take a stab at this - but it will also force a lot of review > IMO of architecture and I wont be hesitant to bring issues up and push for > change when needed, especially in core. We HAVE to get core RIGHT. > > >> Already exists, for both VMWare and Bochs >> > > Ok, then change Item 3 to - Make a new, better, easier to understand > website. I can do that too, if you don't care what tool I use. That failing > I can make a fork with my own info. :) > > Definitely not disagreeing with any of the above. I'm taking all next week off for a vacation, so I have the time to do this. But within all the flurry of email, we haven't heard from William or Chriss, who so far are the two main devs of the existing codebase. There's been a general consensus of "what we have already works", even if it isn't formalized or documented, which makes the "professional software engineer" side of me grumble. The biggest thing is whether William and Chriss would agree to stop kernel and compiler development until we have a chance to look back over the architecture, agree and document said new architecture, and look back over existing code to massage it accordingly. |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 20:52:31
|
> http://members.simunex.com/sbalmos/CosmOS.pdf (heh, notice I fell into Thanks. Saved for a future plane ride (I have 15 or so long hauls to Asia, back and forth in Sept) > By my count, I think 6 including you? There is no current team Which to me is all the more reason we need to establish some sort of structure now before it grows to big. |
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: Pieter M. <pie...@in...> - 2007-08-28 20:51:00
|
Oops, I seem to have a typo in my previous message: I was UNable to test it ;) 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 22:49 To: sha...@li... Subject: Re: [SharpOS Developers] SharpOS name > I did find another project here https://gna.org/projects/mos. I have > been able to test it, but it seems to target embedded applications. > Unfortunately development seems to have halted. For nearly 20 years Ive been interested in a truly layered system that can be small, or be big. Id like to see that and that's why I started asking about layering. ------------------------------------------------------------------------ - 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 20:49:57
|
> That'd be all well and good. But you would be tainted then, exposing > project to liability. At least Rotor has, as far as I have always > understood it, a license that basically says "you can use whatever you Will be interesting to see if the open Singularity more in the future and on what terms. |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 20:49:27
|
> I did find another project here https://gna.org/projects/mos. I have > been able to test it, but it seems to target embedded applications. > Unfortunately development seems to have halted. For nearly 20 years Ive been interested in a truly layered system that can be small, or be big. Id like to see that and that's why I started asking about layering. |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 20:47:59
|
> Someone will probably say this already exists. I don't know. My major > recommendation right now is establishment of a build master, who owns Where is it documented? :) What is the process of conflict resolution? I don't just mean build team vs doc team type things. > check, and the build master normalizes the code to a coding standard > before committing it to the trunk. Trying to get rid of William We can use code formatters for such items in many places. > I've been kicking for this for awhile. Currently it's more a code- > write-architecture-later. The largest part of the system, the compiler, > is AOT-only, and only one person knows its architecture. I've been very > vocal about that. Don't know if Chriss has gotten anywhere with > documenting the architecture. The problem is that docs get too far behind too quickly and people forget why/what. I can take a stab at this - but it will also force a lot of review IMO of architecture and I wont be hesitant to bring issues up and push for change when needed, especially in core. We HAVE to get core RIGHT. > Already exists, for both VMWare and Bochs Ok, then change Item 3 to - Make a new, better, easier to understand website. I can do that too, if you don't care what tool I use. That failing I can make a fork with my own info. :) |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 20:42:06
|
> and I written two books for writing OS=A0using C(you can see the > information for this book in here my blog : > http://wonbear.egloos.com/3181423, http://wonbear.egloos.com/3266598) Your experience is very welcome. Unfortunately I wont be able to read = your book as its in some language I cant read. :) |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 20:40:26
|
> Huh... What everyone seems to forget speaking about Singularity and > such is OS'es that Singularity borrows lots of ideas from. It's Oberon To me one of the major keys of this is that it uses .NET, which is language agnostic and will allow the OS to reuse tons of code once its going. That's something only the Java ones could say, and they will have problems in that very little desktop software is in Java, in addition to performance and other issues. |
From: Scott B. <sb...@me...> - 2007-08-28 20:39:53
|
Chad Z. Hower aka Kudzu wrote: > I'd like to make a few proposals. > > 1) We establish a loose but workable team structure which includes conflict > resolution. > > Someone will probably say this already exists. I don't know. My major recommendation right now is establishment of a build master, who owns the trunk. All changes should be done in local repos. When something should be promoted to the trunk, it is debated here, goes through a code check, and the build master normalizes the code to a coding standard before committing it to the trunk. Trying to get rid of William breaking the kernel again (heh), or our infamous problems of things compiling under Mono but not VStudio or vice versa. Between that, and API / architecture docs before you start coding a major piece. Everyone else can tell you how much I've grumbled lately about not being able to get my VM code going because the trunk repo got reworked, the base kernel's in flux, and the AOT is still buggy. :) > 2) We establish a highly documented, well debated kernel design doc. Then > proceed to make the kernel rock solid before putting too much effort into > anything beyond the command line. > > I've been kicking for this for awhile. Currently it's more a code-first, write-architecture-later. The largest part of the system, the compiler, is AOT-only, and only one person knows its architecture. I've been very vocal about that. Don't know if Chriss has gotten anywhere with documenting the architecture. Personally, I would halt all current kernel-related development, go back and tear back apart the compiler and get that completely rearchitected, redocumented, and retested. Start with reading in the source bytecode at a method level from multiple sources, whether it's a byte stream, file, whatever. This ensures an easy separation of code into an embeddable JIT engine, with the AOT system simply being a file-feeder shell. Convert to unoptimized IR code, then register transfer code. Spit out direct, unoptimized machine code from there. Possibly hand-verify if necessary the generated machine code. That way we know the basic compiler works and implements all CIL opcodes. Optimizations such as SSA, dead code elimination, loop unwinding, etc can all be implemented as transforms on top of the base IR code stream. From the testing I've seen, I can't tell whether bugs are in simple bytecode conversion or various IR optimization algorithms. They all seem to be intertwined currently. But I'm liable to get my head chopped off by Chriss for the above. :) > 3) We establish a build process to produce ready to go VMWare images as well > as easier to build source scripts. > Already exists, for both VMWare and Bochs |
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 20:24:56
|
I'd like to make a few proposals. 1) We establish a loose but workable team structure which includes conflict resolution. 2) We establish a highly documented, well debated kernel design doc. Then proceed to make the kernel rock solid before putting too much effort into anything beyond the command line. 3) We establish a build process to produce ready to go VMWare images as well as easier to build source scripts. -- 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: 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: Roman I K. <ro...@kh...> - 2007-08-28 20:21:38
|
JaeHyun Roh: > this is not a CLR based operating system, but I think it's good to > mention it. > > http://sourceforge.net/projects/squeaknos/ > > squeaknos(Squeak No Operating System). in this project, they are trying > to implement OS using only SmallTalk. :) Huh... What everyone seems to forget speaking about Singularity and such is= =20 OS'es that Singularity borrows lots of ideas from. It's Oberon and its=20 successor Bluebottle, that are made way cleaner and leaner then Singularity= =20 itself (forgive it for that, it has to live with all CLR nonse^W stuff)... http://bluebottle.ethz.ch/ =2D-=20 Roman http://roman.khimov.ru .o. mailto: ro...@kh... ..o gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3 ooo |
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 19:25:54
|
> No, I'm afraid not. The last one I attended was the Business Innovation > Event in Brussels at the end of last year. Our main business is hosting > based on the Microsoft platform. So we only attend the major launches The DevDays is MS's biggest dev event by far.... This year I did tech sessions as usual but also did the closing session. Your name is still oddly familiar... I cant remember where I know it from. |
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/ |