October 13, 2005
"Trevor Parscal" <Trevor_member@pathlink.com> wrote in message news:dimanu$2is7$1@digitaldaemon.com...
> In article <dim8c4$2ge7$1@digitaldaemon.com>, James Dunne says...
>>
>>pragma wrote:
>>> In article <diktru$1kpn$1@digitaldaemon.com>, Kyle Furlong says...
>>>
>>>>Kyle Furlong wrote:
>>>>
>>>>>Trevor Parscal wrote:
>>>>>
>>>>>
>>>>>>So, I am starting this project.. Titan... Its a kernel in D.. I hope
>>>>>>it to be
>>>>>>very high performance, with garbage collection, and be able to execute
>>>>>>several
>>>>>>common executable formats.
>>>>>>
>>>>>>If you are interested in helping, let me know... I put in a request
>>>>>>for a
>>>>>>dsource project page..
>>>>>>
>>>>>>I look forward to working with some others on this.. Its a bit large
>>>>>>for me to
>>>>>>do alone...
>>>>>>
>>>>>>Thanks,
>>>>>>Trevor Parscal
>>>>>>trevorparscal@hotmail.com
>>>>>
>>>>>
>>>>>Sounds exciting, I would like to help.
>>>>
>>>>Take a look: http://unununium.org/
>>>>
>>>>Maybe some ideas from this project could affect the architecture of Titan. Particularly interesting to me was the idea of orthogonal persistence.
>>>
>>>
>>> *Especially* the bit about orthogonal persistence.  Even if not
>>> implemented in
>>> the way the '111' guys suggest, its a powerful concept.
>>>
>>> From the abstract, I gather that would mean that 'on-disk' and
>>> 'in-memory'
>>> becomes almost totally transparent, with the OS performing any needed
>>> translation between mediums.  Barring concerns of most forms of
>>> direct-serialization being largely non-portable mediums for binary
>>> storage, it
>>> sounds like a winner.
>>>
>>> Trevor, any concepts for characterizing Titan outside of using exokernels?
>>>
>>> - EricAnderton at yahoo
>>
>>Concerns about serializing objects to memory/disk in relation to endianness issues is no worse than how it is now, without orthogonal persistence.  Serialization of objects over the network can easily be accomplished with automatic-endian-converting stream classes for transferring data between different endian'd machines.  I don't think this is a problem when switching the clear memory vs. disk barrier to a transparent combined storage medium.
>>
>>In fact, that is a cool concept!  A disk devoted entirely to storage... makes me want to write up a revision logging library for disk storage. Think how cool that would be - the entire OS has revision capabilities on everything storable.  "Application deployment and updatings/versionings have never been easier!"
>>
>>The only barrier here is how far you're willing to take this concept. i.e. completely do away with specialized file formats?  or provide backward compatibility with said formats?  In an exokernel design, one could write thousands of libraries to handle each individual file format (much like it is now with linux libraries...there's a libSomething for most every type of widely-used standard file format; mp3, xml, mpg, avi, etc.).
>>
>>Anyways... what is the scope of your operating system, Trevor?  Do you wish to completely revolutionize computing and do away with unnecessary (or maybe necessary) evils of the "old way"?  Personally, I wouldn't like to move to a new OS and not be able to play my MP3s ;).
>>
>>Once you get the exokernel up, I'd love to take a swing at developing some OS libraries.
>
> I think that Titan should indeed do away with the "old" way of doing
> things..
> But, I think also that playing MP3's is going to be easier on Titan, not
> impossible, due to its design.
>
> I think format handlers has long been the domain of the App.. Moving that
> to an
> OSlib is quite an idea.. Such as, there would be a common way to get meta
> information about a file. This can include ID3 tags, but to me, this is
> more
> allong the lines of versioning and such as well.
>
> YES, we should design a file system that can do versioning natively, meta
> information seamlessly, and be immune to interal and external
> fragmentation
> (Journaling Files Systems) ...
>
> I want to also make the way you access files on disks the same as the way
> you
> access network resources, so this meta information needs to be flexible
> enough
> to carry HTTP headers for instance.
Hmm... as long as you can point out to the program that it's a *network* resource, I figure (for what it's worth) that it would be pretty useful.
>
> Good ideas... And yes, I would love your help.
>
> Thanks,
> Trevor Parscal


