DOCSLIB.ORG

Fundamentos De Sistemas Operativos / Gunnar Wolf [Y Tres Más]

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Fundamentos De Sistemas Operativos / Gunnar Wolf [Y Tres Más] FUNDAMENTOS DE SISTEMAS OPERATIVOS Fuente: http://github.org/gwolf/sistop Compilación: 2015/06/02-13:41:24 Versión C51FA2B UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO Dr. José Narro Robles Rector Dr. Eduardo Bárzana García Secretario General Ing. Leopoldo Silva Gutiérrez Secretario Administrativo Dra. Estela Morales Campos Coordinadora de Humanidades INSTITUTO DE INVESTIGACIONES ECONÓMICAS Dra. Verónica Villarespe Reyes Directora Mtra. Berenice Ramírez López Secretaria Académica Aristeo Tovías García Secretario Técnico María Soledad Simón Pinero Jefa del Departamento de Ediciones FACULTAD DE INGENIERÍA Dr. Carlos Agustín Escalante Sandoval Director Ing. Gonzalo López de Haro Secretario General Dr. Boris Escalante Ramírez Jefe de la División de Ingeniería Eléctrica Mtra. María Cuairán Ruidíaz Jefa de la Unidad de Apoyo Editorial FUNDAMENTOS DE SISTEMAS OPERATIVOS Gunnar Wolf Esteban Ruiz Federico Bergero Erwin Meza UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO INSTITUTO DE INVESTIGACIONES ECONÓMICAS FACULTAD DE INGENIERÍA Esta investigación, arbitrada por pares académicos, se privilegia con el aval de la institución editora. Fundamentos de sistemas operativos / Gunnar Wolf [y tres más]. – Primera edición. – México D.F. : Universidad Nacional Autónoma de México, Instituto de Investigaciones Económicas : Facultad de Ingeniería, 2015. 367 p. : ilustraciones ; 28 cm. Bibliografía: páginas 359-367 ISBN 978-607-02-6544-0 1. Sistemas operativos (Computadoras). 2. Sistemas de software. 3. Organización de archivos (Informática). I. Wolf, Gunnar, autor. II. Universidad Nacional Autónoma de México. Instituto de Investigaciones Económi- cas. III. Universidad Nacional Autónoma de México. Facultad de Ingeniería. 005.43-scdd21 Biblioteca Nacional de México Primera edición 8 de abril de 2015 D. R. © UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO Ciudad Universitaria, Coyoacán, 04510, México D.F. INSTITUTO DE INVESTIGACIONES ECONÓMICAS Circuito Mario de la Cueva s/n Ciudad de la Investigación en Humanidades 04510, México D.F. FACULTAD DE INGENIERÍA Av. Universidad 3000 Ciudad Universitaria 04510, México D.F. ISBN 978-607-02-6544-0 Diseño de portada: Victoria Jiménez Diseño de interiores y formación: Gunnar Wolf Corrección y cuidado de la edición: Marisol Simón Impreso y hecho en México ¡Copia este libro! Los textos que componen este libro se publican bajo formas de licenciamiento que permiten la copia, la redistribución y la realización de obras derivadas siempre y cuando éstas se distribuyan bajo las mismas licencias libres y se cite la fuente. El copyright de los textos individuales corresponde a los respectivos autores. El presente trabajo está licenciado bajo un esquema Creative Commons Atribución CompartirIgual (CC-BY-SA) 4.0 Internacional. http://creativecommons.org/licenses/by-sa/4.0/deed.es Compartir no es delito. La versión electrónica de este libro está disponible en: http://sistop.org/ Índice general Presentación 11 1. Punto de partida 17 1.1. ¿Qué es un sistema operativo?.................... 17 1.1.1. ¿Por qué estudiar los sistemas operativos?........ 17 1.2. Funciones y objetivos del sistema operativo............ 18 1.3. Evolución de los sistemas operativos................ 19 1.3.1. Proceso por lotes (batch processing)............. 19 1.3.2. Sistemas en lotes con dispositivos de carga (spool).... 20 1.3.3. Sistemas multiprogramados................. 20 1.3.4. Sistemas de tiempo compartido............... 21 1.4. Y del lado de las computadoras personales............ 22 1.4.1. Primeros sistemas para entusiastas............. 22 1.4.2. La revolución de los 8 bits.................. 23 1.4.3. La computadora para fines “serios”: la familia PC .... 23 1.4.4. El impacto del entorno gráfico (WIMP)........... 24 1.4.5. Convergencia de los dos grandes mercados........ 25 1.5. Dispositivos móviles......................... 27 1.5.1. Reseña histórica........................ 27 1.5.2. Características diferenciadoras............... 31 1.6. Seguridad informática........................ 35 1.6.1. Código malicioso....................... 36 1.7. Organización de los sistemas operativos.............. 37 1.8. Ejercicios................................ 39 1.8.1. Preguntas de autoevaluación................ 39 1.8.2. Lecturas relacionadas.................... 41 2. Relación con el hardware 43 2.1. Introducción.............................. 43 2.2. Unidad de procesamiento...................... 43 2.2.1. Jerarquía de almacenamiento................ 44 2.2.2. Interrupciones y excepciones................ 46 5 6 ÍNDICE GENERAL 2.3. Las terminales............................. 49 2.4. Dispositivos de almacenamiento.................. 49 2.5. Relojes y temporizadores....................... 50 2.6. Canales y puentes........................... 51 2.6.1. Contención.......................... 52 2.6.2. Acceso directo a memoria (DMA).............. 53 2.7. Interfaz del sistema operativo: llamadas al sistema........ 54 2.7.1. Llamadas al sistema, arquitecturas y API ......... 55 2.8. Referencia a los componentes.................... 57 2.9. Cuando dos cabezas piensan mejor que una............ 58 2.9.1. Multiprocesamiento..................... 58 2.9.2. Cómputo distribuido..................... 62 2.9.3. Amdahl y Gustafson: ¿qué esperar del paralelismo?... 63 2.10. Ejercicios................................ 66 2.10.1. Preguntas de autoevaluación................ 66 2.10.2. Temas de investigación sugeridos............. 67 2.10.3. Lecturas relacionadas.................... 68 3. Administración de procesos 69 3.1. Concepto y estados de un proceso................. 69 3.1.1. Estados de un proceso.................... 69 3.1.2. Información asociada a un proceso............. 70 3.2. Procesos e hilos............................ 71 3.2.1. Los hilos y el sistema operativo............... 72 3.2.2. Patrones de trabajo con hilos................ 72 3.3. Concurrencia............................. 75 3.3.1. Introducción.......................... 75 3.3.2. Problema: el jardín ornamental............... 76 3.3.3. Mecanismos de sincronización............... 86 3.3.4. Problema productor-consumidor.............. 95 3.3.5. Bloqueos mutuos e inanición................ 97 3.3.6. Problema de los lectores y los escritores.......... 98 3.3.7. La cena de los filósofos.................... 100 3.3.8. Los fumadores compulsivos................. 102 3.3.9. Otros mecanismos...................... 105 3.4. Bloqueos mutuos........................... 110 3.4.1. Prevención de bloqueos................... 113 3.4.2. Evasión de bloqueos..................... 115 3.4.3. Detección y recuperación de bloqueos........... 120 3.4.4. Algoritmo del avestruz................... 124 3.5. Ejercicios................................ 126 3.5.1. Preguntas de autoevaluación................ 126 3.5.2. Temas de investigación sugeridos............. 128 3.5.3. Lecturas relacionadas.................... 129 ÍNDICE GENERAL 7 4. Planificación de procesos 131 4.1. Tipos de planificación......................... 131 4.1.1. Tipos de proceso....................... 133 4.1.2. Midiendo la respuesta.................... 134 4.2. Algoritmos de planificación..................... 137 4.2.1. Objetivos de la planificación................ 138 4.2.2. Primero llegado, primero servido (FCFS).......... 139 4.2.3. Ronda (Round Robin)..................... 140 4.2.4. El proceso más corto a continuación (SPN, shortest process next).............................. 142 4.2.5. Ronda egoísta (SRR, selfish round robin)........... 144 4.2.6. Retroalimentación multinivel (FB, multilevel feedback). 145 4.2.7. Lotería............................. 148 4.2.8. Esquemas híbridos...................... 149 4.2.9. Resumiendo.......................... 151 4.3. Planificación de hilos......................... 154 4.3.1. Los hilos POSIX (pthreads)................ 155 4.4. Planificación de multiprocesadores................. 156 4.4.1. Afinidad a procesador.................... 156 4.4.2. Balanceo de cargas...................... 157 4.4.3. Colas de procesos: ¿una o varias?.............. 158 4.4.4. Procesadores con soporte a hilos hardware ......... 158 4.5. Tiempo real.............................. 160 4.5.1. Tiempo real duro y suave.................. 161 4.5.2. Sistema operativo interrumpible (prevenible)....... 162 4.5.3. Inversión de prioridades................... 162 4.6. Ejercicios................................ 163 4.6.1. Preguntas de autoevaluación................ 163 4.6.2. Temas de investigación sugeridos............. 164 4.6.3. Lecturas relacionadas.................... 165 5. Administración de memoria 167 5.1. Funciones y operaciones....................... 167 5.1.1. Espacio de direccionamiento................ 167 5.1.2. Hardware: la unidad de manejo de memoria (MMU)... 168 5.1.3. La memoria caché ....................... 169 5.1.4. El espacio en memoria de un proceso........... 172 5.1.5. Resolución de direcciones.................. 173 5.2. Asignación de memoria contigua.................. 174 5.2.1. Partición de la memoria................... 175 5.3. Segmentación............................. 178 5.3.1. Permisos............................ 179 5.3.2. Intercambio parcial...................... 180 5.3.3. Ejemplificando........................ 181 8 ÍNDICE GENERAL 5.4. Paginación............................... 182 5.4.1. Tamaño de la página..................... 184 5.4.2. Almacenamiento de la tabla de páginas.......... 185 5.4.3. Memoria compartida..................... 188 5.5. Memoria virtual............................ 191 5.5.1. Paginación sobre demanda................. 193 5.5.2. Rendimiento.........................
Load more

