Author’s note: This article is excerpted in part from chapter 18 of my book, The Linux Philosophy for SysAdmins, with some changes to update the information in it and to better fit this format.

Why is this a tenet of The Linux Philosophy for System Administrators? Because arguing about editors can be the cause of a great deal of wasted energy. Everyone has their favorite editor and it might not be the same as mine. So what?

I use vim as my editor. I have used it for years and like it very much. I am used to it. It meets my needs more than any other editor I have tried. If you can say that about your editor – whichever one that might be – then you are in editor nirvana.

I started using vi when I began learning Solaris over twenty years ago. My mentor suggested that I start learning to edit with vi because it would always be present on every system. That has proven to be true whether the operating system is Solaris or Linux. The vi editor is always there so I can count on it. For me, this works.

The vi editor can also used as the editor for bash command line editing. Although the default for command editing is emacs, I use the vi option because I already know the vi keystrokes. The option to use vi style editing in bash can be set by adding the line “set -o vi” to the ~/.bashrc file for just your own use. For setting the vi option globally, a configuration file in /etc/profile.d/ is used, so that all users, root and non-privileged have that as part of their bash configuration.

Other tools that use vi editing are the crontab and visudo commands; both of these are wrappers around vi. Lazy SysAdmins use code that already exists, especially when it is open source. Using the vi editor for these tools is an excellent example of that.

There are many other editors available that are also great and powerful and fantastic. I still prefer vi or vim. You should use what you want and don’t worry about what everyone else is using. Just because I use vim does not mean you have to use it also. Using the best editor for you is important for your productivity. Once you’ve learned the keystroke combinations and commands that you use most frequently in an editor, you can be very efficient in editing files of all types.

More than editors

There is much more to this chapter than just editors. It is really about using the tools that work for you and the discussions about the best editors are the archetype for those same types of discussions about all kinds of tools.

Discussions about which tools to use, whether about editors, desktops, shells, programming languages, or anything else, are normal and can be very helpful. Those discussions provide knowledge of new things or new information about how known things work and how to make them work better. Thoughtful and respectful discourse can be helpful and even critical to enhancing my knowledge and improving my skills as a SysAdmin. I hope it works that way for you, too.

The problem arises when those discussions degenerate into disrespectful and useless flame wars that only create anger and discord among the participants. I always try to exit those discussions in order to conserve my energies for more productive activities. Let’s look at some examples.

Linux startup

SystemV and systemd are two different methods of performing the Linux startup sequence. SystemV start scripts and the init program are the old method and systemd using targets is the new method.

Just to ensure that we are all on the same page here, the Linux startup sequence begins after the kernel has loaded either init or systemd, depending upon whether the distribution uses the new or old startup, respectively. The init and systemd programs start and manage all of the other processes, i.e., programs, and are both know as the mother of all processes on their respective systems.

Although many modern Linux distributions use the newer systemd for startup, shutdown, and process management, there are still some that do not. One reason for this is that some of the distribution maintainers and some SysAdmins prefer the older SystemV method over the newer systemd.

The real issue with SystemV vs systemd is that there is no choice on the SysAdmin level¹. The choice of whether to use SystemV or systemd has already been made by the developers, maintainers, and packagers of the various distributions.

Despite the fact that this particular choice has been made for us, our Linux hosts boot up and work, which is what I usually care the most about. As an end user and even as a SysAdmin, my primary concern is whether I can get my work done; work such as writing my books or this article, installing updates, and writing scripts to automate everything. So long as I can do my work, I don’t really care about the start sequence used on my distro.

One of our editors, Seth Kenlon, has written a pair of articles for Both.org that look at both sides of this debate. In 5 reasons to love systemd, he describes the advantages of systemd for SysAdmins and other users. In 5 reasons to love init he explores the advantages of the SystemV init system.

Desktop

My preferred desktop is KDE Plasma. Several years ago, around 2008 with the release of Fedora 9, KDE moved from V3.x to V4 with significant changes that caused some serious problems. Some of my favorite KDE applications no longer worked because they had not yet been updated to work with the new version of KDE. I experienced frequent crashes of the desktop that made it impossible to get any real work done. Sometimes KDE would crash several times an hour. This was not good for productivity.

Fortunately I was able to switch to a different desktop and I used GNOME 2 for a year until KDE was usable again.

Then in late 2016 KDE underwent another set of changes that resulted in more instability. This time I made it a priority to learn more about several of the other desktop environments that are available. Starting in December of 2016 I used each of three different desktops for a month so I could really get a feel for how they worked. Just trying something out for a couple hours does not give you any real idea how a desktop works or how it can be configured to work more in line with your own style. I tried Cinnamon, LXDE, and GNOME 3 and learned to like each for their own strengths.

I was able to turn a problem into an opportunity to try some new things; desktops, in this case. Each of these desktops has a number of strengths and each has some things that I found to be drawbacks when I used them.

Even KDE, my favorite desktop, has some issues. It does tend to go through cycles where it is unusable. It is large and takes a great deal of memory. Some of the default applications that it installs and which start when KDE is launched at login, suck up CPU cycles. My post installation script has code to remove the more problematic KDE applications and turn off the background daemons of others so that my systems are not affected by them. And so I continue to use it when it is usable.

A few closing words

It does not matter to me what tools you use and it should not matter to anyone else, either. What really matters is getting the job done. Whether you are vim or EMACS, systemd or SystemV, RPM or DEB, what difference does it make? The bottom line here is that you should use the tools with which you are most comfortable and that work best for you.

It is of the utmost importance that the tools we choose to use are not restricted or hindered in any manner. The misuse of perfectly good tools to aid and abet this impediment is unconscionable and inimical with all of the freedoms that Linux and open source stand for. It should be resisted and circumvented whenever it is encountered.

One of the greatest strengths of Unix, Linux, and open source in general is that there are usually many options open for each task we need to accomplish. We have more open source word processors available to us than the three or so I remember at the height of the proprietary PC software age.

1. OSnews, “Editorial: Thoughts on Systemd[sic] and the Freedom to Choose,” http://www.osnews.com/story/28026/Editorial_Thoughts_on_Systemd_and_the_Freedom_to_Choose ↩︎