clinic in Constant 2018


tware in a
long-term context. It offered us the occasion to reflect on the
conditions of its appearance, and allowed us to take on current-day
questions from a genealogical perspective. What is software? How did it
appear as a concept, in what industrial and governmental circumstances?
What happens to the material conditions of its production (minerals,
factory labor, hardware) when it evaporates into a cloud?

The second two days we focused on the space-time dimension of IT
development. The way computer programs and operating systems are
manufactured changed tremendously through time, and so did its
production times and places. From military labs via the mega-corporation
cubicles to the open-space freelancer utopia, what ruptures and
continuities can be traced in the production, deployment, maintenance
and destruction of software? From time-sharing to user-space partitions
and containerization, what separations were and are at work? Where and
when is software made today?

The Walk-in Clinic
------------------

The last two days at the Techno-galactic software observatory were
dedicated to observation and its consequences. The development of
software encompasses a series of practices whose evocative names are
increasingly familiar: feedback, report, probe, audit, inspect, scan,
diagnose, explore, test \... What are the systems of knowledge and power
within which these activities take place, and what other types of
observation are possible? As a practical set for our investigations, we
set up a walk-in clinic on the 25th floor of the World Trade Center,
where users and developers could arrive with software-questions of all
kinds.

> Do you suffer from the disappearance of your software into the cloud,
> feel oppressed by unequal user privilege, or experience the torment of
> software-ransom of any sort? Bring your devices and interfaces to the
> World Trade Center! With the help of a clear and in-depth session, at
> the Techno-Galactic Walk-In Clinic we guarantee immediate results. The
> Walk-In Clinic provides free hands-on observations to software curious
> people of all kinds. A wide range of professional and amateur
> practitioners will provide you with
> Software-as-a-Critique-as-a-Service on the spot. Available services
> range from immediate interface critique, collaborative code
> inspection, data dowsing, various forms of network analyses,
> unusability testing, identification of unknown viruses, risk
> assessment, opening of black-boxes and more. Free software
> observations provided. Last intake at 16:45.\
> (invitation to the Walk-In Clinic, June 2017)

On the following pages: Software as a Critique as a Service (SaaCaaS)
Directory and intake forms for Software Curious People (SCP).

