[FRIAM] IT is Not Sustainable
Steven A Smith
sasmyth at swcp.com
Thu Dec 26 12:42:25 EST 2019
Frank -
It is fascinating to hear that you were in the "belly of the beast" if
only for a short while. I suppose we have all been in the belly of
*some* beast in our various times.
My earliest years were without a telephone in the house (camp-trailer in
the woods) followed by several party lines (shared in 2 cases amongst
other USFS families in forest-camp compounds) and understanding that the
magical rings and voices coming from the handsets in the house were
modulated (whatever that meant to a 3 year old) over the insulated
bundles of wires running from tree-to-tree and pole-to-pole... It
wasn't hard to understand the idea that if voices could travel over
single wires, that any one of us on a party line could pick up and hear
the other's voices during a conversation or even that the volume/static
on the line would abruptly change if someone picked up (say to listen
in?). It made perfect sense that such resources (wires on poles) were
very scarce and needed to be shared... I had heard of
operator-assisted calling which made great sense (patch panels) but the
idea that the pulses sent via the spring-loaded rotary dial could "tell"
a electromechanical switch (my father showed me the one in the main
location at the second forest camp when I was about 5) and I remember
watching/hearing a call go through it... relays opening and closing as
ring pulses went through...
One of my friend's father was the local telephone lineman and he was
busy all the time either going out on trouble calls or doing maintenance
on the switches. Realizing that in a community of roughly 300 (600 in
the county at the time!) was keeping one man busy (more than) full time
doing this was my first taste of "infrastructure". I don't know what
kind of backup he had... I never saw anyone else working with him nor
heard of anyone else employed... though I do know sometimes there were
company trucks parked at the fenced yard next to his house... probably
for new line buildout? Another father of a friend owned/operated the
local "vending" routes which included soda machines, candy machines and
best of all pinball machines. HIs territory must have been pretty wide
because our 300 town only had one soda/candy machine at each of 2
gasoline stations and 3 pinball machines at the drug/variety store. I
got to see the ones in their shop behind the house under repair opened
up and really got a kick out of trying to "trace the logic" of a
coin-drop/lever-pull, delivery-chute... and even better, the complex
logic of a pinball machine. Yet another father drove the propane
delivery truck (he had a boss who drove some, but he was the main
driver) and another who ran the local branch of the power - coop along
with his wife. They had more trucks that came in from the next large
town (60 miles and maybe 1000 people?) to do major repairs/upgrades, but
he was out in his truck all the time fixing/installing *something*.
Several of these men ran an ad-hoc cable network in the core of the
village... nothing came in by antenna and I guess they had their own up
on a mountain with a rebroadcast system... the network was down as
much as it was up and while *some* of the customers had to have been
paying customers, it was these guys who somewho cooperatively kept it
going. I *knew* that someone besides these men were *designing* and
*building* the systems they maintained (thought the cable TV thing was
more DIY).
Many years later, we moved to a large town/small-city (2 supermarkets, a
dozen motels and gas stations?) and our neighbors at the edge of town
owned the local AM radio station... they solicited me to clean the
station every Saturday and after a few months of that I graduated to
typing up station program logs and then began to operate the station
under supervision... they were largely "automated" which meant 4 big
carousels with 4-track endless loop (similar to 8-track) cartidges that
we would load with music, PSAs and commercials which were then
"programmed" by inserting pins in different patch-panels... there were
two modes... for example, the system that took over on the top of hour
for the network news would inject one of a small handful of instrumental
tunes that could be faded/interrupted at-will to flip over the
newsfeed. The rest of the time, the system had a priority stack and
the commercial/PSAs stack had priority in the sense that it wanted to
play out it's queue within the allotted time (usually one hour) no
matter what... while the music queue would simply play whenever one of
the others were not... only rarely (due to bad planning) would a
commercial or PSA go unplayed. Not every hour was different, but there
were periods (8-12AM, 1-5PM, 6-10PM) that had a particular character and
there was some variation within it. By the time I was 15 (Freshman in
HS) the station owners saw my diligence and curiosity (the Station
Engineer would take the time to explain most everything there to me in
as much detail as I had time for) and offered me a nighttime live show
which I ran for most of my HS years. I always had the option to fire up
the automated system, as I was also trying to do my homework during that
time. I went in to the station before 4PM to handle the 4-6 news
programs (I can still hear Paul Harvey ringing in my ears) and then the
(automated) 6-7 PM "sundown serenade" curated by the wife but executed
by me (most of the time). At 7 we rolled into "the Night Show" which
was conceived by the owners to be something for the "youth crowd". It
was nominally a Rock show but was really Top-40 by their measure... We
had the full array of classic rock vinyl in the shelves and I was
allowed to use (most of) it but there was the top-40 billboard charts to
be serviced which meant a lot of pop-rock and country-rock and pop-pop.
Yet another exposure to the complexities of "programming" and "logic"
from a somewhat different perspective. The engineer at the time had
been on the predecessor to the NIF fusion project in Livermore (MFE?)
(designing/building the capacitor banks) and clued me in a lot of
things. He was a greasy-haired wiry little hippy that drove an old
italian convertible (very finicky with dual carbs...) and had a penchant
for visiting the bars/brothels in Mexico (this was a border town) and
probably got rolled by someone at least once a year... and had the
stories (and scuffs) to tell about it. He taught me binary
logic/arithmetic and showed me how that related to the somewhat
similar/different discrete/analog systems behind the carousels (all the
electronics were exposed, so you could trace wires and watch relays
open/close) and even taught me the basics of analog circuits including
soldering, relays, power amplifiers/transmitters. Later, as I went
into the all-digital world of Computer Science, It was as if I was
learning about Mammals after growing up among only Marsupials. Of
course automobiles had their own share of analog-discrete logic with an
HV (timed) side and a 12V mostly continuous (but with switches/relays)
side. This was the 70s and the autos of interest were mostly from the
50s/60s.
I went to LANL in 1981 to work on the Proton Storage Ring which was in
some ways the epitome of an anolog/digital hybrid systems with huge
subsystems being HV and HF while others were "utility" (110/60) and yet
others were TTL. The place was "in flux" all the time... with
magnetic fields (intended and unintended) coming and going effecting
everything. It was a quite the milieu. Moving to HPC was both a
relief and a whole new world... even though I still worked with some
analog systems, they were much less dangerous and much less high
speed... the digital stuff was lickety-split (by those days standards)
and the introduction of vector and parallel (and eventually distributed)
processing was new and interesting. By the time I was mentoring others
(90s), the backgrounds were almost exclusively digital and most if not
all of the "kids" that came through had never even worked on their own
cars, much less vending machine or automated tape carousel logic.
As Y2K approached, a consultant from SAIC was working in my general
area... we became friends... but his role and way of thinking was
incredibly foreign to me. One of his roles (he felt like a plant from
the military-industrial into the military-scientific establishment) was
to consult on Y2K readiness. My system at the time had been hand-built
on top of UNIX (replacing a VMS system that was falling apart every day)
by a small team (3-5 of us) and while I did not know every line of code
in the system (I had written a good portion of it), we had coding
practices and standards and code-reviews and I was roughly 99.9%
confident that we didn't have a single 2-digit date in the system, nor
did we depend on any libraries or system code which did. The
open-source/community nature of BSD Unix meant that everything we relied
on and trusted without inspecting personally had been inspected by
hundreds or thousands of others. The Y2K problem had been discussed a
lot and there were plenty of procedures in place to encourage (though
never ensure) that every code-team/system had expunged any possible Y2K
bugs. My SAIC buddy talked in SLOC and had metrics up the wazoo about
things which almost exclusively did not apply (well) to our systems
as-designed and as-built. There may well have been (especially in the
Business Processing side of the house) some big risk/holes, but I knew
my system intimately and the other major/similar systems (slightly
larger development teams with more turnover) were well in hand.
We (the three major systems) also had on-call responsibility and were
used to being called at 3AM if something wasn't right.... *we* had been
trained by the operations staff to not leave them hanging... they could
be pretty easy-going/helpful with those of us who answered our phones
and were easy-going/helpful with them, but the few who thought they
shouldn't have to help stand up a system they built when it fell over
(or sprung a leak) at 3AM on a holiday discovered quickly that they
would not be let off easier just because they were reluctant or pissy
about the call. Bottom line was that we (developers) knew that our
systems had to run 24/7/365 and the 00:00:01 01/01/00 was just like any
other day, and if/when/as the dominoes might start to fall, it was OUR
job to be right there standing back up any of OUR dominoes that might
fall on their own or be knocked down by others. There was a little
rivalry between systems (operations as well as development) but for the
most part of someone else's system was falling down and making a mess
(creating possible/implied bugs in other systems) we all pulled together
pretty well. I don't know to this day if my SAIC friend understood
how coordinated and intimate we all were, because he kept on predicting
gloom and doom for us as the date approached. As it was, there wasn't
even much scurry as the calendar/clocks cranked over Y2K, and I don't
remember any acute problems. We (wanted to?) believed that the ADP
side of the house had no end of problems due to their heavy dependence
on commercial systems/layers/middle-ware/vendors. As I remember it,
Y2K was pretty much a flop everywhere.
All this in response to "IT is Not Sustainable". I would claim that
virtually NOTHING we build is sustainable... or at least there is a huge
spectrum. Engineering can be incredibly robust within it's design
parameters, but is often incredibly fragile when confronted with a
unexpected conditions... Evolved systems are also simultaneously
fragile and robust. They are robust within the "basins of attraction"
implied by the ecosystem they operate within but once pushed out of
those robust regions they can self-destruct quickly... I've been
studying (very loosely) the myriad examples of species extinction and
habitat loss and cascading failures (in progress and/or impending) in
our ecosystems and am appalled at how unprepared we (humans, engineers,
even scientists) are to apprehend the fragile interconnectedness and
"designed for near-optimal-conditions" we have set up. Not precisely a
house of cards, a line of dominos, a stack of Jenga sticks, but not
precisely NOT those either.
My recent trip to Europe/Scandinavia opened my eyes to some things I was
previously under-aware of. The evolved-engineered systems of polder
and canal and dike and hydrology in the Netherlands is perhaps the most
impressive. Realizing that they started significantly holding back the
north sea during the "little ice age" (dikes and polders had started
earlier, but this was when they really came into their own?) helps me to
appreciate the difference between what they have done there over
centuries vs what our own Army Corps has done in less than 100... and
most to the point, the ways a whole culture can adapt to things
including their own engineering given many generations, but how we
"moderns" don't have time to adapt culturally to the changes. We DO
adapt (the talk of telephones and the earliest examples leading up to a
global wireless, multi-system-technology mesh/grid being an example),
but it isn't clear to me that our adaptation is *deep* enough to be
robust...
Another example in less detail is what has been come to be called "the
Nordic Secret" which is roughly the response of Scandinavia to the
enlightenment followed by the industrial revolution and perhaps most
acutely the post WWII industrial/cultural explosion in the west. In
many ways they follow the rest of the West, but it seems they may
actually know "a secret" about sustainability, both industrially and
culturally.
The "Endogenous Existential Threats" of our time are many/myriad and to
the point... Endogenous... self-generatated... and while we may be
taking down a lot of the biosphere-as-we-know it with us, the biggest
tragedy seems to be set to land ON us, and those closest to us (our
domisticates and the remaining large mammal species)... though that
also may simply be an anthropocentric view.
As Dave's title says "IT" is not sustainable... you name the "it" and
it very likely has a lamer lifetime than you imagine (my Y2K anecdote
notwithstanding)...
I WILL say that despite my neo-Luddite rants, I've become more of an
Eco-Modernist of late... not necessarily wanting to trust that we can
"technology" our way out of the disasters we are creating with our
technology, but recognizing that perhaps we have little other choice
(culturally)... and that we must *try* to walk the tightrope of using
"fire to fight fire" but with (perhaps) a lot more self-awareness than
that which we used to paint ourselves into this (mixed metaphor of a)
corner.
</ramble>
- Steve
On 12/26/19 9:08 AM, Frank Wimberly wrote:
>
> "CenturyLink (NYSE: CTL) has set a goal to reduce power consumption on
> its public switched telephone network by nearly 22,000 megawatt-hours
> a year, reducing greenhouse gas emissions as more customers migrate to
> VoIP and mobile voice services.
>
> Although CenturyLink is growing its IP-based voice service, this
> project is focused on consolidating more than 400,000 legacy PSTN
> subscriber lines across 50 Class 5 voice switches. "
>
>
> They're called class 5 because of 5ESS which is the most used class 5
> switch at CenturyLink.
>
> Sorry, but I had to clarify this.
>
>
> Frsnk
>
> -----------------------------------
> Frank Wimberly
>
> My memoir:
> https://www.amazon.com/author/frankwimberly
>
> My scientific publications:
> https://www.researchgate.net/profile/Frank_Wimberly2
>
> Phone (505) 670-9918
>
> On Thu, Dec 26, 2019, 8:43 AM Frank Wimberly <wimberly3 at gmail.com
> <mailto:wimberly3 at gmail.com>> wrote:
>
>
> June 2019) (Learn how and when to remove this template message).
> 5ESS used in a mobile telephone network. The 5ESS Switching System
> is a Class 5 telephone electronic switching system developed by ...
> -----------------------------------
> Frank Wimberly
>
> My memoir:
> https://www.amazon.com/author/frankwimberly
>
> My scientific publications:
> https://www.researchgate.net/profile/Frank_Wimberly2
>
> Phone (505) 670-9918
>
> On Thu, Dec 26, 2019, 8:36 AM Marcus Daniels <marcus at snoutfarm.com
> <mailto:marcus at snoutfarm.com>> wrote:
>
> Frank writes:
>
>
>
> “This was the telephone network in question.“
>
>
>
> With the mobile carriers and VOIP, I wonder how much of that
> code is still used? I once worked for a small company that
> wrote software to do billing for long distance telephone
> carriers. I was amazed by the seemingly arbitrary
> complexity. Complex at a policy and inter-organizational
> level, not just the software.
>
>
>
> Marcus
>
>
>
> *From: *Friam <friam-bounces at redfish.com
> <mailto:friam-bounces at redfish.com>> on behalf of Frank
> Wimberly <wimberly3 at gmail.com <mailto:wimberly3 at gmail.com>>
> *Reply-To: *The Friday Morning Applied Complexity Coffee Group
> <friam at redfish.com <mailto:friam at redfish.com>>
> *Date: *Thursday, December 26, 2019 at 5:39 AM
> *To: *The Friday Morning Applied Complexity Coffee Group
> <friam at redfish.com <mailto:friam at redfish.com>>
> *Subject: *Re: [FRIAM] IT is Not Sustainable
>
>
>
> At Bell Labs we sure didn't pay anyone by LOC. We also had
> code reviews and software tools to enforce standards and very
> high pay. With a brand new PhD I made more than all but the 3
> most senior members of the CS faculty at Pitt where I was a
> grad student. This was the telephone network in question.
>
>
>
> Despite the high pay I disliked software administration
> methodology. The disagreements between the software tool
> developers (version control, integration of subsystems,
> compilers, etc) and the implementors of the applications, such
> as call processing, were epic. Recall that Bell Labs invented
> C and Unix. After 18 months I returned to Pittsburgh to work
> at Carnegie Mellon in Robotics for two thirds the salary.
>
>
>
> Number 5 ESS was first deployed in March 1982, 4 years after
> work began. I suspect that it didn't have 200 million lines
> of code then, but close to it. Maybe Dave doesn't consider it
> an IT project but many of the software tools that were
> developed were included in later Unix releases, I believe.
>
>
>
> It's going to be a beautiful day in Santa Fe.
>
>
>
> Frank
>
>
>
>
>
> -----------------------------------
> Frank Wimberly
>
> My memoir:
> https://www.amazon.com/author/frankwimberly
>
> My scientific publications:
> https://www.researchgate.net/profile/Frank_Wimberly2
>
> Phone (505) 670-9918
>
>
>
> On Thu, Dec 26, 2019, 1:28 AM Gary Schiltz
> <gary at naturesvisualarts.com
> <mailto:gary at naturesvisualarts.com>> wrote:
>
> Spot on.
>
>
>
> On Thu, Dec 26, 2019 at 2:29 AM Marcus Daniels
> <marcus at snoutfarm.com <mailto:marcus at snoutfarm.com>> wrote:
>
> Most programmers won't struggle to rationalize or
> improve code written by other people. The problem
> is that people are selfish. They think that their 10K
> LOC problem is beautiful and nimble, but that 1M LOC
> was once that too. It's the behavior of teenagers.
>
> On 12/25/19, 10:47 PM, "Friam on behalf of Russell
> Standish" <friam-bounces at redfish.com
> <mailto:friam-bounces at redfish.com> on behalf of
> lists at hpcoders.com.au <mailto:lists at hpcoders.com.au>>
> wrote:
>
> It's all about the LOC! Actually, I kind of agree
> - having worked on
> some MegaLOC codebases that functionally seemed to
> be no more complex
> than a 10KLOC project I'm involved in, the 10KLOC
> project is much more
> nimble - compile times are far less, making
> changes to the code easier
> and bugs less troublesome to winkle out.
>
> I've also refactored or rewritten pieces of code
> to slash the LOC by a
> factor of 3 or more for that particular section
> (eg 3KLOC -> 1KLOC) -
> but usually when bugs and problems kept on
> cropping up in that
> section.
>
> Even though the LOC is an entirely bogus
> measurement - if you paid a
> programmer by LOC, you'd get boilerplate and
> crappy comments.
>
> --
>
>
> ----------------------------------------------------------------------------
> Dr Russell Standish Phone 0425
> 253119 (mobile)
> Principal, High Performance Coders
> Visiting Senior Research Fellow
> hpcoder at hpcoders.com.au <mailto:hpcoder at hpcoders.com.au>
> Economics, Kingston University
> http://www.hpcoders.com.au
>
> ----------------------------------------------------------------------------
>
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> to unsubscribe
> http://redfish.com/mailman/listinfo/friam_redfish.com
> archives back to 2003:
> http://friam.471366.n2.nabble.com/
> <http://friam.471366.n2.nabble.com/>
> FRIAM-COMIC http://friam-comic.blogspot.com/ by
> Dr. Strangelove
>
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> to unsubscribe
> http://redfish.com/mailman/listinfo/friam_redfish.com
> archives back to 2003: http://friam.471366.n2.nabble.com/
> FRIAM-COMIC
> <http://friam.471366.n2.nabble.com/FRIAM-COMIC>
> http://friam-comic.blogspot.com/ by Dr. Strangelove
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> to unsubscribe
> http://redfish.com/mailman/listinfo/friam_redfish.com
> archives back to 2003: http://friam.471366.n2.nabble.com/
> <http://friam.471366.n2.nabble.com/>
> FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr.
> Strangelove
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> to unsubscribe
> http://redfish.com/mailman/listinfo/friam_redfish.com
> archives back to 2003: http://friam.471366.n2.nabble.com/
> FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove
>
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
> archives back to 2003: http://friam.471366.n2.nabble.com/
> FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://redfish.com/pipermail/friam_redfish.com/attachments/20191226/208071b9/attachment.html>
More information about the Friam
mailing list