October 13, 2005
Trevor Parscal wrote:
> So, I am starting this project.. Titan... Its a kernel in D.. I hope it to be
> very high performance, with garbage collection, and be able to execute several
> common executable formats.
> 
> If you are interested in helping, let me know... I put in a request for a
> dsource project page..
> 
> I look forward to working with some others on this.. Its a bit large for me to
> do alone...
> 
> Thanks,
> Trevor Parscal
> trevorparscal@hotmail.com

Hope you realize what you are getting yourself into. Goodluck.

Here's an article that may be useful:
http://www.osnews.com/story.php?news_id=1482
October 14, 2005
Recommend you also take a look at the l4 microkernel.

http://l4ka.org/

Matthias

Trevor Parscal wrote:
> So, I am starting this project.. Titan... Its a kernel in D.. I hope it to be
> very high performance, with garbage collection, and be able to execute several
> common executable formats.
> 
> If you are interested in helping, let me know... I put in a request for a
> dsource project page..
> 
> I look forward to working with some others on this.. Its a bit large for me to
> do alone...
> 
> Thanks,
> Trevor Parscal
> trevorparscal@hotmail.com
October 14, 2005
In article <dimit2$30bq$1@digitaldaemon.com>, clayasaurus says... *snip*
>Hope you realize what you are getting yourself into. Goodluck.
*snip*

Yeah, really.. Its a really big undertaking - that is for sure... I just hope I can get something to boot, and we can go from there :)

BTW, Titan is on DSource now... Feel free to continue discussion there..

http://www.dsource.org/forums/viewtopic.php?t=1034

