Older blog entries for lindsey (starting at number 16)

28 May 2002 (updated 29 May 2002 at 00:28 UTC) »
On Academic Computer Science

Whilst I was back home a couple of weeks ago, cmiller asked whether I was as dissatisfied with Computer Science Academia as my advogato entries seem to indicate.

I've just completed my first year of graduate school in Computer Science at UNC Chapel Hill. It's been a lot of fun, but I was alarmed to realize a few facts:

  • CS grad students aren't like top CS undergrads. I was surprised to learn that many of the grad students I've met didn't study CS as undergraduates; that many of them have only been using computers for a few years; and that many of them don't even particularly like programming. My theory to explain the difference between CS undergrads and CS grad students is this: most CS undergrads who are genuinely good at making computers do things find gainful and satisfying employment.

  • ``Computer Science is embarrassed by the Computer'' There is a strong current through CS that is at once irritated by the difficulties of real-world implementations, and seeks to trivialize the value of making computers do things. In the worst cases, PhD Computer Scientists can be little more than mathematicians, ready and willing to burn years on thought experiments and research based on apparently- arbitrary assumptions. To these theoreticians, it's more important to fully explore every point along every dimension of an old problem than it is to find a new problem which might have a helpful solution. (Some other Computer Scientists claim that this isn't really CS.) Theoreticians seem to be afraid of tackling the details of real-world systems.

    I've noticed that if a professor carries a laptop, he's likely to be more realistic and do more-interesting things than otherwise.

  • Computer Science trivializes important problems. For example, Computer Security has not been considered a significant issue within CS. Nor has large-scale system configuration. These problems, CS people have said to me, are just issues of proper software engineering practice. But both of these are leading causes of operational failure in existing systems.

    Lesson: Some fields which deserve concerted CS research have not been embraced by the CS community. My theory is that CS has really solved a problem when it's not causing a problem any more for real systems and their real users. That is, it's not enough for CS types to publish some abstract descriptions of how the world should be.

So, then, why did I still enjoy a year of it, and intend to continue on further?

  • I get to have great stuff explained to me. In my first year, I've had professors carefully explain to me how some of the best-designed systems in all of CS work: the domain name system (DNS); the network file system (NFS), the Andrew File System (AFS), HTTP, TCP Congestion Control, IP, TCP, and UDP protocol operation, DiffServ, IntServ, Class-Based Queueing (CBQ), online Real-Time scheduling algorithms, MPEG audio (mp3) and video encoding, JPEG video, RTP, NTSC video encoding -- and others.

    Of course, I could have read about these myself -- and I already knew about some of them -- but there's something great about having someone carefully explain a system or an algorithm with the aid of slides, and to know that they're explaining something that's actually useful because I use them.

  • CS course provide motivation to do good things. Even CS practitioners like me can fall for the trap of believing that something is easy because we can conceptually imagine an approach to it. These are all of the programs that I imagine that I know how to write, but I don't actually go to the effort to write them. CS professors actually make me wrote some of those programs, and wrestle with the details inherent.

    I learned from undergrad CS programming assignments, but rarely very much. They weren't very hard; most of them took four hours or less, even in the senior-level classes. By constrast, graduate level programming assignments can be rough -- some take weeks of daily effort. But I implemented some neat stuff -- many parts of an operating system including distributed IPC, scheduling, and process management; a framework for distributed, fault-tolerant applications; two real-time scheduling simulators; a web server (in C); an RPC-accessible cache server; and a model checker for software validation (in ML).

  • I'm learning about scientific evaluation. CS is about identifying problems, developing solutions, and showing that the solutions actually solve the problem. This later part helps to make CS a science, but it's not something that we do naturally.

    It's about claims: if I claim that this program does something, I need to be prepared to prove it. And not just prove it to a willing accomplice. I need to be able to show that a system necessarily has certain properties. This is done with analytical proof (by developing theoretical models about which properties can be logically deduced); with simulations, and with actual experiments.

    The quality of the simulation or of the experiment matters, too -- even a skeptic should not be able to argue that my results are invalid. And the quality of your evaluation matters, too: I'm learning to be skeptical, and to require that you substantiate your claims with quality evaluation.

    Having good ideas is just the beginning.

Polished courseness

The MacOS X user interface, `Aqua', is very nicely polished; rendering seems fast and beautiful. But underneath the glitz, it leaves some things to be desired.

Examples related to debugging the system: man pages are not provided for quite everything, and the man pages that are provided are not entirely consistent with the system as sold.

No strace or truss utility is provided.

When Mac programs started with the "open" utility (i.e., gui programs) die, they don't dump core, they don't seem to log anything to the syslog facility, and there's no accessible stderr.

For example: the "Help Viewer" program seems to die any time it's opened from within another program, but I don't know of any way to figure out why it's dying. If it were an X program, I look at its stdout, or strace it to see where it's croaking.

Probably the root cause for this is that it's all relatively new to the Apple folks, and so they're having to work out the bugs. But I'm a tad bit further irritated that Apple doesn't make it easy to contact them in order to suggest that something might be a bug. I may be the only person who's tickled some of the bugs I've run into -- will they ever be fixed? How will Apple ever know that these bugs exist?

A beautiful UI is nice, but I'm not sure that it's worth the hassle of using a poorly-evolved system.

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.

26 Apr 2002 (updated 10 Oct 2002 at 17:00 UTC) »
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!

16 Apr 2002 (updated 16 Apr 2002 at 17:14 UTC) »
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.

5 Apr 2002 (updated 5 Apr 2002 at 18:47 UTC) »
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.

5 Apr 2002 (updated 5 Apr 2002 at 02:20 UTC) »
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.

7 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!