On 4/21/2016 12:01 PM, Mike Small wrote: > I'm thinking from the perspective of a person writing a program more > than an end user. It's easy to abstract details from a user (though > whether the result is completely palatable without them buying new > computers often may be in question). What would be interesting would be > to write to an operating system interface and have the system > transparently migrate processes by various criteria, do redundancy for > failure and load, etc. etc and have it accessible by friends and family > or for it to get popular and scale nicely without further work or too > high a cost.
That sounds great. There's just one problem: it doesn't work. Have you ever managed a highly available cluster? If you have then chances are you've done rolling upgrades across the cluster: migrate everything off of one node, upgrade it, test it, add it back, move on to the next. You can't do this in an SSI cluster. All nodes must be running the same patch levels and feature sets because it's one single operating system. You have to take the whole thing down, upgrade all of the nodes en masse, and start it back up again. There may be a solution to this but none of the big SSI players ever figured it out (that I know of). This is just one of the very hard problems that have prevented the widespread adoption of SSI. Another is how programs are written. Programs must be designed such that multiple instances of themselves can run on monolithic architectures. Sounds simple? It's not. Take Apache (the web server) for example. How do you get two different instances of Apache with different configurations, different sets of modules, different everything, running on one host? Now scale that to any number of instances. That's just a taste of how hard it is to use SSI as a general purpose computing tool. -- Rich P. _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
