
The Lack of Historic Knowledge Is Frustrating - vezzy-fnord
http://blog.ipspace.net/2015/10/the-lack-of-historic-knowledge-is-so.html
======
Terr_
> I started with B2B credits in FC and told him "Fibre Channel uses exactly
> the same approach as hop-by-hop windows we had in X.25, with the same
> results…" resulting in confused blank stare. Further down the conversation I
> said "FCoE uses lossless Ethernet, which uses PAUSE frames, which are
> exactly the same thing as Ctrl-S and Ctrl-Q on an async link." Same result.

Or -- to play contrarian/devil's-advocate -- perhaps you should find more ways
to convey these timeless logical concepts that don't _depend_ on ancient war-
stories or shared-suffering involving "dead" technologies? I'm not saying you
have to turn your baseball cap sideways and start saying "dawg", but effective
communication means you need to update your metaphors and analogies at least
once in a decade as your audience changes.

If the past contains useful lessons, sometimes the best thing you (i.e. direct
contemporaries who were there) can do is to isolate the most important,
broadly-useful parts, and _cut them loose_ from the gnarly matrix of
specifics. Then you can teach the lesson over and over in a way that doesn't
_depend_ on audiences who worked with Tech X from years Y to Z.

~~~
hueving
This can't be overstated. If you dump a pile of acronym diarrhea on someone
from a bunch of dead technologies and get upset when you get a blank stare, it
is 100% your own fault for lacking the communication skills or abstraction
skills to separate useless jargon from important concepts.

~~~
brianmwaters_hn
This is an attitude I see more and more of today, and I think it's
unfortunate. The slides in question aren't "a pile of acronym data;" they're
made of lingo that would be recognizable to anyone who works in the field of
networking - even if they don't understand the specifics of the protocols in
question.

At any rate, the author's complaint isn't that "kids these days" haven't heard
of all these acronyms, it's that they haven't learned any of the technical
details behind those acronyms, and that those details are still relevant.

Finally, I have a bone to pick with the "it's the older generations'
responsibility to educate the younger generation" idea that I hear so often.
At the end of the day, it's everyone's own responsibility to educate
themselves, and we all know there's plenty of materials available for that.

~~~
nickpsecurity
"Finally, I have a bone to pick with the "it's the older generations'
responsibility to educate the younger generation" idea that I hear so often.
At the end of the day, it's everyone's own responsibility to educate
themselves, and we all know there's plenty of materials available for that."

I'm on your side of the discussion overall but that's unrealistic. It took me
a decade to get so much of this knowledge and wisdom out of papers on
programming, OS design, networking, security, etc. I just found some more
foundational work in past months that should've been in every classroom for
its relevance but nobody's heard of it.

The problem is that the stuff is scattered all over the place and not in pure
form at all. There's books, papers, brochures, lectures, etc. These might have
good details, fluff, or a varying mixture of each. Many great works can only
be found behind paywalls (IEEE, ACM). Others are on academic sites, specific
blogs, or places like CiteseerX where you have to know what you're looking for
ahead of time.

Our field is anything but a clean, integrated presentation of what really
mattered, matters, and might matter. It's a huge, scattered mess that we
expect new crowd to just automagically sort through and discover necessary
stuff. Prior generations certainly have some responsibility to make that
easier rather than harder. I do my part with posts here and elsewhere
directing people to specific techs that solved (or nearly so) the problems
they are talking about. Need a more thorough solution, though, for the various
sub-fields of I.T. before I'll blame the newcomers for prior generation's
mess.

~~~
brianmwaters_hn
Hm, I agree that there's a lot scattered out there, but I hope that there's
some room for exploration (and maybe specialization) somewhere in the noise.

I actually have an interesting perspective on this, being completely self-
taught, before returning to university as an adult to get a computer science
degree.

There are pros and cons to both sides of the self-taught vs. teacher-taught
thing, though I'll make my bias clear up front: I spent a lot of years reading
books and messing around with stuff; now, when I hear college students
complain that a teacher "isn't a clear lecturer" or "didn't answer my question
well," my tendency is to say "there's a book and an Internet out there, suck
it up and get to studying, buddy," though I realize that attitude isn't
perfect for everyone.

~~~
cbd1984
> when I hear college students complain that a teacher "isn't a clear
> lecturer" or "didn't answer my question well," my tendency is to say
> "there's a book and an Internet out there, suck it up and get to studying,
> buddy,"

