> >>So, let's start. > >Yes, let's. I think we should look into aquiring/merging with the >openbeos.sourceforge.net space and seeding the source tree with Bruno G. >Albuquerque and Nathan Whitehorn's Mail Daemon Replacement, if they're >willing. That'd be one server down, and a bunch more plus a kernel to >go. ;) I will take care of getting sourceforge set up. >If we can firmly establish the project as a true replacement for R5 with >a future ahead of it, we can probably coax the community to move to gcc >3.x. If nothing else, we can do what Be wouldn't do and version the >libs. Or even go with the good ideas you have here -- just later. >Getting up and running as quickly as possible should be our foremost >concern, otherwise the userbase and community might fade out on us. >Strike while the iron is hot and all that. =) I 100% agree. That is why I really don't think that we should change any more than we have to right now. I would rather have a working R5 replacement that will run every app (to start with) than a new OS with a BeOS like design, no software and more ambitious/less stable. Let's get to R5/R6 level first. >>* i think we should use the beos kernel approach, this means >independent modules >> which are all loaded at boot time, and those who find hardware keep >loaded. >> You really don't want a single large kernel you need to constantly >recompile! > >I think we're talking about basically reimplementing the OS, so this is >probably a given. If nothing else, this architecture is definitely one >of the cooler aspects of BeOS. 100% agreed. The replacability of the server/kit model is a big bonus. >>Some legal things: >[stuff re. GPL] > >As much as I admire what the GNU folks have accomplished, I find the, >uh, "enthusiasm" of their userbase a bit hard to take at times. I'm in >favor of a more liberal license -- Mozilla, BSD, maybe OpenTracker; >something along those lines. I was looking fondly at the MIT license.