Learning more about commands and software components that make a distro

I’m very much a Linux beginner.
The biggest problem as a beginner is that for every problem I encounter that’s just a bit more complicated I always see people listing commands that are different from each other to solve the same problem.
a.Is this because you can do the same thing multiple ways?That’s pretty horrible from a beginner’s perspective.

b.Is it because most people do not understand how software components work together specifically in Fedora?

c.in 95% of the times for Fedora and for other distros I see just a lot of people pasting commands in forums and not offering any assurance that those commands are correct in that context.
The spirit most times is “trust me bro” or “try that maybe it works…maybe it doesn’t”…

1.So as a beginner what book or multiple books are absolutely crucial and gold standard that I need to read that can offer me a correct understanding of how commands work?

2.What commands are truly universal on all distros?

3.What commands work only for Fedora and nowhere else?

The correct sequencing of commands and all the parts of one command. There needs to be some consistent logic to this…I hope.

4.After that how can i understand the software components that together makes up what Fedora is today as a distro?
Also the commands that are up to date and consistent of how to work with these components.

I honestly want if possible to contribute in some why to the distro(Fedora) that I want to use as a daily driver. If i find issues that no one is interested in fixing then I want to be able to fix them and send those fixes so everyone benefits. Can you guys help me please?

I want to go from my current level where I just see random commands to a level where these commands make sense and I know how to judge if those commands are actually solving the problem I want to solve correctly and not just some hack-ish way that temporarily fixes something.
Of course me fixing things presumes I also learn bash or programming languages that are used for different components.

All the help and recommendations you guys can give me is very much appreciated. Thank you!

1 Like

Hi @daosans

The issues you state are not uncommon. Like every field, there is a learning curve that must be scaled to understand how operating systems and their components work. For example, if one wants to learn how their car works, there will be an initial learning curve that must be scaled—to learn the terminology (“jargon”) of the field and the basic assumptions that people in the field make.

With that in mind, we’ll try to answer your questions:

Yes, there are many ways to do the same thing. I understand how this may be horrible for a beginner, but Open Source Software is about choice, and the freedom to choose how to do things. This means folks use method a, and if they’re not happy with it, they’ll modify it to suit their preferences, creating method b. Now, a lot of folks may move to method b, but some will remain with method a. So, for a newcomer, there are many many choices, and that’s what makes it hard. It may sound like a bad thing for newcomers in the short run because they don’t know enough on how to choose between different methods, but in the long run, it’s a very very good thing. For tools that are not FOSS, one does not have a choice—one cannot modify anything. It must be done the way the developer wants to do it.

Well, it’s hard to say. Folks in the community certainly have different levels of understanding of the different components. For example, I’m a package maintainer and know how things work at that level very well, but if you ask me how the kernel works, I don’t really know. One cannot know all of it, most of us will choose the bits that we are interested in and learn those.

Users may not have the same level of understanding, of course, but then they don’t need to know too much unless they run into some issues and need to look “under the hood”.

Forums in FOSS are not tech support. We don’t tell people “yes, this is wrong, this is how you fix it”. Forums are a place where we discuss issues and together try to find a solution. An important aspect of this is to not spoon feed users but instead, work with them to help them figure out what the issue is—so that the next time it happens, they know a little more about how to go about figuring out the issue, and perhaps fixing it.

This is different from corporate support where someone will fix the issue without necessarily explaining it or the fix to the user.

Different people, again, have different ways of diagnosing issues. We like to narrow it down first to the most likely component causing it, and then proposing a fix/work around. There are some notes in the introductory posts in the #start-here category about this (or so I seem to remember).

There are many many books, all including lots of usually overlapping information—but we don’t usually suggest that one go through a book primarily because they may not be up to date, and because they may not apply to all distributions. We suggest “use it, when you run into an issue, search the web, and learn that way”, because no matter how many books one reads on the subject, one will not really learn how to use a system without spending the time on it. Going back to the car analogy, you can learn all the theory you want about cars from books, but it doesn’t make you a mechanic—you have to work on the car to really learn how it works.

Here are some general notes on some “standards”:

  • all commands will have a -h or --help flag that should provide information about their usage
  • lots of commands will also have “man pages”: man man in a terminal will tell you about these
  • some may even have longer info documents but there are getting rarer from what is see. man info to learn more about this sytem.
  • there are websites which host web versions of man pages too (but do check to see that the version these have been generated from match the version of the command you are using): https://helpmanual.io/ (there are others too)
  • to find a man page, use the apropos command: try apropos dnf
  • finally, search for the “upstream documentation” that the developers provide. These will often include usage examples. e.g.: https://dnf.readthedocs.io/en/latest/

