Maneesh Yadav 97yadavm@scar.utoronto.ca
Fri, 28 May 1999 15:37:53 -0400 (EDT)

Tom, I hope this shows you that you have a ways to go before anything
useful can come of retro, let alone using as the lower part of the
ambitious tunes project.  You may think that things in computer world are
terrible and bloated, but by the time you get all the nessecary features
you won't make anything that's much better in terms of size or
eficiency and robustness, compared to say linux or an available embedded
OS.  If you're just doing for learning, that's great; but Tril keeps
saying that this is goig to be used as a lower layer, and I believe his
plans were to initially develop TUNES over Retro.  Why?  You'll never get
to all the features you need, and the thing is that they are already
available; why hinder the development effort by using a prototype OS that
doesn't (and no offense tcn, but I will put money on the bet that they
never will) impliment features expected of computing and having to deal
with th associated problems of developing on an experimental OS.  The time
invovled in development is really impossible, I assure you.  So Tril,

Kindly explain why you want to initially develop your type system, and
Fare's scheme over Retro <well that's directed to Fare>?

On Fri, 28 May 1999, Tom Novelli wrote:

> On Fri, May 28, 1999 at 02:08:26AM -0400, Maneesh Yadav wrote:
> > THis is by no means an apology for my recent posts, but I would like to
> > say that I hope I am not offending anybody, I am really just trying to
> > kick some reality into some empty promises and possibly educate some
> > people who, IMHO really haven't had any experience with and sort of real
> > code development, let alone a project such abmition.  The differences in
> > opinions are clear, some are saying that all the projects will eventually
> > become integrated, other are saying TUNES is a discussion form etc...I am
> > usually not one for strict definition in these things, but to really call
> > yourselves a group and have goals like the ones posted on the web page and
> > have n different projects and say that they will magically someday be
> > integrated into one another all the while solving all the problems of
> > software design in some finite amount of time is just plain lying.
> Thanks for your realism, but your negativity isn't getting us anywhere. 
> Luckily it's falling on deaf ears.  Anyway, for those who aren't experienced
> in software development, this is a good opportunity for them to learn.  So
> what if there are a few different "factions" within Tunes?  Eventually
> they'll either merge together or split off.  Yeah, we'll never solve all the
> world's problems but at least we're trying!
> > I'm going to post a series of questions one the various project out again
> > and I think for the sake
> > of the group having an idea what is going on they should be answered,
> > please no editorials jus simple short answers.
> Allright, sounds good.  I'm sure it'll raise a few points I've overlooked.
> > First of all, part of the TUNES project seems to be developing a
> > microkernel in assembler (I'm looking at tcn).
> >
> > Ok,
> > What advantages are there to using this kerenel than to use an existing
> > one?
> If you're referring to Linux or *BSD, those come with too much Unix
> baggage.  When you start from scratch, you're free to try different ideas.
> Keep *my* goal in mind: I just want a simple, fast, useful computer system. 
> I don't need any fancy new ideas for that, I just need to keep it simple and
> use common sense.  I may reinvent the wheel, or I may invent something new
> without realizing it... I don't really care, as long as I reach my goal.
> For me, Tunes is a further goal, something to work toward even after I've
> reached my first goal.
> > What language are you writing it in (assembler last I checked), how do you
> > expect to port efficently?
> The core is in assembler... porting it won't be that difficult.  Hardware
> drivers are usually written in assembly too (for efficiency and control),
> but other platforms have different hardware.  Also, I expect the assembler
> code to shrink as the OS becomes high-level.  Much of the porting time will
> involve writing a code generator for the new platform.  Another thing to
> ease porting: translate the assembler code to high-level code (or pseudocode).
> > WHat is you basic multitasking mechanisms (what data structures are
> > involved, hardware/software,  priorities, timesclicing etc.)?
> Currently, it's just a circular list of tasks, switching at fixed intervals. 
> I plan to use a better structure at some point, probably a priority heap. 
> Variable intervals are another possibility.  But these things can be easily
> changed; they aren't tied to the rest of the OS.
> > What does a task memory map look like (or the basic memory scheme in
> > general, what parts of mem are shared, selectors, page granularity etc.?
> I'm not nearly done with the Persistent Store, which will manage all forms
> of storage.  Right now I can tell you I'm using paging on the 80x86, not
> segments.  Most architectures support paging, but not segmentation. 
> Besides, I took a good look at the 80x86 segmentation mechanism, and it
> didn't look very useful.
> > What does you basic IPC mechanism look like (message, sizes, mechanisms of
> > transport, do they suppourt multiprocessing)?
> I haven't implemented anything like that.  I have distributed computing in
> mind, though.  Do you use registers, shared memory, networking..?  It
> depends how much data there is and where it's going.  That's the kind of
> stuff that should be handled by a high-level OS/language.
> > How is shared video impliemnted?
> You mean windows?  Well, each task has a video buffer (or several)
> associated with it.  These buffers can be full-screen or windowed, text or
> graphics.  (At least, that's the plan)
> > How are device drivers implimented (accesed through call gates, shared
> > code etc.)?
> Both.. shared code and call gates.  Gates are only for calling supervisor
> code from user mode programs, of course... I haven't done that yet.
> > Does you taking model, memory management and IPC allow for
> > multiprocessing?  What about distributed computing (what consitency, fault
> > tolerant mechanisms have you used?)?
> Yes, but I haven't gotten that far.  I need to set up a LAN or a simulated
> distributed system, to experiment with.  The only fault-tolerance mechanism
> I've worked out so far is redundancy.  I still have lots of research to do
> in this area.
> > What about the filesystem?  Is it tied to the device interface, is it
> > "pluaggable" (ala linux VFAT)?
> Oh, persistent storage... it treats all storage devices uniformly (although
> optimizations for disks, etc, could be added).
> The Persistent Store has close ties with objects and languages... actually,
> it's the most important part of the OS... it manages damn near everything. 
> Already, it does a lot of the work traditionally done by a language.
> -- 
> Tom Novelli <tcn@tunes.org>