[Discuss] Whence distributed operating systems?

[smallm at sdf.org (Mike Small)]

Hmmm. I guess I meant single system image more in the sense of an
extension of the research work done in the 80s (and nineties a little?)
in the sense of there being a real network operating
system. i.e. something picking up from where Chorus or Amoeba left
off. (I haven't used these systems only read a little about them in
Tanenbaum's Distributed Operating Systems book.) If you'll allow me to
be a bit obnoxious, i.e. single system image not bundled together from
what we had combined with the requisite amount of bubble gum and baling
wire.

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. Then supposing the application writer is curious about how
all that works, it would be further interesting for him to be able to
read a nice book by Andrew Tanenbaum and, if not read all the code, at
least learn the next layer of abstractions and have it be somewhat
elegant, or at lease not something to make him slam the unscrewed panel
down in horror and paint a radioactive sign upon it. Further it would be
nice if reading said book helped supplement the application developer's
mental model in a way that makes writing programs more satisfying and
the resulting programs run yet better.

I guess I'm hoping for a new system programming hobbiest and follow on
entrepreneurs and a new inflection point for the industry. Something
feels deeply wrong about where we are right now, to the degree I get the
gist of it. Ditto twice over for this whole problem of the web browser
as client application delivery mechanism and defacto operating
system. If new Linuses come along whose design will they snarf?

Jack Coats <jack at coats.org> writes:

> [1:text/plain Hide]
>
> In many ways, we do have a single system signon, with a 'single system
> image' for well developed systems today.
>
> This is not true for everything, but within many companies web presence,
> the user (who we are in in business to support, right?) sees a 'single
> system image', whether it is implemented on a single system or a complex
> system or a 'cloud' (basically an obscured set of cooperating systems).
>
> Most often we just ask for users to sign in once to access all aspects of
> their 'user experience', even if the systems do re-authorization behind the
> curtains.
>
> For supporting the systems that provide this illusion to the users, we are
> still lacking on making that as smooth as it needs to be eventually.
>
> The cost of computing has kept going down for years.  And to make it
> economical to provide seamless experience for users, the cost of networking
> and computing in general has had to go way down. ... Even on a single
> platform, let's talk word processing.  Today Word or equivalent is the
> standard.  It generates a very flexible document.  Not just text anymore,
> but colors, multiple fonts, graphics, and much more, let alone the
> programability built into the macro type functions.
>
> This is all great, but it comes at a price.  Just look at the difference in
> size between a text only ASCII file that says "The little brown fox jumps
> over the lazy dog." and the word processing document that does that.
>
> The price?  Complexity in the programming, the size of files to store and
> shuffle from place to place (and associated network traffic).  Bigger
> systems (not individual but think all the aspects it takes to run things)
> take more administration, maintenance, power, people effort as developers,
> admins, system maintainers, let alone the overhead that comes with that and
> keeping things semi-organized.
>
> Is all this worth it?  Today the market has said it is.
>
> This whole computing thing is to provide users with a way for them to be
> more profitable in their lives.  Whether it is to lower stress, communicate
> easier, process information in a way than makes sense to them (not
> necessarily us), at a price that the end customer can tolerate and many of
> us 'middlemen' can still make a living (some better than others).
>
> Back toward the original subject, the reason that Single System Image was a
> big deal was to simplify life for customers and to reduce overhead for the
> customers.  Single Sign On was part of the whole thing too.
>
> So back to the question: Is SSI still a thing?  Yes. ... Just re-branded,
> revamped, re-released under a label saying it is all 'New and Improved'.
>
>
> On Thu, Apr 21, 2016 at 7:11 AM, Dan Ritter <dsr at randomstring.org> wrote:
>
>> On Thu, Apr 21, 2016 at 04:50:35AM +0000, Mike Small wrote:
>> >
>> > After the meeting I was discussing this issue with a friend. It's not an
>> > original criticism I didn't suppose, so I found someone with better
>> > words to sum up my reaction:
>> >
>> > "Sadly it seems that we now need to either wait for Linux or Windows to
>> > catch up with the 1980s state of the art in distributed systems (think
>> > Locus or AFS). What went wrong? Products like DataSynapse?s FabricServer
>> > look like an interesting attempt to address the problem, at least for
>> > the Java world, but it feels to me that mainstream operating systems
>> > designers seem to have lost the plot somewhere along the way."
>> >
>> >
>> http://discovery.bmc.com/community/blog-post/whatever-happened-to-distributed-operating-systems3/
>> >
>> > Is single system image still a thing?
>>
>> No, because you need to deal with parallelism issues on a single server.
>> Pocket computers now have four simultaneously working cores. It got really
>> hard for CPUs to get faster -- how long has the state of the art hovered
>> around 4GHz -- so the process improvements lead to more cores, instead.
>>
>> 80 cores used to be called a cluster, now it's a moderately expensive
>> 1U box. If your problems are smaller than that, you use virtualization
>> to gain efficient utilization. If your problems are bigger than that,
>> you need to coordinate lots of machines anyway, which will be managed
>> in a manner nearly identical to a swarm of virtual machines even if they
>> are containers or real metal.
>>
>> The easiest answer is to take your problem, split it into a lot of
>> cases, and send the cases out to all the [threads, cores, containers,
>> VMs, boxes] to be worked on. Hopefully they don't need to interact much
>> during the case work, and hopefully they don't need to coordinate much
>> afterwards. Most of the work involves figuring out what to do for those
>> interactions and coordinations.
>>
>> -dsr-