Also, I find things like updating and/or installing packages to be confusing. Anytime I want to do something, it seems I need to install a package in which case I find the steps online. Once I execute the commands, I never understand what I've done, but know it works
who want to install packages from command line nowadays?
For Debian-derivatives, I can warmly recommend Synaptic, a GUI-based package manager interface. It has very good search facilities (allowing you to search keywords in the package name, or package description, or in both). It is not as powerful as the command-line interface, but for day-to-day tasks, it is very useful. It also automatically tells you what other packages it marks to be installed if there are dependencies.
I do also use a couple of PPA's, or Personal Package Archives. These are basically miniature repositories intended for individual software suites or families of applications. Currently, I have the
FreeCAD (stable) and
OpenSCAD ones enabled, as the mainline repository versions are older than I like. I recommend using the
sudo apt-add-repository etc. commands shown for each repository to add that repository, run
sudo apt update to reload repository package lists, and finally fire up Synaptic and look for the package to install.
The only software I have installed the Windows way -- via an installer instead of a repository and package management -- is Arduino + Teensyduino. However, they install as the user running them (without superuser privileges), so that's okay. (My udev rules for microcontroller support are customized, though.) Although I really don't like the Arduino editor much, and have considered switching to e.g. PlatformIO. One of the custom scripts I use with Arduino is one that reboots and autodetects Pro Micro clones' serial port (the cheap ATmega32u4's that have the Arduino Leonardo bootloader, and are treated as Arduino Leonardos in the Arduino environment, that you can get for ~ $5 USD apiece off eBay); I like those, but they can be a bit fiddly to program without that utility. (It interposes avrdude, that's all.)
Like
AVE says, the learning curve is steep, and you will suck at the beginning. Some of that old DOS muscle memory may even be hindering you, because you already have expectations on how things should work, and you're finding out Linux works differently. It is unfortunate, but I haven't found any way around it. The sooner you'll decide it's just another tool that you wish to find how it works best for you, the easier it will be.
(I'm not saying you are not already doing that, I'm talking statistically, according to my own experience helping others learn.)
The
Debian Reference Card (English PDF; others and Debian documentation at
https://www.debian.org/doc/user-manuals) can be useful.
You can find the latest versions of the C library interfaces (sections 2 and 3) and command-line commands (sections 1, 6, and 8) at the
Linux man pages project, which is the upstream for the non-application/library-specific man pages. On the command line, you can use
man section command-or-function to display a specific man page, say
man 1 bash . You can omit the section number, in which case man will look it up in the preferred section order, but note that sometimes different sections do have very different pages; for example,
man 2 signal shows the signal() C library function interface, but
man 7 signal shows the overview of POSIX/Unix signals.
You can do a keyword search using
man -k term or
man -s section -k term to look up manual pages related to
term.
One very useful command in Debian derivatives is is
dpkg-query -S $(which command) or equivalently
dpkg-query -S /path/to/file . It will tell you the package name that provided the command-line command or specified file; just remember to supply full absolute path to the file in the latter form. Then, you can use
dpkg-query -L package | less to list all the other files in that package, or
dpkg-query -s package to show the description of the package.
If you don't remember those options (I don't!), use
man dpkg-query or
dpkg-query --help to look them up!
(This is also the reason why my example code almost always contains such an usage information when run with
-h or
--help as the first command line parameter. I have a directory tree full of examples, and instead of checking the source code to see if a particular one is the one I'm looking for, I just run the binary with the --help flag, to see if it does what I'm looking for. If it does,
then I go looking at its sources. Much faster this way.)
One thing I wish new Linuxers would consider and wield properly, is the privilege separation: users, groups (including supplementary groups), and filesystem capabilities. If you ever find yourself doing
sudo su - or
chmod 0777 /dev/foo, you're doing things seriously wrong.
I have installed quite a few Apache servers in large organizations over the past two and a half decades, with multiple partially overlapping administrators (really, a proper admin hierarchy), without anyone needing to use
sudo , with file user ownership indicating creator user, and access managed through group memberships (and a couple of helper scripts). So I do claim I know this stuff.
On single-user workstations it does not matter much, except that it opens security holes that may or may not matter, but getting it right gives you a powerful new set of tools (that again, on a single-user workstation may not be of much use). However, even a rough
understanding the privilege separation mechanism gives you a starting point to solve problems instead of getting completely frustrated. In short, that every process has a specific user and a group, plus optionally a set of supplementary groups (that are essentially equivalent to the process group); and optionally a set of Linux
capabilities, with the superuser (root) having all capabilities; and files and devices are owned by a specific user and group; that
udev sets those (and the access mode associated) for devices; and that executable binaries, but not scripts, can be set to grant special privileges (capabilities), much like the SetUID and SetGID bits can grant the process executing the binary superuser privileges, except much more fine-grained.
I wish there was a good guide I could point you to, but thus far, I haven't found one.
I have considered trying to write my own, several times, but the best format I can think of is a Wikipedia-like interlinked snippet archive, but it is too large an undertaking for myself alone, and there are very few people I'd trust to add
correct advice... and methinks providing misleading advice is much worse than being silent.