Skip to main content

What is my next *nix?

I have long since been a fan of Slackware and OpenBSD. Both are rock solid and while they are opinionated they are clean and reliable. Many years ago the Slackware author dropped out for about a year in the middle of the most productive time in the Linux Kernel. Patrick was also highly skeptical of the 3.X branch of the kernel and as a result things, including driver support, lingered.

OpenBSD has long since been laser focused on security and freedom. Theo has always held true to those principles. There was a time when certain wifi and video drivers were closed source. While OpenBSD was the most secure *nix available it simply would not run on some of the most common hardware without requiring substitute video and network hardware.

There is a lot going on right now and things are only getting faster. While I like Ubuntu, Fedora, CentOS, Mint and a few others... I am starting to focus on smaller OS'. For example, CoreOS, NixOS, MirageOS, Erlang on Xen and Elixir on Xen; so called unikernels.

What I like about OpenBSD is that I rarely have to patch it. The team is always back porting bugs and patches. What I really like is that it's very rare that I need to implement the patches because they are in userspace and 3rd party projects. The main OpenBSD Server is tight.

What makes CoreOS a very likable project is in their marketing. (a) mostly immutable (b) green/blue installation inspired by ChromeOS (c) enterprise ready with monitoring service (d) precooked with etcd, fleetd, systemd, and docker (e) scheduled upgrades with locksmith. (f) there are simply fewer dependencies and moving parts. (g) cloud-init. As a devops person I like that the heavy lifting of maintaining the bare metal is virtually eliminated.

NixOS is a relative newcomer; to me. Where most *nix systems rely on batch or script files, orchestration systems like chef, puppet, ansible, saltstack; NixOS has it's own package manager. This package manager addresses many of the shortcoming in the other orchestration systems and yet provides a idempotent OS instance after startup. NixOS could end up spanning the chasm between CoreOS and unikernels.

I was never a fan of Erlang on Xen, however, after watching a presentation from one of the developers at Jane Street I have a new respect. Whether my next unikernel is going to be OCaml, erlang or elixir is still to be seen. The thing to keep in mind is that most services or agents simply do not need all the cruft that a full-blown operating system provides.

Containers, NixOS and unikernels all provide interesting potential for green/blue as well as zero downtime... they all feel like the right future.


Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).


I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…