diff --git a/HOWTO_MAKE_SYSTEM_NOT_SUCK.README b/HOWTO_MAKE_SYSTEM_NOT_SUCK.README
deleted file mode 100644
index 82ce8a1588..0000000000
--- a/HOWTO_MAKE_SYSTEM_NOT_SUCK.README
+++ /dev/null
@@ -1,13 +0,0 @@
-If you tried the system window manager style you probably noticed it's not
-too nice looking using the standard KDE color scheme. This is because this
-is the first style to use a kwin extended color configuration and needs some
-additional entries in order to look decent.
-
-Try using the "System" color scheme in kcmdisplay to make it look rather cool.
-You'll need to restart kwin because it doesn't handle this dynamically yet.
-
-Daniel M. Duley
-mosfet@kde.org
-mosfet@linuxmandrake.com
- 
-
diff --git a/README.KRASH b/README.KRASH
new file mode 100644
index 0000000000..3e81f1d3cd
--- /dev/null
+++ b/README.KRASH
@@ -0,0 +1,44 @@
+Important notes on KWin for the Krash (1.89) developers release:
+
+Contents:
+* Muliple Style Support
+* Memory Usage
+* Theme Support
+* Things removed for Krash
+
+* Multiple Style Support And Themes:
+KWin now supports multiple styles in the same fashion as KDE widgets although
+the KWin support is much less complete as of this time. The mechanism is very
+similar - KWin can allocate different client decoration code at runtime in
+order to decorate the windows. This means that developers can easily code
+window manager styles that do absolutely anything they can think of. It also
+means that for simple look and feels using a theme engine is not required but
+can be coded directly into a window manager component, making it very efficent.
+
+Right now the infrastructure to support this is in development. Most
+importantly, dynamic loading of client style components is not implemented.
+The ones currently available are actually compiled into the window manager.
+This is not good and will be resolved prior to beta releases. Compiling all
+the styles currently entails a lot of overhead.
+
+Secondly, color schemes that are applicable to one style don't necessarily
+look good in another. For example, the default color scheme for the standard
+style looks horrible on System and neither color scheme really looks good on
+Next. In the future styles will be able to set their own default color scheme.
+Until then you must set them yourself. Color schemes for System and Next are
+provided. Also note that currently style gradient calculation is not dynamic -
+so it is important to set the color scheme before the style. All this will
+be resolved before release.
+
+* Memory Usage:
+Right now the memory usage of KWin can be high due to all the compiled-in
+styles mentioned above. The window manager itself is actually very lean. Once
+component loading is complete you will be able to see that ;-)
+
+* Theme Support:
+A KWM theme compatible plugin is mostly done and will be announced shortly.
+A new theme plugin is also in the works but not ready at this time.
+
+Daniel M. Duley
+mosfet@kde.org
+