[SHOW IMAGE HERE:
http://observatory.constantvzw.org/documents/masterlist\_twosides\_NEU.pdf]{.tmp}
[SHOW IMAGE HERE:
http://observatory.constantvzw.org/documents/scprecord\_FINAL.pdf]{.tmp}
[]{#owqzmtdk .anchor}

Techno-Galactic Software Observation Essentials

=
**WARNING**

The survival techniques described in the following guide are to be used
at your own risk in case of emergency regarding software curiosity. The
publisher will not accept any responsability in case of damages caused
by misuse, misundestanding of instruction or lack of curiosity. By
trying the action exposed in the guide, you accept the responsability of
loosing data or altering hardware, including hard disks, usb key, cloud
storage, screens by throwing them on the floor, or even when falling on
the floor with your laptop by ta


]{#ndhkmwey .anchor}
[[Method:](http://pad.constantvzw.org/p/observatory.guide.everyonescp)
Persist in calling everyone a Software Curious Person]{.method
.descriptor} [What: Persistance in naming is a method for changing a
person\'s relationship to software by (sometimes forcibly) call everyone
a Software Curious Person.]{.what .descriptor} [How: Insisting on
curiosity as a relation, rather than for example \'fear\' or
\'admiration\' might help cut down the barriers between different types
of expertise and allows multiple stakeholders feel entitled to ask
questions, to engage, to investigate and to observe.]{.how .descriptor}
[Urgency: Software is too important to not be curious about.
Observations could benefit from recognising different forms of
knowledge. It seems important to engage with software through multiple
interests, not only by means of technical expertise.]{.urgency
.descriptor} [Example: This method was used to address each of the
visitors at the Techno-Galactic Walk-in Clinic.]{.example .descriptor}
[TODO: RELATES TO]{.tmp} [Healing]{.grouping} []{#mmu1mgy0 .anchor}
[[Method:](http://pad.constantvzw.org/p/observatory.guide.relational)
Setup a Relational software observatory consultancy (RSOC)]{.method
.descriptor} [Remember]{.remember .empty .descriptor}

- Collectivise research around hacking to save time.
- Self-articulate software needs as your own Operating (system)
perspective.
- Change the lens by looking to software through a time perspective.

[What: By paying a visit to our ethnomethodology interview practice
you'll learn to observe software from different angles / perspectives.
Our practionners passion is to make the \"what is the relation to
software\" discussion into a service.]{.what .descriptor} [How: Reading
the signs. Considering the everchanging nature of software development
and use and its vast impact on globalized societies, it is necessary to
recognize some of the issues of how software is (often) either
passively-perceived or


LONG AS THEY WILL BE ABLE TO, provided sufficient power is available.
> You, as a human, don\'t have the luxury of being always connected to
> the power grid and this have to rely on your INTERNAL BATTERY. Be
> aware of your power cycles and set yourself to POWER-SAVING MODE
> whenever possible.

[SHOW IMAGE HERE:
http://gallery.constantvzw.org/var/resizes/Techno-Galactic-Software-Observatory/IMAG1407.jpg?m=1497344230]{.tmp}
[TODO: RELATES TO]{.tmp} []{#yznjodq3 .anchor}
[[Method:](http://pad.constantvzw.org/p/observatory.guide.dirty) Bug
reporting for sharing observations]{.method .descriptor} [What: Etherpad
had stopped working but it was unclear why. Where does etherpad
\'live\'?]{.what .descriptor} [How: Started by looking around the pi\'s
filesystem by reading /var/log/syslog in /opt/etherpad and in a
subdirectory named var/ there was dirty.db, and dirty it was.]{.how
.descriptor} [When: Monday morning]{.when .descriptor} [Urgency:
Software (etherpad) not working and the Walk-in Clinic was about to
start.]{.urgency .descriptor} [Note:
http://pad.constantvzw.org/p/observatory.inventory.jogi]{.note
.descriptor}

from jogi\@mur.at to \[Observatory\] When dirty.db get\'s dirty

Dear all,

as promised yesterday, here my little report regarding the broken
etherpad.

\ \#\#\# When dirty.db get\'s dirty

When I got to WTC on Monday morning the etherpad on etherbox.local was
disfunct. Later someone said that in fact etherpad had stopped working
the evening before, but it was unclear why. So I started looking around
the pi\'s filesystem to find out what was wrong. Took me a while to find
the relevant lines in /var/log/syslog but it became clear that there was
a problem with the database. Which database? Where does etherpad
\'live\'? I found it in /opt/etherpad and in a subdirectory named var/
there it was: dirty.db, and dirty it was.

A first look at the file revealed no apparent problem. The last lines
looked like this:

`{"key":"sessionstorage:Ddy0gw7okwbkv5BzkR1DuSLCV_


in a world of
distributed systems where there are many parts being organized
simultaneously. Continuous integration is a form of observation that
helps (micro)services maintain a false sense of independence and
decentralization while constantly subjecting them to centralized
feedback.]{.when .descriptor} [Who: Continuous integration assumes that
all services will submit themselves to the feedback loops of continuous
integration. This could be a democratic process or not.]{.who
.descriptor} [Urgency: Continuous integration reconfigures divisions of
labor in the shadows of automation. How can we surface and question its
doings and undoings?]{.urgency .descriptor} [WARNING: When each service
does one thing well, the service makers tend to assume everybody else is
doing the things they do not want to do.]{.warning .descriptor}

At TGSO continuous integration was introduced as a service that responds
to integration hell when putting together a number of TGSO services for
a walk-in software clinic. Due to demand, the continuous integration
service was extended to do \"service discovery\" and \"load balancing\"
once the walk-in clinic was in operation.

Continuous integration worked by visiting the different services of the
walk-in clinic to check for updates, test the functionality and think
through implications of integration with other services. If the pieces
didn\'t fit, continuous integration delivered error messages and
solution options.

When we noticed that software curious persons visiting the walk-in
clinic may have troubles finding the different services, and that some
services may be overloaded with software curious persons, continuous
integration was extended. We automated service registration using
colored tape and provided a lookup registry for software curious
persons.

http://gallery.constantvzw.org/index.php/Techno-Galactic-Software-Observatory/IMAG1404

Load balancing meant that software curious persons were forwarded to
services that had capacity. If all other services were full, the load
balancer defaulted to sending the software curious person to the [Agile
Sun
Salutation](http://pad.constantvzw.org/p/observatory.guide.agile.yoga)
service.

[WARNING: At TGSO the bundling of different functionalities into the
continuous integration service broke the \"do one thing well\"
principle, but saved the day (we register this as technical debt for the
next iteration of the walk-in clinic).]{.warning .descriptor} [Remember:
Continous integration may be the string that holds your current software
galaxy together.]{.remember .descriptor}

\"More technically, I am interested in how things bounce around in
computer systems. I am not sure if these two things are relted, but I
hope continuous integration will help me.\"

[]{#zdixmgrm .anchor}
[[Method:](http://pad.constantvzw.org/p/observatory.guide.pipeline) make
make do]{.method .descriptor} [What: Makefile as a method for
quick/collective assemblages + observing amalgamates/pipelines]{.what
.descriptor} [Note: Note:
http://observatory.constantvzw.org/etherdump/makefile.raw.html]{.note
.descriptor}

etherpad-\>md-\>pdf-\>anything pipeline. makefile as a method for
quick/collective assemblages + observing amalgamates/pipelines CHRISTOPH

[]{#zweymtni .anchor}
[[Method:](http://pad.constantvzw.org/p/observatory.guide.ssogy)
Flowcharts (Flow of the chart -- chart of the flow on demand!)]{.method
.descriptor} [Example]{.example

 

Display 200 300 400 500 600 700 800 900 1000 ALL characters around the word.