Updated «Dependency Heck»

005/codex-005.tex

@@ -330,7 +330,7 @@ I use Okular as a pdf viewer. Even though Ubuntu has a default pdf viewer (Evinc
 
 The problem is that there is no perfect way to install things in Linux. There are many different ways, and some ways are better than others. I had originally installed Okular from the GNOME Software store. The version it installed was an older one though, and it would not update to a newer version that had a feature I wanted.\footnote{Specifically, the option to view bookmarks from a single pdf document, rather than all of them. I get why you \textit{sometimes} might want to view all the bookmarks in every document, but it doesn't make sense to me to have that on all the time.} 
 
-I decided to uninstall that one and then install it from Flatpak. This gave me the latest version (24.05.1) which did have this feature. The problem then became that Okular would not open new documents in tabs—it opened each one in a separate window, which I just find annoying. This works if you use \texttt{File $\rightarrow$ Open} to open your pdfs, but who does that? That's the point of a GUI—you can just double-click on files to open them.\footnote{As it turns out this is not so much an Okular issue as it is an ``Okular in Flatpak'' issue. See \kref{https://github.com/flathub/org.kde.okular/issues/36}{https://github.com/flathub/org.kde.okular/issues/36} and \kref{https://bugs.kde.org/show_bug.cgi?id=427653}{https://bugs.kde.org/show\_bug.cgi?id=427653} for more information.} So I uninstalled the Flatpak version until they get that bug fixed (although a bug report was filed for this issue in 2020, so it doesn't look like a priority). 
+I decided to uninstall that one and then install it from Flatpak. This gave me the latest version (24.05.1) which \textbf{did} have this feature. The problem then became that Okular would not open new documents in tabs—it opened each one in a separate window, which I just find annoying. This works if you use \texttt{File $\rightarrow$ Open} to open your pdfs, but who does that? That's the point of a GUI—you can just double-click on files to open them.\footnote{As it turns out this is not so much an Okular issue as it is an ``Okular in Flatpak'' issue. See \kref{https://github.com/flathub/org.kde.okular/issues/36}{https://github.com/flathub/org.kde.okular/issues/36} and \kref{https://bugs.kde.org/show_bug.cgi?id=427653}{https://bugs.kde.org/show\_bug.cgi?id=427653} for more information.} So I uninstalled the Flatpak version until they get that bug fixed (although a bug report was filed for this issue in 2020, so it doesn't look like a priority). 
 
 I tried installing it directly through snap using this command:
 
@@ -358,7 +358,7 @@ which tells us that this particular dependency is contained in \texttt{kf6-core2
 
 \input{include/sudoinstallkf6}
 
-Unfortunately that told me that this dependency was already installed. But it's probably not an updated version of it that will run with this newer, improved version of Okular. That's okay, we can fix that with 
+Unfortunately that told me that this dependency was already installed. But it's probably an older version of it that will run with this newer, improved version of Okular. That's okay, we can fix that with 
 
 \input{include/snaprefresh}
 
@@ -372,13 +372,13 @@ I'm so glad you asked.
 
 The short answer is that a dependency is a collection of code that another piece of software relies on to do something. Which leads us to another question—why doesn't the software in question contain all the code that it needs to have in order to operate? Why do we bother with dependencies?
 
-The reason is that a lot of different software packages all need to do the same thing. So rather than include that other thing in each software package, we bundle it into a \textit{library}—a bit of software that other software packages can rely upon if they need to. When they do that, this library is now a dependency. The software package in question can't run without it.
+The reason is that a lot of different software packages all need to do the same thing. So rather than include that other thing in each software package, we can bundle it into a \textit{library}—a bit of software that other software packages can rely upon if they need to. When they do that, this library is now a dependency. The software package in question can't run without it.
 
-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. 
+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 even 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.\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} files—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.
+For what it's worth, it's not just Linux that does this. Windows also makes use of \texttt{.dll} files—Dynamic Link Libraries. These contain code and data that can be used by multiple programs. For example, there is a \texttt{.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 \texttt{.dll} file instead.
 
 That's the real reason for using libraries. If you are writing software, chances are it's going 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. 
 
@@ -386,7 +386,7 @@ Using shared libraries also reduces the number of resources your computer is usi
 
 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. 
+The biggest advantage of using shared libraries (at least these days) 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}
 
@@ -398,9 +398,9 @@ Dependency hell is what happens when you try to install new software on your com
 
 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}. 
+I know I did. For example, I usually install software using \texttt{sudo apt install foo}, but there is a parameter\footnote{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 \texttt{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 
+For example, if I'm thinking about install \texttt{meld} (which is a great 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}
 
@@ -428,7 +428,7 @@ 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 simulation, 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'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. There's no point in training your brain with bad habits.}
 \item It also tells me that I have a few 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}