From adam at fsl.cs.sunysb.edu Mon Oct 3 03:35:16 2005 From: adam at fsl.cs.sunysb.edu (Adam Martin) Date: Mon, 03 Oct 2005 03:35:16 -0400 Subject: March work In-Reply-To: <200510022242.02722.jrh29@alumni.cwru.edu> References: <200510022242.02722.jrh29@alumni.cwru.edu> Message-ID: 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.