The Lack of Historic Knowledge Is Frustrating | Hacker News Reader

The Lack of Historic Knowledge Is Frustrating

blog.ipspace.net

87 pointsvezzy-fnord76 comments

> 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.

To be fair, you have a point. Most of this knowledge is buried in poorly indexed or in some ways restricted vaults of papers in the ACM or various foundations, institutes and research universities. Some form of search engine for digging up prior art in CS and systems research is in order. A one canonical and easy to use resource for programmers and architects to look up before they go off reinventing flat tires.

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.

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.

"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.

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.

" 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,""

I get that and mostly agree with it. Exception being the people who learn best with the help of others (esp face-to-face). They don't learn the hard stuff well with text but they're valuable once they learn it. The other exception would be the topics where having a pro at hand can greatly simplify the learning process mostly due to nature of topic itself.

In most situations, you're totally right. People just aren't putting in effort. I think the stuff with lots of historical baggage of unknown usefulness seems like unjustifiable effort to many in IT. So, I don't throw them into that category if it's such a thing rather than their own skill set. Now, if they didn't know essential networking skills and griped that nobody told them, I might link to your comment followed by a back hand.

> 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?

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.

There are an order of magnitude more failed technologies than there are successful ones and learning all of the successful ones is already a gargantuan task. Just because some crotchety old guy watched a particular one go up in flames doesn't mean that everyone he talks to about a concept needs to be subjected to an analogy only relevant to one failed subject.

You are misunderstanding me if you think I suggested that old people need to educate young people. I'm suggesting that if concepts cannot be distilled from the technology and discussed on their own merit, don't bring them up because it means you don't actually understand them well enough.

This guy is mad not because people couldn't understand concepts, he is mad that they didn't get his archaic analogies. It's like a car guy calling an engineer stupid for not know what engine was in a 52 Chevy.

So he's a "crotchety old guy" with an analogy relevant to just "one failed subject." You have absolutely no respect for your elders, do you?

Also, the second sentence of your second paragraph makes no sense to me.

>You have absolutely no respect for your elders, do you?

No, I have no respect for people that offer analogies via obtuse references and then look down on you for not getting it.

I'll give you that. Someone called me on this in a security discussion by recommending people get a glossary. The terms were all recent and modern in this case but mainstream crowd apparently wasn't aware of any of them. So, I went back and explained each one so the reader would have context in the previous post. The vote count indicated that worked better.

That's happened enough that I sent out a recommendation to a bunch of people in high security industry to straight up drop our terminology when addressing a wide audience, look up what they call everything we talk about, and go through a major revision process on each post to translate it to their language. Might be able to get adoption of some of the techniques that already solved so many problems but just have no awareness or willingness to understand how they're normally presented. Not sure how many are going to do that rather than say "it's not our fault they didn't Google (topic) 101 to get the basic terminology and foundations."

I feel revision and avoiding acronyms particularly will help us but transferring the wisdom will still be an uphill battle. Especially with the Silicon Valley startups...

Totally agree with everything you're saying, but I would point out the the article is not about addressing a lay audience, it's about addressing network engineers who are supposedly lacking some historical/technical knowledge of their own field of work.

I expect network engineers to understand what they do day to day. Do they really need to understand the whole history of the field to do that? Mostly not: just specific things necessary for their jobs. Our economy and resources are sort of rigged in that direction. So, we might need to use a preemptive solution where we present various principles, tactics, pro's, and con's to them rather than a full history lesson they'll think is useless.

Ideally, they'll learn it all. I've learned the world is rarely ideal. Need a practical alternative to ideal...

That's just it, those who do not understand history are doomed to repeat it. By not learning about it they will make poor day to day decisions which lead to the exact same mistakes decades later.

It's true. Most of history is probably useless, though. So, you need to know which parts to learn. Most people getting into network engineering don't have 5-10+ years to figure that out on top of work, family, fun, etc. So, the most relevant parts of history of a subfield should be accessible in a way that doesn't require that level of effort. That's like making people studying mathematics, mechanical engineering, etc look through every ancient manuscript and writing to unearth the best principles and techniques for their field day-to-day and project-to-project. Makes no sense.

And this is coming from a guy whose gone to the extreme of studying everything in several sub-fields of IT: over 12,000 academic or professional papers in my archive on top of the books, etc. Skimmed most, fully read some, and re-read a tiny few (gold mine). Took a long time to get to that tiny few. No justification for that except that generation made little to no attempt to get that stuff to me in an accessible way. And now my generation is repeating the mistake for the next.

