:: 11-Jan-2000 01:08 (Tuesday) ::

The following clients have been updated/added:

– MacOS [PPC/OS7.5+] v2.8005.453
– MacOS [m68k/OS7.5+] v2.8005.453
– MacOS [fat/OS7.5+] v2.8005.453

See http://www.distributed.net/download/updates.html for updates by
date.

See http://www.distributed.net/download/clients.html for updates by
System.

Enjoy!
Moose

:: 10-Jan-2000 23:08 (Monday) ::

The following client was updated. NT service problems were corrected.

– Windows 95/98/NT [x86/Zipped]

See http://www.distributed.net/download/updates.html for updates by
date.

See http://www.distributed.net/download/clients.html for updates by
System.

:: 10-Jan-2000 01:56 (Monday) ::

The following clients have been updated/added:

– Windows 95/98/NT [x86/Zipped]

Thanks for your patience.

See http://www.distributed.net/download/updates.html for updates by
date.

See http://www.distributed.net/download/clients.html for updates by
System.

Changes:
2.8005.453 chg: client supports thresholds either as a time-factor, or
as a workunit-factor. -config documentation has more info.
A review of your settings is *strongly* advised.

2.8004.452 chg: all: .ini option spin off from the generic [parameters]
section into subsections is now complete. phew! Nothing
left except “id”.
chg: reverted log file opening on win/dos/netware/os2 to
non-shared.

Enjoy!
moose

:: 09-Jan-2000 18:25 (Sunday) ::

The following clients have been updated/added:

– Linux [x86/ELF/glibc2.0/MT]

Please see http://www.distributed.net/download/updates.html for
clients updated by dates.

Many of you have still been mailing me to ask where the Win32 client
is (Windows 95/98/NT [x86/Zipped]). I am am still waiting for it to
be uploaded again. I will update it as soon as i get it. Once again
I am sorry for the confusion.

Thanks
Moose

:: 09-Jan-2000 15:07 (Sunday) ::

In the next release of the Mac client – and I’m not tellin’ when it’s
gonna be :) – you can expect the following changes.

The client works on pre-8.0 Mac OSes. We’ve got documented evidence of
the client running on systems as early as 7.5.5, but it still fails on
7.1.2. Still more tweaking is required for operation on literally every
Mac made since 1985, but the goal is in sight.

About networking, lead Mac coder Michael Feiri says, “I have found a new
bug in the networking of GUSI2. Even the age old MacTCP is not really
rock solid. If you actively cancel a dialup attempt (e.g. press the
cancel button) then the client loses its networking ability [for the]
entire session… This is frustrating, but at least it’s better than the
OpenTransport reconnect bug, in that you can leave this client
unattended.”

The buffer fix attempted in -452 caused more problems than it solved for
some people. We’re taking another shot at it, so again: FLUSH your 452
buffers before upgrading to the next release.

MP support and a Mac OS X version of the client are currently being
worked on by our crack-smoking team of top hackers. Stay tuned!

:: 09-Jan-2000 06:24 (Sunday) ::

Ok sorry. Looks like the win32 client was packaged incorrectly. I’m
trying to get a hold of the coder now. please hold off for now on the
win32 client. I will post the minute i get an updated client

sorry for the problems

moose

:: 09-Jan-2000 06:06 (Sunday) ::

The following clients have been updated/added:

– Linux [Sparc/ELF/glibc2/MT]
– Linux [x86/ELF/libc5/MT]
– Linux [x86/ELF/glibc2.1/MT]
– PC-DOS, MS-DOS [x86]
– Windows 3.x [x86]
– Windows 95/98/NT [x86/Zipped]
– NetBSD [m68k] (2000-01-08)

I have updated the clients.html page to be created from a client
database. This has allowed me to create a client page sorted by dated
updated. So from now on I will include a link to
http://www.distributed.net/download/updates.html

This page will be updated every time the clients.html page is updated
from the client database. I hope this helps those of you who wanted a
date listing and a quick refernce to all the clients updated on a
certain day.

:: 08-Jan-2000 19:48 (Saturday) ::

I’ve been receiving some reports of folks who are receiving buffer-error
messages when they try to upgrade their clients to -452 on the Mac OS.
This is a result of new buffer-handling code in -452 that was
implemented to alleviate problems that develop when buffer files are
shared across OSes, and is as such a one-time event.

In general, however, it is always best to flush your buffers (or update
them) prior to starting a new version of the client. I myself run all my
clients with memory-buffers to make sure that I never share them between
versions.

Sorry for any confusion. I’ll stick a note on this in the next client’s
readme.

:: 08-Jan-2000 03:48 (Saturday) ::

The following clients have been updated/added:

– ftp://ftp.distributed.net/pub/dcti/current-client/dnetc-macos-ppc.sit Mac OS ppc v2.8004.452
– ftp://ftp.distributed.net/pub/dcti/current-client/dnetc-macos-fat.sit Mac OS fat v2.8004.452
– ftp://ftp.distributed.net/pub/dcti/current-client/dnetc-openbsd-sparc-aout.tar.gz OpenBSD Sparc v2.8004.452

Enjoy!
Moose

:: 07-Jan-2000 09:47 (Friday) ::

I’ve gotten a very large number of emails asking for clarification
on the distributed.net reissuing policy and for details about
the precise amount of blocks being reissued. I have been distributing
this form letter:

————————————————————————
Greetings!

Thanks for your email regarding my post[1] or about CSC being shown
as more than 100% complete on the statistics page[2].

It is perhaps a common misconception that each CSC work unit
completed is unique. With a short contest like CSC, we have
implemented special keymaster code to use complex tests to verify
the authenticity and validity of each work unit submitted. Malicious
users could conceivably run a tampered version of the distributed.net
client to gain an unfair advantage in statistics and rankings. In
order to test an experimental method of attempting to uncover and
disqualify these users, it was decided that certain CSC work units
would periodically reassigned work done by suspect users to random
clients to ensure that our work is not compromised. As an unfortunate
result, work is duplicated.

There is no question that this method of project security is
suboptimal. We are aware of the flaws of this method and are
working to develop a new generation of clients that can produce
secure and reliable results. Jeff Lawson, distributed.net project
leader, has written an explanation[3] of all of the considered
methods. Distributed.net users can expect to see one or more of
these methods utilized in future clients and contests.

The method used by the keymaster to decide which blocks should be
flagged for reissuing is fairly complex and varies depending on a
variety of factors. At this point in the contest, we generally
have been reissuing between 9.1% to 11.5% of received blocks.

It is distributed.net policy to give users credit for all legitimate
work completed, regardless of whether it’s virgin work or reassigned
work. Accordingly, the completed percentage showed on the statistics
server represents both virgin and reissued work units, so it’s
possible that we go beyond 105% completion.

Every key in the keyspace has an equal chance of being “the” key.
Statistically speaking, it was unlikely that we reached this far
in the keyspace without finding the success key. However, this is
no indication that we will not find the key. We are just as likely
to find the key as we ever were.

I apologize if I didn’t address your issue specifically. I receive
hundreds of messages a day, and that load is growing exponentially
as we get further and further beyond 100% in CSC. If you need
general distributed.net support, please contact help@distributed.net.
Otherwise, can you resubmit your message to me.

Thanks for your continued support. Good luck.

Daniel Baker
distributed.net project leader

[1] http://www.distributed.net/cgi-bin/dnet-finger.cgi?user=dbaker
[2] http://stats.distributed.net/csc/
[3] http://www.distributed.net/source/specs/opcodeauth.html
————————————————————————