I think you definitely need to say that the idea of file descriptors in the unix API anticipated the current style (fad?) of object-oriented programming by about 20 years, languages like Smalltalk/C++, more recently java/ruby, use opaque objects with polymorphism to provide services, which is exactly what unix does, an object hierarchy would look something like: - read/write capable (file descriptor) objects - seek capable (storage) objects - truncate capable (file) objects - non truncate capable (block) objects - non seek capable (stream) objects - pipes - sockets - stream oriented sockets - datagram oriented sockets - terminals For terminals, the extension to the API over the basic read/write capable object is via an ioctl, whereas for sockets it is via its own API (connect/accept/listen/etc), but conceptually there is no reason why read/write/lseek/etc couldn't be ioctls as well, since the mapping from userspace calls (such as lseek or stty/gtty) to syscalls is up to the standard library. pipe() is a java-style constructor, whereas socket() or open() is conceptually a static factory as it can return different types of objects depending on the request, the constructors for the corresponding objects are conceptually private constructors. An errno is basically a checked exception that can be thrown, each syscall effectively has a java style "throws ..." clause and well designed userland code catches or rethrows these. cheers, Nick On Tue, Jun 28, 2011 at 10:11 AM, Warren Toomey <wkt(a)tuhs.org> wrote:

Warren, In regard to Unix, the most important revelations to me personally are: 1) detailed documentation of every aspect of the system - Having instant access to consistent documentation on commands, system calls, libraries, and the bit level formats of inodes, directory structures, and the filesystem, was a revelation both in terms of productivity and expanse of knowledge. 2) uniform device handling - Rendering all I/O as a stream of bytes, without regard to content or record sizes, provided a universal foundation for data exchange among heterogenous devices. 3) pipelining - In my opinion, this is the computing equivalent to the invention of interchangeable parts. Many programming tasks could be completed by the successive processing of a stream of data by a series of small but well defined set of utility programs. 4) C - Writing 90% of the system in a "portable assembler" reduced the cost of implemention on new architectures by a magnitude. For these reasons, I jumped on board and Unix became a central part (if not the foundation) of my career in software development. I'm sure you've read these at one time or another, but here are a few of my favorites. Some of them might help you chase down the quotes you are looking for: Excerpt from UNIX Time-Sharing System: UNIX Implementation, By K. Thompson, The Bell System Technical Journal, Vol. 57, No. 6, July-August 1978, pp. 1931: "The kernel is the only UNIX code that cannot be substituted by a user to his own liking. For this reason, the kernel should make as few real decisions as possible. This does not mean to allow the user a million options to do the same thing. Rather, it means to allow only one way to do one thing, but have that way be the least-common divisor of all the options that might have been provided." Excerpt from UNIX Time-Sharing System: A Retrospective, By D. M. Ritchie, The Bell System Technical Journal, Vol. 57, No. 6, July-August 1978, pp. 1948: "UNIX was never a 'project'; it was not designed to meet any specific need except that felt by its major author, Ken Thompson, and soon after its origin by the author of this paper, for a pleasant environment in which to write and use programs." Excerpt from The UNIX Programming Environment, By Brian W. Kernighan & Rob Pike, Prentice-Hall 1984, pp. viii: "Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is an approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial tasks in isolation, but, combined with other programs, become general and useful tools." Finally, attached is a .png of a collage that I had intended to put together for the 40th Anniversary of UNIX last year. I hope that you find it interesting at least. Cheers, Jim ----- Original Message ----- From: "Warren Toomey" <wkt(a)tuhs.org> To: tuhs(a)tuhs.org Sent: Monday, June 27, 2011 8:11:40 PM Subject: [TUHS] Ideas for a Unix paper I'm writing All, IEEE Spectrum have asked me to write a paper on Unix to celebrate the 40th anniversary of the release of 1st Edition in November 1971. I'm after ideas & suggestions! I think my general thrust is that Unix is an elegant design, and the design elements are still relevant today. The implementation is mostly irrelevant (consider how much the code has changed from assembly -> C, from the simple data structures in V7 through to current BSD), but the original API is classic. Note that about 28 of the 1st Ed syscalls are retained in current BSDs and Linux, and with the same syscall numbers. I'm having some trouble thinking of the right way to explain what is an elegant design at the OS/syscall level, so any inspirations/ideas would be most welcome. I might highlight a couple of syscall groups: open/close/read/write, and fork/exec/exit/wait. If you have any references/URLs you think I should look at, please pass them on to me. I'm also trying to chase down some quotes; my memory seems to be failing me but I'm sure I've seen these somewhere: - in a paper, I think by Thompson & Ritchie, where they assert that the kernel should provide no more than the most minimal services to the userland programs. I thought this was the CACM paper, but I can't spot this bit. Maybe it's in Thompson's preface to the Lions Commentary, of which my copy is elsewere at present. - I'm sure I remember someome (Kernighan?) say that Ritchie encouraged them to espouse the use of processes as context switching was cheap, but later measurements showed that in fact it wasn't that cheap in the early versions of Unix. Anyway, if you can think of good ideas/references about the elegance of Unix, especially from the design perspective, I would much appreciate them. Cheers, Warren _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

