[Novalug] Learning stuff (was: Posting Stories)
Sun Dec 4 21:57:06 EST 2016
Hey Walt and everyone else,
I'm trying to avoid another mega post, so excuse the initial top-posting
here. Sure there are different levels of knowledge, different levels of
expertise and our learning process also differs from person to person.
Some do best reading, others by doing, others again with a
mentor/teacher taking them through things. It's pretty much impossible
to create a "golden" approach that helps everyone regardless of where
the person is on the above attributes. This is why companies that
specialize in training exist - if it was easy we wouldn't need them.
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
really starts with the 7 OSI layers and some basics in how signals are
modulated to carry information. Otherwise, you're going to have nothing
to build your understanding of what ARP, IP, TCP, UDP etc. is - and if
you do study the OSI layers you'll notice that it's all about the
interfaces between them. So if the goal is LEARNING you've got to start
with the basics.
My approach in forums is to never _just_ answer the specific question.
I've done enough browsing of other people's post to understand the value
of explaining the situation, so others can gain benefit from the answer
too. And part of that is to set the context in which the answer is
given. I'm not always successful in this, but that's at least the goal.
And to do that, it's necessary to draw on the essence of what we're
actually doing as system admins, developers, hardware folks etc.
Now to some specific points ... (see below)
On 12/04/2016 02:19 PM, Walt Smith via Novalug wrote:
> ** An aspect I think should be expanded: There is
> configuration, which can be gui or specific fileFixes. The
> configurations depends on the network interconnections
> and use. Theory of the layers of OSI and matching to
> specific Linux commands are 2 different thingys.
> Knowing how commands/utilites work independently
> would be a little more fundamental before trying to do
> network configuration. Or in addition to.
It's not as much which command matches what layer, but it's explaining
how a concept like DHCP works. The commands tends to all be layer 7
(application) but then move their way down without really involving you.
But if you're not aware of how the DHCP operates, most of it's options
are going to make no sense what so ever. For instance, it's rather
important to understand that it's layer 2 as it means DHCP is limited to
a single subnet. Just like looking at the ARP table means you're looking
at layer 2 information - but as we all know, we rarely operate directly
at this level. But if that level doesn't work, NOTHING works.
> bottom up:
> packet/frame/transport theory
> network configuration
> 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. I'm sorry, but I don't see how you can explain IP (layer 3)
without ARP (layer 2) and for that matter, layer 2 without basic
understanding of layer 1.
Unless the end goal is not learning how things work you have to build
things up like that.
> Networking - or any widely used and developed
> computer technology - is NOT rocket science.
Hmmm - are you sure? Did you talk to NASA on how they manage to
communicate and control their rockets from earth? :) Kidding aside, I
think the level of difficulty is in the eye of the beholder. But I do
think it's in everyone to learn and understand.
> 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
> NOT abstract, it's not elevated theory.
Ehhh sure it is? Just because we have practical implementations, there
definitely is a lot of scientific theories behind computer networking.
But you don't need to get to those details. That said, I cannot see
Brocade and Cisco NOT evolving these theories in order to find ways to
pushing more bits through the wires, lessen overhead etc.
And it's abstract because there's nothing physical about a network
except for a wire. From a human perspective since we cannot perceive
electrons as mass, it's just a wire. So our whole foundation is
abstraction. The way you see memory is an abstraction and so on.
Everything the kernel do are abstractions?
> To answer a
> couple guys who need to counter: Areas Are for example
> abstract when abstracts are forced upon it by high
> minded thinkers in terminology: virtual this and that,
> containers, classes etc... 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? Or
Turring's writing that brought us the concepts for our computer models -
aren't they still abstract? How can you improve and have multiple
implementation if we don't start with one or more abstract ideas that
keep on moving? And how can you understand the implementation isolated
from these abstractions?
Or put in a different way - when we talk about IP, we're describing an
abstraction. Just like any data structure is an abstraction. It's that
abstraction we teach and need to know about.
But I get the idea that to you abstraction is something different?
> I think I defined that for NetworkManager from a persons POV
> with little exposure - whether by literature or friend consulting,
> who is a wanna be professional, or someone who doesn't have a
> presenter who can explain the textually written details, or someone
> not of classic academic grade A background.
The context here is important (which is why we quote what we answer -
including other people's aspects and input)l. We started this thread
based on using the "wrong" tools to try to manage networking
configuration. It's from that perspective, talking about what a tool
should and should not do, and making statements such as "lacks a lot of
features" become important because it's that perspective that's messing
up the understanding of what tools like NetworkManager does. In
particular because we started with just ifconfig and ip, and all of a
sudden NetworkManager is lacking even though it not only covers these
tools but a ton more. So yes, you were asked where to draw the line, and
how to decide what should and should not be included in a tool/utility.
That's a pretty fair question.
> 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
indefinite? If you know what a tool can do, you can easily tell if you
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
> I think my
> definition was reasonable. There's not a lot about how/what
> technology has been integrated or repackaged ( Wireless AP
> with 4 post router, swich, DHCP, firewall, MAc filter etc etc.. ).
> This made if more difficult for me reading existing literature
Why not simply start with the type of features/functions that an
(abstract) idea contains, and map those to tools? Why do anything else?
> My sentiments reside with the comment about about non-
> enlightenment. Thats my case with most of the literature, and
> as I do more, I find wikipedia seeming to become much more
> useful as their articles - many of which of at a PhD. level, or
> just containing no useful info, gradually move toward having
> just the right info --- as an example.
Actually, I use Wikipedia quite a lot - but unlike a lot of people I
know I use the references to move from the overview pages to the details
to get a full description of a topic. One of the features of Wikipedia
that's really helpful is how topics are interlinked. So a detailed topic
links to overview and puts it into perspective. And elsewhere in the
topic are links to more deeper types of topics. In particular for
technical topics, does this work very well. However, if you find
yourself on a single page expecting to find all the answers, then yes
that's going to be tough.
The OSI model is an excellent example of this:
Now, a topic tends to be touched on in details. It may be a very long
set of complex sections to explain the details of a specific concept,
and all you want to know is what the term means. That's why there's a
summary section and nobody says you have to read the whole set of pages
to just get that answer. Personally it's always a challenge because I
tend to want to know WHY things are like they are, so once I have the
summary and gotten a taste, I usually end up wanting to know a lot more.
> Articles are written by
> most - as I said before -- like every C book since Kernigan and
> Ritchie - are almost copies of each other. And sometimes someone
> writes in an additional example because it wasn't what They
> understood when they read it.
I'm not sure what books you're reading - but while I certainly recognize
that some books are more than "inspired" I do find a broader spectrum
out there. But if you want a description of a scientific topic, it will
in the end be the same description and even use very similar words.
However, you have choices - if you just want an introduction to a topic
for beginners, it's structure tends to be very different. But a thorough
description of a very well defined scientific abstraction/idea such as a
specific programming language, well in the end it's not really possible
to do that in so many ways?
Programming languages also tend to be very similar. When all is said and
done, structural programming languages are pretty much the same with
different symbols and syntax, however the artifacts/building blocks are
the same. Some languages may have more features than others, but we're
not talking about something completely different. So I would expect a
lot of similarities in the books describing languages like Java, C,
Perl, Python etc. But try to read about imperative languages like
Prolog and LISP and now you'll see the guide is very different, since
the language abstraction is so very different. At least for me,
learning the first language was the hardest. Every language after that
got progressively easier and easier.
> At the other end, is the desire for conciseness. Most material is far
> too concise.
Then don't read the whole thing. But I'm really curious, how is an
author going to know what features you'll need to know about if they
shouldn't describe it all? If you all of a sudden have 50 different
materials covering the topics each outmitting different aspects, which
source are you doing to use? Or do you need to read all 50? Why not
read the detailed guide, and just skip the sections you don't care about?
> As a reference., like man pages, thats fine. But many
> articles are written so a writer can sell himself, sell a product, or
> - IMHO - written for a very specific. case..
Yes! But that's done based on input like yours, that an abstract guide
is too difficult to understand. So if you cannot use a practical
example, and you cannot use highly theoretic and abstract guides to
describe something that is abstract, then what? The fact is, that we
are ending up with a lot of different "books" and sources for
information describing the same stuff over and over again, because
people are refusing to learn the theory to understand the concept that
writing use cases because straight forward.
But let's remember that man pages are a 40-50 year old technology. It's
pure text and no illustrations. Which is why user guides, wikipedia and
so many other sources out there in the graphical world, and it's
something books, magazines and web pages do a lot better. After all,
humans understand visually - so getting something beyond just words help
> 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.
> or are simply
> no written about, and if it it, it uses technology not in use today-
> whether program names, or options, or distro specific--- Ubuntu
> has made great strides in this area, and much of it's literature in
> now looked at be people using other distros.
Now if there hasn't been anything written about it, it cannot be written
by Canonical or the first statement would be false? I find too many
people just do a "google search" and grab the first page that shows up
not looking at the source. If you have a problem/challenge on CentOS,
why not search the Centos sites first (which means the documentation on
https://docs.redhat.com)? The associated mailing lists etc. - and you'll
find that while it may not have been high on the search engine rating
that it actually provides a specific answer with your platform in mind.
But I'm not crying over choice here. To me it's a great thing that we
have these differences. That depending on our own subjective opinions we
can find something that works for us. And it also gives us the
opportunity to see ideas we may not have agreed with, work or play out
> ** There was earlier discussion about man pages, and info is
> mentioned. I've read the argument about difficulties into
> converting man pages to another form, such as html. We're
> way WAY past that. If someone or a group want to continue to
> present in man pages or info, thats fine. It their time or money.
What's wrong with man2html? Man pages are actually linked so the
resulting html hyperlinks where the topics are referenced. But all that
does is help you navigate quicker from one area to another. The
text/content remains the same, structure and all that stuff is the same.
It's just the format that changes and as the content goes that doesn't
seem to matter?
> However, many web sites have the man pages in html which
> is much easier to read, and often contains links to the various
> other buzz tech words.
The man pages are still just man pages. However, do remember that a
when it comes random pages out there, do keep in mind that some are very
outdated, and as always keep your source in mind (use common sense).
> For a distro, it's time to move to all man
> pages to html. If the source is still "man page" ( whose creation
> is merely done from a text editor and often just fed into a script to
> format, ), then html is no beyond reasonabilty. Granted, I'm not
> personally involved in the process. But thats my POV.
It's just a format. This is what "info" (the command) does - it creates
a hyper-linked version of the text. I'm still not sure I understand your
argument. If the content is too technical and comprehensive why does the
format make a difference?
> html would solve the problem of links
The data is linked already? At worst, do as I do have just have two
windows, and type the man for the keyword you found in another window.
There are a few other methods to help with this, including the built in
Install man2html. Start your local Apache server, and then substitute
man with hman ... ie. hman bash
Have fun! It's already done - but really it's the exact same content as
the man pages.
> and contexts with additional
> input which Seem to be happening on many web sites. ( finding
> useful/recommended info is difficult but again wikipedia is moving
> quick to take up the distro's doc work.
Since wikipedia is collaborative, isn't that a good change? But note,
Wikipedia tends to not be specific to the distributions which is going
to make it very hard to understand highly integrated tools that differs
on each distribution and choice on installation.
> We've had calls for volunteers quite a few times for novalug.com - this
> is definitely something that could be done
> ** I was on this maillist for 10 years or so, and saw references
> once or twice to novalug.com and tux.com, and saw outdated
> web sites, and otherwise had no idea what they were for
> except of hosting the maillist.
Calls for volunteers are usually done at our meetings. If you're not
there, you've not heard them. The sites you mention have been
extensively covered at the meetings, including trying to find people to
help out. That doesn't mean they haven't been mentioned on the list too.
> And hence no reason to go visit again.
That's your choice.
> This is NOT a complaint. I realize that volunteers
> don't often maintain schedules or updates etc. I'm fairly passive
> myself and don't pretend to pull my fair share. For "newer" list
> members, this is merely FYI.
Again, context here is important. We've looked for people to help make
these kind of changes that's being talked about here. It's extremely
easy to make it someone else's problem - but somehow the priority
changes the moment people have to invest their own time and resources.
> A fear is one of getting dumped on
> if one volunteers, or dropping the ball and looking irresponsible.
> ( obvious social group difficulties ). It's also true that dividing up
> the work into really small segments and changing who does
> it based on family or work responsibilites helps. ( G A W D !!!
> who am *I * to say this !!! )
Well, if you want change that's only going to happen if you take a
chance. But as Greg so often says, we're a group of very friendly
people, so it's a great group to take those chances with.
> ** agreed !!
> man pages don't teach - they're concise ( VERY concise in most cases ).
> RHEL are closer to being User Manuals.
And yet, you spend quite a bit of your post saying that as long as
they're in HTML they're helpful?
> To take a somewhat experienced
> person in an enterprise environment and help out.. Written VERY much the
> same way as distro Manuals for Irix/SGI, DEC, etc. The assumption is you
> already are experienced or are in an environment with a "Senior"/mentor,
> or were a straight A academic in school. Remembering back to their
> early days and getting the perspecitve right often doesn't happen ( poke poke ).
There isn't a lot of "fluff" but to say you cannot learn from the man
pages is a bit of a stretch. But yes, they're not written as
introductory courses in whatever topic you find. As I wrote, that
training/learning comes from somewhere else. The man pages are there to
understand how to use the commands of the system. No more, no less.
Regardless of how you present the text in the guides. That said, they're
extremely useful when it comes learning the details of a command,
library and feature.
> We must remember BOTH the arrays: the breadth of the written data,
> the depth of the written data, and the depth of experiience of employees
> and casual users. ( I'm realizing I'm sermonizing -- sorrrry ! )
Not sure I understand here. So far your solution to this "problem"
seems to be to present it in HTML. How do you propose fixing this? How
can you write to X degree of complexity and knowledge?
> to tell the truth, I forgot or chose not to remember how to insert all
> the ">" at line start in any editor etc... so I did it all manually....
> kinda pathetic right ?? Just shows how MUCH you have to remember !!
> Over 50, one idea goes in, two more drop out.
No need to remember if you use the "right" email client like gmail,
thunderbird, evolution etc. Actually I have a hard time thinking of ANY
mail client I've used over the last 25 years or so that didn't
automatically quote emails "correct".
More information about the Novalug