Which raises the question of what the lecturer is even standing around talking
for. Isn't it just a waste of their own and everyone else's time if they
aren't good at doing what they attempt to do? If someone is a good researcher
and lousy in the classroom, why make them teach classes and waste everyone's
time?

~~~
nickpsecurity
I agree with you there. I think Brian probably would, too. His point was that
many people let their pursuit of knowledge end there rather than use other
resources available to learn what they needed to know. The lecturer becomes an
excuse rather than an obstacle on the path to understanding.

------
hueving
The author of this article is making terrible mistakes in the other direction.
He attributes failures of entire technologies to single issues. ATM wasn't
killed just because of design failures, it was killed in large part because of
being crushed by Cisco. Ethernet fabrics were fucked up by Juniper's poor
execution, not because they are a bad design.

This thought process leads to unoriginal and restrictive thinking. Take the
following bullet point: "Central Controller = single failure domain". When you
see that he wants you to think designs with controllers are crap. However,
Google's network uses a central controller to distribute policy and make QoS
optimizations. If all of it's members go down (it's also a distributed system)
it doesn't take down the network, you just lose some optimizations. This gets
them much better utilization >90% than the run-of-the-mill BGP folded clos
junk that 'experienced network engineers' churn out today.

Sorry for venting, but I see this guy's attitude very frequently in the
network engineering community. "Oh, someone tried something like that once,
and it didn't work, so we are going to refuse to do anything that has an
overlapping concept." It's no wonder we still use command-lines and have to
script SSH sessions to configure things. This industry is stagnant as hell.

~~~
cbd1984
You know what would be nice? If there were a good place to learn which
technologies were dead, dying, or had gone niche instead of becoming
mainstream.

Your rant implies ATM is in one of those categories, but it's surprisingly
hard to find places which actually _say that_ instead of being all polite (or
whatever concept is in play here) and pretending that it's just as mainstream
as DOCSIS or Ethernet.

Maybe it's too much to ask for. Maybe there's always going to be too much bias
and... I don't know... hurt feelings?... for something like that to exist. It
certainly wouldn't be a nice thing to have if you were in the business of
selling ATM "Solutions".

~~~
fulafel
ADSL is ATM, so not entirely dead yet.

------
Animats
For real historic knowledge, here are a few things to understand about
networking:

\-- Bell System #5 Crossbar. The best of the electromechanical telephone
switches. No Bell System #5 crossbar central office was ever out of service
for more than 30 minutes for any reason other than a natural disaster or fire.
That level of reliability was not maintained in the computer era. It's useful
to know how that was accomplished. Briefly, there was a big, dumb switch
fabric and common shared resources. Resources included markers (which set up
calls), senders (which sent data to another central office to route a call),
trunks (lines to other offices), originating registers (which provided dial
tone and listened to dialed digits and tones), and some specialized units such
as trouble recorders (which punched cards), automatic line insulation test
units (which tested lines and phones remotely), traffic service position
system consoles (phone operator), and card translators (a clunky device for
looking up routes). All these resources were in resource pools, used in
rotation with broken units skipped. If anything failed, the call was retried
once using different resources. If the retry failed, the call was rejected
with the fast busy tone, on the grounds that if two tries had failed, a third
retry probably would not help. Everything had hardware timeouts, so if a relay
stuck, after a few seconds the unit would fault, a trouble recorder would be
seized, and the trouble recorder would drop a trouble card in front of a
technician. Major problems set off alarm bells. The most complex units, the
markers, ran in pairs, with one checking the other. Any difference generated a
trouble card. In an emergency, a marker could run without its checking other
half to keep calls going through.

It's worth understanding #5 Crossbar because it was a system far more reliable
than its components. It scaled up to handling entire cities, could be
maintained while running, and just did not have outages.

\-- Western Union Plan 55-A. This automatic telegram switching system handled
most telegrams in the US in the 1950s. Think Sendmail, built out of paper tape
readers and punches and a telephone switch, an email server that filled a
large building. The queuing theory for the ARPAnet came from Kleinrock's
thesis on Plan 55-A. Only a superficial knowledge of Plan 55-A is useful
today.

------
brianclements
The only ways people learn important lessons from the past is by 1) being
taught them by someone willing to teach it 2) overhearing someone else being
taught it, or 3) reinventing the wheel and learning it yourself.

If 1 and 2 aren't happening, then you can't blame people for resorting to
method 3. Perhaps some blame should go to teachers/curriculum, but bagging on
people for what they don't know only creates frustration, not progress.

