Over the last 4 years the world as we know it as systems administration has changed pretty significantly. Not that it had not already started changing in this direction since about 2008-2009, but it seems that the majority of companies are pursuing systems in a different way than ever before.

In days gone by, a Systems Engineer or System Admin for Unix/Linux systems would generally automate the build and configuration of systems in a similar fashion – and this was the automated way.

For a time kickstart was used, and still is in some cases. The process usually involved PXE Boot, DHCP, a kickstart server, a kickstart image, kickstart scripts and then some other automation script that completed the system configuration.

After that, a common tactic was building images using Packer, deploying the image to a standard location, then booting that image and attaching it to some configuration management system, such as puppet or chef. Often times for datacenter servers, this is still the method used.

But each year, developers want infrastructure faster, and in reality, all they want is to deploy their code and not worry about the infrastructure. Gone are the days that developers put in a request for a server and wait weeks for it to be built, or even wait days or minutes for it to be built. They want to deploy their code into a managed environment. The landscape in this space is varied.

Once upon a time LSF Grid or similar compute grid systems were used – built and managed internally to the company. Other PaaS systems were developed and have been used, such as PCF, but most recently the rise of Kubernetes is pretty impressive.

I went to Kubecon in Seattle this past month, and it was pretty amazing to hear about the growth of the conference (number of attendees year over year) and the number of vendors creating solutions for managing K8s clusters. Even with a managed platform though, there are the headaches that come with deploying apps as there is no one way to do it, there are many ways. But this is typical of open source solutions and the Linux culture in general. Why build one way with one vendor when you can have 10,000 different people work in groups of tens and hundreds of engineers to build things quickly.

Every company is adopting the concepts of infrastructure as code. Agile development practices, for good or bad, and ease of deployment of applications. What this means is that apps get built and deployed quickly, and it is not uncommon for large enterprise companies to have thousands of apps running, doing similar or conflicting things all over the company.

The good part is that it can be done fast, and great ideas come along. If you have good communication strategies to get the engineers to talk together, share information and learnings, and have open strategies for collaboration without keeping silos in effect or building them higher, there is something to be gained by having a lot of different engineers coding similar things.

The challenge is alignment. The challenge has always been standards to prevent duplication of systems.

In the quick moving environment, internal and cloud systems grow quickly which causes more points for audit compliance, security and the spread of a beast you cannot control or manage.

In some ways, it is like releasing a spring that has been coiled too tightly for too long and it flies off quickly in an undetermined direction. In other ways, it is like a bird gaining its wings, and it flies off with a wonderfully new found freedom.

Which way do you see this going where you work?



We had this discussion go around the world at work recently after the article appeared in a recent online trade rag. Basically the title was “The last days of Unix – after a 30-year run, once dominant server OS gets 86ed by x86es”, suggesting that the UNIX market was dead. That something else was replacing it. It spawned a great bit of discussion, primarily because it was misleading, while at the same time technically true.

The market share for servers in the data center for Commercial Unix vendors has been declining for some time.

The headline of the article made it sound like what the world of Unix developers have been doing for years was somehow fated for oblivion. But we must remember that what was created by creating UNIX in the first place was more about the concept of an operating system written in a language that was portable across hardware platforms. Prior to UNIX all the hardware drivers were written in low level code like assembly language or proprietary languages that were hardware dependent.

But whether is it UNIX or a system very much like UNIX (aka Linux) it is easy to switch from being a UNIX developer to a Linux developer – therefore the concept, the people and the skills live on through the metamorphosis.

Make no mistake – We have seen this before, and we will likely see it all again. Remember in the early days of Unix there was UNIX – but there were distributions of UNIX – System V and BSD. They diverged and merged ideas and then corporate vendors made versions to run on their hardware – thus the beginning of the commercial UNIX brands.

At one point there were over 400 different flavors of Unix. During this time of everyone writing their own Unix, based on the two or three main sources, we started to see GNU tools being developed to make applications available for free, then a fully-fledged FREE “Unix-Like” OS called Linux. In the beginning Linux meant “Linux is not Unix”. But it was built on the same concepts.

