Slashdot Mirror

A technical book with personality? Chromatic claims just that in his review of Linux Graphics Programming with SVGAlib. If you're a graphics guru, or are looking for a book that describes a lot of the low level functions that put pretty pictures on your screen, this one sounds like one you should at least consider.

Linux Graphics Programming with SVGAlib author Jay Link pages 513 publisher Coriolis Open Press rating 7.5 reviewer chromatic ISBN 1-57610-524-5 summary A tour of the SVGAlib library, designed to help you create new Linux applications or port existing applications to Linux.

The Scoop XFree86 isn't the be-all end-all of Linux graphics. Consider the embedded space, or dedicated turnkey apps, or console games, or... Jay Link introduces readers to SVGAlib in a flawed, but entertaining and useful tutorial. (If you've never heard of SVGAlib, it's a Linux-specific graphics library providing fast functions for full-screen use, joystick and keyboard input, and even 3D. It's undergone development and refinement for a few years, and it's easy to use but still powerful.) What's to Like? More than a listing of SVGAlib functions and their uses, the author covers a wide scope of graphics topics. They're all explored in the context of SVGAlib, but the basic principles apply to other libraries. Monitors display information the same way, polygons and primitives have the same algorithms, and something has to save the background before you draw something over top of it. The first three chapters cover libraries, competing tools, graphics modes, hardware fundamentals, and the primitive primitives. It's a good introduction to graphics in general.

Starting simply, SVGAlib functions obviously build on each other. For the most part, so do the chapters. Once you've mastered setting pixels and drawing lines, it's time to draw circles and arcs or fill in your shapes. You'll want fonts after that, and then animation. Basically, this is a book you can read straight through with little trouble. Link travels a lot of ground -- input devices, 3D development, raytracing, animation, and user interfaces. Appendices B and C list and describe the vga and vgagl functions of SVGAlib. Though usually short, the descriptions have information enough to be useful to a casual programmer, often listing caveats and gotchas.

The most enjoyable part of the book, though, is the author's enthusiasm. It's obvious he had great fun in writing the book, and that shines through his prose. It's infectious -- he's found something cool and wants to share that with the world. There's room to grow, too. The last two code chapters build a simple paint utility and discuss ways it could be improved. If you've done your homework up 'til that point, you should be able to complete it and add more whizbang features at will.

What's to Consider? The author's pretty casual. It's refreshing to read a technical book with personality. If you're a big X fan, though, or a closet Microsoft sympathizer, you might disagree with Link's rhetoric in a couple of spots. Of course, those aren't the people likely to pick up the book, leaving the rest of us free to chuckle along with the personable prose.

Two things might put you off if you're considering the purchase. First, it's not precisely a tutorial. Some chapters have pages of source code with little actual commentary. If your C-reading skills are low, be prepared to do a lot of homework to figure out what's going on. Second, there's also not a lot of explanation of the math involved. In places (geometric shapes, advanced primitive drawing, ray tracing) either dig up those old trigonometry notes or a battered copy of Michael Abrash's Zen of Graphics Programming (recommended in the text). This isn't an exploration of specific graphics theory as much as an exploration of the library.

The only thing I really disliked was the book's formatting. As is usual with techie books, warnings and notes are interspersed throughout the text. In a few spots, there also are glossary-like definitions mingled with notes, text, and figures in a hard-to-read mess of words, lines, and icons. More consistency would improve the readibility. Having additional explanations would have helped, but most of the code is clear enough that the a-ha factor comes into play. (Moderately experienced programmers can read the accompanying code and description and things will click the first or second time through). The overall tone says, "Here are the tools, now go explore and play and have fun."

The Summary Somewhat experienced programmers with a decent math background will get the most out of this book. It's an entertaining look at a library I'd overlooked for quite some time. For a good introduction to SVGAlib (and a healthy dose of fun programming), check it out. Table of Contents

1. Getting Started
2. Graphics Basics
3. First Programs
4. Complex Shapes, Formulas, And Functions
5. Color
6. Shades, Fills, And Patterns
7. Fonts
8. Fractals
9. Graphic Files
10. Basic Animation
11. Polygons
12. 3D Images
13. Raytracing And Photorealism
14. Game Basics
15. Using The Mouse And Joystick
16. Landscapes
17. A Look At Existing SVGAlib Applications
18. Simple Paint Program
19. Thoughts On A GUI
20. Video Card Drivers

1. GNU General Public License
2. Libvga Functions
3. Libvgagl Functions
4. ASCII Character Codes
5. Chipsets Supported By SVGAlib
6. A Brief History of SVGAlib
7. FAQs And Troubleshooting

