Older blog entries for lindsey (starting at number 14)

A Theory of Research

Most of the proofs that I've seen lately really aren't very startling, once explained. It just appears that a scientist or mathematician was thinking carefully about something, and derived something, then wrote a proof convince the rest of us.

Perhaps this sort of research is what happens when you focus your mind on one specific little topic, allocating all of your registers to that one topic. It's relatively rare, then, because we're rarely willing to focus on one tiny little topic in all of its excruciating detail.

Theoretical Computer Science: useful, for something

I've commented previously about my skepticism with theoretical Computer Science. My first personal, real encounter with it came in the form of a Real-Time Systems Course which has a heavy theoretical component.

My basic issue with it boils down to this: CS Theory predicts that some things will be possible when they're not possible on real machinery. It works in a world of algorithms and structures which have no real manifestation.

For example, Preemptive Earliest-Deadline-First scheduling can produce a schedule for any real-time task set that can be scheduled. But, in reality, preemptive EDF may have oodles of context switching which means that some task sets declared "feasible" cannot actually run on any real machines. I like to make things run, and this thing seems to be lying to me. See 2002 October 10 ammendment to this comment.

However, I've come to realize one big benefit from theoretical analysis: even though some things are possible in theory that are not possible in practice, nothing that's impossible in theory is going to be possible in practice. I.e., theoretical analysis is useful for telling us what we cannot do.

MacOS X -- maybe a little buggy

Averaged over the last two weeks, my MacOS X machine has hiccuped once every three days. Network activity stops and it won't start some programs. That's an annoyingly-high failure rate, and because there's no readily-available working shell (like a text console outside of the windowing environment) I haven't been able to analyze the running system to see what's happening.

While it's in this weird state, some programs won't start even in a running shell window. ping doesn't run; netstat does. 'ps' with no args does, 'ps auxw' won't run.

So I can't tell if it's just a kooky GUI thing (forgiveable, since GUIs are always kooky) or if it's something more fundamental (like a broken linker).

Grr

I had to reboot my MacOS X machine because I couldn't get to a real terminal and clean things up.

It somehow went nuts; I couldn't start a shell, and, even in the shell window that I did have, some commands didn't seem to work; e.g., netstat did work, ping didn't work, ps didn't work. I couldn't start anything new from the "Dock", and the "Finder" program (which seems to be somehow related to a window manager) was only partially working -- as if some of its threads had locked up.

Now, in an X11 world, I'd just switch over to a real terminal (Ctrl-Alt-F1, on a suitably-configured FreeBSD or Linux system) kill the offending programs, and restart the UI. But in MacOS X I had to (a) manually "force kill" each of the programs (Ctrl-Option-Esc), then (b) restart.

