DOCSLIB.ORG

Moosefs 3.0 User's Manual

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Moosefs 3.0 User's Manual MooseFS 3.0 User's Manual Core Technology Development & Support Team January 7, 2017 c 2014-2017 v. 1.0.5 Piotr Robert Konopelko, Core Technology Development & Support Team. All rights reserved. Proofread by Agata Kruszona-Zawadzka Coordination & layout by Piotr Robert Konopelko. Please send corrections to Piotr Robert Konopelko { [email protected]. 1 Contents 1 About MooseFS 6 1.1 Architecture . .6 1.2 How does the system work . .8 1.3 Fault tolerance . .9 1.4 Platforms . 10 2 Moose File System Requirements 11 2.1 Network requirements . 11 2.2 Requirements for Master Servers . 11 2.2.1 CPU . 11 2.2.2 RAM size . 12 2.2.3 HDD free space . 12 2.3 Requirements for Metalogger(s) . 12 2.4 Requirements for Chunkservers . 13 2.4.1 CPU . 13 2.4.2 RAM size . 13 2.4.3 HDD space . 13 2.5 Requirements for Clients / Mounts . 13 3 Installing MooseFS 3.0 15 3.1 Configuring DNS Server . 15 3.2 Adding repositories . 16 3.2.1 Ubuntu / Debian . 16 3.2.2 RedHat / CentOS (EL7) . 16 3.2.3 RedHat / CentOS (EL6) . 17 3.2.4 Apple MacOS X . 17 3.3 Differences in package names between MooseFS Pro and MooseFS . 17 3.4 MooseFS Master Server(s) installation . 18 3.5 MooseFS CGI Monitor, CGI Server and Command Line Interface installation . 19 3.6 Chunk servers installation . 20 3.7 MooseFS Clients installation . 20 3.8 Enabling MooseFS services during OS boot . 22 3.8.1 RedHat / Centos (EL6) . 22 3.8.2 RedHat / Centos (EL7) . 22 3.8.3 Debian / Ubuntu . 23 3.8.4 FreeBSD . 23 3.9 Basic MooseFS use . 25 3.10 Stopping MooseFS . 25 2 4 Storage Classes 26 4.1 Introduction to Storage Classes functionality in MooseFS 3.0 . 26 4.1.1 What is a Storage Class? . 26 4.1.2 What are labels? . 26 4.2 How to use Storage Classes? . 27 4.2.1 Machines configuration . 27 4.2.2 Example of MooseFS installation without Storage Classes . 27 4.2.3 Labelling Chunkservers . 28 4.2.4 Creating Storage Classes . 30 4.2.5 Listing Storage Classes . 31 4.2.6 Assigning Storage Class to files / directories . 31 4.2.7 Creation, keep, archive labels . 33 4.2.8 Chunkserver states . 34 4.2.9 Chunk creation modes . 34 4.2.10 Preferred labels during read/write (in mfsmount).............. 35 4.3 Storage Classes tools . 36 4.3.1 MooseFS Storage Class administration tool { mfsscadmin ......... 36 4.3.2 MooseFS Storage Class management tools { mfssclass .......... 39 4.4 Common use scenarios . 41 4.4.1 Scenario 1: Two server rooms (A and B) . 41 4.4.2 Scenario 2: SSD and HDD drives . 42 4.4.3 Scenario 3: Two server rooms (A and B) + SSD and HDD drives . 44 4.4.4 Scenario 4: Creation, Keep and Archive modes . 46 5 Troubleshooting 47 5.1 Metadata save . 47 5.2 Master metadata restore from Metaloggers . 48 5.3 Maintenance mode . 48 5.4 Chunk replication priorities . 49 6 MooseFS Tools 50 6.1 For MooseFS Master Server(s) . 50 6.1.1 mfsmaster ................................... 50 6.1.2 mfsmetarestore ................................ 51 6.1.3 mfsmetadump .................................. 51 6.2 For MooseFS Supervisor . 55 6.2.1 mfssupervisor ................................. 55 6.3 For MooseFS Command Line Interface . 56 6.3.1 mfscli ..................................... 56 6.4 For MooseFS CGI Server . 58 6.4.1 mfscgiserv ................................... 58 6.5 For MooseFS Metalogger(s) . 59 6.5.1 mfsmetalogger ................................. 59 6.6 For MooseFS Chunkserver(s) . 60 6.6.1 mfschunkserver ................................ 60 6.7 For MooseFS Client . 61 6.7.1 mfsmount .................................... 61 6.7.2 mfstools .................................... 64 7 MooseFS Configuration Files 68 3 7.1 For MooseFS Master Server(s) . 68 7.1.1 mfsmaster.cfg ................................. 68 7.1.2 mfsexports.cfg ................................ 71 7.1.3 mfstopology.cfg ............................... 73 7.2 For MooseFS Metalogger(s) . 74 7.2.1 mfsmetalogger.cfg .............................. 74 7.3 For MooseFS Chunkservers . 75 7.3.1 mfschunkserver.cfg ............................. 75 7.3.2 mfshdd.cfg ................................... 76 8 Frequently Asked Questions 77 8.1 What average write/read speeds can we expect? . 77 8.2 Does the goal setting influence writing/reading speeds? . 77 8.3 Are concurrent read and write operations supported? . 77 8.4 How much CPU/RAM resources are used? . 78 8.5 Is it possible to add/remove chunkservers and disks on the fly? . 78 8.6 How to mark a disk for removal? . 79 8.7 My experience with clustered filesystems is that metadata operations are quite slow. How did you resolve this problem? . 79 8.8 What does value of directory size mean on MooseFS? It is different than standard Linux ls -l output. Why? . 79 8.9 When I perform df -h on a filesystem the results are different from what I would expect taking into account actual sizes of written files. 80 8.10 Can I keep source code on MooseFS? Why do small files occupy more space than I would have expected? . 80 8.11 Do Chunkservers and Metadata Server do their own checksumming? . 81 8.12 What resources are required for the Master Server? . 82 8.13 When I delete files or directories, the MooseFS free space size doesn't change. Why? .......................................... 82 8.14 When I added a third server as an extra chunkserver, it looked like the system started replicating data to the 3rd server even though the file goal was still set to2............................................ 83 8.15 Is MooseFS 64bit compatible? . 83 8.16 Can I modify the chunk size? . 83 8.17 How do I know if a file has been successfully written to MooseFS? . 83 8.18 What are limits in MooseFS (e.g. file size limit, filesystem size limit, max number of files, that can be stored on the filesystem)? . 84 8.19 Can I set up HTTP basic authentication for the mfscgiserv? . 85 8.20 Can I run a mail server application on MooseFS? Mail server is a very busy application with a large number of small files { will I not lose any files? . 85 8.21 Are there any suggestions for the network, MTU or bandwidth? . 85 8.22 Does MooseFS support supplementary groups? . 85 8.23 Does MooseFS support file locking? . 85 8.24 Is it possible to assign IP addresses to chunk servers via DHCP? . 85 8.25 Some of my chunkservers utilize 90% of space while others only 10%. Why does the rebalancing process take so long? . 86 8.26 I have a Metalogger running { should I make additional backup of the metadata file on the Master Server? . 86 8.27 I think one of my disks is slower / damaged. How should I find it? . 87 4 8.28 How can I find the master server PID? . 87 8.29 Web interface shows there are some copies of chunks with goal 0. What does it mean? . 87 8.30 Is every error message reported by mfsmount a serious problem? . 88 8.31 How do I verify that the MooseFS cluster is online? What happens with mfsmount when the master server goes down? . 88 5 Chapter 1 About MooseFS MooseFS is a fault-tolerant distributed file system. It spreads data over several physical loca- tions (servers), which are visible to user as one resource. For standard file operations MooseFS acts as any other Unix-alike filesystem: • Hierarchical structure (directory tree) • Stores POSIX file attributes (permissions, last access and modification times) • Supports special files (block and character devices, pipes and sockets) • Symbolic links (file names pointing to target files, not necessarily on MooseFS) and hard links (different names of files that refer to the same data on MooseFS) • Access to the file system can be limited based on IP address and/or password Distinctive features of MooseFS are: • High reliability (several copies of the data can.
Load more

Recommended publications
  • Cryptomator Documentation Release 1.5.0
    Cryptomator Documentation Release 1.5.0 Cryptobot Sep 15, 2021 Desktop 1 Setup 3 1.1 Windows...............................................3 1.2 macOS................................................3 1.3 Linux.................................................3 2 Getting Started 5 3 Adding Vaults 7 3.1 Create a New Vault..........................................8 3.2 Open an Existing Vault........................................ 13 4 Accessing Vaults 15 4.1 Unlocking a Vault.......................................... 16 4.2 Working with the Unlocked Vault.................................. 17 4.3 Locking a vault............................................ 18 5 Password And Recovery Key 21 5.1 Change Password........................................... 21 5.2 Show Recovery Key......................................... 22 5.3 Reset Password............................................ 23 6 Vault Mounting 27 6.1 General Adapter Selection...................................... 27 6.2 Options applicable to all Systems and Adapters........................... 27 6.3 WebDAV-specific options...................................... 28 6.4 Dokany-specific options....................................... 28 6.5 FUSE-specific options........................................ 28 7 Vault Management 29 7.1 Remove Vaults............................................ 29 7.2 Reorder Vaults............................................ 29 7.3 Vault Options............................................. 29 8 Setup 33 8.1 Google PlayStore..........................................
    [Show full text]
  • CST8207 – Linux O/S I
    Mounting a Filesystem Directory Structure Fstab Mount command CST8207 - Algonquin College 2 Chapter 12: page 467 - 496 CST8207 - Algonquin College 3 The mount utility connects filesystems to the Linux directory hierarchy. The mount point is a directory in the local filesystem where you can access mounted filesystem. This directory must exist before you can mount a filesystem. All filesystems visible on the system exist as a mounted filesystem someplace below the root (/) directory CST8207 - Algonquin College 4 can be mounted manually ◦ can be listed in /etc/fstab, but not necessary ◦ all mounting information supplied manually at command line by user or administrator can be mounted automatically on startup ◦ must be listed /etc/fstab, with all appropriate information and options required Every filesystem, drive, storage device is listed as a mounted filesystem associated to a directory someplace under the root (/) directory CST8207 - Algonquin College 5 CST8207 - Algonquin College 6 Benefits Scalable ◦ As new drives are added and new partitions are created, further filesystems can be mounted at various mount points as required. ◦ This means a Linux system does not need to worry about running out of disk space. Transparent ◦ No application would stop working if transferred to a different partition, because access to data is done via the mount point. ◦ Also transparent to user CST8207 - Algonquin College 7 All known filesystems volumes are typically listed in the /etc/fstab (static information about filesystem) file to help automate the mounting process If it is not listed in the /etc/fstab file, then all appropriate information about the filesystem needs to be listed manually at the command line.
    [Show full text]
  • File System, Files, and *Tab /Etc/Fstab
    File system, files, and *tab File system files directories volumes, file systems mounting points local versus networked file systems 1 /etc/fstab Specifies what is to be mounted where and how fs_spec: describes block special device for remote filesystem to be mounted fs_file: describes the mount point fs_vfstype: describes the type of file system fs_mntops: describes the mount options associated with the filesystem 2 /etc/fstab cont. fs_freq: used by the dump command fs_passno: used by fsck to determine the order in which checks are done at boot time. Root file systems should be specified as 1, others should be 2. Value 0 means that file system does not need to be checked 3 /etc/fstab 4 from blocks to mounting points metadata inodes directories superblocks 5 mounting file systems mounting e.g., mount -a unmounting manually or during shutdown umount 6 /etc/mtab see what is mounted 7 Network File System Access file system (FS) over a network looks like a local file system to user e.g. mount user FS rather than duplicating it (which would be a disaster) Developed by Sun Microsystems (mid 80s) history for NFS: NFS, NFSv2, NFSv3, NFSv4 RFC 3530 (from 2003) take a look to see what these RFCs are like!) 8 Network File System How does this actually work? server needs to export the system client needs to mount the system server: /etc/exports file client: /etc/fstab file 9 Network File System Security concerns UID GID What problems could arise? 10 Network File System example from our raid system (what is a RAID again?) Example of exports file from
    [Show full text]
  • The Linux Command Line
    The Linux Command Line Fifth Internet Edition William Shotts A LinuxCommand.org Book Copyright ©2008-2019, William E. Shotts, Jr. This work is licensed under the Creative Commons Attribution-Noncommercial-No De- rivative Works 3.0 United States License. To view a copy of this license, visit the link above or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042. A version of this book is also available in printed form, published by No Starch Press. Copies may be purchased wherever fine books are sold. No Starch Press also offers elec- tronic formats for popular e-readers. They can be reached at: https://www.nostarch.com. Linux® is the registered trademark of Linus Torvalds. All other trademarks belong to their respective owners. This book is part of the LinuxCommand.org project, a site for Linux education and advo- cacy devoted to helping users of legacy operating systems migrate into the future. You may contact the LinuxCommand.org project at http://linuxcommand.org. Release History Version Date Description 19.01A January 28, 2019 Fifth Internet Edition (Corrected TOC) 19.01 January 17, 2019 Fifth Internet Edition. 17.10 October 19, 2017 Fourth Internet Edition. 16.07 July 28, 2016 Third Internet Edition. 13.07 July 6, 2013 Second Internet Edition. 09.12 December 14, 2009 First Internet Edition. Table of Contents Introduction....................................................................................................xvi Why Use the Command Line?......................................................................................xvi
    [Show full text]
  • Filesystem Hierarchy Standard
    Filesystem Hierarchy Standard LSB Workgroup, The Linux Foundation Filesystem Hierarchy Standard LSB Workgroup, The Linux Foundation Version 3.0 Publication date March 19, 2015 Copyright © 2015 The Linux Foundation Copyright © 1994-2004 Daniel Quinlan Copyright © 2001-2004 Paul 'Rusty' Russell Copyright © 2003-2004 Christopher Yeoh Abstract This standard consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems. All trademarks and copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Permission is granted to make and distribute verbatim copies of this standard provided the copyright and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this standard under the conditions for verbatim copying, provided also that the title page is labeled as modified including a reference to the original standard, provided that information on retrieving the original standard is included, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this standard into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the copyright holder. Dedication This release is dedicated to the memory of Christopher Yeoh, a long-time friend and colleague, and one of the original editors of the FHS.
    [Show full text]
  • Oracle® Linux 7 Managing File Systems
    Oracle® Linux 7 Managing File Systems F32760-07 August 2021 Oracle Legal Notices Copyright © 2020, 2021, Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.
    [Show full text]
  • Bash Tutorial
    Bash Shell Lecturer: Prof. Andrzej (AJ) Bieszczad Email: [email protected] Phone: 818-677-4954 Bash Shell The shell of Linux • Linux has a variety of different shells: – Bourne shell (sh), C shell (csh), Korn shell (ksh), TC shell (tcsh), Bour ne Again shell (bash). • Certainly the most popular shell is “bash”. Bash is an sh- compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh). • It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard. • It offers functional improvements over sh for both programming and interactive use. Bash Shell Programming or Scripting ? • bash is not only an excellent command line shell, but a scripting language in itself. Shell scripting allows us to use the shell's abilities and to automate a lot of tasks that would otherwise require a lot of commands. • Difference between programming and scripting languages: – Programming languages are generally a lot more powerful and a lot faster than scriptin g languages. Programming languages generally start from source code and are compil ed into an executable. This executable is not easily ported into different operating syste ms. – A scripting language also starts from source code, but is not compiled into an executabl e. Rather, an interpreter reads the instructions in the source file and executes each inst ruction. Interpreted programs are generally slower than compiled programs. The main a dvantage is that you can easily port the source file to any operating system. bash is a s cripting language. Other examples of scripting languages are Perl, Lisp, and Tcl.
    [Show full text]
  • To FUSE Or Not to FUSE? Analysis and Performance Characterization of the FUSE User-Space File System Framework
    To FUSE or not to FUSE? Analysis and Performance Characterization of the FUSE User-Space File System Framework A Thesis Presented by Bharath Kumar Reddy Vangoor to The Graduate School in Partial Fulfillment of the Requirements for the Degree of Master of Science in Computer Science Stony Brook University Technical Report FSL-16-02 December 2016 Copyright by Bharath Kumar Reddy Vangoor 2016 Stony Brook University The Graduate School Bharath Kumar Reddy Vangoor We, the thesis committee for the above candidate for the Master of Science degree, hereby recommend acceptance of this thesis. Signature: Dr. Erez Zadok, Thesis Advisor Professor, Computer Science Signature: Dr. Mike Ferdman, Thesis Committee Chair Assistant Professor, Computer Science Signature: Dr. Vasily Tarasov IBM Research – Almaden This thesis is accepted by the Graduate School Charles Taber Dean of the Graduate School ii Abstract of the Thesis To FUSE or not to FUSE? Analysis and Performance Characterization of the FUSE User-Space File System Framework by Bharath Kumar Reddy Vangoor Master of Science in Computer Science Stony Brook University December 2016 Traditionally, file systems were implemented as part of operating systems kernels, which provide a limited set of tools and facilities to a programmer. As complexity of file systems grew, many new file systems began being developed in user space. Low performance is considered the main disadvan- tage of user-space file systems but the extent of this problem has never been explored systematically. As a result, the topic of user-space file systems remains rather controversial: while some consider user-space file systems a “toy” not to be used in production, others develop full-fledged production file systems in user space.
    [Show full text]
  • Cygwin User's Guide
    Cygwin User’s Guide i Cygwin User’s Guide Cygwin User’s Guide ii Copyright © 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 Red Hat, Inc. Permission is granted to make and distribute verbatim copies of this documentation provided the copyright notice and this per- mission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this documentation under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this documentation into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. Cygwin User’s Guide iii Contents 1 Cygwin Overview 1 1.1 What is it? . .1 1.2 Quick Start Guide for those more experienced with Windows . .1 1.3 Quick Start Guide for those more experienced with UNIX . .1 1.4 Are the Cygwin tools free software? . .2 1.5 A brief history of the Cygwin project . .2 1.6 Highlights of Cygwin Functionality . .3 1.6.1 Introduction . .3 1.6.2 Permissions and Security . .3 1.6.3 File Access . .3 1.6.4 Text Mode vs. Binary Mode . .4 1.6.5 ANSI C Library . .5 1.6.6 Process Creation . .5 1.6.6.1 Problems with process creation . .5 1.6.7 Signals . .6 1.6.8 Sockets . .6 1.6.9 Select .
    [Show full text]
  • The Android Platform Security Model∗
    The Android Platform Security Model∗ RENÉ MAYRHOFER, Google and Johannes Kepler University Linz JEFFREY VANDER STOEP, Google CHAD BRUBAKER, Google NICK KRALEVICH, Google Android is the most widely deployed end-user focused operating system. With its growing set of use cases encompassing communication, navigation, media consumption, entertainment, finance, health, and access to sensors, actuators, cameras, or microphones, its underlying security model needs to address a host of practical threats in a wide variety of scenarios while being useful to non-security experts. The model needs to strike a difficult balance between security, privacy, and usability for end users, assurances for app developers, and system performance under tight hardware constraints. While many of the underlying design principles have implicitly informed the overall system architecture, access control mechanisms, and mitigation techniques, the Android security model has previously not been formally published. This paper aims to both document the abstract model and discuss its implications. Based on a definition of the threat model and Android ecosystem context in which it operates, we analyze how the different security measures in past and current Android implementations work together to mitigate these threats. There are some special cases in applying the security model, and we discuss such deliberate deviations from the abstract model. CCS Concepts: • Security and privacy → Software and application security; Domain-specific security and privacy architectures; Operating systems security; • Human-centered computing → Ubiquitous and mobile devices. Additional Key Words and Phrases: Android, security, operating system, informal model 1 INTRODUCTION Android is, at the time of this writing, the most widely deployed end-user operating system.
    [Show full text]
  • Design and Implementation of an Intelligent Gaming Agent Using A* Algorithm and Finite State Machines
    International Journal of Engineering Research and Technology. ISSN 0974-3154, Volume 13, Number 2 (2020), pp. 191-206 © International Research Publication House. https://dx.doi.org/10.37624/IJERT/13.2.2020.191-206 Design and Implementation of an Intelligent Gaming Agent Using A* Algorithm and Finite State Machines Adekanmi Adeyinka Adegun1, Roseline Oluwaseun Ogundokun2, *, Samuel Ogbonyomi3 and Peter O. Sadiku4 1, 2, 3Department of Computer Science, Landmark University Omu Aran, Kwara State, Nigeria. 4Department of Computer Science, University of Ilorin, Kwara State, Nigeria. *ORCID: 0000-0002-2592-2824 Abstract Artificial Intelligence (AI) is the field within Computer Science that seeks to explain and to emulate some or all The last decade has seen Artificial Intelligence (AI) seep into aspects of human intelligence through mechanical or the game development industry, mainly for the purpose of computational processes. Included among these aspects of developing more human-like non-player characters (NPCs) to intelligence are the ability to interact with the environment improve player experience. This study focuses on solving the through sensory means and the ability to make decisions in problem of player experience with respect to AI controlled unforeseen circumstances without human intervention. gaming agents. The main aim of the study is to develop an Typical areas of research in AI include game playing, natural intelligent gaming agent by implementing A* Pathfinding and language understanding and synthesis, computer vision, Finite State Machines. For the implementation, problem solving, learning, and robotics (Restu, 2015). Over Mixamo/Adobe Fuse was used to model the 3D characters the years, there has been an increase in the need for Artificial (PC and NPCs), the A* Pathfinding component was Intelligence in Game Development.
    [Show full text]
  • Bygone Battles
    LINUX USER Retro-Gaming Emulating Legacy Game Platforms Bygone Battles Do you miss your trusty Sinclair Spectrum? Do you long for the Commodore you know only in your history books? Old platforms come alive using the tools of the retro-gamers. BY IAN POINTER efore the computer industry set- tled on the IBM PC, there were Bmany different types of computers with exotic-sounding names like Enter- prise, Oric, Dragon, Electron, Spectrum, and Amiga. Although these machines are no longer with us, most of these legacy systems sill have ardent fans that keep their memory alive. These fans prefer the simplicity of the older era – when pro- grams had to fit inside tiny quantities of memory and programmers had to use Gavin Banns,Gavin www.visipix.com every trick they could imagine to get the most out of a computer – to the fast processors and gigabytes storage of today. These enthusiasts are more common than you might think; the coming of the Internet has allowed people from all across the world to reminisce about the past, and for the last eight years, a Clas- can even use Linux to develop new pro- found at http://www.libsdl.org. It is sic Gaming Expo (http://www.cgexpo. grams for these old computers. probably best to download the source com) has been held in America, with and build it manually, so you can be sure exhibitions from big arcade firms like Sinclair Spectrum it doesn’t use older graphics systems like Midway and Konami, plus lectures from The Spectrum, released in 1982, was the svgalib.
    [Show full text]