An example from the music world. I've taught the same "wisdom" about voice
leading, what it is and why we like to use it, to both AP music theory
students in high school as well as middle school band students learning to
improvise. You can bet I change my analogies and vernacular to match their
knowledge, but they've both been exposed to the concept and have some core
vocabulary to research it further if they like.

~~~
jacobolus
You left off (0) doing your own research when you run into a problem. These
days, with search engines, google scholar, google book search, Wikipedia, IRC
channels full of folks trying to prove their knowledge, easy access to
professors’ email addresses, etc., it’s easier than ever before.

~~~
dikaiosune
It's easier to be overloaded by the volume of information too.

~~~
tcdent
It is unfortunate, but it compliments cognitive decision making well; ingest
information from multiple sources, identify outliers and inconsistencies, the
truth will present itself.

~~~
nickpsecurity
Not that simple. Usually leads to a local maxima that might not even be the
maxima it appears to be. Really digging into all the sources of wisdom in our
field takes a _lot_ of time. Most only have a subset of that.

So, expecting those with the wisdom to present it in an approachable and
efficient-to-learn way is reasonable. Only then should we critique those that
didn't make the effort to learn.

------
StillBored
Its called a literature search... and for some reason no one does it in
computing...

This reminds me that just last month I attended a talk on hp's "the machine"
where the presenter talked for about 20 minutes about all the revolutionary
new ideas, before someone broke in and asked "how does this differ from an
as400". After all the presentation looked like a copy paste job from the
wikipedia page on as400 technology. The poor presenter didn't know, and
eventually admitted he didn't even know what an as400 was. Much less than the
fact that they continue to be sold. In the end someone suggested a literature
search.... The presentation went downhill from there.

~~~
pcl
To quote Frank Westheimer: _A month in the lab can save a night in the
library._

------
ianstormtaylor
As someone who knows nothing about these technologies, I have to say the use
of abbreviations and acronyms in the post adds a huge barrier to even
_wanting_ to unpack the information.

It reminds of me Elon Musk's memo to SpaceX:
[https://twitter.com/collision/status/602950284864692224](https://twitter.com/collision/status/602950284864692224)

For example...

    
    
        SONET/SDH and ATM WAN
        ATM-to-the-desktop and ATM LANE
        MPLS Traffic Engineering
        BGP Brownouts
    

Or...

    
    
        I was trying to explain the principles of SAN and differences between FC and 
        FCoE to a networking engineer a while ago. I started with B2B credits in FC and 
        told him Fibre Channel uses exactly the same approach as hop-by-hop windows 
        we had in X.25, with the same results…
    

Of course, I understand that I'm not the target audience, and the author
didn't decide on the names for the technologies in the first place, and maybe
even that these acronyms are common knowledge for the target audience, but it
sure isn't helping information sharing if every sentence requires tons of
extra parsing for new acronyms.

The comments section gets even worse...

    
    
        None of our NOC guys know what ATDT means, even the ones that did come through 
        tech support. (PSTN is still more reliable than 3G for OOB, assuming you 
        test it often - anybody got a good automated test script?).
    
        ATDT - priceless ;)) Thanks for bringing this up! Now that I think about that, 
        I started with ATDP :D... and I'm positive there's AT command set hidden 
        within every 3G modem (in the good old days you could use it to send SMS 
        messages).
    
        ATDT is still alive!. Just setup a simple GSM/SMS based solution and used 
        AT commands to control GSM modem. It's really coll that this has not 
        changed over the years.
    
        I remember having a little BBS in 1989 using some BBS SW called pirate or 
        black beard or something like that for my Novell and Token-Ring customers 
        to dial in and obtain the latest desktop drivers for IPX and IBM NICs etc. 
        I love the analogies on the older tech and SDN. Especially IntServ...
    

At a certain point, I'd blame technologists who enjoy feeling smart due to the
barriers put up around the knowledge they've worked hard to earn, and who
chastise newcomers for not doing tons of work to slog through poorly
communicated concepts, instead of newcomers who would probably love to learn
more and don't know where to start.

We should communicate more clearly so that it's easy to share knowledge.

~~~
jnbiche
> I understand that I'm not the target audience,

Yes, that's it in a nutshell. People who work in the same field/sub-field will
use jargon to enhance/shorten communication. This has been the case for at
least several thousand years.

If you're out to rid the world of jargon, you've got quite a battle ahead of
you.

