< Free Open Study >

---

Tuning and Customizing a Linux System

Daniel L. Morrill

Apress™

Copyright © 2002 Daniel L. Morrill

All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher.

1-893115-27-5

Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.

Technical Reviewer: Douglas Kilpatrick

Editorial Directors: Dan Appleman, Peter Blackburn, Gary Cornell, Jason Gilmore, Simon Hayes, Karen Watterson, John Zukowski

Managing Editor: Grace Wong

Development Editor and Indexer: Valerie Perry

Copy Editors: Kim Goodfriend, Ami Knox, Nicole LeClerc

Production Editor: Kari Brooks

Compositor: Diana Van Winkle, Van Winkle Design Group

Artist: Cara Brunk, Blue Mud Productions

Cover Designer: Kurt Krames

Manufacturing Manager: Tom Debolski

Marketing Manager: Stephanie Rodriguez

Distributed to the book trade in the United States by Springer-Verlag New York, Inc., 175 Fifth Avenue, New York, NY, 10010 and outside the United States by Springer-Verlag GmbH & Co. KG, Tiergartenstr. 17, 69112 Heidelberg, Germany.

In the United States, phone 1-800-SPRINGER, email orders@springer-ny.com, or visit http://www.springer-ny.com.

Outside the United States, fax +49 6221 345229, email orders@springer.de, or visit http://www.springer.de.

For information on translations, please contact Apress directly at 2560 9th Street, Suite 219, Berkeley, CA 94710. Phone 510-549-5930, fax: 510-549-5939, email info@apress.com, or visit http://www.apress.com.

The information in this book is distributed on an "as is" basis, without warranty. Although every precaution has been taken in the preparation of this work, neither the author nor Apress shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work.

The source code for this book is available to readers at http://www.apress.com in the Downloads section. You will need to answer questions pertaining to this book in order to successfully download the code.

To Aimee Morgan, who has always wanted to see her name in a bookstore.
This will have to do … for now.

About the Author

Dan Morrill holds a master's degree in computer science and currently works as a researcher at GE's Global Research Center in upstate New York. He is skilled in a wide variety of software development areas, from real-time and embedded systems development, to desktop applications, to web infrastructure and applications. He has been using Unix systems since 1994 and has used Linux systems exclusively since 1998. Before being Enlightened, he used other operating systems, including IBM's OS/2, Microsoft's Windows, and various Unix platforms.

Dan lives in a modest house filled with far too many toys for his own good and delights in tinkering with them all. Sometimes they even survive.

About the Technical Reviewer

Douglas Kilpatrick has been working with Unix systems since 1992 and Linux systems since 1993. While he does have a beard, he offically denies rumors that he wears suspenders. Douglas has been working in the field of computer security for the last 4 years and has taken to random fits of maniacal laughter when the subject is raised.

Acknowledgments

First, I must thank the staff at Apress, especially the editors, whose patience and professionalism are like unto angels. If true quality takes time, this had better be the best book ever written, because they certainly waited long enough.

I am also indebted to my parents, Kevin and Carolyn Morrill, who set the stage for that fateful day when the busy glow of my own computer monitor first lit upon my face. Thanks for the support, then and since.

Sometimes it seems as if much of my success was inspired by others whose talent so vastly surpassed mine. Without these people and the professional milestones to which they drove me, this book would not exist, and so I must thank: Vincent Kane, for shaming me into learning programming; Chris "Hocy" Ho, for shaming me into learning Slackware; Douglas Kilpatrick, for shaming me into learning C; Richard Arthur, for shaming me into learning software engineering; David Czarnecki, for shaming me into starting a book; and Aimee Morgan, for shaming me into completing it.

And finally, to my colleagues at GE—both current and former—I can say only this: YLB. YPM.

Section 25.253. Select: a graphical selection list

