* * * * *

                            Reduced Configurations

I made mention [1] of the RISC (Reduced Instruction Set Computer)esque
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 (American National Standards
Institute) C compiler I used on the SGI (Silicon Graphics Incorporated) [2]
machine at FAU (Florida Atlantic University) [3] 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 (Complex Instruction Set Computer)
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 (United States) would
have to become telephone operators to handle the growth of phone calls and to
a point, that's what AT&T (American Telegraph and Telephone) 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 (Central Processing Unit)
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 (Graphical User
Interface).

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

[1] gopher://gopher.conman.org/0Phlog:2004/12/27.2
[2] http://www.sgi.com/
[3] http://www.fau.edu/

Email author at [email protected]