diff --git a/README b/README
index 293f989..47925ec 100644
--- a/README
+++ b/README
@@ -594,48 +594,88 @@
         News regarding these platforms with more recent Cygwin
         versions would be appreciated!
 
+AtheOS: From Octavian Cerna <tavy at ylabs.com>:
+
+	Before building:
+
+	    Make sure you have shared versions of the libraries you
+	    want to use with Python. You will have to compile them
+	    yourself, or download precompiled packages.
+
+	    Recommended libraries:
+
+		ncurses-4.2
+		readline-4.2a
+		zlib-1.1.4
+
+	Build:
+
+	    $ ./configure --prefix=/usr/python
+	    $ make
+
+	    Python is always built as a shared library, otherwise
+	    dynamic loading would not work.
+
+	Testing:
+
+	    $ make test
+
+	Install:
+
+	    # make install
+	    # pkgmanager -a /usr/python
+
+
+	AtheOS issues:
+
+	    - large file support: due to a stdio bug in glibc/libio,
+	      access to large files may not work correctly.  fseeko()
+	      tries to seek to a negative offset.  ftello() returns a
+	      negative offset, it looks like a 32->64bit
+	      sign-extension issue.  The lowlevel functions (open,
+	      lseek, etc) are OK.
+	    - sockets: AF_UNIX is defined in the C library and in
+	      Python, but not implemented in the system.
+	    - select: poll is available in the C library, but does not
+	      work (It does not return POLLNVAL for bad fds and
+	      hangs).
+	    - posix: statvfs and fstatvfs always return ENOSYS.
+	    - disabled modules:
+		- mmap: not yet implemented in AtheOS
+		- nis: broken (on an unconfigured system
+		  yp_get_default_domain() returns junk instead of
+		  error)
+		- dl: dynamic loading doesn't work via dlopen()
+		- resource: getrimit and setrlimit are not yet
+		  implemented
+
+	    - if you are getting segmentation faults, you probably are
+	      low on memory.  AtheOS doesn't handle very well an
+	      out-of-memory condition and simply SEGVs the process.
+
+	Tested on:
+
+	    AtheOS-0.3.7
+	    gcc-2.95
+	    binutils-2.10
+	    make-3.78
+
+
 Configuring the bsddb and dbm modules
 -------------------------------------
 
-XXX Shouldn't this section be rewritten now that we use Sleepycat's
-BSDDB 4.0?
+Beginning with Python version 2.3, the PyBsddb package
+<http://pybsddb.sf.net/> was adopted into Python as the bsddb package,
+exposing a set of package-level functions which provide
+backwards-compatible behavior.  Only versions 3.1 through 4.1 of
+Sleepycat's libraries provide the necessary API, so older versions
+aren't supported through this interface.  The old bsddb module has
+been retained as bsddb185, though it is not built by default.  Users
+wishing to use it will have to tweak Modules/Setup to build it.  The
+dbm module will still be built against the Sleepycat libraries if
+other preferred alternatives (ndbm, gdbm) are not found, though
+versions of the Sleepycat library prior to 3.1 are not considered.
 
-Configuring the bsddb module can sometimes be a bit tricky.  This module
-provides a Python interface to the Berkeley DB library.  As of this writing
-several versions of the underlying library are in common use (versions 1.85,
-2.x, 3.x, and 4.x).  The file formats across the various versions tend to be
-incompatible.  Some Linux distributions install multiple versions by
-default.  It is important that compatible versions of header files and
-libraries are used when building bsddb.  To make matters worse, version 1.85
-of Berkeley DB has known bugs in its hash file implementation, but is still
-the most widely available version of the library.  Many people build bsddb
-with version 1.85 but aren't aware of the bugs.  This affects people using
-the anydbm and dbhash modules because they are both use Berkeley DB's hash
-file format as a side effect of calling bsddb.hashopen.
-
-To try and remedy this problem, beginning with Python version 2.3 a number
-of changes to the bsddb build process were made.  First, and most important,
-the bsddb module will not be built with version 1.85 unless the relevant
-lines in setup.py are uncommented first and no other higher-numbered
-versions are found.  Second, matching versions of the library and include
-files must be found.  Third, searching is performed in order, starting from
-version 4 and proceeding to version 2 (or version 1 if it is enabled).
-Version-independent libraries and header files (e.g. /usr/lib/libdb.a and
-/usr/include/db.h) are never considered.  They must be in version-specific
-directories or have version-specific filenames (e.g. /usr/lib/libdb-3.2.so
-and /usr/include/db3/db_185.h).
-
-Since the bsddb module is programmed using the Berkeley DB version 1 API,
-the underlying library must be configured with the --enable-compat185 flag.
-Most vendor-provided distributions are so-configured.  This is generally
-only an issue if you build Berkeley DB from source.
-
-All this affects the dbm module as well.  There are several dbm-compliant
-APIs provided by different libraries, including ndbm, gdbm and Berkeley DB.
-The build process for dbm would previously use the version 1.85 library,
-thus extending the potential hash file corruption to the dbm module as well.
-The dbm module will use the library and include files found for the bsddb
-module if neither ndbm nor gdbm libraries are found.
 
 Configuring threads
 -------------------