Purchase this book at ThinkGeek.

satch89450 asks: "I am one of the authors of the book Linux IP Stacks Commentary published by Coriolis Press. This book comments the TCP/IP code in Linux kernel 2.0.34. The history of the book is described here in detail, including our reasons for 'leapfrogging' the 2.2 releases and going right to 2.4. Yes, it's long past time to update the book, especially as kernel 2.4.0 has many, many changes in the TCP/IP code and is in test release as you read this. Our problem is how to fund the effort. Coriolis appears not to be interested in another round at this time. Heather and I are both professional writers, and that's how we make our living. Given the amount of work, donating the effort is out of the question -- it wouldn't keep kibble in the kitty bowls and have the material available in a timely fashion. We're looking for ideas." One of the largest complaints about Linux is that there is a lack of high-profile documentation. It would be sad if this publication were not made simply because of the lack of funds (which some people would see as a lack of interest) necessary to complete it.

"Doing the update as a Second Edition (even if Coriolis was on board) means that useful information wouldn't be available until sometime in 2001 -- at which time the information will be obsolete again. Based on reader feedback, that simply isn't acceptable. The format of the First Edition is incredibly hostile to incremental publication. So Heather and I have decided to start over, completely re-designing and re-writing the book from scratch, incorporate additional information that was beyond the scope of the original book, and publish it incrementally on the Web. We have figured out the mechanics: we have a rough page design, we have a start on the publishing automation tools, and we have a Web server.

Based on some suggestions (one from a /. reader) here are the options as we see them for funding this project:

1. Subscriptions: Our original idea (mentioned in our page) was to sell subscriptions to access most of the material; some material would be open to show what we do. Buyers of our book would get a discount on their first subscription, based on the fact they had bought our book. To keep overhead down, we were expecting to sell subscriptions on a quarterly and annual basis. We thought that $12/year or $4/quarter would strike a good balance. (We would also investigate how to accept subscriptions in currency other that U.S. dollars.)

2. Advertising: The old standby, banner ads, is the most distasteful option, but one that we have to consider. I've noticed that a number of Linux sites use banner ads to help fund the effort. In our page design, we want to maximize the use of Web page real estate to show code and commentary, not ads. There are a couple of issues, such as where to place the ads, that would need to be addressed, but given the page design we would incorporate the ads in the commentary, and not the code or control panes.

3. Contributions: Grants and subsidies from interested parties would help the project; if the contributions were large enough we could abandon both advertising and subscription completely and make the site open to all. We would use the Seti@Home treatment of contributions as a model, so that everyone who contributes can be recognized. Where would we put out our tin cup?

4. The Eudora Model: One mixture that might work is to mimic the model used by Qualcomm's Eudora MUA for Windows and Macintosh: display ads to those who want to use the "free" service and suppress ads for those who subscribe. This adds a little complexity (and an annoyance to the free users) but it means the information would be available to all.

I'm sure these aren't the only way to do the trick that keeps us off the street. I welcome comments, suggestions, and brick-bats from Slashdotters.

Why not 'open source' the book as well? Part of the reason Heather and I didn't try to farm out the code analysis is that we wanted to have a consistent style. Frankly, it would be as much work to accept contributions and then edit them for style and structure as it would be to do the entire job ourselves. In one sense, the book will be open source in that readers will be able to post "yellow stickies" on our commentary...and readers can see the yellow-stickies (with attribution)."

Managing software development is a job right up there with aircraft controller in the realm between fascinating and nerve-wracking. chromatic's latest review is of a book introducing one of the best known tools for managing the complexity inherent in such projects, Karl Fogel's Open Source Development with CVS.

Open Source Development with CVS author Karl Fogel pages 316 publisher Coriolis Open Press rating 8.5 reviewer chromatic ISBN 1-57610-490-7 summary More than a summary of CVS commands, Open Source Development with CVS is a study of how to organize and lead free software projects.

The Scoop Free software, the theory goes, is in a constant state of release. Instead of working in secret for years to produce a Grand Unified Model of Everything, then unleashing it on an unsuspecting world to the accompaniment of television commercials and full-page ads in trade magazines, development occurs in public view. That's aided, in no small part, by the convenience of CVS. So argues Karl Fogel in his introduction to Open Source Development with CVS. In that case, why not try it yourself?

Interspersed between CVS How-To chapters are Developer How-To chapters. For example, chapter 3 describes the author's theories on the entire Open Source process. That includes such common-sense advice as "Release something useful" and "Release something usable." There're plenty of examples to back up these ideas, drawn from the examples of large and popular open source projects.

