Solaris 10 & 11 CLI wants to be like Cisco IOS and SMF wants to be like Systemd … but why?
It’s quite obvious with all the new features added to Solaris 10 that Oracle (and probably Sun before them) wants to change the way their users interact with their favored tools on the command line. Previously, say in Solaris 8 (we won’t talk about Solaris 9… it barely existed), you’d have standard UNIX tools which took arguments and switches in the normal fashion. Ie….
$ foobar -a -b -z somearg
Now Oracle wants everything to be in what I recognize as “Cisco Style” where there are no flags or switches and every command has to take place inside of a “context”. In this sort of style:
$ foobar sub-command -z somearg
You can see this all over the place. The ZFS toolset (zpool, zfs, etc..) is this way, the virtualization tools are this way (for LDOMs and Solaris Containers), the networking toolset is also setup this way in Solaris 11 (ipadm & dladm).
My impression of Solaris 10 was “I Love ZFS and I hate SMF”. I love ZFS because it’s about a million times easier to administer than Solstice Disc Suite (Solstice Volume Manager), which frankly is garbage. I remember having to re-jigger RAID arrays because SDS/SVM didn’t write enough metadata to them to reconstruct meta devices that had been physically moved around. This was back in the Solaris 8 days, but nonetheless, it was way more pain than folks had to endure in LVM or VxVM. ZFS was a great thing and I don’t find the toolkit particularly odious. However, I do have some critiques of the approach in general.
There are two concerns that I have over this new “style” of command line tools. First is that the desire to load one binary up with a million different features and functions is not the UNIX way and is unenlightened. Ever work with the “net” tool on Windows for administering SMB shares and users? It’s a mighty powerful tool, but it has about a zillion different features and functions. Some might argue that having one-tool is easy to remember, but I consider that a bogus argument since you’ll still have to remember all the sub-commands; so what difference does it make? The problem with bundling too many features with one tool is that the main logic path of the tool becomes a marathon to keep up with for the developers. New folks to the project have to learn where all the land mines are buried and the longer the logic path, the more terrain they have to know. That’s why one of the fundamental principles of UNIX is KISS (Keep it Small and Simple). Discard and deprecate UNIX core principles at your peril, corporate kiss-ups. You’ll be lucky to stay in business long enough to regret it.
The other issue is that it’s simply weird looking and non-standard but doesn’t give you anything in return. I teach classes in various flavors of UNIX and Linux and one of the most common annoyances new students cite is how non-standard UNIX commands can be. They see “ps aux” and ask why there is no option specifier (the hyphen). They see commands which create captive interfaces and ask “how can this be used in a pipe” (which of course they can’t). I have to explain that every now and then, either some jerkhole thinks they have “a better way” (wrongly), they come from DOS or Windows and use clueless conventions from those OSs, or they just get plain lazy. This annoys folks to no end. It especially annoys the VMS crowd who is used to high degrees of regularity in their DCL CLI. They are rarely amused by “ps -ef” vs “ps aux” hand-waving (ie.. SysV vs BSD conventions). Sun/Oracle didn’t make this better with Solaris 10 & 11, they made it far far worse (and for no good reason).
Lastly, let me give you one more example of why this method is inferior and has real drawbacks. It has to do with the “contextual” nature of the command strings when used in scripts. Consider an example where a resource of some type is created then configured. This happens a lot with tools in Solaris that manage storage objects, network interfaces, CPUs, etc. The old way would involve creating the resource, then using other tools to further configure it. Here is a pseudo-example that creates a widget:
# Make a frobozz widget as an example. Set attribute foo to equal "bar" while we are at it. $ mkthing -a foo=bar -n frobozz
That’s not so bad. Now let’s do some further configuration to it. As a thought experiment, say for example that ‘-s’ is to set the state of the frobozz thingy to “active”.
$ modthing -n frobozz -s active
Now consider the same thing but done using the Cisco / Solaris 10||11 way. It would likely look more like this:
$ superthing create-obj -n frobozz superthing> set context obj=frobozz superthing.frobozz> set state=active superthing-frobozz> .. superthing> save INFO: Stuff was saved superthing> quit
At first blush, you might say “Big deal, they are about the same.” However, for those of you who write scripts, ask yourself this, would you rather drive individual command line programs where you can check each one’s status and not have to do screen-scraping, or would you rather have to interact with something Expect-style where you will need to interpret the slave-application’s every response (via parsing it’s output, not using return values). Many programming languages can’t do it at all. Some of the more astute defenders of this brand of stupid will say “Wait! You can feed those options on the command line.” Well, yes, most of the time you could. However, I’ve noticed several places in Solaris’s new toolbox where there is no way to do that. Thus, if that facility is purely there by the goodness of their hearts, then the only way you are going to be able to drive things programmatically is if they let you do it! If the commands were discrete (the way $Deity intended) then you wouldn’t have that issue.
It’s not an issue of old school versus new school. It’s an issue of people who have learned better through experience and pay attention vs those who want to plunge ahead and disregard the work in the past with hubris and lack of planning. I love Solaris’s ZFS and the new IPS system as much as the next guy. However, I think Oracle (and Sun before them) has done an awful lot of damage to Solaris in other places. I think the SMF was really a design pattern that Linux’s systemd is now following. Both are showing themselves to be weak and ill-thought out. Most of my support calls for Solaris are for SMF. The are not coming from old greybeards who hate it, either. They are from non-UNIX folks who are baffled and beaten by it. Just like many of my recent calls for Linux are for systemd issues where it’s either eating CPU for no apparent reason, stymieing users seeking to setup simple startup and shutdown procedures. I don’t give a damn what the market-droid cheerleaders say to spin the issue, SMF was just as bad an idea as systemd. In fact, I’d say it’s even worse because significant portions use binary-opaque sqlite backends (not to knock sqlite, but this is a bad place to put it). The other half of SMF configuration goes into XML files. All this used to be human-readable scripts you could tweak/tune/read individually. They turned a traditional simple text-based UNIX feature into a complex binary opaque nightmare.
The decision for SMF and Systemd (in Linux) was probably made on the basis that developers who use an IDE more than the CLI would be more comfortable editing XML or “unit files” than writing shell scripts. They’d be free from having to learn shell script, too. Lastly they’d have more determinism over startup and shutdown since they’d moved the primary startup logic out of scripts and into their own tool. This allowed folks to parallelize the startup and other nifty features. The only trouble with these arguments is that they are either fools gold (“oh it’s going to be so much easier”) or the features being touted are not tied to the ill-advised/foolish decisions and thus invalid as an argument for implementing them (ie.. there already existed parallelized “init” implementations – it didn’t need a re-write or replacement to do that).
The only valid argument I can see being made is the one about XML and unit-files being more deterministic. However, I think this needs to be put in the context of losing the features available to the user in the shell scripts used for SysV init. In this case you’re dealing with a zero-sum game. What you give to the developers, you take away from the sysadmins.
While there are certainly those who can force us to go along, don’t expect folks to go along quietly. Furthermore, don’t expect them to stay on platforms like Linux and Solaris just because of some perceived momentum or acceptance when they become too onerous to bear anymore. The SMF and the Cisco-izing of Solaris are unwelcome from my perspective. While some Solaris die-hards are still drinking the kool-aid, most Solaris sysadmins have moved on. I personally don’t expect anyone to care when Solaris 12 comes out (if it even gets that far). All the cool features are being take up and enhanced by more enlightened projects (such as ZFS on FreeBSD). Anyone who isn’t tied to some legacy environment is going to have jumped ship by then. Legacy environments only get smaller and suffer attrition. That’s Oracle Solaris’s future, if you ask me.