Tannenbaum's Amoeba system supports is designed 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 nearest to home.
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 a language designed in the mid 1960's.
A better exception handling model is found in the Ada programming language, but this isn't the place to discuss it.
More importantly, the question is, what do you gain by allowing users to attach their own exception handlers to a process.