Actually, I was planning to write something on this, anyway, since we are all spending *WAY* too much time reading and writing about things that are non-issues at this point. :-/ Helmar and the BeFAQs folks are going and trying something on the business side. When they have a *real* proposal, I think that we should listen and talk for a couple of days and decide whether or not to support them. Trying to decide that now, when they don't have a real idea what is going on (since they haven't negotiated with Palm yet) is foolish, really. They don't have a solid proposal and even if they did, I doubt that they could or would talk about it. Reverse engineering is another hot topic. I consider this a 5% problem - we can do 95% of what we want/need without ever talking about this. When we are almost done, and something doesn't work right or isn't fast enough, we can work this out in private. Fact is, no one is going to sit down and R.E. the whole kernel. We have TONS of work to do without discussing this. Kernel selection - every couple of days, a new users pops up and suggests that we use Linux/AtheOS/NewOS/OpenBLT/WHATEVER as a basis. This needs to go in the FAQs (Phyte?) - we made a decision. Right or wrong, we could debate forever. But no more list bandwidth needs to be wasted on it, IMHO. Open vs Closed source is also something that we have been over. Names, copyright law and patents, ditto (phyte?) Source vs binary compatability - this is, IMHO, another 5% question. Let's get the thing 95% done and then talk about it. I do not want to waste energy debating an issue that is 9-12 months (at least) in the future. NewOS issues - IMHO, that is really something for the kernel team. I am not sure why anyone else would want to even mess with it - it doesn't have a build environment, it isn't suitable for development yet, etc. The way I see it (and I am not the Gestapo, here), everyone not doing kernel development ought to not care in the least about NewOS, other than out of project wide interest. The fact that we chose NewOS does not (should not) matter to (say) the interface kit team in the least. A new kernel from the ground up, a modified linux kernel, or (God help us all) a layer on top of Win32 ought to serve all of the other groups just fine. Sigh. I am sorry if any of the above sounds angry or harsh. That is not my intent at all. To be honest, though, when I have > 100 mail messages per day to read and maybe respond to, it cuts into my kernel hacking time. I think that we all have real lives, too. Families/spouses/dates, work, school, whatever. I doubt that most of us want to/can afford to spend an hour or 2 each day reading these messages AND be significant contributors. And as interesting as some of these topics are, I am not really sure how most of them are going to get us to an OpenBeOS release. I don't want to tell anyone what to say or not to say. Or do/not do. I don't want to be the List Nazi. If anyone disagrees, please send it to me off-list. >I am in full agreement that we need to break up this forum. In the manner >that Be's mailing list were broken up for the developers. BeCodeTalk and >BeDevTalk both had clear purpose and you could much more easily filter out >the noise. > >However, we are hardly at a stage where this breakup is a good idea. The >things that we are talking about are important at this stage. There are >fundamental questions that need to be answered before we can hit the >ground running. > >As far as I'm concerned, this talk of open or closed is useless. We spend >all our time debating how Palm will handle things. /This is out of our >control/. So let's talk about the things that we _can_ control. > >1. Source vs Binary compatibility >2. NewOS compatibility issues >3. Plan of attack > >In my opinion, it's time to get everyone a copy of the most recent NewOS >build and see what hardware works and what doesn't so we can help Travis >get the kernel booting. We need to build up the tools that we'll use to >write OpenBe. We need to hack on the kernel so we can start using it as >our development environment. Then we can talk about delegating work to >get openBe to comply to Be (in one way or another). > >I say we leave the politicking to the politicians and get to what we >know: hacking out code. > >Who's with me? > >-Justin >(trying to keep us all united) > > >