More work on dependency heck

005/codex-005.tex

@@ -1,4 +1,5 @@
 \documentclass[twoside]{report}
+
 \usepackage[utf8]{inputenc}
 \usepackage[T1]{fontenc}
 \usepackage{amsmath}
@@ -319,10 +320,74 @@ The short answer is that a lot of different software packages all need to do the
 
 To make things even less clear, a dependency doesn't necessarily have to be a library. It could be something like a configuration file, a device driver, or a database. 
 
-This is where things get confusing when it comes to computers. Not all dependencies are libraries (some are other things, like I mentioned), but not all libraries are dependencies. They are only dependencies for a particular bit of software. You can have a library on your computer which isn't used by any particular software package, and thus it is not a dependency. You can also have a library which is used by software package Foo, and so it's a dependency of Foo, but it's not used by software package Bar, so it's not a dependency of Bar. 
+This is where things get confusing when it comes to computers. Not all dependencies are libraries (some are other things, like I mentioned), but not all libraries are dependencies. They are only dependencies for a particular bit of software. You can have a library on your computer which isn't used by any particular software package, and thus it is not a dependency. You can also have a library which is used by software package Foo, and so it's a dependency of Foo, but it's not used by software package Bar, so it's not a dependency of Bar.\footnote{If you are not familiar with the ``Foo'' and ``Bar'' terminology, they are simply words that computer people use to substitute for anything else, be it a software package, a function, etc.}
+
+For what it's worth, it's not just Linux that does this. Windows also makes use of \texttt{.dll} file—Dynamic Link Libraries. These contain code and data that can be used by multiple programs. For example, there is a .dll file that just handles ``Open'' dialogue boxes. If you are writing a program for Windows, you don't need to worry about creating your own ``Open'' dialogue boxes. You can just call up this .dll file instead.
+
+That's the real reason for using libraries. If you are writing software, chances are it's goign to do a lot of things that other software packages do, like throwing up an ``Open'' dialogue, or printing a document, or displaying something on a monitor. There is no point in creating everything from scratch when so many of the basic things (and a lot of the advanced things) have already been built. 
+
+Using shared libraries also reduces the number of resources your computer is using. If you have ten different applications running, they can used these shared libraries which are probably already loaded into memory, rather than loading their own. As a result, you use less memory and things run faster. 
+
+Another advantage of using shared libraries is that they are well-written and usually perform without issues, because they are written by people who really know what they're doing. I may not have the foggiest idea of how to create an ``Open'' dialogue box, but I could figure it out if I had unlimited time and resources. The problem is that my time and resources are finite, so it's a better use of my time to rely on a library that already does this thing and does it well.
+
+The biggest advantage of using shared libraries (these days, at least) is \textit{security}. If a security flaw is found in a shared library, it only has to be fixed once. And because many, many people are using those shared libraries, security vulnerabilities have a better chance of being found—and fixed—quickly. 
 
 \section{Dependency Hell}
 
