Messages in this thread | | | Date | Wed, 3 Sep 2003 17:49:43 -0700 | From | Larry McVoy <> | Subject | Re: Scaling noise |
| |
On Wed, Sep 03, 2003 at 08:50:46AM -0700, Martin J. Bligh wrote: > > Err, when did I ever say it wasn't SSI? If you look at what I said it's > > clearly SSI. Unified process, device, file, and memory namespaces. > > I think it was the bit when you suggested using bitkeeper to sync multiple > /etc/passwd files when I really switched off ... perhaps you were just > joking ;-) Perhaps we just had a massive communication disconnect.
I wasn't joking, but that has nothing to do with clusters. The BK license has a "single user is free" mode because I wanted very much to allow distros to use BK to control their /etc files. It would be amazingly useful if you could do an upgrade and merge your config changes with their config changes. Instead we're still in the 80's in terms of config files.
By the way, I could care less if it were BK, CVS, SVN, SCCS, RCS, whatever. The config files need to be under version control and you need to be able to merge in your changes. BK is what I'd like because I understand it and know it would work, but it's not a BK thing at all, I'd happily do work on RCS or whatever to make this happen. It's just amazingly painful that these files aren't under version control, it's stupid, there is an obviously better answer and the distros aren't seeing it. Bummer.
But this has nothing to do with clusters.
> > I'm pretty sure people were so eager to argue with my lovely personality > > that they never bothered to understand the architecture. It's _always_ > > been SSI. I have slides going back at least 4 years that state this: > > > > http://www.bitmover.com/talks/smp-clusters > > http://www.bitmover.com/talks/cliq > > I can go back and re-read them, if I misread them last time than I apologise. > I've also shifted perspectives on SSI clusters somewhat over the last year. > Yes, if it's SSI, I'd agree for the most part ... once it's implemented ;-)
Cool!
> I'd rather start with everything separate (one OS instance per node), and > bind things back together, than split everything up. However, I'm really > not sure how feasible it is until we actually have something that works.
I'm in 100% agreement. It's much better to have a bunch of OS's and pull them together than have one and try and pry it apart.
> I have a rough plan of how to go about it mapped out, in small steps that > might be useful by themselves. It's a lot of fairly complex hard work ;-)
I've spent quite a bit of time thinking about this and if it started going anywhere it would be easy for you to tell me to put up or shut up. I'd be happy to do some real work on this. Maybe it would just be doing the architecture stuff but I strongly suspect there are few people out there masochistic enough to make controlling tty semantics work properly in this environment. I don't want to do it, I'd love someone else to do it, but if noone steps up to the bat I will. I did all the POSIX crud in SunOS, I understand the issues, I can do it here and it is part of the least fun work so if I'm pushing the model I should be willing to put some work into the non fun part.
The VM work is a lot more fun, I'd like to play there but I suspect that if we got rolling there are far more talented people who would push me aside. That's cool, the best people should do the work. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |