From: Zooko O'Whielacronx <zooko@zooko.com>
Date: Sun, 2 Aug 2009 02:26:01 +0000 (-0700)
Subject: docs: add a couple of details to NEWS, change date and a bit of formatting, name... 
X-Git-Tag: allmydata-tahoe-1.5.0~6
X-Git-Url: https://git.rkrishnan.org/components/com_hotproperty/simplejson/...?a=commitdiff_plain;h=e784fbdbf3f32d7f64d2338c883272bb316af5ca;p=tahoe-lafs%2Ftahoe-lafs.git

docs: add a couple of details to NEWS, change date and a bit of formatting, name of 'Tahoe-LAFS' project
---

diff --git a/NEWS b/NEWS
index b1bf8a21..cb4958d5 100644
--- a/NEWS
+++ b/NEWS
@@ -1,6 +1,6 @@
-User visible changes in Tahoe.  -*- outline -*-
+User visible changes in Tahoe-LAFS.  -*- outline -*-
 
-* Release 1.5.0 (2009-07-22)
+* Release 1.5.0 (2009-08-01)
 
 ** Improvements
 
@@ -28,13 +28,13 @@ and algorithm remains the same, so using mutable files still requires
 bandwidth, computation, and RAM in proportion to the size of the mutable file.
 (#694)
 
-This version of Tahoe will tolerate directory entries that contain filecap
+This version of Tahoe-LAFS will tolerate directory entries that contain filecap
 formats which it does not recognize: files and directories from the future.
 This should improve the user experience (for 1.5.0 users) when we add new cap
-formats in the future. Previous versions would fail badly, preventing the
-user from seeing or editing anything else in those directories. These
-unrecognized objects can be renamed and deleted, but obviously not read or
-written. Also they cannot generally be copied. (#683)
+formats in the future. Previous versions would fail badly, preventing the user
+from seeing or editing anything else in those directories. These unrecognized
+objects can be renamed and deleted, but obviously not read or written. Also
+they cannot generally be copied. (#683)
 
 ** Bugfixes
 
@@ -53,8 +53,8 @@ the Helper's ability to mount a partial-information-guessing attack. (#722)
 
 ** Platform/packaging changes
 
-Tahoe-LAFS now runs on NetBSD, OpenBSD, and ArchLinux, and an embedded system
-based on an ARM CPU running at 266 MHz. XXX
+Tahoe-LAFS now runs on NetBSD, OpenBSD, ArchLinux, and NixOS, and on an
+embedded system based on an ARM CPU running at 266 MHz.
 
 Unit test timeouts have been raised to allow the tests to complete on
 extremely slow platforms like embedded ARM-based NAS boxes, which may take
@@ -62,16 +62,20 @@ several hours to run the test suite. An ARM-specific data-corrupting bug in
 an older version of Crypto++ (5.5.2) was identified: ARM-users are encouraged
 to use recent Crypto++/pycryptopp which avoids this problem.
 
-Tahoe now requires a SQLite library, either the sqlite3 that comes built-in
-with python2.5/2.6, or the add-on pysqlite2 if you're using python2.4. In the
-previous release, this was only needed for the "tahoe backup" command: now it
-is mandatory.
+Tahoe-LAFS now requires a SQLite library, either the sqlite3 that comes
+built-in with python2.5/2.6, or the add-on pysqlite2 if you're using
+python2.4. In the previous release, this was only needed for the "tahoe backup"
+command: now it is mandatory.
 
 Several minor documentation updates were made.
 
-To help get Tahoe into Linux distributions like Fedora and Debian, packaging
-improvements are being made in both Tahoe and related libraries like
-pycryptopp and zfec.
+To help get Tahoe-LAFS into Linux distributions like Fedora and Debian,
+packaging improvements are being made in both Tahoe-LAFS and related libraries
+like pycryptopp and zfec.
+
+The Crypto++ library included in the pycryptopp package has been upgraded to
+version 5.6.0 of Crypto++, which includes a more efficient implementation of
+SHA-256 in assembly for x86 or amd64 architectures.
 
 ** dependency updates