I think it's time to split OSes into independent services. This will modularize them and make it easier to trouble-shoot problems. Possible divisions: * Kernel - Basic coordination and task master * File System * Security System (may expect certain meta-data in file system to function properly) * Device Manager - Tracks active devices and the traffic between them. ** Both "native" and pipe-based versions of devices should be available in all drivers. Native for speed and pipe-based when we want more monitoring or control. ** ''PowerOfPlainText should be taken advantage of. Binary is evil and should only be used as a last efficiency resort and be an extra to text-based instead of a replacement. Communication could be done via a text console if needed for debugging with standard commands between each server. This allows logging, tracking, debugging, etc.'' ** I'd avoid saying "never" on such. Binary may be needed for efficiency in some cases. Perhaps "avoid if possible". ** ''That might have made sense if someone had said "never"...'' * Application manager - tracks the apps/tasks, their memory allocaton, etc. * UI - User interface. Perhaps this could be HTML-based or AJAX. ** System services UI ** UI engine(s) for applications ''Congratulations, you've re-invented UNIX.'' {If that's so, then I can mix it with Windows, and have some parts Linux and some BSD without signif recoding.} ''Yup, and it's called Cygwin. :) I'm being somewhat facetious, of course, but UNIX and its derivatives are largely modular. Devices are abstracted as files, the usual UI (X) is unbound from the kernel and essentially runs as a suite of applications, file systems can be supported as removable kernel modules and mounted and unmounted, and the general philosophy is one of intercommunicating small tools rather than a monolithic environment. Of course, greater modularity ''could'' certainly be achieved -- it would be interesting to see what an operating system based on, say, WebServices would look like.'' And even going further and splitting the kernel isn't new either. The only remaining part might be - but correct me - of splitting a microkernel like L4 into * a mmu abstraction that ** guarantees that no page maps the page or hw table ** can set page table entries * a cpu abstraction that ** swap a cpu context from/to a page table ** can set irqs (initiate a specific cpu swap) * a hardware abstraction that ** can compile io-operations to valid hw-accesses ** execute such a specific table One could implement e.g. L4 on top of this by providing a specific memory and cpu mapping. ''Can Unix use a NT file system? Without case-sensitivity?'' Not sure about case-sensitivity or lack thereof, but see http://www.linux-ntfs.org/doku.php ---- You should check out NewOsFeatures, look up ExoKernel, and read some of what RichardKulisz writes on this subject. He may have been kicked from the Wiki for being too mean to others and a bit overbearing, but he's still full of good ideas. You also can't separate the security system from everything else. Security isn't something that can exist sitting off on its own as an optional service; it must be pervasive. However, you can centralize a few aspects of security, such as caches of public/private keys and key distribution services, and perhaps a communications watchdog. ''Think sort of in terms of how services and files are shared on a '''network'''. Yes, there are login prompts/steps, etc., but these are generally automatable (if we want them to be).'' Are you confusing user-interface with security? ''No, that is why I used a slash. If a remote service needs a login (authentification transaction) of some sort, there are usually two choices: a user login action or a proxy of the user action. In other words, the OS or security-system can store the passwords etc. and login on behalf of the user. That way the user is not necessarily prompted for every service (file system, GUI system, app database, etc.)'' ''If we use existing "web" technologies as our metaphor or guide, then the OS can be split roughly into:'' * Application server * File server * Database server * Client/browser * Security manager (Controversial. Perhaps "coordinator server?") ''A "desktop" setup is merely a special case where there is strong bandwidth between all these services.'' -top {What's a "strong" bandwidth?} The assumption that there is a "fat pipe", that the volume and response time between these "services" is good. {How do you define "fat" and "good"? I'm aware of casual definitions of these things, but casual definitions are ambiguous.} * [It is worth noting that 'GoodEnough' latency to support UI is often a very 'soft' measurement anyway. Sometimes 100ms is GoodEnough. Sometimes 2-3 seconds latency is GoodEnough. In that sense, the vagaries of the definition are warranted in this case. As to the "fat", I'm not sure the purpose there. If one is streaming music or video, that requires a 'fat pipe' in some sense. In DistributedSystem''''''s, one can use fat pipes. It's easy to push more data. Latency is the only real concern.] Well, I don't want to get stuck in definition-land today, so I'll offer a scenario. "Bound controls" are a common feature of desktop-oriented CrudScreen''''''s. For example, if you have a data grid and you are doing data-entry, as soon as you leave a given cell (on-cell-unfocus event), it may immediately validate and save that cell into the database. A web-based or WAN-based application is much less likely to do that, so they use "un-bound" architectures. Generally you make all your data grid changes, and then press some kind of "Save" button. Waiting for approval for each on-cell-unfocus event over the web or WAN would result in a slow or jittery user interface because the turn-around time is either slow or too unpredictable. (Asynchronous approaches can be used, but are trickier to coordinate, especially if a cell fails validation after we've already finished 10 other cells.) Thus, "desktops" assume and/or rely on quick turnaround time between messages/packets. We could probably have a web-based app effectively use bound controls if all the services/parts listed above were on the same CPU box. In short, apps tend to "batch" messages and info packets more if the latency or bandwidth is noticeable. -t [Asynch approaches would work quite well, there: validation would conceptually be performed 'continuously', and in the background (e.g. via highlighting) to help the user know which inconsistencies exist. Similar to how syntax highlighting can help users detect errors at edit-time. Whether one also uses ZeroButtonCheckin (automatic 'save' when consistencies are removed) is a possible extra feature. Even better: when using '''multi-user''' CRUD-screens, where two or more users are editing the same object, the asynchronous approach can help users see each other's edits and possible conflicts.] [And the ApplicationModel for UserInterface sucks on many, many levels for performance and such. There are better models for UI, not the least of which is the humble SceneGraph (more accurately, the InteractiveSceneGraph) combined with a dose of PublishSubscribeModel. (related: DocumentDefinitions)] I'm not happy with your style of favorite languages/tools. You think weird, from my perspective; but to each his own. [You think like a fucking '''crank''' (http://en.wikipedia.org/wiki/Crank_%28person%29) from the perspective of the majority of people who have every had the misfortune to communicate with you on this wiki (ObjectiveEvidenceAgainstTopDiscussion). You are illogical, irrational, uneducated, arrogant, biased, and stubborn from my perspective. But, to each his own.] The feeling's mutual. I suspect only a handful of people cause the majority of conflicts, and they tend to be the type who are against science and RaceTheDamnedCar, thinking about that merely ''talking'' enough about theoretical elegance is sufficient to establish their point as fact. In other words, "do-metric" people communicate with me much better than talk-metric people. Further, I don't see any majority support for your favorite UI technologies. Thus, the "majority of people" metric that you introduced would ironically be problematic for you, for you are the "MIT" camp in WorseIsBetter: overly idealistic. But I think we can both agree not to over-emphasize ArgumentByTheMasses (truth-by-vote). -t ----- I realize for action gaming systems, this suggestion would probably result in too many levels such that performance is compromised. Thus, perhaps there should be a gaming mode or zone and a "regular" mode or zone. ''Not necessarily. Gaming needs optimization, but the primary optimization required is only that services communicate via a rapid communication mechanism (e.g. shared memory), and that security verifications provide locality optimizations (to avoid repeated decrypt/encrypt on the same memory... a pointless activity if ever there was one) along with representation optimizations (to avoid parsing/presenting repeatedly on the same machine). However, I'd imagine that you're unlikely to easily gain the performance you're looking for without using a programming language dedicated to these sorts of cross-abstraction, cross-layer, and cross-communications optimizations. Doing it by hand in the modern programming languages will be painful as hell (due to variation approaching cartesian product).'' I can see how hookups to input devices, such as joy-sticks may be sufficient these days under a text protocol, but not communication from say the CPU to the graphics card. But, the text-protocol path between the two should still exist as a secondary option if the one cannot get the binary drivers to work (which is often the case). ''I'd imagine that one might be abstracting or translating a bit. A text-based protocol to the graphics card might still be interpreted by the CPU then transformed into proper GPU commands.'' ----- Not to sound like a zealot, but in an ExoKernel based system, a game would just use its own library-OS ''True. And that may work quite well for a game, absent any need for fair distribution of resources.'' --------- SplitOperatingSystemIntoServices isn't a bad idea, but I'd urge some caution. Achieving "features" for an OperatingSystem or ProgrammingLanguage that are ''orthogonal'' will usually require design and implementation details that are tightly interwoven, especially for resource management and dependencies. One cannot separate security from persistence or process or devices. Modularity is possible, but requires that the 'weaving' be performed dynamically... i.e. via a DependencyInjection framework, which may be part of a kernel. Anyhow, this means one might SplitOperatingSystemIntoServices, but the resulting services will be ''interdependent'' rather than ''independent'' as suggested at the top of the page. ------- See also: NaturalEventSyntaxDiscussion, AreDesktopComputersObsolete ------ CategoryOperatingSystem