Home

This is from my private notes while reading the initial spoon theory text:

As a side note, I believe that the spoon theory holds for parents and caregivers too.  And it can be used to explain intolerant and bad behavior to those close to us. They, in contrast with anyone else, should know better of the energy consumption that some communication entails. They should facilitate it, not hinder it with unnecessary extras.  Get to the point!

There is not much communication energy left at the end of the day. You need to respect what is left of it. Most do not.

Advertisements

It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.

said Sherlock Holmes in “A Scandal in Bohemia” by Sir Arthur Conan Doyle. I smiled a bit, because I had blogged about this back in 2009 when I was still writing mostly in Greek.

Moses B. popped this in my timeline. Although the piece is about philosophy (of which I know nothing about) I thought I could entertain myself by paraphrasing the key points a bit. I am blatantly plagiarizing:

People like me, who have been trying to do Ops (system administration by a new name) for more than twenty years, do in due course learn, if they’re lucky, how to do what they’ve been trying to do: that is, they do learn how to do Ops. But although I’ve learned how to do Ops, nobody ever told me how do it, and, so far as I would guess, nobody will have told you how to do it, or is likely to tell you how to do it in the future.

So back in the early 90s why was I not taught how to do Ops? In parallelism with the philosophy article, here are some ideas:

  • System administration was free of methods.
  • The methods were kept quiet, perhaps because people thought “the methods of cannot be explicitly taught/said, but have to be shown via example/exemplars.”.
  • “those of us who have learned how to do it struggled so hard to get where we now are that…we think you, too, should suffer,” perhaps because “we’re now selfishly reluctant to give you some of the fruit of our struggle for free”.
  • “the methods of (early to middle) system administration were not unified”.
  • “it is a form of boundary policing. Under such a regime, outsiders are permanently mystified about the rules of the game because they don’t know what move to make to acquire standing”.

Let me see. When I started in this line of work there was no manual other than man and the technical documentation from the vendor (if you were lucky to have access to it).  Humble posts to the USENET groups and to lists like decstation-managers also paid off.

People lead by example. So their accumulated knowledge was not part of the technical documentation (I still find old vendor technical documentation far superior than today’s). Knowledge gained from experience, was passed the same way forward: By experience. “Do that” said the wizard in a stressful situation and afterwards they would share the war story that led to that. You were then supposed to generalize from what you were shown.

But sometimes, being shown was not enough. You had to struggle. Because the wizard as an apprentice was forced to learn how to swim by themselves, they retained the same belief for the next generation, or even for a peer (if you’re an equal, you can do it). The initiation process would require you to struggle, to earn the knowledge, to be able to read the packets in the wire like being the network driver yourself. The wizard was one with the machine, why should you benefit from this and not become one too?

How would you administer your systems? Via, SAM, SMIT, some other curses-based tool, if any, the shell, batch scripts doing rlogin? How? How would you do that in an era when infrastructure as code was not a thing and cfengine was a curiosity? How do you even do that now that you are hit by the paradox of choice? Did you ever hear of a book like this? If you did, did you read it?

Do you remember what a BOFH is? I know, because I was one. Before becoming one, I was told: “I do not understand why you’re asking this: You should either know what to do, and not ask, or you do not know what to do, and do not have to ask because you will not do it”, said the elder, then thought to be wise BOFH.

We are priests. Either you know how to read our hieroglyphs and you’re in, or you’re out. A great sense of empowerment came out of this. We take your crap and place it in production. It breaks. We tell you why and you still do not have a clue. We’ve explained the issue clearly, but not in your language. Your fault.

I will go with the most charitable explanation: We do not know how to pass the craft’s knowledge and everything else is a defense so as not to fall in your eyes.

I’m sorry.

PS: And then, DevOps came along

I moved to a new flat today, and after unpacking and general housekeeping, it was time to connect the Echo to the network.  Unfortunately, it refused to play ball.

So I reset it to factory defaults. No luck. The process was hanging when it tried to connect to the net. The progress bar stopped at some point after being halfway through. Factory defaults again. No luck. But the old mother of all evil came into mind:

Everything is a DNS problem.

Could it be so? Of course it could. I am running dnscrypt-proxy so my DNS server is always set to 127.0.0.1 and not whatever the DHCP proxy serves. So, let’s get the default from the network:

networksetup -setdnsservers Wi-Fi empty

I then pointed my browser to alexa.amazon.com (yes I am not using the app) and the configuration completed without a hassle! I switched back to using OpenDNS FamilyShield by:

networksetup -setdnsservers Wi-Fi 127.0.0.1

For anyone interested I brew install dnscrypt-proxy and my dnscrypt-proxy.conf has:

ResolverName cisco-familyshield

I admit, I almost forgot. I got reminded that it is SysAdminDay via a text message from a friend.  I am in between jobs in a new country, trying to fix an agreement on a house, so I forgive myself.  But as always, I want to write a few lines. They might echo an older post but I cannot do better today. So I am going to revisit my Conway’s goals, but for DevOps:

  • Big Problem: I guess this is going to come my way thanks to my new employer. They hired my for a reason.
  • Workable Problem: There will always be a second problem to spend my day at. One that will progress easier than others and offer a sense of daily accomplishment. At least I am it to be this way.
  • Book problem: I have three of those lined up. I am not writing a book, but there are three that I aim to study thoroughly. In fact I am a year behind in one of them. However, with a lot of free time away from my family, I guess I do not have the excuse of non existent time.
  • Fun problem: I intend to learn Go. I’ve no problem with GNU-Go’s text interface.

Happy SysAdmin day everyone. May your puppets, salt minions and pod containers sail bug free and fail only within 9 to 5.

I used to listen to hip-hop a lot. For years my screen saver was the text you don’t quit. This week this changed. After listening to the Mogul podcast it became:

keep raising the bar

Hip-hop is good at giving you mission statements I guess.

on drawing circles

2017/07/06

The way you draw circles says a lot about you, claims a post that popped into my INBOX today. Indeed I thought, since I was reminded of an older post about Giotto and his true mastery drawing the perfect circle which kind of also required that you were able to recognize the craftsmanship.

Which keeps me wondering what the perfect circle for DevOps would be? At least for this point in time.