[Novalug] Learning stuff
Tue Dec 6 21:57:46 EST 2016
On 12/05/2016 12:23 PM, Walt Smith wrote:
>> So that brings me to the essence. I don't think Walt is right around the
>> expectation that theory doesn't matter. Unless what you're looking for
>> is someone giving you the answers (support) to understand what you're
>> doing you've got to understand the basics, and for networking that
> I never said theory doesn't matter. Not at all !
> Depending on the starting point, theory can be
> introduced depending on the level, topic, context and
> student's questions. Theory can be added as a topic
> progresses. I think I'll give an example later,
> it I find the right section below.
Again, you cannot understand the practical implementation without
understanding the theory. Otherwise it's just learning a specific
method/commands without understanding why it works that way, and hence
you cannot diagnose or move on, since it's all just gibberish.
We can discuss the degree of knowledge needed, but not if it's need.
> OK. I've heard the argument about top/down or down/top for design
> since, what, late 1970's ? Not all designs - or teaching - is done with
> one approach.
In the case of computer science, if your goal is understanding then
that's what you'll need to do. Otherwise you're just building air
castles building on assumptions and features you don't understand. Now,
that is at times what we want. Ie. developers these days rarely want to
understand what "memory" actually is, file systems etc. - I find quite a
few programmers don't even have a clue what an inode is on Linux. In the
end, it limits their ability to be very good programmers, but since our
goal rarely is to educate people to that level, then we make shortcuts
> I've come to the conclusion that many types of
> projects (I use the word kinda generically- education, writing, design,
> build, debug ) are better starting at both top and bottom simultaneously,
> often with two different teams, sometimes the same team, or client/student.
> Staring in the middle is quite usual.
There's the pedagogical methods of how to teach to a specific target
group, and then what's eventually required for the understanding of the
topic. Introduction and building a set of concepts can start all over
the place (I really admire how teachers can do this) but in the end, if
you want to understand how DHCP, IP and DNS works, you have to
understand basic networking principles and theories. Otherwise you'll
never get why routers and switches are different, needed and what roles
> Ask anyone involved in a hobby when
> many people at different levels and interests come together. From
> the middle, questions, or project necessities often require a look
> up or a look down.
You start somewhere - absolutely. But to understand what you're
reading/doing you dig DOWN. If you knew the subject you could start from
the bottom first, and not have to navigate back and forth as you go
through a topic. In the end, you have to get the theory enough that you
can draw the lines the ISO model talks about.
> As a matter of more direct interest, a teacher I know who taught networking
> ( mostly theory ) believes that the textbooks decades ago were written,
> as you desire, teach subjects from the bottom up.
I cannot say I've read every book out there. My typical technical
literature always had a preface that explained the level and assumptions
of knowledge to understand the text. But clearly not every text book
would cover every fundamental aspects. That said, I did grow tired
having to skip the first few chapters of every book because they all
laid out the same theory.
> However, most
> texts today are top down. (I didn't say EVERY uni taught top down !)
That would explain a lot given the "talent" I frequently see :(
> But certainly, the formalization of RAD ( rapid application development )
> awhile back made tools that start at the top, and the development
> OF THOSE TOOLS continues to migrate upwards.
RAD is so 15-20 years ago :) But yes, as I stated above our programming
languages have become more and more abstract, and most programmers today
doesn't really know what makes the code work or how to write efficient
code. The market has made a choice here and picked getting a lot of
shallow programmers vs. fewer deep ones. And that may work, as long as
the team has the deep people - those who understand the theory - to lead
I'm not saying people aren't teaching top down, in networking and so
much more. But we started this discussion based on wanting to understand
tooling, and that's where the theory, layers etc. comes in.
> I am NOT saying that understanding layers bottom up is not useful !
> It's just today, things went the other way. No one writes sockets anymore.
So you're no longer using "netstat" (or ss as it's called now)?? That's
what it shows? I think it would depend on what kind of programming
language you use. C and Assembler programmers would definitely disagree
with you. And technically everyone does sockets - most people just don't
> Calls to sockets, maybe. but not the actual low level socket.
> So we need maybe 9 people in the entire country who know how
> to write a socket ( a bit of hyperbole ).
So let's make this simple - no socket pair, no network connection. As I
already stated, you're listing the active sockets when you type
"netstat" or "ss". The "ss" folks even had a sense of humor when when
they wrote the man page: "ss - another utility to investigate sockets".
Also, how do you explain SSL without "socket" since it's part of the name?
>> This may be a more personal experience, but I learn/remember much easier
>> by understanding how components 'fit together". It makes it a lot easier
>> to remember how each component work as it has to fit within the total
>> scope of things. It's not (just) a massive amount of discrete facts -
>> but because there's a synergy involved, that helps memory and how to
>> apply the knowledge. It also makes it relatively easier to expand on the
>> knowledge later.
> Thats exactly where I'm at right now. Trying to tackle 2 years of networking
> courses into a couple months.
Good luck on the cramping :)
> The hard part is -- as you said --
> knowing how then pieces fit together - and filling in some theory.
> ( at least, thats my description. I started with no goal, nor knowing how
> long or much effort I wanted to spend. I have no obvious reason to
> do it.
So as my earlier post said, we learn differently. I remember best seeing
connections and relationships between objects. To me, it means there's
less to remember by heart as the connection induces a lot of knowledge
indirectly. Others may find words or video easier to remember. Anyway,
it's these connections that leads me to ever new discoveries.
As to no goal, can we presume your initial goal was to understand the
subject of networking better? It may have changed, but there must have
been a reason you got started on this journey?
> Just because a person thinks it doesn't mean it's abstract.
Depends on what they think :)
> Although, it may appear that way. This is tough to justtify
> I agree. However, from my POV, if a person thinks it, and
> it's implementable as a real device, or already implemented
> or physical, it's not abstract. But there
> again, get a patent ? OK, OK, this is arguable. In context though,
> I don't regard electrons as abstract. A portrait painter may.
> Now, consider virtual ports in a frame.... < smiley !! >
I'm mighty confused by this. It's all over the place. Ideas are
abstract. We can implement ideas (in different ways) but it's still an
> long setup...re: your last statement.
> YES, you do need to know what things don't do.
No. If you have the list of concepts that is covered by an idea, by
definition you have the list of everything that it isn't? If it's not on
the list, it's not covered? What I think you're thinking about is a kind
of matrix where you have multiple concepts and ideas, and need to map
them together. Still, you concentrate on what things are, and all the
holes you have left over in the matrix is what it's not. So you don't
have to work on creating it.
> As I've mentioned many times, and to paraphrase
> differently, unless you're a genius with a photo memory,
> you often discover what doesn't work: for example,
> every mistake you make is that experience. Oh, it may
> include the fingers typing a wrong key, but it was still
> what you did. OR didn't know ( tired fingers ).
But you don't need to enumerate it. Once you have your topic defined,
you know what it's not by inference. Otherwise how do you limit the
"what it is not" list?
> Anything acquired experientially is finding what something
> didn't do. In my case, I find the myriad of Windows networking
> windows to be confusing, and haven't found a "menu"
> that exactly fits my tasks. OK, drill a hole. But I find that
> people without any hint of understanding about "misunderstanding"
> in speech, or text, or content is a graphical window to be
> argumentative, or overly concise, and limited in what they
> can offer. And often quickly quit attempting to solve a
> problem when it's not soluble in a textbook sense.
You're confusing the process with the end-result knowledge?
> I'm NOT trying to be personal, here, on this ONE character
> trait. Although it may seem that way. I don't know you or
> anyone else personally. It's based on
> close contact with "smart guys" on many jobs.
I learned pretty early on, that we all learn and remember differently.
The smart guys included in that. So I wouldn't say that my experience
should be the one everyone else have to share to "know". Just the
opposite - because we learn differently, we can still learn from each
other - smart or not.
> [ I also disagree that people with soft skins need to
> a develop thicker one. I've got a much thicker one - now.
> But civility and courtesy are good if one wants inclusion.
> Although, running an Army or being president or a shark
Not sure about the context of this. That said, if you have a tendency
to be very cold, you probably shouldn't try to swim in the ocean. Same
way with "thin skin". If how people respond is more important than what
they respond, then posting in an online forum probably isn't a good
idea. Unless you're willing to change.
> in Facebook, or corporate law certainly fit the environment.
> Several maillist/blogs I've been on ( as everyone one else
> has ] have been extremely crude. ]
As someone who is very interested in learning about other cultures and
have had the pleasure of getting to know people from all around the
world online, I can tell you that what goes as civility and courtesy
changes by just moving across a border. It also depends on your
educational level, and life experience. So while the young 16 year old
may seem rude to you, it may not be the intention. And it's up to you to
decide if that should change the dialog. And of course you've got all
the right to do that. But just because you feel something is "right" in
a certain way, doesn't mean that's shared by others - and that's
important to realize in a forum full of people with all kinds of people,
backgrounds, ages etc.
Let me use an example. In speech, Danish and German are getting less
formalized, but the written part of the languages still have a lot of
formal phrases. In person, meeting an elderly person you would
automatically change your language to fit the older formal way of
speaking as it's considered rude to be informal. Now, online that's
pretty damn hard to do since we cannot see the age of those we speak to.
And if you speak formally to a young person you're not taken seriously -
and visa versa with an elder. Someone has to give - and in the end, the
elder generations slowly realized it wasn't rudeness when their grand
kids didn't use the formal titles. So when I grew up I was often
considered rude online because of that - even though that was not the
intention. I know it's crude, but to me it illustrates a basic
generational gab which caused issues when it came to being polite and
proper online. Why not simply start with the type of features/functions
>> (abstract) idea contains, and map those to tools? Why do anything else?
> agreed. except for the "why do anything else".....
> I started to read an article about how to do switching in
> linux. I was mildly curious up to a point, about the generral
> mechanism, programs/daemons, and options. Right at the start,
> the writer went into VLAN and a few other choice words
> that were technically correct, I'm sure, but only another person
> who already knew the theory and concepts and only needed
> a few pointers could understand it. I think it was written
> for the 15 year sys admin sitting next to the writer, but was
> not given as a pre-requisit.
There are lots of bad technical books that are all over the place. VLAN
isn't a basic initial concept but of course without actually seeing the
context (the book) it's really hard to tell why someone would bring that
up. Of course if it's not a beginner book, it may very well be a proper
thing to do.
> I've never found such a topic yet. I'll love to hear about it. In the
>> end, given enough time everything is possible.
> I'm not buying this one at all !!!
Imagine you had indefinite time and money. What couldn't you do?
> Quite a bit was written. I'd only like to repeat that man pages
> and info should merely go away totally, and distros supply
> the html form. ( As I mentioned, this is already done on web sites ).
Not written by me. You wanted html versions of man pages, and I told you
that you already had them. Given the huge majority of systems that
aren't online, and systems that won't provide you internet access,
that's pretty much a dead idea out of the door if you ask me.
> OTOH, I don't do any remote text-only maintenance, and
> perhaps one form is needed for reference by those who
> do that. Perhaps on "servers". As for my workstation ........
Yes, and much more. What if your problem is that you cannot get out of
the network? Why wouldn't you want documentation available offline?
> and yeah, I've been with FRIENDS in heated arguments
> and still friends and beer drinkers. Unfortunately, I don't
> know you guys personally, so I choose not to curse, swear
> --only a little -- call people names, yell YOUR WRONG 15 times,
> say you're ugly, stupid, or any such non-sense. Now, if I
> had a list of you guys who KNOW each other THAT WELL,
> I could get it !! I'm getting to know Larsen !!! No matter what,
> always trying to help and see bigger pix..
In my 30+ years online I've gotten to know a lot of people whom I've
never meet in person. Heck, I meet my wife that way too. There's nothing
preventing you from getting to know people using forums, IRC, IM and the
tons of other means we have online these days. Back in the days it was
text only :) It takes energy just like "in real life" to make
However, it makes it a lot easier when you meet regularly like we do
here in this group.
> I'm wondering when he's going to re-write his volumes into an
> online hit reference manual ? Hell, he only needs to reorganize
> and do some editing !! At one time, 15 years ago, I made a list
> ( much of which Larsen addresses now ) of things I wish
> they had told us in college ( or the first week on the job.
> -- and I don't mean tech specific stuff ....
I try to help in other ways than writing books. Trust me, you're not the
first one to suggest it. However, practical technical books are usually
out of date before they "hit the press". I'm considering making more
blogs etc. but really, I have little time as it is ....
More information about the Novalug