Slashdot Mirror

rjnagle writes "I got my cubicle colleague interested in OpenOffice.org when I said, "Here's something that can convert your Word files to PDF ... for free!" By now people hip to the open source concept use OpenOffice.org for everyday applications, yet MS Office is still the predominant application in the home and workplace. Many educated people have still not heard of it. Why?" Read on for Nagle's four-part answer to that question, and his (lengthy) review of Michael Koch's Special Edition Using Star Office 6.0 -- the content applies to StarOffice's free cousin OpenOffice.org as well. Special Edition Using Star Office 6.0 author Michael Koch pages 1078 + index publisher Que rating quality: 5 stars; usability: 4 stars; weight: 1 star reviewer Robert Nagle ISBN 0789728338 summary Great for easing the transition to Openoffice/Staroffice.

First, PC makers rarely have financial inducements to preinstall open source applications, especially when it eats into their upsell margins. Second, people have a misconception that documents produced in MS Office can only be read by MS Office (a fact which leads Richard Stallman to call for an end to all Microsoft Word attachments ). Third, subsidized prices and the wide availability of instructional material ensure that teachers use these commercial products for class and give assignments requiring them. Finally, consumers switching to an open source product need confidence that the open source application has equivalent functionality and adequate documentation to reduce the learning curve.

Fortunately, a first-class user guide on OpenOffice.org/StarOffice has been written, and that book is Michael Koch's Special Edition Using StarOffice 6.0. This book, actually a second edition, covers the new version and gives fuller treatment to StarOffice writer and the HTML editor. Despite the use of "StarOffice" in the title, this book actually covers both StarOffice and OpenOffice.org in depth.

An an aside, let me compliment Que editions for the legibility and usability of layout. (Que also produced the excellent Ed Bott's Special Edition Using Microsoft Office XP). Nice readable texts, lots of boxes, tips and cautions. Every chapter finishes with a helpful troubleshooting section.

Two immediate reactions: 1) Gosh, I didn't know OpenOffice/StarOffice could do all that! I was pleasantly surprised, for example, to learn the number of graphic capabilities the program has. 2) This book covers functionality in considerable depth, with enough content to satisfy the newbie as well as the advanced user. In addition to documenting the office software, the book also includes reference sections on StarOffice Basic, using data sources, building forms and macros. It also includes a chapter on Adabas, the database that comes as part of the StarOffice package (but not with OpenOffice.org).

Koch benefits from the fact that users already start with a good conceptual framework of what MS Office products are supposed to do. The biggest conceptual challenge in moving from MS Office to Star/OpenOffice is getting used to the idea of applying styles to text instead of just clicking on an icon for formatting. MS Office actually has terrific styling capabilities (and a usable interface for managing styles),but Microsoft's friendly GUI discourages users from thinking about document structure. Contrast that to OpenOffice.org, which nudges the user more firmly towards styles. Managing the different layers of styles in OpenOffice.org can be tricky and confusing, so Koch spends a considerable amount of time and space on that. Another chapter on sharing and exchanging information with MS Office users goes into exquisite detail about compatibility and formatting losses when converting documents, as well as the StarOffice XML file format.

