March work

Adam Martin adam at fsl.cs.sunysb.edu
Mon Oct 3 03:35:16 EDT 2005


On 2005 Oct 02 , at 22:41, Justin Hibbits wrote:

> Adam,
>
> We have 2 choices for proceding with Gold:
>
> 1) Go back to what we decided in March.  This means we use files and 
> forks,
> and expose them to the developer.
>
> 2) Hack the runtime to use an index rather than a pointer to the actual
> object.  I think this is how smalltalk does it.  It would allow us to 
> do some
> cool things, but may not be worth the time and effort for Gold v0.5.
>
> James has already voted for choice 1, so I'm looking for your vote.
> If you decide on option 1 (which I recommend for now), I need the 
> details of
> what we decided, including the list of classes we agreed upon, as well 
> as the
> hierarchy, which may be in the svn tree.

	Given that this will not require any changes to the LSD to user API, I 
think
this is a sane course of action.  While I love the concepts we're 
introducing,
I think expecting many of these advanced features for v1 is perhaps a 
bit too much.
I would argue that v0.5 should have few if any feature differences.  
Let's get
a simple product out the door, and spark interest.

	I think a good plan is to have a 3 part list of features for v1 series:
A) The features we will have in v0.5
B) The features we will also add for the v1 release
C) A list of features that will possibly be added in the v1 series.

	In reality, v1 may never make it to a business market, so it need not 
be the
be all and end all of OSes.  Even with the more modest system design we 
had, GOLD
with LSD and GOLEM is still something quite phenomenal.

	So, to make it simple, my vote is for reducing feature sets.  This has 
the
added advantage of embracing more classically oriented developers, for 
a time.
The mental state shift from POSIX to even stripped GOLD v1 is a big 
step.
Remember, our system will be quite useless if people DON'T want to 
write for
it, or cannot write for it as easily as they would like.  (Albeit we're 
trying
to make it easier, people adjust slowly.)

	My vote: Expose the file api.  I love the concept of objects as a 
filesystem,
but it's so grand a paradigm shift that we lose in 3 ways.  We lose on 
the
count of requiring programmers to make a radical change.  We lose on 
the count that
we cannot easily move to this paradigm using existing platforms and 
tools.  And
we also lose on the count that we're gonna sink MORE time into this 
change than
we should.

	Once we have v0.5 out the door, the people in #gold on freenode will 
start
to take interest.  A few will install it.  If we have a working POSIX 
layer on it,
people will even start replacing some of their systems with it.  This 
is what we
want.  They'll become end-testers, and we'll pick up a few more, maybe 
a dozen
more developers.  We can outline the developer model we want for v1, 
and hold
them to strict coding standards, using a commit model like FreeBSD or 
the other
BSD's.

	Long range plans:  After v0.5 ramps into v1.0, we turn over the 1.0 
branch
for maintenance to the developers we have recruited.  They'll keep it 
going, and
we'll have a stable platform to bootstrap GOLD v2 ideas on.

	I honestly think we're at the point of diminishing returns on ideas 
for v1.
v1's design as of March (loosely) is a good starting point for a 
system.  It has
a lot of great concepts, and sets the stage to introduce more concepts, 
later.
while the API's from that time are a bit incompleat, and stunted, they 
all
embody a full fledged idea, that just needs fine tuning.

	We've got a lot of work left for ourselves, even with this reduced 
goal set.
Justin needs to get used to making his system work on a block-and-event 
API, and
so does James.  I need to get used to the idea of certain asynchronous 
events in
userland causing things to occur in other threads in kernel.  There's 
filesystem
structures to debug, and plenty more things too.  It just seems that at 
the rate
we're going we've innovated whole new ideas and changes to the system, 
before we
totally understand the previous innovation, let alone have tried to 
code it, or
design how to code it.  We're getting too far ahead of ourselves and 
we're going
to stumble that way.

	 Yeah... I'm being long winded.  I hope I have gotten the point across
though.  The whole point of v1 being v1 is that we DON'T have time to 
get all
we want done.  That's why there's a v2 and a v3.  We can't explore it 
without
building it, and we need something feasible to build.

	That said, I will get together that list of classes Justin wrote up.  I
will send it in a mailing when I wake up "tomorrow"  (It's post 0000) 
Tuesday night,
or Wednesday I should be restarting development.  Right now, I've got 
the
whole Jewish High Holy Days thing coming up, so I'm taking some time 
for that.
I'll re-connect with you guys then.


--
Adam David Alan Martin

P.S.: Let's be more professional about the whole endeavour from here on 
out:  All
mailings related to Gold should go to one or more of the mailing lists. 
  Logs of
irc all the time.  Document everything.  And keep it modest.

P.P.S.: Since I think v1 should be feature frozen, all new ideas should 
go into a
discussion list for v2.  No work, hardly any discussion on it at this 
time, just one
big ever growing brainstorm list of ideas we might play around with in 
v2, or later.




More information about the gold-devel mailing list