What's to Like? CVS-specific chapters build on each other. Though 95% of the commands the average developer will ever use are covered in chapter two, the increasingly specific information just may come in handy someday. Though there's a price to pay for flexibility, the increased power it brings is worth it. If you've followed the examples and done some testing of your own, you'll have earned the title 'CVS Guru' by the end of chapter six.

Fogel's development essays take the pragmatic approach. Rather than preaching the One True Way to Do It, he analyzes several successful projects (Apache, the Linux kernel, and CVS itself being among the most prominent) and attempts to draw general principles from their histories. His overall philosophy seems to be "manage a few things well and strictly, and let your project evolve." With a good framework in place (both in your code and for your project administration), things will work smoothly and you'll be more likely to reap the benefits of the free software model.

Chapter eight gives troubleshooting tips. Fogel walks through the most common errors he's seen, doling out explanations and solutions with abandon. Chapter nine is a good reference, neatly summarizing CVS commands and files. Having completed the rest of the book -- and understanding the concepts, this section has the exact syntax at your fingertips.

What's to Consider? Though a complete reference on its own, occasionally the author defers discussion of some subjects in favor of referring to the Cederqvist manual accompanying a CVS source distribution. To be fair, these are often highly technical minutiae, but at 316 pages there is space for an expanded explanation of topics such as the RCS roots of CVS (knowing the source of CVS can help one to understand why some things are the way they are). Thankfully, there's information provided about the official FAQ and mailing lists where such data can be found. The Summary Beyond a comprehensive guide to using and administering CVS, Karl Fogel has written an easy-to-read guide on successful Open Source development. His practical focus and laid-back approach should prove workable for everything from pet projects to large undertakings. The author and Coriolis, the publisher, have also made chapters 2, 4, 6, 8, 9, and 10 available online at http://cvsbook.red-bean.com, under the GPL. Table of Contents

Purchase this book at ThinkGeek.

1. Why Open Source Development and CVS Go Together
2. An Overview of CVS
3. The Open Source Process
4. CVS Repository Administration
5. Designing for Decentralized Development
6. Advanced CVS
7. Building, Testing, and Releasing
8. Tips and Troubleshooting
9. Complete CVS Reference
10. Third-Party Tools That Work With CVS

1. CVS Maintenance and Development Today
2. GNU General Public License

Matthew Miller recently went through the RH300 training course, as well as the RHCE Certification Exam. He was kind enough to write an overview and give us his opinions on both of them, as well as his opinions on the relevance and quality of the training and the exam. Certification has been discussed extensively with regards to Linux, and here's a big scoop of food for thought.

The following was written by Slashdot Reader Matthew Miller

I'm fortunate enough to work at a place that realizes the importance of keeping employees educated and up-to-date. Since my largest current project is Linux-related, and based on Red Hat's distribution in specific, we thought it'd be worthwhile to send me to Red Hat for their RH300 course. I'm pretty familiar with Linux, but I'm a long way from knowing everything, and it's always interesting to learn what the vendor thinks are the most important parts of their product. We chose RH300 because it's the highest-level systems administration class currently offered. It's also the one linked to the RHCE exam, which was an added bonus, but learning was my main goal, not getting the certification. This is my report on the experience -- hopefully, it will help you decide if this is a good choice for you, either as a sysadmin or as an employer.

The Training Center

This course is not only available directly from Red Hat, but also from various partner organizations, including Global Knowledge, which has a training center here in Boston. However, we decided that if we were going to go to the expense of sending me, I might as well go directly to Red Hat, to increase the chances of getting a good instructor, and to insure adequate access to resources. We've had experiences in the past with third-party instructors who didn't know much beyond what was written in the materials. Of course, I don't know that this would be the case with Global Knowledge's version of RH300 -- perhaps someone else can comment on any experience they've had there.

