Package Managers & Dependencies
Most Linux distributions use package managers for software installation and removal. Package managers provide some benefits such as the possibility of using a central repository from which (almost) any piece of software can be downloaded, the organization of pieces of software into bundles that can be installed as one cohesive group, and the main benefits: automatic dependency handling and tracking what changes packages make so they can be uninstalled.
Certain pieces of software might require certain libraries or other programs to perform duties that would be redundant if it was re-implemented in that piece of software. Packages allow for the expression of these dependencies.
Differences: package formats and strategies
There exist several different package managers. Each was created because the existing ones did not meet the needs of some people. Each package manager requires packages in its own format.
Furthermore, different distributions have different requirements of the software that is included. There are a number of pieces of software that can have differing capabilities depending on options that are given when it is compiled from source code into a machine executable. Some distributions want to provide full feature sets and a rich experience while others want to provide as lean and simple an experience as possible, and there is everything in between. Also, the distribution may decide to format its directory structure differently or use a different init system. They may decide to bundle the software differently: there may be a package called "dev-utils" in two different distributions, but one version of that includes yacc while the other doesn't. Because of these different needs, the distributions choose to compile the software in different ways.
This is why even if you have a package in the correct format for your package manager, it may not work if the package was intended for a different distribution. For instance, that package might rely on yacc being installed, and it expressed that dependency through requiring the "dev-utils" package, but your "dev-utils" doesn't include yacc. Now there is a package installed with an unmet dependency.
It's not really a problem.
A big part of being a Linux distribution is maintaining a central software repository. The distribution takes care of maintaining all of this for you. This actually makes it very easy to install software. You typically use the package manager to search for and select some packages, then tell it to install them; it takes care of the rest for you. The Windows software installation process includes hunting for software on 3rd-party websites, trying to locate the appropriate download link, downloading, virus-checking, and running an install program which then asks you a bunch of irrelevant questions. That whole mess isn't the standard on Linux.
The repository can't possibly include everything
Now, there may be cases where a piece of software you require is not in your distribution's repository. The packages that are supplied by a software repository is one of the differentiating features of distributions. When you can't find the software you need in your distribution's repositories, there are three possible avenues (really, two plus a way to really screw things up).
Community Repositories
Many distributions have unofficial repositories that are maintained by people not associated with the distribution. Ubuntu calls them PPAs, Fedora calls them Fedora People Repositories. Arch Linux doesn't have a specific name for third-party repositories, but it does have its AUR, which is a collection of "recipes" for packages (note: there is only one AUR). You might first try installing a package from one of these sources since it is easy to un-install them if they don't work.
Compile from Source
If you can't find an unofficial repository with what you need, compiling from source is not hard. You need to have your distribution's development package installed; this includes basic things like a compiler, linker, parser, and other tools that are usually needed for compiling software. Then you find the source code of the project (which is almost always packaged in a .tgz or .tbz (called a "tarball"). Download it into its own directory somewhere, extract it (using tar -xf filename.tgz, and usually go into the one directory it created. In that directory may be a file called README or INSTALL. If it exists, go ahead and read it; most of them tell you to do the same thing. The next few steps are done at a command line. Run ls, and look for an executable file called configure. If it exists, run it by doing ./configure; it can take a couple of minutes sometimes. That usually runs some tests to figure out how your distribution has things setup, and it makes sure you have the tools required to compile this piece of software. The next step is to run make. This actually compiles the software, and it will likely take some time - anywhere from a few minutes to hours depending on the size of the software you're compiling. Once that is done, you run make install. This installs the software, which involves copying the products of the compilation to the appropriate places in your filesystem. After that, the software is available for use.
This was a long section, but it's summarized as "README, ./configure, make, make install". That's the routine to remember.
Install a package from another distribution (don't do this)
I list this only because it is and alternative, but it will almost certainly not end well. It is possible to install packages for other distributions, and you might find yourself wanting to do that. Well, don't. Don't do it until you understand your system very well. In fact, I'm not going to put any commands here showing how to do it even though it's possible. If you do get to that point where it seems like this is the only option, don't install the package using the package manager; instead, pull things out of the package and place them in your system manually, along with notes about what you've done so that you can undo it if necessary.
The command-line bit
Some people prefer the command line for the advantages it gives them. These can be summarized into three things:
- Ease of automation
- Speed (compared to clicking all over the place in a gui)
- Expressiveness
The biggest of these is expressiveness; there are things that can be done at a command line that are not possible in a graphical interface.
Finally, command-line instructions are frequently given in helpful forums such as this one because it is much easier to convey the correct information than giving "click-here-then-there-then-there" type instructions.
Best Answer
What is UNIX at all ?
Short answer: UNIX is a specification/standard nowadays.
At the time of writing, to quote the official sources, "UNIX® is a registered trademark of The Open Group", the company which among many things provides UNIX certification:
The same page specifically states which specification defines UNIX:
Details of those specs can be found here. Curiously enough the latest standard listed on their website is UNIX 03, and to quote another source, "UNIX® 03 - the mark for systems conforming to version 3 of the Single UNIX Specification".
To quote the About Us page with my own emphasis in bold:
So what this suggests (or at least so is my interpretation), is that when an OS conforms to the POSIX standard and Single UNIX Specifications, it is compatible in behavior with Unix as an OS that once existed at one point in time in history. Please note that this does not mention the presence of any traces of the original Unix source code, nor does it mention the kernel in any way (this will become important later).
As for the AT&T and System V Unix developed by Ritchie and Thompson, nowadays we can say it has ceased to exist. Based on the above sources, it seems UNIX nowadays is not that specific OS, but rather a standard derived out of the best possible generalization for how operating systems in Unix family behave.
Where does macOS X stand in the *nix world ?
In a very specific definition, macOS version 10.13 High Sierra on Intel-based hardware is compliant to the UNIX 03 standard and to quote the pdf certificate, "Apple Inc. has entered into a Trademark License Agreement with X/Open Company Limited." Side note: I hesitate to question what it would means for macOS 10.13 on non-Intel hardware to be treated as, but considering that hardware is mentioned for other OS, the hardware is significant. Example: "Hewlett Packard Enterprise: HP-UX 11i V3 Release B.11.31 or later on HP 9000 Servers with Precision Architecture" (from the register page).
Let’s return to previous section of my answer. Since this particular version of OS conforms to interoperability and compatibility standard, it means the OS is as close in behavior and system implementation as possible to original Unix as an Operating System. At the very least, it will be close in behavior and in environment. The closer it gets to system level and kernel level, the more specific and shadier the area will get, but at least fundamental mechanics and behavior that were present in Unix should be present in an OS that aims to be compatible. macOS X should be very close to that aim.
What is a distribution ?
To quote Wikipedia:
Let's remember for a second that Linux as in the Linux Kernel is supposed to be distributable software, with modifications, or at least in accordance with GPL v2. If we consider a package manager and kernel, Ubuntu and Red Hat being distributions makes sense. macOS X has a different kernel than the original AT&T Unix - therefore calling macOS X a Unix distribution doesn't make sense. People suggest that macOS X kernel is based on FreeBSD, but to quote FreeBSD Wiki:
Some people mistakenly call the OS X kernel Darwin. To quote Apple's Kernel Programming Guide:
And to quote the same page:
Based on everything above we can confidently say, OS X is not a distribution, in the sense of Linux distribution. Similarly, other mentioned OSs are POSIX compliant and are certified Unix systems, but again they differ in kernels and variations on underlying system calls (which is why there exist books on Solaris system programming and it's a worthy subject in its own right). Therefore, they aren't distributions in the sense Linux distributions are - a common core with variations on utilities. In case of Linux, you see books on Linux system programming or Linux kernel programming, not system programming specific to distribution, because there's nothing system-specific about a particular distribution.
Confirmation of what we see here can be found in official documentation. For instance, article on developerWorks by IBM which addressed difference between UNIX OS types and Linux distributions states (emphasis added):
In other words, they are based on the same foundation, but they don't share exactly same one in the sense Linux distros share the kernel.
Considerations
Note that the word distribution appears to be mostly used when referencing operating systems which have the Linux kernel at its core. Take for instance the BSD type of Operating Systems: there's GhostBSD, which is based on the kernel and uses some of the utilities of FreeBSD, but I've never seen it to be referred to as a BSD distribution; every BSD OS only mentions what it is based on and usually an operating system is mentioned as an OS in its own right. Sure, BSD stands for Berkeley Software Distribution, but...that's it.
To quote this answer on our site in response to the question whether different BSD versions use same kernels:
They are not distributions in the sense of Linux distributions. Consider the copyright notice from this document:
Notes
In conclusion: