DOCSLIB.ORG

MINIX3: a Reliable and Secure Operating System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
MINIX3: a Reliable and Secure Operating System MINIX3: A Reliable and Secure Operating System Andrew S. Tanenbaum and a team of students and programmers who actually did all the work Vrije Universiteit Amsterdam, The Netherlands 1 GOAL OF OUR WORK: BUILD A RELIABLE OS Tanenbaum’s definition of a reliable OS: “An operating system is said to be reliable when a typical user has never experienced even a single failure in his or her lifetime and does not know anybody who has ever experienced a failure.” In engineering terms, this is probably mean time to failure > 50 years I don’t think we are there yet 2 THE TELEVISION MODEL 1. You buy the television 2. You plug it in 3. It works perfectly for the next 10 years 3 THE COMPUTER MODEL (WINDOWS EDITION) 1. You buy the computer 2. You plug it in 3. You install service packs 1 through 9f 4. You install 18 new emergency security patches 5. You find and install 7 new device drivers 6. You install antivirus software 7. You install antispyware software 8. You install antihacker software (firewall) 9. You install antispam software 10. You reboot the computer 4 THE COMPUTER MODEL (2) 11. It doesn’t work 12. You call the helpdesk 13. You wait on hold for 30 minutes 14. They tell you to reinstall Windows 5 TYPICAL USER REACTION The New York Times recently reported that 25% of computer users have gotten so angry at their computer that they physically hit it. 6 IS RELIABILITY SO IMPORTANT? • Annoying • Lost work • But also think about – Industrial control systems in factories – Power grids – Hospital operating rooms – Banking and e-commerce servers – Emergency phone centers – Control software in cars, airplanes, etc. 7 IS THIS FEASIBLE? • We won’t find out if we don’t try • Dutch Royal Academy gave me €2 million to try • European Union gave me €2.5 million to give it a shot • So, we’re trying 8 IS RELIABILITY ACHIEVABLE AT ALL? • Systems can survive hardware failures! – RAIDs can survive failed disks – ECC memory can survive parity errors in memory – TCP/IP can survive lost packets – CD-ROM drives can correct many simultaneous errors • We need to be able to survive software failures, too 9 A NEED TO RETHINK OPERATING SYSTEMS • Operating systems research need to be refocused – We have nearly infinite hardware on PC-class machines – Plenty of CPU cycles, RAM, bandwidth – Current software has tons of (useless) features – Consequently, the software is slow, bloated, and buggy • To achieve the TV model, future OSes, must be – Small – Simple – Modular – Reliable – Secure – Self-healing 10 BRIEF HISTORY OF OUR WORK • (1976) John Lions wrote a book on UNIX V6 • (1979) AT&T released V7 and forbade books on it L • (1985) I started to write a UNIX-like OS from scratch • (1987) MINIX 1 + book for teaching OS classes released • (1997) MINIX 2 (POSIX) & 2nd edition of book released • (2000) MINIX 2 license changed to BSD • (2004) MINIX 3: start of work making a reliable OS • (2006) 3rd edition of book • (2008) European grant • (2010) Focus moved towards embedded systems • (2013) MINIX 3.3.0 moves to NetBSD “compatibility” 11 THREE EDITIONS OF THE BOOK 1 2 3 12 INTELLIGENT DESIGN AS APPLIED TO OPERATING SYSTEMS • Microkernel (15,000 LoC vs. > 15 million for Linux) – Bugs per 1000 LoC: Most S/W (1-10) – MINIX 3 at least 15 kernel bugs; Linux has > 15,000 – Drivers have 3-7x more bugs than rest of kernel – About 70% of the code is drivers • Highly modular • OS runs as multiple user-mode server processes 13 STEP 1: ISOLATE COMPONENTS • Move all loadable modules out of the kernel – includes all device drivers and file systems • Run each module as a separate process with POLA (Principle Of Least Authority) 14 STEP 2: ISOLATE I/O • Isolate I/O devices • Limit access to I/O ports • Constrain DMA (needs hardware assistance) 15 STEP 3: ISOLATE COMMUNICATION • Limit interprocess communication • Restrict kernel calls on a per component basis • Restrict IPC on a ‘need-to-communicate’ basis • Make sure faulty receiver cannot hang sender 16 ARCHITECTURE OF MINIX 3 Process Shell Make ... User User mode FS 1 FS 2 Proc. ... Other Servers Disk TTY Net Print ... Other Drivers Kernel Microkernel handles interrupts, mode processes, scheduling, IPC 17 USER-MODE DEVICE DRIVERS • Each driver runs as a user-mode process • No superuser privileges • Protected by the MMU • Do not have access to I/O ports, privileged instrs 18 USER-MODE SERVERS • Each server runs as a separate process • Some key servers – Virtual file server – Actual file servers – Process manager – Memory manager – Network server – Reincarnation server 19 A SIMPLIFIED EXAMPLE: DOING A READ User Users 1 User 4 mode FS Servers Disk 2 3 Drivers Kernel File access when the block is in the FS cache 20 FILE SERVER (2) User Users 1 User 9 mode FS Servers 2 6 7,8 5 Disk Drivers 3 4 Notification Kernel File access when the block is NOT in the FS cache 21 REINCARNATION SERVER • Parent of all the drivers and servers • When a driver or server dies, RS collects it • RS checks a table for action to take e.g., restart it • RS also pings drivers and servers frequently 22 DISK DRIVER RECOVERY RS 1 User Users User 5 4 FS Servers mode 2 New Disk driver driverX 3. Crash! Drivers Kernel System is self healing—this is how we hope to make it reliable 23 KERNEL RELIABILITY/SECURITY • Fewer LoC means fewer kernel bugs • Small kernel (15,000 LoC) means reduced TCB • NO foreign code (e.g., drivers) in the kernel • Static data structures (no malloc in kernel) • Moving bugs to user space reduces their power 24 IPC RELIABILITY/SECURITY • Fixed-length messages (no buffer overruns) • Rendezvous system was simple – No lost messages – No buffer management – We had to add asynchronous messages • Interrupts and messages are unified 25 DRIVER RELIABILITY/SECURITY • Untrusted code: heavily isolated • Bugs, viruses cannot spread to other modules • Cannot touch kernel data structures • Bad pointers crash only one driver; recoverable • Infinite loops detected and driver restarted • Restricted power to do damage (not superuser) 26 OTHER ADVANTAGES OF USER DRIVERS • Short development cycle • Normal programming model • No down time for crash and reboot • Easy debugging • Good flexibility 27 FAULT INJECTION EXPERIMENT • We injected 800,000 faults into each of 3 drivers • Done on the binary drivers • Examples, change src addr, dest addr, loop condition • 100 faults were injected on each experiment • Waited 1 sec to see if the driver crashed • If no crash, inject another 100 faults and repeat • The driver crashed in 18,038 trials • The operating system NEVER crashed 28 PORT OF MINIX 3 TO ARM • Restructured source tree for multiple architectures • Changed booting to support uboot for ARM • Rewrote the low-level code dealing with hardware • Changed code for context switching, paging, etc. • Removed x86 segmentation code • Imported NetBSD ARM headers and libraries • Ported build.sh for cross-toolchain support • Wrote drivers for SD card and other Beagle devices 29 EMBEDDED SYSTEMS BeagleBone Black 5 cm 9 cm 30 CHARACTERISTICS Item Beaglebone Black 31 CHARACTERISTICS Item Beaglebone Black CPU ARM v7 32 CHARACTERISTICS Item Beaglebone Black CPU ARM v7 Clock 1 GHz 33 CHARACTERISTICS Item Beaglebone Black CPU ARM v7 Clock 1 GHz RAM 512 MB 34 CHARACTERISTICS Item Beaglebone Black CPU ARM v7 Clock 1 GHz RAM 512 MB Flash 4 GB 35 CHARACTERISTICS Item Beaglebone Black CPU ARM v7 Clock 1 GHz RAM 512 MB Flash 4 GB Video HDMI/1080p 36 CHARACTERISTICS Item Beaglebone Black CPU ARM v7 Clock 1 GHz RAM 512 MB Flash 4 GB Video HDMI/1080p GPIO pins 92 37 CHARACTERISTICS Item Beaglebone Black CPU ARM v7 Clock 1 GHz RAM 512 MB Flash 4 GB Video HDMI/1080p GPIO pins 92 Ethernet 10/100 Mbps 38 CHARACTERISTICS Item Beaglebone Black CPU ARM v7 Clock 1 GHz RAM 512 MB Flash 4 GB Video HDMI/1080p GPIO pins 92 Ethernet 10/100 Mbps USB 1 39 CHARACTERISTICS Item Beaglebone Black CPU ARM v7 Clock 1 GHz RAM 512 MB Flash 4 GB Video HDMI/1080p GPIO pins 92 Ethernet 10/100 Mbps USB 1 Open source Yes 40 CHARACTERISTICS Item Beaglebone Black CPU ARM v7 Clock 1 GHz RAM 512 MB Flash 4 GB Video HDMI/1080p GPIO pins 92 Ethernet 10/100 Mbps USB 1 Open source Yes Price (quantity 1) $45 41 CHARACTERISTICS Item Beaglebone Black Raspberry Pi B+ CPU ARM v7 Clock 1 GHz RAM 512 MB Flash 4 GB Video HDMI/1080p GPIO pins 92 Ethernet 10/100 Mbps USB 1 Open source Yes Price (quantity 1) $45 42 CHARACTERISTICS Item Beaglebone Black Raspberry Pi B+ CPU ARM v7 ARM v6 Clock 1 GHz RAM 512 MB Flash 4 GB Video HDMI/1080p GPIO pins 92 Ethernet 10/100 Mbps USB 1 Open source Yes Price (quantity 1) $45 43 CHARACTERISTICS Item Beaglebone Black Raspberry Pi B+ CPU ARM v7 ARM v6 Clock 1 GHz 700 MHz RAM 512 MB Flash 4 GB Video HDMI/1080p GPIO pins 92 Ethernet 10/100 Mbps USB 1 Open source Yes Price (quantity 1) $45 44 CHARACTERISTICS Item Beaglebone Black Raspberry Pi B+ CPU ARM v7 ARM v6 Clock 1 GHz 700 MHz RAM 512 MB 512 MB Flash 4 GB Video HDMI/1080p GPIO pins 92 Ethernet 10/100 Mbps USB 1 Open source Yes Price (quantity 1) $45 45 CHARACTERISTICS Item Beaglebone Black Raspberry Pi B+ CPU ARM v7 ARM v6 Clock 1 GHz 700 MHz RAM 512 MB 512 MB Flash 4 GB None Video HDMI/1080p GPIO pins 92 Ethernet 10/100 Mbps USB 1 Open source Yes Price (quantity 1) $45 46 CHARACTERISTICS Item Beaglebone Black Raspberry Pi B+ CPU ARM v7 ARM v6 Clock 1 GHz 700 MHz RAM 512 MB 512 MB Flash 4 GB None Video HDMI/1080p HDMI/1080p GPIO pins 92 Ethernet 10/100 Mbps USB 1 Open source Yes Price (quantity 1) $45 47 CHARACTERISTICS Item Beaglebone Black Raspberry Pi B+ CPU ARM v7 ARM v6 Clock 1 GHz 700 MHz RAM 512 MB 512 MB Flash 4 GB None Video HDMI/1080p HDMI/1080p GPIO
Load more