25.253. Select: a graphical selection list DOM Level 2 HTML: Node Element HTMLElement Select 25.253.1. Properties readonly Form form The <form> element that contains this <select> element. readonly long length The number of <option> elements contained by this <select> element. Same as options.length. readonly HTMLCollection options An array (HTMLCollection) of Option objects that represent the <option> elements contained in this <select> element, in the order in which they appear. See Select.options[] for further details. long selectedIndex The position of the selected option in the options array. If no options are selected, this property is -1. If multiple options are selected, this property holds the index of the first selected option. Setting the value of this property selects the specified option and deselects all other options, even if the Select object has the multiple attribute specified. When you're doing listbox selection (when size > 1), you can deselect all options by setting selectedIndex to -1. Note that changing the selection in this way does not trigger the onchange( ) event handler. readonly String type If multiple is true, this property is "select-multiple"; otherwise, it is "select-one". This property exists for compatibilty with the type property of the Input object. In addition to the properties above, Select objects also mirror HTML attributes with the following properties: Property Attribute Description boolean disabled disabled Whether the user element is disabled boolean multiple multiple Whether more than one option may be selected String name name Element name for form submission long size size The number of options to display at once long tabIndex tabindex Position of Select element in the tabbing order 25.253.2. Methods add( ) Inserts a new Option object into the options array, either by appending it at the end of the array or by inserting it before another specified option. blur( ) Takes keyboard focus away from this element. focus( ) Transfers keyboard focus to this element. remove( ) Removes the <option> element at the specified position. 25.253.3. Event Handlers onchange Invoked when the user selects or deselects an item. 25.253.4. HTML Syntax A Select element is created with a standard HTML <select> tag. Options to appear within the Select element are created with the <option> tag: <form> ... <select name="name" // A name that identifies this element; specifies name property [ size="integer" ] // Number of visible options in Select element [ multiple ] // Multiple options may be selected, if present [ onchange="handler" ] // Invoked when the selection changes > <option value="value1" [selected]>option_label1 <option value="value2" [selected]>option_label2// Other options here </select> ... </form> 25.253.5. Description The Select element represents an HTML <select> tag, which displays a graphical list of choices to the user. If the multiple attribute is present in the HTML definition of the element, the user may select any number of options from the list. If that attribute is not present, the user may select only one option, and options have a radio-button behaviorselecting one deselects whichever was previously selected. The options in a Select element may be displayed in two distinct ways. If the size attribute has a value greater than 1, or if the multiple attribute is present, they are displayed in a list box that is size lines high in the browser window. If size is smaller than the number of options, the listbox includes a scrollbar so all the options are accessible. On the other hand, if size is specified as 1 and multiple is not specified, the currently selected option is displayed on a single line, and the list of other options is made available through a drop-down menu. The first presentation style displays the options clearly but requires more space in the browser window. The second style requires minimal space but does not display alternative options as explicitly. The options[] property of the Select element is the most interesting. This is the array of Option objects that describe the choices presented by the Select element. The length property specifies the length of this array (as does options.length). See Option for details. For a Select element without the multiple attribute specified, you can determine which option is selected with the selectedIndex property. When multiple selections are allowed, however, this property tells you the index of only the first selected option. To determine the full set of selected options, you must iterate through the options[] array and check the selected property of each Option object. The options displayed by the Select element may be dynamically modified. Add a new option with the add( ) method and the Option( ) constructor; remove an option with the remove( ) method. Changes are also possible by direct manipulation of the options array. 25.253.6. See Also Form, Option, Select.options[]; Chapter 18

Comments

[Page 811 (continued)] Comments Java recognizes two types of comments. C-style comments use the same syntax found in C and C++. They are delimited by /* ... */ and //. The first set of delimiters is used to delimit a multiline comment. The Java compiler will ignore all text that occurs between /* and */. The second set of delimiters is used for a single-line comment. Java will ignore all the code on the rest of the line following a double slash (//). C-style comments are called implementation comments and are mainly used to describe the implementation of your code. Documentation comments are unique to Java. They are delimited by /** ... */. These are used mainly to describe the specification or design of the code rather than its implementation. When a file containing documentation comments is processed by the javadoc tool that comes with the Java Development Kit (JDK), the documentation comments will be incorporated into an HTML document. This is how online documentation has been created for the Java library classes. Implementation Commenting Guidelines Implementation (C-style) comments should be used to provide an overview of the code and to provide information that is not easily discernible from the code itself. They should not be used as a substitute for poorly written or poorly designed code. In general, comments should be used to improve the readability of the code. Of course, readability depends on the intended audience. Code that is easily readable by an expert programmer may be completely indecipherable to a novice. Our commenting guidelines are aimed at someone who is just learning to program in Java. [Page 812] Block Comments A block comment or comment block is a multiline comment used to describe files, methods, data structures, and algorithms: /* * Multiline comment block */ Single-Line Comments A single-line comment can be delimited either by // or by /* ... */. The // is also used to comment out a line of code that you want to skip during a particular run. The following example illustrates these uses: /* Single line comment */ System.out.println("Hello"); // End of line comment // System.out.println("Goodbye"); Note that the third line is commented out and would be ignored by the Java compiler. In this text, we generally use slashes for single-line and end-of-line comments. And we frequently use end-of-line comments to serve as a running commentary on the code itself. These types of comments serve a pedagogical purposeto teach you how the code works. In a "production environment" it would be unusual to find this kind of running commentary. Java Documentation Comments Java's online documentation has been generated by the javadoc tool that comes with the Java Development Kit (JDK). To conserve space, we use documentation comments only sparingly in the programs listed in this textbook. However, javadoc comments are used more extensively to document the online source code that accompanies the textbook. Documentation comments are placed before classes, interfaces, constructors, methods, and fields. They generally take the following form: /** * The Example class blah blah * @author J. Programmer */ public class Example { ... Note how the class definition is aligned with the beginning of the comment. Javadoc comments use special tags, such as author and param, to identify certain elements of the documentation. For details on javadoc, see: http://java.sun.com/reference/docs/index.html

COCOMO II

< Free Open Study >

COCOMO II COCOMO II is a revised and extended version of the model, built upon the original COCOMO. It more easily allows the estimation of object-oriented software, software created via spiral or evolutionary models, and applications developed from commercial-off-the-shelf software. It was created, in part, to develop software cost database and tool support capabilities for continuous model improvement and to provide a quantitative analytic framework and a set of tools and techniques for evaluating the effects of software technology improvements on software life cycle costs and schedules. During the earliest conceptual stages of a project, the model uses object point estimates to compute effort. During the early design stages, when little is known about project size or project staff, unadjusted function points are used as an input to the model. After an architecture has been selected, design and development begin with SLOC input to the model. COCOMO II provides likely ranges of estimates that represent one standard deviation around the most likely estimate. Accommodating factors that received little attention in the first version, COCOMO now adjusts for software reuse and re-engineering where automated tools are used for translation of existing software. COCOMO II also accounts for requirements volatility in its estimates. Whereas the exponent on size in the effort equations in the original COCOMO varies with the development mode, COCOMO II uses scaling factors to generalize and replace the effects of the development mode. The COCOMO II application composition model uses object points to perform estimates. The model assumes the use of integrated CASE tools for rapid prototyping. Objects include screens, reports, and modules in third-generation programming languages. The number of raw objects is estimated, the complexity of each object is estimated, and the weighted total (object-point count) is computed. The percentage of reuse and anticipated productivity is also estimated. With this information, an effort estimate can be computed. COCOMO II explicitly handles the availability of additional information in later stages of a project, the nonlinear costs of reusing software components, and the effects of several factors on the diseconomies of scale. (Some of these are the turnover rate of the staff, the geographic dispersion of the team, and the "maturity" of the development process as defined by the SEI.) The model also revises some coefficient values and eliminates discontinuities present in the old model (related to "development modes" and maintenance vs. adaptation). COCOMO II is really three different models: The application composition model� Suitable for projects built with modern GUI-builder tools. Based on new object points. The early design model� Used to get rough estimates of a project's cost and duration before the entire architecture has been determined. It uses a small set of new cost drivers and new estimating equations, and it is based on unadjusted function points or KSLOC. The post-architecture model� The most detailed COCOMO II model, to be used after the development of the project's overall architecture. It has new cost drivers, new line counting rules, and new equations. In collaboration with Rational, Inc., COCOMO II integrates phases and milestones with those of the Rational Unified Process and has provided phase and activity distribution estimators for COCOMO II.

< Free Open Study >

19.5 Configuring a Keyboard

[ Team LiB ]

19.5 Configuring a Keyboard Windows 9X/2000/XP allows you to customize some aspects of keyboard behavior. To do so, run the Keyboard applet (Start Settings Control Panel Keyboard) to display the Keyboard Properties dialog, which includes the following pages: Speed (Windows 9X/2000/XP) Includes settings for how long a key must be held down before it begins repeating and for how quickly it repeats. Also allows setting cursor blink rate, which controls how fast the virtual cursor blinks in Windows applications. Change any of these settings by dragging the associated slider. Changes take effect immediately when you click Apply or OK. Language (Windows 9X) or Input Locales (Windows 2000/XP) These pages are nearly identical except for their names. They are used to install additional keyboard languages and layouts. Windows 9X allows specifying a key sequence (either Left Alt-Shift or Ctrl-Shift) to rotate through available languages from the keyboard. Windows 2000/XP provides the same choices, and adds an optional second key sequence to jump directly to the default language using the same key sequences listed for Windows 9X, with the addition of one character, 0 through 9, tilde, or grave accent. Windows 2000/XP also allows specifying the method used to turn off Caps Lock, either by pressing the Caps Lock key or by pressing the Shift key. Hardware (Windows 2000/XP) This page displays the type of keyboard installed. It provides a Troubleshoot button, which invokes the Keyboard Troubleshooter Wizard, and a Properties button, which simply displays Device Manager properties for the keyboard. Installing a programmable keyboard and driver may install a separate management application, or may simply add pages and options to the standard Keyboard Properties dialog. For example, Figure 19-3 shows the additional page of the extended Keyboard Properties dialog that results from installing the Microsoft IntelliType Pro driver under Windows 2000. If you install a programmable keyboard, make sure to locate and explore the options its driver provides. The default driver installation for some programmable keyboards leaves some very useful options disabled or set to less-than-optimum values. Figure 19-3. The Windows 2000 Keyboard Properties dialog as modified by installing the Microsoft IntelliType Pro driver Finally, do not overlook the Accessibility Options dialog, shown in Figure 19-4 (Start Settings Control Panel Accessibility Options). This dialog is available in both Windows 9X and Windows 2000/XP. Although intended primarily to aid people with various disabilities, some options available here may be useful to anyone. In particular, anyone who has accidentally toggled Caps Lock on will appreciate the audible warning provided by ToggleKeys. Figure 19-4. The Windows XP Accessibility Options dialog Linux also provides comprehensive keyboard configuration options via the configuration utilities included with the Gnome and KDE desktop environments. Figure 19-5, for example, shows the Red Hat 8.X Gnome Keyboard Accessibility Configuration dialog, which can be accessed by running gnome-keyboard-properties from the command line or by clicking Preferences Keyboard Accessibility from the Start menu. Figure 19-5. The Linux AccessX Keyboard Accessibility Configuration dialog

[ Team LiB ]

3.6 Feedback

3.6 Feedback

Feedback is another classic engineering principle that applies to analysis and testing. Feedback applies both to the process itself (process improvement) and to individual techniques (e.g., using test histories to prioritize regression testing).

Systematic inspection and walkthrough derive part of their success from feedback. Participants in inspection are guided by checklists, and checklists are revised and refined based on experience. New checklist items may be derived from root cause analysis, analyzing previously observed failures to identify the initial errors that lead to them.

Summary

Principles constitute the core of a discipline. They form the basis of methods, techniques, methodologies and tools. They permit understanding, comparing, evaluating and extending different approaches, and they constitute the lasting basis of knowledge of a discipline.

The six principles described in this chapter are

• 
  

  Sensitivity: better to fail every time than sometimes,

  
  


• 
  

  Redundancy: making intentions explicit,

  
  


• 
  

  Restriction: making the problem easier,

  
  


• 
  

  Partition: divide and conquer,

  
  


• 
  

  Visibility: making information accessible, and

  
  


• 
  

  Feedback: applying lessons from experience in process and techniques.

  
  

Principles are identified heuristically by searching for a common denominator of techniques that apply to various problems and exploit different methods, sometimes borrowing ideas from other disciplines, sometimes observing recurrent phenomena. Potential principles are validated by finding existing and new techniques that exploit the underlying ideas. Generality and usefulness of principles become evident only with time. The initial list of principles proposed in this chapter is certainly incomplete. Readers are invited to validate the proposed principles and identify additional principles.

Further Reading

Analysis and testing is a relatively new discipline. To our knowledge, the principles underlying analysis and testing have not been discussed in the literature previously. Some of the principles advocated in this chapter are shared with other software engineering disciplines and are discussed in many books. A good introduction to software engineering principles is the third chapter of Ghezzi, Jazayeri, and Mandrioli's book on software engineering [GJM02].

Exercises

3.1	Indicate which principles guided the following choices: Use an externally readable format also for internal files, when possible. Collect and analyze data about faults revealed and removed from the code. Separate test and debugging activities; that is, separate the design and execution of test cases to reveal failures (test) from the localization and removal of the corresponding faults (debugging). Distinguish test case design from execution. Produce complete fault reports. Use information from test case design to improve requirements and design specifications. Provide interfaces for fully inspecting the internal state of a class.
3.2	A simple mechanism for augmenting fault tolerance consists of replicating computation and comparing the obtained results. Can we consider redundancy for fault tolerance an application of the redundancy principle?
3.3	A system safety specification describes prohibited behaviors (what the system must never do). Explain how specified safety properties can be viewed as an implementation of the redundancy principle.
3.4	Process visibility can be increased by extracting information about the progress of the process. Indicate some information that can be easily produced to increase process visibility.