hpr-knowledge-base/hpr_transcripts/hpr4206.txt

Episode: 4206
Title: HPR4206: New to GNU/Linux resources.
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4206/hpr4206.mp3
Transcribed: 2025-10-25 21:23:21

---

This is Hacker Public Radio Episode 4200 and 6 from Monday the 16th of September 2024.
Today's show is entitled New to New Linux Resources.
It is hosted by some guy on the internet and is about 28 minutes long.
It carries a clean flag.
The summary is, Scotty talks about resources for new Linux users.
Hello and welcome to another episode of Hacker Public Radio.
I'm your host, some guy on the internet.
Today I want to be talking to you guys about two resources that I think are just excellent
for new to Linux users.
Now new to Linux, how I'm using it here does not mean new to computers.
If you're new to computers, I am not equipped to assist you.
The people I have in mind here are, people who may have built their own PC, their Windows
users or maybe even Mac users, have been using computers for a long time, they're not afraid
to tinker with their systems.
And maybe due to frustration of their current system, you know, Windows 10, remember when
Windows 8 switched to Windows 10, the frustration that caused, that's one of the reasons why
I came to Linux just terrible.
Same thing now, Windows 10 going to Windows 11, then I'm trying to build in language models
directly into the operating system, just, I mean blatantly making clear that they're
going to drill down and spy on every single aspect of what you the user has, again, I'm
going to untangle.
Let me not for whatever reason, for whatever reason you may have for wanting to try Linux.
I feel like the people who are willing to go get a thumb drive, grab a piece of software
that allows them to make that thumb drive into a bootable media and then try out or install
a different operating system, you know, a completely new environment.
Those people are ready for everything I'm going to introduce here today.
So kid gloves are off, we will be talking about terminal resources as well, I recommend
the terminal for new to Linux users, I understand that some others that speak about new to
Linux users, they recommend things like Ubuntu as a operating system and then they'll include
with that how you do not necessarily need to use the terminal whenever using Ubuntu.
I'm going to skip that 100% because you came to Linux for a reason, you understand,
you came to the links because you either felt for me, I did not feel like I was the administrator
of my own computer, right, I built my computer, I feel like I, I provide the warranty, I
provide the guarantee, I provide the final say so, but for whatever reason Microsoft took
all of that away from me.
So I came to Linux to get that back, the final say so, and I'm willing to put in work
to have that, I believe the same of you, and I'm going to treat you like that.
So I'm going to give you some resources that will help you feel like you have the final
say so, first up, the Linux command line where it all begins, I definitely recommend this
as your first resource when learning Linux because the command line is super powerful
and this is going to teach you how to safely navigate and maneuver using the command line.
So we're going to start off with the simplest thing like what is the shell, your terminal
emulators, right, very, very basic stuff.
Before you know it, you're going to be navigating around, you know, CDing around, changing
directories all the way up to manipulating files, copying and removing files and things
of that nature all in a safe environment.
So you don't have to worry about doing this with your own files where you might accidentally
delete and remove something important.
Again, it teaches you how to do it in a very safe way.
Another thing about this resource, it doesn't bog you down with a lot of the internet arguments.
Sometimes when seeking information online, users may be a bit more passionate about the
software that they're using and the insert certain biases with the information that
they provide.
This will usually start some kind of an argument and the user asking a question attempting
to learn does not benefit from any of the argument.
So for me personally, I like books and documentation as a distraction free environment for learning.
Another good thing about this resource is not just for the new users, like I've been
using Linux for a little while now, and I love coming back to read this document again.
It's a wonderful reference.
So even after you feel as though you know what you're doing and you can use the terminal
daily to get most of your work done, you'll still love having this book just to, you
know, hop back in there, refresh yourself.
Maybe there's some terms and things you don't really remember because you hadn't used
them in a while.
You could just hop right back in here and refresh yourself without going online because
it's an offline document as well.
There's no DRM, no ads, no subscriptions and all kinds of stuff.
I bought the book a few times because I buy humble bundles and this book was a part of
multiple humble bundles that I've purchased in the past.
So I've already paid for it multiple times.
But it is available as a at no cost to you download online link in the show notes.
Now for just a few quick mentions about the book before going forward.
This is based on my own experience, but file permissions is something that I believe
you really, really need to spend some time on for security sake.
And just because if you, you can sometimes create headaches for yourself when working
in different directories owned by other users, you may get confused as to why, why things
are not happening as you believe they should file permissions is just a wonderful thing to
keep in mind.
So the book does an excellent job helping you understand file permissions, giving you
lots, it's motorcycle season.
So I apologize for all of the noise you can hear out there.
I got the door and the windows open, letting some of the wonderful fresh air in.
So along with the fresh air, there's going to be a bit of the environment as I was saying,
the permissions section of the book does an excellent job.
It gives you just enough information to help you understand how permissions work.
What all the symbols mean, you know, you'll see our WX and you'll see it multiple times
along side certain files whenever you do an LS with the long flag followed by something
like the A flag or whatever, it'll fill in all the blanks for you.
I believe the book also does a really good job explaining quoting.
So with time, if you decide to embark in bash scripting, you will have questions about
quoting, double quotes, single quotes, that kind of thing.
The book does an excellent job sort of introducing you to it, but time and experimentation will
help fill in the rest of the gaps.
Now for a couple of cons really quickly.
The book does introduce you to RegX, which is great.
If you don't know what RegX is, it's pattern matching.
You're looking for a pattern and you may wish to either remove that pattern or substitute
it with a different pattern.
So changing A, B, C with D, F. Funny story about that.
When I joined open source and started reading a lot of the online documentation scattered
all over the web, a lot of examples use something called Foo and Bar.
And I thought these were some sort of system variables that were like super important because
my experience with the word Foo bar, it was spelled differently and it had a meaning
that I will not mention here.
I had no idea that they were, what they were doing with their version of Foo, which is
Foo and Bar, B-A-R, but yeah, in open source, because there is no sort of company behind
a lot of it.
At times you will learn that there's no adult in the room.
I'll just tell you that from now.
So there are certain projects out there that may be great projects, but they have names
that are just not for everyone.
So I'll also create issues because, say for instance, right now if I ask you to spell
engine X, what you might spell will be completely different from the package engine X.
There's a lot of play on words, so documentation means a lot.
You're going to get a lot of correct pronunciation and spelling of these different packages because
having someone just tell you, hey, yeah, I use engine X, you're going to go actually running
out there, type in what you know of as an English speaker, engine and X, and it's not going
to be what you think it is.
Another thing about that for me, when I was on Reddit looking for different communities,
especially adding all of the different desktop environments, that's another thing in Linux,
they're going to eventually come across.
This is an interesting one.
I was adding the different ones, so X, F, C, E, I, at the time, I called X, F, C, E, X,
face.
So I didn't know that it was just called X, F, C, E, to me, it looks like the word X and
face.
And then, you know, KDE and all the other ones, I'm adding them to my Reddit logs, so
I can follow the projects, see what users are saying about the different desktop environments.
And I was trying to find Cinnamon, because at the time I was using Linux meant with the
Cinnamon Desktop environment, well on Reddit, there is another community called Cinnamon,
and it is not the Cinnamon Desktop environment.
I'm going to give you a warning about that right now.
If you are looking for the Cinnamon Desktop environment, you have to type Cinnamon, DE, for
Cinnamon Desktop environment, yeah.
So someone else already had to name Cinnamon, it is a 18 plus community, not say for work,
giving you a heads up about that now, and if you want to start, you know, joining the
different communities again, you just got to be careful with spelling and open source
and other things.
But back to Rejects, a lot of people have a hard time wrapping their head around Rejects,
because when you get to using it, depending on the technology that you're using, GRIP,
SAID, ARC, the different languages that implement their own versions of Rejects, wrapping your
head around it can be difficult, because a lot of times you're going to have to put your
own understanding aside and adopt the understanding of the tool that you're using, and you're going
to have to be able to toggle that, you know, turn it on and off based on what you're
doing at the time.
And that's where the difficulty will come in.
In the book, what I do not appreciate as much is that they use examples that are kind
of just, you know, this is, this is kind of when, when you're learning from in, from a
gray beard in the Linux community, they accidentally introduce confusion in the learning process.
So for instance, they're teaching you about SAID and using Rejects with SAID.
A good thing to do that with is just plain English, like some regular writing or something,
you can just, you know, do substitutions on writing.
And if you want to do anything that's kind of formatted, XML would be a little bit easier
to work with.
But just basic writing or work just fine.
I would even say mark down, even though people may not recognize the formatting as mark
down, just regular bullet pointing or whatever, that's a lot easier to build your examples
around because when I came in open source, I didn't know what mark down was, it didn't
take me long to find out.
And then adopting it also didn't take too long, you know, just for regular vanilla mark
down, now when you want to start doing complicated things, like setting up table tables and
things of that nature, and you start dealing with the different flavors of mark down, you
know, you can, you can spend some time on it if you'd like, but it's still not a difficult
thing to understand.
Regardless, they decided to use something called graph and in variance of graph, which
are like spin offs of raw off and when you're learning, you know, in Linux, you're going
to find out that some of the learning resources introduced complexities that are just beyond
what a new to Linux user should have in front of them at the time.
So you now have to research what the heck is a graph so that you can understand the
syntax that you're looking at and separate it from the syntax that you're attempting
to learn.
So you're going to be constantly peeling back the onion, attempting to separate the graph
from the, from the said, and how all of this ties in with you learning Linux, you know,
it, for me, in my own learning journey, I considered this to be a bad example using a
graph with said, it was, it was not well done in my opinion.
One other thing that I'll mention about the book before we move on to the next resource,
the book, they spelled them wrong when, yeah, you know, them is, it's, it's a text editor
called them V I M. And for some reason, they ended up spelling it in a N O. I don't know
what was that with that, but, you know, wink, wink, all right, all right, enough fooling
around.
That was a joke, by the way, if you're new and you're listening to this, I'm joking.
Nano is a perfectly good text editor.
And a lot of people start out using it because it really does remove a lot of mystery.
I'm not going to say complexity because none of the text editors that I have used in
the terminal, you know, them nano micro, they, they were not complex, however, because
you need to stop and learn what you're doing before you touch them, except for nano nano
is a little bit easier.
You can actually just play around in an old before you do a lot because the controls are
kind of listed at the bottom of the screen.
And if you're not new to computers, like if you're a savvy Windows user, I was going to
give some examples there, but there's no need.
You'll figure it out.
It's, it's very simple stuff.
And again, documentation is king for everything.
Whenever someone recommends a new project, the very first thing you need to do is ask about
the documentation.
If they start holding, humming, hand waving about the documentation, skip it, just forget
about it.
All right.
Or if they try to tell you, here is a list of different forms that you can dance around
trying to build your understanding, forget about it.
Most projects today do have decent documentation.
The word get may arrive in front of you at some point.
I'm going to avoid it here.
And if there is someone with far better understanding on get and can actually recommend it, I would
greatly appreciate it.
I have some books on it.
I mess around with it, but I cannot in any way give justice to the project in recommendations.
So I'll leave that up for my betters.
I'll leave that up to my betters to recommend that project.
I can't possibly do you any justice by recommending it.
All right.
Now, for the next resource that I want to bring to the table, it's a specific man page.
It's the bash man page.
Now understand, you may not know a lot about the man pages and looking at them.
At first, the man pages are not going to make a lot of sense to you.
If I could put in the words my own confusion, it felt like the man pages were just a high
elevation top down reference for the creators of whatever technology you a new Linux user
are attempting to learn.
So in many cases, it felt like it did you no justice to even look at a man page because
it only benefited the creator of said technology.
The reason why I'm recommending the bash man page here, when I learned bash or when I began
because I don't think the learning ever stopped freely, but when I began to learn bash,
I learned from a bunch of scattered online forms, documents, videos, just people all over
the internet and I appreciate them all for what they've taught me.
However, my growth was always stunted in that most of the examples and things that I come
across did not include show grammar and the show grammar gives you depth in your learning.
So you may learn how to mimic a certain process, for instance, in the F statement.
If you're already a developer, F statements are probably not going to be that difficult
for you.
However, if you're new to Linux and you're not already a developer and you really do want
to use the terminal, you know, you're eventually going to find fascination in bash scripts and
there's something called an F statement.
If this thing is true, then do something for me.
That's the base, basics of it.
Shell grammar is going to introduce things like definitions.
You're going to learn that in the shell word means something, name means something.
You're going to learn about things like control operators and you see when you're on these
forms, they may demonstrate how to use a control operator, but they never tell you what
it is, like what it's called.
So when you're trying to explain your confusion, because you're basically just mimicking what
you saw someone else do with a control operator, but you can't tell a more knowledgeable individual
about your confusion, because so much of the depth is lost through these tutorials that
you're going to encounter, you're going to be able to understand arithmetic evaluation
through expressions, as well as conditional expressions.
That's another big one right there, like, you know, especially me bringing up F statements
and things of that nature, again, understanding the shell grammar and the definitions behind
each of these different terms will benefit you greatly.
It'll take some time, obviously, you know, you're learning something new that doesn't immediately
make it difficult.
It makes it tedious at times, but if you're interested in learning, I think this is going
to be just a very, very valuable resource for you, the bash man page.
And there's another one I'm not going to bring it up here, or maybe I should, because
I don't like the tease, but it's the bash built ends.
They don't have an online for it, but if you tighten the same way you do man bash in
your terminal to pull up the bash man page, man stands for manual, by the way, you can
do man built ends.
That's all one word built ends plural built ends.
You can do a tab complete once you type built and it'll you can hit tab and it'll complete
the rest of the word.
So that way you are doing that with a syntax error.
This is going to help you also understand that there are certain tools that bash your
shell comes equipped with that are different from your system.
And you'll find that your system also comes with some of the same tools and you can, you
can depend if you want to switch between the tools.
So a good example of that is in bash, they have a built-in echo that you can use and your
system also comes with echo, which is located if you're using an Ubuntu based system.
It's going to be in your USR bin bash or not bash, excuse me, USR bin is the directory
in the root directory.
You're going to find echo down in there as a binary, but it's also a bash built in as
well.
By learning these differences, right, you're going to be, you're going to really fill in
a lot of gaps.
Expansion is another big one.
I mentioned quoting earlier from the Linux command line, when you're dealing with expansion
and quoting, if you're new to Linux right now, hearing me just say expansion doesn't mean
anything to you.
And I'm not going to attempt to give you some half-witted explanation of it.
I would much rather you read the resource, go to the bash, man page, that's where you
need to get your understanding from.
And then from there, ask questions, right, because that's another thing about the community.
And you mention that you are reading the man page and you still have questions and you
are able to express yourself a little clear using the language or the grammar of the
shell or whatever technology that you're using.
People are more willing to help you because they can see that you're also trying to help
yourself.
But if you're just sure, hey, how do I do a thing?
Well, it's not going to work out well for you all the time.
Some people will try to help you, but you may not be well received.
Finally, a fun one that I enjoy using all the time.
Job control.
Oh, man.
Once you become a little bit more fluent in using Linux systems, job control is great.
Because, for instance, I use tar from my backup solution.
So I'll jump in and I'm just giving an example here.
I'll have say my shows directory where I create my HPR shows on.
Let's just say that's like 50 gigabytes, whereas the shows, right, I'll throw a tar on
that baby.
And I'm not going to wait for tar to completely archive that 50 gigabytes, right?
So with job control, I can send that job to the background while I continue reading
my notes or doing whatever I'm doing and say a them session or whatever.
And as another example here as well, let's say, for instance, I accidentally tarred
the wrong directory, right?
Maybe I made some changes, but those changes were in a sub directory somewhere.
And that's the directory I actually should have used tar on, not the parent directory.
Well, I could have a choice here.
I could kill the current job, you know, the first tar job that I set up there.
I could kill that and then start a new one or, you know what?
It's not going to hurt anything.
I'll leave that running and then just start a new tar job, send it to the background
as well.
So they'll all be running consecutively.
And I'll be there just, you know, again, still reading my notes, documentation, whatever
in them while both of those tar jobs are running in the background.
And I don't need multiple terminals all over the, but you're going to eventually run
into Unix porn or you'll be on YouTube and you'll see people using things like tolling
window managers.
And they'll have like five or six terminals scattered all over the screen, demonstrating
the flexibility of a tiling window manager.
The first thing I'm going to tell you is learn how to manage your jobs.
All you really need is one terminal window open when you know how to manage your jobs.
One window open and full screen and a few jobs in the background.
Why do I need multiple of them scattered all over the screen?
But when I need to go back and check on a job, I can.
But it depends on how you like to work as well.
So I don't, I don't mean to speak light of those other tools.
They're great tools and they may benefit you more than I could possibly understand.
I'm just giving you examples of what is possible.
So that's all I'm going to leave you with now.
Just those two resources.
The book known as the Linux command line and the bash man page.
If you use those two, you know, because I do believe in documentation and I think these
two will be great for a new to Linux users documentation.
That's all I have time for.
I'll catch you guys in the next show.
Take it easy.
You have been listening to Hecker Public Radio at HeckerPublicRadio.org.
Today's show was contributed by a HPR listener like yourself.
If you ever thought of recording podcasts, you click on our contribute link to find out
how easy it really is.
Hosting for HPR has been kindly provided by an honesthost.com, the internet archive and
our sings.net.
On this advice status, today's show is released under Creative Commons, Attribution 4.0 International
License.