Thanks,
Trevor Parscal
October 14, 2005
Trevor Parscal wrote:
> In article <dim7gl$2fj0$1@digitaldaemon.com>, pragma says...
> 
>>In article <diktru$1kpn$1@digitaldaemon.com>, Kyle Furlong says...
>>
>>>Kyle Furlong wrote:
>>>
>>>>Trevor Parscal wrote:
>>>>
>>>>
>>>>>So, I am starting this project.. Titan... Its a kernel in D.. I hope it to be
>>>>>very high performance, with garbage collection, and be able to execute several
>>>>>common executable formats.
>>>>>
>>>>>If you are interested in helping, let me know... I put in a request for a
>>>>>dsource project page..
>>>>>
>>>>>I look forward to working with some others on this.. Its a bit large for me to
>>>>>do alone...
>>>>>
>>>>>Thanks,
>>>>>Trevor Parscal
>>>>>trevorparscal@hotmail.com
>>>>
>>>>
>>>>Sounds exciting, I would like to help.
>>>
>>>Take a look: http://unununium.org/
>>>
>>>Maybe some ideas from this project could affect the architecture of Titan. Particularly interesting to me was the idea of orthogonal persistence.
>>
>>*Especially* the bit about orthogonal persistence.  Even if not implemented in
>>the way the '111' guys suggest, its a powerful concept.
>>
> 
>>From the abstract, I gather that would mean that 'on-disk' and 'in-memory'
> 
>>becomes almost totally transparent, with the OS performing any needed
>>translation between mediums.  Barring concerns of most forms of
>>direct-serialization being largely non-portable mediums for binary storage, it
>>sounds like a winner.
>>
>>Trevor, any concepts for characterizing Titan outside of using exokernels?
>>
>>- EricAnderton at yahoo
> 
> 
> I am still working on the concpet, of course, but I would say that I am not
> trying to just leave it at exokernel, and stop designing.. I just think that an
> exokernel design pretty much gives use the modularity we would need to get
> things done like garbage collection libraries, multi-format execution very
> easily..
> 
> Some of the latest ideas include...
> 
> - Exokernel Design (multiple OS layers can run simultaniously)
> - MultiFormat Execution (OMF, ELF, COFF, PE, etc..)
> - Garbage Collection (libraries accessable to apps in different flavors)
> - Trasparent Memory (the the app, memory is memory, no matter where it's at)
> - Transparent Data (to an app, a network path or local drive path act the same)
> - Modern Hardware Only (don't waste time supporting ainchient machines)
> 
> I am working together a presentation of sorts to outline these concepts, but, I
> am still researching them, so it's not quite done...
> 
> Any ideas are very much welcome, and all offers to help are being added to a
> list, you will not be forgotten...
> 
> Thanks,
> Trevor Parscal

On the matter of combining network paths with local drive paths...

Are you thinking of using URIs and using resource indicators like http://, fish://, file://, smb://, etc?  Reminiscient of KDE.  Yes, it is a good idea to write a set of stream handlers to handle all different types/sources of streams.  However, build in a VERY ROBUST system which can gracefully handle connection failures.  Don't simply assume the resource is existing.

I also really think file extensions should be done away with.  File types should be meta information with the option of backward compatible meta tags which contain the file extension (if moved over from 'old-style' file system).  Also, a database of existing and commonly supported file extensions should contain maps to the new meta information format.

Also, I think an important concept is to allow the USER to get the most work done (on a desktop system).  Don't let the process scheduler give higher priority to non-user tasks.  The UI should be fast, responsive, and should NOT lag behind the user.
October 14, 2005
Trevor Parscal wrote:
> So, I am starting this project.. Titan... Its a kernel in D.. I hope it to be
> very high performance, with garbage collection, and be able to execute several
> common executable formats.
> 
> If you are interested in helping, let me know... I put in a request for a
> dsource project page..
> 
> I look forward to working with some others on this.. Its a bit large for me to
> do alone...
> 
> Thanks,
> Trevor Parscal
> trevorparscal@hotmail.com

I may have mentioned this before: it's worth taking a look at the Xen project - they have a thin layer that sits under virtualised operating systems (you have to modify the system to coexist with Xen). All actual operating systems sit abopve this layer, and some can have privileged access to others, while others get mediated virtual access.

Xen is at http://www.cl.cam.ac.uk/Research/SRG/netos/xen/

The effect is that you can have a reasonable development environment, get your OS working at the virtual interface, and then go to the bare metal when you're ready to spend 200 years writing device drivers.

And of course, you'll need a language machine- new release 0.2.0, new examples, surprising letter to Jonathan Swift (the original inventor of generative grammatical engines?) etc. :)

Good luck
Peri

-- 
http://languagemachine.sourceforge.net - The language machine
October 14, 2005
Trevor Parscal wrote:
> So, I am starting this project.. Titan... Its a kernel in D.. I hope it to be
> very high performance, with garbage collection, and be able to execute several
> common executable formats.
> 
> If you are interested in helping, let me know... I put in a request for a
> dsource project page..
> 
> I look forward to working with some others on this.. Its a bit large for me to
> do alone...
> 
> Thanks,
> Trevor Parscal
> trevorparscal@hotmail.com

Sorry - typo in previous message - should have read: ... some (virtualised operating systems) can get privileged access to hardware, while others get virtualised access.

-- 
http://languagemachine.sourceforge.net - The language machine
October 15, 2005
In article <diorv7$dtj$1@digitaldaemon.com>, James Dunne says... *snip*
>Are you thinking of using URIs and using resource indicators like http://, fish://, file://, smb://, etc?  Reminiscient of KDE.  Yes, it is a good idea to write a set of stream handlers to handle all different types/sources of streams.  However, build in a VERY ROBUST system which can gracefully handle connection failures.  Don't simply assume the resource is existing.
*snip*

I completely agree - you are very right - I like your thinking... I believe that abstractions all too often become synonomous with NOT ROBUST... which is sad.

*snip*
>I also really think file extensions should be done away with.  File types should be meta information with the option of backward compatible meta tags which contain the file extension (if moved over from 'old-style' file system).  Also, a database of existing and commonly supported file extensions should contain maps to the new meta information format.
*snip*

I totally agree. The file system we use should have a very flexible meta-data system for files, so that we can store the file format information in there.

>Also, I think an important concept is to allow the USER to get the most work done (on a desktop system).  Don't let the process scheduler give higher priority to non-user tasks.  The UI should be fast, responsive, and should NOT lag behind the user.

I totally agree - again. I think the kernel should be designed to be a User OS kernel, but, I am open to the idea, and hope to eventually do something meaningful with, a Server OS on the kernel too...

Priorities for processing is something that should be really flexible with the kernel..

I am writing some basic source code as we speak... I look forward to input on what I put together...

Your ideas are most helpfull - as there is sooo much to think about...

Thanks,
Trevor Parscal
1 2
Next ›   Last »