Operating Systems of the Future 436
An anonymous reader writes: "'Imagine computers in a group providing disk storage for their users, transparently swapping files and optimizing their collective performance, all with no central administration.' Computerworld is predicting that over the next 10 years, operating systems will become highly distributed and 'self-healing,' and they'll collaborate with applications, making application programmers' jobs easier."
Amoeba (Score:5, Informative)
As long as... (Score:5, Informative)
Grumble, grumble...
Freenet (Score:2, Informative)
These guys already do alot of that... (Score:1, Informative)
Links provided (Score:3, Informative)
Butler Lampson [microsoft.com], for papers on Byzantine reliability, mostly based on the work of
Leslie Lamport [microsoft.com]
Re:Mod Me Down If I'm Wrong..... (Score:3, Informative)
http://www.computerworld.com/computerworld/records /images/story/Farsite.gif [computerworld.com]
Was it just me or does the notion of a "Centralized file server" NOT sound like distributed computing to you?
Not being in possesion of any moderator points I am forced to respond to your comment....
If you were to have read the caption on the image, you would see that it says Logically: a centralized file server, but then it goes on to say Physically distributed among clients.
Re:Futurists are stupid (Score:2, Informative)
Re:OS's will be so smart in 10 years..... (Score:2, Informative)
Actually, they already invented that with W2k.. if you khappen to be on a coffee break while it crashes and don't pay attention whether you are doing a login or a unlock, then you might be surprised to a fresh desktop just when you thought there was too many apps anyway..
Re:Scalability problems, anyone? (Score:5, Informative)
That's why it's research. I've met and talked to Bill Bolosky (Farsite project lead); he's very clueful wrt scalability in general, and well aware of the problems that networks like Gnutella (an unusually naive protocol, BTW) have run into. However, like the folks working on OceanStore [berkeley.edu] or CFS [mit.edu] or many other projects, the Farsite folks have a fairly formidable arsenal of innovative techniques they can apply to the problem. The details are still being worked out, of course, because that's what research is all about, but the people working in this area do seem to be making real progress toward solutions that could scale to such levels.
Re:Mod Me Down If I'm Wrong..... (Score:4, Informative)
The first statement above makes perfect sense if you consider the second as axiomatic. However, the people working on these types of systems don't accept that axiom. Instead, they believe that cryptography-based security is just as strong as physical security...the odds that someone will factor a couple of hundred-digit numbers (or accomplish some equally difficult mathematical feat) are no higher than that they'll break into your home/office and steal your hardware. If they're right then there should be no problem with storing your files on some Iowa farmhand's computer (so long as you also have other replicas elsewhere for availability purposes), because Iowa Farmboy still can't access or modify your data without the right keys.
That's a big "if" you say. Well, yes it is. But if you want to make an argument that hardware security is the only real security, you'll need to show that cryptographically based systems aren't as secure as skilled and experienced implementors of such systems seem to think. Good luck.
Re:Amoeba (Score:1, Informative)
Re:Futurists are stupid (Score:2, Informative)
Really? Please tell me how to break down:
"Why are we here?", or "I think I love her", or "He died last week"
into a sufficient granularity to be implemented in C, of course with the full semantic connotations involved. There's a huge difference between a formally defined language and a natural language. That's why NLP is so damn hard.
As far as computers programming themselves, well... a c/c++ compiler translating c/c++ code into machine code isn't the same thing. Translation *is* a necessary step, but you also have to add the ability to change the running program. For that you need a language that blurs the distinction between data and instructions.
Re:Futurists are stupid (Score:2, Informative)
I'd like to see it (Score:2, Informative)
Mosix does a pretty good job of balancing processing time, but won't split tasks that require shared memory, sockets, and is not fine grained enough to put threads on different machines. It also requires a simular kernel to run on all of the machines. But I run it now because it is the closest we have. I think it may catch on.
For distributed disk sharing, the closest we could find was Coda, although it has a few disadvantages also. You can't have very large volumes, its difficult to configure, it takes painfuly earned experience to use efficiently.
Mosix has its MFS, which gives everyone a shot at everyone's disk drive. This is an interesting possibility also, however it is not configurable. You can't lay the volumes down where you want them to be. It could be used.
But then, we could partitian available disk space to large network raids with network devices. GFS I believe works along this principle. Lower layered than Coda, but without the caching that I think lets the system work efficiently over the network.
I guess the funny thing is that I use and consider them them inspite of the challenges. Kind of like Linux in the 1.2.13 days. Ahh the good ol' days when "Hey we finaly got X working" would bring a round of congradulations from lab. "Oh no, the mouse doesn't work" would only mean we'd be happy to fumble around for another few hours with faith that it would eventually work, if we changed something somewhere.
Hey wait a minute. You know, maybe linux isn't dead like some have said. Maybe there is still software frontier to cover and being covered that we can download/compile and enjoy....
(Although I have yet to get a workable EROS kernel doing anything useful...)
This was being done in 1968 (Score:2, Informative)
I believe that it also used an intresting mechanism in which resource requests were allocated using an auction like mechanism - if one of the boxes needed to spawn a process it would put out an RFP and machines willing to undertake the job would offer bids with costs. A second committment phase bound the offer to the bid.
All this in the late 1960's.
Eros's features for keeping EB to a minimum (Score:3, Informative)
in eros everything is orthogonally persistant meaning that every object, without doing anything on its own, has it's state saved by the system.
the other neat feature that makes it more reliable even in the face of bad application level code is that instead of access list based security ala unix, there are fine grained permissions called capabilites that govern what any object may do to any other.
these features coupled with transparent distribution could guarantee that even if the terminal in front of you is struck by lightning you'll be able to move to the nearest working one and pick up *exactly* where you left off!
check it out- there are a lot of kewl os level ideas that could make life better if adopted by more mainstream oses.
Re:VMS (Score:2, Informative)