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.: DNF, the next-generation replacement for YUM — dnf latest documentation
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:
ls
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.
So,
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.