{"id":11057,"date":"2025-07-07T01:02:00","date_gmt":"2025-07-07T05:02:00","guid":{"rendered":"https:\/\/www.both.org\/?p=11057"},"modified":"2025-07-07T06:42:01","modified_gmt":"2025-07-07T10:42:01","slug":"the-linux-philosophy-for-sysadmins-tenet-24-reality-bytes","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=11057","title":{"rendered":"The Linux Philosophy for SysAdmins, Tenet 24\u2014Reality Bytes"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>\n

Author\u2019s note: <\/strong>This article is excerpted in part from chapter 26 of my book, The Linux Philosophy for SysAdmins<\/a>, with significant changes to update some information in it and to better fit this format. This is the last article in this series.<\/em><\/p>\n\n\n\n

This series of articles and the book on which it’s based are, after all, about a technical philosophy which would not normally be considered to be very practical. I just want to take this opportunity to bring us back down to the real world.<\/p>\n\n\n\n

There is \u201ctruth\u201d here. Reality imposes itself upon SysAdmins every day in a multitude of ways. It is possible always to be able to follow each of the tenets previously set forth in this book — but it is quite improbable. In the \u201creal\u201d world, we SysAdmins face some incredible challenges just to get our assigned work completed. Deadlines, management, and other pressures force us to make decisions many times a day about what to do next and how to do it. Meetings usually waste our time — not always but usually. Finding time and money for training is unheard of in many organizations and requires selling your SysAdmin soul in others.<\/p>\n\n\n\n

Finding the time to remember and employ the Philosophy is challenging at best. Yet adhering to the Philosophy does pay high-value returns in the long run.<\/p>\n\n\n\n

Still, reality always intrudes on the ever-so-perfect philosophical realm. Without room for flexibility any philosophy is merely doctrine and that is not what the Linux Philosophy for System Administrators is about. In this final article we explore how some aspects of reality affect us as System Administrators.<\/p>\n\n\n\n

People<\/h1>\n\n\n\n
\n

Computers are easy \u2013 people are hard<\/em><\/p>\n\n\n\n

\u2013 Bridget Kromhout<\/p>\n<\/blockquote>\n\n\n\n

SysAdmins must work and interact with people. It can be a difficult but we do need to do so from time to time.<\/p>\n\n\n\n

One thing I have always liked about computers from the very first time I sat down at one in 1969 was the fact that is did exactly what I told it to do when I wrote the program. I could make it do anything I wanted \u2013 within its capabilities \u2013 by typing in a series of commands that formed a program. If I wanted to change what it did all I had to do was change the program. Very simple.<\/p>\n\n\n\n

People are not simple at all. Not only don\u2019t I have access to their programming, they don\u2019t always pay attention to the programming they have — or that others think they have. People are not at all simple. If I were the boss of everyone they would all do it my way and then things might be simple. But it doesn’t work that way.<\/p>\n\n\n\n

So in our striving to be the most Zen SysAdmins possible we run into people. They are usually well meaning, even most of the PHBs. The problem is that many don\u2019t understand technology.<\/p>\n\n\n\n

The micromanager<\/h1>\n\n\n\n

I once had a situation where someone with a position of some authority at a place I did some volunteer work for sent me an email saying I needed to get a document up on the web site news feed as soon as possible. They also said that the hard copy was on the desk at the office. They wanted me to scan the hard copy and put that up as an image. I responded that I wanted to see the file and I could put it up before I would have a chance to look at the hard copy.<\/p>\n\n\n\n

This person responded back to me that they (meaning more than two people by now) wanted me to see the hard copy because it was an odd size and they did not want it \u201cto be too big.\u201d Whatever that meant. But, oh, by the way, they did have a copy of the PDF that was sent to the printer. Unfortunately that PDF was not attached. To which I responded that I do not care about the size of the hard copy because I would make it an appropriate size for the space available on the web site news feed and please send me the PDF.<\/p>\n\n\n\n

The next email I received had a copy of the PDF attached and a few words to the effect that, if the document was too big on the web site, a lot of people would be very upset. What?!<\/p>\n\n\n\n

I did a copy and paste from the PDF to the WordPress post on the web site and added a copy of the image they wanted on the document. It looks really good, but it will be gone by the time you read this so I won\u2019t tell you where to look for it.<\/p>\n\n\n\n

But wait! There\u2019s more!<\/p>\n\n\n\n

So far, this has taken about three days. I could have had the document up on the news feed twenty or thirty minutes after receiving it had they sent the PDF in the first email.<\/p>\n\n\n\n

In the interest of ensuring harmony amongst the people involved, I spoke to the writer of the emails the next time we met in person, indicating that I was not thrilled with their tone. I then briefly explained four good reasons why I was doing it the way I did and why the use of a PDF directly on the web site was not nearly as good as using the raw text I copied from it. I am sure you can think of multiple reasons why, so I won\u2019t even go into that here.<\/p>\n\n\n\n

The person I spoke to looked quite perplexed at all of this and said, \u201cI don\u2019t understand anything about what you just said.\u201d I said that I was just trying to make sure that the document looked as good as possible on the web site, and left the conversation at that point, leaving unsaid a few things that I was thinking by then.<\/p>\n\n\n\n

That is dealing with people. It is our reality.<\/p>\n\n\n\n

I know that the people involved in this just wanted everything to look good and make a good impression on visitors to the web site. I know<\/em> that. But knowing it does not make it easier to deal with the frustration of having multiple people trying to micromanage a task that needed no management at all.<\/p>\n\n\n\n

Tech support terror<\/h1>\n\n\n\n

I am a people, too. When I call for tech support for my Internet connection when something is not working, I don\u2019t even let the first level support person ask me the first question on their script before I say, \u201cI did reboot the modem. I did not reboot my computer because it is Linux and does not need rebooted. I want to speak to the third level support.\u201d<\/p>\n\n\n\n

They hate when I call. I know they talk about me for days after I call them. And yet when I call I have already done all of the things that they would try to have me do during the scripted conversation with the level one support people. I cannot stand having to work my way up through various levels of support. It takes time away from me getting my work done.<\/p>\n\n\n\n

Yet, sometimes, they can get it fixed right away. Sometimes the person on the other end of the conversation actually has some pertinent knowledge.<\/p>\n\n\n\n

So I asked myself, \u201cself — how do others see me when they need help from me?\u201d The answer was not good. I asked my wife and she did not hesitate. It was not pretty. I can be arrogant, condescending, brusque, and a real jerk all at the same time. That is certainly not my intent, but there it is.<\/p>\n\n\n\n

For me this can be the result of frustration at something else entirely, that I was interrupted, that I hear the same problems many times over, that I am just tired, or whatever. All of this emotional response to whatever is happening then gets in the way of fixing the problem.<\/p>\n\n\n\n

This is my reality — in both directions. So my personal tasks are to be nicer to people who need my help and also to the people from whom I am trying to get help.<\/p>\n\n\n\n

Of course, since I first wrote this for a different article, long before I included it in my book, we now have the endless loop of AI-driven voice response units to isolate us from any humon[sic] who might actually know about how to fix our problems. <\/p>\n\n\n\n

You should do it my way<\/h1>\n\n\n\n

I can\u2019t count how many times I have said in this series — and my book — that there is no one right way to do anything in Linux. I even wrote a chapter for the book entitled, \u201cThere is no should,\u201d to get the point across.<\/p>\n\n\n\n

Yet everything would be so much simpler if I just gave in to my urges and tell people to do it may way. I just know that everything would be fine if they just did it my way. It can be frustrating and hard to watch a new SysAdmin struggle with something that I can fix quickly. It is very difficult for me as a mentor to let them make mistakes. I think this is the hardest thing for me, to watch and let the young ones learn the hard way.<\/p>\n\n\n\n

I learned how to do this from my flight instructor. Many years ago I took flying lessons. I was about half way through this process, which took several months, and I was preflighting a Cessna 152 prior to a training flight with my instructor. I had completed the entire checklist for the exterior and had gotten in the plane and seated myself in the left-hand seat. I went through the checklist for the cabin and the startup checklist. checklists are big things for pilots. All this time, my instructor just sat in the co-pilot\u2019s seat and watched.<\/p>\n\n\n\n

At the end of the checklist I released the parking brake and advanced the throttle a bit. The airplane did not move. I advanced the throttle a bit more and still nothing happened. There was only one reason this might occur. I looked out the side window to verify that I had indeed left the chocks in place. That plane was not going to go anywhere \u2013 that is exactly what the chocks are supposed to do.<\/p>\n\n\n\n

I went through the shut-down checklist, exited the aircraft, pulled the chocks, got back in, and went through the startup checklist for the second time. This time, the aircraft did move freely. I taxied to the end of the runway and took off to start our training flight.<\/p>\n\n\n\n

My instructor never said a word about it. She did not have to because I knew I had missed a step on the checklist. I learned that lesson well. It was my instructor\u2019s job to teach me how to fly by myself <\/em>and not to do things for me. How would I ever learn if she did the things that I forgot for me? I don\u2019t fly any longer, but when I did, I always, always<\/em> remembered to perform every item on the list and to be sure I checked that the chocks had been pulled.<\/p>\n\n\n\n

These are absolutely the best teaching moments. When you can see that the young SysAdmin is clearly in the process of making a mistake and you let them continue without saying a word.<\/p>\n\n\n\n

There is something else to watch for in these situations. Observe the demeanor of the SysAdmins you are training. If they get frustrated and angry and blame you for not telling them what they know you saw, if they blame someone else for their problems, they may not be suitable for the job of SysAdmin.<\/p>\n\n\n\n

It\u2019s OK to say no<\/h1>\n\n\n\n

Sometimes a SysAdmin just has to say “no.” A flat, straight, there are no alternatives, “no.” BRuce<\/a> and I had to completely reject a couple projects that wanted to use our lab. Those projects would have produced great upheaval in our smoothly running lab, destroying the work of several other projects while they were about it.<\/p>\n\n\n\n

I mean, we did explain why we could not take on those projects. We spent some time with the engineers who proposed those projects and helped them understand why their projects were incompatible with the work already being done in our lab. They were not happy but they ultimately understood why we could not do what they needed in our lab. In both cases we suggested alternatives including building their own labs but I have no idea what they ultimately did.<\/p>\n\n\n\n

Sometimes a strong \u201cno\u201d is the right answer whether it is appreciated or not.<\/p>\n\n\n\n

Understanding the past<\/h1>\n\n\n\n

I find it both fun and informative to learn about the history of Unix and Linux. Earlier in this series I referred to two books in particular that I have found helpful in my understating of Linux and its philosophy.<\/p>\n\n\n\n

“Linux and the Unix Philosophy”1<\/a><\/sup> by Mike Gancarz has been particularly interesting in terms of the philosophy. The second book, \u201cThe Art of Unix Programming\u201d2<\/a><\/sup> by Eric S. Raymond, provides fascinating insider historical perspective on Unix and Linux programming and history. This second book is also available in its entirety at no charge on the Internet.3<\/a><\/sup><\/p>\n\n\n\n

I recommend reading both of these books if you have not already. They provide a historical and philosophical basis for much of what I have written in this book.<\/p>\n\n\n\n

Final thoughts<\/h1>\n\n\n\n

This has been a fun book (and series of articles) to write. When I first outlined the chapters I thought that I might not find very much to say about some of them. It seems that I really did have a lot to say. So I will keep this last part brief.<\/p>\n\n\n\n