DOCSLIB.ORG

[11] Case Study: Unix

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
[11] Case Study: Unix [11] CASE STUDY: UNIX 1 . 1 OUTLINE Introduction Design Principles Structural, Files, Directory Hierarchy Filesystem Files, Directories, Links, On-Disk Structures Mounting Filesystems, In-Memory Tables, Consistency Summary 1 . 2 INTRODUCTION Introduction Design Principles Filesystem Summary 2 . 1 HISTORY (I) First developed in 1969 at Bell Labs (Thompson & Ritchie) as reaction to bloated Multics. Originally written in PDP-7 asm, but then (1973) rewritten in the "new" high-level language C so it was easy to port, alter, read, etc. Unusual due to need for performance 6th edition ("V6") was widely available (1976), including source meaning people could write new tools and nice features of other OSes promptly rolled in V6 was mainly used by universities who could afford a minicomputer, but not necessarily all the software required. The first really portable OS as same source could be built for three different machines (with minor asm changes) Bell Labs continued with V8, V9 and V10 (1989), but never really widely available because V7 pushed to Unix Support Group (USG) within AT&T AT&T did System III first (1982), and in 1983 (after US government split Bells), System V. There was no System IV 2 . 2 HISTORY (II) By 1978, V7 available (for both the 16-bit PDP-11 and the new 32-bit VAX-11). Subsequently, two main families: AT&T "System V", currently SVR4, and Berkeley: "BSD", currently 4.4BSD Later standardisation efforts (e.g. POSIX, X/OPEN) to homogenise USDL did SVR2 in 1984; SVR3 released in 1987; SVR4 in 1989 which supported the POSIX.1 standard In parallel with AT&T story, people at University of California at Berkeley (UCB) added virtual memory support to "32V" [32-bit V7 for VAX] and created 3BSD 2 . 3 HISTORY (III) 4BSD development supported by DARPA who wanted (among other things) OS support for TCP/IP By 1983, 4.2BSD released at end of original DARPA project 1986 saw 4.3BSD released — very similar to 4.2BSD, but lots of minor tweaks. 1988 had 4.3BSD Tahoe (sometimes 4.3.1) which included improved TCP/IP congestion control. 19xx saw 4.3BSD Reno (sometimes 4.3.2) with further improved congestion control. Large rewrite gave 4.4BSD in 1993; very different structure, includes LFS, Mach VM stuff, stackable FS, NFS, etc. Best known Unix today is probably Linux, but also get FreeBSD, NetBSD, and (commercially) Solaris, OSF/1, IRIX, and Tru64 2 . 4 SIMPLIFIED UNIX FAMILY TREE (NON-EXAMINABLE) https://commons.wikimedia.org/wiki/File:Unix_history-simple.svg DESIGN PRINCIPLES Introduction Design Principles Structural, Files, Directory Hierarchy Filesystem Summary 23 . 51 DESIGN FEATURES Ritchie & Thompson (CACM, July 74), identified the (new) features of Unix: A hierarchical file system incorporating demountable volumes Compatible file, device and inter-process IO (naming schemes, access control) Ability to initiate asynchronous processes (i.e., address-spaces = heavyweight) System command language selectable on a per-user basis Completely novel at the time: prior to this, everything was "inside" the OS. In Unix separation between essential things (kernel) and everything else Among other things: allows user wider choice without increasing size of core OS; allows easy replacement of functionality — resulted in over 100 subsystems including a dozen languages Highly portable due to use of high-level language Features which were not included: real time, multiprocessor support 3 . 2 STRUCTURAL OVERVIEW Clear separation between user and kernel portions was the big difference between Unix and contemporary systems — only the essential features inside OS, not the editors, command interpreters, compilers, etc. Processes are unit of scheduling and protection: the command interpreter ("shell") just a process No concurrency within kernel All IO looks like operations on files: in Unix, everything is a file 3 . 3 FILESYSTEM Introduction Design Principles Filesystem Files, Directories, Links, On-Disk Structures Mounting Filesystems, In-Memory Tables, Consistency Summary 4 . 1 FILE ABSTRACTION File as an unstructured sequence of bytes which was relatively unusual at the time: most systems lent towards files being composed of records Cons: don't get nice type information; programmer must worry about format of things inside file Pros: less stuff to worry about in the kernel; and programmer has flexibility to choose format within file! Represented in user-space by a file descriptor (fd) this is just an opaque identifier — a good technique for ensuring protection between user and kernel 4 . 2 FILE OPERATIONS Operations on files are: fd = open(pathname, mode) fd = creat(pathname, mode) bytes = read(fd, buffer, nbytes) count = write(fd, buffer, nbytes) reply = seek(fd, offset, whence) reply = close(fd) The kernel keeps track of the current position within the file Devices are represented by special files: Support above operations, although perhaps with bizarre semantics Also have ioctl for access to device-specific functionality 4 . 3 DIRECTORY HIERARCHY Directories map names to files (and directories) starting from distinguished root directory called / Fully qualified pathnames mean performing traversal from root Every directory has . and .. entries: refer to self and parent respectively. Also have shortcut of current working directory (cwd) which allows relative path names; and the shell provides access to home directory as ~username (e.g. ~mort/). Note that kernel knows about former but not latter Structure is a tree in general though this is slightly relaxed 4 . 4 ASIDE: PASSWORD FILE /etc/passwd holds list of password entries of the form user- name:encrypted-passwd:home-directory:shell Also contains user-id, group-id (default), and friendly name. Use one-way function to encrypt passwords i.e. a function which is easy to compute in one direction, but has a hard to compute inverse. To login: Get user name Get password Encrypt password Check against version in /etc/password If ok, instantiate login shell Otherwise delay and retry, with upper bound on retries Publicly readable since lots of useful info there but permits offline attack Solution: shadow passwords (/etc/shadow) 4 . 5 FILE SYSTEM IMPLEMENTATION Inside the kernel, a file is represented by a data structure called an index-node or i- node which hold file meta-data: owner, permissions, reference count, etc. and location on disk of actual data (file contents) 4 . 6 I-NODES Why don't we have all blocks in a simple table? Why have first few in inode at all? How many references to access blocks at different places in the file? If block can hold 512 block-addresses (e.g. blocks are 4kB, block addresses are 8 bytes), what is max size of file (in blocks)? Where is the filename kept? 4 . 7 DIRECTORIES AND LINKS Directory is (just) a file which maps filenames to i-nodes — that is, it has its own i-node pointing to its contents An instance of a file in a directory is a (hard) link hence the reference count in the i- node. Directories can have at most 1 (real) link. Why? Also get soft- or symbolic- links: a 'normal' file which contains a filename 4 . 8 ON-DISK STRUCTURES A disk consists of a boot block followed by one or more partitions. Very old disks would have just a single partition. Nowadays have a boot block containing a partition table allowing OS to determine where the filesystems are Figure shows two completely independent filesystems; this is not replication for redundancy. Also note |inode table| |superblock|; |data blocks| |inode table| 4 . 9 ON-DISK STRUCTURES A partition is just a contiguous range of N fixed-size blocks of size k for some N and k, and a Unix filesystem resides within a partition Common block sizes: 512B, 1kB, 2kB, 4kB, 8kB Superblock contains info such as: Number of blocks and free blocks in filesystem Start of the free-block and free-inode list Various bookkeeping information Free blocks and inodes intermingle with allocated ones On-disk have a chain of tables (with head in superblock) for each of these. Unfortunately this leaves superblock and inode-table vulnerable to head crashes so we must replicate in practice. In fact, now a wide range of Unix filesystems that are completely different; e.g., log-structure 4 . 10 MOUNTING FILESYSTEMS Entire filesystems can be mounted on an existing directory in an already mounted filesystem At very start, only / exists so must mount a root filesystem Subsequently can mount other filesystems, e.g. mount("/dev/hda2", "/home", options) Provides a unified name-space: e.g. access /home/mort/ directly (contrast with Windows9x or NT) Cannot have hard links across mount points: why? What about soft links? 4 . 11 IN-MEMORY TABLES Recall process sees files as file descriptors In implementation these are just indices into process-specific open file table Entries point to system-wide open file table. Why? These in turn point to (in memory) inode table 4 . 12 ACCESS CONTROL Access control information held in each inode Three bits for each of owner, group and world: read, write and execute What do these mean for directories? Read entry, write entry, traverse directory In addition have setuid and setgid bits: Normally processes inherit permissions of invoking user Setuid/setgid allow user to "become" someone else when running a given program E.g. prof owns both executable test (0711 and setuid), and score file (0600) 4 . 13 CONSISTENCY ISSUES To delete a file, use the unlink system call — from the shell, this is rm <filename> Procedure is: Check if user has sufficient permissions on the file (must have write access) Check if user has sufficient permissions on the directory (must have write access) If ok, remove entry from directory Decrement reference count on inode If now zero: free data blocks and free inode If crash: must check entire filesystem for any block unreferenced and any block double referenced Crash detected as OS knows if crashed because root fs not unmounted cleanly 4 .
Load more

