diff --git a/README b/README
index 2ca616a4..a69cbd8a 100644
--- a/README
+++ b/README
@@ -1,70 +1,44 @@
 COMPATIBILITY
 
-    This code is intended for use with Linux 2.2.xx, 2.4.xx,
-    2.6.xx, and hopefully all future kernels. You should be
-    running a system with libc 6, but libc 5 might work too.
+    This code is intended for use with Linux 2.6.xx, 3.x and
+    hopefully all future kernels.
 
 INSTALLATION
 
+    If you are using git version of the project you need extra step.
+
+    ./autogen.sh
+
+    After that, and everyone using .tar.xz version of procps-ng, can
+    do normal build.  Read './configure --help' to select options for
+    your needs.
+
+    ./configure
     make
     make install
 
-    Only the second ("make install") is needed if you just
-    want to build and install procps-ng in the normal way.
+    If you have DejaGNU installed you can run optional test suite.
 
-    If you wish to test before installing, use the scripts
-    named t, v, and p to ensure that the correct libproc
-    (the new one) is used during your testing.
-
-    You may set SKIP to avoid building or installing things.
-    For example:
-
-    make SKIP='/bin/kill /usr/share/man/man1/kill.1' install
-
-    Use SHARED=0 to build procps-ng without shared libraries.
-    This may be useful for installing in your home directory.
-
-    make SHARED=0 DESTDIR=$HOME install
-
-    Suppose you wanted to install stuff in strange places.
-    You might do something like this:
-
-    make usr/bin=/tmp/Q/i/ DESTDIR=/tmp/Q install="install -D" ldconfig=echo install
-
-    If cross-compiling, you might need to set lib64 to
-    either "lib" or "lib64". You might need to set m64 to
-    -m64, -m32, or nothing at all. Some examples:
-
-    make lib64=lib m64=-m32      # for a bi-arch gcc
-    make lib64=lib64 CC=x86_64-gcc
-    make lib64=lib CC=alpha-gcc
+    make check
 
 PACKAGING
 
-    If you are a downstream maintainer (packager) for a Linux distribution,
-    please avoid causing troubles. This section applies to you.
+    If you are a downstream maintainer (packager) for a Linux
+    distribution, please avoid causing troubles.  This section
+    applies to you.
 
-    Send patches in regularly. Many patches made by vendors have been buggy,
-    some quite severely so. Sending in a patch will at least get it reviewed,
-    if not included. There is a procps-ng test suite that must be passed.
-    Forward all bug reports. If your bug database is public and busy enough
-    to bother with, please make this known. Follow Debian's lead in making
-    the bug database easy to comment on via email w/o need for an account.
+    Avoid maintaining distribution specific patches.  Send your
+    patches to upstream, where they are at least reviewed, if not
+    included.
 
-    Do not change the user interface. Many of the programs are intended to be
-    compatible with Solaris, FreeBSD, AIX, IRIX, Tru64, and the UNIX standard.
-    Your nice new command options WILL BE BROKEN as needed to ensure that
-    procps-ng remains compatible with the rest of the world. Sysadmins hate to
-    deal with incompatible behavior. If you need a new option, ask for it.
+    Please forward bug reports. If your bug database is public and
+    busy enough to bother with, please make this known.  Follow
+    Debian's lead in making the bug database easy to comment on via
+    email without need for an account.
 
     For normal packages, ensure that you do not add debugging flags
-    to the CFLAGS variable. If debugging flags are present, the Makefile
-    will avoid adding several optimizations that would interfere with gdb.
+    to the CFLAGS variable.
 
-    There should be no need to modify the Makefile. You can set variables
-    on the "make" command line or use "make -e" to pass variables from
-    the environment.
+UPSTREAM & BUG REPORTS
 
-BUG REPORTS
-
-    Email to procps@freelists.org.
+    procps-ng <procps@freelists.org>