~~~
sdenton4
The point, though, is that these technologies aren't in use anymore, and
therefore no one new has a good reason to know the acronyms... There are
plenty of new acronyms to know, after all!

Ultimately, this is why we write textbooks, to consolidate knowledge for the
next generation. It may not matter if you know a particular historical
example, so long as you know the ups and downs of a given approach.

~~~
dsp1234
_is that these technologies aren 't in use anymore_

SONET/SDH - Still in use today (though not as much as in the past)

SAN - Storage area network. Basically any large enough organization is going
to have one.

FC - Fibre Channel, still one of the top ways to connect SAN and other storage
arrays.

FCoE - Fibre Channel over Ethernet, taking the FC protocols and moving them
over copper

B2B credits - Back to Back buffer credits. Knowing this is like knowing about
TCP window size adjustments or three way handshake. It's knowing about how the
protocol works over the wire.

NOC - Network Operations Center, the place where the network guys keep an eye
on the physical layer.

PSTN - Public switched telephone network. Think all of the hardline
telephones. It's that entire network. Still in use as my grandmother can
attest to.

3G - 3rd generation wireless (or at least the wireless carriers brand it that
way).

OOB - Out of band. Not using the normal network of a particular system. ex:
using a modem hooked up to the PSTN to dial out and send calls when a server's
IP network is down. OOB communication is very common as it provides redundancy
when all the "normal" stuff fails.

SMS - Short Message Service. Non-picture text messages.

GSM - Global System for Mobile Communication. One of the two leading wireless
protocols/systems. ATT and T-mobile phones use GSM.

AT commands - ATtention commands. A command language for manipulating modems.
Still in use in many phone radios today.

Basically every acronym listed is in existing use and generally still widely
used. So there is good reason for people who work with them to know them.

And it doesn't take a network technician to know what all of these mean. I'm a
lowly classic asp web developer, and everyone of these was familiar to me.

 _therefore no one new has a good reason to know the acronyms_

These acronyms allow me to talk with the network people. In the same way them
knowing what HTML, CSS, JS, PNG, JPEG, PS, etc are allows them to work with
me. It's not absolutely required, but it greases the wheel.

~~~
hueving
>PSTN - Public switched telephone network. Think all of the hardline
telephones. It's that entire network. Still in use as my grandmother can
attest to.

It's not that simple anymore. Now it's frequently packetized after the last
mile so PSTN is just an illusion provided as a service to your phone jack.

------
XaspR8d
As someone with no networking experience, that example slide and the following
paragraph could be parody for all I know.