Or do you really think it's optimal that every learner have to spend 3-5 years per sub-topic digging through the whole of knowledge on it just to find the few things that might pay off?

Do you keep track of your gold mine in a list somewhere? Would be interested in looking at it. :)

Before I can wholesale share it, I have to go through to figure out which ones are locked in to ACM/IEEE to exclude them from the list. The rest are [mostly] disorganized because I started pulling them in batches of 20-100 a day. So, there's a little work to be done there before I can publish them.

I've saved your username and email somewhere so I can notify you when I get around to doing that. What topics are your core interests? My main focus is high security IT and software/system verification with a number on programming, hardware design/synthesis, software engineering, networking, databases, filesystems, OS's, and high-performance computing. Might send you a few samples of each in your interest to let you see the kinds of things people overlook. I should have time this week.

I sent you an email (the one linked to your HN profile description) on the subject. I hope you get back.

As far as computer disciplines go, my core interests are in language design, distributed systems design, software engineering, security, string and graph algorithms, high performance computing, OS and filesystem design. Aside from that I have interests in genomics, nanoscale optics, and AI/ML.

Thanks for the offer!

It's not about spending 3-5 years learning about the history but actually believing and understanding that that history has value. It's the ability to regularly ask the question "is this a solved problem" and actually be willing to work to figure it out. This is what I feel is missing with a lot of the younger engineers I interact with.

"It's the ability to regularly ask the question "is this a solved problem" and actually be willing to work to figure it out. This is what I feel is missing with a lot of the younger engineers I interact with."

I agree with you on that. Many don't have that desirable trait. They'll miss out on greater things because of that. Another thing worth study and effort is figuring out how to teach that mindset to young engineers.

Once they have it, then they need the organized presentation of our fields that I'm arguing for. Both the will/mindset and resources for learning are necessary for best results.

