What follows is a listing of tools I use -- to enhance my productivity, to satisfy my conscience, and to enhance my quality of life. It is unlikely to ever be a complete list, but it will do for now.
This is meatspace gear I have and use for various purposes that I find important and interesting enough to give it special mention, or otherwise just feel like sharing.
I decided I wanted to learn to do some sewing, to repair worn clothing (patches, restitching seams, et cetera) and maybe even make something useful from time to time, so I checked around at a few local sewing or vac-and-sew shops. At one in particular, J&M Vac & Sew, I ended up with the owner showing me around. He had the passion of an enthusiast, and I later found that he had been working with vacuum cleaners and sewing machines for decades. He caught on very quickly to my needs, and directed me toward a 1950s steel tank of a machine that will probably survive the death of the human race, and even the rats and roaches. He demonstrated sewing through more than half a dozen layers of denim without a problem, then putting stitches in a piece of kleenex without changing out the need or thread, and without any tears or puckers in the tissue. I was already sold on the thing before he was halfway through the spiel, at a very affordable price (a fraction of the price of new, cheap, plastic pieces of junk of comparable size). He then went on to throw in a cabinet for the machine at no cost (for those not familiar with sewing machine terminology, "cabinet" basically refers in this case to a sewing table to which the machine can be attached, where the machine can actually flip down inside the table and leave a smooth top table surface) with some damage to the finish, but no functional problems whatsoever.
He made a very satisfied customer out of me. The machine has been great. It may weigh something like forty pounds, but the solid strength and durability of the thing is worth a lot more to me than the light weight of a flimsy plastic machine, and I can sleep better knowing that if I'm attacked by a rhinoceros I have a suitable blunt instrument for use defending myself. I was so happy with the machine, and with the classes I took at the store, that I ended up applying for a job there, to learn to be a vacuum cleaner technician, and got hired. While I did not work there long (a combination of being an introvert in a job more extroverted than I expected and some terrible dust issues I had not anticipated), I remain on excellent terms with the owner and staff, and am grateful the owner directed me to a machine that so perfectly matches my needs.
My first electric bass guitar was a junker with a warped neck from a pawn shop; I do not even recall what brand, and do not recall its looks well enough to hazard a guess. I had no idea what I was doing, and I did not do it long. Fast-forward a couple years: I had moved across the countinent, and I found myself hankering to pick up a bass again, so I shopped around, mostly at places like Guitar Center. I put some money down to reserve a bass, then found myself moving more than a thousand miles away again, to a place where there were no local stores of the chain where I had reserved the bass (no, not Guitar Center -- those things are everywhere, the McDonald's of guitar shops), so I called up corporate and got the refundable portion of my money back. A couple more years later, I found myself spending a lot of time in guitar shops in the area (one of them a Guitar Center).
I eventually ended up buying a bass in a locally owned and operated place called Spotlight Music. What I got this time was a four string Ibanez Soundgear with two big active humbucker pickups, a beautiful dark finish with a kinda pearlescent silvery edging, and furniture that has a sort of hematite look to it. The styling is beautiful (and a trifle wicked looking), it has a reasonably fast neck on it, the heft is solid but not unwieldy, and the ergonmics are pleasant. It sounds great and feels great, making it easy to understand why Soundgear seems to have a good reputation with session musicians.
I went back to Spotlight for lessons from one of the freelancer instructors who use their rooms, and ended up with Tony Deyo giving me some much-needed basics. Either I learned very quickly or he says that to all his students, but in either case I found the experience helpful and the price reasonable, and I really like my bass.
These are software tools that I use on a regular basis, in alphabetical order.
Migration paths are listed for some applications, showing how I have moved from one application to another over time. In each case, some minor selections have been left out for the sake of simplicity. For instance, I left out Red Hat, SuSE, MacOS, WinNT 4.0, MEPIS, Slackware, and a bunch of other stuff in the operating system migration path, because none of them really served as big a role as the options I did list.
I have very little use for BitTorrent in my life, but I do occasionally use it to get the latest ISO of some Unix-like operating system or other. I looked around for something fairly minimalistic, and I found the command line version of Transmission (called transmission-cli in various software managers). Maybe my memory is playing tricks with me, but as I recall things Transmission went from being basically cleanly copyfree licensed (using the MIT/X11 License, apart from dependencies, at least where the GUI front end is concerned) to anything more than transmission-cli being GPLv2, to everything being GPLv3. In the middle stage of that, I looked around for a decent replacement and found a console based BitTorrent client called unworkable, but it was half-finished and not really usable at the time. I think it has become more complete since then, but I have not really looked into it very thoroughly.
At the end of that license change path, I started looking around again and found btpd. After giving it a try, I am impressed. It is a nice, clean tool, with a handy client/server operation model that allows me to use a command line interface called btcli. It is also copyfree, distributed under the terms of the Simplified BSD License. Even more impressive, using it is simple, straightfoward, and well documented with both manpages and
--help options, making it very easy to pick up and use for the first time -- or, as is kind of important for my rare use of the thing, after a long period of not using it. By way of that simple, easy, straightforward interface, it also provides the user with some great functionality, like stopping and resuming downloads, connection limiting, unambiguous status listings, and other shiny stuff, all without making the thing feel like some kind of bloated monstrosity.
I used to use a little command line tool called Tofu as my todo manager, but I since stumbled across something called Calcurse while looking for a palatable way to deal with an iCal file sent to me by an employer/client. Calcurse is a console-based calendar/organizer application with a curses interface that also happens to come with an excellent little todo list manager that encourages keeping the list relatively small. I typically prefer command line over curses, and Calcurse even offers some of its functionality through command line options, but I tend to just open Calcurse in a terminal and leave it open pretty much all the time. It's that handy. It's also distributed under the terms of the Simplified BSD License, so that makes me happy too.
Backups are easily scripted using tools that do checksum-based incremental backups over SSH (with compression) from a shell command, and cpdup fulfills that need in spades. I prefer it over the significantly more ponderous major competitor for that kind of backup capabilities, rsync.
I went from taskbar menus to desktop-click menus, then to no menus (just using keybindings configured in my window manager), to a combination of keybindings for all the commonly used stuff plus dmenu, and ultimately to just dmenu for just about everything. It turns out dmenu is awesome that way. It's a truly effective and elegant meshing of the benefits of a GUI and the power of the command line for providing simple access to applications on the system.
When I first started using smaller, simpler tools for managing email, the only real option along those lines for fetching email from a remote server that I found was fetchmail. Unfortunately, fetchmail is kind of a pain in the butt to configure. It is, in fact, bad enough that using the GUI configuration tool is almost mandatory, and even that almost always screws things up. On top of that, the restrictive licensing was kind of a downer. I eventually discovered getmail, which was a touch more stable, and a smidgen easier to configure, but not any better on the licensing. After a few years of fetchmail, and a few more of getmail, I decided to write my own replacement, which I intended to call pullem, but I never really got very far on it, mostly because I kept getting distracted by other projects that were more fun. Just as I was about to dive back into it and get pullem written once and for all (probably a couple weekends to get it to the point where it would be worth sharing with the world), I stumbled across a handy little tool called fdm, with a much simpler and clearer configuration style than even getmail (let alone the snarl of configuration issues of fetchmail). It is fast, lightweight, flexible, and blessed with extensibility rather than being loaded down with half-broken features I'll probably never use. It even comes with built-in capacity for filtering rules in a simple, pattern based style -- always more my preferred approach for things like spam filtering than the typical Bayesian approach, which has some potential for false positives.
I pretty much started with Subversion (back when it was still copyfree licensed) for version control. When DVCSes started taking over, I ended up using Mercurial and Subversion both, for different purposes. Subversion eventually got phased out entirely, probably not long after the Apache Foundation took over the project and changed the licensing, but a bigger influence on the change was my discovery of Fossil SCM.
Fossil does things a little differently than the competition, and I find that I like it more. Among other things I quite like about it is the fact that issue tracking goes with the version control repository, which is pretty handy, but there are other things I like. In addition to that, it's really the only viable choice for copyfree licensed version control at this point, as far as I've seen. Code hosting for it lurks somewhere between nonexistent and woefully inadequate, unfortunately, so I still use Mercurial for a number of projects, but I hope to solve that problem "soon" (not too many years in the future) so I can just move everything to Fossil.
In addition to the official Fossil Quickstart Guide, there's also a very simple intro I wrote called Fossil For New Users, which helps get some of the basic getting-started stuff out of the way without having to trial-and-error your way to figuring out how its use patterns differ from Git's or Mercurial's.
I made the switch from Debian GNU/Linux a few years ago for a number of reasons, including the decay of the Debian distribution. I was immediately impressed with the technical benefits FreeBSD offered that I'd been missing all those preceding years, without realizing it -- such as increased software auditing capabilities and reliability, better software choices in FreeBSD Ports than in the official APT archives (at least for my tastes), easier system configuration, and better documentation outside of manpage coverage (which is still one of Debian's primary strengths). The feeling of enlightenment wasn't nearly as big as the switch from MS Windows to Linux distributions, but it was still significant. Add to that the fact that it's more thoroughly copyfree licensed (with a BSD licensed kernel and default shell, among other things), and I'm quite happy.
I'm not the world's biggest fan of its copyleft licensing, but its core functionality is indispensable, at least until netpgp achieves something close enough to feature parity with GnuPG to make it a suitable replacement. It does actually have technical shortcomings (such as its inability to natively check multiple keyservers for keys), but some of them can be worked around and there simply aren't any alternatives for others that suit my needs.
The GraphicsMagick tool, especially using the
gm display command, provides enough image editing functionality to suit my most common needs. In addition to being much lighter weight and more stable software than The GIMP, it also benefits from friendlier licensing and far fewer dependencies.
Rather than use some GUIfied thing with clicky buttons, I just wanted a music player application that did its thing with minimal use of system resources, minimal hard drive space consumed during install, and a keyboard-driven interface. The word "herrie" is Dutch for "noise", and it's quite effective at delivering the noises I want, in FLAC, MP3, and Ogg Vorbis formats. Its keyboard controlled interface is very reminiscent of Vim's and Mutt's. It can automatically communicate with Audioscrobbler, for crying out loud. It's even copyfree licensed, under the terms of the BSD license. In general, it's simple, effective, and efficient. The only downside seems to be its lack of true command line interface -- it requires an active (curses based) captive interface to do its thing.
I have finally come to see the light, with regard to tiling window managers. Since early 2011, I have been using a tiling window manager called i3 pretty much full-time, and it is distributed under the terms of a BSD license. I have also used dwm and a couple other tiling WMs, giving them each a real chance. I think that dwm would be my second choice out of everything I've tried, if i3 was for some reason not an option any longer, with the floating model AHWM (my previous favorite) tagging along in third place.
At first, i3 was nothing but good, as far as I was concerned. Eventually, however, an update to i3 came with an incompatible set of default keybindings that made things less smooth for me. It turns out the defaults were changed not directly, but by way of a change in the assumptions inherent in the way the window manager's developers designed its operation. I have been told (by the project maintainer) they have plans to add in a way to optionally configure it to behave more as it once did, but such changes have not yet materialized as far as I'm aware. In essence, the changes make it more trouble than it is worth to organize windows in a tiling layout that I used to find extremely handy and productive for my typical workflow when coding.
Even with this deficiency, I find i3 easier to deal with than dwm or AHWM or anything else these days, so I'm sticking with it, and anticipating the promised enhancement that will allow me to recapture the previous bliss I found with i3. Dwm does offer some advantages, though, and I suppose they might win me over yet -- and, for that matter, I might get enough of a handle on xmonad to feel at least as comfortable with it as with i3. I hear nothing but good stuff about xmonad.
Since I made the switch to FreeBSD years ago, I basically just stuck with tcsh for my interactive command shell. I like the C shell style of syntax just slightly more than the Bourne shell style, and tcsh was a default part of the FreeBSD base system. The only real downside was the annoying contortions needed to redirect STDOUT and STDERR separately, but that was not something I needed to do with any frequency to speak of. My interactive command shell choice had no impact on scripting, because when writing shell scripts I choose sh, full stop. There are very good reasons no shell scripts should ever be anything but sh syntax; if you need more, use a real programming language (at least as "real" as Perl, Python, or Ruby).
I had a brief-ish foray into the Linux world again for a couple of years. I decided to try zsh there, because bash was already the default for the system, and if everything's going to be bloated and horrible anyway I thought I might as well try something that gives me some real features for the bloat, is better designed, and is not as user-hostile in its documentation (to say nothing of zsh using better licensing). To my surprise, it was also actually faster than bash, despite being able to do a lot more stuff -- though that "more stuff" turned out to be basically useless to me, because honestly I don't need weird symbols and dynamically calculated values in my shell prompts or other such frippery.
When I switched back to using FreeBSD full time, I decided to try something new. I installed mksh, and ended up making it my primary interactive command shell. I have found its vi-mode capabilities pretty comparable with zsh's and slightly better than tcsh's, it has basically all the features that I need for an interactive command shell, it's well-licensed, and it is not only smaller than zsh, but actually smaller than tcsh, which is pretty impressive. It also lacks the STDERR and STDOUT redirect problem of the C shells, and it keeps me in slightly better practice for the rare occasion when I need to write a shell script in sh (because mksh, being a Korn shell descendant, uses a Bourne style of shell syntax).
Much as I have been pursuing a path through relatively simple tools for retrieving email (see fdm above), from options that are mediocre at best to those that are progressively better, I have been doing the same for sending email. I had discovered sSMTP about the same time as fetchmail, then msmtp some time after getmail. Before discovering fdm, I had despaired for some time of finding a copyfree tool that was simple enough to avoid making things difficult for me and capable enough so that I would not feel constrained to use something suboptimal with bad licensing. As such, I had started thinking about writing my own tool to fill that niche, but stumbled upon fdm so that I did not need to reinvent the wheel. I hold out hope, now, that I will similarly discover a good copyfree replacement for msmtp, though for some time I have been fairly convinced that I would have to write it myself to get such a thing.
One point of departure from the same pattern with discovery of replacement tools for fetching email is where moving from fetchmail to getmail meant simplifying things and getting more capability out of it for my needs. Moving from sSMTP to msmtp gave me more capabilities for my needs, and solved the problem that sSMTP was such a dead project that it was getting difficult to even get source code for it, but was a definite trade-off as msmtp was a significantly more complex tool (though still simple enough to be quite usable). If I do have to write my own SMTP agent, I'll aspire to fdm's combination of simplicity, flexibility, and capability. I only hope I will succeed.
It's my current favorite mail user agent, and has been for some time. It's a huge productivity boost when dealing with email, as compared with previous tools I've used. There are some minor niggling annoyances in how it works, though. I haven't found anything better, yet, but I may eventually have to write something better. Yeah, right -- immediately after I write all the rest of the software I'd like to have but that doesn't exist. I'll get right on that. Of course, there's the added incentive of wanting something that isn't GPLed for my MUA. Dammit.
When I discovered Vim, it was a revelation. The productivity enhancing design philosophy of the vi-like editor really opened my eyes to ways I could improve my computing life. It ultimately led to the discovery, adoption, and enjoyment of many other non-GUI, no-frills, get-out-of-the-way, functionality-over-features tools. There were things I would have liked to improve about Vim, of course, including the licensing. I eventually grew to appreciate nvi as a simpler, smaller vi-like editor, complete with better licensing. For a long time I had difficulties with nvi, keeping myself trapped in Vim use, but when I finally tried the development version (v1.81.6, rather than the default v1.79 on various systems, notably including FreeBSD) I have found it to be quite sufficient for my needs thus far. There are things I wish nvi could do, that I had to give up when I stopped using Vim all the time, but there does not seem to be anything I can't live without that it lacks, and Vim comes with a lot of things I'd really rather live without, so the trade-off seems worthwhile when I take into account the matter of licensing. I may some day fork, or contribute to, the nvi project to ensure my editor of choice supports everything I want, but that day seems far in the future just now. I'll just have to add it to the queue, along with everything else I want to do "some day" -- probably within the first hundred years after I achieve immortality.
Its LGPL distribution terms are better than pure GPL, but still suboptimal. Regardless, it's such a stellar piece of software that fills such an important need in my life that there's no way I'm passing it up at this point. I've even let it lock me into Pidgin use, as much as I dislike the program, because Pidgin's OTR support is so good. Some day, after I create my own Web browser, Vim clone, Mutt clone, GNU toolset replacement, OpenPGP implementation, and probably a dozen other things, I may have to extend CenterIM to properly support the OTR library for encrypted IMs.
As noted on my projects page, I created a simple wrapper for the Markdown parser, Redcarpet. I use it pretty heavily, both in web dev (as a library) and on my laptop (as the
redrug command line utility) to handle Markdown formatted text. I used to use BlueCloth, but that has been subject to various forms of ugly over the years.
Simply put, it's a command line screenshot grabber utility. Combined with good keyboard shortcut configuration, such as that provided by AHWM, it becomes about the world's easiest screenshot grabber in the world. It's offered under a BSD license, so it's copyfree software, too.
The scrot page at its maintainer's site is dead now, but the utility itself is in software management archives for many open source Unix-like systems, so it's easy to install. I'm considering taking up maintainership of the codebase at some point in the future, though it is simple and stable enough that as long as it remains in various OS' software management archives I'm not sure it really needs any maintainership to speak of.
One day, I started thinking about the possibility of getting a stand-alone screen locking utility to "secure" my laptop when I, say, went to the bathroom. I find myself in situations where I use my laptop around other people quite a lot, so that kind of functionality can be kind of important. I didn't want a screen saver, mind you: just a way to lock the interface until a password is entered so you can't really access stuff on my laptop, without having to shut down X and log out. Being the sort that favors lightweight window managers, my WM of choice didn't have that functionality built in; that's why I wanted a small stand-alone utility. That's all slock does, and it's perfect for my needs. Just type slock into a shell, and the screen goes black. Keystrokes are intercepted by the screen lock, mouse clicks don't get through, and your GUI environment is effectively hidden from prying eyes. You can still switch to other TTYs, though, so be sure you're logged out of those if you don't want people to be able to access the running OS without logging in. Like everything that comes from suckless.org, slock is copyfree licensed by way of the MIT/X11 license.
I recently replaced GNU Screen with this handy little tool. So far, it does everything I need it to do, and does it well. It's very similar to GNU Screen in terms of interface and capabilities, but it's copyfree licensed (via the BSD license, specifically) and a much smaller program -- both clear wins, in my estimation. It also employs a client/server model of operation, which helps keep resource usage low for times when multiple sessions are needed and simplifies the design of components of the system by decoupling them. The major immediate gotcha in making the transition is the fact that the command prefix is ^B instead of ^A by default. The reason for this change is actually a very good reason, of course; ^A is the command character used by most shells to move the cursor to the beginning of the line, and using it for the command prefix in your terminal multiplexer interferes with the ability to use it as the command character for moving the cursor to the beginning of the command line. The other basics are quite easy to find in the clear, concise manpage for tmux (including the tmux attach-session command used for reattaching a detached session).
My life was, in small but rather pervasive ways, made much easier by the discovery of command line utilities that greatly ease the task of copying from the shell to paste elsewhere. The best combination of licensing, usability, and functionality that I've found so far in that software niche is an
xsel utility written by Conrad Parker, and available in the FreeBSD ports system as
xsel-conrad. In fact, I like it so much I became the
xsel-conrad port maintainer for FreeBSD; see my Projects page for more details. Raise your hand if you're old enough to remember the old Remington electric shaver ads featuring board chairman Victor Kiam: "I liked the shaver so much I bought the company."
For a while, I used rxvt-unicode for a number of reasons. The key reasons were its smaller size than XTerm and default behavior that suited my preferences. Of course, defaults are easily overcome with configuration changes and, frankly, the smaller size of rxvt-unicode is somewhat mitigated by the fact that XTerm is installed with the X Window System anyway -- so there's little point being stingy about program size when you're going to end up with the larger program installed on the system anyway. I've gone back to using XTerm, and explained how I use XTerm so that it suits my needs. Of course, I've only explained why I stopped avoiding XTerm, and not why I actually like it. The answer to that is pretty simple: it doesn't require a mouse to use effectively, it's copyfree licensed, and it offers Unicode support via the uxterm wrapper as well as by way of an X resource. Also . . . it's basically everywhere, something on which you (I, at least) can count, which is nice. It's kind of like a "standard" that way.
When I first discovered the Phoenix browser, it was like an amazing revelation. It was a browser that was so much better than the competition that it boggled the mind. In time, the name was changed to Firebird due to a conflict with other software with the Phoenix name. It kept getting better. Around the time it reached v1.0 release status, and the name was changed once again so that it became the Firefox browser, something else changed as well. Instead of getting better as the developers continued to work on it, the browser got worse with every new release. For around half a decade, I had suffered increasingly at the hands of the perversely guided browser project that has abandoned all the principles that originally made it great, and had found myself essentially unable to use any competing browser in its place because (of course) all web browsers sucked.
Late in 2011, I discovered the xxxterm project; in January 2012, I used xxxterm almost exclusively, and have only opened Firefox again since then to harvest data before finally uninstalling that monstrosity. After close to a decade of never being able to really get away from Firefox for various reasons, in that one month I only launched Firefox a very small number of times (probably two or three times), and even that was only to get at bookmarks and saved tabs that I wanted to move to a xxxterm (pronounced "triple-ex term", according to the developers, thus "a" instead of "an") session. While xxxterm had a steep learning curve relative to other browsers (like vi relative to other editors), and generally required the user to change the way (s)he uses -- and thinks about using -- browsers to get the most out of it (like vi requires the user to change the way (s)he uses -- and thinks about using -- editors to get the most out of it), xxxterm compensated the user for this by providing enhanced security, stability, and productivity to the motivated user (like vi enhances the productivity of the editor user).
Since then, it has been renamed xombrero (xxxterm was only ever intended as a working title until the developers came up with something "better"), and I have continued using it without needing Firefox at all; all the benefits of xxxterm apply as well to xombrero, and it has continued to improve since then. Possibly the most amazing thing about the way I have completely left Firefox out of my computing life since January 2012 is the fact that I did not have to try to do so. Just getting familiar with xombrero has resulted in me ignoring Firefox, not even thinking about it or missing it, in much the same way I one day found myself not turning on MS Windows for a few months back when I was a relatively new user of open source Unix-like systems because the Unix-like system I was using at the time provided everything I needed, better than MS Windows could provide any of it, despite the fact I had MS Windows customized and tuned within an inch of its life and running on a machine with probably six or eight times the power and capabilities of the system on which I was ran my Unix-like system. Firefox has just become . . . irrelevant. Finally, after years of searching, I found a way to escape the screaming plunge into stupidity and aggravation Firefox had pursued after reaching 1.0 release status.
Simply put, this is a tool for downloading videos from YouTube so you can watch them at your leisure and with the tool of your choice. It can be handy for things like hedging against censorship or -- as I use it -- to allow watching YouTube videos that are available only as Flash videos without having to enable Flash in the browser: I just download with youtube-dl then watch with a native multimedia application.
An open source development group calling itself "pwmt", or Programs With Movie Titles, decided to create a PDF viewer called Zathura. It uses vi-like keybindings, and it's quite nice. I like it a fair bit more than that old mainstay Xpdf, and (unlike Xpdf) it is even distributed under a fairly friendly license. Its only real usability flaw is in dealing with scrolling long lists of things in PDF indices, but it's a very small flaw in the grand scheme of things.