+Once you start to get into Linux, you inevitably hear about ``Dependency Hell''. This used to be a huge problem, but it has largely gone away. 
+
+Note that I said ``largely'' and not ``completely''. Hence, dependency \textit{heck}. 
+
+Dependency hell is what happens when you try to install new software on your computer, but some of the dependencies are missing, conflict with one another, or have been deprecated.\footnote{Because this is no longer much of a problem, I don't want to get into it too much. If you are interested, Wikipedia has an excellent article on depency hell at \kref{https://en.wikipedia.org/wiki/Dependency\_hell}{https://en.wikipedia.org/wiki/Dependency\_hell}.} This problem has largely gone away due to the use of package managers, which handle the actual compiling and installation of software, because they handle issues with dependencies on their own. 
+
+For example, on Debian/Ubuntu systems, the default package manager is \texttt{apt}. Red Hat/Fedora uses \texttt{dnf}, openSUSE uses \texttt{zypper}, Gentoo uses \texttt{emerge}, and ArchLinux uses \texttt{pacman}. In fact, the ArchLinux wiki has a page which extensively documents the difference between these different package managers.\footnote{See \kref{https://wiki.archlinux.org/title/Pacman/Rosetta}{https://wiki.archlinux.org/title/Pacman/Rosetta}.} If you've never gotten further than \texttt{sudo apt install foo}, you will find a lot of useful information there.
+
+I know I did. For example, I usually install software using \texttt{sudo apt install foo}, but there is a parameter (which I would know about if I had read the \texttt{man} file for \texttt{apt}, which I obviously have not—in general when working in \texttt{sudo} I just want to do my business and get out) which will just do a dry run of the install: \texttt{sudo apt install --dry-run}. 
+
+For example, if I'm thinking about install meld (which is a great little tool for visually comparing files and directories, and which will help you merge them), but I'm not sure what all is going to be installed, I can just run 
+
+\input{include/installmeld}
+
+which then gives me this output:
+
+\begin{Verbatim}[frame=lines, numbers=left, xleftmargin=5mm, framesep=3mm, breaklines=true, label=\fbox{}]
+NOTE: This is only a simulation!
+      apt needs root privileges for real execution.
+      Keep also in mind that locking is deactivated,
+      so don't depend on the relevance to the real current situation!
+Reading package lists... Done
+Building dependency tree... Done
+Reading state information... Done
+The following packages were automatically installed and are no longer required:
+  libwmf0.2-7 php8.2-common php8.2-mysql
+Use 'apt autoremove' to remove them.
+The following NEW packages will be installed:
+  meld
+0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
+Inst meld (3.20.4-2 Ubuntu:22.04/jammy [all])
+Conf meld (3.20.4-2 Ubuntu:22.04/jammy [all])
+\end{Verbatim}
+
+This is highly useful information, so let's break this down a bit.
+
+\begin{enumerate}
+\item First, \texttt{apt} is telling me that this is only a situation, so I don't have to go into Karen mode when I try to run this application later and can't find it.
+\item It's also reminding me that \texttt{apt} needs root privileges to actually do anything. I didn't use \texttt{sudo} here because I don't want to get in the habit of using it all the time.\footnote{Which is the same reason I don't use the ATM at a casino. If I'm out of money, it's time to go home.}
+\item It also tells me that I have a couple of packages that I don't really need, and it provides the command I need to remove them.
+\item It then tells me which packages it will install. In this case, it's only going to install the \texttt{meld} package, which means either that \texttt{meld} doesn't need any dependencies, or that all the ones that it needs to function are already on my system.
+\end{enumerate} 
+
+This is the kind of information I need to think about before I install something. How many new packages will I have to install? How much space will it need? What am I even doing with my life? (Okay, there's no option for that, but it sure would be nice if there were one, wouldn't it?)
+
+\section{Containers}
+
+As a way around any risk of dependency hell (or dependency heck), software developers have also started putting their software into containers. A container is basically an entire runtime environment: it's your application, all of its required libraries and binaries, along with any configuration files, all bundled into a single package.
+
+And yes, if it seems like we are moving backward, we are, in a way. I'm not going to say too much about these because I am not terribly familiar with them, although I've used a few of them. This is going to be a very brief rundown, because if I go into too much detail, I am likely to be wrong.\footnote{To be honest, I'm not even sure that the word ``container'' is the right word here because a lot of people on the internet cannot agree. Just be aware that if you research any of this on the web, be aware that you will find a lot of people who agree with my characterization (yay! I'm right!) and you will also find a lot of people who disagree with my characterization (poop! I'm wrong!). Such is life.}
+
+
+
+
 \section{What Probably Happened Here}
 
 

005/include/installmeld.tex

@@ -0,0 +1,3 @@
+\begin{Verbatim}[]
+$ apt install meld --dry-run
+\end{Verbatim}