This is hard to say—distros by definition are different in their composition, i.e., they vary in the software that they include.

  • one would expect that each will have a shell, but it could be bash or tcsh or zsh or fish or another—depends on the distro.
  • each shell provides some “built-ins”, e.g: bash commands
  • most distros will include the GNU core utilities: ls and so on (try: rpm -ql coreutils | grep bin to see what commands coreutils provide on a Fedora installation)
  • distros tend to include util-linux: try rpm -ql util-linux |grep bin to see what commands this provides on Fedora
  • a default terminal based editor is usually included. Traditionally, this used to be vi, but it could be anything—depending on the distro. Fedora, for example, moved off vi to nano.
  • each distro tends to have a “package manager” because distros usually rely on one. The prevalent ones are rpm and deb. The Fedora ecosystem is rpm based, so we’ll have commands related to that. man rpm to learn more.
  • on top of the default package manager, most distros will have another utility to allow the installation of packages from its repositories. On Fedora, dnf is default (man dnf), but other distros will have their own (apt and so on).
  • nowadays PackageKit is meant to be distro-agnostic. It lives on top of dnf or apt or whatever, so users don’t have to worry about the “backend” and can just use packagekit. The terminal command for PackageKit is pkcon, so man pkcon for more information. Note that PackageKit will not expose all the functions that dnf will, just like dnf will not expose all the functions that rpm allows. So a lot of us just use dnf. Gnome-software etc. are built on top of PackageKit

As noted above, this is hard to say. One will need to look at the specific distribution.

Yes, there is. This won’t be exhaustive, because I’m sure I’ll miss something, but generally commands follow:

command  [arguments]

arguments can be compulsory or optional, and they can be positional or use “flags”.

For example:


does not require any arguments, but can take many many arguments that are provided using flags:

ls -l -a -s -h

these can usually be passed together:

ls -lash

Some flags may not require additional information, others may:

ls --sort=time

Finally, arguments have a “short form” and may have a “long form”. The short form is the -a, the long form is --all. The second is just longer and more readable, and from what I see, is not compulsory.


ls -a
ls --all

do the same thing (as man ls will tell you).
There are now a number of argument parsing libraries out there, and they’ll generally follow this standard, but may provide some extra functions. Bash uses getopt (man getopt), Python has multiple libraries with the standard being argparse, and so on.

Well, if you want to understand it from the ground-up, you need to take a course on Operating Systems to begin with—that will cover the data structures etc., and paging and so on, to give you an idea of how the kernel works.

If you want to learn how a whole Linux based OS is built and works, most will direct you to the Linux From Scratch project.

To understand how distros work, the simplest answer is “use it daily and you’ll learn as you use it”. There is no short-cut, unfortunately—one can’t just learn everything you wish to learn from a book/course. Reading and participating in forum discussions is a great way to learn from others queries.

We have a whole SIG dedicated to this:

The thing to do is to pick anything of interest and just get started. That’s how we all learn while contributing.

The same holds. Use it daily. When you do something, think “is there a better way to do this”. Search the web. It is almost impossible that someone hasn’t already asked the question before. You’ll usually find an existing forum discussion around the subject. Same for when you run into an issue. Just search to see what’s already been done.

To understand what’s happening, even if a command is provided, don’t, just run it and move on. Read the docs for the command, see what each argument is doing. All of that is up to the user. Folks short on time are happy to “fix and move on”, folks that want to learn will be happy to spend some time investigating what’s going on.


Thank you so much Ankur for your very thorough reply.

1 Like

I would recommend Linux Pocket Guide. It covers most of the elementary stuff. Or maybe The Linux Command Line which again covers many topics in depth.


Firstly, as someone once said, In Unix, there’s always more than one way to do things, with the corollary, Someone will think your way is stupid.
Humble bundle recently announced a bundle of Unix/Linux books, which includes, The Linux Command Line, which is very good for the beginner, in my opinion The list has something for the experienced and novice, and is worth checking out. Humble bundle lets you pay what you want, for books that can be worth hundreds, if purchased individually.

Sorry, in this case, it’s pay minimum of $40 for a bundle with retail value of $791. It’s still a good deal, though many of the books are more for the developer.


The humble bundle requires the 16 book bundle @ a minimum of $18 to include “the linux command line” Other bundles vary in content, but the full bundle of 21 books is a minimum of $40 as stated.

Still a very good deal for a lot of information that might fit what you want to learn.

1 Like

Thanks, I’d missed the lower available price, I’d just seen the $40 one for all the books.

1 Like