In article <dii9pm$l85$1@digitaldaemon.com>, Niko Korhonen says...
>
>pragma wrote:
>> Janus - god of doorways, beginnings and endings
>
>That's slightly too Javaish because it starts with a J. For some reason the Java people have a strong compulsion to name all their software J-something. I don't know if it's a part of Sun's Java EULA or something ('§8.7 The party hereby referred to as You must name all digital intellectual property hereby referred to as Software You create with the digital intellectual property copyrighted by Sun Microsystems hereby referred to as Java Software J-Something').
>
>> Athena - godess of war and so the female counterpart to Ares/Mars (only with a more scrupulous reputation)
>
>Now that would be insanely cool! With a nice reference to Digital Mars too :)
>
>-- 
>Niko Korhonen
>SW Developer


Yes, but.. AthenaOS is already taken.. :)

http://savannah.nongnu.org/projects/athena/

Thanks,
Trevor Parscal

In article <dihjg2$4pc$1@digitaldaemon.com>, Carotinho says...
>
>Trevor Parscal wrote:
>
>> An Operating System In D...
>> 
>> I have extreme ambition, tons of ideas, programming skills, and enough time to make a consistent effort. Perhaps I could get some help from some of you guys, and get a proof of concept together... Like pragma said... And yes, I have seen, and played with the beginings of a kernel in D that are posted on that wiki, and they should help us to get something together as well.
>> 
>> Idea...
>> A kernel
>> - execute several different kinds of compiled code (DDL seems to help
>> here) - has garbage collection (D's GC should work)
>> - perhaps an exokernel design (http://pdos.csail.mit.edu/exo.html)
>> 
>> Name...
>> Honestly, as long as it's not an achronym, I am all for it... So, name
>> ideas anyone?
>
>I'd put the garbage collector in the kernel, and if you want some memory, you have to ask him the permission! So there is one big gc for everyone. No ideas about shared libs etc. though...
>
>Carotinho

Didn't anybody *read* the exokernel ideas?  GC can go in a library above exokernel and apps can use it if they like, or not.

Regards,
James Dunne

In article <dike13$b70$1@digitaldaemon.com>, James Dunne says...
>
>In article <dihjg2$4pc$1@digitaldaemon.com>, Carotinho says...
>>
>>Trevor Parscal wrote:
>>
>>> An Operating System In D...
>>> 
>>> I have extreme ambition, tons of ideas, programming skills, and enough time to make a consistent effort. Perhaps I could get some help from some of you guys, and get a proof of concept together... Like pragma said... And yes, I have seen, and played with the beginings of a kernel in D that are posted on that wiki, and they should help us to get something together as well.
>>> 
>>> Idea...
>>> A kernel
>>> - execute several different kinds of compiled code (DDL seems to help
>>> here) - has garbage collection (D's GC should work)
>>> - perhaps an exokernel design (http://pdos.csail.mit.edu/exo.html)
>>> 
>>> Name...
>>> Honestly, as long as it's not an achronym, I am all for it... So, name
>>> ideas anyone?
>>
>>I'd put the garbage collector in the kernel, and if you want some memory, you have to ask him the permission! So there is one big gc for everyone. No ideas about shared libs etc. though...
>>
>>Carotinho
>
>Didn't anybody *read* the exokernel ideas?  GC can go in a library above exokernel and apps can use it if they like, or not.
>
>Regards,
>James Dunne

Thats true... Well, the thing is, you could do it either way... So, I guess you would have to decide how you wanted to do it...

Thanks,
Trevor Parscal

In article <dike13$b70$1@digitaldaemon.com>, James Dunne says...
>
>Didn't anybody *read* the exokernel ideas?  GC can go in a library above exokernel and apps can use it if they like, or not.

I went through the slide presentation.  Pretty impressive stuff--I'm interested to hear how things go with their upcoming testing.  Overall, I very much like the idea of a heavily modular OS, which exokernel seems to support quite well.


Sean

James Dunne wrote:
> In article <dihjg2$4pc$1@digitaldaemon.com>, Carotinho says...
>>I'd put the garbage collector in the kernel, and if you want some memory,
>>you have to ask him the permission! So there is one big gc for everyone. No
>>ideas about shared libs etc. though...
> 
> Didn't anybody *read* the exokernel ideas?  GC can go in a library above
> exokernel and apps can use it if they like, or not.

I say put the GC in a library (or actually multiple libraries, read on) for two reasons. One, allow programs to forego GC and use malloc()/free() if they so choose.  Although in this case the kernel should probably still have some way of keeping a really close eye on things.  Two, allow programs to select from a small collection of GC's of differing styles.  Useful for people who, for example, really prefer a copying GC for their program (or whatever variety).

Maybe instead of literally leaving out GC, malloc()/free() programs could be assigned to a special GC library that just implements those two traditional memory functions and some mechanism to keep on eye on the program, to make sure it doesn't step out of bounds, to be sure its memory doesn't leak on termination, for example.

-- Chris Sauls

In article <dikv03$1m7t$1@digitaldaemon.com>, Chris Sauls says...
>
>James Dunne wrote:
>> In article <dihjg2$4pc$1@digitaldaemon.com>, Carotinho says...
>>>I'd put the garbage collector in the kernel, and if you want some memory, you have to ask him the permission! So there is one big gc for everyone. No ideas about shared libs etc. though...
>> 
>> Didn't anybody *read* the exokernel ideas?  GC can go in a library above exokernel and apps can use it if they like, or not.
>
>I say put the GC in a library (or actually multiple libraries, read on) for two reasons. One, allow programs to forego GC and use malloc()/free() if they so choose.  Although in this case the kernel should probably still have some way of keeping a really close eye on things.  Two, allow programs to select from a small collection of GC's of differing styles.  Useful for people who, for example, really prefer a copying GC for their program (or whatever variety).
>
>Maybe instead of literally leaving out GC, malloc()/free() programs could be assigned to a special GC library that just implements those two traditional memory functions and some mechanism to keep on eye on the program, to make sure it doesn't step out of bounds, to be sure its memory doesn't leak on termination, for example.
>
>-- Chris Sauls


Very good ideas.. I agree that there should be choice in which type of GC, and also if you prefer not to use it at all.. And thats the great thing about an exokernel, the ability to put it all in a library...

Titan should be modular...

Thanks,
Trevor Parscal