Recommended publications
  • Examining the Viability of MINIX 3 As a Consumer Operating
    Examining the Viability of MINIX 3 as a Consumer Operating System Joshua C. Loew March 17, 2016 Abstract The developers of the MINIX 3 operating system (OS) believe that a computer should work like a television set. You should be able to purchase one, turn it on, and have it work flawlessly for the next ten years [6]. MINIX 3 is a free and open-source microkernel-based operating system. MINIX 3 is still in development, but it is capable of running on x86 and ARM processor architectures. Such processors can be found in computers such as embedded systems, mobile phones, and laptop computers. As a light and simple operating system, MINIX 3 could take the place of the software that many people use every day. As of now, MINIX 3 is not particularly useful to a non-computer scientist. Most interactions with MINIX 3 are done through a command-line interface or an obsolete window manager. Moreover, its tools require some low-level experience with UNIX-like systems to use. This project will examine the viability of MINIX 3 from a performance standpoint to determine whether or not it is relevant to a non-computer scientist. Furthermore, this project attempts to measure how a microkernel-based operating system performs against a traditional monolithic kernel-based OS. 1 Contents 1 Introduction 5 2 Background and Related Work 6 3 Part I: The Frame Buffer Driver 7 3.1 Outline of Approach . 8 3.2 Hardware and Drivers . 8 3.3 Challenges and Strategy . 9 3.4 Evaluation . 10 4 Progress 10 4.1 Compilation and Installation .
    [Show full text]
  • What Is LLVM? and a Status Update
    What is LLVM? And a Status Update. Approved for public release Hal Finkel Leadership Computing Facility Argonne National Laboratory Clang, LLVM, etc. ✔ LLVM is a liberally-licensed(*) infrastructure for creating compilers, other toolchain components, and JIT compilation engines. ✔ Clang is a modern C++ frontend for LLVM ✔ LLVM and Clang will play significant roles in exascale computing systems! (*) Now under the Apache 2 license with the LLVM Exception LLVM/Clang is both a research platform and a production-quality compiler. 2 A role in exascale? Current/Future HPC vendors are already involved (plus many others)... Apple + Google Intel (Many millions invested annually) + many others (Qualcomm, Sony, Microsoft, Facebook, Ericcson, etc.) ARM LLVM IBM Cray NVIDIA (and PGI) Academia, Labs, etc. AMD 3 What is LLVM: LLVM is a multi-architecture infrastructure for constructing compilers and other toolchain components. LLVM is not a “low-level virtual machine”! LLVM IR Architecture-independent simplification Architecture-aware optimization (e.g. vectorization) Assembly printing, binary generation, or JIT execution Backends (Type legalization, instruction selection, register allocation, etc.) 4 What is Clang: LLVM IR Clang is a C++ frontend for LLVM... Code generation Parsing and C++ Source semantic analysis (C++14, C11, etc.) Static analysis ● For basic compilation, Clang works just like gcc – using clang instead of gcc, or clang++ instead of g++, in your makefile will likely “just work.” ● Clang has a scalable LTO, check out: https://clang.llvm.org/docs/ThinLTO.html 5 The core LLVM compiler-infrastructure components are one of the subprojects in the LLVM project. These components are also referred to as “LLVM.” 6 What About Flang? ● Started as a collaboration between DOE and NVIDIA/PGI.
    [Show full text]
  • Microkernels in a Bit More Depth • Early Operating Systems Had Very Little Structure • a Strictly Layered Approach Was Promoted by Dijkstra
    Motivation Microkernels In a Bit More Depth Early operating systems had very little structure A strictly layered approach was promoted by Dijkstra THE Operating System [Dij68] COMP9242 2007/S2 Week 4 Later OS (more or less) followed that approach (e.g., Unix). UNSW Such systems are known as monolithic kernels COMP9242 07S2 W04 1 Microkernels COMP9242 07S2 W04 2 Microkernels Issues of Monolithic Kernels Evolution of the Linux Kernel E Advantages: Kernel has access to everything: all optimisations possible all techniques/mechanisms/concepts implementable Kernel can be extended by adding more code, e.g. for: new services support for new harwdare Problems: Widening range of services and applications OS bigger, more complex, slower, more error prone. Need to support same OS on different hardware. Like to support various OS environments. Distribution impossible to provide all services from same (local) kernel. COMP9242 07S2 W04 3 Microkernels COMP9242 07S2 W04 4 Microkernels Approaches to Tackling Complexity Evolution of the Linux Kernel Part 2 A Classical software-engineering approach: modularity Software-engineering study of Linux kernel [SJW+02]: (relatively) small, mostly self-contained components well-defined interfaces between them Looked at size and interdependencies of kernel "modules" enforcement of interfaces "common coupling": interdependency via global variables containment of faults to few modules Analysed development over time (linearised version number) Doesn't work with monolithic kernels: Result 1:
    [Show full text]
  • Building Performance Measurement Tools for the MINIX 3 Operating System
    Building Performance Measurement Tools for the MINIX 3 Operating System Rogier Meurs August 2006 Contents 1 INTRODUCTION 1 1.1 Measuring Performance 1 1.2 MINIX 3 2 2 STATISTICAL PROFILING 3 2.1 Introduction 3 2.2 In Search of a Timer 3 2.2.1 i8259 Timers 3 2.2.2 CMOS Real-Time Clock 3 2.3 High-level Description 4 2.4 Work Done in User-Space 5 2.4.1 The SPROFILE System Call 5 2.5 Work Done in Kernel-Space 5 2.5.1 The SPROF Kernel Call 5 2.5.2 Profiling using the CMOS Timer Interrupt 6 2.6 Work Done at the Application Level 7 2.6.1 Control Tool: profile 7 2.6.2 Analyzing Tool: sprofalyze.pl 7 2.7 What Can and What Cannot be Profiled 8 2.8 Profiling Results 8 2.8.1 High Scoring IPC Functions 8 2.8.2 Interrupt Delay 9 2.8.3 Profiling Runs on Simulator and Other CPU Models 12 2.9 Side-effect of Using the CMOS Clock 12 3 CALL PROFILING 13 3.1 Introduction 13 3.1.1 Compiler-supported Call Profiling 13 3.1.2 Call Paths, Call and Cycle Attribution 13 3.2 High-level Description 14 3.3 Work Done in User-Space 15 3.3.1 The CPROFILE System Call 15 3.4 Work Done in Kernel-Space 16 3.4.1 The PROFBUF and CPROF Kernel Calls 16 3.5 Work Done in Libraries 17 3.5.1 Profiling Using Library Functions 17 3.5.2 The Procentry Library Function 17 3.5.3 The Procexit Library Function 20 3.5.4 The Call Path String 22 3.5.5 Testing Overhead Elimination 23 3.6 Profiling Kernel-Space/User-Space Processes 24 3.6.1 Differences in Announcing and Table Sizes 24 3.6.2 Kernel-Space Issue: Reentrancy 26 3.6.3 Kernel-Space Issue: The Call Path 26 3.7 Work Done at the Application
    [Show full text]
  • A DSL for Resource Checking Using Finite State Automaton-Driven Symbolic Execution Code
    Open Comput. Sci. 2021; 11:107–115 Research Article Endre Fülöp and Norbert Pataki* A DSL for Resource Checking Using Finite State Automaton-Driven Symbolic Execution https://doi.org/10.1515/comp-2020-0120 code. Compilers validate the syntactic elements, referred Received Mar 31, 2020; accepted May 28, 2020 variables, called functions to name a few. However, many problems may remain undiscovered. Abstract: Static analysis is an essential way to find code Static analysis is a widely-used method which is by smells and bugs. It checks the source code without exe- definition the act of uncovering properties and reasoning cution and no test cases are required, therefore its cost is about software without observing its runtime behaviour, lower than testing. Moreover, static analysis can help in restricting the scope of tools to those which operate on the software engineering comprehensively, since static anal- source representation, the code written in a single or mul- ysis can be used for the validation of code conventions, tiple programming languages. While most static analysis for measuring software complexity and for executing code methods are designed to detect anomalies (called bugs) in refactorings as well. Symbolic execution is a static analy- software code, the methods they employ are varied [1]. One sis method where the variables (e.g. input data) are inter- major difference is the level of abstraction at which the preted with symbolic values. code is represented [2]. Because static analysis is closely Clang Static Analyzer is a powerful symbolic execution related to the compilation of the code, the formats used engine based on the Clang compiler infrastructure that to represent the different abstractions are not unique to can be used with C, C++ and Objective-C.
    [Show full text]
  • SMT-Based Refutation of Spurious Bug Reports in the Clang Static Analyzer
    SMT-Based Refutation of Spurious Bug Reports in the Clang Static Analyzer Mikhail R. Gadelha∗, Enrico Steffinlongo∗, Lucas C. Cordeiroy, Bernd Fischerz, and Denis A. Nicole∗ ∗University of Southampton, UK. yUniversity of Manchester, UK. zStellenbosch University, South Africa. Abstract—We describe and evaluate a bug refutation extension bit in a is one, and (a & 1) ˆ 1 inverts the last bit in a. for the Clang Static Analyzer (CSA) that addresses the limi- The analyzer, however, produces the following (spurious) bug tations of the existing built-in constraint solver. In particular, report when analyzing the program: we complement CSA’s existing heuristics that remove spurious bug reports. We encode the path constraints produced by CSA as Satisfiability Modulo Theories (SMT) problems, use SMT main.c:4:12: warning: Dereference of null solvers to precisely check them for satisfiability, and remove pointer (loaded from variable ’z’) bug reports whose associated path constraints are unsatisfi- return *z; able. Our refutation extension refutes spurious bug reports in ˆ˜ 8 out of 12 widely used open-source applications; on aver- age, it refutes ca. 7% of all bug reports, and never refutes 1 warning generated. any true bug report. It incurs only negligible performance overheads, and on average adds 1.2% to the runtime of the The null pointer dereference reported here means that CSA full Clang/LLVM toolchain. A demonstration is available at claims to nevertheless have found a path where the dereference https://www.youtube.com/watch?v=ylW5iRYNsGA. of z is reachable. Such spurious bug reports are in practice common; in our I.
    [Show full text]
  • The Dragonflybsd Operating System
    1 The DragonFlyBSD Operating System Jeffrey M. Hsu, Member, FreeBSD and DragonFlyBSD directories with slightly over 8 million lines of code, 2 million Abstract— The DragonFlyBSD operating system is a fork of of which are in the kernel. the highly successful FreeBSD operating system. Its goals are to The project has a number of resources available to the maintain the high quality and performance of the FreeBSD 4 public, including an on-line CVS repository with mirror sites, branch, while exploiting new concepts to further improve accessible through the web as well as the cvsup service, performance and stability. In this paper, we discuss the motivation for a new BSD operating system, new concepts being mailing list forums, and a bug submission system. explored in the BSD context, the software infrastructure put in place to explore these concepts, and their application to the III. MOTIVATION network subsystem in particular. A. Technical Goals Index Terms— Message passing, Multiprocessing, Network The DragonFlyBSD operating system has several long- operating systems, Protocols, System software. range technical goals that it hopes to accomplish within the next few years. The first goal is to add lightweight threads to the BSD kernel. These threads are lightweight in the sense I. INTRODUCTION that, while user processes have an associated thread and a HE DragonFlyBSD operating system is a fork of the process context, kernel processes are pure threads with no T highly successful FreeBSD operating system. Its goals are process context. The threading model makes several to maintain the high quality and performance of the FreeBSD guarantees with respect to scheduling to ensure high 4 branch, while exploring new concepts to further improve performance and simplify reasoning about concurrency.
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO
    Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO..........................................................................................................................................1 Martin Hinner < [email protected]>, http://martin.hinner.info............................................................1 1. Introduction..........................................................................................................................................1 2. Volumes...............................................................................................................................................1 3. DOS FAT 12/16/32, VFAT.................................................................................................................2 4. High Performance FileSystem (HPFS)................................................................................................2 5. New Technology FileSystem (NTFS).................................................................................................2 6. Extended filesystems (Ext, Ext2, Ext3)...............................................................................................2 7. Macintosh Hierarchical Filesystem − HFS..........................................................................................3 8. ISO 9660 − CD−ROM filesystem.......................................................................................................3 9. Other filesystems.................................................................................................................................3
    [Show full text]
  • Introduction to Bioinformatics Introduction to Bioinformatics
    Introduction to Bioinformatics Introduction to Bioinformatics Prof. Dr. Nizamettin AYDIN [email protected] Introduction to Perl http://www3.yildiz.edu.tr/~naydin 1 2 Learning objectives Setting The Technological Scene • After this lecture you should be able to • One of the objectives of this course is.. – to enable students to acquire an understanding of, and understand : ability in, a programming language (Perl, Python) as the – sequence, iteration and selection; main enabler in the development of computer programs in the area of Bioinformatics. – basic building blocks of programming; – three C’s: constants, comments and conditions; • Modern computers are organised around two main – use of variable containers; components: – use of some Perl operators and its pattern-matching technology; – Hardware – Perl input/output – Software – … 3 4 Introduction to the Computing Introduction to the Computing • Computer: electronic genius? • In theory, computer can compute anything – NO! Electronic idiot! • that’s possible to compute – Does exactly what we tell it to, nothing more. – given enough memory and time • All computers, given enough time and memory, • In practice, solving problems involves are capable of computing exactly the same things. computing under constraints. Supercomputer – time Workstation • weather forecast, next frame of animation, ... PDA – cost • cell phone, automotive engine controller, ... = = – power • cell phone, handheld video game, ... 5 6 Copyright 2000 N. AYDIN. All rights reserved. 1 Layers of Technology Layers of Technology • Operating system... – Interacts directly with the hardware – Responsible for ensuring efficient use of hardware resources • Tools... – Softwares that take adavantage of what the operating system has to offer. – Programming languages, databases, editors, interface builders... • Applications... – Most useful category of software – Web browsers, email clients, web servers, word processors, etc..
    [Show full text]
  • Recompiling Minix
    8 RECOMPILING MINIX This chapter is intended for those readers who wish to modify MINIX or its utili- ties. In the following pages we will tell what the various files do and howthe pieces are put together to form the whole. It should be emphasized that if you simply intend to use MINIX as distributed, then you do not have torecompile the system and you do not have toread this chapter.Howev er, ifyou want to makechanges to the core of the operating system itself, for example, to add a device driverfor a streamer tape, then you should read this chapter. 8.1. REBUILDING MINIX ON THE IBM PC Although this section is specifically for IBM PC users, it should also be read carefully by everyone interested in recompiling MINIX.Most of what is said here applies to all versions of MINIX.The sections about other processors mostly discuss the differences between recompiling MINIX on an IBM PC and on another system. The MINIX sources are contained in the following directories, normally all subdi- rectories of /usr/src except for include which goes in /usr/include: center allbox; l l. Directory Contents include The headers used by the SEC. 8.1 REBUILDING MINIX ON THE IBM PC 113 commands (has twosubdirectories) kernel Process, message, and I/O device handling mm The memory manager fs The file system tools Miscellaneous tools and utilities test Test programs lib Libraries (has several subdirectories) commands The utility programs (has manysubdirectories) Some of the directories contain subdirectories. If you are working on a hard disk, be sure that all these directories have been set up, and all files copied there from the dis- tribution diskettes and decompressed and dearchived.
    [Show full text]
  • Mac OS X Intro for UNIX Users
    Mac OS X An Introduction for UNIX Users Leon Towns-von Stauber, Occam's Razor Seattle BSD Users Group, October 2004 http://www.occam.com/osx/ X Contents Opening Remarks.............................3 Where Did Mac OS X Come From?.....5 What is Mac OS X?..........................13 A New Kind of UNIX........................25 A Different Kind of UNIX.................28 Why Use Mac OS X?.........................60 Resources.......................................63 Closing Remarks.............................67 X Opening Remarks 3 This is a technical introduction to Mac OS X, mainly targeted to experienced UNIX users for whom OS X is at least relatively new Some emphasis on comparisons with FreeBSD I'm assuming basic familiarity with operating system design Where I'm coming from: UNIX user and some-time admin since 1990 Full-time UNIX admin since 1995 NeXTstep user and admin since 1991 This presentation covers primarily Mac OS X 10.3.5 (Darwin 7.5) X Legal Notices 4 This presentation Copyright © 2003-2004 Leon Towns-von Stauber. All rights reserved. Trademark notices Apple®, Mac®, Macintosh®, Mac OS®, Aqua®, Finder™, Quartz™, Cocoa®, Carbon®, AppleScript®, Rendezvous™, Panther™, and other terms are trademarks of Apple Computer. See <http:// www.apple.com/legal/appletmlist.html>. NeXT®, NeXTstep®, OpenStep®, and NetInfo® are trademarks of NeXT Software. See <http://www.apple.com/legal/nexttmlist.html>. PowerPC™ is a trademark of International Business Machines. Java™ is a trademark of Sun Microsystems. Other trademarks are the property of their
    [Show full text]