Split Operating System Into Services
Split Operating System Into ServicesI think it's time to split OSes into independent services. This will modularize them and make it easier to trouble-shoot problems. Possible divisions:
{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
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:
{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.}
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
EditText of this page
(last edited July 21, 2014)
or FindPage with title or text search