Our frustrations with OmniOS's 'KYSTY' minimalism

October 24, 2017

OmniOS famously follows a principle called KYSTY, where OmniOS itself ships with minimal amounts of software (and the versions can be out of date). As far as I know, OmniOS CE has continued this practice, which has an obvious appeal for people trying to maintain an OS distribution on limited amounts of time (especially a LTS version, where you might be stuck patching old versions of programs that aren't supported upstream any more). All of this is well and good, but in practice the results of this KYSTY approach have been one of our significant points of frustration with OmniOS.

As sysadmins operating servers (primarily Linux ones), we have come to expect that our systems will have a certain basic collection of workable standard programs that we use for basic system management. For instance, we want every system to be able to send us email, and we really want to do this with Postfix (Exim is an acceptable substitute). Almost every system needs a program that can talk to disks to get SMART information, and while there are alternatives to tcpdump, we have tcpdump everywhere else and we really want one standard program. I could go on; there's an entire collection of things that we consider standard that just aren't there on a baseline OmniOS machine.

(I can't not mention top, though.)

We were able to mostly fix this with various third party package sources, but the result is complicated, requires a large magic $PATH in order to work relatively seamlessly, has gaps, and is quietly fragile over the long term. As an example of something that has quietly worried me, at this point there's probably no way to exactly reproduce one of our fileservers because it's very likely that at least some of the third party package sources we use have moved on from the package versions we installed. Does this matter? Probably not, which is why we didn't spend a significant amount of effort to figure out how to get and freeze local copies of all those packages.

(The exact version of top that's installed is probably not important for our NFS fileservers. We could even live without top at all, although it would be annoying.)

I sympathize with OmniOS here in the abstract, but in the concrete it was and is a point of friction when we work with our OmniOS machines. They're different, and from our biased perspective, gratuitously so. The result makes our life harder and leaves us less happy with OmniOS.

(I think that a great deal of the problems could be removed if there was an OmniOS CE equivalent of Ubuntu's 'universe' repository and it could easily be enabled. The main OmniOS CE developers wouldn't be responsible for maintaining software there; instead it would be open for reasonably vetted community contributions. Officially embracing pkgsrc might be another option, but I don't like that as much for various reasons.)

Comments on this page:

By Jinks at 2017-10-24 04:00:27:

(I can't not mention top, though.)

Honestly, these days I expect htop to be available, at least as a package from the official repos.

Its interface is so much nicer and more responsive than top and I'm more used to its keybindings by now than top's.

By dozzie at 2017-10-24 05:29:30:

Third party packages gone missing is the main reason I never use third party repositories (I've seen this happen to packages I cared in RPMForge for RHEL5) and instead I always add the required package to my own repository. My own repository is the very first thing I set up for a new environment. A little more work in the short run, but nice long term stability and predictability.

I think this is one of the problems that pkgsrc is trying to fix:

Originally written for, and still used by, NetBSD, it also works on Linux, other BSDs, Darwin / OS X, Solaris (since 1999), IRIX, AIX, Cygwin, etc.

If you want a consistent system on your non-Linux systems, and even perhaps leveraging it on Linux as well, it's worth looking into.

I've always applied KYSTY to things like services and applications. So I always want to maintain things like apache, nginx, even runtimes like java, independent of the OS, so that an OS upgrade can't destroy a service I'm running. (And so as to make it easier to move the stack to a different system.)

But there's no reason to cripple a system by not providing utilities. And I think that top and tcpdump fall fairly and squarely into the utility category. Not providing those isn't anything to do with KYSTY, it's more JEOS.

By opk at 2017-10-24 16:51:12:

And I think that top and tcpdump fall fairly and squarely into the utility category. Not providing those isn't anything to do with KYSTY, it's more JEOS.

As Chris mentions, there are alternatives and on a Solaris system, that means prstat and snoop. And for the vast majority of cases, they are more than just enough. Maybe they don't have quite so many options but it's unfair to criticize the lack of top and tcpdump if it is just that you're used to typing those command names on Linux.

Written on 24 October 2017.
« I've now seen something doing SMTP probing of IPv6 addresses
Having different commands on different systems does matter »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Oct 24 00:41:36 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.