The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Tuesday, March 22, 2005

Reduced Configurations

I made mention of the RISCesque approach to service configuration in relation to control panels and I figured it was about time I expound on it, if only because P, a fellow cow-orker, is now having to deal with both Insipid and Blech.

I don't like control panels (that much should be obvious by now) because, among other things, they take control of the machine away and hide it behind an abstraction; they also make certain operations down right painful, if not outright impossible due to these abstractions. And the more I thought about them, the more they reminded me of arguments I've heard before, years ago. They sounded much like the arguments people used in heated debates between Assembly language and C (or other higher-level languages).

Dare we write “non-portable” code? Horror of horrors! What next? The liberal use of goto's? Slipping back into Assembly? Aaaaaah! Hell, if we allow that to happen, we might even get a Real-Time Unix kernal that's under 64K in size! Can't allow that to happen, ho sir. AT&T might kill us. BSD might kill us. Dijkstra might kill us. The whole XXXXXXX industry might blackball us for providing the customer with something that actually performs reasonably well.

Me, probably about 1991

As you can see from the above quote, you can see where I fell during that time (and for the record, I have since changed my stance on portable code since I had the opportunity to program under a variety of architectures). And now, here I am, sounding like my old self, only instead of programming exclusively in Assembly, I'm wanting to configure systems by the command line.

Now, at the time (late 80s/learly 90s) a very competent Assembly language programmer could write code that outperformed what a compiler could spit out, but times, they changed. First, compilers would always get better as more research was done; for instance the ANSI C compiler I used on the SGI machine at FAU could do optimizations across entire directories of source code (although it took a long time).

Second, research into what instructions compilers typically used lead to RISC—Reduced Instruction Set Computers. The idea behind RISC is that instead of wasting silicon on complex instructions rarely used (by compilers), instead make the instructions simple and then waste silicon on making those instructions fast (with the result that writing in Assembly on those systems is even more tedious than their CISC ancestors).

Third, programmer time kept getting more and more expensive while hardware kept getting both faster and cheaper so who cares if compilers produce less than optimal code? It's not execution time that needs to be optimized for anymore (well, there are still a few instances but if the code runs fast enough, that's good enough).

So it is with control panels.

First, the argument can be made that control panels can only get better. At least, I would hope so. The third point—the expense of humans will always be true—the less humans you have, the cheaper it is. And as with compilers, which means you can employ less experienced programmers (or fewer experienced programmers), control panels mean you can get by with less experienced sysadmins (or fewer experienced programmers). Not that this is a bad thing mind you—at one point it looked like everyone in the US would have to become telephone operators to handle the growth of phone calls and to a point, that's what AT&T did—it turned everybody into their own operator.

It's the second point that's the problem. The success that compilers (and RISC architectures) have had in recent years is due to a large amount of blood, sweat and tears in making it work well (CPU designs changed to make compiled code run faster, and compiler designs changed to adapt to the new CPUs). Now, does that mean that configurations will have to get simpler? Well … perhaps. As it stands, control panels do make certain tedious operations easier, as long as the tedious operation is something the programmers planned for. But I don't think simplification of configuration files is the answer. What may need to happen is a decoupling of the configuration from the service. Or a way to feed the configuration to (and from!) the service from different sources.

But what I see happening is a reduction in the ability to configure services, and not even a consistent set of reductions either! (for instance, Insipid has the concept of an “alias” for a site, where the same website comes up under two different names, but Blech doesn't—you can physically host a site, or have the request for a webpage forwarded to another server, but there didn't seem to be the option to setup an “alias” like you can under Insipid—on the flip side, under Insipid you can't set up forwarding like you can under Blech) And I prefer to edit files over using a GUI.

And I still like programming in Assembly from time to time.

Obligatory Picture

[“I am NOT a number, I am … a Q-CODE!”]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.