The design of Tannenbaum's Amoeba system is based on the assumption that memory will be sufficiently inexpensive that paged access to memory and sector-by-sector access to files is unreasonable. Thus, the kernel's model of memory is in terms of contiguous memory segments, and the Bullet file server stores files that must be read or written in a single indivisible operation.
Given that there is an optimal relationship between sector size (or page size) and data transfer rate, access time and CPU speed, where increasing the CPU speed relative to the access time increases the optimal sector size, it is clear that there has been an upward trend in the optimal sector size over time.
Tannenbaum's design of Amoeba is based on the assumption that the optimal sector size is now or will soon be equal to the typical file or segment size, and thus, that designing a file system or memory architecture to operate in terms of sectors or pages is probably inappropriate.
My counter argument to this is that the file size we use is strongly tied to the speed of the available system. In the days when systems were small and slow, the common advice was to use a separate file for each procedure in a program; this allowed separate compilation (minimizing the compile time when making small incremental changes to a program), and it reduced the time taken to enter and exit the cumbersome editors of the day. Now, with relatively fast editors and compilers, there is no such reason for maintaining each routine in a separate source file. (Note, however, that poor programming language design may still encourage it, and that there are other good reasons to modularize programs.) Furthermore, as systems have gotten faster, we have used them to store larger and larger data objects, for example, images, simulation models, and databases.
The directory servers provided with Amoeba map textual names to capabilities. Typically, these will be file capabilities, but this is not necessarily the case. The directory server can, in principle, map names to any type of capability, including not only files and directories, but also servers and other types of objects.
The Amoeba directory server has the interesting property that it maps names not to single capabilities but to sets of capabilities. This is done in order to support replicated resources. Thus, if some file is popular, copies of it could be included on a number of servers, and the directory entry could list all the copies. Crude users would typically pick one of the copies at random; sophisticated users could select the copy on the nearest server (measuring distance in terms of communication delay).
The Amoeba directory server includes Unix style access-control lists because it is intended to support a Unix model of files, but much of the protection in the Amoeba scheme comes from the fact that each user is given a home directory that lists the resources that that user may access. Thus, two different users might have different "/etc" directories and different "/bin" directories, while sharing the same "/public" directory.
Exception handling is an important area of programming language and operating system design which is frequently handled very poorly! The UNIX signal mechanism (see the man page for sigvec and related pages) is basically a warmed over version of the exception handling features of the PL/I programming language, the language used in the implementation of the MULTICS system, and designed in the mid 1960's.
A better exception handling model is found in the Ada programming language, Here, exception handlers are not procedures, called when an exception occurs; rather, a handler is effectively entered by a longjump or non-local goto, causing the stack to unwind to the environment of the procedure that installed the handler.
It is important to ask about the purpose of user installed exception handlers. There are two common uses for these: