|Page 1 of 1|
Date of review: 11-April-2000
Type Of Review: Articles/Editorials
The funny thing about UNIX is how it just doesn't stop surprising you. Even after years of using it, I still get surprises. There're just so many ways to do something and so many things to learn it is amazing.
In this respect, sitting for that IC173 paper (since discontinued) back in April 1996 did me a lot of good. It humbled me, and forced me to accept how little I knew. Derek was a genius with the UNIX command line and the UNIX/C API, and he expected no less from his students.
But he wasn't particularly good at writing down his knowledge. It seemed as if the modus operandi for the successful IC173 student was self-study, exploration, and lots of Q&A. Or at least for me, since I wasn't exactly new to C and UNIX by that time; the lectures bored me.
And I just loved to Q&A my big iron.
But a little knowledge can be dangerous. And for me, it _was_ dangerous. I didn't even buy the recommended text for the course, nor read it. Derek wasn't a particular great lecturer, and so the recommended text, which he authored, couldn't be that great. Other students shared the sentiment, so I knew I wasn't alone.
After all, I didn't really need it. By that time, I had learned to depend on the man pages and the command line itself. I was being taught by UNIX. I had discovered that almost every dang C system call (or group of them) had a man page all to itself, detailing more about it than any description in the lecture notes could afford to. You didn't need a book to understand the system when the system _was_ the book.
That meant that while I had to spend more time learning UNIX and C, I didn't quite have to put in as much effort as the IC173 bookworms out there for a silly written paper.
Or so I thought.
Weeks before, I had forced myself to read the three-thousand-line bash man page. I had spent hours going through the paragraphs again and again, trying to understand. I could digest perhaps 15% of the stuff. And nobody taking IC173 read the bash man page in its entirety. It was a waste of time. The stuff they needed to know was in the lecture notes. Distilled, filtered, processed for them, stapled nicely at the co-op. Nobody.
The paper slaughtered all of us. Right after I left the exam hall, I went straight to my big iron and
I was humiliated. The answer to the last question was staring me in the face. I had never known that such a command existed. And it was a critical missing piece without which there was no way to complete the last question in the time alloted. And that wasn't the only part of the paper I had needed more time to fill in.
Folks who never touched UNIX before reading IC173 had completed most of the paper on time. A few said it was a piece of cake. It was open book, and most of us had brought tomes with us. Few of us came empty-handed (except for the lecture notes, but lecture notes are not very helpful anyway, especially here at NUS where you actually buy them from the bookshop). I didn't believe in tomes. And in that exam hall, for the first time, I desperately needed one to learn UNIX.
I was awed. I was forced to accept that however much I explored, however quickly I could skim the man pages, however much experience I had, it was only the tip of the iceberg. There was always some corner of the system that I had no clue about, some gem that a beginner could stumble into, and some unique set of circumstances existed in which he could outperform even the most experienced UNIX gurus with his knowledge.
And then I knew. I could never finish learning UNIX. It was like a huge playground, a world all by itself. Using the UNIX command line, you were forever the curious child exploring the woods, never having to grow up. Sometimes you would figure for hours how to achieve a certain result on the command line because it was simply too troublesome through other means; like renaming a whole bunch of files, or concatenating the first few lines of all the files in a directory tree, or transferring a partition of the harddisk across the network.
You'd struggle with it, come up with a sub-optimal one-liner, and when you finally decided to go look at the man page for the associated commands you'd find that somebody had already thought of it before you, that command line switches already existed to do all the work for you, that if only you had read the manual, you could have done it with a fraction of the effort and in a fraction of the time, flexibly connecting different little commands together to form a bigger one that got the job done.
I discovered that the UNIX command line was unlike any command line I had known. It was a creative discipline all by itself, where experienced users routinely created works of art. And I had begun to understand why the UNIX man pages are so tersely written. Without that kind of completeness and conciseness, it would certainly be easier to feed the kids, but it would be impossible to feed the teenagers. UNIX gave me a deep respect for good online documentation, a respect that I would later realize was critical to the volunteer software community that I was yet to discover.
But the design of the UNIX command line, with its incredible flexibility, also awoke in me a respect for something else. I was beginning to understand how the guiding philosophies behind the general structure of a system were crucial to its success, not so much because it helped the system to meet its requirements, but because the increased flexibility gave rise to unforeseen second-order effects.
The guiding philosophies of UNIX -- small sharp tools, extreme modularity, layers, clean separation between user and kernel, among others -- had paid off handsomely, for decades proving the UNIX naysayers wrong. People would use the components of the system in ways that the original architects (or the naysayers) never intended, or perhaps even thought possible. And in a world of changing requirements and high software development cost, this flexibility was going to take or break one's software business.
I had not then known that a field existed whose purpose was to study this phenomenon and which attempted to turn this field from a black art into an engineering discipline. It is the field of software architecture. Ironically, the haphazardly-written UNIX clone that I learned the most from, Linux, and the software that revolved around it, was giving me a respect for software architecture.
It was a strange sensation, so near yet so far away. I was barely millimeters into the crust, yet little by little, I was getting closer to the core, and I could feel it.
Editor's Note: Derek, or more commonly known as A/P Derek Kiong is a lecturer in NUS. He is a Java guru and have written some interesting books (nah, I don't read'em ) like Object-Oriented Programming and Java, Compiler Technology: Tools, Translations and Language Implementation as well as Jump Start to C Programming and Unix Interface.
If you miss out Part 1 of How I Learned Linux, check this out. If you miss out Part 2, then follow this link.
Print this Review
Mail this review to your friend