Recommended publications
  • CSE 220: Systems Programming Input and Output
    CSE 220: Systems Programming Input and Output Ethan Blanton Department of Computer Science and Engineering University at Buffalo Introduction Unix I/O Standard I/O Buffering Summary References I/O Kernel Services We have seen some text I/O using the C Standard Library. printf() fgetc() … However, all I/O is built on kernel system calls. In this lecture, we’ll look at those services vs. standard I/O. © 2020 Ethan Blanton / CSE 220: Systems Programming Introduction Unix I/O Standard I/O Buffering Summary References Everything is a File These services are particularly important on Unix systems. On Unix, “everything is a file”. Many devices and services are accessed by opening device nodes. Device nodes behave like (but are not) files. Examples: /dev/null: Always readable, contains no data. Always writable, discards anything written to it. /dev/urandom: Always readable, reads a cryptographically secure stream of random data. © 2020 Ethan Blanton / CSE 220: Systems Programming Introduction Unix I/O Standard I/O Buffering Summary References File Descriptors All access to files is through file descriptors. A file descriptor is a small integer representing an open file in a particular process. There are three “standard” file descriptors: 0: standard input 1: standard output 2: standard error …sound familiar? (stdin, stdout, stderr) © 2020 Ethan Blanton / CSE 220: Systems Programming Introduction Unix I/O Standard I/O Buffering Summary References System Call Failures Kernel I/O (and most other) system calls return -1 on failure. When this happens, the global variable errno is set to a reason. Include errno.h to define errno in your code.
    [Show full text]
  • Introduction to Unix
    Introduction to Unix Rob Funk <[email protected]> University Technology Services Workstation Support http://wks.uts.ohio-state.edu/ University Technology Services Course Objectives • basic background in Unix structure • knowledge of getting started • directory navigation and control • file maintenance and display commands • shells • Unix features • text processing University Technology Services Course Objectives Useful commands • working with files • system resources • printing • vi editor University Technology Services In the Introduction to UNIX document 3 • shell programming • Unix command summary tables • short Unix bibliography (also see web site) We will not, however, be covering these topics in the lecture. Numbers on slides indicate page number in book. University Technology Services History of Unix 7–8 1960s multics project (MIT, GE, AT&T) 1970s AT&T Bell Labs 1970s/80s UC Berkeley 1980s DOS imitated many Unix ideas Commercial Unix fragmentation GNU Project 1990s Linux now Unix is widespread and available from many sources, both free and commercial University Technology Services Unix Systems 7–8 SunOS/Solaris Sun Microsystems Digital Unix (Tru64) Digital/Compaq HP-UX Hewlett Packard Irix SGI UNICOS Cray NetBSD, FreeBSD UC Berkeley / the Net Linux Linus Torvalds / the Net University Technology Services Unix Philosophy • Multiuser / Multitasking • Toolbox approach • Flexibility / Freedom • Conciseness • Everything is a file • File system has places, processes have life • Designed by programmers for programmers University Technology Services
    [Show full text]
  • Storage Devices, Basic File System Design
    CS162 Operating Systems and Systems Programming Lecture 17 Data Storage to File Systems October 29, 2019 Prof. David Culler http://cs162.eecs.Berkeley.edu Read: A&D Ch 12, 13.1-3.2 Recall: OS Storage abstractions Key Unix I/O Design Concepts • Uniformity – everything is a file – file operations, device I/O, and interprocess communication through open, read/write, close – Allows simple composition of programs • find | grep | wc … • Open before use – Provides opportunity for access control and arbitration – Sets up the underlying machinery, i.e., data structures • Byte-oriented – Even if blocks are transferred, addressing is in bytes What’s below the surface ?? • Kernel buffered reads – Streaming and block devices looks the same, read blocks yielding processor to other task • Kernel buffered writes Application / Service – Completion of out-going transfer decoupled from the application, File descriptor number allowing it to continue - an int High Level I/O streams • Explicit close Low Level I/O handles 9/12/19 The cs162file fa19 L5system abstraction 53 Syscall registers • File File System descriptors File Descriptors – Named collection of data in a file system • a struct with all the info I/O Driver Commands and Data Transfers – POSIX File data: sequence of bytes • about the files Disks, Flash, Controllers, DMA Could be text, binary, serialized objects, … – File Metadata: information about the file • Size, Modification Time, Owner, Security info • Basis for access control • Directory – “Folder” containing files & Directories – Hierachical
    [Show full text]
  • Absolute BSD—The Ultimate Guide to Freebsd Table of Contents Absolute BSD—The Ultimate Guide to Freebsd
    Absolute BSD—The Ultimate Guide to FreeBSD Table of Contents Absolute BSD—The Ultimate Guide to FreeBSD............................................................................1 Dedication..........................................................................................................................................3 Foreword............................................................................................................................................4 Introduction........................................................................................................................................5 What Is FreeBSD?...................................................................................................................5 How Did FreeBSD Get Here?..................................................................................................5 The BSD License: BSD Goes Public.......................................................................................6 The Birth of Modern FreeBSD.................................................................................................6 FreeBSD Development............................................................................................................7 Committers.........................................................................................................................7 Contributors........................................................................................................................8 Users..................................................................................................................................8
    [Show full text]
  • Linux Kernel and Driver Development Training Slides
    Linux Kernel and Driver Development Training Linux Kernel and Driver Development Training © Copyright 2004-2021, Bootlin. Creative Commons BY-SA 3.0 license. Latest update: October 9, 2021. Document updates and sources: https://bootlin.com/doc/training/linux-kernel Corrections, suggestions, contributions and translations are welcome! embedded Linux and kernel engineering Send them to [email protected] - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 1/470 Rights to copy © Copyright 2004-2021, Bootlin License: Creative Commons Attribution - Share Alike 3.0 https://creativecommons.org/licenses/by-sa/3.0/legalcode You are free: I to copy, distribute, display, and perform the work I to make derivative works I to make commercial use of the work Under the following conditions: I Attribution. You must give the original author credit. I Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. I For any reuse or distribution, you must make clear to others the license terms of this work. I Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. Document sources: https://github.com/bootlin/training-materials/ - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 2/470 Hyperlinks in the document There are many hyperlinks in the document I Regular hyperlinks: https://kernel.org/ I Kernel documentation links: dev-tools/kasan I Links to kernel source files and directories: drivers/input/ include/linux/fb.h I Links to the declarations, definitions and instances of kernel symbols (functions, types, data, structures): platform_get_irq() GFP_KERNEL struct file_operations - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 3/470 Company at a glance I Engineering company created in 2004, named ”Free Electrons” until Feb.
    [Show full text]
  • File and Console I/O
    File and Console I/O CS449 Spring 2016 What is a Unix(or Linux) File? • File: “a resource for storing information [sic] based on some kind of durable storage” (Wikipedia) • Wider sense: “In Unix, everything is a file.” (a.k.a “In Unix, everything is a stream of bytes.”) – Traditional files, directories, links – Inter-process communication (pipes, shared memory, sockets) – Devices (interactive terminals, hard drives, printers, graphic card) • Usually mounted under /dev/ directory – Process Links (for getting process information) • Usually mounted under /proc/ directory Stream of Bytes Abstraction • A file, in abstract, is a stream of bytes • Can be manipulated using five system calls: – open: opens a file for reading/writing and returns a file descriptor • File descriptor: index into an OS array called open file table – read: reads current offset through file descriptor – write: writes current offset through file descriptor – lseek: changes current offset in file – close: closes file descriptor • Some files do not support certain operations (e.g. a terminal device does not support lseek) C Standard Library Wrappers • C Standard Library wraps file system calls in library functions – For portability across multiple systems – To provide additional features (buffering, formatting) • All C wrappers buffered by default – Buffering can be controlled using “setbuf” or “setlinebuf” calls (remember those?) • Works on FILE * instead of file descriptor – FILE is a library data structure that abstracts a file – Contains file descriptor, current offset, buffering mode etc. Wrappers for the Five System Calls Function Prototype Description FILE *fopen(const char *path, const Opens the file whose name is the string pointed to char *mode); by path and associates a stream with it.
    [Show full text]
  • A Platform Architecture for Sensor Data Processing and Verification in Buildings
    A Platform Architecture for Sensor Data Processing and Verification in Buildings Jorge Ortiz Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2013-196 http://www.eecs.berkeley.edu/Pubs/TechRpts/2013/EECS-2013-196.html December 3, 2013 Copyright © 2013, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. A Platform Architecture for Sensor Data Processing and Verification in Buildings by Jorge Jose Ortiz A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor David E. Culler, Chair Professor Randy H. Katz Professor Paul Wright Fall 2013 A Platform Architecture for Sensor Data Processing and Verification in Buildings Copyright 2013 by Jorge Jose Ortiz 1 Abstract A Platform Architecture for Sensor Data Processing and Verification in Buildings by Jorge Jose Ortiz Doctor of Philosophy in Computer Science University of California, Berkeley Professor David E. Culler, Chair This thesis examines the state of the art of building information systems and evaluates their architecture in the context of emerging technologies and applications for deep analysis of the built environment.
    [Show full text]
  • Plan 9 from Bell Labs
    Plan 9 from Bell Labs “UNIX++ Anyone?” Anant Narayanan Malaviya National Institute of Technology FOSS.IN 2007 What is it? Advanced technology transferred via mind-control from aliens in outer space Humans are not expected to understand it (Due apologies to lisperati.com) Yeah Right • More realistically, a distributed operating system • Designed by the creators of C, UNIX, AWK, UTF-8, TROFF etc. etc. • Widely acknowledged as UNIX’s true successor • Distributed under terms of the Lucent Public License, which appears on the OSI’s list of approved licenses, also considered free software by the FSF What For? “Not only is UNIX dead, it’s starting to smell really bad.” -- Rob Pike (circa 1991) • UNIX was a fantastic idea... • ...in it’s time - 1970’s • Designed primarily as a “time-sharing” system, before the PC era A closer look at Unix TODAY It Works! But that doesn’t mean we don’t develop superior alternates GNU/Linux • GNU’s not UNIX, but it is! • Linux was inspired by Minix, which was in turn inspired by UNIX • GNU/Linux (mostly) conforms to ANSI and POSIX requirements • GNU/Linux, on the desktop, is playing “catch-up” with Windows or Mac OS X, offering little in terms of technological innovation Ok, and... • Most of the “modern ideas” we use today were “bolted” on an ancient underlying system • Don’t believe me? A “modern” UNIX Terminal Where did it go wrong? • Early UNIX, “everything is a file” • Brilliant! • Only until people started adding “features” to the system... Why you shouldn’t be working with GNU/Linux • The Socket API • POSIX • X11 • The Bindings “rat-race” • 300 system calls and counting..
    [Show full text]
  • [11] Case Study: Unix
    [11] CASE STUDY: UNIX 1 . 1 OUTLINE Introduction Design Principles Structural, Files, Directory Hierarchy Filesystem Files, Directories, Links, On-Disk Structures Mounting Filesystems, In-Memory Tables, Consistency IO Implementation, The Buffer Cache Processes Unix Process Dynamics, Start of Day, Scheduling and States The Shell Examples, Standard IO Summary 1 . 2 INTRODUCTION Introduction Design Principles Filesystem IO Processes The Shell Summary 2 . 1 HISTORY (I) First developed in 1969 at Bell Labs (Thompson & Ritchie) as reaction to bloated Multics. Originally written in PDP-7 asm, but then (1973) rewritten in the "new" high-level language C so it was easy to port, alter, read, etc. Unusual due to need for performance 6th edition ("V6") was widely available (1976), including source meaning people could write new tools and nice features of other OSes promptly rolled in V6 was mainly used by universities who could afford a minicomputer, but not necessarily all the software required. The first really portable OS as same source could be built for three different machines (with minor asm changes) Bell Labs continued with V8, V9 and V10 (1989), but never really widely available because V7 pushed to Unix Support Group (USG) within AT&T AT&T did System III first (1982), and in 1983 (after US government split Bells), System V. There was no System IV 2 . 2 HISTORY (II) By 1978, V7 available (for both the 16-bit PDP-11 and the new 32-bit VAX-11). Subsequently, two main families: AT&T "System V", currently SVR4, and Berkeley: "BSD", currently 4.4BSD Later standardisation efforts (e.g.
    [Show full text]
  • Workstation Operating Systems Mac OS 9
    15-410 “Now that we've covered the 1970's...” Plan 9 Nov. 25, 2019 Dave Eckhardt 1 L11_P9 15-412, F'19 Overview “The land that time forgot” What style of computing? The death of timesharing The “Unix workstation problem” Design principles Name spaces File servers The TCP file system... Runtime environment 3 15-412, F'19 The Land That Time Forgot The “multi-core revolution” already happened once 1982: VAX-11/782 (dual-core) 1984: Sequent Balance 8000 (12 x NS32032) 1985: Encore MultiMax (20 x NS32032) 1990: Omron Luna88k workstation (4 x Motorola 88100) 1991: KSR1 (1088 x KSR1) 1991: “MCS” paper on multi-processor locking algorithms 1995: BeBox workstation (2 x PowerPC 603) The Land That Time Forgot The “multi-core revolution” already happened once 1982: VAX-11/782 (dual-core) 1984: Sequent Balance 8000 (12 x NS32032) 1985: Encore MultiMax (20 x NS32032) 1990: Omron Luna88k workstation (4 x Motorola 88100) 1991: KSR1 (1088 x KSR1) 1991: “MCS” paper on multi-processor locking algorithms 1995: BeBox workstation (2 x PowerPC 603) Wow! Why was 1995-2004 ruled by single-core machines? What operating systems did those multi-core machines run? The Land That Time Forgot Why was 1995-2004 ruled by single-core machines? In 1995 Intel + Microsoft made it feasible to buy a fast processor that fit on one chip, a fast I/O bus, multiple megabytes of RAM, and an OS with memory protection. Everybody could afford a “workstation”, so everybody bought one. Massive economies of scale existed in the single- processor “Wintel” universe.
    [Show full text]
  • Linux and GNU
    Operating systems Operating systems UNIX, Linux PhD Damian Radziewicz Wrocław 2017 Unix, MINIX and GNU/Linux system basics, licensing and history devices and device drivers internal structure of the ext filesystem proc filesystem mounting other filesystems shell programming and simple Bash scripts network communications OS brief history [1st lecture reminder] 1969: work started on Unix. Space Travel game, written by Jeremy Ben for Multics, then ported to FORTRAN running on the GE635; then ported by J. Ben and Dennis Ritchie in PDP-7 assembly language. Porting the Space Travel game to the PDP-7 computer was the beginning of Unix. The date: January 1, 1970 00:00:00 UTC is the beginning of Unix Epoch and is used until now in POSIX. 1981: MS-DOS 1984: GNU project started 1989: SCO UNIX, WWW 1991: Linux kernel Source: http://en.wikipedia.org/wiki/Dennis_Ritchie 1992: Solaris; Windows 3.1 Dennis MacAlistair 1993: Windows NT 3.1; Ritchie—notable for Debian GNU/Linux developing C and for 2001: Windows XP having influence on 2008: Google Android; other programming 2009: Windows 7 languages, as well ‘UNIX is basically a simple operating system, as operating but you have to be a genius to understand systems such as the simplicity’ Multics and Unix. Source: www.meetdageeks.com Dennis Ritchie (right) with Ken Thompson Unix written in 1969 (assembler) at AT&T re-written in the C in 1973 (D. Ritchie) easier portability across hardware platforms academic world: BSD (Berkeley Software Distribution) Berkeley sockets (or BSD sockets) API for Internet communication de facto world standard until now today: mainly open-source versions: FreeBSD, NetBSD, OpenBSD, closed-source products: HP/UX, AIX, MacOS MINIX Unix-like system written by A.
    [Show full text]
  • Ten Steps to Linux Survival
    Ten Steps to Linux Survival Bash for Windows People Jim Lehmer 2015 Steps List of Figures 5 -1 Introduction 13 Batteries Not Included .............................. 14 Please, Give (Suggestions) Generously ...................... 15 Why? ........................................ 15 Caveat Administrator ............................... 17 Conventions .................................... 17 How to Get There from Here ........................... 19 Acknowledgments ................................. 20 0 Some History 21 Why Does This Matter? .............................. 23 Panic at the Distro ................................. 25 Get Embed With Me ................................ 26 Cygwin ....................................... 26 1 Come Out of Your Shell 29 bash Built-Ins .................................... 30 Everything You Know is (Almost) Wrong ..................... 32 You’re a Product of Your Environment (Variables) . 35 Who Am I? .................................. 36 Paths (a Part of Any Balanced Shrubbery) .................... 37 Open Your Shell and Interact ........................... 38 Getting Lazy .................................... 39 2 File Under ”Directories” 43 Looking at Files .................................. 44 A Brief Detour Around Parameters ........................ 46 More Poking at Files ............................... 47 Sorting Things Out ................................ 51 Rearranging Deck Chairs ............................. 55 Making Files Disappear .............................. 56 2 touch Me .....................................
    [Show full text]