[Novalug] Learning stuff (was: Posting Stories)

Walt Smith waltechmail@yahoo.com
Mon Dec 5 12:23:21 EST 2016


see inline:
I recognize much was written for general readers.
I merely would like to clarify what I meant in context,
although, I thought I had done so.

( as I mentioned, I'm sometimes doing editing from
a cut/paste from digest, especially if I'm not CC'd 
or the CC didn't arrive at the same time.  yeah, yeah,
again, I'm just doing what my brain is at the present...
and, YES, Peter, you always CC me !!! < grin > !!)


-----------------------------


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


>> And, it seems to be forgotten that there's not necessarily a
>> compelling reason to 1) start at the top or bottom.
>> The middle is acceptable with aside info and examples.

>I'm not sure I can find a lot to agree with here. To understand
>networking your starting point HAS to be at the bottom. Otherwise the
>different wrappers on each layer is going to make NO sense what so
>ever.
 
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.   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.  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.

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.  However, most
texts today are top down.  (I didn't say EVERY uni taught top down !)
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.

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

>> It's
>> complicated, it can be complex, it's an art form in
>> that there's a LOT of specifics to remember. 

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


>>but since those abstracts are
> >immediately implemented, is it really abstract ?
> >( this is WAY off topic ).

>Just because parts of an abstract idea gets implemented, doesn't make
>the abstract idea go away?  Or are you saying that Van Neumann's
>abstract ideas of a computer architecture aren't abstract anymore? 

Just because a person thinks it doesn't mean it's abstract.
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 !! >

So, consider a transistor in a VHDL chip that does compiling of
containers.  To me, it's real.  To a programmer, the molecules that make
it are abstract.    OK, OK, I didn't need another example...
moving on  -----> 

 >>And knowing what 
>> something Doesn't Do is important toward learning. 

>It's a rather odd way to learn since the number of "cannot do" is
>    [ damn !! classic yahoo doesn't have an undo button !! ]
>have the right tool or not based on what you want to do? You may not
>know the tool you NEED, but you'll know if the tools you have can do
>what you're seeking to do. I'm puzzled how knowing what it does NOT do,
>will help?  Or maybe put this way, by knowing what it does you know what
>it doesn't (everything else). So I don't need to enumerate the "doesn't
>do" features.

long setup...re: your last statement.

YES, you do need to know what things don't do.
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 ).

[off-topic]
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.  

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

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

WAY WAY off-topic   -- Sorry !!!!!!  [ I should snip all this 
before I hang myself before ya'll hang me -- or in addition to ...]


>> This made if more difficult for me reading existing  literature
> >online.

>Why not simply start with the type of features/functions that an
>(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.  


>> I've found a number of
>> things I think I want to do either cannot be done, 

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


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

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


In toto, I have snipped a considerable amount of material
( and added some ).  We agree, more than disagree,
on much of that snipped. Hence  its  not included.

(I didn't want this reply to end with 15 successive 
threads naturally appended.... thats for crazy folk.)

damn !! I missed the noon digest.
Hey, you guys are great therapists when you're courteous !!

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

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



thx !!

Walt.......


More information about the Novalug mailing list