DOCSLIB.ORG

System Administration Mtat.08.021 Extra Material 1: Unix File Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

SYSTEM ADMINISTRATION MTAT.08.021 EXTRA MATERIAL 1: UNIX FILE SYSTEMS PREPARED BY AMNIR HADACHI, ARTJOM LIND AND ANDRE TÄTTAR UNIVERSITY OF TARTU, INSTITUTE OF COMPUTER SCIENCE UNIX FILE SYSTEMS OUTLINE • Definition of file systems • Everything is a file • File types • File system hierarchy tree • Understanding file system • Navigating Linux file system • Paths / Mount / Mount point / Permanent Mount • Files in Unix • File names in Unix • Ownership and permissions • Partitions UNIX FILE SYSTEMS DEFINITIONS OF FILE SYSTEMS • First definition: • Directory tree: is a hierarchy of directories that consists of a single directory. • Second definition: • File system: is the way in which files are named and organized in their appropriate and logical place for storage and retrieval. EXAMPLE 3.1: "Linux Filesystem is stored on multiple partitions." vs "Should I use ext4 or ntfs for my multimedia usb?" UNIX FILE SYSTEM EVERYTHING IS A FILE QUOTE 4.1: “Everything is a File” EXAMPLE 4.1: “primary hard drive appears as a file / dev/sda and also all directories are files” QUOTE 4.2: “If it is not a file then it is a process” UNIX FILE SYSTEM EVERYTHING IS A FILE • File types: • Regular files (-) • Directories (d) • Special files (c) • Links (l) • Domains / sockets (s) CAPTION: COMPARISON OF FILE TYPES IN ROOT(/) VS /DEV VS HOME(~) • Named pipes (p) • Block device (b) UNIX FILE SYSTEM EVERYTHING IS A FILE • Special file examples: EXAMPLE 6.1: “/dev/null” discards all data written to it, like a black hole. It is implemented in software and does not map to a hard drive on your system. QUOTE: "Please Send complaints to / dev/null" MEANING: A NICE WAY TO SAY THROW IT IN THE GARBAGE EXAMPLE 6.2: “/dev/zero” produces infinite stream of zeros, good for wiping hard drives. EXAMPLE 6.3: “/dev/random” produces stream of random numbers generated from background noise. UNIX FILE SYSTEM FILE SYSTEM HIERARCHY TREE UNIX FILE SYSTEM UNDERSTANDING FILE SYSTEM • From Humans prospective: • file systems is a hierarchical tree • From kernel prospective: • file system is a flat tree. REMARK 8.1: Kernel does not differentiate between directories, files and programs. It identify files not by names but by inodes. DEFINITION 8.1: An inode is a data structure on a filesystem on Linux that stores all the information about a file except its name and its actual data. EXAMPLE 8.1: “Inode" structure: 1) inode number (unique id) 2) file owner and group 3) file type 4) file permission list 5) File creation, access and modification times 6) Size of the file 7) disk address (identifier for where the file is physically stored) UNIX FILE SYSTEM NAVIGATING LINUX FILE SYSTEM • Root directory “/” • Home directory “~” • Parent directory “..” • Sub-directory “/home/user” is sub-dir of “/home” • Current directory “.” UNIX FILE SYSTEM PATHS • Absolute Path: DEFINITION 10.1: The absolute path is a full path which contains the root directory and all other subdirectories in which a file or folder is contained. • Always start with “/” EXAMPLE 10.1: “/home/user/Desktop/Files/index.html” • Relative Path: DEFINITION 10.2: A relative path (partial path or non absolute path) is only a portion of the full path. EXAMPLE 10.2: - bin/gcc (Used when pwd = /usr) - ./bin/gcc (Used when pwd = /usr) - ../bin/gcc (Used when pwd = /usr/lib) UNIX FILE SYSTEM MOUNT / MOUNT POINT • Mount Command DEFINITION 11.1: Mount command makes block device file system a part of the root file system, so you can access the data. EXAMPLE 11.1: Manually Mounting “$ mount -t ext4 /dev/sdb1 /mnt/my_usb” (some OS's do it automatically) DEFINITION 11.2: A mount point is a directory in the currently accessible filesystem on which an additional filesystem is mounted REMARK 11.1: Mount options are Block devices(HDD, SSD, SDcard, CD-ROM) and also network share filesystems like nfs REMARK 11.2: “Will be Covered in bash extra material” Important commands for mounts: mount, df -h, lsblk, fdisk -l and many more UNIX FILE SYSTEM MOUNT POINTS UNIX FILE SYSTEM PERMANENT MOUNT REMARK 13.1: Configured using the /etc/fstab file - To remount, after inserting lines, use command mount -a UNIX FILE SYSTEM FILES IN UNIX UNIX FILE SYSTEM FILE NAME IN UNIX • Case sensitive • Hidden file start with “.” • File name max length = 255 bytes • File path max length = None • Reserved characters: & ; | * ? ` " [ ] ( ) $ < > { } % ! # @ \ • Escaping reserved chars With '\' \( \) \! \\ UNIX FILE SYSTEM OWNERSHIP AND PERMISSIONS • Three Ownership types: (Owner, Group, Others) REMARK 16.1: Owner These permissions apply only to owner of the file or directory REMARK 16.2: Group These permissions apply only to the group that has been assigned to the file or directory REMARK 16.3: Others There permissions apply to all other users on the system. Important for security • Three Permission types: (Read, Write, Execute) REMARK 16.4: Read User can read the contents of the file REMARK 16.5: Write User can write or modify the contents of the file REMARK 16.6: Execute User can execute file or view contents of a directory UNIX FILE SYSTEM OWNERSHIP AND PERMISSION UNIX FILE SYSTEM PERMISSIONS MANAGEMENT UNIX FILE SYSTEM PARTITIONS • Data Partition DEFINITION 19.1: Data partition is a logical division of hard disk, that include the OS system data, root partition and all the data to ensure the start up and run of the system. • Swap Partition DEFINITION 19.2: Swap partition is the expansion of the computer’s physical memory and it acts as a overflow for the memory. UNIX FILE SYSTEM PARTITIONS • Partitioning is an essential task • Partitioning configuration is stored in partition table. EXAMPLE 20.1: Popular options for storing partitioning information DOS partition table GPT (GUID Partition Table) or (Globally Unique Identifiers Partition Table) UNIX FILE SYSTEM STICKY BITS CASE DESCRIPTION 21.1: So far, it is clear that we can control the read/write/execute on file and read/write/list on directory. Now, if we allow to write to directory - this means that we also allow to remove from directory. Moreover, “o+rwx" on directory means anyone can remove anything. What if I want to allow anyone to write to directory; however, removing process can be only allowed to the files and directories created by the concerned users themselves and at the same time they cannot remove the existing random files. “Looks like impossible task considering classic UNIX permission schema ?” The solution to our case that we can suggest is called "sticky bit" SOLUTION To add sticky bit: “chmod +t dir” To remove sticky bit: “chmod -t dir” REMARK 21.1: Make sure that it has en effect if directory is allowed to write by many users, so either g+w or o +w or both were given on the directory. If the directory is only writable by owner user (u+w) - the sticky bit is useless. UNIX FILE SYSTEM FORCING GROUP ID CHANGE ON EXCISION CASE DESCRIPTION 22.1: let’s suppose we have a directory called “dir” and it has the following ownership and permission: drwxrwxr-x userA.G1 dir we see that our directory is owned by userA and it is associated to group G1. Moreover, any user who belongs to group G1 can read, write and execute commands in the “dir”. In addition we suppose that the userA has G1 a his primary group. Now if we have another userB who belongs to group G1 and group G2, plus having G2 as primary group. What happen if userA create a file and also userB did the same? What happened if the same case as previous question happened with a small change in the ownership and permission of the “dir” (drwxrwsr-x)? REMARK 22.1: The “s” approving in the group persimmon is the result of command “chmod g+s” on directory “dir”. chmod g+s dir UNIX FILE SYSTEM FORCING GROUP ID CHANGE ON EXCISION SOLUTION First question: when the userA create the file1 in directory “dir” the results ownership and permission of the new file will be: -rw-rw-r— userA.G1 and for the file2 created by userB will be: -rw-rw-r— userB.G2 REMARK 23.1: As you can in this case the user ownership of the created files is assigned directly to the primary group of each user. UNIX FILE SYSTEM FORCING GROUP ID CHANGE ON EXCISION SOLUTION Second question: when the userA create the file1 in directory “dir” the results ownership and permission of the new file will be: -rw-rw-r— userA.G1 and for the file2 created by userB will be: -rw-rw-r— userB.G1 REMARK 24.1: As you can in this case the user ownership of the created files for both users is group G1, due to the fact that the directory “dir” has a group ownership G1 and “chmod g+s” was given. This latter, means that before executing any command within the directory “dir” the group ID of user is changed to the one of the directory “dir”. UNIX FILE SYSTEM ASSIGNING EXECUTABLE BIT RECURSIVELY BUT TO DIRECTORIES ONLY CASE DESCRIPTION 25.1: let’s suppose in this case that we executed: “chmod -R go+x dir” this command will go recursively through directory “dir” assigning “chmod go+x” to all content of “dir” including files and directories. But, what if we want to assign “go+x” to all the directories inside the “dir” and not to the files? SOLUTION First solution: we may issue find command to find all the directories and for each execute “chmod go+x”. find dir -type d -exec chmod go+x {} \; Second solution: Or we just issue the following command: chmod go+X dir which will do the same..
Recommended publications
  • CSE 220: Systems Programming Input and Output

    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.
  • Software Distributor Administration Guide for HP-UX 11I

    Software Distributor Administration Guide for HP-UX 11I

    Software Distributor Administration Guide for HP-UX 11i HP Computers Manufacturing Part Number: B2355-90754 June 2002, Edition 3 © Copyright 2002 Hewlett-Packard Company. Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material. Warranty A copy of the specific warranty terms applicable to your Hewlett-Packard product and replacement parts can be obtained from your local Sales and Service Office. Restricted Rights Legend Use, duplication or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 for DOD agencies, and subparagraphs (c) (1) and (c) (2) of the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 for other agencies. HEWLETT-PACKARD COMPANY 3000 Hanover Street Palo Alto, California 94304 U.S.A. Use of this document and any supporting software media supplied for this pack is restricted to this product only. Additional copies of the programs may be made for security and back-up purposes only. Resale of the programs, in their present form or with alterations, is expressly prohibited. Copyright Notice Copyright 1997-2002 Hewlett-Packard Company. All rights reserved.
  • Introduction to Unix

    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
  • Storage Devices, Basic File System Design

    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
  • File Permissions Do Not Restrict Root

    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
  • Linux Kernel and Driver Development Training Slides

    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.
  • File and Console I/O

    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.
  • Interesting Things You Didn't Know You Could Do With

    Interesting Things You Didn't Know You Could Do With

    Interesting Things You Didn’t Know You Could Do With ZFS Allan Jude -- ScaleEngine Inc. [email protected] twitter: @allanjude Introduction Allan Jude ● 13 Years as FreeBSD Server Admin ● FreeBSD src/doc committer (focus: ZFS, bhyve, ucl, xo) ● Co-Author of “FreeBSD Mastery: ZFS” and upcoming “FreeBSD Mastery: Advanced ZFS” with M. W. Lucas ● Architect of the ScaleEngine CDN (HTTP and Video) ● Host of BSDNow.tv & TechSNAP.tv Podcasts ● Use ZFS for large collections of videos, extremely large website caches, mirrors of PC-BSD pkgs and RaspBSD ● Single Handedly Manage Over 1000TB of ZFS Storage The Power of ZFS ● Integrated Redundancy (Mirroring, RAID-Z) ● Data Integrity Checking (Checksums, Scrub) ● Pooled Storage (Hot Add Disks) ● Multi-Level Cache (ARC, L2ARC, SLOG) ● Copy-on-Write (no fsck) ● Snapshots and Clones ● Quotas and Reservations ● Transparent Compression (LZ4, GZIP1-9) ● Incremental Replication (zfs send/recv) ● Datasets with Individual Inherited Properties ● Custom Properties ● Fine Grained Delegation Applying That Power ZFS has many features, but how can I use them to solve my problems? ZFS has a very well designed command line user interface, making it very easy for a sysadmin to perform common tasks (add more storage, create new datasets, change settings and properties), accomplish things that were not possible before, as well as extract a great deal more information from the storage system. ZFS Was Meant To Be Scripted # zfs list -Hp -r -o name,refer,logicalreferenced sestore5/mysql02 22001288628 24331078144 sestore5/omicron
  • A Platform Architecture for Sensor Data Processing and Verification in Buildings

    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.
  • Plan 9 from Bell Labs

    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..
  • Workstation Operating Systems Mac OS 9

    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.
  • Linux and GNU

    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.