:: 04-Jan-2000 03:40 (Tuesday) ::

The following clients have been updated/added:

– dnetc-macos-ppc.sit Mac OS PPC/OS8.x+ v2.8004.451
– dnetc-macos-68k.sit Mac OS m68k/OS8.x+ v2.8004.451

Enjoy!
moose

:: 04-Jan-2000 03:38 (Tuesday) ::

ftp://ftp.distributed.net/pub/dcti/current-client/dnetc-macos-ppc.sit
ftp://ftp.distributed.net/pub/dcti/current-client/dnetc-macos-68k.sit

Okay, they’re out. I made the fatal mistake of announcing that they were
in the pipeline prior to their actually being in the pipeline; a horde
of anxious users flooded Moose with some emails that he didn’t have to
receive. I won’t make that mistake again…

I yanked the ‘start & hide’ applescript from the 68k distribution just
before upload because of a few reports of it being faulty. Various
applescripts will become separately available as support for that
technology in the client increases.

You’ll also find that the 68k client hogs your CPU. This is (obviously)
a timing issue, and we’ll work on it in future releases.

I’ll keep you posted.

:: 04-Jan-2000 02:45 (Tuesday) ::

The following clients have been updated/added:

– dnetc-win32-x86-setup.exe Windows 95/98/NT/2000 Installer v2.8004.451
– dnetc-bsdi2-x86-aout.tar.gz BSD/OS 2.x/3.x x86 aout v2.8004.451

Happy Cracking
moose

:: 04-Jan-2000 02:10 (Tuesday) ::

Build 451 of the Mac OS client will be hitting an FTP site near you in
the very near future. A quick version of the release notes follows.

We’ve gone 68K! The 68K client is identical in function to its faster
PowerPC brethen (as well as every other distributed.net client). The 68K
client can participate in the CSC contest. Don ‘Dakidd’ Bruder is the
brain & fingers behind latest addition to our family of clients.

The current CSC G4 core has been sped up by 70% in build 451, without
using Velocity Engine enhancements. Our CSC bitslicer is chasing tail at
college; he’s obviously not having much success, or else he would be on
the Net more. (Or is that backwards?)

Misc bugfixes: random blocks are generated again, and the timestaping is
now correct. G4s choose the proper core, and ‘Benchmark All’ benchmarks
all the available cores. As always, send all new bugs to bugzilla.

:: 03-Jan-2000 08:47 (Monday) ::

As we near the 100% mark of CSC keyspace completion, I think it’s
time to explain what that CSC statistics mean, and how they are
determined.

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 to suspect users and random clients
to ensure that our work is not compromised. As an unfortunate
result, work is duplicated.

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 well beyond 100% completion.

Please remember that from the viewpoint of the network, submitting
duplicated work units is different from submitting blocks that have
been redistributed for secondary revalidation. Duplicated work is
defined as either re-uploading the same results or uploading stale
blocks that have already been recycled and redistributed. Meanwhile,
work units that have been redistributed for reverification will
have different sequence numbers and are credited as distinct pieces
of work. Please keep this information in mind when parsing our
statistics.

Thanks.

Daniel “dbaker” Baker and Jeff “bovine” Lawson
distributed.net project leaders

:: 02-Jan-2000 18:19 (Sunday) ::

The following clients have been updated/added:

– dnetc-win32-x86.zip Windows 95/98/NT/2000 x86 v2.8004.451
– dnetc-win32-alpha.zip Windows NT Alpha v2.8004.451
– dnetc-win16-x86.zip Windows 3.1 v2.8004.451
– dnetc-dos-x86.exe DOS v2.8004.451
– dnetc-freebsd-x86-elf.tar.gz Freebsd X86 [Elf/MT]

The files will not show up on the mirrors for another 15 minutes or
so, so please be patient. Also, I will not be updating the
clients.html page till a bit later today. I have to run out the door.
You can either directly download them from the FTP server, or use the
existing links.

Here is the update to the Changes.txt file:

