File System Issues Role of Files

Total Page:16

File Type:pdf, Size:1020Kb

File System Issues Role of Files File System Issues Role of Files • What is the role of files? • Persistance - long-lived - data for What is the file abstraction? posterity • File naming. How to find the file we want? à non-volitile storage media Sharing files. Controlling access to files. à semantically meaningful (memorable) • Performance issues - how to deal with the names bottleneck of disks? What is the “right” way to optimize file access? Abstractions *File Abstractions User view Addressbook, record for Duke CPS • UNIX-like files Application – Sequence of bytes – Operations: open (create), close, read, write, fid addrfile ->fid, byte range* seek bytes File System • Memory mapped files block# device, block # – Sequence of bytes Disk Subsystem – Mapped into address space surface, cylinder, sector – Page fault mechanism does data transfer • Named, Possibly typed 1 Functions of File System Functions of Device Subsystem • (Directory subsystem) Map filenames to fileids- In general, deal with device characteristics open (create) syscall. Create kernel data structures. • Translate block numbers (the abstraction of Maintain naming structure (unlink, mkdir , rmdir) device shown to file system) to physical disk addresses. • Determine layout of files and metadata on disk in terms of blocks. Disk block allocation. Bad Device specific (subject to change with upgrades blocks. in technology) intelligent placement of blocks. • Handle read and write system calls • Schedule (reorder?) disk operations • Initiate I/O operations for movement of blocks to/from disk. • Maintain buffer cache Know your Workload! Unix File Syscalls User grp others • File usage patterns should influence design int fd, num, success, bufsize; rwx rwx rwx decisions. Do things differently depending: char data[bufsize]; long offset, pos; 111 100 000 – How large are most files? How long-lived? fd = open (filename, mode [,permissions]); Read vs. write activity. Shared often? success = close (fd); O_RDONLY – Different levels “see” a different workload. O_WRONLY pos = lseek (fd, offset, mode); O_RDWR • Feedback loop O_CREAT num = read (fd, data, bufsize); O_APPEND num = write (fd, data, bufsize); ... Usage patterns File System Relative to design and impl observed today beginning, current position, end of file 2 File System Data Structures UNIX Inodes System-wide System-wide Data Block Addr Open file table File descriptor table File Data blocks Process 3 ... 3 3 ... 3 descriptor Attributes in-memory r-w pos, mode copy of inode File data Addr ... ptr to on-disk inode r-w pos, mode Block 1 ... stdin 2 ... array stdout ... 2 stderr ... process ptr - Decoupling meta-data 1 pos 2 per file from directory entries 2 pos 1 Pathname Resolution cps110 File Sharing Between Parent/Child Directory node “cps110/current/Proj/proj3” File current main(int argc, char *argv[]) { current inode# Attributes Directory node File char c; Attributes int fdrd , fdwt, fdpriv; Proj inode# if (( fdrd = open(argv[1], O_RDONLY)) == -1) exit(1); if (( fdwt = creat([argv[2], 0666)) == -1) File exit(1); Attributes File fork(); Attributes if (( fdpriv = open([ argv[3], O_RDONLY)) == -1) exit(1); Proj proj3 while (TRUE) { data file Directory node if (read(fdrd , &c, 1) != 1) exit(0); proj3 inode# write(fdwt, &c, 1); } index node of wd } 3 Sharing Open File Instances File System Data Structures System-wide System-wide user ID Open file table File descriptor table process ID parent process group ID shared seek parent PID offset in shared Process signal state siblings file table entry descriptor children in-memory r-w pos, mode copy of inode ptr to on-disk inode user ID shared file r-w pos, mode process ID (inodeorvnode) process group ID child parent PID stdin signal state siblings children array stdout process file system open stderr process process ptr descriptors file table - forked process’s objects per file openafterfork Process descriptor Memory Mapped Files Nachos File fd = open (somefile, consistent_mode); Syscalls/Operations pa = mmap(addr, len, prot, flags, fd, Create(“zot”); offset); R, W, X, OpenFileId fd; none fd + offset fd = Open(“zot”); Close(fd); pa Shared, len Private, Fixed, char data[bufsize]; Limitations: len Noreserve Write(data, count, fd); 1. small, fixed-size files and directories Read(data, count, fd); 2. single disk with a single directory 3. stream files only: no seek syscall 4. file size is specified at creation time VAS Reading performed by Load instr. 5. no access control, etc. 4 Goals of File Naming Naming Structures • Foremost function - to find files (e.g., in open() ), • Flat name space - 1 system-wide table, Map file name to file object. – Unique naming with multiple users is hard. • To store meta-data about files. Name conflicts. • To allow users to choose their own file names – Easy sharing, need for protection without undue name conflict problems. • Per-user name space • To allow sharing. – Protection by isolation, no sharing • Convenience: short names, groupings. – Easy to avoid name conflicts • To avoid implementation complications – Register identifies with directory to use to resolve names, possibility of user-settable (cd) Naming Structures Full Naming Network* Terry A Naming network • /Jamie/joe/project/D • Component names - pathnames grp1 root • /Jamie/d – Absolute pathnames - from a designated root Jo • /Jamie/joe/jam/proj1 – Relative pathnames - from a working directory TA /C – Each name carries how to resolve it. joe Jamie • (relative from Terry) • Short names to files anywhere in the network project jam A produce cycles, but convenience in naming B d proj1 • (relative from Jamie) things. D E C d D project * not Unix 5 Full Naming Network* Meta-Data Terry A • /Jamie/joe/project/D • File size • Location of file - grp1 root • /Jamie/d • File type which device Jo • /Jamie/joe/jam/proj1 • Protection - access • Location of TA /C control information individual blocks of joe Jamie the file on disk. project • (relative from Terry) • History: jam A creation time, • Owner of file B d last modification, • Group(s) of users proj1 • (relative from Jamie) D E last access. associated with file C d D project Why? * Unix Operations on Directories Restricting to a Hierarchy (UNIX) • Problems with full naming network • link (oldpathname, newpathname) - – What does it mean to “delete” a file? make entry pointing to file – Meta-data interpretation • unlink (filename) - remove entry pointing to file • Eliminating cycles • mknod (dirname, type, device) - used – allows use of reference counts for (e.g. by mkdir utility function) to create a reclaiming file space directory (or named pipe, or special file) – avoids garbage collection • getdents(fd, buf, structsize) - reads dir entries 6 A Typical Unix File Tree Garbage Collection Each volume is a set of directories and files; a host’s file tree Terry is the set of directories and files visible to processes on A a given host. File trees are built by grafting / grp1 X root volumes from different devices or from network servers. Jo bin etc tmp usr vmunix X TA In Unix, the graft operation is joe XJamie Series of the privileged mount system call, ls sh project users project unlinks and each volume is afilesystem. packages jam mount point B d proj1 coveredDir D E mount (coveredDir, volume) C coveredDir: directory pathname D project volume: device volume root contents become visible at pathname coveredDir A Typical Unix File Tree Each volume is a set of directories and files; a host’s file tree Reclaiming Convenience is the set of directories and files visible to processes on a given host. • Symbolic links - indirect files File trees are built by grafting / volumes from different devices filename maps, not to file object, but to or from network servers. bin etc tmp usr vmunix another pathname In Unix, the graft operation is – allows short aliases the privileged mount system call, ls sh project users and each volume is afilesystem. – slightly different semantics packages mount point • Search path rules (volumecoveredDir root) mount (coveredDir, volume) tex emacs /usr/project/packages/coveredDir/emacs 7 Unix File Naming (Hard Links) Unix Symbolic (Soft) Links directory A directory B A Unix file may have multiple names. 0 wind: 18 • Unix files may also be named by symbolic (soft) links. rain: 32 0 – A soft link is a file containing a pathname of some other file. hail: 48 sleet: 48 Each directory entry naming the file is called a hard link. symlink system call symlink (existing name, new name) inodelink directory A directory B Each inode contains a reference count allocate a new file (inode) with type symlink count = 2 0 wind: 18 showing how many hard links name it. initialize file contents with existing name 0 inode48 rain: 32 create directory entry for new file with new name hail: 48 sleet: 67 linksystem call unlinksystem call (“remove”) The target of the link may be link (existing name, new name) unlink(name) removed at any time, leaving create a new name for an existing file destroy directory entry inodelink ../A/hail/0 a dangling reference. increment inode link count decrement inode link count count = 1 if count = 0 and file is not in active use inode48 inode67 How should the kernel free blocks (recursively) and on -disk inode handle recursive soft links? Convenience, but not performance! Access Control for Files UNIX access control • Access control lists - detailed list • Each file carries its access control with it. attached to file of users allowed rwx rwx rwx setuid (denied) access, including kind of access allowed/denied. Owner Group Everybody else When bit set, it
Recommended publications
  • Intermedia: a System for Linking Multimedia Documents. IRIS
    DOCUMENT RESUME ED 296 735 IR 052 399 AUTHOR Yankelovich, Nicole TITLE Intermedia: A System for Linking Multimrdia Documents. IRIS Technical Report 86-2. INSTITUTION Brown Univ., Providence, RI. Inst. for Research in Information and Scholarship. PUB DATE 86 NOTE 19p. PUB TYPE Reports - Descriptive (141) EDRS PRICE MF01/PC01 Plus Postage. D'1CRIPTORS Bibliographic Coupling; *Computer Assisted Instruction; Computer Graphics; *Computer System Design; Higher Education; *Information Retrieval; *Man Machine Systems; *Multimedia Instruction; Word Processing IDENTIFIERS *Hypermedia ABSTRACT "Intermedia" is a hypermedia system which was developed for use in university research and teaching. It provides a framework for object-oriented, direct manipulation editors and applications, and the capability to link together materials created with those applications. Instructors are able to construct exploratory environments for their students as well as use applications for their day-to-day work, research, and writing. This paper provides a discussion of hypermedia systems in general, as well as a description of the Intermedia system which focuses on several important user features, and illustrates the operation of the system thrw,h a sample session. The text is supplemented by 15 figures. (19 references) (Author/EW) *********************************************************************** Reproductions supplied by EDRS are the best that can be made from the original document. *********************************************************************** INTERMEDIA: A System for customizing, visualizing, integratingand 0 Linking Multimedia Documents retrieving information. oi This paper describes Intermedia,one such tool designed for use in theuniversity O Nicole Yankelovich environment. The system, developedat Lid "PERMISSION TO REPRODUCE THIS Brown University's Institute for Researchin MATERIAL HAS BEEN GRANTED BY Information and Scholarship (IRIS),contains U.S.
    [Show full text]
  • IT1100 : Introduction to Operating Systems Chapter 15 What Is a Partition? What Is a Partition? Linux Partitions What Is Swap? M
    IT1100 : Introduction to Operating Systems Chapter 15 What is a partition? A partition is just a logical division of your hard drive. This is done to put data in different locations for flexibility, scalability, ease of administration, and a variety of other reasons. One reason might be so you can install Linux and Windows side-by-side. What is a partition? Another reason is to encapsulate your data. Keeping your system files and user files separate can protect one or the otherfrom malware. Since file system corruption is local to a partition, you stand to lose only some of your data if an accident occurs. Upgrading and/or reformatting is easier when your personal files are stored on a separate partition. Limit data growth. Runaway processes or maniacal users can consume so much disk space that the operating system no longer has room on the hard drive for its bookkeeping operations. This will lead to disaster. By segregating space, you ensure that things other than the operating system die when allocated disk space is exhausted. Linux Partitions In Linux, a minimum of 1 partition is required for the / . Mounting is the action of connecting a filesystem/partition to a particular point in the / root filesystem. I.e. When a usb stick is inserted, it is assigned a particular mount point and is available to the filesytem tree. - In windows you might have an A:, or B:, or C:, all of which point to different filesystems. What is Swap? If RAM fills up, by running too many processes or a process with a memory leak, new processes will fail if your system doesn’t have a way to extend system memory.
    [Show full text]
  • Io — I/O Functions
    Title stata.com io — I/O functions Contents Description Remarks and examples Reference Also see Contents [M-5] Manual entry Function Purpose Console output printf( ) printf() display sprintf() display into string errprintf( ) errprintf() display error message display( ) display() display text interpreting SMCL displayas( ) displayas() set whether output is displayed displayflush( ) displayflush() flush terminal output buffer liststruct( ) liststruct() list structure’s contents more( ) more() create --more-- condition setmore() query or set more on or off setmoreonexit() set more on or off on exit File directories direxists( ) direxists() whether directory exists dir( ) dir() file list chdir( ) pwd() obtain current working directory chdir() change current working directory mkdir() make new directory rmdir() remove directory File management findfile( ) findfile() find file fileexists( ) fileexists() whether file exists cat( ) cat() read file into string matrix unlink( ) unlink() erase file adosubdir( ) adosubdir() obtain ado-subdirectory for file 1 2 io — I/O functions File I/O fopen( ) fopen() open file fclose() close file fget() read line of ASCII file fgetnl() same, but include newline character fread() read k bytes of binary file fput() write line into ASCII file fwrite() write k bytes into binary file fgetmatrix() read matrix fputmatrix() write matrix fstatus() status of last I/O command ftell() report location in file fseek() seek to location in file ftruncate() truncate file at current position ferrortext( ) ferrortext() error text of file error code freturncode()
    [Show full text]
  • File Formats
    man pages section 4: File Formats Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A. Part No: 817–3945–10 September 2004 Copyright 2004 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, docs.sun.com, AnswerBook, AnswerBook2, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and Sun™ Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements.
    [Show full text]
  • Version 7.8-Systemd
    Linux From Scratch Version 7.8-systemd Created by Gerard Beekmans Edited by Douglas R. Reno Linux From Scratch: Version 7.8-systemd by Created by Gerard Beekmans and Edited by Douglas R. Reno Copyright © 1999-2015 Gerard Beekmans Copyright © 1999-2015, Gerard Beekmans All rights reserved. This book is licensed under a Creative Commons License. Computer instructions may be extracted from the book under the MIT License. Linux® is a registered trademark of Linus Torvalds. Linux From Scratch - Version 7.8-systemd Table of Contents Preface .......................................................................................................................................................................... vii i. Foreword ............................................................................................................................................................. vii ii. Audience ............................................................................................................................................................ vii iii. LFS Target Architectures ................................................................................................................................ viii iv. LFS and Standards ............................................................................................................................................ ix v. Rationale for Packages in the Book .................................................................................................................... x vi. Prerequisites
    [Show full text]
  • Cygwin User's Guide
    Cygwin User’s Guide Cygwin User’s Guide ii Copyright © Cygwin authors 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 . .4 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 . .7 1.7 What’s new and what changed in Cygwin . .7 1.7.1 What’s new and what changed in 3.2 .
    [Show full text]
  • Where Do You Want to Go Today? Escalating
    Where Do You Want to Go Today? ∗ Escalating Privileges by Pathname Manipulation Suresh Chari Shai Halevi Wietse Venema IBM T.J. Watson Research Center, Hawthorne, New York, USA Abstract 1. Introduction We analyze filename-based privilege escalation attacks, In this work we take another look at the problem of where an attacker creates filesystem links, thereby “trick- privilege escalation via manipulation of filesystem names. ing” a victim program into opening unintended files. Historically, attention has focused on attacks against priv- We develop primitives for a POSIX environment, provid- ileged processes that open files in directories that are ing assurance that files in “safe directories” (such as writable by an attacker. One classical example is email /etc/passwd) cannot be opened by looking up a file by delivery in the UNIX environment (e.g., [9]). Here, an “unsafe pathname” (such as a pathname that resolves the mail-delivery directory (e.g., /var/mail) is often through a symbolic link in a world-writable directory). In group or world writable. An adversarial user may use today's UNIX systems, solutions to this problem are typ- its write permission to create a hard link or symlink at ically built into (some) applications and use application- /var/mail/root that resolves to /etc/passwd. A specific knowledge about (un)safety of certain directories. simple-minded mail-delivery program that appends mail to In contrast, we seek solutions that can be implemented in the file /var/mail/root can have disastrous implica- the filesystem itself (or a library on top of it), thus providing tions for system security.
    [Show full text]
  • Chapter 19 RECOVERING DIGITAL EVIDENCE from LINUX SYSTEMS
    Chapter 19 RECOVERING DIGITAL EVIDENCE FROM LINUX SYSTEMS Philip Craiger Abstract As Linux-kernel-based operating systems proliferate there will be an in­ evitable increase in Linux systems that law enforcement agents must process in criminal investigations. The skills and expertise required to recover evidence from Microsoft-Windows-based systems do not neces­ sarily translate to Linux systems. This paper discusses digital forensic procedures for recovering evidence from Linux systems. In particular, it presents methods for identifying and recovering deleted files from disk and volatile memory, identifying notable and Trojan files, finding hidden files, and finding files with renamed extensions. All the procedures are accomplished using Linux command line utilities and require no special or commercial tools. Keywords: Digital evidence, Linux system forensics !• Introduction Linux systems will be increasingly encountered at crime scenes as Linux increases in popularity, particularly as the OS of choice for servers. The skills and expertise required to recover evidence from a Microsoft- Windows-based system, however, do not necessarily translate to the same tasks on a Linux system. For instance, the Microsoft NTFS, FAT, and Linux EXT2/3 file systems work differently enough that under­ standing one tells httle about how the other functions. In this paper we demonstrate digital forensics procedures for Linux systems using Linux command line utilities. The ability to gather evidence from a running system is particularly important as evidence in RAM may be lost if a forensics first responder does not prioritize the collection of live evidence. The forensic procedures discussed include methods for identifying and recovering deleted files from RAM and magnetic media, identifying no- 234 ADVANCES IN DIGITAL FORENSICS tables files and Trojans, and finding hidden files and renamed files (files with renamed extensions.
    [Show full text]
  • File Permissions Do Not Restrict Root
    Filesystem Security 1 General Principles • Files and folders are managed • A file handle provides an by the operating system opaque identifier for a • Applications, including shells, file/folder access files through an API • File operations • Access control entry (ACE) – Open file: returns file handle – Allow/deny a certain type of – Read/write/execute file access to a file/folder by – Close file: invalidates file user/group handle • Access control list (ACL) • Hierarchical file organization – Collection of ACEs for a – Tree (Windows) file/folder – DAG (Linux) 2 Discretionary Access Control (DAC) • Users can protect what they own – The owner may grant access to others – The owner may define the type of access (read/write/execute) given to others • DAC is the standard model used in operating systems • Mandatory Access Control (MAC) – Alternative model not covered in this lecture – Multiple levels of security for users and documents – Read down and write up principles 3 Closed vs. Open Policy Closed policy Open Policy – Also called “default secure” • Deny Tom read access to “foo” • Give Tom read access to “foo” • Deny Bob r/w access to “bar” • Give Bob r/w access to “bar • Tom: I would like to read “foo” • Tom: I would like to read “foo” – Access denied – Access allowed • Tom: I would like to read “bar” • Tom: I would like to read “bar” – Access allowed – Access denied 4 Closed Policy with Negative Authorizations and Deny Priority • Give Tom r/w access to “bar” • Deny Tom write access to “bar” • Tom: I would like to read “bar” – Access
    [Show full text]
  • Dmlite Shell
    DMLite Shell Ivan Calvet CERN IT/SDC-ID 4th DPM Workshop 13th December 2013 Presentation of DMLite Shell . Tool to administrate DMLite . Shell who provides bash-like commands . Made for admins and developers, not for users (root access needed) DMLite Shell – 4th DPM Workshop 13/12/13 2 Under the hood . Developed in Python (2.4) . Based on the python wrapper for DMLite called pydmlite DMLite Shell – 4th DPM Workshop 13/12/13 3 Usage as a command . Execute only one command: . Execute a script: DMLite Shell – 4th DPM Workshop 13/12/13 4 Usage as a shell (1/2) . Launch the shell: . Launch it with a specific configuration: DMLite Shell – 4th DPM Workshop 13/12/13 5 Usage as a shell (2/2) . Auto-completion . Type checking . Syntax checking DMLite Shell – 4th DPM Workshop 13/12/13 6 Commands (1/2) . 41 commands: . 5 to manage the shell: init, help, version, getimplid, exit . 20 to manage files: pwd, cd, ls, mkdir, unlink, rmdir, mv, du, ln, readlink, comment, info, create, chmod, chown, chgrp, checksum, utime, acl, setguid . 3 to manage replicas: replicaadd, replicamodify, replicadel DMLite Shell – 4th DPM Workshop 13/12/13 7 Commands (2/2) . 5 to manage pools: pooladd, poolinfo, poolmodify, pooldel, qryconf . 4 to manage users: useradd, userinfo, userban, userdel . 4 to manage groups: groupadd, groupinfo, groupban, groupdel DMLite Shell – 4th DPM Workshop 13/12/13 8 Demonstration DMLite Shell – 4th DPM Workshop 13/12/13 9 Need help? https://svnweb.cern.ch/trac/lcgdm/wiki/Dpm/Dev/Dmlite/Shell Check the Man page DMLite Shell – 4th DPM Workshop 13/12/13 10 Future improvements .
    [Show full text]
  • 21Files2.Pdf
    Here is a portion of a Unix directory tree. The ovals represent files, the rectangles represent directories (which are really just special cases of files). A simple implementation of a directory consists of an array of pairs of component name and inode number, where the latter identifies the target file’s inode to the operating system (an inode is data structure maintained by the operating system that represents a file). Note that every directory contains two special entries, “.” and “..”. The former refers to the directory itself, the latter to the directory’s parent (in the case of the slide, the directory is the root directory and has no parent, thus its “..” entry is a special case that refers to the directory itself). While this implementation of a directory was used in early file systems for Unix, it suffers from a number of practical problems (for example, it doesn’t scale well for large directories). It provides a good model for the semantics of directory operations, but directory implementations on modern systems are more complicated than this (and are beyond the scope of this course). Here are two directory entries referring to the same file. This is done, via the shell, through the ln command which creates a (hard) link to its first argument, giving it the name specified by its second argument. The shell’s “ln” command is implemented using the link system call. Here are the (abbreviated) contents of both the root (/) and /etc directories, showing how /unix and /etc/image are the same file. Note that if the directory entry /unix is deleted (via the shell’s “rm” command), the file (represented by inode 117) continues to exist, since there is still a directory entry referring to it.
    [Show full text]
  • A Brief Technical Introduction
    Mac OS X A Brief Technical Introduction Leon Towns-von Stauber, Occam's Razor LISA Hit the Ground Running, December 2005 http://www.occam.com/osx/ X Contents Opening Remarks..............................3 What is Mac OS X?.............................5 A New Kind of UNIX.........................12 A Diferent Kind of UNIX..................15 Resources........................................39 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 This presentation covers primarily Mac OS X 10.4.3 (Darwin 8.3), aka Tiger X Legal Notices 4 This presentation Copyright © 2003-2005 Leon Towns-von Stauber. All rights reserved. Trademark notices Apple®, Mac®, Macintosh®, Mac OS®, Finder™, Quartz™, Cocoa®, Carbon®, AppleScript®, Bonjour™, Panther™, Tiger™, 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>. Other trademarks are the property of their respective owners. X What Is It? 5 Answers Ancestry Operating System Products The Structure of Mac OS X X What Is It? Answers 6 It's an elephant I mean, it's like the elephant in the Chinese/Indian parable of the blind men, perceived as diferent things depending on the approach X What Is It? Answers 7 Inheritor of the Mac OS legacy Evolved GUI, Carbon (from Mac Toolbox), AppleScript, QuickTime, etc. The latest version of NeXTstep Mach, Quartz (from Display PostScript), Cocoa (from OpenStep), NetInfo, apps (Mail, Terminal, TextEdit, Preview, Interface Builder, Project Builder, etc.), bundles, faxing from Print panel, NetBoot, etc.
    [Show full text]