What is UNIX®?

UNIX 98 | UNIX 03

The Single UNIX Specification Version 4

The Single UNIX Specification Version 3

ISO/IEC 9945

UNIX System API Tables

White Papers

UNIX Certification


Slide Presentations

Test Tool Downloads

Questions and Answers


The Platform Forum projects

The Single UNIX Specification
The UNIX Certification Program

CSci 493.66 System Programming Prof. Stewart Weiss Spring 2012

CSci 493.66 System Programming Prof. Stewart Weiss Spring 2012

Lecture Notes

Chapter 1: Introduction to Systems Programming
Chapter 2: Login Records, File I/O, and Performance
Chapter 3: File Systems and the File Hierarchy
Chapter 4: Controlling File and Terminal I/O
Chapter 5: Interactive Programs and Signals
Chapter 6: Event Driven Programming: Timers and Asynchronous I/O
Chapter 7: Process Architecture and Control
Chapter 8: Interprocess Communication, Part I
Chapter 10: Threads and the Pthread Library
A Tutorial on Creating and Using Software Libraries in UNIX

The Story of the PING Program

The Story of the PING Program
My original impetus for writing PING for 4.2a BSD UNIX came from an offhand remark in July 1983 by Dr. Dave Mills while we were attending a DARPA meeting in Norway, in which he described some work that he had done on his “Fuzzball” LSI-11 systems to measure path latency using timed ICMP Echo packets. In December of 1983 I encountered some odd behavior of the IP network at BRL. Recalling Dr. Mills’ comments, I quickly coded up the PING program, which revolved around opening an ICMP style SOCK_RAW AF_INET Berkeley-style socket(). The code compiled just fine, but it didn’t work — there was no kernel support for raw ICMP sockets! Incensed, I coded up the kernel support and had everything working well before sunrise. Not surprisingly, Chuck Kennedy (aka “Kermit”) had found and fixed the network hardware before I was able to launch my very first “ping” packet. But I’ve used it a few times since then. *grin* If I’d known then that it would be my most famous accomplishment in life, I might h

darknedgy.net: uselessd :: information system – use less

darknedgy.net: uselessd :: information system – use less
Support for compilation under musl and uClibc. This has meant eradicating plenty of GNUisms, including ones that spread out as deeply as requiring specific printf(3) semantics. No journald. Consequently, this also means no libqrencode and libmicrohttpd integration, nor hooking coredumps to the journal. The default log target for auxiliaries is now LOG_TARGET_KMSG_OR_SYSLOG. The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd developers on handling this? Ignore it. Otherwise, the main legitimate case for binary logs (but actually journald in particular) is Forward Secure Sealing. This is no longer a dealbreaker, since rsyslog supports log signing through GuardTime since 3.7.9 now. You can also use a combination of OpenSSL or the NSS signtool plus logrotate jobs to verify log authenticity, though this is more intricate. Secondary concerns includ

boycott systemd

boycott systemd
systemd is viral by its very nature. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment has adopted systemd as a hard dependency since 3.8 for various utilities, including gdm, gnome-shell and gnome-extra-apps7. This means GNOME versions >=3.8 are incompatible with non-Linux systems, and due to GNOME’s popularity, it will help tilt a lot of maintainers to add systemd. The rapid rise in adoption by distros such as Debian, Arch Linux, Ubuntu, Fedora, openSUSE and others shows that many are jumping onto the bandwagon, with or without justification. It’s also worth noting that systemd will refuse to start as a user instance, unless the system boots with it as well – blatant coercion8.

pappp.net: FLOS: The future of Linux?

pappp.net: FLOS: The future of Linux?
To me, the core of a UNIX system is a philosophical matter. To quote Mike Gancarz’s The UNIX Philosophy from 1994, UNIX has 9 paramount precepts: Small is beautiful. Make each program do one thing well. Build a prototype as soon as possible. Choose portability over efficiency. Store data in flat text files. Use software leverage to your advantage. Use shell scripts to increase leverage and portability. Avoid captive user interfaces. Make every program a filter. FLOS is a nearly diametrically opposed design, with design concepts like the following: FLOS avoids scripts, and prefers to split tasks into compiled logic interacting with logic-less configuration files. FLOS prioritizes ease of machine manipulablity over human manipulablity. The components of FLOS communicate over D-Bus rather than sockets and pipes. FLOS is built on a core of monolithic programs which attempt to synergisticly manage multiple complex components. FLOS leverages features specific to Linux and ignores portabili