Home   Info   DevZone   Wiki  
UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
NetworkOperatingSystem ] [ not logged in ] [ Web: Imported ] goto:  options
[ get info on or edit ] login or new user ] [ list of topics, hubs & nodes, or recent changes ]

A NetworkOperatingSystem is a task-oriented OS that is set up so that users can interact with the internet very easily; it's central tenets are Collaboration and Information; everything is built around these two goals, to the point of blurring the line between the local computer and the network. For example, Windows 98 is a pseudo-NetworkOperatingSystem, because the line between the desktop and the network begin to merge with the ActiveDesktop and the integration of Internet Explorer. I agree that it is very important for an OS to know about the local machine, but what if we blurred the lines a little bit more? Old OS's and NOS are centered around different tasks; Old OS's are about managing files and running programs; NetworkOperatingSystems are about _organizing information and promoting collaboration_. It's like the difference between command-line operating systems and GUI operating systems; command-line OS's are oriented around different tasks than GUI's. The usefulness of a command-line OS did not disappear when GUI's came along; it was merely subsumed by it. Perhaps the same is true for NOS's

Old OS's like Windows and Mac OS are about local File Systems and local Programs (pretty much)

A NetworkOperatingSystem is centered around Collaboration and Information.

Perhaps the core of a NetworkOperatingSystem might be a Multi-User Dungeon(MUD), with services built above this in the same way that services are built above Windows 95.

What do you feel a NetworkOperatingSystem should be?

Insert comments here


Nonexistent. An OS that supports collaboration & networking is a worthwhile goal. Tying a machine to a network is __a bad idea__ , IMHO --BillRehm
A NetworkOperatingSystem is just an OperatingSystem which is Network-Aware. This can be as unattached to the network as not even having a tcp/ip address to as attached as downloading the major kernel parts from a server. But in reality will probably be somewhere in the middle. -- MichaelFried

As stated above, it is wrong to tie the OS to a network. What the OS should provide is a great deal of transparency and power when connected to the network. A good example of this kind of behaviour is how machines across a Mac network appear just like any other volume on the desktop. As well as ease of access to data across the network, communication should also be easy. However I feel that it would be unwise to build the mode of communication in to the OS. Build in powerful services and then write E-mail, whiteboarding tools to take advantage of them. --WillMatthews


Make the local computer look like the network so that the rest of the OS is un aware it is not attached to the network when there is not one. In basic make all local work the domain of servlets so the tasks are performed by the shell accesing network resourses at the local host address (or at the server address if the network exists(or both)) A simple advantage of this could be forinstance voice recognition: the user interface pases the sound to a servelet that may reside localy or on the network where more powere is available and the servelet responds with the command or result.

--ChrisLee 05/01/98


There is always going to be a distinction to the operating system itself as to what resources are local and what are not. However, providing distributed computing as functionality within the OS is fairly trivial if done at the beginning. I have the start of a device driver design that builds on Java RMI.

RMI (in 1.2) doesn't care what its transport is. So if there is a mechanism within the OS for local machine communication, and you then provide external networking protocols on top of the internal one, you by default can provide access to device drivers from other machines on the network.

If memory, address spaces, and other task properties are accessible as device drivers, and particular machines on a network trust each other, they can access each other's task controls and execute code on each other's processors or read each others disk volumes (or any other activity) with no additional OS support. It's really fairly simple. See KeithsDriverDesign for more info.

-- KeithMason 16-Mar-1998


Content of these pages are owned and copyrighted by the poster.
Hosted by: