DOCSLIB.ORG

This Book Doesn't Tell You How to Write Faster Code, Or How to Write Code with Fewer Memory Leaks, Or Even How to Debug Code at All

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Practical Development Environments By Matthew B. Doar ............................................... Publisher: O'Reilly Pub Date: September 2005 ISBN: 0-596-00796-5 Pages: 328 Table of Contents | Index This book doesn't tell you how to write faster code, or how to write code with fewer memory leaks, or even how to debug code at all. What it does tell you is how to build your product in better ways, how to keep track of the code that you write, and how to track the bugs in your code. Plus some more things you'll wish you had known before starting a project. Practical Development Environments is a guide, a collection of advice about real development environments for small to medium-sized projects and groups. Each of the chapters considers a different kind of tool - tools for tracking versions of files, build tools, testing tools, bug-tracking tools, tools for creating documentation, and tools for creating packaged releases. Each chapter discusses what you should look for in that kind of tool and what to avoid, and also describes some good ideas, bad ideas, and annoying experiences for each area. Specific instances of each type of tool are described in enough detail so that you can decide which ones you want to investigate further. Developers want to write code, not maintain makefiles. Writers want to write content instead of manage templates. IT provides machines, but doesn't have time to maintain all the different tools. Managers want the product to move smoothly from development to release, and are interested in tools to help this happen more often. Whether as a full-time position or just because they are helpful, all projects have toolsmiths: making choices about tools, installing them, and then maintaining the tools that everyone else depends upon. This book is especially for everyone who ends up being a toolsmith for his or her group. Practical Development Environments By Matthew B. Doar ............................................... Publisher: O'Reilly Pub Date: September 2005 ISBN: 0-596-00796-5 Pages: 328 Table of Contents | Index Dedication Copyright Preface What This Book Is About What This Book Is Not About Who Should Read This Book What's Inside Style Conventions Using Code Examples Safari Enabled Comments and Questions Acknowledgments Chapter 1. Introduction Section 1.1. Developing Software Products Section 1.2. Open and Closed Software Development Section 1.3. Dirty Secrets of Software Projects Section 1.4. What Does "Practical" Mean? Section 1.5. A Personal Tools Quiz Chapter 2. Project Basics Section 2.1. The Parts of a Project Section 2.2. Software Configuration Management Section 2.3. Building Software Section 2.4. Testing Software Section 2.5. Tracking Bugs Section 2.6. Writing Documentation Section 2.7. Releasing Products Section 2.8. Maintenance Section 2.9. Recommended Tools Chapter 3. Project Concepts Section 3.1. Preconstructed Development Environments Section 3.2. Why Integration Is Helpful Section 3.3. Why Automation Is Vital Section 3.4. Automation Environments Section 3.5. Labeling Builds Section 3.6. Naming Projects and Machines Section 3.7. Choosing New Tools Section 3.8. Internationalization and Localization Section 3.9. Authentication, Authorization, and Accounting Chapter 4. Software Configuration Management Section 4.1. Why Do I Need SCM? Section 4.2. What SCM Is and Is Not Section 4.3. Drawbacks of SCM Section 4.4. A Typical Day's Work with SCM Section 4.5. SCM Annoyances Section 4.6. SCM Tools Section 4.7. Comparison of SCM Tools Section 4.8. Wider Uses of SCM Section 4.9. Checklist Chapter 5. Building Software Section 5.1. How Software Gets Built Section 5.2. Build States: Virgin, Up-to-date, Changed, Interrupted, Clean Section 5.3. Build Dependencies Section 5.4. Common Build Problems Section 5.5. Build Tools Section 5.6. Comparison of Build Tools Section 5.7. Changing Your Build Tool Section 5.8. Checklist Chapter 6. Testing Software Section 6.1. Different Kinds of Tests Section 6.2. Why Automate Your Tests? Section 6.3. Evaluating Test Environments Section 6.4. Test Environments Section 6.5. Types of Test Tools Section 6.6. The Difficult Parts of Testing Section 6.7. Checklist Chapter 7. Tracking Bugs Section 7.1. Tool Requirements Section 7.2. Bug Tracking Tools Section 7.3. Bug Tracking Annoyances Section 7.4. Integrating with SCM Tools Section 7.5. Checklist Chapter 8. Documentation Environments Section 8.1. Technical Documentation Section 8.2. Documents and SCM Section 8.3. File Formats for Documentation Section 8.4. Documentation Environments Section 8.5. More File Formats Section 8.6. Automated Production of Documentation Section 8.7. Bad Ideas for Documentation Section 8.8. Internal Project Documentation Section 8.9. Checklist Chapter 9. Releasing Products Section 9.1. Overview Section 9.2. Before the Release Section 9.3. Creating the Release Section 9.4. Packaging Formats Section 9.5. Installation Tools Section 9.6. Installation IrritationsShip Happens! Section 9.7. After the Release Section 9.8. Checklist Chapter 10. Maintenance Section 10.1. Maintaining an Environment Section 10.2. What Is Product Maintenance? Section 10.3. Product Maintenance Tasks Section 10.4. Product Maintenance and Development Environments Section 10.5. Cleaning Up Your Environment Section 10.6. Checklist Chapter 11. Project Communication Section 11.1. Tools for Communication Section 11.2. A Project Web Site Section 11.3. Different Areas for the Project Web Site Section 11.4. Creating the Web Site Section 11.5. Avoiding Content Rot Chapter 12. Politics and People Section 12.1. The Role of the Toolsmith Section 12.2. When Good Projects Go Bad Section 12.3. Awkward People Section 12.4. Twisted Communications Section 12.5. Commit Rights Section 12.6. Automation Discipline Section 12.7. What Do Developers Really Want? Section 12.8. An Upbeat Ending Appendix A. How Tools Scale Section A.1. Scaling of Compilers Section A.2. Scaling of Build Tools Appendix B. Resources Section B.1. Online Section B.2. Magazines Section B.3. Books Section B.4. Conferences Section B.5. University and College Courses Colophon Index Dedication To all the toolsmiths who haven't yet found a name for what they do Copyright © 2005 O'Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O'Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://safari.oreilly.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. The O'Reilly logo is a registered trademark of O'Reilly Media, Inc. The Theory in Practice series designations, Practical Development Environments, and related trade dress are trademarks of O'Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O'Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. Preface A good technical environment for developing your software can make or break a project, or even a company. What goes into a good technical development environment? This book contains helpful answers to that question and describes some of the current tools that can help provide a good software development environment. Areas covered include: version control, build tools, testing tools, bug tracking systems, documentation, release, and maintenance. What This Book Is About A development environment is the whole collection of tools that people use to create software, not just a few tools that are specific to a particular programming language. Examples of these tools are version control tools such as CVS, build tools such as make, and bug tracking tools such as Bugzilla. Practical development environments are the environments that are really used by successful projects, and are consequently reused for many different projects. Just as there is a wide range of productivity for different programmers, there is a wide range of productivity for different projects, and that's often due to differences in development environments. This book is a guidea collection of advice about real development environments. Each of the core chapters considers a different kind of tool: tools for tracking versions of files, build tools, testing tools, bug tracking tools, and tools for creating documentation. Each chapter discusses what you should look for in each kind of tool and what to avoid, and also describes some good ideas, bad ideas, and annoyances for each development activity. Specific instances of each type of tool are described in detail so that you can decide which ones you want to investigate further. The tools described in this book are mostly intended for small to medium-sized projects, up to around 200 developers. However, the concepts and concerns described in each chapter are equally valid for large projects. One of the key ideas throughout this book is to automate wherever possible, and this becomes even more important as a project grows. Finally, this book recognizes that some progress is better than none, and encourages you to take even the smallest steps to improve your own development environment. What This Book Is Not About This book is not about a set of abstract concepts, patterns, or a single way of doing things. It is a collection of practical, commonsense advicethe kind of ideas that you wish you had thought of before the project began.
Recommended publications
  • Source Code Trees in the VALLEY of THE

    Source Code Trees in the VALLEY of THE

    PROGRAMMING GNOME Source code trees IN THE VALLEY OF THE CODETHORSTEN FISCHER So you’ve just like the one in Listing 1. Not too complex, eh? written yet another Unfortunately, creating a Makefile isn’t always the terrific GNOME best solution, as assumptions on programs program. Great! But locations, path names and others things may not be does it, like so many true in all cases, forcing the user to edit the file in other great programs, order to get it to work properly. lack something in terms of ease of installation? Even the Listing 1: A simple Makefile for a GNOME 1: CC=/usr/bin/gcc best and easiest to use programs 2: CFLAGS=`gnome-config —cflags gnome gnomeui` will cause headaches if you have to 3: LDFLAGS=`gnome-config —libs gnome gnomeui` type in lines like this, 4: OBJ=example.o one.o two.o 5: BINARIES=example With the help of gcc -c sourcee.c gnome-config —libs —cflags 6: gnome gnomeui gnomecanvaspixbuf -o sourcee.o 7: all: $(BINARIES) Automake and Autoconf, 8: you can create easily perhaps repeated for each of the files, and maybe 9: example: $(OBJ) with additional compiler flags too, only to then 10: $(CC) $(LDFLAGS) -o $@ $(OBJ) installed source code demand that everything is linked. And at the end, 11: do you then also have to copy the finished binary 12: .c.o: text trees. Read on to 13: $(CC) $(CFLAGS) -c $< manually into the destination directory? Instead, 14: find out how. wouldn’t you rather have an easy, portable and 15: clean: quick installation process? Well, you can – if you 16: rm -rf $(OBJ) $(BINARIES) know how.
  • Red Hat Enterprise Linux 6 Developer Guide

    Red Hat Enterprise Linux 6 Developer Guide

    Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Dave Brolley William Cohen Roland Grunberg Aldy Hernandez Karsten Hopp Jakub Jelinek Developer Guide Jeff Johnston Benjamin Kosnik Aleksander Kurtakov Chris Moller Phil Muldoon Andrew Overholt Charley Wang Kent Sebastian Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Edition 0 Author Dave Brolley [email protected] Author William Cohen [email protected] Author Roland Grunberg [email protected] Author Aldy Hernandez [email protected] Author Karsten Hopp [email protected] Author Jakub Jelinek [email protected] Author Jeff Johnston [email protected] Author Benjamin Kosnik [email protected] Author Aleksander Kurtakov [email protected] Author Chris Moller [email protected] Author Phil Muldoon [email protected] Author Andrew Overholt [email protected] Author Charley Wang [email protected] Author Kent Sebastian [email protected] Editor Don Domingo [email protected] Editor Jacquelynn East [email protected] Copyright © 2010 Red Hat, Inc. and others. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
  • ROBERT BURNS and PASTORAL This Page Intentionally Left Blank Robert Burns and Pastoral

    ROBERT BURNS and PASTORAL This Page Intentionally Left Blank Robert Burns and Pastoral

    ROBERT BURNS AND PASTORAL This page intentionally left blank Robert Burns and Pastoral Poetry and Improvement in Late Eighteenth-Century Scotland NIGEL LEASK 1 3 Great Clarendon Street, Oxford OX26DP Oxford University Press is a department of the University of Oxford. It furthers the University’s objective of excellence in research, scholarship, and education by publishing worldwide in Oxford New York Auckland Cape Town Dar es Salaam Hong Kong Karachi Kuala Lumpur Madrid Melbourne Mexico City Nairobi New Delhi Shanghai Taipei Toronto With offices in Argentina Austria Brazil Chile Czech Republic France Greece Guatemala Hungary Italy Japan Poland Portugal Singapore South Korea Switzerland Thailand Turkey Ukraine Vietnam Oxford is a registered trade mark of Oxford University Press in the UK and in certain other countries Published in the United States by Oxford University Press Inc., New York # Nigel Leask 2010 The moral rights of the author have been asserted Database right Oxford University Press (maker) First published 2010 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, without the prior permission in writing of Oxford University Press, or as expressly permitted by law, or under terms agreed with the appropriate reprographics rights organization. Enquiries concerning reproduction outside the scope of the above should be sent to the Rights Department, Oxford University Press, at the address above You must not circulate this book in any other binding or cover and you must impose the same condition on any acquirer British Library Cataloguing in Publication Data Data available Library of Congress Cataloging in Publication Data Data available Typeset by SPI Publisher Services, Pondicherry, India Printed in Great Britain on acid-free paper by MPG Books Group, Bodmin and King’s Lynn ISBN 978–0–19–957261–8 13579108642 In Memory of Joseph Macleod (1903–84), poet and broadcaster This page intentionally left blank Acknowledgements This book has been of long gestation.
  • Buildbot: a Continuous Integration System

    Buildbot: a Continuous Integration System

    Buildbot: A continuous integration system Krzysztof Voss January, 2013 Outline • Testing and Continuous Integration • Introduction to Buildbot • BuildMaster • BuildMaster components • BuildSlave • Installation and Usage 1 Testing and continuous integration Tests: • the best specification • safety-net for refactoring • bug identification Tests are the most effective if we: • run them often • run them on different machines/environments • can easily see their results 2 The most straightforward approach would entail: • logging in to different machines • fetching the newest source code • running tests • analyzing their output In case we want to test a few environments, repeating the above steps is tedious. Developers do not focus on the code, instead they run tests. A continuous integration system performs all of these steps for us, so developers can focus on their code. 3 Introduction to Buildbot: Features • run builds on a variety of BuildSlave platforms • arbitrary build process: handles projects using C, Python, . • minimal host requirements: python and Twisted • BuildSlave can be behind a firewall if they can still do checkout • status delivery through web page, email, IRC, other protocols • track builds in progress, provide estimated completion time • flexible configuration by subclassing generic build process classes 4 • debug tools to force a new build, submit fake Changes, query BuildSlave status • released under the GPL source: http://buildbot.net/buildbot/docs/current/manual/introduction.html 5 Introduction to Buildbot: Overview system overview source: http://buildbot.net/buildbot/docs/0.8.1/full.html 6 BuildMaster BuildMaster components source: http://buildbot.net/buildbot/docs/0.8.1/full.html 7 BuildMaster BuildMaster: • holds the configuration of the entire system.
  • Chapter 4: Forges

    Chapter 4: Forges

    Chapter 4: Forges Josep M. Rib´o October 15, 2010 INDEX Chapter 4: Forges 4.1 Introduction • Repositories (forges) • Repositories of repositories 4.2 Sourceforge.net 4.3 Google code 4.4 Trac 1 4.1 Introduction INDEX 4.1 Introduction A project repository (aka a forge) is a web platform that offers project hosting and infrastructure to develop an open source project following the bazaar-model This infrastructure includes: • Version control system • Bug/issue tracker • Mail lists • Monitoring tools • Software downloading tools.... A repository of repositories (aka RoRs) is a repository that aggregates projects from other repositories or private websites extracting data and collecting various measures Usually, they are not repositories that provide infrastructure to manage the project (version control system, bug tracker...) but they provide a project index meant to search for projects that satisfy specific features 2 4.1 Introduction INDEX Repositories [BLM2008] provides a list of repositories and repositories of repositories (Table from [BLM2008]) A summary of these repositories and their features is presented in the next few slides 3 4.1 Introduction INDEX • Apache (http://www.apache.org) It stores projects developed by the Apache foundation These projects have some common features: { Collaborative, community-based development process { Open software license { Managed by a self-selected team of software experts who are the project core developers { Membership to the foundation (and the right to change the repository content) is granted only to volunteers that have contributed to the project (meritocracy) The repository offers a software catalogue with a short description of each project: { Programming languages, { Categories, { Lists, { Issue tracker { License { Proejct website { ..
  • Efficient Algorithms for Comparing, Storing, and Sharing

    Efficient Algorithms for Comparing, Storing, and Sharing

    EFFICIENT ALGORITHMS FOR COMPARING, STORING, AND SHARING LARGE COLLECTIONS OF EVOLUTIONARY TREES A Dissertation by SUZANNE JUDE MATTHEWS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY May 2012 Major Subject: Computer Science EFFICIENT ALGORITHMS FOR COMPARING, STORING, AND SHARING LARGE COLLECTIONS OF EVOLUTIONARY TREES A Dissertation by SUZANNE JUDE MATTHEWS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Approved by: Chair of Committee, Tiffani L. Williams Committee Members, Nancy M. Amato Jennifer L. Welch James B. Woolley Head of Department, Hank W. Walker May 2012 Major Subject: Computer Science iii ABSTRACT Efficient Algorithms for Comparing, Storing, and Sharing Large Collections of Evolutionary Trees. (May 2012) Suzanne Jude Matthews, B.S.; M.S., Rensselaer Polytechnic Institute Chair of Advisory Committee: Dr. Tiffani L. Williams Evolutionary relationships between a group of organisms are commonly summarized in a phylogenetic (or evolutionary) tree. The goal of phylogenetic inference is to infer the best tree structure that represents the relationships between a group of organisms, given a set of observations (e.g. molecular sequences). However, popular heuristics for inferring phylogenies output tens to hundreds of thousands of equally weighted candidate trees. Biologists summarize these trees into a single structure called the consensus tree. The central assumption is that the information discarded has less value than the information retained. But, what if this assumption is not true? In this dissertation, we demonstrate the value of retaining and studying tree collections.
  • GNU Emacs Manual

    GNU Emacs Manual

    GNU Emacs Manual GNU Emacs Manual Sixteenth Edition, Updated for Emacs Version 22.1. Richard Stallman This is the Sixteenth edition of the GNU Emacs Manual, updated for Emacs version 22.1. Copyright c 1985, 1986, 1987, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being \The GNU Manifesto," \Distribution" and \GNU GENERAL PUBLIC LICENSE," with the Front-Cover texts being \A GNU Manual," and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled \GNU Free Documentation License." (a) The FSF's Back-Cover Text is: \You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development." Published by the Free Software Foundation 51 Franklin Street, Fifth Floor Boston, MA 02110-1301 USA ISBN 1-882114-86-8 Cover art by Etienne Suvasa. i Short Contents Preface ::::::::::::::::::::::::::::::::::::::::::::::::: 1 Distribution ::::::::::::::::::::::::::::::::::::::::::::: 2 Introduction ::::::::::::::::::::::::::::::::::::::::::::: 5 1 The Organization of the Screen :::::::::::::::::::::::::: 6 2 Characters, Keys and Commands ::::::::::::::::::::::: 11 3 Entering and Exiting Emacs ::::::::::::::::::::::::::: 15 4 Basic Editing
  • The GNOME Desktop Environment

    The GNOME Desktop Environment

    The GNOME desktop environment Miguel de Icaza ([email protected]) Instituto de Ciencias Nucleares, UNAM Elliot Lee ([email protected]) Federico Mena ([email protected]) Instituto de Ciencias Nucleares, UNAM Tom Tromey ([email protected]) April 27, 1998 Abstract We present an overview of the free GNU Network Object Model Environment (GNOME). GNOME is a suite of X11 GUI applications that provides joy to users and hackers alike. It has been designed for extensibility and automation by using CORBA and scripting languages throughout the code. GNOME is licensed under the terms of the GNU GPL and the GNU LGPL and has been developed on the Internet by a loosely-coupled team of programmers. 1 Motivation Free operating systems1 are excellent at providing server-class services, and so are often the ideal choice for a server machine. However, the lack of a consistent user interface and of consumer-targeted applications has prevented free operating systems from reaching the vast majority of users — the desktop users. As such, the benefits of free software have only been enjoyed by the technically savvy computer user community. Most users are still locked into proprietary solutions for their desktop environments. By using GNOME, free operating systems will have a complete, user-friendly desktop which will provide users with powerful and easy-to-use graphical applications. Many people have suggested that the cause for the lack of free user-oriented appli- cations is that these do not provide enough excitement to hackers, as opposed to system- level programming. Since most of the GNOME code had to be written by hackers, we kept them happy: the magic recipe here is to design GNOME around an adrenaline response by trying to use exciting models and ideas in the applications.
  • Analysis of Devops Tools to Predict an Optimized Pipeline by Adding Weightage for Parameters

    Analysis of Devops Tools to Predict an Optimized Pipeline by Adding Weightage for Parameters

    International Journal of Computer Applications (0975 – 8887) Volume 181 – No. 33, December 2018 Analysis of DevOps Tools to Predict an Optimized Pipeline by Adding Weightage for Parameters R. Vaasanthi V. Prasanna Kumari, PhD S. Philip Kingston Research Scholar, HOD, MCA Project Manager SCSVMV University Rajalakshmi Engineering Infosys, Mahindra City, Kanchipuram College, Chennai Chennai ABSTRACT cloud. Now-a-days more than ever, DevOps [Development + Operations] has gained a tremendous amount of attention in 2. SCM software industry. Selecting the tools for building the DevOps Source code management (SCM) is a software tool used for pipeline is not a trivial exercise as there are plethora’s of tools development, versioning and enables team working in available in market. It requires thought, planning, and multiple locations to work together more effectively. This preferably enough time to investigate and consult other plays a vital role in increasing team’s productivity. Some of people. Unfortunately, there isn’t enough time in the day to the SCM tools, considered for this study are GIT, SVN, CVS, dig for top-rated DevOps tools and its compatibility with ClearCase, Mercurial, TFS, Monotone, Bitkeeper, Code co- other tools. Each tool has its own pros/cons and compatibility op, Darcs, Endevor, Fossil, Perforce, Rational Synergy, of integrating with other tools. The objective of this paper is Source Safe, and GNU Bazaar. Table1 consists of SCM tools to propose an approach by adding weightage to each with weightage. parameter for the curated list of the DevOps tools. 3. BUILD Keywords Build is a process that enables source code to be automatically DevOps, SCM, dependencies, compatibility and pipeline compiled into binaries including code level unit testing to ensure individual pieces of code behave as expected [4].
  • Bluej Teamwork Repository Configuration

    Bluej Teamwork Repository Configuration

    BlueJ Teamwork Repository Configuration Version 2.0 for BlueJ Version 2.5.0 (and 2.2.x) Davin McCall School of Engineering & IT, Deakin University 1 Introduction This document gives a brief description of how you might set up a version control repository for use with BlueJ’s teamwork features. It is intended mainly as a “quick start” guide and not as a complete reference – for that you should refer to the version control software documentation (i.e. the CVS manual or the Subversion manual) – but it does explain some BlueJ-specific concepts (such as how BlueJ supports the notion of student groups or teams). Setting up a repository usually requires a server to which you have “root” or administrator access. This may mean that you need to ask a Systems Administrator to set up the repository for you. Since BlueJ version 2.5.0, both Subversion and CVS are supported version control systems. BlueJ version 2.2.x supports only CVS. BlueJ versions prior to 2.2.0 did not support teamwork features. Chapters 2 and 3 explain how to set up and test a repository using CVS. Chapter 4 then covers the equivalent steps for using Subversion. 2 Setting up a simple single user CVS repository for testing the BlueJ teamwork features 2.1 Setting up the repository server On Unix / Linux / MacOS X: You must have the CVS software installed on the machine you intend to use as a server. There is a good chance that it is already installed, but if not, your vendor or distribution provider will almost certainly provide packages that can be installed.
  • Downloads." the Open Information Security Foundation

    Downloads." the Open Information Security Foundation

    Performance Testing Suricata The Effect of Configuration Variables On Offline Suricata Performance A Project Completed for CS 6266 Under Jonathon T. Giffin, Assistant Professor, Georgia Institute of Technology by Winston H Messer Project Advisor: Matt Jonkman, President, Open Information Security Foundation December 2011 Messer ii Abstract The Suricata IDS/IPS engine, a viable alternative to Snort, has a multitude of potential configurations. A simplified automated testing system was devised for the purpose of performance testing Suricata in an offline environment. Of the available configuration variables, seventeen were analyzed independently by testing in fifty-six configurations. Of these, three variables were found to have a statistically significant effect on performance: Detect Engine Profile, Multi Pattern Algorithm, and CPU affinity. Acknowledgements In writing the final report on this endeavor, I would like to start by thanking four people who made this project possible: Matt Jonkman, President, Open Information Security Foundation: For allowing me the opportunity to carry out this project under his supervision. Victor Julien, Lead Programmer, Open Information Security Foundation and Anne-Fleur Koolstra, Documentation Specialist, Open Information Security Foundation: For their willingness to share their wisdom and experience of Suricata via email for the past four months. John M. Weathersby, Jr., Executive Director, Open Source Software Institute: For allowing me the use of Institute equipment for the creation of a suitable testing
  • Vmpro 3.2 Open Source Licenses

    Vmpro 3.2 Open Source Licenses

    Quantum vmPRO 3.2 Open Source Licenses This document presents the open source software components used in Quantum® vmPRO™ 3.2. For information on obtaining the open source code, contact Quantum Support. Abstract This document lists the open source components used in the vmPRO product along with their licenses. 6-67728-03 Rev A, August 2014 *6-67728-02 A* Quantum vmPRO 3.2 Open Source License Agreement 6-67728-03 Rev A August 2014 Standard RPMs in the CentOS OS Package Version Build URL License ConsoleKit 0.4.1 3.el6 http://www.freedesktop.org/wiki/Software/ GPLv2+ ConsoleKit ConsoleKit- 0.4.1 3.el6 http://www.freedesktop.org/wiki/Software/ MIT libs ConsoleKit MAKEDEV 3.24 6.el6 http://www.lanana.org/docs/device-list/ GPLv2 MariaDB- 10.0.3 1 http://mariadb.org GPL compat MariaDB- 10.0.3 1 (none) GPL compat-pkg QuantumOS 2.8.0 2607 (none) Proprietary TPlugin acl 2.2.49 6.el6 http://acl.bestbits.at/ GPLv2+ aic94xx- 30 2.el6 http://www.adaptec.com/en-US/speed/scsi/ Redistributable, no firmware linux/aic94xx-seq-30-1_tar_gz.htm modification permitted atmel- 1.3 7.el6 http://at76c503a.berlios.de/ Redistributable, no firmware modification permitted attr 2.4.44 7.el6 http://acl.bestbits.at/ GPLv2+ audit-libs 2.2 2.el6 http://people.redhat.com/sgrubb/audit/ LGPLv2+ authconfig 6.1.12 13.el6 https://fedorahosted.org/authconfig GPLv2+ avahi-libs 0.6.25 12.el6 http://avahi.org LGPLv2 Made in the USA. Quantum Corporation provides this publication “as is” without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability or fitness for a particular purpose.