Ken's Guide: Indie Publishing on Linux (2. Three Key Preferences)

how to self-publish on linux, part 2 preferences

There are three key preferences I express in this and my other guides, and it is worth explaining them. They all inform my choices and approaches, though some play a larger role than others.

Why Linux?

Linux is a very stable operating system, it is powerful, and it gets out of your way. My goal isn't to start an OS flame-war. I've used all 3 at various points, and will be the first to admit that Linux has its drawbacks. But in my experience both Windows and OSX are clunky, unstable, and designed around certain tradeoffs which work to my disadvantage. These tradeoffs favor certain uses and workflows at the expense of others, and unfortunately writing is one of those others. Both OS'es seem to be moving toward a heavy emphasis on mobile device use, content consumption, and web-design applications.

However, I speak of the general approach taken by the OS'es. Any of the three can be made to do anything --- it's just a question of ease. If you're wed to Windows or OSX, then that's not a problem. The remainder of my guide will still be useful, but you may find some adaptation necessary. In addition to full Windows/OSX ports of some packages I mention, both Windows and OSX have some Unix support built in. OSX actually is layered on a flavor of Unix and offers a proper command-line. Homebrew or its ilk may be used to install packages, and much of what I describe directly carries over. Limited Unix tools are available on older versions of Windows via cygwin. I'm told that the newest version of Windows offers a full Unix carriage.

If you want to use (or try) Linux but simply don't wish to purchase a new computer, that's no problem either. Linux easily may be installed in a VM using free software like Virtualbox (available on both Windows and OSX). Modern hardware has direct virtualization support and the installed instance will run at near-native speed.

Why a text-based environment (i.e. the command-line)?

I use an almost exclusively command-line environment. There are several text-based windows managers on Linux, all quite good. If you're curious, I happen to use i3. There are important reasons why I feel a command-line environment is preferable to a graphic window-manager. But first, I should clarify something. A text-based window-manager does not preclude the use of graphical programs. It just allows me to avoid the use of a mouse under other circumstances. I still can pull up Gimp, Inkscape, or any other fully-graphical program and mouse my way around it like anyone else. But when I'm not using a graphics program, I'm not forced to use a mouse to switch windows, move around, and so on. And yes, I have an aversion to mice. Not the cute furry kind that stop being cute and furry when they decide to pass away in the attic and stink up the whole house for a week. I think mice are one of the worst things to happen to computers. They started as a great tool. But like anything new and flashy, they quickly evolved from "had-to-have" to HAD to have. But this was part of a broader trend.

My experience has been that as computers grew more powerful and snazzier, basic software grew less functional. In the late 80s to mid 90s, I used a variety of excellent programs. Wordperfect was a solid word processor, Irfanview was a great photo-library manager, and treepad was an excellent PIM --- to name a few Windows examples. This isn't simple nostalgia. I've used countless products since, some quite good in other ways. However, the basic usability has declined. Programs have gotten bigger, offering lots of features that I don't use, yet have regressed when it comes to the basics. I won't go into the causes of this --- there are several, some organic, others related to market dynamics and programming fads. But the gist is that power has gone up and core functionality has declined. Or, more precisely, core functionality of popular commercial software has done so.

As mentioned, one of my biggest problems is the mouse. The trouble with a mouse is that it forces an interruption of mental focus --- at least when it comes to tasks like writing. When invented, the mouse was a godsend (though I personally prefer trackballs, certain trackpads, and mini-joysticks). I'm not a luddite in this regard. I even have a Space-nav 6-axis mouse. It's amazing and nifty and perfect for one or two applications I almost never use. But if I were a CAD designer or graphic artist it probably would be indispensable. The same is true of the mouse. There are applications in design and elsewhere for which a mouse is a major blessing. But I find that it generally slows down my workflow more than anything else. Nowhere is this more evident than in word-processing.

Early on, the mouse allowed the coupling of word-processing and desktop-publication software. This was amazingly cool and very counterproductive. There's a reason that content and form are kept separate in most writing workflows. Imagine a writer in the old days who insisted on manually typesetting his work every so often — just to see how it would come out. He’d probably produce a single book in his lifetime. And it would be on the benefits of typesetting while writing. There are indeed benefits to having some sense of what a piece will look like, particularly with visual forms such as verse. And it certainly can be fun and motivating for an amateur writer to do so. However, in my experience serious thought and writing is undermined by the visual distraction associated with the constant reflowing of text or other visual aids in modern word processors. But it is difficult to avoid this in modern graphical environments. The problem is that content and form have become inseparable --- literally --- in most applications. And the emphasis on web-publication has made this much much worse.

The end result is that a mouse now is required even for the simplest tasks, and we're constantly distracted from our purpose. Windowing OS'es also tend to require a lot of mouse-related intervention of their own: dialogs, popups, and so on. Each requires a change of mental focus.

It is my experience --- and this is highly subjective --- that this is not the case when performing comparable tasks in something like Emacs. I personally find that between Emacs and various unix utilities I can accomplish most tasks far faster via keyboard than I ever could with comparable mouse-based applications. Nor do I mean to proselytize about Emacs. Vim or any other text-based tool offers the same benefit.