Nick, (this is a reply to your post at the same nesting depth, as we're at the max here)

We're pretty much on the same page on this whole thread, but consider the idea that perhaps the fact that it took so many years and thousands of papers wasn't because the previous generation didn't organize them well, but was simply due the the sheer volume of information. That time wasn't wasted sifting through irrelevant stuff - you're now an expert.

On the contrary, I think the writers and organizers of all that material did a great job; both of us owe nearly everything we know to them.

Replied here:

https://news.ycombinator.com/item?id=10420017

@ brianmwaters_hn

"took so many years and thousands of papers... due to the sheer volume of information. That time wasn't wasted sifting through irrelevant stuff - you're now an expert. On the contrary, I think the writers and organizers of all that material did a great job; both of us owe nearly everything we know to them."

I agree there's a lot of material, the learning process was worth it, and there's even more to gain. That said, the learning process taught me that a tiny, tiny fraction of those papers taught people 95+% of what they need to know for their sub-field. We need that information packaged, well-presented, and widely distributed for each sub-field. People wanting to learn more can volunteer time to do so. All I'm pushing for is that baseline packaged and ready for newcomers with few to no obstacles. Right now, it's hard enough to find that most don't. Gotta change that.

>Do they really need to understand the whole history of the field to do that?

That marks the difference between being a technician and being an engineer. A technician just needs to know how to do their job, whereas an engineer needs to know why they need the technician to do their job.

I still repeat the same question to your answer. Most engineers don't need to do near as much digging as many IT people do to understand the important stuff behind their field. For instance, despite all that's written on HW design, my research found that most of the key stuff (including insightful wisdom) can be found in under 10 books that properly transferred both knowledge and wisdom with minimal extraneous information. From there, it's years of experimentation to make those things habit and better understand why they're true. I discovered them with some Google perseverance but also because pro's were recommending them while explaining what wisdom each contained.

That could be done way more easily in networking. Should be done if it hasn't already. If it has with key resources, they shouldn't be so obscure with people like that blogger readily linking to them as I've seen in engineering fields. Don't make people wade through endless papers and histories of bureaucracies' decision-making processes to determine one technical report's worth of important design guidelines and justifications. Give them the good stuff in a way they know it's the good stuff.

"If you want your son to throw 50 yards, well... GIVE HIM... 50... YARDS!" (Vault drink commercial)

And, heck, it can even be presented in a time-ordered fashion where they learn some of the past as they go. They might start with a certain type of medium, the protocol for it, the issues, the solutions, and key things to learn from that which might apply to other situations. Then the next and the next. All the way up to samples of cutting edge stuff* at the end to make it memorable with an awe factor and exotic, weird stuff from our history sprinkled throughout just to hold attention (but also teach).

* A book on supercomputing got me more into networking than networking itself. The ultra-low-latency, high-bandwidth, cross-bar switches blew away anything I used. Plus, they in theory let many cheap nodes become a machine with CPU's, RAM, and graphics cards of a SGI Onyx2! To do it, though, I needed to understand the effect of wires/optics, host connectors, host protocols, cross-bar designs, topologies, cache-coherence algorithms, and so on. Quite a lot but quite the motivation. Never got to Onyx2 level on a budget but lessons gave long-lasting capabilities: topology, Beowulf clustering, single system image, clustered filesystems, Active Messages, reliable UDP (eg UDT), and discovering NUMAscale's products after typing the concept (NUMA) and connector (HyperTransport) into Google. One or two badass technologies along with justifications went a long way, eh?

Example would be me studying ancient NSA computers to find one used mercury for RAM. The concept of buffer overflow became more memorable as the story brought to life the consequences they endured: mercury exploding out the computer. Crazy stuff we'll never encounter but I still remember it & it reinforced preventing overflows.

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.

> script SSH sessions

Using TCL?

I sort of remember ATM from descriptions back in the early 90's. Seemed like just the thing if you were a Telco wanting to efficiently send voice packets coast to coast and over-charge the customer for each and every bit. As a protocol for sending cat pictures and porn, not so good.

Friend of mine in industry referred to the conversion between IP packets and ATM packets and back as a meat grinder. As in your packets get chopped into bits sent over the wire and if you are lucky all bits make it through and you get a fully assembled packet on the other side. If not you get to retry the whole packet again. And of course you get charged for ATM packets even though you couldn't use them.

I think Cisco added an option where if you were using their equipment on both sides you could turn off the IP to ATM packet conversion. Which everyone immediately did. Sayonara ATM.

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".

ADSL is ATM, so not entirely dead yet.

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.

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.

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.

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

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

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.

Or you disappear down the rabbit hole and you find that 9/10 of the tutorials / references you're reading are completely wrong or outdated.

Seriously, I don't know if it's as bad in the network world, but I reckon PHP tutorials were the reason SQL injection was as prevalent as it was.

You run into a bootstrapping problem: The information you find first determines which information you see as credible later, so you might end up having to unlearn a lot of bullshit before you actually get up to speed.

A good teacher will, if nothing else, get you over that hump and pointed in the right direction with the right instincts about who to listen to and which information is both correct and up-to-date.

For knowledge and facts, I mostly agree. I would add that doing your own research is what you do while attempting method 3 and get stuck. But I think the article, and my original point, was about subject area wisdom. The larger lessons behind past failures, and the stuff that can save you unnecessary detours. There is much value in digging into a problem for a long time; you really do own it. But some things are just a waste of time to learn that way, and are better primed with the guidance of someone who can present that collective wisdom to you in a way in which you understand.

Sometimes teaching won't focus on failure modes that much.

They might teach you intrisnics of some outdated technology as if it was alive and give no hints on why you no longer see any of it around. Pure waste of time.

I had a course on IBM SNA like that.

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.

Those keep getting reinvented haha.

To quote Frank Westheimer: A month in the lab can save a night in the library.

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

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.

> 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.

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.

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.

>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.

OK, now explain ATM-to-the-desktop. Not what, but why: I know what ATM is, I just don't understand why I'd want an internal networking protocol designed to mix voice and data transmissions using short cells running right to my desktop.

If we're going to do the 1980s Telco solution, isn't ISDN the service I'd get to my desktop?

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

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".

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.

> 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.)

This may be, but then you should single that out as a problem, not place it on the relatively inexperienced not knowing the things you know.

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.

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.

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.

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.

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

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?

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

The impression I got from the article is sort of the reaction to not understanding some facet of social justice. It's apparently your job to educate yourself.

It's a big firehose, but McDsyan-Spohn "ATM Theory and Applications" (ISBN-13: 978-0070453463) from 1998 covers the general principles extremely well. There have obviously been entire technologies that came and went since, but the first few chapters do a remarkable job of drawing up all the evolutionary pressures.

Since it's so old, it's also pretty cheap.

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.

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

thanks for the explanation, it's a rare skillset to be able to explain technical stuff on sort-of layman term :)

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.

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.

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.

It's almost as if the GP's 'capitalism!' explanation is just ideology and doesn't stand up to the real world.

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

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

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.

Reply on news.ycombinator.com