Distributed Operating Systems?

ayejay asks: "Are there any models/designs for a totally distributed operating system, possibly utilizing AI to learn patterns of use, resource need, and anything else that might be relevant? What -would- be relevant to such a thing? Given Napster and all the load balancing kernel enhancements and SETI@home type programs out there, it seems the idea is ready to be developed into a feasible paradigm. What do you think some of the major concerns/design issues are? I'm talking about nuts and bolts..." Now I'm all for distributed applications, but applying such paradigms to something as critical as the operating system seems to be taking the issue a bit too far. Would creating a 'distributed' operating system gain us any advantage over what we are currently familiar with?

Comments

Suns... Plan 9

[Dungeon Dweller]

Sun Microsystems products are designed around a network paradigm. A lot of the distributed stuff we have today comes out of their work. Distributed being used in a bit more ubiquitous sense than necessarily meaning clustering the processor power.

Plan 9, as part of its design, is designed with distribution in mind. Check it out!

Mosix

[1010011010]

Mosix is pretty cool, and will be even nicer when they have Distributed Shared Memory, Migratable Sockets and Direct Filesystem Access issues worked out (currently Mosix does i/o remotely through the home node, which makes it slower and loads the home node; DFSA allows remote nodes to access files locally rathen than via remote-I/O).

It provides preemptive process migration among cluster members. If you log into your "home node" and start a process, it will get migrated around the cluster according to its memory and CPU needs. Take a look at their remote monitor.

Currently it's Intel-only, but a mixed-architecture version would be sweet. Imagine a cluster of intel, alpha, PPC and sparc CPUs such that you log into any of them, run any Linux binary, and the loader cranks it up on the appropriate machien for you, transparently...

From the website:

MOSIX is a software package that enhance the Linux kernel with cluster computing capabilities. The enhanced kernel allows any size cluster of X86/Pentium based workstations and servers to work cooperatively as if part of a single system.

To run in a MOSIX cluster, there is no need to modify applications or to link with any library, or even to assign processes to different nodes. MOSIX does it automatically and transparently, like an execution in an SMP - just "fork and forget". For example, you can create many processes in your (login) node and let MOSIX assign these processes to other nodes. If you type "ps", then you will see all your processes, as if they run in your node.

The core of MOSIX are adaptive resource management algorithms that monitor and respond (on-line) to uneven work distribution among the nodes in order to improve the overall performance of all the processes. These algorithms use preemptive process migration to assign and reassign the processes among the nodes, to continuously take advantage of the best available resources. The MOSIX algorithms are geared for maximal performance, overhead-free scalability and ease-of-use.

Because MOSIX is implemented in the Linux kernel, its operations are completely transparent to the applications. It can be used to define different cluster types, even a cluster with different machine or LAN speeds, like our 100 processors cluster:

---- ----

Google is your friend.

[Carnage4Life]

From a quick search on Google.

A listing of the major OS research projects involving distributed operating systems

OS info, including distributed ones

[JohnZed]

There's a huge list of various operating system projects here: http://www.cs.arizona.edu/peo ple/bridges/os/full.html.
I find all the "pure" distributed OS stuff (systems build from the ground up to do distributed processing and not much else)relatively uninteresting on its own, but a lot of good ideas from those projects can filter into general purpose operating systems, especially when you start talking about clustering or even NUMA. You might want to see MOSIX for a cool, distributed/clusterd Linux version.
--JRZ

Several Options...

[Christopher B. Brown]

• Mach was the "granddaddy" of distributed OS work, with most of the recent efforts going into GNU Hurd.
• There's Mosix that builds a NOW atop Linux
• The MIT Parallel and Distributed OS Group should be mentioned; efforts include the Exokernel
• Plan 9 has an interesting model for splitting work across "compute servers" and "file servers" and "display servers."
• Distributed Operating Systems lists lots of them...
• Sun's Spring was the basis for much of what is in CORBA;
• Sprite provided a Unix-like distributed OS that provided much of what is being used now to build journalling filesystems
• Amoeba was Tanembaum's successor to Minix; note that Python was one of the side-effects of the Amoeba project...

Each has some somewhat different insights to bring to the table; there is no unambiguous way of saying "this is all vastly superior."

Success Depends on Application

[tarsi210]

From the What-do-you-mean-the-coffee-maker-stopped-respondi ng? dept.

The true success of a distributed OS will be in the applications in which it is applied. Obviously, if you don't have need for the advantages that a distOS brings to your computing, then you don't need a distOS, however cool it might be. My mother (who finally checks her email every night, bless her technologically-crippled heart) does not need the problems associated with attempting a distOS. What she does would not benefit from the extra resources.

Of course, supporters of this idea (and I'm not saying I'm not one) would state that you don't think you need the distOS because we haven't actually made a reason yet to need it. Kind of like how everyone didn't NEED the Internet until, of course, we had it. Now there are sites like /. full of caffeine-enhanced techno-addicts. The presence created the need.

This is true, I think, in many ways. However, I think when implementing such an OS consideration needs to be had for exactly what is being accomplished by it being distributed. I can see mainframe-like systems being extremely benefitted by such a system. A game system could really benefit from the extra horsepower, given that the connections were strong enough. Playing music, DVDs, etc...all very high CPU and memory applications could see some interesting benefits.

How about stability and redundancy? How would you like an OS that ran even if a bomb knocked out part of its system? Rewrote and/or re-routed itself to account for the damage and still get the job done? Wow! What a disaster-safe way to compute! Of course, you have one of these OSes inside your head right now......

End fact is: Good idea, needs lots of consideration into the practical application of such a thing so that we aren't playing solitaire with a distOS.

Distributed OSes are here

[Greg Lindahl]

There are several real, full-featured distributed operating systems out there. One good example is Legion. It gives you the illusion of running programs on your desktop, while they are actually running lord-knows-where. Yes, you often need a lot of network bandwidth to get good results. Depending on the exact details, you can run programs on other machines with either no or small modifications.

Lest you think this has nothing to do with today's operating systems, the Linux desktop folks have started using Corba quite a bit to link things together. Well, Legion provides much more powerful, secure, and reliable ways to do the same thing, in a much more consistant fashion.

Distributed, but not too connected

[Animats]

There have been all too many "distributed operating systems" out of academia. Few if any have gone mainstream, for a number of good reasons.

• There aren't many problems that really need one. SETI@Home and crypto problems need so little coordination that E-mail would be enough.
• Clusters are easier to do Read In Search of Clusters, a philosophical book on why clustering beats tightly-connected systems. This was written in 1995, before clusters took over the web server industry, but it's more relevant today than it was then. And it's out in paperback now.
• There seem to be no useful stops between shared-memory multiprocessors and clusters. Many efforts have been made to build machines with lots of processors and exotic schemes for interconnecting them. From the Illiac IV to the Ncube to the Transputer to the Monarch to the Connection Machine, they've all lost out to more vanilla architecture.
• Writing tightly-coupled distributed applications is both hard and wierd. There have been many attempts to make it easier via language design, from T/TAL for Tandems to LINDA to Occam to single-assignment languages. Nobody uses that stuff. (Arguably some should; one big lack of C/C++ is a total lack of language support for concurrency.)
• Networking bandwidth is high enough for clusters. So ordinary techniques suffice.

It's one of those things that's hard to do and has a low payoff.