讀書人

他(熊十力)服膺王船山哲學,將其概括為,[尊生以箴寂滅,明有以反空無,主動以起頹廢,率性以一情欲;又以類似的語言概括自己的哲學:[吾平生之學,窮探大乘,而通之於<易>。尊生而不可溺寂,彰有而不可耽空,健動而不可頹廢,率性而無事絕欲。此<新唯識論>所以有作,而實根柢<大易>以出也。魏晉人祖尚虛無,承柱下之流風,變而益厲,遂以導入佛法。宋儒受佛氏禪宗影響,守靜之意深,而健動之力,似 疏於培養;寡欲之功密,而致用之道,終有所未宏。

<天地間一個讀書人--熊十力傳>

Running Leopard

The runtime architecture of Mac OS X is Mach-O. Although Mac OS X understands only the Mach-O binary executable format, many specialized applications can run on Mac OS X. Mac OS X kernel uses execve() system call (implemented in the BSD portion of the OS X kernel) to load the Mach-O program to run. The following are the main applications that can run on OS X:

• UNIX command-line tools and X Windows applications written in portable interfaces such as POSIX
• Carbon GUI and command-line applications written in C
• Cocoa GUI and command-line applications written in Objective-C, Java, or AppleScript
• AWT and Swing applications written in Java
• Generic command-line applications or tools written in C++ or C that may link with one or more frameworks such as Core Foundation (of Carbon), Core Services, Foundation (of Cocoa), and I/O Kit.

Mach-O files used on Mac OS X for implementing different types of system components:

• Bundles (programmatically loadable code)
• Dynamics shared libraries
• Frameworks
• Umbrella frameworks
• Kernel extensions
• Linkable object files
• Static archives
• Executables

Frameworks
Frameworks differ from shared libraries in that they can contain resources, such as headers, in addition to codes. They are usually found in /System/Library/Frameworks. The standard frameworks on Mac OS X are:

• Application Environment - Carbon, Cocoa, System
• Application Functionality - e.g. Screen Saver, WebKit, etc
• Core Functionality - e.g. CoreFoundation, CoreServices, etc
• Graphics and Multimedia - e.g. CoreAudio, OpenGL, QuickTime, Quartz, etc
• Security and System Management - e.g. DirectoryService, Kerberos, LDAP, etc
• Languages, Scripting, and Automation - e.g. Automator, JavaVM, Python, etc
• Peripheral Access - e.g. FWAUserLib, ForceFeedback, etc

Static and dynamic shared libraries
Previous operating systems used statically linked libraries (also called archived libraries with file extension .a). Modern operating systems used shared libraries. The names of these files have filename extension of .dylib (dynamic libraries). Applications can have their own shared libraries. For example, the gcc compiler might keep its libraries in /usr/lib/gcc/i686-apple-darwin9/.

The Carbon API, used with C and C++, provides compatibility with Mac OS 9 and earlier. The Cocoa API, which is based on the OpenStep API, is used for native OS X development. The Cocoa API is used with Objetive-C. Cocoa classes have names starting with NS is stands for NeXT and SUN.

Mac OS X's UNIX API follows the conventions associated with BSD UNIX more often than System V UNIX. It is called the BSD API because it also offers some BSD extensions. The standard libraries and headers for the BSD environment reside in the directories /usr/lib and /usr/include respectively. Many header files in /usr/include are part of the System framework. However, the System framework directory neither contains or links to these headers since the C compiler searches in /usr/include by default. A typical OS X installation has more than 150 shard libraries in /usr/lib and more than 30 in /usr/X11R6/lib. For X11, OS X includes an optimized X Winder server (/usr/X11R6/bin/xquartz) along with a modern X Window environment. The Xquartz sits atop the native Core Graphics APIs, links to the native OS X event system.

The libc, the user-level standard C library, is also found in libSystem on Mac OS X. libSystem consists of several BSD libraries, some of which are independent libraries on a typical UNIX system. Normalcy is maintained by symbolically linking such libraries to libSystem, as is the case with libpoll. Some of externally visible libraries contained in libSystem:

• libc - the standard C library (/usr/lib/libc.dylib on OS X 10.5)
• libdbm - a database library (/usr/lib/libdbm.dylib on OS X 10.5)
• libdl - a programming interface to the dynamically linking loader (/usr/lib/libdl.dylib on OS X 10.5. On OS X 10.3 and earlier, libdl is a wrapper library that emulates the POSIX dynamic linking loader API functions - - dlopen(), dlclose(), dlsym(), and dlerror() - on top of Darwin's native dyld API.)
• libinfo - a library that provides various "info" APIs, such as DNS and NIS, and NetInfo (/usr/lib/libinfo.dylib on OS X 10.5)
• libkvm - a library that provides a uniform interface for accessing kernel virtual memory images; used by programs such as ps (no libkvm is found in /usr/lib on OS X 10.5)
• libm - the standard math library (/usr/lib/libm.dylib on OS X 10.5)
• libpoll - a wrapper library that emulates the System V poll () system call on top of BSD's select () system call
• libpthread - the POSIX thread library. On Mac, POSIX threads are implemented using Mach kernel threads, with one Mach thread per pthread.
• librpcsvc - a miscellaneous "Sun" RPC services library

Some of internally available functionality in libSystem includes the following:

• libdyldapis - provides a low level API to the dynamic link editor
• libkeymgr - used for maintaining process-wide global data known to all threads across all dynamic libraries
• liblaunch - provides an interface to launchd, the manager of system-wide and per-user daemons and agents
• libmacho - provides an API for accessing segments and sections in Mach-O files
• libnotify - allows applications to exchange events through namespace-based stateless notifications
• libstreams - implements an I/O streams mechanism
• libunc - allows creation, dispatch, and manipulation of user notifications

libSysetm also includes an object file containing the commpage symbols. The commpage area is a region of memory that is mapped (shared and read-only) into every process's address space. It contains frequently used system-wide code and data. The commpage symbols in libSystem are placed in a special segment (the _DATA segment within the _commpage section), which allows a debugger to access them.

The otool (object tool) utility with the -L option lists which shared libraries a program needs.
e.g.# otool -L /bin/cp

Dynamic libraries are searched for in DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH. Frameworks are search for in DYLD_FRAMEWORK_PATH and DYLD_FALLBACK_FRAMEWORK_PATH.

DYLD_LIBRARY_PATH is used in the script called wrappers to fix broken binaries.
Rename bb to bb.broken and create a /bin/sh wrapper named bb:

$cat bb
#! /bin/sh
DYLD_LIBRARY_PATH=/opt/bb/lib
export DYLD_LIBRARY_PATH
exec bb.broken "$@"

Trojan horse security issue
In this case, a malicious user can create a Trojan horse named libc.dylib and place it in a directory that is searched before /usr/lib by using DYLD_LIBRARY_PATH.

Linux vs UNIX

Linux miss some features that make it a sophisticated modern operating system for advanced computer hardware.

POSIX
The IEEE's Portable Operating Systems based on UNIX (POSIX) and X/Open's Common Applications Environment (CAE) specify only an application programming interface (API). However, the standards do not impose any restriction on internal choices of a compliant kernel. The kernel of the Linux version 2.6 aims to complaint with the POSIX. This means that most of the existing UNIX programs can be compiled and executed on a Linux system with little effort or even without the need for patches to the source code.

Linux
Linux was initially developed by Linus Torvalds in 1991 (1990 4.3BSD-Reno, 1991 NET/2, 1993 Linux, 1994 4.4BSD Lite-1). After many years of development, Linux includes all the features of a modern UNIX operating system, it is compare to the other UNIX kernels with the following differences:

• Monolithic kernel - Mach and its variants use the microkernel approach
• Use of modules - Linux is able to automatically load and unload modules on demand (i.e. device drives). Among the commercial UNIX variants, only SVR4.2 and Solaris kernels have a similar feature.
• Kernel threading - Linux uses kernel threads in a very limited way to execute a few kernel functions periodically; however they do not represent the basic execution context abstraction. UNIX kernels of Solaris and SVR4.2/MP are organized as a set of kernel threads.
• Multithreaded application support - A multithreaded user application could be composed of many lightweight processes (LWP), which are processes that can operate on a common address, common physical memory pages, common opened files, and so on. While all the commercial UNIX variants of LWP are based on kernel threads, Linux regards LWP as the basic execution context and handles them via the nonstandard clone() system call.
• Preemptive kernel - When compiled with the "Preemptible Kernel" option, Linux 2.6 can arbitrarily interleave execution flows while they are in privileged mode. Solaris and Mach 3.0 are fully preemptive kernels.
• Multiprocessor support - Linux 2.6 support SMP for different memory models including NUMA: the system can use multiple processors and each processor can handle any task. However, a few parts of the kernel code are still serialized by means of a single "big kernel lock".
• Filesystem - Linux object-oriented Virtual File System technology allows porting a foreign filesystem to Linux easily. Linux comes with the standard Ext2, Ext3 and ReiserFS, AIX's JFS, and IRIX's XFS filesystem.
• STREAMS - Linux has no analog to the STREAMS I/O subsystem which is used in writing of device drivers, terminal drivers, and network protocols.

Note on STREAMS
Original work on the flexible configuration of IPC processing modules was done in UNIX V8. The V8 stream I/O system was adopted in SVR3 as the STREAMS system. The Streams I/O System was based on UNIX character I/O system. It allowed a user process to open a raw terminal port and then to insert appropriate kernel-processing modules, such as one to do normal terminal line editing. Modules to process network protocols also could be inserted. Stacking a terminal-processing module on top of a network-processing module allowed flexible and efficient implementation of network virtual terminals within the kernel. Therefore, it is possible to connect kernel-resident modules dynamically in a stack-oriented fashion, and to have these modules process data sent and received on an I/O stream.

A problem with stream modules is that they are inherently linear in nature, and thus they do not adequately handle fan-in and fan-out associated with multiplexing in datagram-based networks; such multiplexing is done in device drivers, below the modules proper. The design of the networking facilities for 4.2BSD took a different approach, based on the socket interface and a flexible multilayer network architecture. The 4.4BSD release made small extensions to the socket interface to allow the implementation of the ISO networking protocols.

Design of Mach

UNIX kernel - "dumping ground for virtually every new feature or facility"

- Richard Rashid of Carnegie Mellon University (CMU)

Based on the Mach 3, Mac OS X should perform well in:

• Memory management
• Preemptive / Real-time operating system
• System call redirection - integration with other operating systems, e.g. BSD

Mach's implementation used 4.3BSD as the starting code base. As Mach evolved, portions of the BSD kernel were replaced by their Mach equivalents, and various new components were added.

1984
The Mach project started in 1984 with several specific goals to achieve:

• Provide full support for multiprocessing
• Support diverse architectures, include shared memory access scheme such as Non-uniform Memory Access (NUMA) and Non-Remote Memory Access (NORMA)
• Support transparent and seamless distributed operation
• Reduce the number of features in the kernel. Although system programmers will have a very small number of abstractions to work with, the abstractions would be general enough to allow several operating system to be implemented on top of Mach
• Provide compatibility with UNIX

Initially there were four basic abstraction in the kernel:

1. A task is a container for the resources of one or more threads. Examples of resources include virtual memory (through memory object), ports, processors, and so on.
2. A thread is a basic unit of execution in a task. A task provides an execution environment for its threads, i.e., threads of task share its resources includes the program counter and various registers.
3. A port is an in-kernl message queue with capabilities. Ports form the basis for Mach's IPC facilities.
4. A message is a collection of data that threads in the same or different tasks can send to each other using ports.

Memory object is a basic Mach abstraction too. It can be considered as a container for data (including file data) mapped into a task's address space. Mach requires a paged MMU (PMMU). It provides an interface to the machine-dependent memory-management unit (MMU) facilities. Its virtual memory subsystem was designed to support large, spare virtual address spaces and was integrated with IPC. Regions of memory can be allocated from anywhere in the address space. Memory could be shared for reading and writing in a structured manner. Copy-on-write techniques were used both to optimize copy operations and for sharing physical memory between tasks. Generalized memory object abstraction allows external memory pagers to handle page faults and page-out data requests. The resource of target data could even reside on another machine.

The virtual memory architectures of FreeBSD is based on Mach

1993
Although Mach was designed to run as the operating system for various operating systems, Mach 3 was the first true microkernel version. The Mach 3 project was started at CMU and continued by OSF (Open Software Foundation). In Mach 3, BSD ran as a user-space task, with only fundamental features being provided by the Mach kernel. Changes and improvements in Mach 3 include the following:

• Kernel preemption and a real-time scheduling framework to provide real-time support
• Low-level device support wherein devices were presented as ports to which data or control messages could be sent. It supports both synchronous and asynchronous I/O.
• A completely rewritten IPC-implementation
• System call redirection - allow a set of system calls to be handled by user-space code running within the calling task
• Use of continuations, a kernel facility that gives a thread the option to block by specifying a function (the continuation function) that is called when the threads runs again

The intended benefits of microkernel-based operating system were offset by the real-life performance problems such as listed at below:

• The cost of maintaining separate protection domains, including the cost context switching from one domain to anther
• The cost of kernel entry and exit code
• Data copies in MIG-generated stub routines. Mach Interface Generator (MIG) generates client stubs for Mach IPC - RPC code for client-server-style Mach IPC from specification files
• The use of semantically powerful but implementation-heavy IPC mechanisms, even for RPC on the same machine.

Timeline and Design of BSD

• BSD is particularly important in resources management and network facilities.
• FreeBSD and NetBSD are the foundation of the development of the various license free operating system.
• Although Linux is POSIX compliant, it is different from UNIX in many aspects.

1979
In 1979, the first Berkeley VAX UNIX work was called the 3BSD. It was the addition to 32V of virtual memory, demand paging, and page replacement. (32V is called UNIX/32V Time-Sharing, System Version 1.0. It is a VAX variety after the first UNIX system with portability, UNIX Time-Sharing System V7).

The reason for the large virtual-memory space of 3BSD was the development of what at the time were large programs, such as Berkeley's Franz LISP. This memory-management work convinced the Defense Advanced Research Projects Agency (DARPA) to fund the Berkeley team for the later development of a standard system (4BSD) for DARPA's contractors to use.

1984
The support of large spare address spaces, mapped files, and shared memory was a requirement for 4.2BSD. Because of pressure to make other features, such as networking, available, it was shipped without the mmap() interface. mmap() was specified to allow unrelated processes to request a shared mapping of file into their address spaces. DARPA wanted Berkeley to develop 4.2BSD as a standard research operating system for the VAX. In addition to the virtual memory system, many new facilities were designed for inclusion in 4.2BSD. These facilities included a much higher-speed filesystem, inter-process-communication, and networking support. The motivation for providing networking support was primarily DARPA's interest in connection their researchers through the 56-Kbit-per-second ARPA Internet.

1990
The 4.3BSD-Reno, was the third release of 4.3BSD, added ISO/OSI networking support, a freely distributable implementation of NFS, and the conversion to and addition of the POSIX.1 facilities.
Note: The implementation changes between 4.2BSD and 4.3BSD were not visible to users, but they are numerous. The development of 4.3BSD was to fix the networking protocol (TCP/IP) bugs, adding TCP/IP subnet and routing support, and correct the performance loss that compared to 41.BSD, etc

1993
The old virtual-memory system was completely replaced in 4.4BSD. The virtual-memory system in 4.4BSD is based on the Mach 2.0 VM, with updates from Mach 2.5 and 3.0. The virtual-memory system is better suited to the large memories and is much less dependent on the VAX architecture. It features efficient support for sharing, a clean separation of machine-independent and machine-dependent features, as well as multiprocessor support. Processes can map files anywhere in their address space. They can share parts of their address space by doing a shared mapping of the same file. Therefore, instead of copies data to the 4.4BSD kernel, the system provides quick passing of large quantities of data between processes by mmap() interface.

The 4.4BSD release also added support of multiple filesystem, extensions to the socket interface to allow the implementation of networking protocols in the ISO suite, and further TCP/IP performance improvements and enhancements. Protocol modules may deal with multiplexing of data from different connections onto a single transport medium, as well as with demultiplexing of data for different protocols and connections received from each network device.

For the support of multiple filesystem, 4.4BSD includes an object-oriented interface to filesystem similar to Sun Microsystem's vnode framework. This framework supports multiple local and remote filesystems. The vnode interface has been generalized to make the operation set dynamically extensible and to allow filesystem to be stacked. 4.4BSD supports many filesystem types, including loopback, union, and uid/gid mapping layers, plus an ISO 9660 for CD-ROMs. It also supports NFS version 2 and 3 and a new local disk-based log-structured filesystem.

Kernel organization
A monolithic kernel make no hardware-enforced distinction between user and kernel space (mmap() interface was implemented in 4.4BSD).

The largest part of the kernel implements the system services that applications access through system calls. Most of the software is machine independent and is portable across different hardware platforms. In 4.4BSD, this software has been organized according to the following (e.g., 80.4% for the HP300 in the 4.4BSD kernel):

• Basic kernel facilities: timer and system-clock handling, descriptor management, and process management
• Memory-management support: paging and swapping
• Generic system interfaces: the I/O, control, and multiplexing operations performed on descriptors
• The filesystem: files, directories, pathname translation, file locking, and I/O buffer management
• Terminal-handling support: the terminal-interface driver and terminal line disciplines
• Interprocess-communication facilities: sockets
• Network communication support: communication protocols and generic network facilities, such as routing

When an platform-dependent action is needed, the machine-dependent code calls an platform-dependent function that is located in the machine-dependent code. The software that is machine-dependent includes (e.g., 19.6% for the HP300 in the 4.4BSD kernel):

• Low-level system-startup actions
• Trap and fault handling
• Low-level manipulation of the run-time context of a process
• Configuration and initialization of hardware devices
• Run-time support for I/O devices

Only a small part of the kernel is devoted to initializing the system. This code is used when the system us bootstrapped into operation and is responsible for setting up the kernel hardware and software environment. The 4.4BSD kernel does not reclaim the memory used by the startup code because the memory space is barely 0.5% of the kernel resources used on a typical machine. Also, the startup code does not appear in one place in the kernel.

The current trend in operating systems research is to reduce the kernel size by placing as many services as possible in user space. For example, filesystems and networking protocols are implemented as client application processes of the kernel.

1995
The 4.4BSD Lite-2 was released in 1995.This release was the final distribution from the CSRG (The Computer Systems Research Group) at the University of California at Berkeley. There were two versions of 4.4BSD. One was to have been a traditional full source and binary distribution, called 4.4BSD-Encumbered. The other one, called Lite-1 (released in 1994), was a subset of the source that contained no license code and did not require the recipient to have a UNIX source license. Lite-2 is the bug-fixed version of Lite-1.

Continued the free software development, FreeBSD and NetBSD were based on 4.4BSD Lite-2. The FreeBSD project concentrates on developing distributions for the PC platform. The NetBSD project concentrates on providing ports of 4.4BSD to as many platform as possible.

DNA of xnu

Mach
Mach can considered as the core of xnu. Mach provides critical low-level services that are transparent to applications. It was used as a true microkernel in version 3. Before that it had monolithic implementation in which BSD and Mach resided in the same kernel address space. In Mac OS X, xnu does not not use Mach as a traditional microkernel - various subsystems that would be implemented as user-space servers in a true microkernel system are part of the kernel proper in Mac OS X. In particular, the BSD portion of xnu, the I/O Kit, and Mach are all reside in the same address space.

System aspects that Mach is responsible for include the following:

• Hardware abstraction to some extent
• Process management, including symmetric multiprocessing and scheduling
• Preemptive multitasking, including support for tasks and threads
• Virtual memory management, including low-level paging, memory protection, sharing, and inheritance
• Low-level IPC mechanisms that are the basis for all messaging in the kernel
• Real-time support that allows time-sensitive applications to have latency-bounded access to processor resources
• Kernel debugging support
• Console I/O

Started with Mac OS X 10.4, xnu added support for 64-bit processes on 64-bit hardware. The upper limit of the process virtual address spaces was 18 exabytes (10^18). Prior to 10.4, process virtual spaces was 32-bit.

BSD
The xnu kernel contains a substantial amount of BSD-derived code. But is is not the case that a well-defined BSD kernel runs within xnu. The BSD-derived portions were made to coexist with non-BSD entities such as I/O Kit and Mach. Some aspects that BSD-style code is responsible for include the following:

• BSD-style process model
• Signals
• User IDs, permissions, and basic security policies
• POSIX APIs
• Asynchronous I/O APIs (AIO)
• BSD-style system calls
• TCP/IP stack, BSD sockets, and firewall
• Network Kernel Extensions (NKEs) - type of kernel extension for making the BSD networking architecture fit into xnu
• The virtual file system (VFS) layer and numerous file systems, including a file-system-independent VFS-level journaling mechanisms
• System V and POSIX interprocess communication mechanisms
• In-kernel cryptographic framework
• A system notification mechanism based on FreeBSD's kqueue/kevent mechanism - a system-wide service enabling notifications between applications, and from the kernel to applications
• The fsevents file system change notification mechanism that is used by the Spotlight search technology
• Access Control Lists (ACLs) and the kauth authorization framework
• Various synchronization primitives

In Mac OS X, a BSD process does not execute. It corresponds to a Mach task, which contains one or more Mach threads, and it is these threads execute. For example, the BSD-style fork() implementation in the kernel uses Mach calls to create a task. At the same time, it allocates and initializes a process structure that is associated with the task. Therefore, BSD process structure bind the UNIX and Mach together. Similarly, BSD's unified buffer cache (UBC) has a back-end that hooks into Mach's virtual memory subsystem. UBC allows the file system and the virtual memory subsystem to share kernel memory buffers. Unifying the buffer cache yields a single backing store for various entities, reducing disk accesses and the amount of wired memory used.

In addition to BSD system calls like sysctl() and ioctl(), Mac OS X uses Mach system calls (or Mach traps) when necessary. There are several ways to map memory, perform block-copy, and exchange information between user and kernel spaces.

I/O Kit
I/O Kit uses a restricted subset of C++ as it programming language. The C++ features that are not allowed include exceptions, multiple inheritance, templates, complicated constructors, initialization lists, and runtime type identification (RTTI). However, it does implement its own minimal RTTI system.

The I/O Kit's implementation consists kernel-resident C++ Libraries (libkern and IOKit) and a user-space framework (IOKit.framework). The Kernel.framework encapsulates the kernel-resident libraries in order to export their header files - the executable code for these libraries is contained in the kernel. The IOKit.framework is a conventional framework used for writing user-space programs that communicate with the I/O Kit. Other frameworks that form the basis of Mac OS X core are: Accelerate.framework, CoreFoundation.framework, CoreServices.framework.

I/O Kit presents abstractions of the underlying hardware to the rest of the system. The device driver model provided by the I/O Kit has the following features:

• Extensive programming interfaces
• Numerous device families such as ATA/ATAPI, FireWire, Graphics, HID, Network, PCI, and USB
• Object-oriented abstractions of devices
• Plug-and-play and dynamic device management ("hot-plugging")
• Power management
• Preemptive multitasking, threading, symmetric multiprocessing, memory protections, and data management
• Dynamic matching and loading of drivers for multiple bur types
• A database for tracking and maintaining detailed information on instantiated objects (the I/O Registry)
• A database of all I/O Kit classes available on a system (the I/O Catalog)
• Interfaces for applications and user-space drivers to communicate with the I/O Kit
• Driver stacking

Therefore, standard devices such as mouse and keyboard that conform to well-defined and well-supported specifications do not require custom I/O Kit drivers.


libkern Library
The libkern library implements the runtime system for restricted subset of C++ used by the I/O Kit's programming model. It also defines the OSObject class which is the root base class for Mac OS X kernel. The following are examples of the functionality provided by libkern:

• Dynamic allocation, construction, and destruction of objects with support for a variety of built-in object types such as Arrays, Booleans, and Dictionaries
• Atomic operations and miscellaneous function such as bcmp(), memcmp(), and strlen()
• Functions for byte-swapping
• Provisions for tracking the number of current instances for each class
• Mechanisms that help alleviate the C++ fragile base-class problem

libsa Library
libsa is an in-kernel support library which function like an in-kernel linker during early system startup for loading kernel extensions (standalone libraries exist on other operating system often with the name libstand). Mac OS X kernel extensions are normally loaded on demand through the kextd user-space daemon (/usr/libexec/kextd). libsa is removed from the kernel once kextd becomes available. Examples of specific functionality implemented by libsa include the following:

• Simple memory allocation
• Binary searching
• Sorting
• Miscellaneous string-handling functions
• Symbol remangling
• A dependency graph package used while determining kernel extension dependencies
• Decompression of compressed kernels and verification of checksums

四年易運

曾翻閱一本以易預測香港六十年運勢的書，現作選年擇事，從卦象看事情繁衍，挑爻入年，由壞損設想，有備而處。

08年 初六，鳴豫，凶 - 奧運後
09年 初六，童觀，小人無咎，君子吝 - 只望神州，不觀其生。
10年 上六，比之無首，凶 - 香江無首，無可比之。
11年 上九，碩果不食，君子得輿，小人剝廬 - 小人當道，虛耗飴盡。

2008 戊子 震坤 豫
豫：利建侯行師。
初六，鳴豫，凶。
六二，介于石，不終日，貞吉。
六三，盱豫悔; 遲有悔。
九四，由豫，大有得; 勿疑，朋盍簪。
六五，貞疾，恒不死。
上六，冥豫成，有渝無咎。

2009 己丑 巽坤 觀
觀：盥而不薦，有孚顒若。
初六，童觀，小人無咎，君子吝。
六二，闚觀，利女貞。
六三，觀我生，進退。
六四，觀國之光，利用賓于王。
九五，觀我生，君子無咎。
上九，觀其生，君子無咎。

2010 庚寅 坎坤 比
比：吉。原筮，元永貞，無咎。不寧方來，後夫凶。
初六，有孚比之，無咎; 有孚盈缶，終來有它，吉。
六二，比之自內，貞吉。
六三，比之匪人。
六四，外比之，貞吉。
九五，顯比; 王用三驅，失前禽，邑人不誡，吉。
上六，比之無首，凶。

2011 辛卯 艮坤 剝
剝：不利有攸往。
初六，剝牀以足，蔑; 貞凶。
六二，剝牀以辨，蔑; 貞凶。
六三，剝，無咎。
六四，剝牀以膚，凶。
六五，貫魚以宮人寵，無不利。
上九，碩果不食，君子得輿，小人剝廬。

X is not UNIX

xnu is the name of the kernel of Mac OS X (Darwin). It is unofficially an acronym for "X is Not UNIX". It is also a coincidental tribute to the fact that it is indeed the NuKernel for Mac OS X. xnu can be viewed as having a Mach-base core (Mach 3), a BSD-based (FreeBSD 5) operating system personality, and an object-oriented runtime environment for drives and other kernel extensions.

A running kernel contains numerous drivers that do not reside in the xnu code base but have their own Darwin packages. Darwin xnu package consists of about million lines of code, of which half could be categorized under BSD and a third under Mach, form the low-level foundation of OS X. The sources for Darwin (version 2.0) under the Apple Public Source License (APSL) was classified as a free software license by the Free Software Foundation (FSF). The rest of the packages are provided under their respective licenses, such as the GNU General Public License (GPL), the BSD License, the Carnegie Mellon University License and so on. There are about 350 packages in Darwin 8.6 (PPC) for Mac OS X 10.4.6. Darwin does not include the proprietary components that are integrated as parts of OS X, i.e. the Aqua, Carbon, Cocoa, OpenGL, Quartz and QuickTime, etc. Although it lacks the visual technologies of OS X, it supports graphical X11 Window System. We can divide Mac OS X kernel into the following components:

• Mach - the service layer
• BSD - the primary system programming interface provider
• I/O Kit - the runtime environment for drivers
• libkern - an in-kernel library
• libsa - an in-kernel library that is normally used only during the system startup
• Platform Expert - the hardware abstraction module (platform-specific)
• Kernel Extensions - various I/O Kit families, the majority of loadable device drivers, and some non-I/O Kit extensions.

The number of kernel extensions loaded at any time on a given system can be read by the kextstat command. The /System/Library/Extensions directory is the standard location of kernel extensions.

nextstep of NEXTSTEP

Steve Jobs announced the NeXT cube on Oct 1988. The operating system of the computer was NEXTSTEP. The system's kernel is a port of Carnegie Mellon University Mach 2.0 with a 4.3BSD environment and its window server was based on Display PostScript. The graphical window system had a dock application stayed on top to hold frequently used applications. Other NEXTSTEP features included:

• The ability to "hide" applications
• CD-quality sound
• A versatile mail application that supported voice annotation of messages, inline graphics, and dynamic lookup of email addresses over the network
• Drag and drop of complex objects between applications
• A services menu that could be accessed from various applications such as dictionary
• A Digital Librarian application that could build searchable indexes of content dragged to it
• A file viewer that extended across the network
• An object-oriented device drive framework called the Driver Kit

The native programming language of NEXTSTEP is Objective-C. Objective-C is an object-oriented, compiled programming language invented by Brad Cox and Tom Love in the early 80s. It is a superset of C, with dynamic binding and a message syntax inspired by Smalltalk. Even though, it does not have many features of C and C++, such as multiple inheritance and operator overloading. In 1995, Apple bought all the intellectual property related to Objective-C. Now, Apple's Objective-C compiler used in OS X is modified version of the GNU compiler.

In 1996, NeXT released the OpenStep-compliant version of NEXTSTEP 4.0 (based on Mach 3.0). OpenStep specification was an object-oriented operating system project introduced by NeXT and Sun Microsystems. It is an open platform, comprised several APIs and frameworks that anybody could use to create their own implementation of an object-oriented operating system.

In the following year, Apple bought NeXT and based its next-generation operating system, namely Rhapsody, on NeXT's OPENSTEP. In March 1999, Apple announced the Mac OS X Server 1.0, which was an improved version of Rhapsody. It was bundled with WebObjects, the QuickTime streaming server, a collection of developer tools, the Apache web server, and the facilities for booting or administering over the network. Later, in Sept 2000, Apple released a beta version of Mac OS X. At the same time, Apple also announced the Darwin - a fork of Rhapsody's developer release.

The key features of the Mac OS X public beta are:

• Darwin core with its xnu kernel provided "true" memory protection, preemptive multitasking, and symmetric multiprocessing
• The PDF-based Quartz 2D drawing engine
• OpenGL support
• The Aqua interface and the Dock
• Apple's new mail client, with support for IMAP and POP
• A new version of the QuickTime player
• The Musical Player application for playing MP3 and audio CDs
• A new version of the Sherlock Internet-searching tool

Then, in 2002, Apple and Internet Systems Consortium, Inc. (ISC) jointly founded the OpenDarwin project. GNU-Darwin is an open source Darwin-based operating system.

Date - Codename - Version
Mar 2001 - Cheetah - 10.0
Sept 2001 - Puma - 10.1
Aug 2002 - Jaguar - 10.2
Oct 2003 - Panther - 10.3
Apr 2005 - Tiger - 10.4 (first shipped x86-Mac used 10.4.4)
Jul 2007 - Leopard - 10.5