Mac OS X for UNIX Users the Power of UNIX with the Simplicity of Macintosh
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Apple Software Design Guidelines
Apple Software Design Guidelines May 27, 2004 Java and all Java-based trademarks are Apple Computer, Inc. trademarks or registered trademarks of Sun © 2004 Apple Computer, Inc. Microsystems, Inc. in the U.S. and other All rights reserved. countries. OpenGL is a trademark of Silicon Graphics, No part of this publication may be Inc. reproduced, stored in a retrieval system, or transmitted, in any form or by any means, PowerPC and and the PowerPC logo are mechanical, electronic, photocopying, trademarks of International Business recording, or otherwise, without prior Machines Corporation, used under license written permission of Apple Computer, Inc., therefrom. with the following exceptions: Any person Simultaneously published in the United is hereby authorized to store documentation States and Canada. on a single computer for personal use only Even though Apple has reviewed this manual, and to print copies of documentation for APPLE MAKES NO WARRANTY OR personal use provided that the REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS MANUAL, documentation contains Apple's copyright ITS QUALITY, ACCURACY, notice. MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. AS A RESULT, THIS The Apple logo is a trademark of Apple MANUAL IS SOLD ªAS IS,º AND YOU, THE PURCHASER, ARE ASSUMING THE ENTIRE Computer, Inc. RISK AS TO ITS QUALITY AND ACCURACY. Use of the ªkeyboardº Apple logo IN NO EVENT WILL APPLE BE LIABLE FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, (Option-Shift-K) for commercial purposes OR CONSEQUENTIAL DAMAGES without the prior written consent of Apple RESULTING FROM ANY DEFECT OR may constitute trademark infringement and INACCURACY IN THIS MANUAL, even if advised of the possibility of such damages. -
Advancing Mac OS X Rootkit Detecron
Advancing Mac OS X Rootkit Detec4on Andrew Case (@attrc) Volatility Foundation Golden G. Richard III (@nolaforensix) University of New Orleans 2 hot research areas State of Affairs more established Live Forensics and Tradional Storage Memory Analysis Forensics Digital Forensics Reverse Engineering Incident Response Increasingly encompasses all the others Copyright 2015 by Andrew Case and Golden G. Richard III 3 Where’s the Evidence? Files and Filesystem Applica4on Windows Deleted Files metadata metadata registry Print spool Hibernaon Temp files Log files files files Browser Network Slack space Swap files caches traces RAM: OS and app data Volale Evidence structures Copyright 2015 by Andrew Case and Golden G. Richard III 4 Volale Evidence 1 011 01 1 0 1 111 0 11 0 1 0 1 0 10 0 1 0 1 1 1 0 0 1 0 1 1 0 0 1 Copyright 2015 by Andrew Case and Golden G. Richard III 5 Awesomeness Progression: File Carving Can carve Chaos: files, but More can't Faster Almost not very accurate Hurray! carve files well Tools Manual File type Fragmentaon, appear, MulDthreading, hex editor aware damned but have beer design stuff carving, et al spinning disks! issues Images: hLps://easiersaidblogdotcom.files.wordpress.com/2013/02/hot_dogger.jpg hLp://cdn.bigbangfish.com/555/Cow/Cow-6.jpg, hLp://f.tqn.com/y/bbq/1/W/U/i/Big_green_egg_large.jpg hLp://i5.walmarDmages.com/dfw/dce07b8c-bb22/k2-_95ea6c25-e9aa-418e-a3a2-8e48e62a9d2e.v1.jpg Copyright 2015 by Andrew Case and Golden G. Richard III 6 Awesomeness Progression: Memory Forensics Pioneering Chaos: More, efforts Beyond run more, show great Windows ?? strings? more promise pt_finder et al More aenDon Manual, Mac, … awesome but to malware, run strings, Linux, BSD liLle context limited filling in the gaps funcDonality Images: hLps://s-media-cache-ak0.pinimg.com/736x/75/5a/37/755a37727586c57a19d42caa650d242e.jpg,, hLp://img.photobucket.com/albums/v136/Hell2Pay77/SS-trucks.jpg hLp://skateandannoy.com/wp-content/uploads/2007/12/sportsbars.jpg, hLp://gainesvillescene.com/wp-content/uploads/2013/03/dog-longboard.jpg Copyright 2015 by Andrew Case and Golden G. -
Chapter 1. Origins of Mac OS X
1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years. -
Kqueue Madness Have to Ponder These Questions Or Write a Began
Kqueuemadness by Randall Stewart ome time ago I was asked to participate in the creation of a Performance SEnhancing Proxy (PEP) for TCP. The concept behind a PEP is to split a TCP connec- tion into three separate connections. The first connection (1) is the normal TCP con- nection that goes from the client towards the server (the client is usually unaware that its connection is not going to the end server). The next connection (2) goes between two middle boxes (M1 and M2), the first middle box (M1) terminates the connection of the client pretending to be the server and uses a different connection to talk to the tail middle box (M2). This middle connection provides the “enhanced” service to the end-to-end connection. The final connection (3) goes between the tail middle box (M2) and the actual server. The figure below shows a diagram of such a connection. A connection (1) (2) (3) through a PEP Client M1 M2 Server 24 FreeBSD Journal Now, as you can imagine, if you have a very event for a socket descriptor, yet do not close busy PEP you could end up with thousands of the socket? TCP connections being managed by M1 and b) Could I possibly see stale queued events M2. In such an environment using poll(2) or that were yet to be read? select(2) comes with an extreme penalty. Each c) How does connect interact with kqueue? time a I/O event completes, every one of those d) What about listen? thousands of connections would need to be e) What is the difference between all of the looked at to see if an event occurred on them, kqueue flags that I can add on to events and and then the appropriate structure would need when do I use them properly? to be reset to look for an event next time. -
Efficient Parallel I/O on Multi-Core Architectures
Lecture series title/ lecture title Efficient parallel I/O on multi-core architectures Adrien Devresse CERN IT-SDC-ID Thematic CERN School of Computing 2014 1 Author(s) names – Affiliation Lecture series title/ lecture title How to make I/O bound application scale with multi-core ? What is an IO bound application ? → A server application → A job that accesses big number of files → An application that uses intensively network 2 Author(s) names – Affiliation Lecture series title/ lecture title Stupid example: Simple server monothreaded // create socket socket_desc = socket(AF_INET , SOCK_STREAM , 0); // bind the socket bind(socket_desc,(struct sockaddr *)&server , sizeof(server)); listen(socket_desc , 100); //accept connection from an incoming client while(1){ // declarations client_sock = accept(socket_desc, (struct sockaddr *)&client, &c); //Receive a message from client while( (read_size = recv(client_sock , client_message , 2000 , 0)) > 0{ // Wonderful, we have a client, do some useful work std::string msg("hello bob"); write(client_sock, msg.c_str(), msg.size()); } } 3 Author(s) names – Affiliation Lecture series title/ lecture title Stupid example: Let's make it parallel ! int main(int argc, char** argv){ // creat socket void do_work(int socket){ socket_desc = socket(AF_INET , SOCK_STREAM , 0); //Receive a message while( (read_size = // bind the socket recv(client_sock , bind(socket_desc, server , sizeof(server)); client_message , 2000 , 0)) > 0{ listen(socket_desc , 100); // Wonderful, we have a client // useful works //accept connection -
Mac OS X and PDF: the Real Story
Mac OS X and PDF The Real Story Leonard Rosenthol Lazerware, Inc. Copyright©1999-2001, Lazerware, Inc. Overview •Mac OS X •PDF • Where’s the overlap? Copyright©1999-2001, Lazerware, Inc. You are here because… • You’re currently working with Mac OS and are interested in what Mac OS X brings to the table. • You’re curious about what Apple’s latest hype is all about. • You’re already awake and had to find something to kill time. • You’re a friend of mine and wanted to heckle Copyright©1999-2001, Lazerware, Inc. How I do things • You should all have copies of the presentation that you received when you walked in. • There is also an electronic copy of this presentation (PDF format, of course!) on my website at http://www.lazerware.com/ • I’ve left time at the end for Q&A, but please feel free to ask questions at any time! Copyright©1999-2001, Lazerware, Inc. Mac OS X Overview Copyright©1999-2001, Lazerware, Inc. Darwin • “Core OS” (Kernel) – Solid Unix foundation • FreeBSD 3.2 & Mach 3.0 • Memory protection, preemptive multitasking, etc. – High performance I/O • Firewire, USB, etc. • Open source Copyright©1999-2001, Lazerware, Inc. Graphics •Quartz – Adobe Imaging Model (PDF) • Includes full anti-aliasing and opacity/transparency • OpenGL – Industry standard 3D engine used by Quake & Maya • QuickTime Copyright©1999-2001, Lazerware, Inc. Graphics Demos - Quartz Copyright©1999-2001, Lazerware, Inc. Graphics Demos – OpenGL Copyright©1999-2001, Lazerware, Inc. Application Frameworks • Classic – Compatibility “box” for existing Mac OS applications. • Carbon – Modern versions of Mac OS applications prepared for Mac OS X. -
Package 'Filelock'
Package ‘filelock’ October 5, 2018 Title Portable File Locking Version 1.0.2 Author Gábor Csárdi Maintainer Gábor Csárdi <[email protected]> Description Place an exclusive or shared lock on a file. It uses 'LockFile' on Windows and 'fcntl' locks on Unix-like systems. License MIT + file LICENSE LazyData true URL https://github.com/r-lib/filelock#readme BugReports https://github.com/r-lib/filelock/issues RoxygenNote 6.0.1.9000 Suggests callr (>= 2.0.0), covr, testthat Encoding UTF-8 NeedsCompilation yes Repository CRAN Date/Publication 2018-10-05 10:30:12 UTC R topics documented: lock .............................................2 Index 5 1 2 lock lock Advisory File Locking and Unlocking Description There are two kinds of locks, exclusive and shared, see the exclusive argument and other details below. Usage lock(path, exclusive = TRUE, timeout = Inf) unlock(lock) Arguments path Path to the file to lock. If the file does not exist, it will be created, but the directory of the file must exist. Do not place the lock on a file that you want to read from or write to! *Always use a special lock file. See details below. exclusive Whether to acquire an exclusive lock. An exclusive lock gives the process ex- clusive access to the file, no other processes can place any kind of lock on it. A non-exclusive lock is a shared lock. Multiple processes can hold a shared lock on the same file. A process that writes to a file typically requests an exclusive lock, and a process that reads from it typically requests a shared lock. -
Managing Network File Systems in Oracle® Solaris 11.4
Managing Network File Systems in ® Oracle Solaris 11.4 Part No: E61004 August 2021 Managing Network File Systems in Oracle Solaris 11.4 Part No: E61004 Copyright © 2002, 2021, Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract. -
Fsmonitor: Scalable File System Monitoring for Arbitrary Storage Systems
FSMonitor: Scalable File System Monitoring for Arbitrary Storage Systems Arnab K. Paul∗, Ryan Chardy, Kyle Chardz, Steven Tueckez, Ali R. Butt∗, Ian Fostery;z ∗Virginia Tech, yArgonne National Laboratory, zUniversity of Chicago fakpaul, [email protected], frchard, [email protected], fchard, [email protected] Abstract—Data automation, monitoring, and management enable programmatic management, and even autonomously tools are reliant on being able to detect, report, and respond manage the health of the system. Enabling scalable, reliable, to file system events. Various data event reporting tools exist for and standardized event detection and reporting will also be of specific operating systems and storage devices, such as inotify for Linux, kqueue for BSD, and FSEvents for macOS. How- value to a range of infrastructures and tools, such as Software ever, these tools are not designed to monitor distributed file Defined CyberInfrastructure (SDCI) [14], auditing [9], and systems. Indeed, many cannot scale to monitor many thousands automating analytical pipelines [11]. Such systems enable of directories, or simply cannot be applied to distributed file automation by allowing programs to respond to file events systems. Moreover, each tool implements a custom API and and initiate tasks. event representation, making the development of generalized and portable event-based applications challenging. As file systems Most storage systems provide mechanisms to detect and grow in size and become increasingly diverse, there is a need report data events, such as file creation, modification, and for scalable monitoring solutions that can be applied to a wide deletion. Tools such as inotify [20], kqueue [18], and FileSys- range of both distributed and local systems. -
Portalocker Documentation Release 2.3.2
Portalocker Documentation Release 2.3.2 Rick van Hattem Aug 27, 2021 CONTENTS 1 portalocker - Cross-platform locking library1 1.1 Overview.................................................1 1.2 Redis Locks...............................................1 1.3 Python 2.................................................2 1.4 Tips....................................................2 1.5 Links...................................................2 1.6 Examples.................................................3 1.7 Versioning................................................4 1.8 Changelog................................................4 1.9 License..................................................4 1.9.1 portalocker package.......................................4 1.9.1.1 Submodules......................................4 1.9.1.2 Module contents....................................9 1.9.2 tests package.......................................... 13 1.9.2.1 Module contents.................................... 13 1.9.3 License............................................. 13 2 Indices and tables 15 Python Module Index 17 Index 19 i ii CHAPTER ONE PORTALOCKER - CROSS-PLATFORM LOCKING LIBRARY 1.1 Overview Portalocker is a library to provide an easy API to file locking. An important detail to note is that on Linux and Unix systems the locks are advisory by default. By specifying the -o mand option to the mount command it is possible to enable mandatory file locking on Linux. This is generally not recommended however. For more information about the subject: • https://en.wikipedia.org/wiki/File_locking -
Real-Time Audio Servers on BSD Unix Derivatives
Juha Erkkilä Real-Time Audio Servers on BSD Unix Derivatives Master's Thesis in Information Technology June 17, 2005 University of Jyväskylä Department of Mathematical Information Technology Jyväskylä Author: Juha Erkkilä Contact information: [email protected].fi Title: Real-Time Audio Servers on BSD Unix Derivatives Työn nimi: Reaaliaikaiset äänipalvelinsovellukset BSD Unix -johdannaisjärjestelmissä Project: Master's Thesis in Information Technology Page count: 146 Abstract: This paper covers real-time and interprocess communication features of 4.4BSD Unix derived operating systems, and especially their applicability for real- time audio servers. The research ground of bringing real-time properties to tradi- tional Unix operating systems (such as 4.4BSD) is covered. Included are some design ideas used in BSD-variants, such as using multithreaded kernels, and schedulers that can provide real-time guarantees to processes. Factors affecting the design of real- time audio servers are considered, especially the suitability of various interprocess communication facilities as mechanisms to pass audio data between applications. To test these mechanisms on a real operating system, an audio server and a client utilizing these techniques is written and tested on an OpenBSD operating system. The performance of the audio server and OpenBSD is analyzed, with attempts to identify some bottlenecks of real-time operation in the OpenBSD system. Suomenkielinen tiivistelmä: Tämä tutkielma kattaa reaaliaikaisuus- ja prosessien väliset kommunikaatio-ominaisuudet, keskittyen 4.4BSD Unix -johdannaisiin käyt- töjärjestelmiin, ja erityisesti siihen kuinka hyvin nämä soveltuvat reaaliaikaisille äänipalvelinsovelluksille. Tutkimusalueeseen sisältyy reaaliaikaisuusominaisuuk- sien tuominen perinteisiin Unix-käyttöjärjestelmiin (kuten 4.4BSD:hen). Mukana on suunnitteluideoita, joita on käytetty joissakin BSD-varianteissa, kuten säikeis- tetyt kernelit, ja skedulerit, jotka voivat tarjota reaaliaikaisuustakeita prosesseille. -
Design and Implementation of XNU Port of Lustre Client File System
Design and Implementation of XNU port of Lustre Client File System Danilov Nikita 2005.02.01 Abstract Describes structure of Lustre client file system module for XNU (Darwin kernel). In particular, changes that were necessary in core XNU kernel to enable unique Lustre requirements (e.g., intents) are discussed in much detail. Changes to the platform-independent core of Lustre in order to make it more portable are discussed in the companion paper Lustre Universal Portability Specification. Contents 1 Introduction 2 2 Distribution 3 3 Backgroundon XNU 3 3.1 XNUVFS.......................................... ......... 3 3.1.1 namei()....................................... ......... 4 3.1.2 vnodelifecycle ................................ ........... 6 3.2 XNUpagecache.................................... ........... 6 3.3 XNUSynchronization .............................. ............. 7 3.4 Miscellania..................................... ............. 9 4 High Level Design 9 4.1 XLLIntentHandling ............................... ............. 9 4.1.1 Requirements .................................. .......... 9 4.1.2 FunctionalSpecification . .............. 10 4.1.3 UseCases ...................................... ........ 10 4.1.4 LogicalSpecification . ............. 11 4.1.5 StateSpecification ......................... .... ............ 12 4.2 Sessions........................................ ............ 12 4.2.1 Requirements .................................. .......... 12 4.2.2 FunctionalSpecification . .............. 12 4.2.3 UseCases .....................................