Re: [Challangeos-developers]New team member

[Gregor M. <Gre...@gm...>]

Fernando Fernandes Neto wrote:
> 
> I was developing the Commando OS, a multi-kernel os, and I'd like to know if
> I could team up  with you. My name is Fernando Fernandes Neto and I code in
> ASM.
> I have some concepts such as the multi kernel concept, that I can introduce
> in Challange OS.
> For example :
> The Challange OS can support it's own kernel and the Unununium kernel.
> 
> What do you think about it ???
> 

Nice idea, really. Even nicer that you already managed to actually do it
once! I like this idea and I think that we should really consider doing
it. The problem is that the kernel must actively support the module
management of ChallengeOS (this mostly concerns memory management and
scheduling). This is the reason why I reverted to writing an own kernel.
But if other kernels can do this as well, I don't see any reason why we
should not support them. And the Unununium kernel should well be able to
include the needed support.

And as I feel like experimenting today: I have been pondering about a
file system replacement. It is centered around data objects which get a
unique ID and description (only the later entered by the user). These
objects are referenced by entries in database-like tables containing
additional descriptive values on data objects (one per table). These
tables are also data objects. These tables may be created, deleted and
edited by the user(s). 

An example would be mp3 files (well, in this case file actually fits).
The description for these files could be something like artist and
title. And there could be a table containing numbers representing how
much you liked that piece on a scale - say - from 0 (worst) to 100
(best). In this table only numbers are allowed as values. And there
could be a table listing all artists, where the entries are the artists'
names (of cause!) and reference tables containing the names of the songs
(in both cases any text is allowed). Both tables refer to the exactly
the same data objects (files would only be linked to, that is). A
drawback with this is that a big number of tables will cause you loose
oversight. 

And I forgot: Tables are searchable with more flexibility than normal
file systems. If I wanted to see the songs that didn't please me much,
but not to bad, I'd search the appropriate table for songs which have a
rating of (say) 30 to 65.

Software modules, the kernel and the GPCDH would be stored in a similar
manner, but seperated from the user data tables, because an ordinary
user doesn't need access to this. But I don't want to lock it away
completely - doing so might only cause trouble. Have a look at Windows
and you'll know what happens if user cannot see what happens inside an
OS.

What do you think about these ideas? I'm pretty shure that there is a
flaw somewhere but I just don't know where... ;-)

Bye,
Gregor

-- 
*****************************************************
* Gregor Mueckl                 Gre...@gm... *
* http://challangeos.sourceforge.net                *
*                                                   *
* Math and alcohol don't mix, so please don't drink *
* and derive!                                       *
*****************************************************