So, it was off to the Red Hat headquarters in Durham, NC. Incidentally, I stayed in the Residence Inn there -- it was on Red Hat's site as being nearby. They didn't mention that it was on the other side of a major highway, with no provision for pedestrians to get across. Moral: stay at one of the closer hotels, or else get a car. Anyway, the RH building is very nice -- much bigger than I expected. (I suppose the IPO cash is going to good use.) Of course, as students, we weren't shown much of it -- no tour, and we weren't introduced to any of the celebrity employees. (Fair enough -- with several classes coming through every week, they'd never get anything done.) The people I did meet seemed pretty cool, and in general I got the impression that it's a fun place to work.

The classroom was about as I expected -- projection screen up front, rows of decent-enough small-brand Celeron-based systems (one per student). The machines were on a private network -- reasonable for the course, but unfortunately there was no provision for Internet access, which at the least would have been nice to have when I finished labs early.

We did have access to a breakroom with free soft drinks / juice and various snack items. This is also where the lunches were served -- to my surprise, these were quite good, and there were even decent non-meat choices.

The Teacher

The instructor was very knowledgeable -- not necessarily a complete guru, but he knew his stuff, including the "why" behind the course material. He was able to present the material in a good way, and was good at answering questions. I think the decision to go to Red Hat directly was wise; unlike a third-party consultant, he had some idea of what was going on inside of Red Hat and of their potential future plans. For example, during the section on the printing subsystem, he mentioned that they're considering a replacement for LPR in future releases -- perhaps LPRng or even CUPS. It's unlikely that someone from a different company would have had access to that kind of information.

Other Students

The other students in the course had a wide range of skills and backgrounds. I think that everyone probably met the listed better than pico. However, I could tell that some people were struggling. The instructor mentioned that the pass rate for the exam is about 65%, and I wouldn't be surprised if our class came out at that level or worse. It's not that anyone was stupid -- just that some people were out of their depth. On the other end of the spectrum, there were some people who were over-qualified: a few highly experienced sysadmins, and some folks from IBM taking the class because they are soon going to teach it.

The Course

The course was generally similar to the outline found on Red Hat's site, although I think the online information is a bit out of date. (Notice that the Web page makes reference to ipfwadm instead of ipchains or netfilter.) The eight units had slightly different names, and covered slightly different information. In the most drastic example, Unit 8, listed on the Web site as "Systems Administration and Security II", has turned into "Routers, Firewalls, Clusters and Troubleshooting". Some of the information listed in the online Unit 8 was moved into Unit 7, and some of it (cops, for instance) wasn't talked about at all. Hopefully, the online info will be updated soon.

Overall, the class went into less depth than I was hoping. Some of this was due to limitations of the lab setup -- it's a bit difficult to experiment with RAID in any meaningful way when you've only got one IDE hard drive, and obviously impossible to set up a cluster on one machine (short of running VMware). Other things where just plain introductory -- the section on the kernel, for example, focused on the steps required to build and install a new kernel, rather than being an in-depth discussion of tunable parameters. The part about Apache was similar; I was hoping to hear "You've all configured Apache before; here's things you should be aware of when you need it to do such-and-such", but the most advanced we got was setting up a virtual host. Building RPMs from source was mentioned briefly, but there was no information given on important and largely undocumented topics like --buildpolicy.

That's not to say I didn't learn anything -- the section on LVS / Piranha was enlightening even without hands-on experience, and I appreciated the part about quotas, which isn't something I've worked with much. And, I learned a large number of tiny things which add up to making the experience worthwhile to me. RPM can now do globbing over ftp! Portmap uses tcp_wrappers, but doesn't do reverse name lookups, so be sure to use IP addresses instead of names. RH Linux provides a little script called "service" that lets one avoid the tedium of typing /etc/rc.d/init.d/servicename all the time. And so on....

The "300" designation is a bit misleading. This isn't really what I'd consider an upper-level course -- it's more along the lines of SysAdmin 101. Overall, I think this class is probably worthwhile to someone with a good RH Linux background who hasn't done any systems administration. In fact, I'd even recommend it to people in that situation. On the other hand, if you've been a Linux sysadmin for a while, you'll probably be bored most of the time. It might be valuable to experienced Unix sysadmins who haven't dealt with Linux much (or even Linux admins who haven't used Red Hat Linux), but the course wasn't particularly taught from that angle and there are probably better options.

The Exam

Since I signed a confidentiality agreement, I can't talk about specific details of the test, but I will address the exam in general terms. It's a day-long three part process, with each part being worth 1/3 of the total. To pass, your overall score must be at least 80%, and you can't do worse than 50% on any one part.

One of the sections is a typical multiple-choice test, but the other two are lab based. I was quite impressed with the hands-on tests -- they are certainly what makes the RHCE meaningful. I'm not aware of any other sysadmin certifications that work this way.

For one of the lab tests, students are given a several-page specification, and must install and configure Red Hat Linux and several network services. This wasn't particularly difficult, and shouldn't be for anyone with much experience. For me, the hardest part was resisting the temptation to go beyond the spec -- since I finished the given requirements with plenty of spare time, I considered installing and setting up additional services in a way that would fit in with the listed goals. But, I decided that it'd be better to leave well-enough alone -- there's no concept of extra credit.

The other hands-on test is the cool and exciting one. Students are given preconfigured setups which are broken in some way, and given a task that must be completed. The system's problem doesn't necessarily relate directly to the task, but does interfere with it. The test-taker must find out what's wrong and correct the error. (Reinstalling packages is not allowed.) Being able to list the steps taken and to repeat the fix is important, but ultimately the test is scored on a works / doesn't work basis. One the examiner verifies that the problem is fixed, he or she wipes the system and provides another broken config.

This problem-solving section directly tests skills important to being a sysadmin in the real world; if someone has trouble with these, they're probably not ready for a systems administration job. Of course, just passing this test doesn't guarantee good problem solving skills (let alone all the other needed abilities), but it does seem a genuinely valuable indicator.

I've only two complaints with this part of the test. First, I'd make it a much larger section -- at least 50% -- and I'd increase the number of problems given so that there'd be a better sample size. The various challenges are assigned at random, and some are easier than others, and each tests knowledge of different parts of the system. The way it's done isn't bad, but it wouldn't hurt to have a lot more of it. Second, I'd give each student two computers, and make more of the problems network-related. This has logistical and cost issues (especially in places other than Red Hat's own training centers), but since many of the problems faced in the real world have to do with the way systems interact, I feel it'd be worth it.

The Exam Separated From The Course

You may have noticed that I seem a lot more excited by the exam than by the course itself. I think both are valuable, but they seemed aimed at slightly different levels. The course definitely can serve as a good review for the exam, but if you need the course, you won't do well on the test. If you're tight on cash and the certification seems valuable to you or to your employer, going straight to the exam would be reasonable. (Make sure you take a look at Red Hat's test prep page.) On the other hand, if you need to be quickly brought up to speed on the basic knowledge required of a RH Linux sysadmin, it might make sense to take this course without worrying about the test. Since RH300 is equivalent to RH033 + RH133 + RH253, this could be a much more intensive and time-efficient option.

Red Hat-Specificness

It's probably obvious, but bears mentioning anyway: this is a Red Hat Linux course and certification, not a general Linux one. I found this to be true both explicitly and implicitly. The instructor was good about saying "This is the Red Hat way of doing things -- it's possibly different on other distributions." (I found the increase-the-whole-pie attitude to be common to all of the RH employees I talked to.) There were also quite a few things that were just assumed. If you take the exam without knowing a lot about Red Hat Linux in particular, you're likely to have trouble.

This doesn't make the certification meaningless for organizations running other distributions -- many of the skills and knowledge required for the test (especially the problem solving part) are generally applicable anywhere. In fact, due to the lab-based testing process, I have more respect for this exam than I might for a multiple-choice test covering more distributions. I think this issue is a one-way sort of thing: the RHCE exam requires knowledge of Red Hat Linux, but anyone who can pass it shouldn't have much trouble picking up other flavors.

Stuff

Ok, the Web page promises that they'll give Red Hat promotional items to course participants. Yeah, well, they can do better on this front. Not even a t-shirt! C'mon, everyone gives t-shirts. Vendor shirts are a staple of my wardrobe! All we got was a mousepad, some stickers, and a baseball cap. (No chance of getting a red fedora.) Oh, and of course an official copy of the CD (with the 180 days of support). Many people in the class were surprised to learn that Red Hat doesn't sell anything from their offices -- you can't buy copies of the distro or additional merchandise. They've got a lot of students coming through there, so it seems like this could be a decent (even if relatively small) revenue stream.

A Bit About Study Guides

Before I went, I flipped through RHCE Exam Cram , the sole study guide I found at the local bookstore. Someone in the class actually purchased it and brought it with them, and I got a chance to read more of it then. I wasn't really impressed. The book was especially concerned with what it called "trick questions", and indeed its sample questions were sometimes a bit confusing -- and often poorly worded. After taking the test, I can say that this seems mostly to be a problem with the book, not something encountered on the actual exam, which was mostly straightforward and fair.

There are RHCE study guides, but I wouldn't recommend spending any money on any of them. As the course instructor told us: if you're going to pass, you'll do so even if you don't have a guide. And if you're going to fail, the guide won't be much help.

Conclusion

I think the RH300 course and RHCE certification can be valuable to both employers and individuals. The course provides a nice quick overview of the basics needed to move, for example, from being a systems operator to being an admin. I wouldn't think of it as either a requirement for the test or as something that can make someone not ready suddenly have the skills required for the exam. Since the exam is hands-on and lab based, those abilities can only come from real world experience. Looking at that from the other direction: this is exactly what makes the RHCE worth anything. While it's not a total statement on someone's talent, being able to pass is a strong indicator that they have the basic skills for a systems administration job. If I were making hiring decisions, I wouldn't make the RHCE a requirement, but I would have more confidence in applicants who have it.

How would you dip your feet in the water, learning enough to start dabbling with kernel development? Scott Maxwell might end up as the guide for a fresh batch of aspiring programmers, with his Linux Core Kernel Commentary. Starting with a lesson on the history and philosophy behind free software, you can learn enough to start contributing on your own.

Linux Core Kernel Commentary author Scott Maxwell pages 575 publisher Coriolis Open Press rating 9 reviewer chromatic ISBN 1576104699 summary In the spirit of Lions' Commentary on Unix, Scott Maxwell takes readers on a tour of the basic architecture and workings of the Linux kernel. The massive tome has nearly 40,000 lines of code from the x86/arch branches of the Linux kernel. That works out to two columns on each of over 400 pages. It's mostly free of annotations, except for small arrows referring to the commentary on that section. The commentary takes up the rest, at three columns per page. The architecture dependent functions target x86 code, and the core features (memory management, processes, scheduling, signals and threads, procfs) are covered.

What's to Like? Most interesting for me was the "a-ha!" factor. The normal chapter flow describes the subsection in general terms (memory management is designed to do such and such, with these issues), moves to the important data structure, and then walks through the vital functions for that section, stopping here and there to explain peculiarities and subtleties of the code. There's rough going in a few spots, but there are occasional moments of insight where the solutions come in to clear focus. (This happened most often for me in the SMP chapter, as the discussion of locks is particularly good.)

Maxwell manages to avoid unexplained jargon for the most part, though he invents names for implied kernel idioms. Even while dealing with highly specific topics, readers won't need a background in OS design to understand the text. Good C skills will help, as well as assembly, though the latter is explained in greater detail than the former.

The author also takes pains to point out flaws and possible optimizations in the kernel, though he often concludes that the route taken is the best for various reasons. Another theme is the tradeoffs necessary between speed, clarity, compatibility and portability. Finally, as kernel 2.4 will be out shortly, Appendix B discusses the modifications in the 2.3 tree as it went to press.

What's to Consider? As space is limited, Maxwell sometimes skips some interesting details -- especially in latter chapters. Unfortunately, phrases like "There's not room to cover this" or "that is out of the scope of this book" pop up now and then. I definitely wanted more.

Two other small nitpicks may be corrected in a future version. First, it would have been nice if the current filename was listed on each page of the source code listing, just for reference. Second, flipping back and forth between commentary and code was tricky, especially in a book of this size. Perhaps splitting things into two books would help? Serious students might find it easier to browse the code from the CD-ROM, which includes the code for kernel versions 0.01, 2.2.5, 2.2.10, 2.3.12, and the entire code of the first section, numbered as it appears.

The Summary This could serve as a textbook in an OS design class. Supplemental material will be necessary (file systems not covered for example, nor are drivers). Perhaps paired with a more theoretical text, it could form the basis of an intermediate computer science class.

The utility is not limited to students, though. Anyone wondering where to start understanding the Linux kernel would do well to consider this book.

Buy this book at ThinkGeek.

Table of Contents

1. Linux Core Kernel Code
2. Linux Core Kernel Commentary
3. 1. Introduction to Linux
   2. A First Look at the Code
   3. Kernel Architecture Overview
   4. System Initialization
   5. System Calls
   6. Signals, Interrupts, and Time
   7. Processes and Threads
   8. Memory
   9. System V IPC
   10. Symmetric Multiprocessing (SMP)
   11. Tunable Kernel Parameters
4. Appendices
5. 1. Linux 2.4
   2. GNU General Public License

Bloob writes, "It seems that Microsoft, in an apparent attempt at leveraging MCSEs to encourage organizations to upgrade to W2K, is expiring the NT4 certificate very quickly, and offering a dubious upgrade route. Here is an open letter from Keith Weiskamp, CEO of Coriolis, a supporter of MSCEs, with over 2000 comments from MCSEs et. al, and a response from Microsoft. Looks like quite a revolt."

Bloob writes, "It seems that Microsoft, in an apparent attempt at leveraging MCSEs to encourage organizations to upgrade to W2K, is expiring the NT4 certificate very quickly, and offering a dubious upgrade route. Here is an open letter from Keith Weiskamp, CEO of Coriolis, a supporter of MSCEs, with over 2000 comments from MCSEs et. al, and a response from Microsoft. Looks like quite a revolt."

SEGV has reviewed Coriolis Books title Game Architecture and Design. The book, written by Andrew Rollings and Dave Morris, is an incisive look into game development. Not just coding techniques, but it also looks at game design, architecture, process and the game industry. Click below to learn more - and perhaps be the next Carmack. Game Architecture and Design author Andrew Rollings and Dave Morris pages 742 publisher Coriolis rating 7.5/10 reviewer SEGV ISBN 1-57610-425-7 summary A rather good game development book.

A Good Game Book

Authors Andrew Rollings and Dave Morris have penned something truly rare: a good book on game development. This is the first one I have seen that I felt served the topic well.

To be sure, this is most definitely not a book on coding. Rather, it is a book on game design, architecture, process, and the industry.

Overview

The book is divided into four main parts. The first covers game design, taking you from the germ of an idea to the description of a product ready to be developed. The second discusses the formal process that will provide the proper environment for this to happen effectively. The third covers the architecture, where everything fits together. The final part, the appendices, provides detailed sample documents which the reader is invited to study.

There are case studies throughout, some of which are real, and others imaginary but illustrative. The first three parts each end with a discussion of the future of that topic, as predicted by the authors. Only time will tell if they are correct, but their views are interesting to read nonetheless.

Game Design

This was my favorite part of the book. The authors focus not just on computer games, but on software entertainment as a more general concept. To that end, they discuss such diverse influences as Aristotle's elements of drama and provide analogies with films and literature.

However, the main focus is on games, and I particularly enjoyed the applications of math and game theory to gameplay and balance. A nice touch was the discussion of emergence as it applies to the interaction of game rules.

Team Building and Management

This next part is a mini-process book embedded in a game book. This puts us on holy ground, and while I don't agree with every point the authors raise, they are for the most part on the right track. If you've read any of the gurus, you won't be surprised here. They correctly assert that the game development industry lags behind the rest of the software development industry on these points.

Game Architecture

By far, this is the largest part of the book. Although the focus is not on coding, it is here where the technical detail abounds. There are plenty of class and object diagrams, state machines, and even the odd illustrative code fragment.

There is a nice discussion of design patterns; the authors apply half of the Gang of Four patterns to game architecture. This ties in nicely with the soft architectures that are becoming more prevalent in today's games. They discuss topics as diverse as localization for foreign markets, deploying patches, and properly conducting the postmortem after a project is completed.

Appendices

The first appendix contains a collection of sample game design documents. The first is a working architecture for a project. Next are two game treatments. The fourth is a technical specification. Finally, there is a code review form and a test script.

I found these documents interesting. My main complaint is that they are all lumped together without organization. The appendix needs to be broken down. The second appendix is nicely annotated, but has an incorrect attribution.

Caveats

Notwithstanding the publisher's "to the reader" message of quality, there are some glitches, typos, and occasional errors. The authors sometimes ramble, making a section too long, but that may be a side effect of having two authors.

The diagrams are not UML, but rather modified OMT and home-brewed notation. The authors recommend learning modified OMT as they believe it is the de facto industry standard, which is no longer the case.

The CDROM contains some sample/demo software for Windows and Macintosh. It includes Python, which is nothing new for Linux users, who are left in the cold using the CDROM. The authors seem to have a love/hate relationship with Microsoft throughout the book. There's no significant mention of Linux or open source game development, not even in the future ponderings.

The book is huge, and my copy already has a cracked spine.

Summary

This book does have warts, but all in all I think it was executed rather well, given its ambition. For a game book, I give it 8/10. Make it 7/10 when compared to other technical books.

Your interests may vary, but I'd recommend this book if you are interested in game development. I think it's worth the time and effort.

Pick this book up at ThinkGeek.

Table of Contents

Part I: Game Design
1. First Concept
2. Core Design
3. Gameplay
4. Detailed Design
5. Game Balance
6. Look and Feel
7. Wrapping Up
8. The Future of Game Design
Part II: Team Building and Management
9. Current Methods of Team Management
10. Roles and Divisions
11. The Software Factory
12. Milestones and Deadlines
13. Procedures and "Process"
14. Troubleshooting
15. The Future of the Industry
Part III: Game Architecture
16. Current Development Methods
17. Initial Design
18. Use of Technology
19. Building Blocks
20. Initial Architecture Design
21. Development
22. The Run-Up to Release
23. Postmortem
24. The Future of Game Development
Part IV: Appendixes
Appendix A: Sample Game Design Documents
Appendix B: Bibliography and References
Glossary
Index

SEGV has reviewed Coriolis Books title Game Architecture and Design. The book, written by Andrew Rollings and Dave Morris, is an incisive look into game development. Not just coding techniques, but it also looks at game design, architecture, process and the game industry. Click below to learn more - and perhaps be the next Carmack. Game Architecture and Design author Andrew Rollings and Dave Morris pages 742 publisher Coriolis rating 7.5/10 reviewer SEGV ISBN 1-57610-425-7 summary A rather good game development book.

A Good Game Book

Authors Andrew Rollings and Dave Morris have penned something truly rare: a good book on game development. This is the first one I have seen that I felt served the topic well.

To be sure, this is most definitely not a book on coding. Rather, it is a book on game design, architecture, process, and the industry.

Overview

The book is divided into four main parts. The first covers game design, taking you from the germ of an idea to the description of a product ready to be developed. The second discusses the formal process that will provide the proper environment for this to happen effectively. The third covers the architecture, where everything fits together. The final part, the appendices, provides detailed sample documents which the reader is invited to study.

There are case studies throughout, some of which are real, and others imaginary but illustrative. The first three parts each end with a discussion of the future of that topic, as predicted by the authors. Only time will tell if they are correct, but their views are interesting to read nonetheless.

Game Design

This was my favorite part of the book. The authors focus not just on computer games, but on software entertainment as a more general concept. To that end, they discuss such diverse influences as Aristotle's elements of drama and provide analogies with films and literature.

However, the main focus is on games, and I particularly enjoyed the applications of math and game theory to gameplay and balance. A nice touch was the discussion of emergence as it applies to the interaction of game rules.

Team Building and Management

This next part is a mini-process book embedded in a game book. This puts us on holy ground, and while I don't agree with every point the authors raise, they are for the most part on the right track. If you've read any of the gurus, you won't be surprised here. They correctly assert that the game development industry lags behind the rest of the software development industry on these points.

Game Architecture

By far, this is the largest part of the book. Although the focus is not on coding, it is here where the technical detail abounds. There are plenty of class and object diagrams, state machines, and even the odd illustrative code fragment.

There is a nice discussion of design patterns; the authors apply half of the Gang of Four patterns to game architecture. This ties in nicely with the soft architectures that are becoming more prevalent in today's games. They discuss topics as diverse as localization for foreign markets, deploying patches, and properly conducting the postmortem after a project is completed.

Appendices

The first appendix contains a collection of sample game design documents. The first is a working architecture for a project. Next are two game treatments. The fourth is a technical specification. Finally, there is a code review form and a test script.

I found these documents interesting. My main complaint is that they are all lumped together without organization. The appendix needs to be broken down. The second appendix is nicely annotated, but has an incorrect attribution.

Caveats

Notwithstanding the publisher's "to the reader" message of quality, there are some glitches, typos, and occasional errors. The authors sometimes ramble, making a section too long, but that may be a side effect of having two authors.

The diagrams are not UML, but rather modified OMT and home-brewed notation. The authors recommend learning modified OMT as they believe it is the de facto industry standard, which is no longer the case.

The CDROM contains some sample/demo software for Windows and Macintosh. It includes Python, which is nothing new for Linux users, who are left in the cold using the CDROM. The authors seem to have a love/hate relationship with Microsoft throughout the book. There's no significant mention of Linux or open source game development, not even in the future ponderings.

The book is huge, and my copy already has a cracked spine.

Summary

This book does have warts, but all in all I think it was executed rather well, given its ambition. For a game book, I give it 8/10. Make it 7/10 when compared to other technical books.

Your interests may vary, but I'd recommend this book if you are interested in game development. I think it's worth the time and effort.

Pick this book up at ThinkGeek.

Table of Contents

Part I: Game Design
1. First Concept
2. Core Design
3. Gameplay
4. Detailed Design
5. Game Balance
6. Look and Feel
7. Wrapping Up
8. The Future of Game Design
Part II: Team Building and Management
9. Current Methods of Team Management
10. Roles and Divisions
11. The Software Factory
12. Milestones and Deadlines
13. Procedures and "Process"
14. Troubleshooting
15. The Future of the Industry
Part III: Game Architecture
16. Current Development Methods
17. Initial Design
18. Use of Technology
19. Building Blocks
20. Initial Architecture Design
21. Development
22. The Run-Up to Release
23. Postmortem
24. The Future of Game Development
Part IV: Appendixes
Appendix A: Sample Game Design Documents
Appendix B: Bibliography and References
Glossary
Index