Warren, Two more excerpts if I may: The UNIX Time-Sharing System, Dennis M. Ritchie and Ken Thompson, Bell Laboratories, CACM July 1974, pp. 374: "Our goals throughout the effort, when articulated at all, have always concerned themselves with building a comfortable relationship with the machine and with exploring ideas and inventions in operating systems. We have not been faced with the need to satisfy someone else's requirements, and for this freedom we are grateful." and "The success of 'UNIX' lies not so much in new inventions but rather in the full exploitation of a carefully selected set of fertile ideas, and especially in showing that they can be keys to the implementation of a small yet powerful operating system." Cheers, Jim ----- Original Message ----- From: "Warren Toomey" <wkt(a)tuhs.org> To: tuhs(a)tuhs.org Sent: Monday, June 27, 2011 8:11:40 PM Subject: [TUHS] Ideas for a Unix paper I'm writing All, IEEE Spectrum have asked me to write a paper on Unix to celebrate the 40th anniversary of the release of 1st Edition in November 1971. I'm after ideas & suggestions! I think my general thrust is that Unix is an elegant design, and the design elements are still relevant today. The implementation is mostly irrelevant (consider how much the code has changed from assembly -> C, from the simple data structures in V7 through to current BSD), but the original API is classic. Note that about 28 of the 1st Ed syscalls are retained in current BSDs and Linux, and with the same syscall numbers. I'm having some trouble thinking of the right way to explain what is an elegant design at the OS/syscall level, so any inspirations/ideas would be most welcome. I might highlight a couple of syscall groups: open/close/read/write, and fork/exec/exit/wait. If you have any references/URLs you think I should look at, please pass them on to me. I'm also trying to chase down some quotes; my memory seems to be failing me but I'm sure I've seen these somewhere: - in a paper, I think by Thompson & Ritchie, where they assert that the kernel should provide no more than the most minimal services to the userland programs. I thought this was the CACM paper, but I can't spot this bit. Maybe it's in Thompson's preface to the Lions Commentary, of which my copy is elsewere at present. - I'm sure I remember someome (Kernighan?) say that Ritchie encouraged them to espouse the use of processes as context switching was cheap, but later measurements showed that in fact it wasn't that cheap in the early versions of Unix. Anyway, if you can think of good ideas/references about the elegance of Unix, especially from the design perspective, I would much appreciate them. Cheers, Warren _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

On 6/27/11 5:11 PM, Warren Toomey wrote: The notion that Unix provided a good enough set of system services that people got on with building systems with a common set of tools. This included things like the RATFOR-based portable operating systems that came out of Georgia Tech and Laurence Livermore Labs. It took most of the 70's to get going, but by the 80's microprocessors were powerful enough that Unix would run well on them, and that dovetailed with Stallman's efforts to get a freely available tool chain. Contrast this with VMS/WinNT and the dozens of proprietary systems which survived by vendor lock in. Having lived through the OS wars inside Apple, it became clear that there weren't enough developer resources available to build a new system from scratch, and the value added wasn't in the core OS and tools, but the user environment. This appears to have occurred to almost everyone else now as well. Go for product differentiators and leverage as much freely available system infrastructure as you can. I was just digging through some CDC documents we just received concerning the joint CDC/NCR developments that happened in the early 70's, and was thinking how fast the pace of system change is now. The system they started on in 1973 was ultimately released almost 10 years later as the CYBER 180. By the end of the 80's they were thinking of porting Unix to it. I can't imagine anyone taking 10 years today to develop a new computer system, or thinking of writing an operating system and tool chain from scratch. Building on the 40 years of experience and not reinventing wheels is the ultimate legacy of the Unix system.