[Humanist] 31.351 different from the sum of its parts

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Wed Oct 11 07:21:35 CEST 2017


                 Humanist Discussion Group, Vol. 31, No. 351.
            Department of Digital Humanities, King's College London
                       www.digitalhumanities.org/humanist
                Submit to: humanist at lists.digitalhumanities.org

  [1]   From:    Gabriel Egan <mail at gabrielegan.com>                      (133)
        Subject: Re: [Humanist] 31.348 different from the sum of its parts

  [2]   From:    "Burke, Robin" <rburke at cs.depaul.edu>                     (12)
        Subject: Re: different from the sum of its parts


--[1]------------------------------------------------------------------------
        Date: Tue, 10 Oct 2017 11:22:18 +0100
        From: Gabriel Egan <mail at gabrielegan.com>
        Subject: Re: [Humanist] 31.348 different from the sum of its parts
        In-Reply-To: <20171010074238.651007E93 at s16382816.onlinehome-server.info>


Dear Tim

I didn't think we could still model the working of a computer in terms of
such a hierarchy.

In UK consumer law, for example, it has long been established that although
the fault in a complex machine may have its root in a particular small
subcomponent, the seller cannot use that fact to argue that overall the
machine is functioning and that only a small subcomponent is at fault. If
the whole machine isn't doing what it's meant to do, the whole machine is
deemed to be faulty.

This way of thinking seems not only pragmatically correct from the point of
view of law, but also technically correct from the point of view of computer
design. Is it not the case that computers and their operating systems are
indeed so complex that we can no longer define their interactions by a
hierarchy of modular operations? The same set of instructions (a single long
number) pulled in off the hard disk may be running on two processor cores
simultaneously, and from the point of view of coding 'intention' it seems to
me that they are only loosely not tightly subordinated to another process
that is meant to be supervising them. Am I wrong? Can we still model this
situation as a hierarchy of intentions? I'm genuinely asking for
enlightenment on this.

Regards

Gabriel

On 10/10/2017 8:42 AM, Humanist Discussion Group wrote:>                   
>                    Humanist Discussion Group, Vol. 31, No. 348.
>              Department of Digital Humanities, King's College London
>                         www.digitalhumanities.org/humanist
>                  Submit to: humanist at lists.digitalhumanities.org
>
>
>
>          Date: Sun, 8 Oct 2017 15:49:18 +0200
>          From: Tim Smithers <tim.smithers at cantab.net>
>          Subject: Re:  31.343 different from the sum of its parts
>
>
> Dear Gabriel,
>
> Let me see if I can say how I see things, using your last part
> about Windows not updating.
>
> I'm guessing some here, because I'm not familiar with the
> insides of the Windows operating system, but I'll use how I
> built other systems that do something similar.
>
> You say ...
>
>   "...  if Windows Update stops working on a PC, as has
>    happened to me, the component parts of the operating system
>    cease to operate properly because the whole operating system
>    has cease to do its job of applying patches to those local
>    parts."
>
> At the level of the "whole operating system" we have a single
> system, a single machine, that does quite a lot of things,
> including keeping itself uptodate.
>
> If this machine stops updating itself, but keeps on doing
> other things, we need to look a the level below to discover
> why it is not updating.  We need to look at the system of
> machines that make up the Operating System Machine.  There we
> will find, I am presuming, an Updating Machine, amongst (many)
> others.  Testing this Updating Machine may lead us to see that
> it is not updating because it fails to connect to a server,
> from where it gets updates.  We then need to look at the level
> below this Updating Machine, at the machines it is composed
> of, to find the machine that does the "connecting to the
> server."  Again, we test this, to understand why it doesn't
> seem to work.  And so on, down through the levels, until we
> find the component machine that is not working, and that,
> through this linear chain of functional dependencies, causes
> the "whole operating system" to be seen to not update itself.
>
> In this view, when you say "the component parts of the
> operating system cease to operate properly," it is not, as you
> say, "because the whole operating system has cease to do its
> job of applying patches to those local parts," but because
> some component machine, down inside the Operating System
> Machine, has failed to do its job.  The "whole operating
> system" doesn't do the updating job, only certain components
> of which it is composed do.
>
> To say the component parts fail because the whole operating
> system has failed is a level confusion: to to confuse the
> causal relationships designed and built into all the machines
> that go together to make the operating system.  If it wasn't
> like this, the Windows Operating system, and other things like
> it, would be much harder to understand, diagnose, and fix.
> In designing and building these kinds of allopoietic machines,
> we try hard to keep the causality that renders the linear
> functional dependencies as simple as possible.
>
> Having said this, a nice example in computer programs of two
> parts (sub-machines) inter-depending for their own correct
> functioning, can be seen in coroutines, a generalisation of
> subroutine.
>
>>From Wikipedia:
>
>   Coroutines are computer-program components that generalize
>   subroutines for non-preemptive multitasking, by allowing
>   multiple entry points for suspending and resuming execution
>   at certain locations.  Coroutines are well-suited for
>   implementing familiar program components such as cooperative
>   tasks, exceptions, event loops, iterators, infinite lists and
>   pipes.
>
> Coroutines are useful, and routinely used for certain things
> operating systems do, but they can be horrible to diagnose and
> debug.
>
> Needles to say, the functional relationship between the
> Windows operating system and its many components, and the
> functional relationships between these components and the
> machines they are, in turn, built from, is not a coroutine
> one.  It's a subroutining relationship.  Operating systems are
> essentially hierarchies of subroutines with a few coroutines.
> This is how new versions of parts of the operating system,
> "patches" as you call them, can be downloaded and installed
> without having to stop the whole operating system.  You can't
> do this easily for one part of a running coroutine, since the
> state that each part depends upon for its proper working is
> shared across bother parts of the coroutine.
>
> Best regards,
>
> Tim

