Chad Perrin wrote:
> I've strapped on my asbestos overalls.
Ut oh...:)
> Ultimately, you'd be better off to learn everything, of course. Nobody
> has that kind of time, though, so you have to make some decisions. As
> others have noted, there are "religious wars" associated with many of
> the questions you're asking.
Hmmm...the more that is suggested the more begin
to wonder if it's those wars that turn some away
from Linux? Tackling the system is daunting enough
for a win user, but then to be confronted with all
the contradictory info and opinion...perhaps they
turn right back and decide to put up with the bsod?
That hasn't been the case in this group..wiser
people ...:)
I'd like to think that the questions I'm asking
would be typical of a newbie....one could almost
edit this thread into an FAQ of sorts explaining
the religious wars and such...
Armed with that knowledge going in the new convert
would be less likely to "give up"?
Or does any decent Linux book cover that up front?
<shrug> Just speculating here...
> vi vs. emacs:
It seems that the GNU crowd has embraced emacs
fully, is tht correct for the most part?
> There are better T-shirts
> available for vim, though.
LOL...:)
> vi vs. vim: These days, unless you find yourself at a really old
> system, vi means vim.
Or you're using a micro distro like I am...it only
has VI...I imagine tht was for size considerations....
> perl: This is a programming and scripting language.
And it's the prgramming aspect that sets it apart
from PHP correct?
>(By the way, if
> you're going to discuss Perl, it might be useful to learn about
> capitalization. Y'see, if you say Perl (first letter capitalized),
> you're talking about the language, but if you say perl (all lower-case),
> you're talking about the interpreter. Calling it PERL is something only
> the uninitiated do, pretty much.)
Thanks for the pointer! Oddly, I could decide when
typing it which way i wanted to do it...but now
that you mention it it would have been all caps or
all lc...:)
> built-in: Basically, nothing is "built in". That's not strictly true,
> but it's true "enough" for a beginning assumption.
I guess when I say tht I mean "compiled in" as if
by default...IOW, it's something accessible in the
kernel?
(I'm not a programmer so when I talk about this
stuff I'm guessing...LOL)
> Anything with which
> you, as a computer user, actually interact can probably be assumed to be
> a utility, server, application, et cetera.
And it(they) in turn interact(s) with the
kernel...correct?
> Each job,
> often, is done by one tool, discrete and separate from all other tools.
> Complex jobs are broken up into individual parts and delegated to other
> tools by a tool whose job that delegation is, giving the illusion of
> integrated functionality in one piece of software.
Sounds like OOP..:)
> Hopefully, this answers some of your questions (both explicit and
> implicit). I'm sure someone will disagree with some of what I said,
> though they'll probably do so politely here.
Yeah, that clears the fog a bit...thanks!
> --
> Chad
>
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:38:16 EDT