Now however, we basically see a similar pattern of companies creating their own distributions of Linux – Fedora, Red Hat, Centos, Slackware, Debian, Ubuntu, Mint, Unbreakable, etc, etc, etc – each with a similar kernel, slightly different in the stream of time, but with their own features – new features that compete with commercial products and commercial add-ons for Linux.

It’s all very similar. But it is all based on the same principle that started Unix. An OS written in a language that was portable to any hardware – hardware independence is what UNIX was all about.

The UNIX philosophy, the skills needed to be productive in the computer field, and the people behind the scenes are not going away – at least not yet – that is a topic for another post.

However, on the truthful side, Solaris, HP-UX, AIX, and similar commercial UNIX versions are losing market share.

When it comes to data centers, 95% of the jobs that I get contacted about are Linux Engineering jobs. I have many more years of ‘Unix’ experience than Linux, but shortly after Oracle bought Sun, the final item needed to turn the tides happened. Oracle on Linux was a reality. Then it was like dominoes – Everyone in a mad rush to convert the data center to Linux and remove “Legacy” Unix systems. It will take a few more years for the conversion to happen, but it has been happening all across corporate America and likely the world for some time.

In regards to UNIX as a whole, I thought it fair to mention what UNIX is today:

From Wikipedia related to the current definition of “UNIX” and the Trademark holder – The Open Group:
“The Single UNIX Specification (SUS) is the collective name of a family of standards for computer operating systems to qualify for the name ‘Unix’. The core specifications of the SUS are developed and maintained by the Austin Group, which is a joint working group of IEEE, ISO JTC 1 SC22 and The Open Group.”

As far as a non-datacenter version of UNIX:

OS X is Unix:

“Apple’s OS X is an Open Brand UNIX 03 registered product,[12] first becoming registered with Mac OS X v10.5 ‘Leopard’ on October 26, 2007 (when run on Intel processors).[13][14] ‘X/Open Brand’ is awarded to software which demonstrates compliance with an X/Open specification, in this case ‘UNIX 03’.”

I would not call OS X a server OS though I think it is used on servers – I would not expect Apple to take over the data center – ever.

Other Unix’s would be registered if it was not so expensive.
It may be possible at some point for Linux to be considered Unix!

Again, from Wikipedia (it’s online, it must be true)

“Linux aims to be compliant, but as certification is expensive, no Linux distribution has been registered as SUS compliant.[21]

The Linux Standard Base was formed in 2001 as an attempt to standardize the internal structures of Linux-based systems for increased compatibility. It is based on, and also extends in several areas, the POSIX specifications, the Single UNIX Specification and other open standards. It is de facto accepted and followed by many Linux distributions.”


Since this is my first post, I’ll start with a little background. I have been in the UNIX community since 1989 professionally. I worked at that time at Digital Equipment Corporation supporting the Ultrix operating system. This is where I learned most of the fundamentals of what UNIX was, how it worked and the guts behind the shell. I learned C programming and system calls, and the various aspects of building, patching, and troubleshooting UNIX problems. I had considered becoming a device driver writer or kernel engineer back in those days, however when I left Digital in 1992 to look for a job outside in the real world I realized that the market for kernel engineers at the time was not so great. And the market for Ultrix was even less.

The recruiter I was working with made it fairly clear that I needed other skills like Sun, IBM or HP to make it in the commercial world. Which sounded reasonable – so I made it my goal to diversify. That is probably the best decision I made – somewhat out of necessity. But it was a similar approach that I have used over the last 20 years that has allowed me to keep current.

Over the course of the last 10 years I’ve had to switch jobs 7 times, some lasting only 2 months as a contractor and as long as 5 years as a full-time employee. This unfortunate circumstance has also been a good thing in a way because I was able to keep practiced in my interviewing techniques, and refine my resume so that it gets attention. It also taught me the second valuable lesson. Your resume is very important in getting jobs quickly. Your ability to interview only comes into play AFTER you get past resume review.

In these blogs, I hope to shed some very important lessons I have learned as a Senior UNIX Professional. I hope you enjoy the insights I plan to share.