Mark wrote: > Which makes it extremely important to make R1 a future-proof and simple > ABI. The mistakes made now sticks around for decades, and the current > baseline seems overly complicated and messy. Keeping gcc2 compat around > must be a future maintenance nightmare. How so? If anything it will speed up rendering it insignificant, at which point we can drop it :-) It doesn't hurt to have the 32 bit ABI around for now (at least I don't see any practical issues aside from how it looks like on paper), and the more incentive we give our developers to switch to an R2 API, the better. The R1 API won't change anymore after a point, and will only need to be adjusted to server protocol changes. While staying compatible is certainly more work than to ignore compatibility, I can't see how GCC2 could create any kind of nightmare. Not sure why you make so many assumptions about that; it certainly doesn't help discussing the goals. In any case, if you need 64 bit, and don't care about 32 bit ABI compatibility, no one prevents you from using the 64 bit version of Haiku -- it actually exists for a reason. And about the user friendly OS: of course that's one of our goals, too. It's just implicit for R1, but it will be pretty much the main goal after that release AFAICT. Bye, Axel.