That said, I really enjoyed RFC 1925:
[https://tools.ietf.org/html/rfc1925](https://tools.ietf.org/html/rfc1925)

~~~
techdragon
Since starting to build a networking software startup a year ago, that RFC has
become far less April 1st material and so much more "advice to live by".

------
c3534l
It isn't their fault for not knowing it; in the ideal world every programmer
would start out with complete and perfect knowledge of everything there is to
know about their craft. No, it's up to older people with more experience to
adequately communicate their experience to others. The responsibility of the
younger programmers is to know when to listen.

It reminds me of my father who, close to retirement, had to switch companies
led by a bunch of young whipper-snappers in their 40s. They had to solve
certain problems that many of the older people had experienced ages ago and
were really solved problems. But everyone was more interested in finding
creative solutions, rather than just listen.

I hear chemists have a saying that you can save two weeks in the laboratory
with an evening in the library.

Of course it's good to know these things. But there's simply going to be some
things you know more about because you grew up in a different time than they
did. That's not a real problem, that's just the way things are.

~~~
smacktoward
_> It's up to older people with more experience to adequately communicate
their experience to others. The responsibility of the younger programmers is
to know when to listen._

The hitch is that the younger programmers are chasing the approval of VCs who
actively encourage them to dismiss "older people" as clueless old fusts who
can't think at Web Scale.

(The VCs don't actually _believe_ that, of course, especially as many of them
are old programmers themselves. But since old programmers know how to read a
term sheet and tend to demand things like sane working hours and pay/equity
commensurate with their skill, it's in the VCs' interest for their portfolio
companies to be cults of youth.)

~~~
hueving
Something doesn't work in your thesis. If old thinking were that valuable in a
startup trying to make a new technology, VCs would insist on hiring some
seasoned devs.

One of the downsides of working in an industry for so long is that is molds
the way you think about problems. Things you deem to be critical might not be
anymore, etc. Things you've been burned by that you avoid like the plague
might be really useful now in light of new hardware.

When experimenting and building new things, years of experience can actually
be a pretty big burden that is hard to shed.

------
gfodor
Of course the corollary to the claim 'there are no new ideas' (which is
probably in line with this article's line of thinking) is that the only way
progress is made is when a previously bad idea becomes a good one due to
circumstance, and some naive fool comes along and tries it again.

------
developer1
A young audio engineer might know every possible fact about how Bluray, DVD,
and CD formats work. Probably even cassette tapes and Long Play records (aka
LPs). But I'm sure it's completely respectable for you to roll your eyes when
an audio engineer gives you a blank stare when you bring up wow and flutter
caused by a flattened pinch roller in an 8-track tape.

What would be the software equivalent? Insulting someone who starting
developing on PHP 5 not knowing about the short_tags() global function which
only existed in PHP 3? Someone proficient in Visual Basic .NET but doesn't
know anything about VB 1-6? There is no reason to know how to develop in an
ancient version of a language if every job you have had thus far has used
exclusively modern versions.

Merely having been alive during the decade in which an obsolete technology was
first introduced or was still popular means nothing. It may even have some
relevance today when discussing the then-and-now similarities or differences,
but frankly someone born decades after its obsolescence just will not care.
There is already more knowledge than is possible to absorb about _current_
technology. There is simply not enough time in a single lifetime to care about
what came 20-40 years before. Perhaps if we ever push life expectancy to 1000
years, we'll spend the first 100 years of our lives reviewing every relevant
detail of the past.

------
cubano
I'm somewhat surprised he doesn't just tell them to get the hell off his lawn,
too.

Acronym soup is such a 80s/90s thing...I for one am glad technologists finally
clued up and stopped that practice for the most part.

~~~
thwarted
Yeah, the cute mining and gemstone themed ruby library names, along with the
random word javascript framework names, are much easier to understand.

------
InclinedPlane
Who is to blame for this though?

I have a strong interest in the history of computing, but most of this sort of
stuff is squirreled away in places most folks wouldn't know to look. If you
want to learn history in any other field you go search for history books, but
a lot of this sort of stuff isn't conveniently compiled in books. Whose fault
is that?

------
idlewords
Can anybody familiar with these old war stories point us to a human-readable
writeup of them?

~~~
madsushi
Both relate to flow control and trying to deliver a lossless network medium.

Regarding B2B credits / Fibre Channel and the hop-by-hop windows in X.25, the
idea is that each hop has a counter of how many packets it will send to the
next hop without receiving an acknowledgement, which are "credits". Once
you're out of credits, that hop stops sending traffic. X.25 was
superceded/replaced by TCP/IP (which uses end-to-end acknowledgements, instead
of hop-by-hop) due to increased performance. But B2B is used with Fibre
Channel (storage) networks, which require lossless performance on each hop.

Regarding PAUSE frames and Ctrl-S/Ctrl-Q, the idea is that as a device's
receive buffer fills up (it is receiving data faster than it can remove it
from the buffer), it will hit its 'pause threshold', and it will send a PAUSE
message to the sender to let it know that it can't handle any more data. This
is similar to Ctrl-S/Ctrl-Q, which are XOFF/XON control commands in flow
control, to stop and start traffic as you ran out of buffer space.

~~~
angersock
Thank you for being the only person to actually write up what the hell the
author was alluding to!

------
rdancer
Dealing with people and organizations who don't take lessons of history
seriously is very easy: take note, and outcompete them without breaking a
sweat. Let them fail! This is one of the respects in which capitalism is
unequivocally a force for good.

~~~
vezzy-fnord
Unfortunately this does not at all apply to the software industry where many
advances can be dismissed out of incredulity, or a parochial reaffirmation of
the status quo either because of path dependence, or simply because of a
perceived achievement in local optimum and incapability of further
introspection. There are no scientific principles followed as such.

~~~
nickpsecurity
There's also the Worse is Better phenomenon now known as "ship early" or "time
to market advantage." They just try to get something going that works without
much time to think on it or research the history.

------
rco8786
You're frustrated and depressed that people aren't well versed in technologies
that died out while they were in diapers?

------
late2part
MPLS Traffic Engineering is a mistake and dead? Oh Really?

------
gopowerranger
In some countries, the children learn from the parents. The children never try
to teach the parents.

The TV show, "Modern Family", the daughter of the owner of a closet
manufacturing company tries to show she can contribute by offering her new
design ideas only to hear from her father that her designs are great cause
they did the same thing decades ago.

