One of the core ideas in Linux is that everything is a file. Regular documents, running processes, hardware devices, and even kernel interfaces are all exposed through the same file abstraction. When you read from a keyboard, write to a disk, or send data to a network socket, you’re interacting with a file-like object—often under /dev or /proc—using the same system calls (open, read, write) you’d use for a text file. This design lets hardware devices and kernel features be accessed, inspected, and controlled using familiar tools like cat, echo, and ls, making device access uniform, scriptable, and transparent.
/
├── bin | Essential user commands
├── boot | Bootloader and kernel files
├── dev | Hardware devices as files
├── etc | System-wide configuration
├── home | User home directories
├── include | System header files
├── lib | Essential shared libraries
├── media | Auto-mounted removable media (USB etc...)
├── mnt | Temporary manual mount points
├── opt | Optional third-party software
├── proc | Live kernel and process info
├── root | Home directory for root user (sudo user)
├── rootfs | Base root filesystem (initramfs/embedded) - used at boot time
├── run | Runtime state (PIDs, sockets, locks)
├── sbin | Essential system administration commands
├── snap | Snap package data (big all-in-one packages)
├── swapfile | Disk space used as memory (slow if used)
├── sys | Kernel device and driver interface (virtual filesystem of devices)
├── tmp | Temporary files
├── usr | User-space programs and libraries
└── var | Variable data (logs, caches, spools)You will see many subdirectories that look very similar to the above structure. These are often used to organize the filesystem and make it more readable. It acts as a heiracy of 'importance' and 'ownership' for the files. The top level directories above, are the most important. They make the system work. The '/usr/local' directories are often used to store user-space programs and libraries. However, the term 'user' can be ambiguous.
│ ├── /usr/local
│ │ ├── /usr/local/bin
│ │ ├── /usr/local/cmake
│ │ ├── /usr/local/CMakeFiles
│ │ ├── /usr/local/cuda -> /etc/alternatives/cuda
│ │ ├── /usr/local/cuda-12.1
│ │ ├── /usr/local/cuda-12.9
│ │ ├── /usr/local/doc
│ │ ├── /usr/local/etc
│ │ ├── /usr/local/include
│ │ ├── /usr/local/lib
│ │ ├── /usr/local/man -> share/man
│ │ ├── /usr/local/sbin
│ │ ├── /usr/local/share
│ │ ├── /usr/local/src
│ │ └── /usr/local/varThe home directory /home/$USER or $HOME is the user's personal directory.
It is owned by the active user, and is generally not available to other users.
This is a BAD place to install software. But I GREAT place for USER-SPECIFIC configurations or data.
This is by no means an exhaustive list of commands. But it is a good starting point. You'll build up your knowledge of commands as you go along.
$ less <file> # view a file, from within less useful commands are:
# "/" - search; "g" - go to start; "G" - go to end; "q" - quit
$ nano <file> # edit a file
$ gedit <file> # edit a file with a gui editor
$ vim <file> # [Worth learning] edit a file with a vim editor$ mv <old-name> <new-name> # rename a file
$ mv <file> <dir> # move file to new directory
$ rm <file> # delete file
$ rmdir <dir> # [safer for directories] delete (empty) directory
$ rm -r <dir> # delete directory and all it's contents
$ man <cmd> # documentation for <cmd>
$ man -k <topic> # search for commands related to <topic>Pipes are suuuper useful. They allow you to chain commands together. Learning a few tools can make your life a lot easier and more efficient.
pipes are the '|' symbol. You can chain commands together with them.
$ <command1> | <command2> | <command3> | ...$ cat <file> # display the contents of a file
# Examples
$ cat <file> | grep "Hello"
$ cat <file> | grep -v "Hello" # Find in a file, excluding the word "Hello"
$ grep <pattern> <file> # search for a pattern in a file
# Examples
$ grep "Hello" <file>
$ cat <some file> | grep -v "Hello" # Find in a file, excluding the word "Hello"
$ find . | grep -v "/home/user/" # Find in all subdirectories, excluding the home directory
$ sort <file> # sort the contents of a file
# Examples
$ ls . | sort | head -n 2 # Sort the files in the current directory and display the first 2
$ uniq <file> # remove duplicate lines from a file
# Examples
$ cat <file> | uniq | wc -l # Count the number of unique files in the current directory
$ wc <file> # count the number of lines, words, and characters in a file
# Examples
$ ls . | wc -l # Count the number of files in the current directory
$ head <file> # display the first 10 lines of a file
$ tail <file> # display the last 10 lines of a file
$ find <dir> -name <pattern> # find files by name
# Examples
$ find . -name "*.txt"
$ find . -name "*.txt" | grep "Hello"Ok, we are really talking about system installs, where things should live and how to find them. But we are doing it through the CMake build system, to make the process interactive and practical.
- How do I make a basic app?
$ mkdir -p $HOME/src/tmp/my_app
$ cd $HOME/src/tmp/my_app
$ Write your code here ...
$ cmake .
$ make- What if I want to use it like a 'normal executable'?
$ sudo make install- Where will that go? By default, this will install to the $CMAKE_PREFIX_PATH. I.e. /usr/local/bin.
$ ls -l /usr/local/bin... TODO
LD_LIBRARY_PATH to "compat". So that it picks up the correct nvcc version. They do not do this by default.
'sudo apt-get install cuda-compat-10.1' export LD_LIBRARY_PATH="/usr/local/cuda-10.0/compat:$LD_LIBRARY_PATH"
there is a lib cuda.so that has the driver version, but the ld library path thing appears to magically provide support for a newer version.
cuda confluence has a webinar: check it out.
https://forums.developer.nvidia.com/t/cuda-12-2-error-with-jetpack-5-1-3/292866/3 https://developer.nvidia.com/blog/simplifying-cuda-upgrades-for-nvidia-jetson-users/