2.8000
——

2.8004.451 fix: OS/2: Fixed crash in -config by using different API calls
fix: OS/2: included the forgotten CSC-MMX core.
fix: win32 Alpha: network connect()
fix: all: 2 digit date in log-by-mail
fix: MacOS: buffer transfer to non-Mac works again
fix: solaris x86: multithreading works correctly now (uses
native threads bound to LWPs instead of pthreads)

Enjoy!
Moose

:: 02-Jan-2000 12:46 (Sunday) ::

The first major release of the new Java Log Visualizer has been made
available on the addons page with accompanying source. This new Java
application (not applet) should be usable on any platform with a
reasonable Java 1.1 implementation. You can find the new version at
http://www.distributed.net/download/addon.html

:: 02-Jan-2000 01:43 (Sunday) ::

We tried to be clever, and it didn’t work out… We tried to recover
some of the team joins performed during the 27-Dec to 29-Dec and it
looks like our code accidently unjoined a few people from their teams.
The problem doesn’t look too widespread, but it may have affected you.
If you notice that your blocks are not being properly assigned to your
team (you’d see this in the members list), please kindly rejoin your team.

If your team doesn’t provide a member’s listing, you can verify that
you’re still properly joined to your team by editing your participant
information, which will show your current team affiliation.

Sorry for the mishap.

:: 31-Dec-1999 01:29 (Friday) ::

I’ve updated the team info in the master tables to reflect what it was
yesterday. If the csc logs ever show up from the master, we’ll be good
to go. If they’re not in by 1:45GMT, rc5 stats will end up running, in
which case we’ll run the CSC stats afterwards.

:: 30-Dec-1999 21:14 (Thursday) ::

For all of you who want to know the gory details of what happened to stats
last night, here they are.

About a week ago, Sybase skipped a bunch of identities in STATS_Participant,
the main participant info table. This tends to happen when the server is
shut down abnormally, and has happened several times in the past. Unfortunately,
we didn’t catch it when it happened this time, so there were several days of
data with bad participant IDs. This meant re-writing the script we use to
correct this problem.

We re-wrote the script a few days ago, but hadn’t run it yet. Yesterday, Bruce
came up with a change for the statsrun code that would allow us to eliminate
the identity field from STATS_Participant, thereby getting rid of this issue.
Since this would also require rebuilding STATS_Participant, it seemed a perfect
time to fix the identity problem.

With the new statsrun code in place and looking good, I was ready to run the
re-identity script. I almost made a backup copy of STATS_Participant, but
remembered that the re-identity script made a backup copy on it’s own. Of course,
this breaks an axiom of computers that goes something like ‘Too many backups is
almost enough.’

The script had a minor syntax error, and in the process of trying to debug it, I
ran the script several times. This had the unfortunate side-effect of sending all
traces of STATS_Participant to the great bit-bucket in the sky.

Not to worry, we make weekly backups of the database for this very reason. With a
boatload of help from Nugget, we got a copy of STATS_Participant from Dec 27 back
into the database. Though, it took us three tries to figure out how to get it back
in without having Sybase redo all the identities.

Once that was in, we fixed the identity problem (making loads of backups along the
way this time) and pondered how to recover the participant data and team info that
had been changed/added to STATS_Participant in the past few days. We decided that
re-running those days from logs would be the easiest.

We extracted the days in question from the master tables and used that info to reset
everyone’s team affiliation to what it was for the 12/28 statsrun (a process that
ended up taking a few hours). We fired off the statsrun and waited. We had to fine-
tune Bruce’s code a bit, but things seem to be going well now and the 12/29 RC5 data
is just about done.

The only thing left to do is re-assign blocks for the past few days to the correct
teams for the handful of people who changed their team membership during those days.
Because that hasn’t been done yet, some of the team stats might look a bit off.
After tonight’s statsrun, everything should be back to normal.

I’m glad we won’t have this problem with STATS_Participants again! }:8)

Thanks as always for your patience and CPU time.