> > >What is also the case, though, is that we already *have* R5. It > > > exists. > > >I'm running it. If R5 is equivalent to R1, then we have R1. So why > > > not > > > > There is have, and there is have. :-) > > We have no source, no possible way to extend, to hope for the > > future > > R5. Yup. > > Also, believe it or not, I believe that there is cruft in R5. From > > Dr8,9 PR,DR3,DR4, etc. > > We will come through cruft free with something that we understand > > and > > have the source > > to. Is that not enough? > > There's *lots* of cruft in R5. But building R1 on R5, for that very > reason, ensures that R1 will hardly be cruft-free. Further, you can > extend it without having source. Look at the MDR, for instance. We > had > no source to anything at all. Yet we managed to extend the system, > and > replace part of it with something that is (IMHO) much better. You > don't > need to clone everything to make changes. That's the beauty of Be's > modular architecture. This is in fact only partially true. You can't just extend an existing module, like adding another method to class XYZ. You will have to rewrite the whole library containing the class instead. And that's exactly what happens: The teams are rewriting the kits. But your statement is also not completely true in another respect: The mammoth part of the API lives in one library, in libbe.so. So if you want to modify a tiny function in the app, interface, support or storage kit (do I miss one?), you will need to reimplement the whole beast. And not only the library, but also app server and registrar. So actually we are exactly doing what also had to be done when following the approach you propose. And by staying focussed on the reimplemention, rather than also extending/improving things, we will much faster reach our goal of a self-contained OS. An OS that can legally be distributed, as opposed to a modified R5 PE. CU, Ingo