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.
![[The future's so bright, I gotta wear shades]](https://www.conman.org/people/spc/about/2023/1023.t.jpg "The future's so bright, I gotta wear shades")