Dear Andrew, > Even if it's more tightly integrated, it's still a penalty box IMO if it's a > second- > class citizen within an incompatible native environment (which few people > are going to port anything to no matter how good it is because any new OS is > going to have limited market share, leaving pretty much everyone to just > write Linux programs, much as with OS/2 and Windows back in the 90s).
I am not good in predicting the future. I can only try to influence it. But still I think you are overgeneralizing a bit here. Not everyone is writing Linux programs. Many people write Windows programs (if we like it or not). Many people write programs for managed environments such as JVM and .NET (among others) or use high-level languages such as Python, R and Haskell (among others) and they don't really care much about the underlying OS. Many people actually write programs for niche environments (i.e. RTOSes). Saying that Linux (or Unix, for that matter) is the entire world and anything that does not try hard to mimic Linux (or Unix) is deemed to fail is just black-and-white thinking to me. The world is actually quite colorful :) and it is surely not static. > What about QNX? It's one of the most practical and successful microkernel > OSes in the world and it's natively Unix-like. It's not perfect, but none of > those imperfections are really inherent to the Unix-like architecture. Pretty > much every other OS developer seems to ignore it though. I really don't get > why that is. I can assure you that I am definitively NOT ignoring QNX. I know the code base of the open-sourced release of QNX quite well and I could spend hours discussing what I like and what I dislike about it :) Plus, I have to deal with the legacy of QNX even more than I would like on a daily basis (wink-wink :)). But, frankly, if QNX is indeed successful primarily because of being Unix-like then it only demonstrates that being Unix-like is not a sufficient condition for world domination. I am not arguing that being Unix-like is not a necessary condition for _some_people_ (like you), I am just saying that it is of little importance or even a hindrance for _some_other_people_ (like me). > UX/RT will more or less just take QNX's general architecture and enhance/fix > a lot of things. Assuming it is successful, it will only be the second working > QNX-like OS other than QNX itself of which I am aware (VSTa was the first > QNX-like OS besides QNX itself that I am aware of, but it is now abandoned). I sincerely wish you good luck regarding that! I honestly welcome every effort related to microkernels. And after all, the observable reality is the only true judge of our ideas :) > UX/RT won't just be a legacy-misfeature-for-legacy-misfeature > compatible reimplementation of conventional Unix on a microkernel. > There will be a lot of longtime Unix features that it will either throw out > completely (e.g. setuid executables, binding of device nodes by major/minor > numbers, utmp) or reimplement on top of new APIs (e.g. > fork, which will be be built on top of an API that allows creating a "blank" > process and manipulating its state, and BSD sockets, which will be > reimplemented on top of a filesystem-based API sort of like that of Plan 9). > Even though it will be superficially familiar-looking in a lot of ways, it > will still > be quite different from conventional Unix. OK. But now I don't really understand what is the main conceptual difference between your approach and the approach of some of the other microkernel-based systems that also provide some (sometimes native, sometimes optional) Unix compatibility (GNU Hurd, MINIX 3, Redox, Huawei's OS, maybe to a lesser degree Genode, HelenOS, etc.). We all follow the same reasoning: Take inspiration in Unix where it makes sense, ignore the parts that are obsolete (or purely obscure from today's perspective), but provide some sort of "polyfills" for the use cases where running Linux programs (with or without recompilation) is really strictly needed by someone. Of course, we will probably never agree where to actually draw the dividing lines and what specific implementation means are the best (what should be "native" and what should be a "polyfill"). And that's perfectly fine because we all have different motivations and tastes. But I fail to see why do you label the approaches of others as "penalty boxes" with respect to full genuine Linux compatibility while you don't label your own approach as such. In case you plan to throw out setuid executables (your own words) then you can hardly achieve full Linux compatibility. Best regards Martin Decky _______________________________________________ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