One other issue with a mouse vs keyboard is precision. For layout purposes, placement with a mouse is inexact (even with snap-to grids), and unstable. In my opinion, it is much better to have a written specification in terms of numbers --- which then can be adjusted to achieve the desired goal. But that has more to do with the software’s internal model, its exposure to the user, and our ability to modify things programmatically.

Why text files?

Another major choice involves text-vs-proprietary formats for storage. There is nothing magical about a text file --- its just a collection of bits like any other file. Text files do have a few advantages, however. They generally are easily-readable by humans and there are many free and well-established utilities to manipulate them. With text files, one is less tied to a specific application. Conversion is easy, either directly or using a script. Basically, text has been around a long time, will be here for a long time, and is well-supported.

Of course, I'm being a little glib here. There are many text-based formats, some as abstruse as any binary format. Moreover, I’ve conflated two separate dichotomies: text vs binary and open vs proprietary are two separate issues. But for our purposes, I can lump them together here. It is important to keep the distinction in mind, however. For example, XML, JSON, and other formats are manageable and open (unless there is a closed schema) but lose many of the benefits of plain text. Note that I'm being purposely vague about what I mean by "text" here.

The basic idea I'm trying to convey is that if our book-related information is stored in some sort of human-readable text format, there are lots of advantages. Some apply to all text-files vs binary, some to human-readable vs non-human-readable, and some to open vs proprietary. But human-readable-text offers the greatest benefits.

Consider Latex as an example. LaTeX (or it's parent TeX) is a text-based formatting language predominantly use for scientific and technical documents. However, it also happens to be fantastic for non-scientific typesetting. Unlike XML, it is human-readable. It is incredibly flexible and can produce books on par with any professional product. A LaTeX file will have some detailed layout information up front, but for non-scientific writing the body of the document typically has little markup.

An even simpler --- if less powerful --- alternative is markdown, and in fact I use this for my novels. It is far less flexible than LaTeX but also can be a bit cleaner to look at. Fortunately, there are tools (such as pandoc) which allow easy conversion --- so one can have most of the power of Latex along with the simplicity of markdown. I'll delve into this in another guide. For now, suffice to say that LaTeX and markdown both are human-readable and text-based. I can compile LaTeX into a print-ready pdf file which will display and print the same on any system.

Let us list the major advantages of human-readable open-format text files over proprietary binary ones. Many of these apply to human-readable text over HTML, XML, JSON, etc, as well.

1. Human readability. You can see what is being done and how. With something like Word, a minor change can cause all sorts of reformatting, and changes may not even be apparent. "Stuff happens," and you have to hope you can see it. An undo stack helps a little, but this is application-dependent and usually cannot be inspected or edited in a meaningful way. With a text file, you can make changes manually and force things to be just the way you want. You don't need to navigate all sorts of hierarchical menus to find something you hope changes the right setting or value.

2. Size and compressibility. Not as much an issue with the cheap availability of disk space these days, but still an indication of maintainability and complexity. Text files tend to be small and highly compressible.

3. Version control. Several very powerful and well-established VC systems exist. These primarily are designed to deal with text-files. Most can manage binary files too, but less efficiently. There is a clear semantic notion of diff (unix for difference) between text files. With proprietary binary formats, one must rely on the application to supply semantics to the VC system if there is to be any hope of meaningfully diff'ing versions. Since this almost never happens, one is forced to use each application’s own home-grown, opaque VC system. The same problem exists for non-proprietary binary files in general VC systems, of course, but users (in theory, at least) can create tools to do so. Proprietary formats admit no such accommodation.

4. Durability. Proprietary formats require continuing access to the program which created them. And not just the application in general, but often the specific version and accompanying OS version on which they existed. Modern subscription models make the situation worse. Users must pay for ongoing access to their own files! Exporting to some other format (if possible), often requires possession of a working copy of the original program. You may not even be able to tell what the file *is* until you open it in that program. With text-based files (or any standard format), you always can extract the info via a script. And you most certainly can tell what the file is about.

5. Interoperability. Text files are universal (aside from a few easily-dealt-with quirks like the use of carriage-returns). Binary files may not work on other OS's. Issues like word-boundaries, endianness, and meta-data can make a file incompatible (and perhaps even inaccessible) on another system. While the program may not exist to use the text file on another OS, you at least can inspect it, convert it, and extract some info. There is little danger that plain text will cease to be supported in the foreseeable future.

6. Editability. Text files easily can be edited. Binary ones can too, but the process is a lot more painful and less intuitive, and typically requires access to information that is not readily available. Although human-readability doesn't mean you meaningfully can edit a file without understanding the details of its use by the program, it *is* much easier to make changes when you do --- or to deduce which changes need to be made.

7. Search. Text files easily can be searched for human-readable phrases. If nothing else, this allows the detection of *which* files possess certain text, even if one doesn't know all the details of the file's format.

In summary, I recommend a text-based environment for human efficiency as a writer, and text-based formats for the powerful version-control and tools they admit. I recommend Linux because it allows all of this for free in a very stable package.

If you strongly disagree with any of these approaches, that doesn't mean this guide will be of no use to you. I recommend you read it anyway and try to adapt the relevant sections as best suits you. If nothing else, you may save some money by avoiding commercial software.

Next week, we’ll dive into the details of book production and get started with our cover!