Fortunately, the force-kill thing worked reliably. It seems to behave like a SIGKILL (`kill -9'). And there was enough of the environment still running to shutdown cleanly, so at least I didn't have to remove the battery.

Apple's mother-may-I approach to user environments runs contrary to my Unix, remount-readonly, kill-and-restart-as-necessary, anything-but-reboot way.

I want a text console!

Initial Experience with MacOS X

MacOS X does indeed appear to be Unix, although it's not entirely Unixy. For example: conventional MacOS applications live under a directory /Applications -- this is sort-of semantically similar to /opt on some Unixes.

It can boot either to login to a specific user by default (normal single-user system behavior), or to an xdm-esque login manager.

The normal database files exist -- e.g., /etc/passwd, /etc/group -- but, apparently, they're only used by naive programs and while in single-user mode. Programs are supposed to use NetInfo, which appears to be an NIS-like thing.

Man pages are provided for many of the `normal' Unix utilities, but -- unlike other commercial Unixes, like Solaris -- man pages are not provided for all of the proprietary programs. For example, there's a program called "SecurityServer" that runs all the time, but there is no SecurityServer man page. Apparently the Apple guys know about it, and they don't expect us users to tweak SecurityServer's parameters. (IMHO, if Apple wants to be taken seriously as a Unix vendor, they'll need to address this mindset. Of course, shipping MacOS X at all may have been a higher-priority than shipping MacOS X with complete man pages.)

MacOS X doesn't ship with compilers, but they're freely available in the 220MB "Developer Tools" package. The Developer Tools package contains at least a C compiler (but not gcc) and a relatively-recent JDK.

Apparently, the Darwin Folks have lots of stuff available for folks like me. I'll be learning about them.

Furled Brows

At a fondue party last night, I got a few furled brows when I mentioned that I was considering an Apple laptop. I explained about how MacOS X was possibly going to be useful, whereas I was sure that the OS on a x86 laptop wouldn't be useful. But I did learn that furled brow dips well in caramel.

Based on some responses from the macos-x-server mailing list hosted by Apple, MacOS X Server is identical to MacOS X non-server, modulo

• the root account comes pre-created on "Server"
• "Server" includes some "webmin" administration utility which provides a GUI to some configuration files
• "Server" includes a utility to automatically restart a service which dies.
• non-server limits the maximum number of concurrent Apple-flavored protocol connections

So I may well become another guinea-pig Unix geek who gives MacOS X a spin.

Nerds

I was accused of being a nerd last night by a Biostatistics grad student.

Looking at Laptops

I'm shopping for a laptop. I spend a lot of time codin' with my current [graciously-lent] laptop in my lap. Opinions and advocacy are welcome.

Genre of OS: x86 laptops are, as always, solidly under the foot of MS. But Apple is going in a Unix direction; I'm starting to find this attractive. jcv has pointed out that it'd be valuable to have a commercially-supported Unix for which widely-distributed applications are available. (Heckle him for such a non-open-source-advocate statement.) But if the good stuff is available for OS X -- gcc+binutils, NFS support, under-the-hood OS access -- then it really does sound viable.

Worst-Case OS: If I got an x86 laptop, I'd immediately jump to the worst case: Install Linux, and derive almost no value from the installed OS. If I got an Apple, then I might actually be able to make use of the installed OS; and, in the worst case, I could use Linux. I think cmiller has said that he'd go with an Apple laptop with plans to use his Linux.

Target market: I don't like the fact that Apple's typical marketing for about a decade was the dumb computer users. OTOH, this implies that the alternative is overly complicated; and, frankly, it is, in the same way that an irrational lab manager is complicated.

Boredom: I've been using x86 for a while, and it hasn't surprised me in a while. Thusly, Apple's PowerPC platform is attractive for the newness of it.

Teams: John Crawford of Intel got his MS in CS from my team, but he's not working in IA32 any more. (It's funny that Intel describes him as a "new college graduate" when he joined Intel, when actually he had had a BS for several years before joining Intel.) In the PowerPC camp, I know a guy who designs parts of the PowerPC chip core here in the triangle (Howdy, Wayne!), so maybe I should throw in my lot with him.

Case material: Do those Titanium-composite cases really add any utility? Nearly every laptop I've ever owned or used or seen used has suffered some sort of minor case trauma; in theory, it would seem that the metal case might help protect the innards. But is a bent case superior to a cracked case? The metal-case models (both x86 and Apple) seem to cost about $500 more than the closest plastic-case models.

Lack of a source: I'm not sure where to shop for laptops any more.

rasmus points out that PHP discourages over-engineering; he might be right. I've come around to the opinion that it's best to design for what you know you need, and leave the future to hide its own bodies.

But for some of the tasks I've tried to do, PHP doesn't even support the the appropriate level of design for the things I know I need now, in the same sense that assembly language doesn't support string manipulation. (I.e., it allows you to do string manipulation, but it doesn't particularly help. Contrast with the way that early Fortran specifically disallowed recursion because of its lack of a runtime stack.)

Theory of Management

Dr. Brooks has been talking about Barnard's Functions of the Executive book in the Professional Practice seminar here. I haven't been able to read much of it yet, but just hearing the discussions and key passages has been much fun. It seems that after many years as an executive in the telephone system, Barnard sought to develop formal models of Organizations, Authority, Responsibility, &c. It appears to be written very precisely and with a mathematical sort of style, but I'm sure it's not beyond most advogatrans. If you're in the market for a strong book on management, have a look.

Theory of Computation

There's a definite mismatch between theories of computation -- largely functional in nature -- and computing as it's done -- which is heavily driven by I/O.

The current theories of computation seem, e.g., Turing Machines and such, are built around these mathematical notions of identity, state changes, and recursion. But might it be possible to model computation as just table lookups? I.e., given these inputs in registers, or those data on the tape, what does the "ADD" lookup return?

And if so, then could we develop a model for computation in which I/O is the intrinsic operation?

I'm getting the feeling that the focus on instruction processing or state transitions isn't really taking us very far. It seems as though our collective focus in Computer Science is too driven by functional notions of computation, so that we might be missing opportunities for research that could render better models for what is really done.

cmiller is gaining wide fame around here. Some sort of script. I'm proud to say that I knew him when he was first introduced to a real user interface:

