Although this is now in your hands, and it's also on the web, so if you really wanted to steal this, I've made it pretty darn easy. I can't imagine why anyone would want to, though. However, you don't need to, because this is licenced under a CC BY-NA-SA 4.0 Creative Commons license. More information is at
FYI, this is made in \LaTeX\,using the report document class. It then gets exported to a letterhalf (5.5 in x 8.5 in) pdf, which then gets made into a booklet using PDF Booklet, which you can find at
The image of Linus Torvalds on the front cover is courtesy JericoDelayah from the WikiMedia Commons and is at \kref{https://commons.wikimedia.org/wiki/File:4_RETAT_04_Linus_Torvalds.jpg}{https://commons.wikimedia.org\\/wiki/File:4\_RETAT\_04\_Linus\_Torvalds.jpg} where you can also find a link to the Creative Commons CC BY-SA 3.0 license there, as well.
I'm pushing this to my own git server as I write this. You can find it \href{https://git.kjodle.net/kjodle/the-codex}{here}: \kref{https://git.kjodle.net/kjodle/the-codex}{https://git.kjodle.net/kjodle/the-codex}. New issues will be pushed after they are complete. A list of topics I may cover in the future can be found at \kref{https://git.kjodle.net/kjodle/the-codex/wiki/List-of-Future-Topics}{https://git.kjodle.net/kjodle/the-codex/wiki/List-of-Fu\\ture-Topics}.
You can just skip over all the diversions in here if you want. It's just how my mind works. (And yes, there will be politics in this. \textit{You have been warned.}) Also, I use a lot of em-dashes, parentheses, and footnotes because that is also how my mind works. It's just one big long stream of consciousness up in here most days.
If you want to donate financial support for the creation of this zine (and all the hours of research that go into it), you can do so at
\noindent\textbf{Credit where credit is due:} A lot of people have come forth (mostly from Reddit) to help me out in various ways. See the preamble to this document in the source code to see them. One aspect of our society is that nobody \textit{has} to help you. It is wonderful when it happens, and I am grateful for their help.
My early experiences with computers were on TRS-80s (aka, ``Trash-80s'') and Commodore machines, and in those days if you wanted a computer to do something you had to write that program yourself or copy it laboriously line-by-line out of a magazine like \textit{Byte}. If you were lucky, a friend might have a program on a floppy disk and could make a copy for you—if you had a blank floppy disk. A 5\nicefrac{1}{4} inch floppy disk cost around \$1.50 in 1980, which is roughly \$6.00 today. While I might have been able to scrape together \$1.50 once or twice back then, I couldn't do it on a regular basis. As a result, I type really fast.
By the time I got to college, the computer labs were mainly just terminals that would allow you to access the mainframes that may as well been in Narnia for all we knew. The concept of a computer was still fairly abstract to a lot of people back then. Families that actually had a computer were still quite rare, and as the potential uses for them were still quite limited in those days, few people saw value in owning one. They were not the absolute necessity that they are now. They were more like a toy, a plaything, something that you used two or three times a week and then went back to your normal life.
Before I went back to college in 2008, I had been working on an ancient Macintosh. I had managed to inherit a series of used Macintoshes or purchase some that had been deacquisitioned by our local university.\footnote{If you like bargains, your local college's or university's suplus sales are your new best friend.} Thanks to a billing error, my parents came into a small amount of money and bought me a Mac Mini.
Anyway, I went back to college with that Mac Mini, a dial-up internet connection, and Microsoft Word. Oddly, that was enough in 2008.
Well, not quite. I lived in the boondocks and things were well enough along at that point that the internet was an absolute necessity. The lack of high-speed internet (and of a laptop) meant that I either spent ridiculous amount of time at home trying to do research, or that I spent of bunch of time on campus in the computer lab doing research and putting a bunch of downloaded pdfs on a jump drive.
But made it work. I managed to get my English degree, pick up some honors along the way, pick up a scholarship that allowed me to take just one more class, and I did it. It could be done then. I'm not so sure about now.
It was a lot more work than it should have been, though. Computers were supposed to be the great equalizer, and when they failed to achieve that, then the Internet (which was always spelled with a capital letter for a while) was supposed to be the great equalizer. But it was not. As Wiliam Gibson said, ``The future is already here—it’s just not very evenly distributed.''
Could have I have done better or done more with high-speed internet and a laptop. I have no doubt that I could have.
But this not the question that haunts my days and nights. I'm fairly good in the classroom, but I'm a fair to middlin' scholar. No doubt there are far better scholars than myself. But while I made due with dial-up internet, they may not have had internet at all, or even a computer.
I always think that the person may have discovered a cure for cancer could quite possibly have shit their guts out and died at the age of five in some third-world country simply because some first-world millionaire couldn't figure out how to make a profit out of feeding them or providing them with health care. But had this person grown old enough to develop this cure, there is no doubt that a hell of a lot of first world companies would have been lining up at the door to exploit that cure for profit.
There is a philosophical word for this position: hypocrisy.
There is also a biological word for this position: parasitism.
But there is also the philosophical position that this person who may have started WWII could also have shit their guts out and died at the age of five in some backwater central European village and nobody bothered to provide them with food or healthcare, and so the greed of capitalism has averted a massive disaster. \textit{Qué será, será} and all that.
But all of that is hypothetical. It's all what might have been. It's an interesting intellectual experiment (which I hesitate to describe as ``fun to think about'' but that's the English language for you. The denotations are the same, but the connotations could not be more different. It's kind of the difference between ``have a nice day'' and ``enjoy the next 24 hours as much as you can.'')
So let's talk about what's not hypothetical, but about what's actually possible. But wait, that's not a yesterday thought—that's a tomorrow thought.
At any rate, I emerged from college with an English degree and a newly refreshed teaching certificate. My grades were good enough that I managed to earn a place in Sigma Tau Delta, the International English Honor Society.\footnote{\kref{https://www.english.org/}{https://www.english.org/}} I had a website, and had recently installed a Wordpress blog to talk about books.\footnote{\kref{https://bookblog.kjodle.net/}{https://bookblog.kjodle.net/}} ``Web 2.0'' was a buzzword and we still thought that social media could transform the world for the better.
We were wrong. Social media is a great way to make the world better. It's also a great way for nut jobs and conspiracy theorists and racists and fascists to connect with each other and increase their levels of hate and ignorance exponentially. What have we done?
I have previously mentioned the educational-industrial complex and its very aggressive embrace of what was then called ``Web 2.0'' and how just devolved into little more than social media.
Because I wanted to be seen as someone who could ride this wave into the future, I decided to embrace it wholeheartedly. I decided to get a website first, so I looked around, found a webhost (who was also a domain registrar—convenient), plunked down \$30, and I was in business.
This was my first real experience with a server and FTP. I had made websites before, usually as something free (that is, along the line of GeoCities) or something similar through my ISP (AOL used to give you a free website) but these were all web-based uploads. You had no control over anything, basically. They would put ads and the top and bottom of your web pages and hoped that your page would interesting enough and would attract enough eyeballs that it would not just cover the server costs but also feed the shareholders—oink, oink. (In point of fact, these usually covered the server costs and then some, but the shareholders are always hungry, no matter how much they are fed. So these things are doomed to failure by their very business model, as they are always based on ``growth''. In reality, creativity and genius ar unlimited, but the amount of time and energy we have to look at those things are. Capitalism is a snake that eats its own tail.)
I had to learn FTP, which meant that I needed an FTP \textit{client}. I had no idea what a client was, so I had to learn some new vocabularly. It was like being in elementary schools again, where new words were printed in boldface and then defined in the margin. But I eventually figured out (through learning JavaScript) the difference between client-side (your computer) and server-side (their computer).
With an FTP client in hand, I could now upload files to my web site far faster than i could via a web based file upload, perhaps because FTP clients don't need to wait for ads to load. I had no idea how to properly view these files locally before I uploaded them to the web, so the only way I could check that everything was correct was to upload them and then refresh my web browser.
FTP gave me a lot will have control over a website that I had never had before but if i've learned anything think from reading comic books it's that great power comes with great responsibility. Sure you can do more things now and rely less on your hosts for certain things (and learning neat .htaccess tricks is but the first of these) but that means that you must assume more responsibility for things. If you screw up a config file it's entirely possible that your web host has a backup copy somewhere and you can file a support ticket and they will eventually get around to replacing it. Even better is when you screw up a config file but you have a backup version of it and can just FTP it to your site. The ideal situation would be to understand that config file well enough that you never make a mistake with it but that's not going to happen we're all human we all make mistakes. To err is human, to have an uncorrupted back up is divine.
But yeah let's talk about backups. If you're going to have a website than you need to seriously consider handling backups on your own. Sure, your web host might make weekly backups, but that is to cover their ass not yours. Their backups are there to cover their fuck ups not yours. The only way to recover from your own fuck ups is to manage your backups.
That's not always a simple thing. Because Web 2.0 included blogs I decided to start a blog where i could use my newly minted English degree to talk about books. My web hosts at the time had a one-click install for WordPress which was then considered to be a blogging platform and little else, so I clicked once and the Big Bad Book Blog was born.
Until then i had been fairly comfortable with everyday run of the mill HTML and CSS files. But nothing is perfect right out of the box and iIfound that my newly formed book bblog was less than satisfying to me. Changes were obviously needed.
The challenge/problem for me is that WordPress is a web application that uses PHP, CSS, and Javascript. I could handle CSS, but I needed to figure out PHP and Javascript.
So yep, Ihad to learn PHP at least in a rudimentary way, and I had to learn some Javascript in an even more rudimentary way.
Let's back up a bit but to understand how this works. It's actually pretty complicated but I'm going to present a greatly simplified version of this.
When you visit a website, there are two computers involved (mainly)—yours and one that is actually hosting all the files that make up that website.
Your computer is called the client computer. When you view a website on your computer you are looking at it in a web browser which is a client-side technology. That is, it exists on your computer. If you don't like the web client you have now you can install a different one.
On the other hand all those files that your client is downloading and presenting to you as a web page must exist somewhere. And they do—on a server somewhere. When you sign up for a website what you are doing is agreeing to pay money for some space on a computer that has been can configured to serve those files to whomever asked for them. In other words, it is a server.
Like i said you can use an FTP client to move files over to your server but if you must make a mistake in one of those files and don't catch it before you upload it then it's there for all the world to see. Even worse you can upload a file with serious errors in it that causes your entire website to not be available. Uh-oh. that's not good.
The obvious solution is to do all your practice runs in a localhost environment.
I got myself a web site and got myself a blog but the educational-industrial complex said that web 2.0 was the next big thing. I thought that having those things would give me a leg up on to the (then) very tight job market.
Alas the educational industrial complex does not exist to do right by students. They largely exist to extract as much as profit as they possibly can. (Guess what---their lobbyists are also behind a lot of the legislation that requires these expenditures. Your tax dollars are not going toward making your child education better, but toward making rich men richer. Yay, capitalism!
Part of the problem with the educational system in the United States is that it's coupled to so many other things. For every teacher that loves their subject matter and once to change kids lives there is at least one (and often two or three teachers) that are there so they can have the summer off or coach the golf team.
In reality they are right—teaching as a profession a job it should not be a cause but as long as there are so many inequities and inequalities in our society teaching will always be a cause because young people are the most effective place to make a chain.
The irony here is that while a teaching profession appears to be very progressive and embracing of new technologies, that is only true on the surface. Under that surface it is deeply deeply conservative. Principals don't want to hire teachers who might rock the boat and teachers are deeply territorial. I suppose the latter is only to be expected when you work in a chronically under funded and under appreciated field.
An aside.
I saw a tweet a couple of years ago by someone in law enforcement who was responding to the ``defund the police''' initiative complaining about how hard it is to be a cop these days and that no other profession has ever been the victim of a defunding initiative. I'm sorry that simply is not true—Republican law makers have been trying to defend public education my entire light.
My web Host offered word press that a one-click installer which meant that you enter few details, click the install button and voila! You have a word press blog. You might know absolutely nothing about web technologies but suddenly here you are easy peazy mac and cheesey—with a blog.
I don't remember exactly when this was but it was before tablets and mobile phones were ubiquitous.
I like having a blog to review books as I thought it would put me head and shoulders over any other potential teaching candidate and getting things done on paper always helps me organize my thoughts.
Alas, I was not entirely happy with the appearance of my blog. At this point knew HTML and I knew CSS but I knew nothing about PHP which is what WordPress is built with. Nevertheless i jumped right into WordPress built-in file editor and started pressing buttons.
This is of course exactly what you are not suppposed to do. I made plenty of mistakes and bolloxed the whole thing up and had to start over from scratch more than once.
It was fun but it was also frustrating to have to start over so i did what i should have done in the first place and RTFM. I learned about the proper way to edit your themes, which is that you don't—you create a child theme and do your mischief there. I learned a lot more about HTML and CSS and delved into the world of PHP and Javascript enough that I was able to develop my own plugins and eventually themes from scratch.
I found a highly adaptable theme that I really loved (Graphene) and became an expert in it and started helping out in its support forums. The theme's developer appreciated my efforts and made me a moderator in those forums and also gave me free access to the mobile-friendly version of the theme. It was a great time and I was learning a lot.
This was back when mobile was just becoming a thing and a lot of websittes had two versions of their site—a desktop version first and a mobile version second but at some point people began accessing websites more on their mobile devices than on a desktop so that process is now reversed—we develop first for mobile and then usually later for desktop, sometimes poorly. If you've ever been to a website that looked fine on your phone but looked like an utter shit show on your computer this is why.
I was not, however, getting a teaching job. I was getting lots of opportunities as a substitute teacher but that was because I could follow a lesson plan, I could manage a class room and keep kids in line, and I would actually teach and then wander around the classroom and make sure kids were learning.
I am in a very different place now than I ever thought I would be. I'm not on Plan A or Plan B. In fact, I've pretty much run out of alphabet to describe exactly where I am now.
I work as a data reviewer for a contract research organization in the pharmaceutical industry. That means that drug companies send us samples of their products, and we test them for things like assay, impurities, appearance, disintegration, etc. People who majored in chemistry run the tests and I sit there and look at their procedures and results and make sure that everything was performed correctly, that the math is correct, and that the results are, indeed, valid.
In theory, I'm an analytical chemist. In practice, I'm a nerdy science accountant who spends the day with his nose buried in Excel spreadsheets. A \textit{lot} of Excel spreadsheets.
Except that I also used to design websites, so my spreadsheets are easy on the eyes, color-coded, and logically oriented—that is, they take you through the analytical method in a step-wise, chronological manner. In other words, we look at standard concentrations first, and then our system suitability tests, and then the actual tests. Every cell is also labeled, so it's clear what goes where.\footnote{For a visual depiction, see \kref{https://www.youtube.com/watch?v=4IFUYg9IUgI}{https://www.youtube.com/watch?v=4IFUYg9IUgI}.} My boss admires them and I am justifiably proud of them. After all, these aren't just your ordinary, run-of-the-mill spreadsheets we're talking about here.
My spreadsheets are so beautiful that when my boss got a glimpse of them he immediately placed me in charge of mentoring new data reviewers, mostly so that they could see what my spreadsheets look like. And I get it. I worked really hard to make spreadsheets that are understandable not just to me but to everybody because we may have a corrective action come up at some point and we need to be sable to see how we arrived at the results that have. So yep, I strive to make all my spreadsheets consistent and understandable to someone who has no familiarity with them.
But it's not satisfying work. It pays the bills.\footnote{Well, barely (and by the time you're reading this, probably not actually), after the recent fit of massive corporate price gouging—I mean, er…inflation.} It's not exactly the hind end of science, but it's close. (I once worked in a lab that did non-clinical testing\footnote{That is, rats and mice. Lots and lots of rats and mice.} and believe me, \textit{that} is the hind end of science.\footnote{Science actually has many hind-ends. This is but one of them.}) I'm not really doing science; if anything I'm just a science accountant, making sure the books balance. It's boring—\textit{really }boring—and more than a bit mind-numbing.
Considering that my entire job exists to help keep the drug supply safe\footnote{Well, the \textit{legal} drug supply anyway.} that statement may sound frightening or even disturbing. But it's not really. You \textit{want} this job to be boring. When it's not boring, it's generally because something has gone wrong, and and this is one of those industries (like nuclear energy or air traffic control) where you really \textit{don't} want things to go wrong.
The irony is that I took this job because I \textit{knew} it would be boring. My last job had been so nerve wracking that mentally I was completely spent by the time I got home and creating anything at that point was damn difficult if not impossible. I figured that if I had a job that was boring where creativity was not encouraged (that is, we have a procedure, so just stick to the procedure) I could store my creative juices during the day the and use them during the evening to create things.
You can't store up creativity during the day and then use it all up in the evening. That's not how creativity works. What happens instead is that your creative juices just dissipate throughout the day and when your day is over you're just empty—a dried up husk that could be blown away by the lightest breeze.
One of the things that attracted me to teaching was that I got to be creative all day. What I forgot about teaching is that when I got home I was still charged up creatively. I hadn't used up all my creativity. I had multiplied it.
Ages ago I saw an interview you with the father of a very large family (which had grown mostly through adoption) and the reporter asked him how he divided his love among so many kids. His answer was brief and to the point: love is not something you divide he said, it's something you multiply.
Creativity is the same way. You can't save up creativity so you can use it later. Creativity is something that cannot be divided. It must be multiplied.
I've since come to view creativity like a river—it has to move to do anything. It can move boulders and it can sift the finest silt. It can carve a valley through a plain or it can split mountains. It can nurse the communities around it and it can serve as a way for them to get from one place to another.
Dam a river and it does not become a lake, it becomes a prisoner. It is not content with its lot. It constantly seeks to escape. And when it finds it, it will give some small warning but then it will completely and utterly destroy that dam.\footnote{See \kref{https://damfailures.org/case-study/teton-dam-idaho-1976/}{https://damfailures.org/case-study/teton-dam-idaho-1976/} for a good example of this.}
That's what I've been doing with my creativity. I've trying to dam it up during the day and then release it in the evening. But it doesn't work that way. You can't hold back creativity. You can't divide it up, hour by hour. You can't parse it out drop by drop. Using your creativity doesn't mean that you use it up. Rather, creativity, like love, can only be multiplied. Creativity just leads to more creativity. It's not a zero-sum game.\footnote{\kref I wish people would realize that our economy—which is not a natural thing, but a thing completely invented by humans—does not have to be a zero-sum game. Just because somebody else gets something they need does not automatically means that I get less of what I need.}
Those are the two things I have always been. I don't mean those two trajectories revealed themselves to me when I was in college. I mean that I knew these thing when I was eight or nine years old.
I have always scribbled. I got a hold of a manual typewriter at the age of eight or nine (I am fairly certain it was an old K-Mart model—I know for sure that it was blue and that I found it in our attic) and never looked back.\footnote{I'm pretty sure it looked like this one: \kref{https://gallery.kjodle.net/picture.php?/628/category/76}{https://gallery.kjodle.net/picture.php?/62\\8/category/76}.}
As for the teaching thing, I'm not quite sure. I've always enjoyed learning things and knowing how to do things and sharing that knowlege with other people in the hopes that that might change their life for the better.
Long ago, I realized that information is just data—which you can get from encyclopedias and dictionaries (and these these days the internet if you know where to look). But knowledge is information \textit{in context}, where it's part of a whole that helps you understand how the universe is put together and how it works. Most people think that teaching is just about providing information (no doubt a result of our over-reliance on worksheets and scantron sheets and Bush II's policy of ``no child left untested''). And that is unfortunately what a lot of teachers do—they force feed kids information, which most kids retain just long enough to regurgitate on a test and then promptly forget.\footnote{Although some of it sticks with us—Mr. Rex insisted that we would need to know the definition the ``mercantilism'' to succeed in college comes to mind. Oddly, the last placed I was asked for that definition was on his final exam.}
Good teachers provide that context. They provide information along with the context and then guide their students through building knowledge out of those. If you can figure out the information and figure out the context and know how to weave those two things into actual knowledge you'll always be able to figure out any task, any role, any job. You'll be able to do anything you set your mind to.\footnote{I haven't even talked about wisdom yet, which is knowledge tempered by experience. And I don't want to discuss it, perhaps mostly because I lack it. But basically information is knowing what a thing \textit{is}, knowledge is knowing \textit{how to do} a thing, and wisdom is knowing \textit{when} to do a thing.}
That was what I loved about teaching—that if I were allowed to do it right I could empower people just now but for the rest of their lives. I once answered a question in a job interview that when it comes to teaching of course I take the long view. The kid I'm teaching today might be working on my brakes in ten years. The kid I'm teaching today might be doing heart surgery on me in twenty years. This is not selfishness. The kid who is working on my brakes is also working on lots of other people's brakes and the kid doing open heart surgery on me is obviously not doing this as a one-off.
The point is that human existence is a tapestry. We're all connected, like it or not, to other people. That tapestry has a lot of holes in it (thanks to war, disease, capitalism, etc.) so of course most of the time we can't see a direct connection to some other people simply because it isn't apparent. But we are all connected nevertheless, whether directly or indirectly. Our choices and our actions have effects that we cannot predict on people we cannot even see, sometimes because they don't exist yet.
So yeah—that is what teaching was about for me—showing kids that they are part of a rich tapestry and that it's okay if they can't see the entire thing because \textit{none} of us can.\footnote{I would like to carve out an exception here for someone like the Dalai Lama, but I think he would be the first person to say that he can't see everything. He can merely see further than most.} The important thing is knowing that you are part of something larger than yourself and to know how to reach out to others when you need help and knowing how to respond to others reaching out to you because they need help. That was my mission as a teacher. I suppose that now, it's my mission with this zine.
It's also why I am not a teacher or now and never will be again—because there is no fucking way that any part of that can ever be converted to a multiple choice question that can be graded by running a scantron sheet through some 1970s-style technology.
Fortunately there there's a sweet spot in all of that that is small but doable. That sweet spot is technical writing. I actually did a lot of technical writing in my last job.\footnote{One of the best compliments I've ever received is that a former colleague who also left that company and eventually went back to it told me that she could ``see my hand in everything we do'' which is a great compliment, but after all, I \textit{literally} wrote the book on that place. She wanted me to come back, but nope, there were reasons that I left, and they haven't changed.} I took my current job because I was led to believe that it would include a lot of technical writing. The amount of technical writing I've done so far as zero. If I wiped my ass with all the writing I've done I would have shit all over my fingers.
Technical writing—that is, writing instruction manuals and work instructions and translating what the chemists and engineers wrote into something that regular people can understand—is what I need to do do because it lands smack dab in the middle of this Venn diagram:
The problem is that while I've pretty much spent my life doing technical writing, my resume doesn't reflect that. I have always been a jack-of-all-trades/master-of-none so I need to make sure my cover letter reflects that. We shall see how it goes.\footnote{I have a lot to save about this, but I'll hold my tongue for now.}
I use Okular as a pdf viewer. Even though Ubuntu has a default pdf viewer (Evince), it doesn't have a lot of features and is unreliable in some ways. Okular has always been a better choice for me.
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 tried installing it directly through snap using this command:
\input{include/snapinstallokular}
\noindent{}and this \textit{did} give me the latest version. But it wouldn't open. I tried opening it from the command line and got this:
\begin{Verbatim}[breaklines=true]
/snap/okular/155/usr/bin/okular: error while loading shared libraries: libKF6Parts.so.6: cannot open shared object file: No such file or directory
\end{Verbatim}
This is, believe it or not, progress. What this is telling us is that Snap did not install all of the required dependencies, which in this case is \texttt{libKF6Pars.so.6}. So the issue now is: where can we can get that dependency from?
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
\input{include/snaprefresh}
That updates the dependencies and also means that Okular will run. A quick check of \texttt{Help $\rightarrow$ About Okular} confirmed that I am on version 24.05.1 and that new documents are opening in tabs when I double click on them in the file manager.
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 short answer 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.
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.\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.
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.
Using shared libraries also reduces the number of resources your computer is using. If you have ten different applications running, they can use 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.
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 \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
\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 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, 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.}
\paragraph{Snap} First developed by Canonical (which is the for-profit company behind Ubuntu) this creates a new directory in your \texttt{\$HOME} directory to install snaps. (I did not like this at first, but okay, whatever.) One of the ideas behind snaps is that you can run different versions of the same program. Which would be handy, except that the people responsible for maintaining the snap packages do a pretty crap job of it, and most snaps are a version or two (or more) behind the current release version.
\paragraph{Flatpak} A quick look at the Flatpak home page\footnote{\kref{https://flatpak.org/}{https://flatpak.org/}} shows that they consider themselves ``The future of apps on Linux''. That's pretty confident. But the idea is pretty much the same as a snap. You first have to install \texttt{flathub}, then you download the relevant file from \kref{https://flathub.org/}{https://flathub.org/} and install it. It's not perfect, but for the one app\footnote{Paper Clip, which allows you to quickly and easily edit a pdf file's metadata. If you need to do that, I highly recommend it. See \kref{https://flathub.org/apps/io.github.diegoivan.pdf_metadata_editor}{https://flathub.org/apps/io.github.diegoivan.pdf\_metadata\_editor} for details.} I need that is only available as a Flatpak, I suppose it works well enough. But I would hate to have to install \textit{all} of my software this way.
\paragraph{AppImage} This is perhaps the simplest one I've used—you just download a file, make it executable,\footnote{You do this by updating the execute bit with \texttt{chmod +x file.AppImage}.} and then run it. I don't have too much of an issue with this one, but I only have a couple of apps that run from an AppImage. (Among them is the Cool Retro Terminal,\footnote{\hspace*{-1mm}\kref{
https://github.com/Swordfish90/cool-retro-term}} which takes me right back to my days in seventh grade. It's pretty cool, but depending on the day it either makes me sad or happy, so I don't use it often.)
Dependency hell is suppposed to be a thing of the past, so I'm not quite sure why I ran into an issue with dependencies when trying to install a different version of Okular.
It's possible that the snap was configured wrong. It's also possible that I borked\footnote{I.e., I misconfigured or broke something.} something without realizing it when I was doing something else. (I do have a tendency to tinker with things under the hood.) Unlike the days of old I did not have to spend hours or days trying to figure this out. A couple of quick web searches got me up and running again.
\lettrine[lines=2, loversize=0.2, findent=2mm, nindent=1mm, image=true]{git-icon}{} Git is version control software. That is, it allows you to record and track changes to a set of files over time. You can then compare different revisions or even revert some files or the entire project back to a previous version.
What I'm going to do here is describe how I understand and use Git. I am far from a power-user or expert in Git, so I may get some things wrong. This is definitely not intended to be at all comprehensive, but more just a way for you to get your feet wet.
Git is great if you are a software developer, because as you work you make a \textit{lot} of changes to your code. It's also great if you are a writer, because you can experiment as much as you want and not have to worry about losing or overwriting something. You can just revert to an earlier version, or \textit{branch} in order to experiment. But more about that later.
Git works best with text-based files—basically, anything that has a \texttt{.txt}, \texttt{.html}, \texttt{.css}, \texttt{.php}, etc. extension will work. There's no reason that you can't add binaries, such as images, pdfs, Microsoft Word files, or LibreOffice files. (I'm writing this zine in \LaTeX{}, and do include a few images in most issues, for example.) The issue is that because they are binaries, Git won't be able to tell you the difference between versions. (I would add, though, that if you are writing, you really should separate out the content and the styling from the beginning, so that you can focus on the story you want to tell. Plain text files are your friends.)
If this is your first exposure to version control software you'll make faster progress if you understand some of the basic concepts. If you are coming to Git from a different version-control software, then some or all of these concepts will be familiar to you, although they will probably have different names and probably different functions. Keep in mind that all of these technologies work differently, so you may have to retrain your brain to follow a different workflow.
\paragraph{Concept One: Git exists in both time and space.} This is true of just about all version control software, or at least all the different types I am aware of.
\paragraph{Concept Two: The basic time unit of Git is a \textit{commit}.} A commit is simply a snapshot of where your project stands at any given moment. When you make a commit, it's like taking a picture of your project at that particular moment.
\paragraph{Concept Three: The basic space unit of Git is a \textit{repository}.} All those commmits have to live somewhere, and a repository is just a place where all those commits exist. Repositories (or ``repos'' for short) can be \textit{local}—that is, they exist on your computer only—or they can be \textit{remote}—meaning that can live on other computers somewhere else. That ``somewhere else'' is usually a publicly available server. You can create your own\footnote{You can see mine at \kref{https://git.kjodle.net/}{https://git.kjodle.net/}, for example.} or you can get an account at someplace like Gitlab\footnote{\kref{https://gitlab.com/}{https://gitlab.com/}} which is for-profit and wants your money, or Github\footnote{\kref{https://github.com/}{https://github.com/}} which is now owned by Microsoft and wants your soul.
\paragraph{Concept Four: Repositories are multi-dimensional.} If you make a series of commits to a repository, it will be linear in nature. This is perfectly ordinary. But you may get to a point where you want to experiment with something and you're not sure whether you'll like the new version or the old version better. Rather than commit that new version, which overrides the original version, you can \textit{branch} and have both versions existing at the same time. A branch is basically a copy of a repository at this point in time (i.e., from the last commit). You can then switch between branches and test things out.
If you like the changes you have in the branch, you can then \textit{merge} them into your main branch. If you don't like them, you have a choice. If, on the one hand, you want to keep them around (in case you change your mind later, or as an example of what \textit{not} to do) you can just return to your main branch and continue working there. That experimental branch will still be hanging out there, existing in our space, but in a parallel dimension. If, on the other hand, you want to forget that you ever did that, you can return to your main branch and then delete it entirely. It will be like it never existed.\footnote{If only we could get a version of Git that would manage our actual lives, this would be great. Until then, we will go on making bad decisions and living with the consequences.}
I really dislike writing about how to install things, because 1) space in this zine is limited, 2) methods are subject to change over time, and 3) those instructions are usually available at the other end of a web search. But I love Git and want to encourage as many people as might be helped by it to use it, so recommend starting with \kref{https://git-scm.com/book/en/v2/Getting-Started-Installing-Git}{https://git-scm.com/book/en/v\\2/Getting-Started-Installing-Git}.
Git is a command line based technology. Yes, there are GUIs out there for Git, and if you are on Windows or macOS, you may find them useful. You can see a fairly comprehensive list at \kref{https://git-scm.com/book/en/v2/Getting-Started-Installing-Git}{https://git-scm.com/book/en/v2/G\\etting-Started-Installing-Git}.
In general, I advise against using any type of GUI with Git. For one thing, Git is fairly easy to manage from the command line, so using a GUI just adds a level of abstraction that we don't really need. For another, the command line is forever, but GUIs come and go. If your GUI gets to a point where it's development is discontinued, or it decides to adopt a subscription model that you can't afford, you're screwed.
Let's start with local repositories. Assuming you have a folder full of files you want to track using Git, open a terminal window in that location (which is now called your ``working directory'') and type \texttt{git init}. Congratulations! You now have a local Git repo!
What has happened is that Git has created an invisible directory (\texttt{.git}) that it will use to store the metadata and database for your project. Do \textbf{not} delete this folder!
Technically, the \texttt{.git} directory is the actual repository. But most people think of the folder that contains your working files along with the \texttt{.git} directory as a repo. As far as I can tell, it doesn't really matter. Just be aware that a) this distinction exists, and b) some people on the internet can be incredibly pedantic about it (sometimes with reason, and often without).
We haven't made any commits yet, though. All we have are files in our working directory. To make a commit, we need to \textit{stage} our files by using the \texttt{git add} command. You can do this a couple of different ways: we can either list each file one by one (i.e., \texttt{git add file1.txt file2.txt}) or we can just add them all in a single go by using the \texttt{*} wildcard (\texttt{git add *} which will \textit{not} add invisible files, or \texttt{git add -A} which \textit{will} add invisible files).
Now that we've added our files, they are considered to be \texttt{staged}, which means that they are ready to commit. We can make a commit now, or we can modify or create new files, and then add them as well. The choice is yours—Git doesn't penalize you either way. Personally, I prefer to make many smaller commits to avoid losing data.
If we're happy with the files we've staged, we can now commit them by using \texttt{git commit -m "<commit message>"}. Note that we have to add a commit message. This can be anything you like, but it helps to make it something that will be useful down the road like ``updated chapter three''. You'll get some miscellaneous messages about what Git is doing and then it is done. You've created your first commit, and all of your staged files are now \texttt{committed}.\footnote{You can also make this process even more efficient by creating some bash alias for the various Git commands. See ``More Fun with bash'' in issue \#4.}
If you want to experiment, the best way to do that is to create a \textit{branch}. To do that, just use \texttt{git branch <name>}. To move to that branch, you check it out\footnote{For a visual depiction, see, \kref{https://www.youtube.com/watch?v=8qxDBiiVjlQ}{https://www.youtube.com/watch?v=8qxDBiiVjlQ}.} using \texttt{git branch checkout <branchname>}.
This is the point where we experiment and have fun on this branch without worrying about our main branch. Wouldn't it be nice if life were like this?\footnote{Gosh, I've mentioned this twice. There are lots of science fiction stories about this possibility. I guess it's time to go read one. Or write one.}
If we like the changes that we made on this branch, we can then go back to our main branch (\texttt{git checkout main}) and \textit{merge} those changes.
\input{include/merge}
It's always a good idea to clean up after ourselves. If we don't need that experimental branch any more, we can delete it with \texttt{git branch -d <branchname>}.
In reality, things are rarely going to be this simple, unless you are only making very basic changes to a branch. You'll likely get all sorts of error messages or warning messages, and will get confused or even scared. Never fear! The nice thing about Git is that most of the solutions you need are easily found at the other end of a web search.
Remote repositories make it possible to share your work and to collaborate with others. You can do all sorts of things locally, but at some point, you're probably going to want to put your work out there, or just to show off.
If you set up a remote repo on some place like GitHub, or you find a repo somewhere that you would like to work with on your own, you can \textit{clone} that remote repo like this:
\input{include/clone}
For example, if you wanted to get a copy of the Apollo 11 Guidance Computer source code because you happen to be planning a trip to the moon of your own,\footnote{I was delighted to find out that this was available on GitHub. I first learned about this in the Volume Thirty-Eight, Number Four issue of \textit{2600} in an article called ``Supply and Demand, Apollo 11, and GitHub'', which is something I will probably talk about in the future.} you would just type \texttt{git clone https://github.com/chrisl\\garry/Apollo-11}. Git would create a directory called ``Apollo-11'' and clone a local version of that entire repository into it.
If you want to see the remotes attached to this repo, you can just type \texttt{git remote -v}. In this case, it would show you something like this:
Of course, those remote repositories don't belong to you, so you can't push any changes you make to them. What you can do is create your own remote repo on a Git-hosting system. I'll do that on my Git site at \kref{https://git.kjodle.net/kjodle/Apollo-11}{https://git.kjodle.net/kjodle/Apollo-11}. To add that remote to my local repo, I will use this:
\input{include/remoteadd}
And running the \texttt{git remote -v} command again shows that I have two different remotes:
I named my remote origin ``ogit'', which is the first letter of my last name combined with ``git''. Let's get rid of those remotes on GitHub, since I can't push any changes to them anyway. To do that we'll use this command:
Are we ready to upload this code from my local repository to my remote repo? Not yet. Let's see what our local branches are by running \texttt{git branch}, which gives us this:
\begin{Verbatim}[]
* master
\end{Verbatim}
In this case, I only have a single branch, which is named ``master''. It also has an asterisk because it's the current branch. The problem here is that my Git website always names branches ``main''. So we need to change that branch name by running
\input{include/branchrename}
Running \texttt{git branch} again confirms that our branch has been renamed:
\begin{Verbatim}[]
* main
\end{Verbatim}
\subsection{Pushing Changes to a Remote Repository}
Okay, we have a local repository, we have a remote repository attached to that local repository, and our current branch on both repos have the same name. It's time to move our code from our local repository to our remote one. For that we use \texttt{git push} <name of remote repo> <name of remote branch>. Since our remote is named ``ogit'' and our branch is named ``main'', the full command looks like this:
That really did take only about 1 second to push 3.1 MiB\footnote{That's not a typo. MiB stands for a \texttt{mebibyte}. See ``The Later Salad Days'' in issue \#2 for more information.} of data. One of the nice things about Git is that it is remarkably fast.
If you visit that original repository that I cloned on GitHub, you'll see that it has 547 commits. If you then visit the repository I created at \kref{https://git.kjodle.net/kjodle/Apollo-11}{https://git.kjodle.net/kjodle/Apollo-11}, you'll see that it also has 547 commits. This is one of the nice things about Git: when you clone that remote repository, you are getting \textit{everything} associated with that repo. Other version control applications just checkout the most recent version. Hence the term ``clone'' rather than ``checkout''.
For what it's worth, you can have multiple remotes. I can create a remote repository on GitHub, clone it to my local machine, then create a remote somewhere else and add that remote to my local repo. To keep both remotes up to date with local changes, you'll need to push twice, once with \texttt{git push remote1 main} and again with \texttt{git push remote2 main}.
I mentioned earlier that you could use Git if you're a writer to keep track of changes to projects, provided you were willing to work with text files. My goal here is to provide at least one workflow for doing that. I'm going to assume a few things:
\item Your repository host allows you to edit files on their website. (I can do this on my own site with Gitea\footnote{\kref{https://gitea.com/}{https://gitea.com/}} but I'm not sure about other sites.
The advantage to the workflow I'm describing here is that you can do work on your files even if you are not working from your normal machine. Thanks to family medical issues, I sometimes spend a lot of time in hospital waiting rooms and I bring my Chromebook with me. I can edit my files on the web, and then pull down changes to my main laptop (which never leaves my house) when I get home. This is how I do it.
Physically go to your remote location (library, caf\'e, hospital waiting room, etc.) and login to your repository host. Make whatever changes you want online and save your files.
Go home and go into your local repo. Open a terminal in that directory and use the \texttt{git pull} command:
What does \texttt{git pull} do? It's a combination of two Git commands: \texttt{fetch} and \texttt{merge}. \texttt{git fetch} gets the change history of the tracked remote and branch, whereas \texttt{git merge} combines the current branch with the specified branch. Your local repository will now look like your remote repository. You can write to your heart's content, push those changes, and call it a day. If you're back at the hospital waiting room again some time later, you can just repeat the process.\footnote{Again, for a visual depiction of this, please visit \kref{https://www.youtube.com/watch?v=FG1NrQYXjLU}{https://www.youtube.com/watch?v=\\FG1NrQYXjLU}.}
These things aren't a part of Git, but they are something that is offered by GitHub and other repository hosts, so I just want to give the briefest of descriptions here for clarity and completion.
To \textit{fork} a remote repository is to make a copy of it so that you can contribute to this project. You fork somebody else's project, clone it locally, make your changes, push those changes to your remote repo, and then make a \textit{pull request}, which alerts the owner of the original repository that you have changes you'd like them to incorporate into their project. They can then pull those changes in, or they can ignore them.
One of my favorite aspects of Git is that it's fairly intuitive to understand and start using right out of the box, but it's also robust enough to meet the needs of large teams and organizations. What I've done in the following table is to summarize the commands I've used in this primer, along with examples where appropriate. I've also included a few commands in this table that you probably won't use unless you are collaborating with others which I haven't discussed thoroughly because it's outside the range of my experience. I included them to make the table a little more complete.
Ever since I first learned about outlining in high school (or was it earlier?) I've always loved being able to organize information hierarchically. The irony is that I also love biology and the natural world does not necessarily organize itself in a hierarchical way. Cross-pollination and inter-species breeding is a thing.\footnote{Don't get me started here. I could write an entire zine about this.}
You can use the built-in \texttt{enumerate} environment to create outlines, but it requires lots and lots of nested \texttt{enumerate} environments. (\texttt{html} is the same way—an occupational hazard, I suppose, of liking both outlines and computers.) I grew up using a typewriter, so I've always been looking for something simpler.
The indents in your source code are absolutely not necessary, but you can indent with tabs or spaces to help you keep visual track of things. The actual levels are controlled by the number after the backslash.
You are limited to four levels of indentation. (This is a part of \LaTeX{}.\footnote{It is possible to build list environments with more than four levels, but I don't think they would automatically work with the \texttt{outlines} package. However, its code is fairly straightforward and simple, so if I get time, I may play around with making my own package.}) You can always introduce a normal, non-itemized paragraph into your list by using \verb|\0| as a list item, which prevents you from having to end a previous environment and then create a new one.
I also passed the \texttt{[enumerate]} option to the environment, so that instead of symbols, it uses numbers and letters to label the list items, rather than symbols. I like this. It's similar to the outline style I learned in high school.
Unfortunately, this isn't exactly the style of outlining I learned in high school.\footnote{Apparently I learned what the Purdue OWL calls a ``decimal outline''. See \kref{https://owl.purdue.edu/owl/general_writing/the_writing_process/developing_an_outline/types_of_outlines.html}{https://owl.purdue.edu/owl/general\_writing/the\_writing\_process/developing\_an\\\_outline/types\_of\_outlines.html}.} However, it is possible to use \texttt{renewcommand} to change the counter style when using the \texttt{[enumerate]} option to get what we want. What we need to know is that the \texttt{enumerate} list style uses two sets of placeholders to keep track of things. \texttt{labelenumi} etc. determines what kind of label you see, and \texttt{enumi} etc. keeps track of the counter. So we can do something like this:
Keep in mind that because we are using the standard \texttt{enumerate} commands, this will affect \textit{all} numbered lists that follow it. We would have to reset these if we need to prevent that from happening. For that, we can use this code:
\begin{Verbatim}[frame=lines, numbers=left, xleftmargin=5mm, framesep=3mm, breaklines=true, label=\fbox{Commands to Reset enumerate Environment}]
\renewcommand{\labelenumi}{\arabic{enumi}.}
\renewcommand{\labelenumii}{(\alph{enumii})}
\renewcommand{\labelenumiii}{\roman{enumiii}.}
\renewcommand{\labelenumiv}{\Alph{enumiv}.}
\end{Verbatim}
If you need to pop in and out of your outlines and also numbered lists quite a bit, you could just turn both sets of those \texttt{renewcommand} lines into macros to make your mischief a bit easier to manage.
\section{Customizing \texttt{enumerate} and \texttt{itemize} List Environments}
Given all that, it's pretty easy to see how to customize list environments. You just need to know the commands that those environments use to keep track of things. Here's a list of the commands used to generate the labels for both environments:
\subsection{the \texttt{ccicons} package}I release this zine under a Creative Commons license (which you can read about on page 2). I used to include a small image that summarizes that license, which I had downloaded from the Creative Commons website. As it turns out, the \texttt{ccicons} package will do this for you—no need to add that image.
(I actually learned about this while working on issue \#4, but it was very close to the end and I came across it accidentally—it wasn't something I was looking for. Serendipity is somethings a thing, so here we are.)
You can add icons individually, but it also has commands to typeset each license and its icons. Because it's basically just a font, you can do with it whatever you would normally do with other text. For example, these lines
You'll notice that chapter \ref{dephell} has a lot of code samples that include code that you enter into the terminal. As such, they include a dollar sign (\$) to indicate the prompt.
While it's easy enough to include those in a \texttt{verbatim} environment, I'm using a GUI to create this (Texmaker,\footnote{See \kref{https://www.xm1math.net/texmaker/}{https://www.xm1math.net/texmaker/} for more information.} in fact) and anything in math mode—that is, anything that follows a dollar sign—is highlighted in green until it gets to another dollar sign. If it doesn't, then everything after that dollar sign is green, which kind of defeats the purpose of code highlighting.
The easy way around this is to write up those code samples in an independent \texttt{.tex} file, and then use the \texttt{input} command to add them at the appropriate point in my story. That keeps the source code in my GUI nice and clean looking, and means that the text highlighting actually means something.
The \texttt{include} command works in a similar way, but adds a pagebreak before and after the included text. This is pretty handy if you are working on a longer document.\footnote{For more about the distinction between the two, see \kref{https://tex.stackexchange.com/questions/246/when-should-i-use-input-vs-include}{https://tex.stackexchange.co\\m/questions/246/when-should-i-use-input-vs-include}.}
I have a table of basic Git commands on page \pageref{tb:gitcommsum}. One of the commands is \texttt{git -{}-version}. Notice that ``version'' has two hypens in front of it, as is typical with full-word bash options. But just typing two hypens didn't display two hypens, it displayed a single hyphen. I was momentarily confused.
What I forgot is that \LaTeX{} has a habit of collapsing multiple hyphens into ligatures. Two hyphens get converted to an en-dash, and three hypens get converted to an em-dash. But because this was displaying in a monotype font, it looked like an ordinary hyphen, even though it was an en-dash.
The fix for this was to use the \texttt{\{\}} token between the two hyphens. Without it, \LaTeX{} sees the two hyphens as a single entity, whereas with it, it sees them as two separate entities. Using this in my file
\begin{Verbatim}[]
git -\{\}-version
\end{Verbatim}
\noindent{}gives me what I needed: \texttt{git -{}-version}.
Read that \textit{again—there is a Hannah Montana version of Linux}.\footnote{Get it while it's hot at \kref{https://hannahmontana.sourceforge.net/}{https://hannahmontana.sourceforge.net/}.}
The developer (who has chosen to remain anonymous—I understand this desire) said that they decided to create this in order to attract young users to Linux. As the FAQ\footnote{\kref{https://hannahmontana.sourceforge.net/faq.html}{https://hannahmontana.sourceforge.net/faq.html}} says, ``I created this idea after a lot of reading and work''.
The problem with this sort of approach is that television shows geared toward tweens and teens come and go like busboys in a restaurant. Here today, gone five minutes later. I have no doubt that a lot of middle school students in 2024 have no idea who Hannah Montana is. (As it \textit{should} be.)
Still, I applaud the work that went into this. If nothing else, it shows that you can pretty much do anything with Linux if you have the time and the energy and also the curiosity.
When speaking about public Git repos earlier, I mentioned the only two that I knew of: GitHub and Gitlab. But I just recently found about about Codeberg\footnote{\kref{https://codeberg.org/}{https://codeberg.org/}}, which run by a non-profit in Germany. I'm going to sign up for an account and test it out. I'll get back to you on how it works out.
\noindent{}This one got done a lot faster than \#4. I got stuck with the previous issue because I got distracted by some other things going on in my life (like my job). As a result, this zine went from feeling like a ``get to do'' kind of thing to a ``have to do'' kind of thing. Like just about everybody else, I have far too many ``have to do'' things in my life already.
What got me unstuck\footnote{I don't believe in writer's block. As Stephen King said, there's no such thing. After all, snow plow drivers don't get snow plow driver's block. That said, it is possible to adopt some unhealthy thinking patterns that make you get \textit{stuck}.}—that is, what turned this from a ``have to do'' back to a ``get to do''—was to focus on the process, and not the product. I let myself have fun with it, in other words. That's something I need to periodically remind myself of, even when the thing in front of me is an actual ``have to do'' like my job. Despite the fact that my job is boring me to death, there are still aspects to it that are quite enjoyable. I try to enjoy them as much as possible, and not let them be overshadowed by the parts I don't really like.
In old news, I do occasionally make other zines besides this one, and I have a website for all of them at \kref{https://just13.click/}{https://just13.\\click/}.
I used to have a mailing list, but Mailchimp blew it up. If you want an email notification of when I produce a new zine, feel free to send me an email at \texttt{wolfgangswishlist@gmail.com} and let me know which zines you want to hear about.
I also have some ideas for other zines that might cover some of the topics I talk about in here in greater depth. I'm not sure how that's going to evolve just yet, so stay tuned.
On page 2 is a link to a list of topics I intend to cover in future issues. If you have ideas for things you'd like me to talk about, send me an email at the above address.
I also have a forum for this zine\footnote{\kref{https://forums.kjodle.net/forumdisplay.php?fid=15}{https://forums.kjodle.net/forumdisplay.php?fid=15}} where I'll be posting updates as I go so that you can see how close we are to a new issue. Feel free to join that forum if you like. I'd love to hear from you.
Also, I joined Mastodon a while ago, but am just now getting serious about it. You can find me at \kref{https://mastodon.social/@kjodle}{https://mastodon.social/@kjodle} where I will post updates, probably using the hashtag \texttt{\#thecodex}.
I've also included some Easter eggs in this issue. If you find them, I'd love to hear about it. As a former teacher, I'd be thrilled to know that you are reading to the bottom of the page.
