:: 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
————————————————————————

:: 07-Jan-2000 07:18 (Friday) ::

Ok, everything on CSC should be all set again, hopefully just
in time for us to announce that it’s over tomorrow };8)

(NO, this does NOT mean we found the key yet!) }:8)

:: 07-Jan-2000 06:21 (Friday) ::

-452 is being operated on as I write this; I have binaries on my hard
disk and am banging on them. I’ll detail some bugfixes below, as well as
new developments in the add-on world.

Here’s something cool:

There’s a freeware screensaver available called MacDim, at
http://www.ibrium.se/macdim.html . It launches small modules – basically
applications that are opened via AppleEvents, display their graphics,
and close via another AppleEvent.

We can turn dnetc for the Mac into a MacDim module. :)

Top hackers are planning to work on this, but things like
multiprocessing and bugfixing have higher priority. You’re welcome to
help out. The possibilites are endless – the dimmer could be combined
with the Java log visualizer, an FBA eventually… and the Start&Hide
AppleScript should come in handy.

Let’s put that Windows screensaver to shame! :)

In other news…

Michael Feiri appears to have fixed the reconnect failure bug. “I
switched lowlevel connectivity inside GUSI to MacTCP because in the
OpenTransport variant there seems to be severe connection maintainance
bug that causes the client to lose [its] connection to the outside
world… The result for the endusers is that network IO is now much
slower but on the other hand it seems that the client can now correctly
redial to the internet” when there has previously been a connection.

Also fixed:

– DriversLib no longer needed
– OpenTransportLib ditto
– 68k synced with PowerPC code
– 68k client uses old assembly RC5 code; faster
– modified buffer IO code in an attempt to fix buffer exchange bugs

Coo coo ca choo.

:: 07-Jan-2000 05:19 (Friday) ::

Ok, I finally got back into tally. I’m running the csc em_rank update
right now. In the interest of time, I’m going to shut off http so that
I’m not competing with all of you for CPU time. I promise I’ll turn it
back on as soon as possible!! }:8)

:: 07-Jan-2000 05:06 (Friday) ::

The CSC statsrun isn’t co-operating again. I’m trying to fix it,
but I’m getting 80% packet loss to statsbox. More as the situation
unfolds…

:: 06-Jan-2000 12:55 (Thursday) ::

We’ve gotten a handful of questions recently from people who are
excited about the recent announcement about work verification. I’d
just like to take this opportunity to point people to the existence of
an old document of mine that has been public for awhile that describes
many of the issues involved and some of the methods we had considered.
http://www.distributed.net/source/specs/opcodeauth.html

:: 06-Jan-2000 03:35 (Thursday) ::

The following clients have been updated/added:

– dnetc-aix41.all.tar.gz Aix 4.1 all platforms v2.8004.451

Enjoy
Moose

:: 05-Jan-2000 07:04 (Wednesday) ::

I discovered/realized that the changes made to the psearch code
will end up requiring some changes in the statproc code as well.
This is always a bit of a hassle, since there are two copies of
statproc code, one for each contest. Instead of making the changes
in both places, I decided to make the changes necessary to allow
the two scripts I changed to work for both contests.

Unfortunately I didn’t realize the RC5 statsrun was still happening.

Net result is that the ranking portion of the RC5 code is now re-
running. Unfortunately, I lost yesterday’s overall email ranking
in the process, so everyone will show up as having moved 0 places
overall in tommorow’s stats. The ranking will be back to normal
tomorrow.

Until I get these changes finished, the participant search function
may stop working for a short time after the rc5 statsrun (it will
only stop working for rc5 folks). CSC *should* be ok.

The good news is that I am working on (and making progress on)
allowing Nugget, Bruce, and myself to have small-scale copies of
the stats database that we can tinker with. This should help
eliminate some of these problems that we’ve been having as of late.

Again, thanks for you patience.