From: Chad <chadmill@valdosta.peachnet.edu>
Date: Sun, 22 Oct 1995 22:51:03 -0400 (EDT)
To: "Mark R. Lindsey" <mrlindse@valdosta.peachnet.edu>
Subject: bash

Mark,
Hey--I set up bash as my shell (well--kinda. This is in my .login:
"bash -i ; logout" . Pretty lame, huh?).

whytheluckystiff

mentions that PHP seems like toy coding; I've had the same thought. In fact, at ApacheCon a couple of years ago, it appeared to me that the PHP programmers were the kids, and the Java programmers were the adults.

Oh, and speaking of interpreted code -- isn't it fair to say that all code on your machine is interpreted? Granted -- it's not interpreted by a software interpretor -- but what particular elegance is provided by that? It speaks more to the weakness of hardware engineers than to the strength of computer scientists.

(I laughed after I wrote that.)

jcv and I have experienced significant pain as PHP applications grow. Sure, you can code in anything if the you're willing to make and follow all of your own rules (parameter passing, memory management, return conventions, data representations, mutual exclusion, etc.). We abandoned PHP for Java.

I guess that's all there is

I'm realizing finally that Unix seems to be the reigning King of Operating Systems that is actually used widely.

I remember having thoughts as a kid, that real computer folks couldn't possible use MS-DOS, which was the only thing available at the time. It was fairly obvious that the popular-culture myth of the mainframe wasn't running DOS.

I got into Unix when I accidently got a SunOS account on the local college's minicomputer, and I knew right off that Unix was Good Stuff. I played with it throughout my teenage years. I remember thinking that I wanted to be knowledgable about Unix by the time that I went to school there.

But I kinda always thought that there was something better; after all, do supercomputers run Unix? Is egrep or vi involved in the launching of missiles?

I'm in an Operating Systems course now, and even though there are lots of research ideas and halves of a real OS here and there, Unix is still the hottest thing going. And, in fact, the SGI Origin supercomputer in the department runs a Unix.

In Praise of Programming

I've known several smart people whose only programming experience came from doing CS course assignments who said that they really didn't enjoy doing programming.

Programming is building gadgets -- no, more than building gadgets -- when it's done right, programming is building gadgets and connecting them to other gadgets then using those conglomerated gadgets to build larger, more magnificent gadgets! Programming is a series of puzzles to be solved, of aesthetic design decisions, of creating spaces, of tradeoffs and balances, of pursuasive conversation, of architecture and re-architecture, of thousands of tiny discoveries. Every useful program gives its author a chance to pursue greatness, and to inflict some miniscule but absolutely perfect order on the decaying universe.

There appears to be a hierarchy of evidence for a scientific thesis: analysis, simulation, and experimentation.

• Analysis usually comes in the form of theoretical, mathematical-style modelling and proofs. The academics that I'm around seem to consider analysis to be an extremely-strong form of evidence; i.e., if you can prove it analytically, then it's gotta be true. Analysis lets you make those nice, smooth graphs.

• Simulation seems to be running programs which implement an analytical models which transform the system state as the model predicts it would through time. Simulation appears to be useful, but it's not always highly respected. For example, this crowd distrusts the popular ns-2 network simulator for many types of network experiments, because it predicts behaviors which don't happen.

• Experimentation is everybody's favorite technique for giving evidence, and it's particularly popular here for demonstrating properties of networks. Experimentation lets you test something new (e.g., a proposed active queue-management algorithm for routers) or something existing (e.g., the end-to-end behavior of traffic through Internet paths). Empirical graphs are jagged and bumpy, with spikes and dips caused by complicated and hidden real-world complexities.

Analysis is considered extremely strong because it uses formal proof techniques, but I don't really find it convincing for two reasons: (a) mathematical/theoretical-types always seem to oversimplify their model in favor of elegance and beauty instead of reality; (b) it's too easy to convince a human of something that it wants to believe. For example, if you've ever written a nontrivial program, you probably believed that it worked long before experimentation would support the theory that it actually worked.

Proofs are `strong' only because everyone wants to believe that they're strong. But there are numerous cases of published proofs standing for years, then being shown to be flawed. (E.g., some of the fundamental theorems of Real-Time Systems theory were published by Liu and Layland in 1973, but some of the proofs in it were shown to be flawed in the late 1990's.)

Donald Knuth's famous quote hilights the tension between analysis and reality:

Be careful about using the following code -- I've only proven that it works, I haven't tested it.

So it appears that the chief purpose of analysis is to simplify the life of the would-be scientist.