Recommended publications
  • LS-09EN. OS Permissions. SUID/SGID/Sticky. Extended Attributes
    Operating Systems LS-09. OS Permissions. SUID/SGID/Sticky. Extended Attributes. Operating System Concepts 1.1 ys©2019 Linux/UNIX Security Basics Agenda ! UID ! GID ! Superuser ! File Permissions ! Umask ! RUID/EUID, RGID/EGID ! SUID, SGID, Sticky bits ! File Extended Attributes ! Mount/umount ! Windows Permissions ! File Systems Restriction Operating System Concepts 1.2 ys©2019 Domain Implementation in Linux/UNIX ! Two types domain (subjects) groups ! User Domains = User ID (UID>0) or User Group ID (GID>0) ! Superuser Domains = Root ID (UID=0) or Root Group ID (root can do everything, GID=0) ! Domain switch accomplished via file system. ! Each file has associated with it a domain bit (SetUID bit = SUID bit). ! When file is executed and SUID=on, then Effective UID is set to Owner of the file being executed. When execution completes Efective UID is reset to Real UID. ! Each subject (process) and object (file, socket,etc) has a 16-bit UID. ! Each object also has a 16-bit GID and each subject has one or more GIDs. ! Objects have access control lists that specify read, write, and execute permissions for user, group, and world. Operating System Concepts 1.3 ys©2019 Subjects and Objects Subjects = processes Objects = files (regular, directory, (Effective UID, EGID) devices /dev, ram /proc) RUID (EUID) Owner permissions (UID) RGID-main (EGID) Group Owner permissions (GID) +RGID-list Others RUID, RGID Others ID permissions Operating System Concepts 1.4 ys©2019 The Superuser (root) • Almost every Unix system comes with a special user in the /etc/passwd file with a UID=0. This user is known as the superuser and is normally given the username root.
    [Show full text]
  • OPL – Die Open Programming Language Die Lösung Zur Entwicklung Von Mobilen Anwendungen?
    OPL – Die Open Programming Language Die Lösung zur Entwicklung von mobilen Anwendungen? Martin Dehler Schumannstraße 18 67061 Ludwigshafen [email protected] Abstract: Die Open Programming Language (OPL) ist eine unter der Lesser Gnu Public Licence frei verfügbare Programmiersprache für das derzeit am weitesten verbreitete Smartphone Betriebssystem von Symbian. Mit seiner BASIC ähnlichen Syntax, der kostenlosen Verfügbarkeit von Runtime und Entwicklungsumgebung und der möglichen Nutzung der kompletten C++ API über OPX Erweiterungen hat OPL das Potential, die Entwicklung mobiler Software wesentlich zu erleichtern und damit die Verbreitung von mobilem Computing in der Medizin nachhaltig zu fördern. 1 Mobile medizinische Software von und für Jedermann? Im Gesundheitswesen findet elektronische Datenverarbeitung (EDV) eine immer größere Beachtung. Insbesondere medizinische Softwarelösungen für mobile Endgeräte, die direkt beim Patienten eingesetzt werden können, bieten das Potenzial, eine weite Verbreitung zu finden. Vom Einsatz mobiler medizinischer Anwendungen erhofft man sich eine Verbesserung von Arbeitsprozessen, der Qualität der erbrachten Leistungen und nicht zuletzt eine Erhöhung der Wirtschaftlichkeit. Eine möglichst weite Verbreitung mobiler medizinischer EDV-Anwendungen setzt sowohl eine weit verbreitete Hardwareplattform, als auch eine geeignete Programmier- sprache voraus. Sowohl für die Hardwareplattform, als auch für die Programmiersprache wäre es wünschenswert, wenn sie nur geringe Investitionskosten erfordern würden. Industrielösungen,
    [Show full text]
  • Sistemas De Archivos
    Sistemas de archivos Gunnar Wolf IIEc-UNAM Esteban Ruiz CIFASIS-UNR Federico Bergero CIFASIS-UNR Erwin Meza UNICAUCA Índice 1. Plasmando la estructura en el dispositivo1 1.1. Conceptos para la organización...................2 1.2. Diferentes sistemas de archivos...................4 1.3. El volumen..............................4 1.4. El directorio y los i-nodos......................6 1.5. Compresión y desduplicación .................... 11 2. Esquemas de asignación de espacio 14 2.1. Asignación contigua......................... 14 2.2. Asignación ligada........................... 15 2.3. Asignación indexada......................... 16 2.4. Las tablas en FAT.......................... 18 3. Fallos y recuperación 20 3.1. Datos y metadatos.......................... 22 3.2. Vericación de la integridad..................... 22 3.3. Actualizaciones suaves (soft updates)................ 23 3.4. Sistemas de archivo con bitácora (journaling le systems).... 24 3.5. Sistemas de archivos estructurados en bitácora (log-structured le systems)................................ 25 4. Otros recursos 26 1. Plasmando la estructura en el dispositivo A lo largo del capítulo ?? se presentaron los elementos del sistema de archivos tal como son presentados al usuario nal, sin entrar en detalles respecto a cómo organiza toda esta información el sistema operativo en un dispositivo persistente 1 Mencionamos algunas estructuras base, pero dejándolas explícitamente pen- dientes de denición. En este capítulo se tratarán las principales estructuras y mecanismos empleados
    [Show full text]
  • Wikipedia: Design of the FAT File System
    Design of the FAT file system A FAT file system is a specific type of computer file system architecture and FAT a family of industry-standard file systems utilizing it. Developer(s) Microsoft, SCP, IBM, [3] The FAT file system is a legacy file system which is simple and robust. It Compaq, Digital offers good performance even in very light-weight implementations, but Research, Novell, cannot deliver the same performance, reliability and scalability as some Caldera modern file systems. It is, however, supported for compatibility reasons by Full name File Allocation Table: nearly all currently developed operating systems for personal computers and FAT12 (12- many home computers, mobile devices and embedded systems, and thus is a bit version), well suited format for data exchange between computers and devices of almost FAT16 (16- any type and age from 1981 through the present. bit versions), Originally designed in 1977 for use on floppy disks, FAT was soon adapted and FAT32 (32-bit version used almost universally on hard disks throughout the DOS and Windows 9x with 28 bits used), eras for two decades. Today, FAT file systems are still commonly found on exFAT (64- floppy disks, USB sticks, flash and other solid-state memory cards and bit versions) modules, and many portable and embedded devices. DCF implements FAT as Introduced 1977 (Standalone the standard file system for digital cameras since 1998.[4] FAT is also utilized Disk BASIC-80) for the EFI system partition (partition type 0xEF) in the boot stage of EFI- FAT12: August 1980 compliant computers. (SCP QDOS) FAT16: August 1984 For floppy disks, FAT has been standardized as ECMA-107[5] and (IBM PC DOS 3.0) ISO/IEC 9293:1994[6] (superseding ISO 9293:1987[7]).
    [Show full text]
  • I. ELECTRONIC DISCOVERY: DEFINITIONS and USES A. What
    I. ELECTRONIC DISCOVERY: DEFINITIONS AND USES A. What Is Electronic Discovery? Electronic discovery includes requests for and production of information that is stored in digital form.1 In short, electronic discovery is the discovery of electronic documents and data.2 Electronic documents include virtually anything that is stored on a computer such as e-mail, web pages, word processing files, and computer databases.3 Electronic records can be found on a wide variety of devices such as desktop and laptop computers, network servers, personal digital assistants and digital phones.4 Documents and data are "electronic" if they exist in a medium that can only be read by using computers such as cache memory, magnetic disks (for example computer hard drives or floppy disks), optical disks (for example DVDs or CDs), and magnetic tapes.5 Electronic discovery is frequently distinguished from traditional "paper discovery," which is the discovery of writings on paper that can be read without the assistance of computers.6 B. Why E-Discovery Can Be Valuable in Litigation With the advancement of technology, electronic discovery is not only valuable in litigation, it is essential. Electronic evidence is affecting virtually every investigation today whether it is criminal or civil.7 Usually, there are no longer "paper- trails" that establish who did what and when.8 Instead, electronic evidence is providing the clues to understanding what actually happened.9 Consider these statistics regarding the electronic evidence explosion: · "In 2002, the International Data Corporation estimated that 31 billion e-mails were sent daily. This number is expected to grow to 60 billion a day by 2006.
    [Show full text]
  • The Symbian OS Architecture Sourcebook
    The Symbian OS Architecture Sourcebook The Symbian OS Architecture Sourcebook Design and Evolution of a Mobile Phone OS By Ben Morris Reviewed by Chris Davies, Warren Day, Martin de Jode, Roy Hayun, Simon Higginson, Mark Jacobs, Andrew Langstaff, David Mery, Matthew O’Donnell, Kal Patel, Dominic Pinkman, Alan Robinson, Matthew Reynolds, Mark Shackman, Jo Stichbury, Jan van Bergen Symbian Press Head of Symbian Press Freddie Gjertsen Managing Editor Satu McNabb Copyright 2007 Symbian Software, Ltd John Wiley & Sons, Ltd The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England Telephone (+44) 1243 779777 Email (for orders and customer service enquiries): [email protected] Visit our Home Page on www.wileyeurope.com or www.wiley.com 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, electronic, mechanical, photocopying, recording, scanning or otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP, UK, without the permission in writing of the Publisher. Requests to the Publisher should be addressed to the Permissions Department, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England, or emailed to [email protected], or faxed to (+44) 1243 770620. Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners.
    [Show full text]
  • Ext4 Disk Layout - Ext4 Hps://Ext4.Wiki.Kernel.Org/Index.Php/Ext4 Disk Layout
    Ext4 Disk Layout - Ext4 hps://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout Ext4 Disk Layout From Ext4 is document aempts to describe the on-disk format for ext4 filesystems. e same general ideas should apply to ext2/3 filesystems as well, though they do not support all the features that ext4 supports, and the fields will be shorter. NOTE: is is a work in progress, based on notes that the author (djwong) made while picking apart a filesystem by hand. e data structure definitions were pulled out of Linux 3.11 and e2fsprogs-1.42.8. He welcomes all comments and corrections, since there is undoubtedly plenty of lore that doesn't necessarily show up on freshly created demonstration filesystems. Contents 1 Terminology 2 Overview 2.1 Blocks 2.2 Layout 2.3 Flexible Block Groups 2.4 Meta Block Groups 2.5 Lazy Block Group Initialization 2.6 Special inodes 2.7 Block and Inode Allocation Policy 2.8 Checksums 2.9 Bigalloc 2.10 Inline Data 2.10.1 Inline Directories 3 e Super Block 4 Block Group Descriptors 5 Block and inode Bitmaps 6 Inode Table 6.1 Finding an Inode 6.2 Inode Size 6.3 Inode Timestamps 7 e Contents of inode.i_block 7.1 Symbolic Links 1 of 43 10/21/2013 10:43 PM Ext4 Disk Layout - Ext4 hps://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout 7.2 Direct/Indirect Block Addressing 7.3 Extent Tree 7.4 Inline Data 8 Directory Entries 8.1 Linear (Classic) Directories 8.2 Hash Tree Directories 9 Extended Aributes 9.1 POSIX ACLs 10 Multiple Mount Protection 11 Journal (jbd2) 11.1 Layout 11.2 Block Header 11.3 Super Block 11.4 Descriptor Block 11.5 Data Block 11.6 Revocation Block 11.7 Commit Block 12 Areas in Need of Work 13 Other References Terminology ext4 divides a storage device into an array of logical blocks both to reduce bookkeeping overhead and to increase throughput by forcing larger transfer sizes.
    [Show full text]
  • Mobile Computing with Python
    Mobile Computing with Python James “Wez” Weatherall & David Scott, Laboratory for Communications Engineering, Cambridge, England, {jnw22, djs55}@eng.cam.ac.uk Abstract This paper describes MoPy, a port of the Python 1.5.2 interpreter to the Psion 5/Epoc32 platform and Koala, a CORBA-style Object Request and Event Broker implemented natively in Python. While primarily a direct POSIX-based port of the standard Python interpreter, MoPy also adds thread, socket and serial support for the Psion platform. The Koala ORB is designed particularly with MoPy in mind and aims to support interoperation of devices over the low-power Prototype Em- bedded Network. The low-power requirements of PEN impose severe bandwidth and latency penalties to which conventional RPC technologies are not typically well suited. 1 Introduction Recent advances in wireless communications and embedded processor technology have paved the way for tetherless, intelligent embedded devices to enter into everyday use. Already technologies such as BlueTooth[2] and WAP[19] enable users to read their email, browse the web and link their various computational devices without physical network connections. This paper describes some key features of Koala, an Object Request and Event Broker written natively in Python and designed for use on handheld and wireless devices, and MoPy (Mobile Python), a Python interpreter for the Psion 5 Series[14]. The PEN project[1] at AT&T Laboratories Cambridge explores the future possibil- ities of embedded low-power wireless communications support in both conventional computer equipment and everyday appliances, with a view to providing totally ubiq- uitous interaction between devices. The prototype units use the 418MHz band and provide 24kbps throughput over a 5 metre radius, with power management allowing a unit to operate for several years on a single cell, subject to environmental conditions.
    [Show full text]
  • Related Links History of the Radio Shack Computers
    Home Page Links Search About Buy/Sell! Timeline: Show Images Radio Shack TRS-80 Model II 1970 Datapoint 2200 Catalog: 26-4002 1971 Kenbak-1 Announced: May 1979 1972 HP-9830A Released: October 1979 Micral Price: $3450 (32K RAM) 1973 Scelbi-8H $3899 (64K RAM) 1974 Mark-8 CPU: Zilog Z-80A, 4 MHz MITS Altair 8800 RAM: 32K, 64K SwTPC 6800 Ports: Two serial ports 1975 Sphere One parallel port IMSAI 8080 IBM 5100 Display: Built-in 12" monochrome monitor MOS KIM-1 40 X 24 or 80 X 24 text. Sol-20 Storage: One 500K 8-inch built-in floppy drive. Hewlett-Packard 9825 External Expansion w/ 3 floppy bays. PolyMorphic OS: TRS-DOS, BASIC. 1976 Cromemco Z-1 Apple I The Digital Group Rockwell AIM 65 Compucolor 8001 ELF, SuperELF Wameco QM-1A Vector Graphic Vector-1 RCA COSMAC VIP Apple II 1977 Commodore PET Radio Shack TRS-80 Atari VCS (2600) NorthStar Horizon Heathkit H8 Intel MCS-85 Heathkit H11 Bally Home Library Computer Netronics ELF II IBM 5110 VideoBrain Family Computer The TRS-80 Model II microcomputer system, designed and manufactured by Radio Shack in Fort Worth, TX, was not intended to replace or obsolete Compucolor II the Model I, it was designed to take up where the Model I left off - a machine with increased capacity and speed in every respect, targeted directly at the Exidy Sorcerer small-business application market. Ohio Scientific 1978 Superboard II Synertek SYM-1 The Model II contains a single-sided full-height Shugart 8-inch floppy drive, which holds 500K bytes of data, compared to only 87K bytes on the 5-1/4 Interact Model One inch drives of the Model I.
    [Show full text]
  • File Allocation Table - Wikipedia, the Free Encyclopedia Page 1 of 22
    File Allocation Table - Wikipedia, the free encyclopedia Page 1 of 22 File Allocation Table From Wikipedia, the free encyclopedia File Allocation Table (FAT) is a file system developed by Microsoft for MS-DOS and is the primary file system for consumer versions of Microsoft Windows up to and including Windows Me. FAT as it applies to flexible/floppy and optical disc cartridges (FAT12 and FAT16 without long filename support) has been standardized as ECMA-107 and ISO/IEC 9293. The file system is partially patented. The FAT file system is relatively uncomplicated, and is supported by virtually all existing operating systems for personal computers. This ubiquity makes it an ideal format for floppy disks and solid-state memory cards, and a convenient way of sharing data between disparate operating systems installed on the same computer (a dual boot environment). The most common implementations have a serious drawback in that when files are deleted and new files written to the media, directory fragments tend to become scattered over the entire disk, making reading and writing a slow process. Defragmentation is one solution to this, but is often a lengthy process in itself and has to be performed regularly to keep the FAT file system clean. Defragmentation should not be performed on solid-state memory cards since they wear down eventually. Contents 1 History 1.1 FAT12 1.2 Directories 1.3 Initial FAT16 1.4 Extended partition and logical drives 1.5 Final FAT16 1.6 Long File Names (VFAT, LFNs) 1.7 FAT32 1.8 Fragmentation 1.9 Third party
    [Show full text]
  • Creating Highly Specialized Fragmented File System Data Sets
    CREATING HIGHLY SPECIALIZED FRAGMENTED FILE SYSTEM DATA SETS FOR FORENSIC RESEARCH A Thesis Presented in Partial Fulfillment of the Requirements for the Degree of Master of Science with a Major in Computer Science in the College of Graduate Studies at University of Idaho by Douglas Drobny May 2014 Major Professor: Jim Alves-Foss, Ph.D. ii AUTHORIZATION TO SUBMIT THESIS This thesis of Douglas Drobny, submitted for the degree of Master of Science with a Major in Computer Science and titled \Creating Highly Specialized Fragmented File System Data Sets for Forensic Research", has been reviewed in final form. Permission, as indicated by the signatures and dates given below, is now granted to submit final copies to the College of Graduate Studies for approval. Major Professor Date Dr. Jim Alves-Foss Committee members Date Dr. Paul Oman Date Dr. Marty Ytreberg Computer Science Department Administrator Date Dr. Gregory Donohoe Discipline's College Dean, College of Engineering Date Dr. Larry Stauffer Final Approval and Acceptance by the College of Graduate Studies Date Dr. Jie Chen iii ABSTRACT File forensic tools examine the contents of a system's disk storage to analyze files, detect infections, examine account usages and extract information that the system's operating system cannot or does not provide. In cases where the file system is not available, or information is believed to be outside of the file system, a file carver can be used to extract files. File carving is the process of extracting information from an entire disk without metadata. This thesis looks at the effects of file fragmentation on forensic file carvers.
    [Show full text]
  • Downloaded in Jan 2004; "How Smartphones Work" Symbian Press and Wiley (2006); "Digerati Gliterati" John Wiley and Sons (2001)
    HOW OPEN SHOULD AN OPEN SYSTEM BE? Essays on Mobile Computing by Kevin J. Boudreau B.A.Sc., University of Waterloo M.A. Economics, University of Toronto Submitted to the Sloan School of Management in partial fulfillment of the requirements for the degree of MASSACHUBMMIBE OF TECHNOLOGY Doctor of Philosophy at the AUG 2 5 2006 MASSACHUSETTS INSTITUTE OF TECHNOLOGY LIBRARIES June 2006 @ 2006 Massachusetts Institute of Technology. All Rights Reserved. The author hereby grn Institute of Technology permission to and to distribute olo whole or in part. 1 Signature ot Author.. Sloan School of Management 3 May 2006 Certified by. .............................. ............................................ Rebecca Henderson Eastman Kodak LFM Professor of Management Thesis Supervisor Certified by ............. ................ .V . .-.. ' . ................ .... ...... Michael Cusumano Sloan Management Review Professor of Management Thesis Supervisor Certified by ................ Marc Rysman Assistant Professor of Economics, Boston University Thesis Supervisor A ccepted by ........................................... •: °/ Birger Wernerfelt J. C. Penney Professor of Management Science and Chair of PhD Committee ARCHIVES HOW OPEN SHOULD AN OPEN SYSTEM BE? Essays on Mobile Computing by Kevin J. Boudreau Submitted to the Sloan School of Management on 3 May 2006, in partial fulfillment of the requirements for the degree of Doctor of Philosophy Abstract "Systems" goods-such as computers, telecom networks, and automobiles-are made up of mul- tiple components. This dissertation comprises three esssays that study the decisions of system innovators in mobile computing to "open" development of their systems to outside suppliers and the implications of doing so. The first essay considers this issue from the perspective of which components are retained under the control of the original innovator to act as a "platform" in the system.
    [Show full text]