I humbly propose that we should set a deadline for Tunes

[Maneesh Yadav]

A proposed plan and some comments of the current state of the Tunes project:

Main Problem:
There hasn't been anything "real" producded yet.  (Anyone seen that Kids In The
Hall skit, where they are members of an awful sounding garage band, they go (I
think by time machine or heaven or something) into the future and their guide
tells them how they grow old and stay the pathetic losers that they are, but
they keep asking "Did we ever make it?")

Comments:

It's very difficult to do something, especially a complex computer system,
without a clear plan and a lot of discussion to show for it.  Yes there probably
has been a lot of useless blabber, but I think doing something of such magnitude
in your spare time will produce blabber.  People have often complained  in this
list that no actual coding is being done; we must work out the theory behind the
system first, to the extent of writing a textbook (with refrences if there are
any poorly known basis of argument) like description that will give anyone who
reads it a clear understanding of the goals of the project.  Once we get to that
point, the implementation is actually easy, yes, easy.  At first I wrote up a
small 386 based microkernel (still have it) and was thinking about all sorts of
technical aspects, and I realize that was the wrong approach but I kept gettting
frustrated when it came to defining the way I wanted "objects" to look in the
system, I didn't want to make a microkernel that was like any other and just
hook Tunes to it's system, it had to work in an elegant object manner from the
ground; but without a clear definition of what I wanted, I couldn't get past
basic resource allocation routines and the like.  How we impliment our
theortical system on a number of different platforms, is DETAILS, we needn't
worry about them yet.

  Also, we shouldn't rush to produce examples of our ideas (my microkernel for
instance), it's better to come up with some well written-well defined paper that
describes it.  In my case I should've written up all the system calls (in a
detailed manner like what params they take) and described the main features of
the kernel (exactly what paging algorithm is used, the task switching mechanism,
memory maps etc.)  in such a manner that if someone did have to impliment it and
knew nothing about it prior, they could do it with ease just by reading the
paper.  Writing up your ideas in detail is generally a more useful thing than
practical code, you spend more time communicating the idea (instead of
implementing it)  and can lead to it's improvement, once you are truly happy
with the idea, you can start implementing it, which by this time is quite easy.
That's what I dislike about the current way we have Tunes setup (at least on the
webpage) splitting up the projects when we don't have a freaking clue as to what
this beast is, doesn't make much sense.

What I propose should be done:

There should be 3 mailing lists a 'baked' one and a 'half baked one', the baked
one will be moderated in a sense, that only full, clear presentations of
concepts should be presented (split up essays result in discontinuity and
seraching through old email, put all the info of your idea in one place).  The
half baked list should be for discussing of new ideas, which I think we are
past, we need more 'baked' goods so that everyone can understand them and can
lead to implementation; but at the same time, stiffling creativity is the last
thing that we want to do.  The third should be used for discussing ideas from
the baked list.

We should SET A DEADLINE.  I propose that by July 1 we seriously re-evaluate the
Tunes project.  If there haven't been enough items in the baked goods
department, unless someone can think of a really, really good reason why, the
project should be stopped; in the sense that we should no longer claim to the
world that we are re-inventing computing, we should state what we really are: a
good discussion group, and if people want to keep discussing, let them.  One the
other hand if we do see enough progress (we are all collectivley deciding of
course, if there are splits in the group opinion we'll figure it out when that
happens).  I hear you say "July 1? That's way too early!", well I realize that
we are all busy people either in school or at work, but if we can't come up with
some good indication of direction by July 1 on the excuse that we are too busy,
we will never get anywhere.  It takes time to do this stuff, time away from
studying, family and life in general; this is a decision you must make if we
want to produce something truly magnificient.  By July first, that'll give us
plenty of time to develop ideas, and a bit of the summer for us students, by
then which we should have some direction.

So here are some ideas that we need to concreteize:

Brian's Arrow System
Jim Little's Prism System

Tril or Fare-Here is something I think would be helpful- a short little paper
that describes terms that we commonly use, I realize that the page has these
definitions but I think they can be improved, with code snippets (which can
really help illustrate points, you often dont need to know a language to
understand a snippet)) that illustrate the ideas (relfectivity for instance).  I
will be more than willing to help out on this, but I think you guys have a
better hold on the terms than me.

Conclusion
The Tunes mailing list has been discussing for a while now, and we have enough
new ideas, but we have trouble communicating them, which prevents a clear vision
of our goal, and prevents implimentation.  I formally request that we should set
a deadline for July 1, at which point the descision by the group should be
collectivley decided as to wether it's a tme-worthy cause to continue the
project or that we should let it die gracefully.

Again don't mean to sound like the big boss, I am of course not, but I think the
previous had to be said.