--
________________________________________________________________________
Professor Gabriel Egan, De Montfort University. www.gabrielegan.com
Director of the Centre for Textual Studies http://cts.dmu.ac.uk
National Teaching Fellow http://www.heacademy.ac.uk/ntfs
Gen. Ed. New Oxford Shakespeare http://www.oxfordpresents.com/ms/nos




--[2]------------------------------------------------------------------------
        Date: Tue, 10 Oct 2017 12:31:16 +0000
        From: "Burke, Robin" <rburke at cs.depaul.edu>
        Subject: Re: different from the sum of its parts
        In-Reply-To: <20171010074238.651007E93 at s16382816.onlinehome-server.info>

Just to push the point a little bit farther…

What if the reason that Windows update stops working is because the computer has some hardware component that is somewhat obscure and Microsoft doesn’t test for compatibility with it when producing updates? Because of this, some previous update has interfered with the functioning of a device driver and now it crashes periodically and this interferes with the operation of the “Update Machine”. (I’m talking real experience here.) So, arguably, a failure on the company’s part to thoroughly test an update is causing the whole updating / patching system to work incorrectly. 

You could still point to the inside of the machine and say “here is the cause: a device driver that keeps crashing”, but I could point back to the update system and say “here is the cause: a failure to test thoroughly, resulting in an incompatible update.” And then the system engineer would point back to my system and say “here is the cause: an obscure peripheral device that isn’t on my compatibility list.” And I could say “here is the cause: a cost-savings measure by the company to restrict the set of tested configurations on the compatibility list.” Or I could point to the peripheral manufacturer. Etc.

I think it is not a stretch to say that at this point personal computing is a pretty complex ecosystem, and even though each machine is fundamentally deterministic, its correct functioning is often subtly but ultimately dependent on decisions made by other actors: software / hardware companies, hackers, ISPs, etc. Ask any IT person charged with keeping such systems up and running. The causal arrows point in multiple directions. 

Robin


———————————————————————————————
Robin Burke, Professor
School of Computing, DePaul University
rburke at cs.depaul.edu

 
 





More information about the Humanist mailing list