Cordelia of Buffy the Vampire Slayer once said, "There are books about computers? Isn't that the point of computers, to replace books?" Perhaps I am just cheap, but when evaluating a user guide, I often ask whether the online help isn't good enough. Or whether newgroups/websites/forums are adequate. Or whether the user interface is intuitive or allows you to discover a solution by just playing around. Dozens of heavy thousand-page books clutter my apartment, leading me to wonder whether the convenience of a gigantic dead-tree reference guide outweighs the increase in clutter. Every time I move to another apartment, I keep lugging those gigantic SQL and C++ books I haven't consulted for years, but feel compelled to keep around. (Contrast that with the very portable and handy Oreilly's Linux Server Hacks: 100 Industrial-Strength Tips and Tools, (reviewed on Slashdot), which covers most sysadmin tasks AND can be stashed in a backpack without causing whiplash).

For the last two months (in which I used OpenOffice.org thoroughly), I performed a little experiment. Where was the best place to find answers to my OpenOffice.org questions? I tried consulting the online help, then the book, then the newsgroups and openoffice websites. Here are the results:

1. Adding page numbers. The book had the best information, though what do you look under in the index? I eventually found it under "Numbers, Writer" (?!). Online help was useless. (The answer is to insert a footer and then insert a page number field in the footer).
2. I just created a hyperlink in the HTML editor. But the underlined style is bleeding to the text after the link. How do I stop that? Neither the book nor online help provided the answer, although the newsgroup did after 24 hours. (The answer is to press the End key or to select Format >> Default)
3. How do I create an HTML style with the stylist which specifies the background color of a table cell? (No answer from anywhere, although Koch admits that that the StarOffice HTML editor is "temperamental").
4. While drawing a flowchart on the Draw program, how do I save the entire image as a jpeg and not just the highlighted part? (By grouping the components together, the book helpfully advises. The online help offers nothing).
5. On a spreadsheet, what is the keyboard shortcut for bringing the cursor back to the left column? (Keyboard shortcuts are easy to find in the book. Couldn't find it in the online help).

Generally, the book had the most reliable and in-depth information. That was especially helpful when trying to perform a complex action (like creating a table of contents). But the majority of my inquiries had to do with using the interface, not functionality. Often the sheer size of the book made daunting the simple task of finding a function on a dialog or a keyboard shortcut.

That is the paradox of super-sized application manuals. Surely one doesn't read them from cover to cover. But after an application reaches a certain level of complexity, the software interface is no longer intuitive, and you pretty much need a book just to find things in the interface. As one who does technical writing, it may sound funny to say, but often my favorite thing about these super-size manuals are the screenshots. I can't tell you how many times I've browsed through a book and come across a dialog box I never knew existed. On the other hand, when application manuals reach a certain size, navigating through "book interfaces" becomes almost as difficult as navigating through the software interface or help system.

Online help is good when you know what you're looking for (i.e., when you have a specific search term to look for). Books are good when you don't know what you're looking for. With books, the reader can flip through pages in the general vicinity of a topic and randomly stumble upon the right information. Books allow the user to bypass the outlined hierarchy of online help and learn the appropriate terminology for describing the task (which then makes it easier to find things in the online help).

A recent visit to a technical bookstore and a large chain bookstores showed no books on the shelf for StarOffice, but dozens of books on Microsoft Office, That is too bad, because Using StarOffice 6.0 provides much-needed in-depth coverage on an application whose user base will grow as tight budgets cause companies and public sector agencies to examine open source alternatives.

* PDF conversion (as well as docbook and Flash) export are available on the OpenOffice.org 1.1 Beta 2 build.

Other OpenOffice.org Resources:

Kaaredyret has the best English language OpenOffice links page . ooodocs.org has a lively Forum for OO users. Or if you want, you can look at a PDF of the official Staroffice Documentation (400 pages)

ROBERT NAGLE (aka idiotprogrammer )is a technical writer, trainer who doesn't think that open source documentation sucks . He works for Texas Instruments in Houston, Texas. You can purchase the Special Edition Using StarOffice 6.0 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

rjnagle writes "I got my cubicle colleague interested in OpenOffice.org when I said, "Here's something that can convert your Word files to PDF ... for free!" By now people hip to the open source concept use OpenOffice.org for everyday applications, yet MS Office is still the predominant application in the home and workplace. Many educated people have still not heard of it. Why?" Read on for Nagle's four-part answer to that question, and his (lengthy) review of Michael Koch's Special Edition Using Star Office 6.0 -- the content applies to StarOffice's free cousin OpenOffice.org as well. Special Edition Using Star Office 6.0 author Michael Koch pages 1078 + index publisher Que rating quality: 5 stars; usability: 4 stars; weight: 1 star reviewer Robert Nagle ISBN 0789728338 summary Great for easing the transition to Openoffice/Staroffice.

First, PC makers rarely have financial inducements to preinstall open source applications, especially when it eats into their upsell margins. Second, people have a misconception that documents produced in MS Office can only be read by MS Office (a fact which leads Richard Stallman to call for an end to all Microsoft Word attachments ). Third, subsidized prices and the wide availability of instructional material ensure that teachers use these commercial products for class and give assignments requiring them. Finally, consumers switching to an open source product need confidence that the open source application has equivalent functionality and adequate documentation to reduce the learning curve.

Fortunately, a first-class user guide on OpenOffice.org/StarOffice has been written, and that book is Michael Koch's Special Edition Using StarOffice 6.0. This book, actually a second edition, covers the new version and gives fuller treatment to StarOffice writer and the HTML editor. Despite the use of "StarOffice" in the title, this book actually covers both StarOffice and OpenOffice.org in depth.

An an aside, let me compliment Que editions for the legibility and usability of layout. (Que also produced the excellent Ed Bott's Special Edition Using Microsoft Office XP). Nice readable texts, lots of boxes, tips and cautions. Every chapter finishes with a helpful troubleshooting section.

Two immediate reactions: 1) Gosh, I didn't know OpenOffice/StarOffice could do all that! I was pleasantly surprised, for example, to learn the number of graphic capabilities the program has. 2) This book covers functionality in considerable depth, with enough content to satisfy the newbie as well as the advanced user. In addition to documenting the office software, the book also includes reference sections on StarOffice Basic, using data sources, building forms and macros. It also includes a chapter on Adabas, the database that comes as part of the StarOffice package (but not with OpenOffice.org).

Koch benefits from the fact that users already start with a good conceptual framework of what MS Office products are supposed to do. The biggest conceptual challenge in moving from MS Office to Star/OpenOffice is getting used to the idea of applying styles to text instead of just clicking on an icon for formatting. MS Office actually has terrific styling capabilities (and a usable interface for managing styles),but Microsoft's friendly GUI discourages users from thinking about document structure. Contrast that to OpenOffice.org, which nudges the user more firmly towards styles. Managing the different layers of styles in OpenOffice.org can be tricky and confusing, so Koch spends a considerable amount of time and space on that. Another chapter on sharing and exchanging information with MS Office users goes into exquisite detail about compatibility and formatting losses when converting documents, as well as the StarOffice XML file format.

Cordelia of Buffy the Vampire Slayer once said, "There are books about computers? Isn't that the point of computers, to replace books?" Perhaps I am just cheap, but when evaluating a user guide, I often ask whether the online help isn't good enough. Or whether newgroups/websites/forums are adequate. Or whether the user interface is intuitive or allows you to discover a solution by just playing around. Dozens of heavy thousand-page books clutter my apartment, leading me to wonder whether the convenience of a gigantic dead-tree reference guide outweighs the increase in clutter. Every time I move to another apartment, I keep lugging those gigantic SQL and C++ books I haven't consulted for years, but feel compelled to keep around. (Contrast that with the very portable and handy Oreilly's Linux Server Hacks: 100 Industrial-Strength Tips and Tools, (reviewed on Slashdot), which covers most sysadmin tasks AND can be stashed in a backpack without causing whiplash).

For the last two months (in which I used OpenOffice.org thoroughly), I performed a little experiment. Where was the best place to find answers to my OpenOffice.org questions? I tried consulting the online help, then the book, then the newsgroups and openoffice websites. Here are the results:

1. Adding page numbers. The book had the best information, though what do you look under in the index? I eventually found it under "Numbers, Writer" (?!). Online help was useless. (The answer is to insert a footer and then insert a page number field in the footer).
2. I just created a hyperlink in the HTML editor. But the underlined style is bleeding to the text after the link. How do I stop that? Neither the book nor online help provided the answer, although the newsgroup did after 24 hours. (The answer is to press the End key or to select Format >> Default)
3. How do I create an HTML style with the stylist which specifies the background color of a table cell? (No answer from anywhere, although Koch admits that that the StarOffice HTML editor is "temperamental").
4. While drawing a flowchart on the Draw program, how do I save the entire image as a jpeg and not just the highlighted part? (By grouping the components together, the book helpfully advises. The online help offers nothing).
5. On a spreadsheet, what is the keyboard shortcut for bringing the cursor back to the left column? (Keyboard shortcuts are easy to find in the book. Couldn't find it in the online help).

Generally, the book had the most reliable and in-depth information. That was especially helpful when trying to perform a complex action (like creating a table of contents). But the majority of my inquiries had to do with using the interface, not functionality. Often the sheer size of the book made daunting the simple task of finding a function on a dialog or a keyboard shortcut.

That is the paradox of super-sized application manuals. Surely one doesn't read them from cover to cover. But after an application reaches a certain level of complexity, the software interface is no longer intuitive, and you pretty much need a book just to find things in the interface. As one who does technical writing, it may sound funny to say, but often my favorite thing about these super-size manuals are the screenshots. I can't tell you how many times I've browsed through a book and come across a dialog box I never knew existed. On the other hand, when application manuals reach a certain size, navigating through "book interfaces" becomes almost as difficult as navigating through the software interface or help system.

Online help is good when you know what you're looking for (i.e., when you have a specific search term to look for). Books are good when you don't know what you're looking for. With books, the reader can flip through pages in the general vicinity of a topic and randomly stumble upon the right information. Books allow the user to bypass the outlined hierarchy of online help and learn the appropriate terminology for describing the task (which then makes it easier to find things in the online help).

A recent visit to a technical bookstore and a large chain bookstores showed no books on the shelf for StarOffice, but dozens of books on Microsoft Office, That is too bad, because Using StarOffice 6.0 provides much-needed in-depth coverage on an application whose user base will grow as tight budgets cause companies and public sector agencies to examine open source alternatives.

* PDF conversion (as well as docbook and Flash) export are available on the OpenOffice.org 1.1 Beta 2 build.

Other OpenOffice.org Resources:

Kaaredyret has the best English language OpenOffice links page . ooodocs.org has a lively Forum for OO users. Or if you want, you can look at a PDF of the official Staroffice Documentation (400 pages)

ROBERT NAGLE (aka idiotprogrammer )is a technical writer, trainer who doesn't think that open source documentation sucks . He works for Texas Instruments in Houston, Texas. You can purchase the Special Edition Using StarOffice 6.0 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

rjnagle writes "When Marc Prensky asked a colleague who had just returned from a training course how it was, she replied, 'AFTRB.' (Another #$#$^&# Three Ring Binder) . In his book, Digital Game-Based Learning , Prensky, an instructional game designer and founder of games2train, argues that computer games are more effective learning tools because they sustain interest and attention in settings where people are normally bored." To follow that train of thought (or if you just liked Ender's Game), read on below for Nagle's lengthy review of the book. Digital Game Based Learning author Marc Prensky pages 442 publisher McGraw-Hill Trade rating 5/5 reviewer Robert Nagle (aka Idiotprogrammer) ISBN 0071363440 summary Visionary book on instructional design and game design.

Digital Game-Based Learning (DGBL) consists of two parts. In the first part, Prensky argues that the prevalence of video games has actually rewired our brains and made traditional learning methods less effective. In the second part, Prensky makes the case that DGBL can be used successfully by corporations to train people and offers practical advice (based on vast experience) about how to deploy game-based training methods. Throughout the book, Prensky examines aesthetic, cognitive and pedagogical questions surrounding such games and provides dozens of case studies to illustrate his points.

Prensky argues that current learning methods for young learners fail to engage learners used to interactive media. Learners now expect interactivity. Prensky writes:

Games Generation workers rarely even think of reading a manual. They'll just play with the software, hitting every key if necessary, until they figure it out. If they can't, they assume the problem is with the software, not with them--software is supposed to teach you how to use it. This attitude is almost certainly a direct result of growing up with Sega, Sony, Nintendo, and other video games where each level and monster had to be figured out by trial and error, and each trial click could lead to a hidden surprise. Games are almost all designed to teach as you go.

Prensky believes that the instructor-led classroom and the teach-test method are actually historical artifacts no more than 200 or 300 years old. The teach-test instructor-led class and its instructional methods arose partially from the rise of the printing press and the widespread availability of reading material.

Why then does the teach-test method still prevail? One reason may be the generation gap and technology gap between learners and teachers. Even technologically savvy educators have biases towards methods that worked while they were learners themselves. The way we learn is to some extent a byproduct of the cultural and technological milieu we mature in. Twenty years ago educators were extolling the virtues of reading books while youngsters (including me) were "wasting" their time before the boob tube. Nowadays, undoubtedly, there is a tension between educators pushing "media literacy" (media, in this case, often equaling conventional TV broadcasting) and students too busy making additions to their online Sims house or watching webcams of friends to care. No matter how much you may try to keep up, I once told a group of middle-aged Ukrainian teachers, your students will always be more hip to the technology than you.

This is not merely a matter of age but of comfort level. Growing up with a technology (especially at an early ago) makes using it second nature. According to the neurology and psychology research that Prensky cites, the brain reorganizes and rewires itself in response to cultural stimuli, so a child who plays videogames at night is bored at class not because of "short attention span" or bad study habits but because the child's brain has programmed itself to respond better to "twitchspeed" interactivity. Prensky cites John Bruer's statement that achieving this kind of brain reorganization requires students to spend "100 minutes a day, 5 days a week, for 5 to 10 weeks to create desired changes because "it takes sharply focused attention to rewire a brain." Then Prensky adds, "Several hours a day, five days a week, sharply focused attention--does that remind you of anything? Oh yes -video games!" (p 43) . Interestingly, Prensky cites research about how children with attention deficit disorder are using video games to retrain their brain and help them to concentrate. For the game-playing child, going to school means having to "power down" and endure teaching methods ill-suited to him. (p44).

After Sesame Street showed that you could educate children by entertaining them (and sustaining their interest), games (and sometimes even instructional technology) have focused on how to sustain this interest. In an age where pop-ups, 15-second promos and CNN updates are everywhere, it is no wonder that "gaining attention share" is the central concern. Children have learned the art of selectively being able to tune out media. How then to keep their attention? Interestingly, this concern parallels that of game developers looking for better ways to sustain gameplay.

A child once described playing educational games as "hard fun." When people are "playing," they forget inhibitions and self-consciousness to concentrate on the game's mission (i.e, "learning objectives"). When I taught English to college students overseas, I was surprised to find that one of my weakest and least confident student interacted adeptly to an immersive role-playing game with a strong English language component. From my viewpoint, she was quickly comprehending spoken dialogue and responding appropriately. From her viewpoint, she had just crossed the bridge and now could start digging for gold. Cognitive breakthroughs often require distracting activity to allow the mind to refocus (visionary Alan Kay wrote, "people have more brainstorms on the jogging path than at their desks."). Educators typically view educational gaming as useful mainly for drill and practice, but as gaming environments become more complex, edugames may be more useful in providing roundabout paths towards concepts hard to reach by traditional methods. To use just one example, computer aids allow students to manipulate data and geometric figures as a way to experiment with mathematical principles. Indeed, one of Prensky's most successful game projects, the Monkey Wrench Conspiracy, taught young learners/players how to do 3D computer design by setting them in a spaceship with a mission to make repairs before the spaceship blows up.

The most fascinating section for me was Prensky's juxtaposition of game design principles alongside instructional design principles. Even if one doesn't accept Prensky's historical analysis (and thoughtful detractors like Kurt Squier have pointed out shortcomings) or his argument that games should be more widely used for training, Prensky's theoretical overview of game design should interest people in both the education and game camps. Both game designers and instructional designers are obsessed with epistemology: how to reveal information to the player/learner in a way that sustains interest; how to use conflict to change the player/learner's behavior or attitudes; how to provide enough feedback for the player/learner to change behavior; how to present a simplified view of the world without distorting it; and how to permit freedom of exploration within the constraints of an object-oriented world or of a lesson plan. These are concerns, by the way, that also interest writers of plays and fiction, except that the "player" is split into two roles: that of character (who is controlled by the playwright/writer controls) and audience (who can emphasize and anticipate, but can't change outcomes).

Prensky's grid that maps learning content to game styles (p156) indicates that sufficient varieties of games exist to tackle any training challenge. Electronic Jeopardy style games can drill employees about company policies (and these templates are commercially available and widely used). Realistic simulation games, although probably more costly to produce, may actually reduce training costs whenever the actual equipment or training environment is expensive to begin with. Better that the potential pilot crash-land a few Flight Simulator planes, or that the combat soldier accidentally kill a few civilians within a simulation environment than for real. Prensky offers good questions for evaluating the educational value of computer games: do people using it think of themselves as players rather than students? Is the experience addictive? Does it encourage reflection? Would the game be considered "fun" by someone outside the target audience? Despite the similarities, there are important differences, Prensky would argue, between games that entertain and those that educate. For one thing, successful games require visual external action to sustain attention. But this is not needed for certain domains of learning. Games may be good for learning the process of putting together a Burger King hamburger (p264), but would a game be practical for learning Java programming? Or Freud's theory of the unconscious? It's probably not impossible to design such a game; both Java and psychoanalysis involve understanding low-level mechanisms of causation, recognizing aberrant patterns and being able to select the correct algorithm from the available repertory of solutions. Role-playing and collaborative simulations would help. But what the learner needs most is FEEDBACK, game or no game. The assumption behind Prensky's advocacy of game-based learning is that content needs "livening up" or that external motivators (like video games) are needed to drive the students toward learning. I am not questioning the value of these "external motivators." But I have to wonder whether Prensky's pedagogical approach implies that certain kinds of learning activities cannot be self-motivating. Sure, a game about Java programming might amuse the CS student, but the more crucial question (I would argue) is whether this student finds the very activity of programming in java to be "hard fun."

To Prensky's credit, he does not insist that game-based learning is the best strategy for every learning situation. Perhaps the most compelling part of the book is a discussion of more than 40 case studies where computer games have been cost-effective at training. They range from an animated courtroom game (Objection) to a customer service game (where in the world is Carmen Sandiego's Luggage?) to a Sexual Harassment gameshow and many fine examples from Prensky's own company (which can be sampled online for free). He offers helpful advice (undoubtedly gained from experience) about how trainers can launch and even manage such a project. Among his suggestions: befriend IT as soon as possible; choose urgent learning needs that are "boring, complex or difficult," and offer game-based learning in conjunction with more traditional methods and give learners the option NOT to learn via the game method. Prensky offers practical suggestions to companies with training budgets ranging from the hundreds of thousands of dollars to nothing. Although the book is two years old, it still gives a good sense of what your money can get you these days.

Critics usually argue that "e-learning" doesn't compare favorably to live teachers. That is missing the point; the real question is whether e-learning (and game-based learning) provides comparable learning at a lower cost. As e-learning and game-based learning becomes more cost-effective, Prensky predicts a fairly radical transformation of the teacher/trainer's role. To some extent, this has already occurred with the advent of collaborative and student-based learning. But trainers may spend more time choosing the best learning tool for students (or creating new ones!) than actually teaching in a classroom. Is this bad? Prensky mentions that "any teacher who can be replaced by a computer, should be." In this world of game-based learning, Prensky argues, teachers can play a vital role in ensuring that students adequately reflect on the problems or conflicts that arose during the game/learning activity. Games are good at interactivity but bad at reflection. They offer ample opportunities for learning by doing, Prensky says, but minimal opportunities for reflection. One student, asked what he learned from playing SimCity, said, "I learned that if I don't feed the people, they will starve and die." That is clearly insufficient. A good instructor can help the student explore issues more deeply: how do politicians decide about allocating resources? Does the feedback offered to politicians give an accurate reflection of society's needs and problems? What strategies worked or did not work within the context of the game? Would these strategies also work in real life? Reflection is not necessary for every learning context, but today's trainers can make sure students have enough reflection to reap the benefits of game-based learning.

Prensky's book is an excellent introduction to this exciting field. He writes superbly and has a good grasp on learning theory and software design. Although clearly an enthusiast, he never implies that DGBL is the only or best teaching method. Many of Prensky's successes involve computer games as a primary component, but computer games don't need to play a central part in a lesson to be useful for learners. For example, a student can attend a traditional foreign language class and practice at home using a computer game. Ultimately computer games may have more value as supplemental material than as primary material.

Prensky's critique of the traditional trainer is sometimes unfair, especially the "generation gap" thing. Technology is not essential for reaching younger learners (and some experts have decried its overuse). Resourcefulness, a well-designed curriculum and motivational ability trumps game-based learning every time (even Prensky would agree with that, I think).

If we accept Prensky's premise that instructional methods are somehow determined by the prevailing state of technology, one starts down the path of saying that instructional methods are subject to obsolescence. New teaching methods may be more cost-effective or more motivating, but they don't necessary repudiate the value of "old-fashioned" methods (indeed, there will come a time when DGBL will be regarded as old-fashioned, so Prensky better watch out what he says). Using teaching methods so dependent on a technology, I would argue, has the unfortunate effect of rendering teachers helpless in the wake of massive technological breakdown. If a trainer/facilitator skilled in DGBL suddenly found his classroom without Internet access, could he still train employees effectively? One of my most edifying experiences as a teacher came at a Albanian university in Vlore lacking not only computers, but also copy machines and yes, sometimes even electricity. Every day I walked to class, mentally having to plan for contingencies (no electricity, inability to obtain photocopies from a nearby shop) for the day's lessons. While I still managed to pull off some funky lessons (with battery-powered cassette players, magic markers, magazine pictures and large posterboards), I couldn't help wondering if my "innovative teaching methods" merely burdened me with more things that could go wrong. The flip side of Prensky's magnificent vision is the nightmare scenario of teachers so overwhelmed with newfangled technological aids that they opt for the tried-and-true (but technologically primitive) methods rather than risk losing a class to downtime.

Although the spectacular successes mentioned in the book were informative, it also might have been helpful to examine cases where DGBL have failed or turned out to be not particularly remarkable. Every so often, a new theory or learning method hits the world, and suddenly educators use this method whether it is appropriate or not. When is DGBL not appropriate?

When making the business case for DGBL, Prensky overlooked two important things. First, the obsolescence of technology and technological standards (and the perception of obsolescence) diminishes the value of custom-built games for corporations. This seems to be an argument for using cheaper mass-market games rather than convincing the CEO to fund an ambitious game project. Also, I'm surprised that the book didn't spend more time on one obvious advantage to DGBL: digital assessments. Computer games make it easier to verify that learners performed required tasks and to keep the performance data in digital form to demonstrate compliance. That would be a big selling point for human resources.

I've written elsewhere that as immersive games become more sophisticated and develop their own society and values, real life will start to resemble a video game and videogame prowess may become an end worth pursuing for its own sake. Now that weapons and radar systems look more like computer games, for example, military recruiters might be happy with legions of game addicts manning their battalions. As it becomes easier to gain knowledge and experience completely from computer games, the notion of having to learn things from real life will start to seem very strange.

Other Resources

Marc Prensky has put generous excerpts from the book online for free. His company website contain a lot of fun free/demo games, including (my favorite) "The Challenge." Expect it to be slashdotted for a while. You can also buy the book here.

Kurt Squire of MIT's Games-to-Teach project , has written a preceptive article, Reframing the Cultural Space of Computer and Video Games and many other things on game-based learning , including an excellent critique of Prensky's book.

Dr. Sivasailam "Thiagi" Thiagarajan writes frequently on using games for training. His Thiagi website contains lots of freebies as well as a free monthly newsletter with lots of game/training ideas.

Gamasutra has a separate section on writings about educational games. Free registration is required.

Although not explicitly about game-based learning, Steven Poole's book, Trigger Happy offers a sophisticated aesthetic analysis of videogame narratives and engagement.

Robert Nagle (aka Idiotprogrammer) is a linux nut, technical writer and trainer with a background in instructional design and game design. He works for Texas Instruments in Houston. You can purchase Digital Game Based Learning from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

rjnagle writes "The availability of HOW-TOs and newsgroups is supposed to make the sysadmin's job easier, right? Much as I am a proponent of the 'distributed learning model' for Linux, the endless searching for answers on the Web for setting up Linux RAID was getting to be a royal pain. Sure, there was a RAID how-to and an excellent newgroup, but some of the information is out of date, and the tricks suggested by people a year ago may be no longer needed today. Robert reviews the O'Reilly title Managing RAID on Linux below to see how it stacks up to HOWTOs, guesswork and anecdotal evidence. Managing RAID on Linux author Derek Vadala pages 245 publisher O'Reilly rating The best reviewer Robert Nagle (aka idiotprogrammer) ISBN 1565927303 summary This book brings RAID to the masses

A person deciding to go with RAID faces a panoply of options and gotchas. Hardware or software? How many controllers? ATA or SCSI (or ataraid)? RAID 1 or RAID 5? Which file system or distribution? Kernel options? Mdadm or raidtools? /swap or /boot on raid? Hybrid? Left or right symmetric? One poster pointed out that putting two ATA drives on the same controller could impact performance. Yikes! Didn't I do that? Upon discovering that O'Reilly had just published its Managing RAID on Linux book, looking at sample chapter , I bought the book and let my blood pressure return to normal.

RAID is one of these subjects that is really not complex; it's just very hard to find all the information in one place. This is precisely the book to solve the problem. Author Derek Vadala, sysadmin and founder of Azurance.com, an open source/security consulting firm, has gathered a lot of information and even personal anecdotes to go through the decision making process when going over to RAID. He goes step-by-step through that process, educating us about hard drives, controllers, and bottlenecks along the way. This exhaustive book may be the first to bring RAID to the masses.

Although parts of the book (RAID types, file system types) may seem already familiar to experienced Linux users, it is helpful nonetheless to have everything in a nifty little book. A section of file systems provided not only a rundown of the merits and drawbacks of each one, but also a guide to their utilities. I learned for example what "file tails" for Reiser are, and why using them causes performance to degrade after reaching 85% capacity. The book compares raidtools with mdadm as well as lovely commands like nohup mdadm -monitor -mail=paranoidsysadmin@home.com (which, if you haven't guessed, causes the system to email you RAID status reports upon boot).

People who use software RAID may skip over the chapter on RAID utilities for the leading RAID controller cards. Still, there was one interesting tidbit: Why, the author asks, do makers of controller cards put all their BIOS utilities on DOS floppies which require us to find a DOS boot disk? Seriously, how many of us carry around DOS boot disks nowadays? The book made me aware for the first time of freedos, an open source solution that solves precisely that problem.

The Software RAID stuff was pretty thorough and clarified a lot of things. The book does an excellent job in helping to identify and eliminate bottlenecks and optimizing hard drive performance (using hdparm and various monitoring commands). The anecdotes and case studies definitely clarified which RAID solution is suited for which task.

I am less impressed by the book's sections on disaster recovery and troubleshooting. Although these subjects are brought up at several places in the software RAID chapter, the book could have discussed several failure scenarios or used a fault tree (such as the famous Fault Tree in Chapter 9 of the Samba book, a marvel for any tech writer to read). The book doesn't even discuss booting with software RAID until the last 10 page of the book and then gives it only a single paragraph (even though the author acknowledges it as "one of the most frequently asked questions on the linux-raid mailing list."). Call me old-fashioned, but isn't the ability to boot into your RAID system ... kinda important? As someone who just spent a significant amount of time troubleshooting RAID booting problems in Gentoo, I for one would have liked more insight into the grub/lilo thing. Also, in the next paragraph in the last chapter on page 228, the author casually mentions that "all /boot and / partitions must be on a RAID-1." Say what? Please pity the poor newbie who religiously follows the instructions in the book but fails to read until the end. I'm not sure what the author meant by this statement, but it required a much more substantial explanation and needed to go into a much earlier chapter.

These complaints don't detract very much from this excellent book, a true O'Reilly classic and a model of clarity and helpfulness. This book provides enough knowledge to avoid the dread and uncertainty that comes with trying to tackle Linux RAID. With a book like this, a sysadmin can sleep a little easier.

Recommended Readings:

• Reliable Linux , by Iaian Campbell, Wiley and Sons, Dec 2001, ISBN: 0471070408. Gives excellent information not only about RAID but on general Linux reliability issues.
  
• Software RAID in the Linux 2.4 Kernel by Daniel Robbins. (Part Two).
  
• Linux Journal Article on Software RAID by Joe Edwards, Audin Malmin and Ron Shaker. ( Part Two).
  
• "How to do a gentoo install on software RAID" by Chris Atwood. Gentoo User Forum.

Robert Nagle (aka Idiotprogrammer )is a Texas technical writer, trainer and Linux aficionado. You can purchase Managing RAID on Linux from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

rjnagle writes "The availability of HOW-TOs and newsgroups is supposed to make the sysadmin's job easier, right? Much as I am a proponent of the 'distributed learning model' for Linux, the endless searching for answers on the Web for setting up Linux RAID was getting to be a royal pain. Sure, there was a RAID how-to and an excellent newgroup, but some of the information is out of date, and the tricks suggested by people a year ago may be no longer needed today. Robert reviews the O'Reilly title Managing RAID on Linux below to see how it stacks up to HOWTOs, guesswork and anecdotal evidence. Managing RAID on Linux author Derek Vadala pages 245 publisher O'Reilly rating The best reviewer Robert Nagle (aka idiotprogrammer) ISBN 1565927303 summary This book brings RAID to the masses

A person deciding to go with RAID faces a panoply of options and gotchas. Hardware or software? How many controllers? ATA or SCSI (or ataraid)? RAID 1 or RAID 5? Which file system or distribution? Kernel options? Mdadm or raidtools? /swap or /boot on raid? Hybrid? Left or right symmetric? One poster pointed out that putting two ATA drives on the same controller could impact performance. Yikes! Didn't I do that? Upon discovering that O'Reilly had just published its Managing RAID on Linux book, looking at sample chapter , I bought the book and let my blood pressure return to normal.

RAID is one of these subjects that is really not complex; it's just very hard to find all the information in one place. This is precisely the book to solve the problem. Author Derek Vadala, sysadmin and founder of Azurance.com, an open source/security consulting firm, has gathered a lot of information and even personal anecdotes to go through the decision making process when going over to RAID. He goes step-by-step through that process, educating us about hard drives, controllers, and bottlenecks along the way. This exhaustive book may be the first to bring RAID to the masses.

Although parts of the book (RAID types, file system types) may seem already familiar to experienced Linux users, it is helpful nonetheless to have everything in a nifty little book. A section of file systems provided not only a rundown of the merits and drawbacks of each one, but also a guide to their utilities. I learned for example what "file tails" for Reiser are, and why using them causes performance to degrade after reaching 85% capacity. The book compares raidtools with mdadm as well as lovely commands like nohup mdadm -monitor -mail=paranoidsysadmin@home.com (which, if you haven't guessed, causes the system to email you RAID status reports upon boot).

People who use software RAID may skip over the chapter on RAID utilities for the leading RAID controller cards. Still, there was one interesting tidbit: Why, the author asks, do makers of controller cards put all their BIOS utilities on DOS floppies which require us to find a DOS boot disk? Seriously, how many of us carry around DOS boot disks nowadays? The book made me aware for the first time of freedos, an open source solution that solves precisely that problem.

The Software RAID stuff was pretty thorough and clarified a lot of things. The book does an excellent job in helping to identify and eliminate bottlenecks and optimizing hard drive performance (using hdparm and various monitoring commands). The anecdotes and case studies definitely clarified which RAID solution is suited for which task.

I am less impressed by the book's sections on disaster recovery and troubleshooting. Although these subjects are brought up at several places in the software RAID chapter, the book could have discussed several failure scenarios or used a fault tree (such as the famous Fault Tree in Chapter 9 of the Samba book, a marvel for any tech writer to read). The book doesn't even discuss booting with software RAID until the last 10 page of the book and then gives it only a single paragraph (even though the author acknowledges it as "one of the most frequently asked questions on the linux-raid mailing list."). Call me old-fashioned, but isn't the ability to boot into your RAID system ... kinda important? As someone who just spent a significant amount of time troubleshooting RAID booting problems in Gentoo, I for one would have liked more insight into the grub/lilo thing. Also, in the next paragraph in the last chapter on page 228, the author casually mentions that "all /boot and / partitions must be on a RAID-1." Say what? Please pity the poor newbie who religiously follows the instructions in the book but fails to read until the end. I'm not sure what the author meant by this statement, but it required a much more substantial explanation and needed to go into a much earlier chapter.

These complaints don't detract very much from this excellent book, a true O'Reilly classic and a model of clarity and helpfulness. This book provides enough knowledge to avoid the dread and uncertainty that comes with trying to tackle Linux RAID. With a book like this, a sysadmin can sleep a little easier.

Recommended Readings:

• Reliable Linux , by Iaian Campbell, Wiley and Sons, Dec 2001, ISBN: 0471070408. Gives excellent information not only about RAID but on general Linux reliability issues.
  
• Software RAID in the Linux 2.4 Kernel by Daniel Robbins. (Part Two).
  
• Linux Journal Article on Software RAID by Joe Edwards, Audin Malmin and Ron Shaker. ( Part Two).
  
• "How to do a gentoo install on software RAID" by Chris Atwood. Gentoo User Forum.

Robert Nagle (aka Idiotprogrammer )is a Texas technical writer, trainer and Linux aficionado. You can purchase Managing RAID on Linux from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

rjnagle writes "I've always been surprised and even disappointed at my friends' lack of curiosity about Linux. Maybe geeks and slashdotters understand why Linux is so appealing, but many people simply don't have time for it. Even the more open-minded people refuse to consider Linux until it runs a lot of commercial applications (does it support Photoshop? Video games? MS Word? Etc)." Robert reviews below Linux in the Workplace, a book intended to surmount this understandable gap in knowledge. Linux in the Workplace: How to use Linux in Your Office author (Group), SSC Publishers of Linux Journal pages 300 pages publisher No Starch Press rating 3 Stars reviewer Robert Nagle ISBN 1886411867 summary A gentle introduction to KDE

Linux has failed to catch on among ordinary users because PC manufacturers have been prevented from offering dual-boot systems. Not only is partitioning and dual booting a little tricky, the OS CD that comes with a new PC is usually just a system restore, making it difficult to configure a dual-boot environment without messing up factory settings and file systems. Learning Linux has become an all-or-nothing proposition; in many cases the new user has to wipe Windows off his system for good or rely on a second machine just to get started.

The irony is that Linux has never been more user friendly, and the latest KDE desktop on my gentoo box is slicker, faster and easier to use than XP. It is becoming easier to be productive on Linux, and while university students have already discovered this, corporate IT departments who support a large number of Windows-only commercial applications tend to view open source solutions as a time burden (these are the same IT departments whose days are consumed with applying Windows patches or verifying license compliance).

The book Linux in the Workplace shows the ordinary user who has never laid eyes on Linux how to perform everyday office tasks. The book assumes that the user has a machine with Linux already installed and successfully configured. This book (which is more of an introduction to the KDE desktop than Linux itself) is easy and fun to read, and has lots of screenshots. Slashdotters might find this book a bit too basic, but it's the kind of book that a technophobe spouse or child or parent might love (and could very well appear under Christmas trees right beside the new Linux PC).

This book devotes a chapter each to talking about Open Office, Gimp, Konqueror, personal information managers, and various KDE office and email applications. Most of them are part of the KDE window manager or installed by default. This book walks a thin line between being too superficial for daily use and dwelling too much on the technical details. There are better books on The GIMP or OpenOffice, for example, but still it is nice to have introductory chapters in a single book. I found a few useful tidbits on controlling file associations, xscanimage, screen capturing and ark archiver. The book is not without a sense of humor. In a useful section on creating a GPG key, the book says "your passphrase should be rude or embarrassing ... using a naughty passphrase will remind you not to type it where others can see."

This book began with the mission to bring a simplified approach to Linux. By definition, it must exclude certain topics, either by design or because an application was not yet mature when the book was being written. The book scrupulously avoids a discussion of server applications like apache (which makes a certain sense), but it would have been nice to have a section on Evolution or mplayer (yes, a media player is an indispensable application for the bored employee) or ssh, cd burning programs, browser plugins, mozilla, crossover, irc or ftp clients.

Surprisingly, the book contains almost nothing about printing or how to install or upgrade applications. Because the book is intended for a newbie user, not a sys admin, it recommends talking to your network administrator about that. Cop out? Perhaps. But even the unskilled non-root user will have to install apps once in a while; the book would have been much better with a section on rpm managers and compiling programs from scratch.

From a sys admin's point of view, I would have liked to see a case study of an office that had actually made the switch. What problems did it encounter? How did the switch change business processes? What applications required the most time and energy for support? How did a Linux-only office manage domain authentication or interoperability? What system management tools made administration easier in a heterogenous environment?

The book raises an epistemological question about the best way to learn a new technology. Will a user who has never really performed tasks as root be able to leverage the freedom and power offered by open source? Will a user truly be comfortable with an operating system without first having experienced the agony of a bad install or frantically scouring the newsgroups for help ? This book presumes that a learner needs to be able to use normal applications before being ready to handle the admin stuff. The problem with that approach is that it depends on IT staff being near and ready to do some hand-holding. But Linux may emerge in the workplace not as a result of IT's enthusiasm but because of ordinary workers' exasperation with uniform proprietary solutions imposed by these IT departments.

In summary: A useful and friendly KDE-centric introduction to Linux for nongeeks. The lack of system administration material makes it probably too basic for slashdotters.



Also recommended:

RUTE Users' Tutorial and Exposition

A Practical Guide to Red Hat Linux 8 by Mark G. Sobell (not yet published)

Robert Nagle is a technical writer, trainer and Linux aficionado in Houston, Texas. You can purchase Linux in the Workplace from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

rjnagle writes "I've always been surprised and even disappointed at my friends' lack of curiosity about Linux. Maybe geeks and slashdotters understand why Linux is so appealing, but many people simply don't have time for it. Even the more open-minded people refuse to consider Linux until it runs a lot of commercial applications (does it support Photoshop? Video games? MS Word? Etc)." Robert reviews below Linux in the Workplace, a book intended to surmount this understandable gap in knowledge. Linux in the Workplace: How to use Linux in Your Office author (Group), SSC Publishers of Linux Journal pages 300 pages publisher No Starch Press rating 3 Stars reviewer Robert Nagle ISBN 1886411867 summary A gentle introduction to KDE

Linux has failed to catch on among ordinary users because PC manufacturers have been prevented from offering dual-boot systems. Not only is partitioning and dual booting a little tricky, the OS CD that comes with a new PC is usually just a system restore, making it difficult to configure a dual-boot environment without messing up factory settings and file systems. Learning Linux has become an all-or-nothing proposition; in many cases the new user has to wipe Windows off his system for good or rely on a second machine just to get started.

The irony is that Linux has never been more user friendly, and the latest KDE desktop on my gentoo box is slicker, faster and easier to use than XP. It is becoming easier to be productive on Linux, and while university students have already discovered this, corporate IT departments who support a large number of Windows-only commercial applications tend to view open source solutions as a time burden (these are the same IT departments whose days are consumed with applying Windows patches or verifying license compliance).

The book Linux in the Workplace shows the ordinary user who has never laid eyes on Linux how to perform everyday office tasks. The book assumes that the user has a machine with Linux already installed and successfully configured. This book (which is more of an introduction to the KDE desktop than Linux itself) is easy and fun to read, and has lots of screenshots. Slashdotters might find this book a bit too basic, but it's the kind of book that a technophobe spouse or child or parent might love (and could very well appear under Christmas trees right beside the new Linux PC).

This book devotes a chapter each to talking about Open Office, Gimp, Konqueror, personal information managers, and various KDE office and email applications. Most of them are part of the KDE window manager or installed by default. This book walks a thin line between being too superficial for daily use and dwelling too much on the technical details. There are better books on The GIMP or OpenOffice, for example, but still it is nice to have introductory chapters in a single book. I found a few useful tidbits on controlling file associations, xscanimage, screen capturing and ark archiver. The book is not without a sense of humor. In a useful section on creating a GPG key, the book says "your passphrase should be rude or embarrassing ... using a naughty passphrase will remind you not to type it where others can see."

This book began with the mission to bring a simplified approach to Linux. By definition, it must exclude certain topics, either by design or because an application was not yet mature when the book was being written. The book scrupulously avoids a discussion of server applications like apache (which makes a certain sense), but it would have been nice to have a section on Evolution or mplayer (yes, a media player is an indispensable application for the bored employee) or ssh, cd burning programs, browser plugins, mozilla, crossover, irc or ftp clients.

Surprisingly, the book contains almost nothing about printing or how to install or upgrade applications. Because the book is intended for a newbie user, not a sys admin, it recommends talking to your network administrator about that. Cop out? Perhaps. But even the unskilled non-root user will have to install apps once in a while; the book would have been much better with a section on rpm managers and compiling programs from scratch.

From a sys admin's point of view, I would have liked to see a case study of an office that had actually made the switch. What problems did it encounter? How did the switch change business processes? What applications required the most time and energy for support? How did a Linux-only office manage domain authentication or interoperability? What system management tools made administration easier in a heterogenous environment?

The book raises an epistemological question about the best way to learn a new technology. Will a user who has never really performed tasks as root be able to leverage the freedom and power offered by open source? Will a user truly be comfortable with an operating system without first having experienced the agony of a bad install or frantically scouring the newsgroups for help ? This book presumes that a learner needs to be able to use normal applications before being ready to handle the admin stuff. The problem with that approach is that it depends on IT staff being near and ready to do some hand-holding. But Linux may emerge in the workplace not as a result of IT's enthusiasm but because of ordinary workers' exasperation with uniform proprietary solutions imposed by these IT departments.

In summary: A useful and friendly KDE-centric introduction to Linux for nongeeks. The lack of system administration material makes it probably too basic for slashdotters.



Also recommended:

RUTE Users' Tutorial and Exposition

A Practical Guide to Red Hat Linux 8 by Mark G. Sobell (not yet published)

Robert Nagle is a technical writer, trainer and Linux aficionado in Houston, Texas. You can purchase Linux in the Workplace from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

rjnagle writes "I've always been surprised and even disappointed at my friends' lack of curiosity about Linux. Maybe geeks and slashdotters understand why Linux is so appealing, but many people simply don't have time for it. Even the more open-minded people refuse to consider Linux until it runs a lot of commercial applications (does it support Photoshop? Video games? MS Word? Etc)." Robert reviews below Linux in the Workplace, a book intended to surmount this understandable gap in knowledge. Linux in the Workplace: How to use Linux in Your Office author (Group), SSC Publishers of Linux Journal pages 300 pages publisher No Starch Press rating 3 Stars reviewer Robert Nagle ISBN 1886411867 summary A gentle introduction to KDE

Linux has failed to catch on among ordinary users because PC manufacturers have been prevented from offering dual-boot systems. Not only is partitioning and dual booting a little tricky, the OS CD that comes with a new PC is usually just a system restore, making it difficult to configure a dual-boot environment without messing up factory settings and file systems. Learning Linux has become an all-or-nothing proposition; in many cases the new user has to wipe Windows off his system for good or rely on a second machine just to get started.

The irony is that Linux has never been more user friendly, and the latest KDE desktop on my gentoo box is slicker, faster and easier to use than XP. It is becoming easier to be productive on Linux, and while university students have already discovered this, corporate IT departments who support a large number of Windows-only commercial applications tend to view open source solutions as a time burden (these are the same IT departments whose days are consumed with applying Windows patches or verifying license compliance).

The book Linux in the Workplace shows the ordinary user who has never laid eyes on Linux how to perform everyday office tasks. The book assumes that the user has a machine with Linux already installed and successfully configured. This book (which is more of an introduction to the KDE desktop than Linux itself) is easy and fun to read, and has lots of screenshots. Slashdotters might find this book a bit too basic, but it's the kind of book that a technophobe spouse or child or parent might love (and could very well appear under Christmas trees right beside the new Linux PC).

This book devotes a chapter each to talking about Open Office, Gimp, Konqueror, personal information managers, and various KDE office and email applications. Most of them are part of the KDE window manager or installed by default. This book walks a thin line between being too superficial for daily use and dwelling too much on the technical details. There are better books on The GIMP or OpenOffice, for example, but still it is nice to have introductory chapters in a single book. I found a few useful tidbits on controlling file associations, xscanimage, screen capturing and ark archiver. The book is not without a sense of humor. In a useful section on creating a GPG key, the book says "your passphrase should be rude or embarrassing ... using a naughty passphrase will remind you not to type it where others can see."

This book began with the mission to bring a simplified approach to Linux. By definition, it must exclude certain topics, either by design or because an application was not yet mature when the book was being written. The book scrupulously avoids a discussion of server applications like apache (which makes a certain sense), but it would have been nice to have a section on Evolution or mplayer (yes, a media player is an indispensable application for the bored employee) or ssh, cd burning programs, browser plugins, mozilla, crossover, irc or ftp clients.

Surprisingly, the book contains almost nothing about printing or how to install or upgrade applications. Because the book is intended for a newbie user, not a sys admin, it recommends talking to your network administrator about that. Cop out? Perhaps. But even the unskilled non-root user will have to install apps once in a while; the book would have been much better with a section on rpm managers and compiling programs from scratch.

From a sys admin's point of view, I would have liked to see a case study of an office that had actually made the switch. What problems did it encounter? How did the switch change business processes? What applications required the most time and energy for support? How did a Linux-only office manage domain authentication or interoperability? What system management tools made administration easier in a heterogenous environment?

The book raises an epistemological question about the best way to learn a new technology. Will a user who has never really performed tasks as root be able to leverage the freedom and power offered by open source? Will a user truly be comfortable with an operating system without first having experienced the agony of a bad install or frantically scouring the newsgroups for help ? This book presumes that a learner needs to be able to use normal applications before being ready to handle the admin stuff. The problem with that approach is that it depends on IT staff being near and ready to do some hand-holding. But Linux may emerge in the workplace not as a result of IT's enthusiasm but because of ordinary workers' exasperation with uniform proprietary solutions imposed by these IT departments.

In summary: A useful and friendly KDE-centric introduction to Linux for nongeeks. The lack of system administration material makes it probably too basic for slashdotters.



Also recommended:

RUTE Users' Tutorial and Exposition

A Practical Guide to Red Hat Linux 8 by Mark G. Sobell (not yet published)

Robert Nagle is a technical writer, trainer and Linux aficionado in Houston, Texas. You can purchase Linux in the Workplace from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

rjnagle writes "I've always been surprised and even disappointed at my friends' lack of curiosity about Linux. Maybe geeks and slashdotters understand why Linux is so appealing, but many people simply don't have time for it. Even the more open-minded people refuse to consider Linux until it runs a lot of commercial applications (does it support Photoshop? Video games? MS Word? Etc)." Robert reviews below Linux in the Workplace, a book intended to surmount this understandable gap in knowledge. Linux in the Workplace: How to use Linux in Your Office author (Group), SSC Publishers of Linux Journal pages 300 pages publisher No Starch Press rating 3 Stars reviewer Robert Nagle ISBN 1886411867 summary A gentle introduction to KDE

Linux has failed to catch on among ordinary users because PC manufacturers have been prevented from offering dual-boot systems. Not only is partitioning and dual booting a little tricky, the OS CD that comes with a new PC is usually just a system restore, making it difficult to configure a dual-boot environment without messing up factory settings and file systems. Learning Linux has become an all-or-nothing proposition; in many cases the new user has to wipe Windows off his system for good or rely on a second machine just to get started.

The irony is that Linux has never been more user friendly, and the latest KDE desktop on my gentoo box is slicker, faster and easier to use than XP. It is becoming easier to be productive on Linux, and while university students have already discovered this, corporate IT departments who support a large number of Windows-only commercial applications tend to view open source solutions as a time burden (these are the same IT departments whose days are consumed with applying Windows patches or verifying license compliance).

The book Linux in the Workplace shows the ordinary user who has never laid eyes on Linux how to perform everyday office tasks. The book assumes that the user has a machine with Linux already installed and successfully configured. This book (which is more of an introduction to the KDE desktop than Linux itself) is easy and fun to read, and has lots of screenshots. Slashdotters might find this book a bit too basic, but it's the kind of book that a technophobe spouse or child or parent might love (and could very well appear under Christmas trees right beside the new Linux PC).

This book devotes a chapter each to talking about Open Office, Gimp, Konqueror, personal information managers, and various KDE office and email applications. Most of them are part of the KDE window manager or installed by default. This book walks a thin line between being too superficial for daily use and dwelling too much on the technical details. There are better books on The GIMP or OpenOffice, for example, but still it is nice to have introductory chapters in a single book. I found a few useful tidbits on controlling file associations, xscanimage, screen capturing and ark archiver. The book is not without a sense of humor. In a useful section on creating a GPG key, the book says "your passphrase should be rude or embarrassing ... using a naughty passphrase will remind you not to type it where others can see."

This book began with the mission to bring a simplified approach to Linux. By definition, it must exclude certain topics, either by design or because an application was not yet mature when the book was being written. The book scrupulously avoids a discussion of server applications like apache (which makes a certain sense), but it would have been nice to have a section on Evolution or mplayer (yes, a media player is an indispensable application for the bored employee) or ssh, cd burning programs, browser plugins, mozilla, crossover, irc or ftp clients.

Surprisingly, the book contains almost nothing about printing or how to install or upgrade applications. Because the book is intended for a newbie user, not a sys admin, it recommends talking to your network administrator about that. Cop out? Perhaps. But even the unskilled non-root user will have to install apps once in a while; the book would have been much better with a section on rpm managers and compiling programs from scratch.

From a sys admin's point of view, I would have liked to see a case study of an office that had actually made the switch. What problems did it encounter? How did the switch change business processes? What applications required the most time and energy for support? How did a Linux-only office manage domain authentication or interoperability? What system management tools made administration easier in a heterogenous environment?

The book raises an epistemological question about the best way to learn a new technology. Will a user who has never really performed tasks as root be able to leverage the freedom and power offered by open source? Will a user truly be comfortable with an operating system without first having experienced the agony of a bad install or frantically scouring the newsgroups for help ? This book presumes that a learner needs to be able to use normal applications before being ready to handle the admin stuff. The problem with that approach is that it depends on IT staff being near and ready to do some hand-holding. But Linux may emerge in the workplace not as a result of IT's enthusiasm but because of ordinary workers' exasperation with uniform proprietary solutions imposed by these IT departments.

In summary: A useful and friendly KDE-centric introduction to Linux for nongeeks. The lack of system administration material makes it probably too basic for slashdotters.



Also recommended:

RUTE Users' Tutorial and Exposition

A Practical Guide to Red Hat Linux 8 by Mark G. Sobell (not yet published)

Robert Nagle is a technical writer, trainer and Linux aficionado in Houston, Texas. You can purchase Linux in the Workplace from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.