I remember this coming up somewhere before, but I cannot find it. So please forgive me if I repeat existing material. Why do we need OS's? Their various components should be considered indpendent and hopefully swappable modules it would seem. Modules include: * File systems - Just like RDBMS are generally OS-independent, so to should the file system. (Some consider file systems simply a form of hierarchical database. See FileSystemAlternatives) * OS interface: The idea of multiple vendors supplying interfaces on top of the OS was common in the DOS days, before MS found a way to squash them with early Windows. And CLI unterfaces are just scripting prompts that operate on files and pipes. API's can be used to access features such as processes and pipes from multiple language environments, similar to the PosixStandard. * Security: Access management is usually just AccessControlList technology used on file systems and process managers. (Generally there are 3 things to manage: files, processes, and communication pipes/pathways.) * Process manager: These too could be independent of the file system implementation. I agree that cordinating it all may be tough, but do we necessarily '''need''' monolithic OSs to pull it off? Has tradition blinded us to component alternatives, or is the problem too complex to manage as interchangable components? --top Be precise please, are you attacking the concept of an operating system or are you attacking monolithic operating systems? The two are very different. Until the last paragraph, you seem to be attacking the concept of an OS as a coherent whole uniformly following a set of well-defined principles. I'll grant that ''in practice'' OSes aren't coherent wholes uniformly following any set of principles, no matter how ill-defined. But then, I don't expect good software from the business sector, that kind of stuff comes from research and OS research is dead. ''Precision may require that we first clearly define what an OS is. If it is a set of fairly distinct services, then it should bring up the question of why they are usually bundled together. If not, then what is the definiton of the central "thing" it allegedly needs to be an OS. --top'' The traditional definition is as you say, a set of fairly distinct services. That definition sucks though since many things which should rightfully be considered part and parcel of the OS (like the window manager) usually aren't included. I prefer defining an operating system as a coherent whole which follows a set of well-defined principles, standards and conventions. Anything you add to the system which follows those same principles, standards and conventions is an extension of the operating system. So an operating system isn't really software, it's the set of concepts which the software adheres to. (Incidentally, this seems to be close to the definition of a 'system', just slightly modified to be a single 'system of software'. To see this, think about a human body as a system and then the foreign things you can add to it which may or may not become part of the system despite being internal to it. In particular, neither asbestos crystals nor an artificial heart pump become part of a human body even though they're in it, but a transplanted organ may.) According to this definition, Unix is defined by its various conventions, of which "every program is a filter" is an important one. X Window is not part of Unix because it violates its conventions. PlanNine is a lot more extensive than Unix because the software made for it is more coherent and uniform. So its window manager, 8 1/2, is part of the OS. By that light, OS isn't an archaic concept, it's just one that's not applicable to the commercial crap we have shoved down our throats. -- RK