> "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx> wrote: > > If the cruft is in the API (as it often is) or in anything > > necessary > > to > > maintain binary compatibility, it will necessarily continue to be a > > part of R1. Further, most of the cruft that is in R5 (as far as I > > can > > tell) is still there only for compatibility reasons. If we > > duplicate > > compatibility, we therefore duplicate cruft. > > At least for MDR, this is true, but we want to achieve binary > compatibility, and that can't be done the way you propose. And if it can't? Is binary compatibility really that important? I can think of only one common, closed-source, extant BeOS application: Gobe Productive. And this is only an issue because the developers seemed unlikely to recompile it for us. But, if I remember correctly, even this has changed now... > > > And getting consensus is the hardest thing which was why R5 was a > > > good > > > starting point. > > So you have a consensus to do something essentlially pointless... > > If you don't get it, well, I can't help you. I understand the rationale. We can't get Be's source, so we'll make our own. The original plan was for Be to improve their software. That failed. So we'll improve it for them. But Palm won't give us source. So we make our own and go from there. That, as far as I can tell, is that basic stategy of OpenBeOS. I am arguing now, as I have in the past, that that strategy is flawed. It was a modification of an existing plan that no longer makes any sense. We might as well figure out where we want to go and aim for there, instead of writing a heck of a lot of code, figuring out where we want to be, tearing it down, and beginning again. The more the future of the project is different from the present, the more code has to be *rewritten*. People don't like to do extra work. As such, developing R1 as R5 ensures conservatism in the evolution of OpenBeOS. At, last I could tell, BeOS was about throwing out compatibility, throwing out conservatism, and building what should have been built all along. > > You *can* run ideas, once they have been coded. Or you can skip the > > ideas, and just code mindlessly. > > Hmm?? Ideas become software. Once they are software, they can be run. Or you can make software without ideas. You can clone what exists. That will run too. But, tens (or hundreds) of thousands of lines of code later, it will just be what you always had. > > Just to make things clear, I *am* a developer. What I'm arguing > > against > > is the lack of foresight of the OpenBeOS project. > > Well, from my POV, you are lacking of foresight, and that's why you > want to go another route :-)) > > OTOH how would you like to design something from scratch in a project > as big as OpenBeOS? Should everyone get a word? Should everyone have > to > come up with a reference implementation to be taken serious? > Having a fixed feature set including a reference implementation (R5) > is > a gift, and one that shouldn't be overseen so easily. I suppose it is a useful thing. But a good one? I'm not so sure. By viewing R5 with such an uncritical eye, we risk duplicating all its mistakes along with it. As for how I would design something like OpenBeOS from scratch, I would simply create a general idea and aim toward it. As that is discussed/ coded, we discover smaller and smaller things that should be changed. Essentially, I would use the coding process as examination. It's something that has always worked for me. Isn't R5 that process, you say? It is indeed. Starting to make R5 is a wonderful place *to begin*. But it is a process that should never be finished. If we succeed in coding R5, we have gained nothing, for we will have copied blindly, without critical examination. Nobody writes code and says: this architecture sucks! or wouldn't it be nice if I could...? There are terrible design decisions in R5. There are places crying out for new architecture. There are great gaps in the API. But, in cloning, we ignore them. True, we see the errors, and correct them, in fits, with individual routines and modules, but not on a large scale, and, as a result, I am afraid that we may succeed in cloning R5. And nothing worse can happen to this project that to have spent all the time and effort we will have spent when we are done without seeing what it is that we are making. -Nathan -- Fortune Cookie Says: "I used to get high on life but lately I've built up a resistance."