ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2025-04-07 10:56:49 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Zooko O'Whielacronx 2009-08-01 19:26:01 -07:00
parent ad45511156
commit e784fbdbf3
1 changed files with 20 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
NEWS
View File

@ -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