Something I found useful is to simply look at all of the files in “/usr/bin” when interested in end user exploration without a particular goal. Some admin type files which are programs might be of interest in “/usr/sbin” or “/bin” or “/sbin”. E.g., “cd /usr/bin”, then “ls” or “ls -F” or “ls g*”.
Whenever you come upon a file there try "man ", e.g., “man rm” or “man cp”.
Sometimes you’ll operate as a regular user (most of the time if things work well). Try “whoami”. Drop in to a root shell with “sudo -s”, run “whoami” again. Whoever it is that you are, see what his/her group and user numeric ID(s) is(are); run command “id”. Exit the root shell, type “exit”, then run “id” again. Numeric ID becomes important when dealing with permissions because no matter what your display name this is who you are named as an identity…this ID can be copied from host to Jetson (the numeric part)…but names will only match if numeric ID matches.
Use “less” (known as a pager) to explore files in “/etc” without risk of altering the file (this just keeps text from scrolling away until you want to scroll…e.g., try “less /etc/mtab” to see stats on mounted file systems…many more show up than just the hard drive. “cat” is useful in combination with “less”…“cat” just turns a file into a string of characters, e.g., “cat /etc/mtab”. Pipes to combine this make it easier to explore, e.g., “cat /etc/mtab | less”. If you have binary characters in something you can strip them out and show only the human readable ones with “strings”, e.g., “/bin/ls” is a binary file, but you can see what human-readable strings are in it with “strings /usr/bin/ls”…or page it with less, “strings /usr/bin/ls | less”. This is one of the most fundamental tools you’ll get…the ability to browse anything, "man " to ask about it, and “strings” and “less” to make it scroll by at your own rate.
If you use “cat” and a binary character messes up your console font or color just type “reset” and it should be back to normal.
It might be easier if you give an idea of a list of tasks or situations you’d like to know more about.
Specifically for a Jetson you will find it is the “Ubuntu” flavor of Linux (Linux is the kernel, all of the files surrounding it get a name too…Ubuntu is a name for one philosophy on packaging). When it gets the direct hardware access drivers (e.g., for CUDA), then you can refer to it as “Linux for Tegra” (“L4T”). Flashing a Jetson implies building an image on the host which is an exact byte-for-byte copy of the full operating system, and then writing it over USB. Further package additions, when using JetPack, implies over ethernet.
To see more about your current network, run “ifconfig”. To see more about what is visible to USB, run “lsusb”. To see specifically about what NVIDIA devices your host sees, run “lsusb -d 0955:”. To specifically see if a Jetson is connected (this requires the Jetson to be in recovery mode) run “lsusb -d 0955:7c18”.
The compiler to use is “gcc” (try “gcc --version”) for C, “g++” for C++.
You’ll want to know your specific distribution’s package manager right from the start…this is important early on. These are usually split into a database format, plus some sort of front end to make the database more convenient. On Ubuntu, which is a Debian derivative, the base tool is “dpkg”, and it deals with Debian format package files. You could manually use dpkg, but if you want automatic dependency checking, you probably want “apt” or “apt-get”. Try “apt search editor” or “apt check-update”…if you get an error for permission, use “sudo apt-get check-update”…but be careful because if you have to use root permissions (sudo), then it might have the opportunity to do something you don’t want. On Fedora rpm is the database tool, and dnf or yum are the package tool front ends which make it act smarter. Both use the same Linux kernel and Linux kernel documentation mostly applies between Fedora and Ubuntu. Jetsons are aarch64/arm64, so although most kernel documents and Ubuntu documents apply regardless of whether it is the PC or the Jetson you may find differences in which kernel features are available.
On a Jetson you will find file “/etc/nv_tegra_release”. This lists files which are specifically provided by NVIDIA for direct hardware access. To validate them check the sha1sum:
sha1sum -c /etc/nv_tegra_release
…if something here fails you might for example lose the GUI display…this command would tell you which file to fix, but this is specific to a Jetson (it is for L4T).