Skip to main content

Blog: Resurrect or Die?

This blog has been idle since 2012. Does anyone care?

Like many, I let this blog die. I think that’s happened for a variety of reasons, both personal and professional.

Relevance: Most of what I was posting was clearly not going to make any difference to myself or anyone else. Posts that announce [random software] has [random vulnerability] could just as well have been machine generated. The state of software security is at best, marginally better than it was a handful of years ago, and some random guy blogging about it isn’t gong to change that.

A few posts were and are still relevant. No matter what I do, I’ll maintain access to those.

Burnout: Having more than one open Oracle Sev 1’s per team member was brutal. We were in a situation where a small handful of us were working a seven-day pace for months. A few months of that and I was more than ready to back off from my immersion in technology and recuperate a bit. Hobbies got more interesting, and being able to disconnect from 24x7 operational responsibilities was essential.

Chaos: Having multiple layers of leadership turnover simultaneously created a work environment that was unpredictable and chaotic. Uncertainty affected staff moral, working environment went from stressful but fun, to simply stressful. I got a new boss, and along with that a significant job change.

Blogging is dead: Of the hundred-odd  blogs that were in my RSS feed, only a handful are being maintained. The center of gravity has shifted. I miss following bloggers – as well formed, thoughtful ‘long form’ writing still interests me far more than short, disconnected 140 character messages.

So – let die gracefully, resurrect, or something in between?

--Mike

Comments

  1. I'm with you ... well written blogs are a lot more interesting to me than short bursts of mostly uselessness. After Google Reader (and whatever I was using before it) shut down (still not sure why) I guess I just lost interest in keeping up with everyone. Most of it didn't apply to me anyway and I was happy to not have the burden of keeping up with hundreds of blogs a week. I had mine organized by day ... I checked a certain subset on Monday, a certain subset on Tuesday, etc.

    I've checked on some of my favorites throughout the years but they've all died off, unfortunately. The new sysadmins today don't know what they're missing out on.

    As far as a direction for your blog, I say do whatever makes you happy. You don't want it to become a chore or a burden .... if a new post fits into the day's schedule then go for it.

    ReplyDelete

Post a Comment

Popular posts from this blog

Cargo Cult System Administration

“imitate the superficial exterior of a process or system without having any understanding of the underlying substance” --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:Failing to understand the difference between necessary and sufficient. A daily backup is necessary, b…

Ad-Hoc Verses Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to …

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:
In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. The…