Slashdot Mirror
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?
Sprite, Plan 9, Inferno, Springs -- just to name a few -- all have various aspects of being "distributed operating systems" to them....
Wasn't NeXTStep a true distributed operating system? I seem to recall reading that even the OS's memory manager could be running on a separate node... but I could be recalling wrong.
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!
Eh...
check out mosix here
Amazing magic tricks
Plan 9
Chris Williams
Parts of the OS has to be local, I presume. ;)
But that wouldn't be so much different from a cluster I guess.
Don't quote me on that tho
English is not my first language, so cut me some slack -: Om du kan lasa det har sa kan du Svenska
If you think about it, your current computer really is a small "distributed system" - you have (at least) one processor for general-purpose data computation, one to handle video, another to handle audio, etc. But the problem is that most programs aren't written to be distributed (or even threaded!!) and as such distributed OS's tend not to have much of an advantage. There are very few things that can be distributed to a good effect over a network of equal processors, even SMP for threading doesn't have much use beyond two processors (unless you're using your computer as a server-farm in a box).
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:
---- ----
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
I forsee intelligent programs wandering the net, finding out watering holes such as processing power and memory resources. I see people setting aside a percent of their computer for a distributed community effort.
Eventually, the use of the new net's processing power would be transparent to the user. People will barter processing power for processing power, give away to friends, sell to others, etc.
- coyo
--------------------------------------------------
Aren't distributed operating systems inevitable?
But then again, what does distributed really mean? Does it mean working across multiple workstations? Or processors? I guess what is meant is a dynamic distributed OS?
Maybe it depends on the degree of distribution and what parts are actually distributed?
We should ask Jane!
Jane? Oops, forgot to put in my earplug...
-Sleen
From a quick search on Google.
A listing of the major OS research projects involving distributed operating systems
IMHO, I think it is quite possible to distribute an operating system. I mean, Beowulf clusters are partially distributed (IF YOU HAVEN'T READ THE FAQ, DON'T POST ABOUT BEOWULF). IT could be quite possbile to divide the utilities among numerous servers, then use a program to determine the need for various utilities, and allow those servers more bandwidth on the network, or even possibly copy data to larger servers, re-arranging programs most needed to the fastest servers. It might be worth it to further investigate the idea of a distributed OS.
====
Crudely Drawn Games
The idea of making a semi-distributed OS, at least in the gathering usage statistics seems like a great idea. It would help to reduce, if not eliminate bloating and may lead to some truly innovative ideas.
However with the recent (ongoing) problem of script-kiddies and general morons, the whole project statistics-wise could be foiled. Yet this is a problem for everything, so perhaps its not even something worth considering.
If such a beast is created, it would be advisable to find a new name for it. "Distributed Operating System", in acronym form, equates to DOS, something /. readers filter out 'cause they don't like M$ and something censorware'll probably filter out 'cause it's short for Denial Of Service (attack).
How much resources any given node would have? If everyone left their computers on all the time (not uncommon) all those screensaver ticks would be put in someone elses processor pool, I assume... so would everyone average 1+ processors worth at any given moment? If it were a linux based DOS (dis. operating system!) would 'uptime' report the os's uptime, the nodes' uptime, or both?
When I grow up, I want to have Christopher Walken hair.
I was thinking about this same problem whilst sitting in a university computer lab staring at 120 or so 400mhz PII systems and thinking just how much CPU power was wasted (probably close to as much as the CrayT3E in the next building has).
My thoughts on the way forward would be to use something like beowolf to build a huge 120 node distributed system and then have each of the nodes also run as an Xterm.
Perhaps this is too distributed and we should have a slightly thicker client but conceptually i'd love to have it so when I want to compress a short mpeg clip I suddenly harness 100 times more cpu power than is in my box.
However implementing it is more of a nightmare and potentially not very worthwhile since comparatively few end user tasks lend themselves to distributed processing.
Some good links:
I don't see why it can't be done. I have written some security tools using heuristic logic and fault trees and it would seem to me that both would work well for something along these lines.
Now I know java is slow as molasses, especially client side through a browser, but i kid at my high school has pulled off the following...
/nutt
He managed to make a java applet hosted off of server A, that when computer B connected to it (through the browser), A would assign it a computation task. A would leave an open listen for connections and would shell out wordloads to be computed and returned
Now I know its not at all effiecent, but since he could take a powermac 6100, an intergraph NT box, a 486 debian box, and a solaris workstation, and have them all compute, this way pretty damn impressive. Thats where Java's platform independance really pays off.
As for what he did with it, I believe his test run involved Some Pi calculations, and it apparently ran quite smoothly.
Just throwing my two euros in the pot.
Whenever I hear things like "Let the AI learn patterns of use" I get nervous, because, IMHO, the biggest problem with user interface design is the increasing habit of second-guessing the user. Most of my frustration with that bad-old monpolist OS is not so much the crashes, but the constant tendency of the OS designers to try to second guess the users. To often, the OS tries to do what it thinks I meant to do rather than what I tell it to do. That makes the OS harder to use.
What makes an OS easy to use is simplicity and obviousness. It is far, far better for an OS to be stupid in an obvious way rather than clever in a non-obvious way. DOS, despite its clunky user interface, was often easier to use than today's Windows boxes, even for the novice users I observed, because when you told it to do something, it did it. And yes, figuring out how to make it do something was often a pain, but once you did, it was all rather simple. Too often, today, the OS makes things difficult because it thinks it knows what you want to do. A classic example on Windows being the behavior of the OS when copying a hard-drive. It tends to move the short-cuts because it thinks you are moving the OS. Mucho-paino when you are really just backing up, or moving hard drives.
An "AI" controlled OS just sounds to me like more of this, and even worse. Suddenly there's this entity out there, deciding what how the resource usage should go. Yeah, perhaps it will often get it right without me intervening. But when it gets it wrong, I get lots of frustrating hours trying to get the damn thing to see it my way. Better to have something simple, stupid and clear that I can easily direct to do what is correct. Just to have an AI that can do quasi-intelligent things in average cases is not enough. Until the AI is smarter than me, I don't want it controlling my OS.
The cake is a pie
Having a distributed OS would take a great load off of distributed application developers. Currently, a distributed application has to be able to handle all the tasks that a normal operating system currently does. Not having a distributed operating system for distributed apps is like not having an OS for normal client apps.
/., so I'm not referring to YOU).
Seti@Home has to be able to route all its necessary functions and information around its network. Why is that necessary? A distributed operating system should be able to handle the tasks of distribution for the applications. It's almost as if every distributed app developer has to re-invent the wheel every time he/she wants to create such an app. Why do you think there aren't many distributed apps out there? They're too bloody hard to code. Joe Schmoe VB developer cannot create distributed apps because like as not, he knows very little about networking. Most developers know squat about networking (keep in mind that most developers don't read
Soon, every appliance in your abode is going to have a processor in it. That processor may be much more powerful than what is really necessary to operate the appliance. Especially if a web browser is built into your fridge. The processor has to be able to run the browser, so lets say it's Pentium class. Do you really need a Pentium to measure the temperature of the fridge and turn on the compressor? No. So every time the browser is not being used, clock cycles are wasted.
I see no reason why future homes don't have the standard PC. They could use the collective power of all the processors in all of the appliances in the home to make a PC-type of interface for a user. It would also lend a certain amount of fault tolerance. Many functions would be duplicated on the home network, and data loss and downtime would be minimal if at all.
QNX distributes very nicely - they have a wonderful node-independent IPC model.
Isn't it interesting how computer-users at large seem to bounce back and forth between individual, autonomous systems and the mainframe paradigm big ble had in my school where you booted off a floppy and everything loaded across the network? What makes people do this?
- Sometimes you're the pidgeon, sometimes you're the statue.
I happen to be in the other 1%. If I could write multi-threaded applications that automatically distributed across a network of computers, I'd be very happy. Zero-effort solutions like this are the way of the future. Now, it doesn't necessarily have to be the OS that has all of these smarts - the compiler could take a big portion of that.
Anyway - good idea for us people who manage 20 machines and batch-process hours of work on them. But, for your average John Q. Citizen, totally useless.
Education is the silver bullet.
What do you mean "distributed operating system"? The purpose of an operating system is to be an abstraction between the hardware and software. Being distributed doesn't help this.
/. articles: "Where Are The Multimedia Personal Digital Portals"? "What's The Best Java To XML Empowerment Paradigm?"
I can think of two possible interpretations.
Network management You want to check diskspace on ALL your fileservers or create a user that can log in from anywhere or something else network-wide. There are products that handle all this stuff, although it's arguable whether a "distributed operating system" could do it better.
Seamless multi-processing You want to submit jobs to "the system" so that unrelated jobs can go fast and related jobs can go fast AND communicate easily. That's a worthy goal, but isn't a "distributed operating system" overkill? Wouldn't a job control system work just as well? Or even, if you don't mind spending the money, an SMP machine?
I suspect none of this is what the poster had in mind. Probably s/he (or Cliff) is just playing buzzword bingo with us. Watch for upcoming Ask
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Why not? I'm sure if the need came around the good folks working on the Linux kernel could come up with something.
RIght now we already have processing distributed over multiple processors. I guess what you're asking is complete distribution between two separate machines. Is this not what Beowulf (sp?) tries to do?
Either way, multiple shareloading over the internet should come around eventually (maybe this is more on subject). The only problem with this at this point is that sending bits and bytes back and forth over the net takes more time and CPU power than just doing it locally. It's kinda sci-fi right now. You know, Star Trek ships have two computer cores co-operating full time and a backup core. Hell, even the twenty year old space shuttle has two computers effectively working together.
So what's the question? =P
Whatever happened to Andrew Tanembaum's Amoeba? Didn't this have a concept of a transparent processor farm?
The question is unclear.
/bin to be distributed, those too are small and speed-critical. If you just want clustering for larger, less-frequent jobs, then you are back to the above solutions: LinuxNOW or Mosix.
If you just want better clustering, shared drives, that sort of stuff, check out Mosix or LinuxNOW, as many other people have already pointed out.
If you want the kernel or other fundamental, low-level parts of the operating system to be distributed, then you have a fundamentally bad idea. If you want the kernel to be distributed, you don't have a clue what you're talking about -- The kernel is designed to be low-level and small. It can't be distributed because it is inherently specific to the machine. It is also small enough that the performance loss in distributing it would be bad for time-critical kernel-space functions. If you want system commands like the shell and things in
--
Friends don't let friends misuse the subjunctive.
I can't believe that this discussion didn't start out with someone mentioning Amoeba. See "Modern Operating Systems" - Andrew Tanenbaum
Amoeba is to distributed OS as Mach is to microkernel OS.
Adam Beberg of distributed.net fame has been working hard on a distributed, encrypted system named Cosm.
Check it out here:
http://cosm.mithral.com/
signatures are for fools with hands
Well except that all the "SETI@home type programs out there" are NOT DISTRIBUTED COMPUTING. Those sorts of things are called "CLIENT/SERVER COMPUTING"... SETI clients talk to SETI servers, not each other. All of the nodes within the network form a tree, not a web.
Exactly what do you mean by "distributed"? What about the OS will make it "distributed"? I don't understand what you're asking... any multi-CPU system is already "distributed" -- even more so in cases where the CPUs are in different geographic locations (i.e. a trans-puter, or "cluster".) [And, Solaris has had this ability in it's "HA" versions for several years. I've seen it in use linking two E4500's 12 miles apart.]
Now, this isn't really applicable for an operating system. If you are dealing with just a UMP/SMP type system, then yes, since resources are shared, you can actually distribute parts of the actual operating system. However, with a true distributed system, resources are not shared.(in the real sense of the word)
So, it doesn't even make sense to distribute a process whose very purpose is resource management. What do you distribute? Memory management? I/O? It just isn't practical.
Now, you might instead think of a "Distributed" OS as one which features "plug and play" distribution. So, it might have infrastructure in place to handle distribution (fault tolerence, networking, etc.) However, this really comes back to the application level. Napster, etc are really no more than an infrastructure layer on top of the OS.
Now, you could probably start bundling these tools with the OS, however, can it really be said that the OS is "distributed"? For example, is "emacs" a part of the *nix operating system (good god, every emacs user everywhere hates me)(including myself)? It's just an incredibly useful "tool".
____________/\ ____________ \/
can we please stop using the term "AI"? Or at least put it in the same category as the word "paradigm": uninformed marketroid-speak.
if it ain't broke, then fix it 'till it is!
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
-Daniel
What we would need is a Seti@home type distribution scheme but with a scheduling scheme like a supercomputer.
Everyone would submit jobs to be excuted on the distributed machine and the central server would coordinate and pass out calculations to all the machines. This would be useful to everything from universities with idling (but powerful) workstations sitting in its labs to even places like NASA that occasionally need more computing power than they even have (Searching for a signal from Mars).
And btw, fortran SMP works rather well for beowulf type systems. Just code like normal, compile and run. -Kashent
To me, an OS manages the resources of a single machine. The job of allocating time and space seems like a minor computational task. Why would a distributed operating system be better? The decision of which user gets a block of a disk seems like a small computation task.
However when the computational need is large, ie rc5/seti/etc, then distribution becomes important. It looks like a user space issue, not an operating system issue.
A single distributed client could handle multiple tasks and be directed to work on different problems at different times in a distributed/cooperative manner. It looks like a user space problem.
How do you handle people who dont want to share there disk space or memory?
Maybe I misunderstand what a distributed operating system is.
You might want to check out "Distributed Operating Systems: Concepts and Design" by Pradeep Sinha.
It talks about Amoeba, the V-System (I couldn't find a good web page), and Chorus.
It's a textbook so it also has a lot of theory about general distributed OS's.
How about "Disturbed?"
SkyNet anyone?
Anxiously awaiting those HK's
jream
Before we go rewiring the whole frikin OSs. Let's try it in applications first!
http://sourceforge.net/project/?group_id=7829
From the Link:
"GnuSpace" is an advanced Gnutella client that let users share both files and computation time. Unlike Gnutella, GnuSpace combines thousands of PCs unused CPU power into one coherent power-source to fuel super services to benefit all.
This
I haven't seen anyone mention this. Isn't Linux NOW supposed to be a distributed version of linux which behaves like a single workstation, complete with migrating processes? I realize its not out yet, but it seems like its exactly what everyone wants (minus the AI)
Information wants Coq
Way offtopic, but:
Yeah, the really reason that C sucks is things like:
if( i = 4 )
DoFoobar;
else
ReportError();
Compile and run perfectly.
The cake is a pie
Having a distributed OS would take a great load off of distributed application developers. Currently, a distributed application has to be able to handle all the tasks that a normal operating system currently does. Not having a distributed operating system for distributed apps is like not having an OS for normal client apps.
Seti@Home has to be able to route all its necessary functions and information around its network. Why is that necessary? A distributed operating system should be able to handle the tasks of distribution for the applications. It's almost as if every distributed app developer has to re-invent the wheel every time he/she wants to create such an app.
You are already running a distributed application whenever you run a threaded application on a SMP box. Writing applications for a distributed operating system is no easier and no harder than this.
You _will_ have some programming overhead no matter what - by nature, a distributed application needs to have multiple pieces running concurrently, and so has to manage synchronization and communication between these parts.
The good news is that everyone already understands multiple processes and threads, so we already have a well-established programming model for it.
Now, in the real world, client/server computing will always tend to have an advantage for wide deployment, as you can run those on heterogenous platforms (a la SETI-at-home). For small deployment... you're looking at either a high-processor-count SMP machine or a cluster, depending on the degree of coupling, and those are already well-understood.
So, I'm a bit puzzled as to what you think needs to be developed. It looks like we have distributed computing already.
This is a really easy hack so perhaps you've
....
already seen it:
if( 4 = i )
will not compile but has the same semantics as
what you have. Get in the habit of putting making
the LHS something non-assignable.
Most decent compiliers will generate a warning when comiling this code. Besides, assignment and equality really are two seperate concepts.
really... microsoft is looking to phase out _*all*_ shrinkwrapped software in stores and move to a subsciption based service. ok, so not REALLY distributed - but here are it coming bugs^H^H^H^H er... features:
microsoft.net - online OS and apps services.
subscription/rental use.
all stored on a centralized set of hardware (centralized meaning that your account is in one location... there will be many hosting facilities holding many accoutns)
your environment will sit on the microsoft.net and you will just pay an additional $5/mo for office, $2 for frontpage etc....
then if you want to buy games - you buy/rent them and when you click - it will schedule an auto install onto your system.
then the future is that - microsoft has no middle men, they get all the $ for their products. they get to market this is the greatest INNOVATION in computing history - even better than the invention of computing itself. and all the stores and computer dealers can no longer sell MS products. (good and bad - many will go out of business - hopefully most will just sell linux on the boxes instead)
so - it will have a big impact on the high-tech economy, and it seems that it is M$' way of giving DOJ the finger with a message "See? See? See what happens when you screw with a company that is big enough to be able to change the course of the computing industry with one fell swoop."
we will see what will come of this - but be ready. gather your alternative OS' and get ready to fight.... I sure as hell will not let MS hold my OS and force me to rent it, and turn it off, corrupt or lose my data at any time (hotmail anyone?)
rant rant rant...
p.s. - its real - its in beta now!
-coyo
--------------------------------------------------
Sounds like a neat idea. I would guess the best part about this is if one guy can't access , the rest of the company/org/etc. can't either (in theory), but the bad parts seem to be too numerous for it to even work.
Example #1, you know how some users seem to royally screw up with no effort? Try those users on that system...
Example #2, those goofy problems that you have that don't seem important, and you can't track down, so you just format and forget? Try formatting an entire company and see how that flies. "Sir, we have to format your network" hehe
Example #3, instead of one user being down, possibly working on another station, EVERYONE is down. Not a pretty picture. Unless there was some way to hot-swap your Distributed OS Servers, I don't think it's feasable.
Actually, on the other hand, if you COULD hot-swap your DistOS, formatting and problem users wouldn't be a problem. You'd just have 2 ready backup hot-swap servers, and hot-swap away.
Sounds like it might work, but also like it might not.
Luv,
Brady
Sig missing. Reward.
Can somebody explain to me the actual purpose of a distributed OS? Wouldn't that just essentially screw over a whole bunch of people if one person "accidentally" removed a few necessary files? Like a distributed Windows, if the registry "suddenly" became corrupted, then everybody else would be in some hot water later when they wanted to do something.
Glen
Track your fuel economy
I think the answer depends a _lot_ on what you want this thing to do. I really don't think your basic web browser, text editor, shell, or even most programs really need the extra resources offered by a distributed computer. As computers get faster, this will only become more true. Thus it really only makes sense for compute-intensive programs, and many of those are of a nature that they can be broken down into large compute-time chunks that can be handed out in small bandwidth, like in SETI, the Prime Search, the RC5 stuff, and a few others. For many others, things like MOSIX or Beowulf are just fine. So, what is the intended application? Just as for different applications, different OS's are useful, so goes for distributed applications, only more so.
---
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
It was my impression from college that the main issues were complexity and the fact that it would be expected to span several different hardware architecutes, (meaning the memory manager is on a sparc, the scheduler is on a intel box, etc..) Are there any others?
What!? No witty quote?
... and thousands of PC's that run it. VBscript and Outlook are your friends.
Each has some somewhat different insights to bring to the table; there is no unambiguous way of saying "this is all vastly superior."
If you're not part of the solution, you're part of the precipitate.
Platform Computing has a product called LSF that runs on top of the operating system. It runs on Unix, Linux and NT. My impression of it is that it is a layer above the operating system that provides clustering, cpu/memory sharing between workstations, fail-over capabilities, dynamic allocation/deallocation of resources. http://www.platform.com
Sorry, cannot boot up OS, /boot timeout...
:)
V
From the What-do-you-mean-the-coffee-maker-stopped-respondi ng? dept.
/. full of caffeine-enhanced techno-addicts. The presence created the need.
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
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.
Blog,Twitter
If I recall correctly, Lucent (Bell Labs?) had a completely distrubted OS called Inferno. It used spare processor cycles and memory/drive resources from all hosts attached to the network; essentially turning the network into a server, it could account for shifts in usage and even rebuild data from hosts that were removed from the network (like RAID) I don't know what the current status of the project is now (that was about 2 years ago)
Yeah, I do that all the time, but people I have worked with in past lives haven't.
Often the problem isn't so much what you do, but what the original programmers of stuff your working on did.
The cake is a pie
I guess the question is what exactly you mean by distributed. At one extreme you could consider DOS a distributed OS if it is set up to use shared drives on another machine. At the other extreme, you could try to distribute even intimate bits of the OS, such as the MM, the dispatcher, etc. The question is what you're trying to achieve: increased performance, or just being able to do it? If it's performance, you have to look into maximizing the bandwidth of the OS entities that communicate the most, and whether it would even make sense to put them at the other end of a network connection. If you just want to do it because you can (e.g. X-Windows), anything goes. All you really need on any machine is the particular entity you're trying to distribute, some network communications capabilities along with a marshalling mechanism, and some glue to make all the distributed entities make sense of it all. Of course, this "glue" is going to be what keeps you up at night when designing this thing.
For a lot of applications, many of today's OSs can be considered distributed. Both CORBA and DCOM (or is it DNA nowadays?) provide mechanisms to abstract the location of a particular service, which in the end is what "distributed" really is all about, right? A lot of enterprise apps nowadays are quite highly distributed and often use OS capabilities to achieve that (certainly in the case of Windows).
In the end, the question is how highly you want to distribute the OS, and what the benefits and tradeoffs are. If you want to achieve smaller unit sizes, eventually the unit might be not powerful enough to do much useful work--like a Beowulf cluster of 386 machines. If you just want to make it fault tolerant, it might be worth it anyway. And so on...
Uwe Wolfgang Radu
If you're interested in learning about Distributed Operating System concepts, you could also check out medusa.
Things you think are in the Constitution, but are not.
2) Performance Benifits from Parallelism: distribute threads of execution across the global computational grid.
3) Share Resources Efficiently: don't waste those idel CPU cycles. Don't waste that extra main memory. This may be the least valid reason, as cpu cycles and memory have a big head start over bandwidth on the value vs. time scale. Moore's law has all of them getting exponentially cheaper over time, but right now bandwidth is the most valuable of the three.
4) Support a New Generation of Applications: Distributed operating systems can offer unique support for things like shared virtual environments, or widly distributed databases. It is a classic point of contention whether the distributed system services should be implemented on the application layer, or on some lower layer. However, I don't think anyone can argue that in terms of ease of application development, it is often very nice to have a really nice abstraction available on which to base your app.
"A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." -- Leslie Lamport
if (i = j)
t
Here are some OS's that I think are interesting. I'm not sure if these are the official sites or not...but they should be interesting to read about (actually, most of them are REALLY cool)
Interesting FAQ: comp.os.research FAQ
Chorus Distributed OS paper
The Amoeba Distributed OS (check out the papers... I think many of the links are broken
Microsofts Rialto OS
OS X has native support built in for disturbuted computing of all the os's functions... Think one giant super computer. Much like neXt OS. Only Better. Steve Jobs though smart.
brainchild out
Notice the paragraph break. It was 2 separate topics. Should I have posted twice? I think that that would really be a waste of time. So, I posted 2 topics in one post. I didn't mean for it to be interpretted that way. Perhaps I should have used better punctuation or something. I was saying, Suns, everyone is familiar with them. Then I was saying Plan 9, few people outside of academia are familiar with it.
Eh...
As far as writing a distributed kernel, I really don't see what the point would be, esp if we are talking microkernel.
Perhaps a distributed module layer, or distributed device drivers would be something to think about, but there are performance considerations.
Maybe distibuted plug-and-play: you install some hardware, the kernel detects it, and goes out and retrieves the latest driver for it.
I am very small, utmostly microscopic.
I have dreamed of something like this. Consider/assume that palm/wireless phone devices will be the future of computing. The concept is a thin OS kernal. Soon systems (to include client hardware) will have to be congruent to be trusted. Careful programming techniques to seperate non-related information from the kernal will be very importand and OS ROMs will be transperently updated. This will likely be called something like e-synetworkingX or something by marketing, and be called Hivemind OS by us geeks. Just my predictions.
Effendi
-Effendi
Both NeXTStep and Digital Unix were monolithic OSes, despite the association with Mach.
What you may be thinking of is that NeXTStep included a "distributed objects" scheme, lately being "cloned" as GDO (GNU Distributed Objects).
If you're not part of the solution, you're part of the precipitate.
Why do we want to go back to distributed processing/operating systems? We have gone down that road once before and regretted it with mainframes. I know it's not exactly the same situation, but it has many of the same drawbacks. If you share necessary elements of your OS, what if that system goes down? What if the machine you rely on becomes overtaxed. If you don't think it's possible, think again, as history has a way of repeating itself.
I think the problem with most distribued
operating systems today is that the langauges
used to build them were not designed with
threaded inter-operability in mind. Sure POSIX
has been standardized for years now, but is C
really a true threaded language?
Some distribued operating environments assert
that applications can run unmodified, but to
really take advantage of the large noded clusters
one must adapt the program for running in a
distributed environment.
Which brings me to my point. Java the
programming language / operating environment
darling of the Internet has really been living up
to its hype lately.
The language is maturing, development tools and
resources have reached a critical mass, the
libraries are stabilizing, more people have had
significant experience with it than not, etc.
What does this mean for distributed systems?
Everything. More languages like Java, multi-
threaded to the lowest levels (VM specification)
are going to be the stepping stone to the
distributed revolution. By providing multi-
threaded support in the language Java is enabling
the mass movement to the distributed systems of
the future with little to no headaches.
At a larger scale, and as others have rightly mentioned, Plan 9 is one of the first major rethinks of fundamental OS design policies and goals. Unix has at its roots assumptions buried in a single large timesharing/batch system, with networking and thus distributed behavior stapled on afterwards. To whet your appetite, the X Window System is fundamentally irrelevant in the Plan 9 environment, except for legacy code. It is safe to say that the Plan 9 papers are required reading for your goals. Note that this really doesn't get into kernel level design -- the Bell Labs team freely admits that the kernel (at least pre-Brazil) was fairly conventional in design.
Last but not least, don't fall into the trap of a Solution looking for a Problem. Don't try to use "AI" (no offense, but whatever the heck you mean by that -- it's so overbroad as be like saying "I'll solve it with Science!") when you don't even have a specific problem in the domain of distributed computing identified. Understand the real problems, which I'm guessing in your case are large-scale systems design and usability issues... THEN look for appropriate solutions.
Good luck!
Many of the important theoretic issues have been addressed at the nuts-and-bolts level by the Mozart Programming System. Specifically, if you read Distributed Programming in Mozart - A Tutorial Introduction you'll have an idea of the kind of distributed programming power provided by a network of Mozart systems.
The key to Mozart's power is its use of ultra-light-weight threads that can share single-assignment distributed variables within heirarchical computation spaces. What this means is you can have unlimited "processes" that are waiting on all sorts of things all over the network -- and failures are easily confined to the minimum logical spaces.
By "ultra-light-weight threads" I mean a virtual unification of process structure with data structure.
Seastead this.
I think it would be even cooler to have something that, given enough bandwidth, would transparently divide up processor time for a single thread/task.
How exactly do you propose that the operating system do this?
Unless the programmer or compiler parallelizes the code, you're out of luck for running it on more than one processor at a time. What is the OS supposed to do? Recompile it on the fly, adding all of the MT-safing, rebuild it, and hope that it's faster?
Unless an application is designed from the start to be parallel, it can't be run as a parallel program.
Seth
$5 / month hosted VPS on linux = awesome!
Hmm... ever hear of ThinClient? This is already here in a big way. Which is almost to bad becasue we all worked really hard to move away from a mainframe style of computing.
----------
while (alive) { Work(); PayTaxes(); Eat(); Sleep(); }
Bool
A computer working on a 3D render, for example, could pull the resources of an idling computer 50 miles away stuck in a screensaver. A company employee who has to perform the backup of 3000 files could cache some of them in a RAM monster in Cleveland.
Granted, the only issue that comes straight to the fold is security. With millions of file transactions taking place on a daily basis, it would become critical to make sure rogue users couldn't snoop on the contents of a file without permission.
Still, with a relatively secure operating system as a standard point (Linux, BSD, or even to some extent Windows 2000) it's possible this wouldn't even be an issue.
Add complex AI to the mix (such as monitoring what resources are most in need - RAM in a rendering circle of computers, bandwidth for streaming across a company wide system stuck in screensaver mode), and finally those wasted CPU cycles would be put to proper use. Not just in monitoring for alien life or searching for the cure to the flu, but speeding up all operations on computers in everyday life.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
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.
- 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.It appears to me that AT&T has pretty much come to a halt as far as the development. They have released a PL, but im convinced that is just to build up on the sucessor, Inferno, which has been sold to Vitanuova??? im not sure of the spelling though. a PL is available, yet no download, yet...personal license is $300.
will work for food
I post at +2. So 1 person modded it up. Also, by ubiquitous I meant in more than just the sense of the processing power. Which is what people generally think of when they think distributed computing. As for personal problems, it's really easy to knock on me as an AC. If you don't like me because I have a high karma, you're a rather immature person. I just enjoy talking on /. Earlier I had plenty modded down, and yet somehow, I didn't make a big fuss about it. Interesting how that is.
Eh...
I agree that computer cycles should not be wasted, but Transmeta has answered that gap. If you don't need cycles, turn the computer "off".
The only real advantage to do distributed computing is the huge number of available computer power. If you want that however, you need a simple problem that is hard to solve and has a simple (read: small in size) answer. Otherwise the communication is going to be a problem. I don't think that that is always the problem.
nosig today
> If you want the kernel or other fundamental,
> low-level parts of the operating system to be
> distributed, then you have a fundamentally
> bad idea.
Not so. Take the virtual memory system. If you
allow the backing store for the memory system to
be distributed you get some totally reasonable benifits. Say you have 20 nice suns all sitting
around connected with 100Mb or 1Gb connections. Gaining access to their RAM via the network is way faster than going to disk. So you can effectively
increase the size of your 'physical' main memory with minimal speed penalty. Of course you have to do things like keep copies of the blocks locally on disk in case of network failure, and you only want to use other machines memory in certain classes of blocks and such. But it does offer gains, I read a paper about this stuff a while back. Pretty sweet, check it out.
You can say that C is unclear and hard to learn, but it is not to blame for this error, just like it's the user's fault for typing rm -rf / as root in Unix.
--
I've set up a distributed system where I can absorb some of your load by hosting your /etc/passwd and /etc/shadow files via NFS. This can result in as much as a 0.003% performance boost on your machine. E-mail me if interested.
- My password is slashdot
Load balancing? Easy to write, hard to make work well. You need to compare the cost of migration to the benefits of balancing, and you need to make decisions based on partial and outdated information. Many early systems thrashed because everybody would migrate to the idle processor, which then became overloaded, so everybody migrated somewhere else, etc.
Speaking of migration, it's a mess. The only system I know of that implemented migration fully was Locus, out of UCLA. The trouble is that whenever a process has a dependency on or a hook into its environment, that connection must be migrated too. Open files, working directory, sockets, controlling tty, signals, process parent/child relationships, and many more details must be handled. Not fun, and the benefits turned out to be mostly minor (though I do recall writing a cool version of "find" that migrated itself to the machine that stored the current subtree as it ran).
The issue of supporting distributed applications is generally considered to be separate from writing a truly distributed OS. Most of what a distributed application needs can be provided by a good communications library. To some extent, we're still learning exactly what such a library should have. What about SETI@home is specialized to it, and what's universal? I don't think we've completely figured it out.
The following is a non-exhaustive list of major concerns and design issues that must be addressed in a distributed OS. We have fairly good solutions to some, but most have not yet been solved:
Finally, I should note that the list of projects at U of Arizona might appear to be complete, but it omits a lot of important projects. Four that jump to my mind are Locus and Ficus from UCLA (though the latter is more of a distributed filesystem than an OS), Coda from CMU (again a DFS, rather well-known to Linux folks), and of course the extremely important Network of Workstations work out of UC Berkeley, which led to Inktomi and Hotbot.
Instead of writing new operating systems that virtually nobody is going to install, it would be far simpler and more cost-effective to simply develop a Distributed Processing API Library and/or supporting system services for existing operating systems that are capable of handling it. Like that MOSIX project.
Obviously most Unices fall into the boat, as would Java-based environments, but you could probably even do it on NT if you were really desperate.
Of course, your really big-ass gov/mil/edu houses may not be too concerned about the cost :-)
Seems like the Java platform would be the best way to get this kind of thing to the masses, nearly everyone has some kind of Java Runtime Environment installed, and not many non-techies are going to want to mess around with their kernel.
Go on, you know you want to:
CLICK HERE TO ENSLAVE YOUR COMPUTER IN THE BORG COLLECTIVE
--
NO TOUCH MONKEY!
When I was an Undergrad at WPI (www.wpi.edu - I was only there 1 year, school life didn't work out) I heard of such a thing. Evidently there was an ongoing research project there to develop just such an OS.
The idea was that all machines running it (and I assume all ones running it AND setup as part of the same group - though personally I like the idea of a singal global distributed system with no boundaries) would be able to use eachothers resources over the network for the applications they were running.
Im not sure HOW distributed it was but it sounded cool. It must have a web page, I wish I could remember the name of the project.
Personally, I always kind of wanted to write a layer on top of the beowulf stuff. Setup the cluster and then make a shell that ran on it.
Really though, the more I think about it, the less I think its needed. How much do most things that are done on a system benefit from paralelism?
It seems to me like this type of problem solution is best suited to large computations and basically large jobs more than normal OS use.
"I opened my eyes, and everything went dark again"
I checked out the NOW thing, and it looks good, but the next big step I see is loosening the centralized authority and control aspects of something like NOW, and allowing machines to join and detach at will.
As NOW stands (as I understand it), all the machines in the cluster are fully trusted.
For a looser version, each node will have to have some kind of trust level.
A concept like this would require lots of changes to a unix type enviornment.
For instance, the idea of a ps showing all the processes is going to have to change. You don't want a non-trusted node to get knowledge it shouldn't have.
This type of env will make system security a much more tricky thing, but, hey, what the hell.
I had lots of other ideas, but they seem to be running away from me right now, so maybe more later.
>So instead my program runs fine then randomly crashes at the aforementioned line on code on some machines.
>Since then I have promised myself never to do any serious development in C if I can help it.
That is why you modularize your code and perform unit testing.. This sort of error will prevail in any sort of language. For a given language, there will always be problems that have complex solutions. At this point, you have to apply good programming practices and a bit of software engineering.
That a language such as Java or Pascal alleviates many types of programming errors is good, but there are just as many minuses to these languages. It's an engineering decision as to which language is best suited for a given set of problems and developers.
Personally I use Perl, but that's even more error-prone than C (with the exception of core dumps). Good coding practices are essential for this. (The benifit, of course, is rapid development time)
-Michael
NeXTSTEP had a number of features that people mistakenly took for a distributed OS, the way that many people assume that any GUI has an OO substrate.
It was the case in NeXTSTEP, that you could log in to any NeXT machine on your LAN, and your home directory (including your preferences like audio volume, etc.) would follow you around.
NeXTSTEP is also the OS where Zilla was developed (Zilla was the program that BeoWulf was copied from.) Richard Crandall developed Zilla, and used it to find the 13th Fermat number, among other supercomputing achievements, on the idle machines at NeXT's headquarters.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Distributed OS? Get a grip. Every OS in the world is already "distributed". The problem here is that people typically think that a PC has only 1 processor, when this is not the case. A PC is actually a collection of smaller computers: - most hard drives have their own CPU and RAM, which qualifies them as small embedded computers. - most video cards have extremely powerful CPUs and gobs of RAM. I'm not even going to get into printer hardware. Whether the OS is interfacing to all these processors via hardware bus architectures or over TCP/IP is pretty irrelevant. There is still a lot of inter-processor communication going on within a single PC. To me, that qualifies every OS in the world as a "distributed OS".
Considering distributed computing being close to "complete", mature subject is extremely naive. Unless one has very strange idea of "Distributed OS" functions, like easily, statically partitionable CPU-intensive problems, running on completely trustable systems, with perfectly working networking, and so on, one must realise that most of the stuff on this field is practically unresearched.
Some of the unsolved and rather untrivial issues that come to my mind are:
How problems are dynamically partitioned dynamically between nodes? There are issues of profiling, communications bandwidth, synchronisation, asymmetric performance, and more. Purely functional programming makes some of these problems easier to figure out, but there's no silver bullet.
How the system is made seem as much as possible as if it were single system, without sacrificing too much performance in a way or another? Machine independent program representation is must for a platform-neutral system, but avoiding virtual machines is very preferable. Proof-carrying code may make this feasible, security- and performance-wise. Transparent migration must also be considered; that isn't totally trivial when systems run on different base architectures. Otherwise making perfectly working system transparent is not hard, but making it efficient is highly related to successful partitioning.
How to cope with unstable computing environment? On normal computing environment, malfunctioning storage, transmission and computing hardware is so untolerable that problem is practically ignored. With widely distributed computing environments, one must compromise between increased performance in perfect case and loss of performance when some essential resource becomes unreachable. There's certainly no magical solution to this problem.
How to manage security and protection in potentially uncooperative environment? How to make sure owned computing capacity is given only those who are granted to use it? How to make sure someone isn't actually returning fake results for critical computations? How to make sure nobody can steal your information, results, or algorithms? These all are theoretically only compromises between safety and performance, but in practice, hard problems to solve feasibly. I'm very interested to see research results on this.
And one more thing. Avoid using "AI" as a proposed solution if you can. One cynical definition of AI is that "it's something we can't make yet." When first programming languages were developed, just being able to parse programming language automatically (based on the syntax definition) was considered AI. Do you consider that AI these days? Always try to find more concrete term; if you don't, either you're underinformed, or there's some research to do.
I have truly great hopes for distributed computing and OSes, but I see it more like a topic of a lifetime than a "Let's hack Linux to do this!" issue.
The best you can hope for is that some day compilers will be really smart and parallelize things for you, but even then the effect would be very limited, I'd think.
You can do this fairly easily for certain types of loop. It would be a straightforward extension of loop unrolling. Now, I don't think anyone's been insane enough to _do_ this to date, as the thread creation overhead would eat the speed gain for anything except a very long-running loop.
Something like TransMeta's code morphing that profiles on the fly could in principle figure out where it's sensible to do this, but speed gains would be questionable except in very special cases.
Teach people to use this shit enough that they can invent it themselves. Open it up to a variety of users.
Do that and the scale of some of this tech compared to the most efficient way of doing a task is going to scare you.
The message on the other side of this sig is false.
I believe this is what Ian Murdock's Progeny Linux is working on. They are working on a system based on Debian to turn a network of workstations into a seemless system. Interview questions about this for Ian were posted on /. just last week.
----
"Oh, bother," said Pooh, as he hid Piglet's mangled corpse.
Hasn't been under the auspices of AT&T since the trivestiture. It was a Bell Labs research project. And Bell Labs went with Lucent.
Lottery: a tax on those bad at math.
Okay, this is what I thought would be cool after reading the "Natural Language CLI" story a couple days ago - each person's machine would have a bunch of rules like "remove is a verb which means rm when referring to files" "delete is a synonym for remove" etc, and a simple system for adding rules. As you add rules to your system, your system contact other systems out there and sees if your rules have anything in common with other peoples'. If it finds a system which is customized like yours, it can import a bunch of rules (or you can set it to import only rules it finds on X number of other systems).
Just a thought - anybody see any use for this? -Eje
Wouldn't one use for a distributed operating system be in artificial intelligence - especially for neural nets?
Aggregating the processor cycles and memory to facilitate massively parrallel processing - giving access to the level of computation required for artificial intelligence?
James
The Ameba OS was a complete distributed OS. It featured distributed disk space, memory, and processor.
The interesting part is that Legion provides tools that resemble some parts of CORBA, whilst Spring provided tools that grew into CORBA, whilst Sprite provided journalling and cache tools that are essentially what journalling and cache servers provide today.
In a sense, what has happened is that an OS of the 1970s, Unix, has been shown sufficiently malleable that it could integrate in concepts from the research projects of the 1970s and 1980s.
Unfortunately, the 1990s were not a terribly good time for OS research; sort of like The Very Long Night of Londo Mollari of the OS world. There was this minor problem of Microsoft "buying away" whatever serious OS researchers that they could...
If you're not part of the solution, you're part of the precipitate.
All a distrubuted OS does is make a cluster more managable, just an OS make the disparate parts of your PC manageable. But it all only works if your problem domain is suitable to being broken up in a parellel manner and communications between the nodes is adequate for your problem. If you are breeding a flock/herd/whatever of geneitic algorithms mosix is probably the best choice because the algorithms only need to interact to mate and cull. PVM is best where there is a greater need for interprocess communication, MPI is less friendly in so far as it doesn't give you the virtual machine but it can apply greater rigor and is a standard parellel programing enviroment. This isn't to say that a combination of mosix and PVM can't be used, they can. Some other things to look at are shrimp. Currently one size doesn't fit all because different problems create different demands on the infrastructure. Does the solution need much IPC, how big are these messages? Ethernet is usually involved in cheap clusters it should be seen as a slow bus that can carry large messages.
There was a document on microsoft.research.com about binary recompilation of existing code on the fly to addapt it to a constantly changing distributed environment.
:-P
They atleast claimed that they were able to run applications designed for one machine on multiple machines. I do relize this probably means highly-threaded well designed applications that normaly run on one machine, but still it's pretty cool. It's a pity I cant give a link to the document as research.microsoft.com aint responding
--typo
seems youall left out the most obvious one, and the one most likely to succeed: taos' elate! this is the platform amiga has adopted. granted that they currently run it hosted on linux, but that wont be typically neccessary for running native amiga/elate programs once they are developed. of course elate as a stand alone os isn't as mature as linux for running on standard pcs, but elate makes a greate embedded os.
:T:R:A:N:S:
Who needs AI research when you have Harvard Business School?
Yes, it's true, folks. We already have the Sci-Fi scenario at hand. Corporations are organic beings that operate on a very simple set of rules. The only problem is that we can't turn them off -- they'll just keep going until they've consumed all the planet's resources. Then they'll use people as a power source. We'll all be "coppertops".
I would suggest that we seriously look at eradicating these beasts before they kill us all.
__________________________________________________
Matter of fact, anyone designing or implementing a large system using multiple machines and lots of IPC should read this book too. In particular, the four basic rules listed in the introduction (pg 35 from memory) covering global data, time etc should be memorized by anyone working on any distributed or network application (including OSes)
Cray does a good job of a psuedo-distributed operating environment. Depends on if you count a processor+memory node as independent.
Check it out.
My appologies for the previous empty post...
The University of Washington CSE department worked on a distributed memory system. The idea was to efficiently use all the excess fragments of ram across a cluster of high performance machines on a high performance network. Called GMS
http://www.cs.washington.edu/homes/lev y/gms/
(\(\
(^.^)
(")")
*beware the cute-bunny virus
Another project that is interested in performance prediction is the Network Weather Service (NWS). An important issue in systems such as RPS (my system) and NWS is accurate and scalable measurement of hosts and networks. Remos is able to do this.
A lot of work in this area is taking place in the context of Computational Grids. The Grid Forum is an IETF-like body that is trying to standardize Grid middleware systems. Globus and Legion are examples of Grid middleware systems.
Well, Im personally a anxious in the free Inferno, its not in publicly downloadable, yet. I've been scouting www.vitanuova.com for a while, watching, waiting. I haven't been able to convince the VP's at my office to shell out $1000, and I dont go to school anymore...that leaves me with a 'Personal Edition' which would run me about $150. Pretty steep price on something Bell-Labs dropped. Im still interested.. the slogan is 'Picking up where Unix left off'
will work for food
People seem to beleive that .net from MS is a new operatingsystem. It's not.
.NET framewrok has nothing to do with operatingsystems or anything else. .NET is a development framework. .NET, which will feature C#, ASP+ etc. To build serverside applications and websites.
/. in their linux loving frenzy, just blurts out one comment after another without looking into the things they are talking about. I find this odd, since most of /. users are pretty knowledgeble people, who know a great deal about many things. But in their linux loving frenzy, they just don't look into the MS products before expressing themself which amounts to a bunch of unusable comments with little basis in facts.
The new
This will result in new products such as Visual Studio
It's not a new windows.
MS though has plans on offering Windows, Office and other apps, over the internet at some point, but this isn't going to happen in the next few years. And they will still be offering a bormal off the shelf version of Windows to install on your local machine.
Anyway...They can't just send windows from the internet to you without you having installed an OS first, which has the capabillity of accessing the internet.
It's really anoying at times, how people on
.Net is NOT an OS, but a new development framework, which will bring a new version of ASP to the masses, called ASP+.
ASP+, has some VERY interesting new things, which (when released), will surpass ANY other webrelated langauge, being that PHP, Perl, Python, Tcl/Tk etc. It's actually a EXCELLENT product from MS.
That's why Algol uses := for assignment. ;)
OT: I wish languages would allow if 0 = x = 1 expressions. Something about conditionals and booleans being different concepts (?)
Bah. Plain text eats less-than signs.
if 0 <= x <= 1
Yes, I'll agree to that. Anyway, part of the development methodology of a professional coder is a "peer review". This means others examine your code for this kind of thing.
Anyone who is a professional coder and does not write module test code *AND* participate in peer review is cheating both themselves and their employer.
This becomes more and more critical as the scale and complexity of the software increases. - Oh yes - I mean all languages, not just C
Anyway, a little teeny tiny effort and of course comprehension is necessary to find out about Condor and Globus. Condor utilizes idle workstation resources for parallel applications. Kind of like PVM or MPI, but designed for clusters of workstations. It provides a mechanism to link several computers together. Globus, built on Nexus, it is a GPL system that runs on just about any grid (such as what Condor/MPI/PVM can be). It provides a consistent API and is useful for much more than standard parallel work. It is still being developed, but you can get the tools and server stuff.
Most people around here including the asker of the question obviously don't know a parallel app from Microsoft Word. I see this alot. "I will run SETI in parallel!" Huh? Not exactly.
I'll explain... I am all for running process independent stuff by rsh script, but it is not a true use of distribution. That is the whole point. SETI is allocated chunks of non-dependent data out to systems. You then send back results, no messaging. It is simplicity and not a multipurpose distributed system. It is pre-distributed and requires only a yes or no result. This is fine and great for embarassingly parallel applications such as number searches. Your adding more monkeys on typewriters, but they're only monkeys.
Real message passing like that of a Beowulf class server is when there is boundary data required between processes. One computer changes a row on a matrix that row is the boundary so it must send the process it shares the boundary with the updated row. This is usually the real crap, what people buy 100's of nodes to do. See MPI and PVM. These programs must be explicitly written in parallel to be efficient and utilize parallel code structures. They are built on top of message passing libraries (MPI/PVM) that are pre-ported to systems.
It is important to note PVM/MPI can be used to reclaim idle workstation time, it is just inefficient at it and will piss people off. However, a proper queueing system set to run at night could be utilized.
Systems like Mosix are OK and they exist now. They give you use of a network of linux workstations with process migration. However, it is very low level and will remain so since it works on x86 process explicitly. It also must have non-I/O bound process to export or it will be limited in utilization. A great project they are working on is the utilization of the networks memory space for large processes. If you ran a 2000x2000 matrix you could solve it using just plain Matlab and 4 256MB systems. It distributes the process state to where the data is. Mosix also is quite useful in dynamic scheduling. PVM and MPI both have very limited use of dynamic scheduling, but thanks to Mosix's peer to peer load balancing it can be utilized as a dynamic scheduler. PVM and MPI issue static process allocation to the nodes, as usage fluxes (finished or waiting process nodes) Mosix can move loads to increase efficiency.
Condor is used on groups of workstations and is heterogenous (NT is getting a port). You can build parallel apps for it just like MPI or PVM, it uses other technologies than them however.
Now Globus, Globus is a huge project utilizing a message passing/thread library called Nexus it can run on any grid. That grid then will connect to other distributed grid resources across the net. The user is presented with a web interface and a secure login. They upload the program and request an allocation of resources. They get the results back when done. It uses whatever servers are availible and can use explicit parallelism through the thread library to make it faster. It is for all purposes a worldwide supercomputer. It goes beyond this to also share all data resources available to the system by database through its directory system. This system allows anyone to join, but you have to be allowed to use other peoples resources.
So if you seriously are thinking about playing with this stuff, figure a real use, figure how much power usage you will be using (NODESx250W 24x7 can be quite a power bill). Then decide what parallel system PVM/MPI/Mosix/Condor you want to use. If you have a whole department of computers Condor might be good, if you have a specific parallel app and a few non-workstation nodes use pvm/mpi. If you run lots of processes or have lots of people logging on, Mosix code be useful. Also, Mosix on MPI/PVM would give probably an efficient cluster. Then you could submit it to Globus so others could utilize it. However, it sounds rather elitest and probably won't use two P133s when they got Cray T3Ds. Also, don't think about actually using Globus yourself. Hey, I guess it would be just about like SETI and others. You could be helping science or at least some grad-student piddle around.
Erlang (developped by the Swedish telecom company Ericsson) is an Open Source distributed operating system that runs on top of a host OS such as Unix or MS Windows. Erlang is based on high-level language paradigms, which makes it refreshingly different from all these C-based OSes. I think it deserves to be better known.
For a rather comprehensive list of operating systems, check out the OS review subproject of the Tunes project. Of course, since Tunes is The Ultimate OS, it is distributed also (its only disadvantage is that it (currently?) doesn't exist).
isn't linux NOW supposed to become an distribuded OS? http://slashdot.org/article.pl?sid=00/07/27/152623 6&mode=thread "Linux NOW makes a network of workstations look like a single integrated system" http://www.progenylinux.com/
There are lots of distributed OSs out there, MACH, AMOEBA, SPRITE, Plan 9, CHORUS, etc. and more recently we've had cluster computers such as Beowulf joining the fray. However using "AI" to do even basic load balancing is problematic. Oxford Brookes are trying to do this using a mobile ganets model, but it does not look promising - most other people are sensibly staying well clear of it.
Where distributed computing and AI will make an impact on peoples life is that distributed computing gives potentially much more compute power to a program and AI is *very* compute intensive for real world tasks. Imagine the ability to do real time summarisation and decent semantic analysis of the web pages returned by your search engine so it is much more readily apparent which ones are interesting, imagine a game of quake where each bot has it's own computer controlling it, imagine the ability to do proper knowledge management on your documents, there's even a possibility that the paperclip might say something useful! These are all things that can be done with the current level of AI technology, but not in anything like real time. With distributed computing (and lots of tweaking of the algorithms) we can try to reach real time response.
TTFN
Faye
It is based on atomically transactions and distributed shared memory.
More information can be found at the Plurix Website - but not really up to date :-(
plim-plam-plompudding
Yes, that was the point he was making. Writing distributed apps for a distributed operating system is not hard, because the job of the distributed OS is to give you the illusion of a single machine. Without this abstraction, writing distributed apps is hard. You have to consider a lot more than synchronisation and concurrency. For example, one of the nodes in the system may go down while others carry on working. How do you ascertain the state of all the shared objects it was using? One of the nodes may be cracked or there may be eavesdroppers on the network. Even the problems of synchronisation and concurrency are a lot harder than they are on a single machine. You can't pass pointers between cooperating threads - they may be running in different address spaces. Changes made to a shared data structure may take time to propagate to other nodes. There are no atomic lock operations (messages take time to propagate). Etc etc.
So, I'm a bit puzzled as to what you think needs to be developed. It looks like we have distributed computing already.
This is like saying we have software already. Look, my hard disk's full of the stuff! Why do you think this means there is no room for improvement?
You and me.. what does that mean?
Always.. what does that mean?