:: 14-Jul-2000 07:19 (Friday) ::

A common question that I’ve been asked is what size the client actually
uses when you leave the block size setting at its default value of “-1”.
As it turns out, the built-in default is 2^30. You can see this by checking
the PREFERREDBLOCKSIZE_DEFAULT that is defined in client.h in the public
client source code.

However, even when you leave the client configured to the default size of
“-1” (or configure a larger block size), it is still possible for you to
receive the small 2^28 sized blocks. If that is the case then there is
nothing for you to be concerned about, since the servers would already be
trying to assign you a block size that most closely matches your request.
Receiving blocks smaller than what your client requests is frequently
common because that is the only block size available after the heavy
key-space fragmentation of so many other people explicitly requesting
smaller sized 2^28 blocks.

And just a reminder for anyone that may have too busy with all of the
recent activities and forgotten… July 15th is Cow Appreciation Day!
Blue-mountain offers us the following description: Started in Woodstock,
Vermont, Cow Appreciation Day involves many cow-related activities, such
as butter and ice cream making lessons, and dairy education programs. For
those unable to attend, it’s an excellent time to reflect on the important
role that cows play in all our lives.
http://www.bluemountain.com/eng3/susie/UNHudderly.html

:: 06-Jul-2000 06:53 (Thursday) ::

I just thought I’d let everyone know that we’re currently experimenting
with enforcing a minimum block-size for RC5. This means that even if you
have your clients configured to request 2^28 blocks, you will likely get
a larger sized block instead. As we are being faced with an ever increasing
amount of network traffic caused by our phenomenal growth, we would like
to explore the impact cause by allowing smaller sized blocks to be
explicitly requested by clients.

So far, we have found that an extraordinary number of people configure
their clients to request small 2^28 sized blocks, even though their
processors are more than adequately fast enough that packets are completed
frequently enough that there is no legitimate need for those specific
machines to configured to request such small blocks. Although allowing
your client to process smaller blocks has the visual appearance of seeming
to complete work packets more rapidly, it does place an increased burden
upon the donated network resources of our servers, in addition to increasing
the daily processing overhead required by our stats server. It additionally
contributes towards keyspace fragmentation at a greater rate than larger
blocks do.

Therefore we’d like to request that everyone evaluate their client
configurations and check whether they’ve configured their client to
specifically request small 2^28 sized blocks and think about whether you
really need to request blocks that small. If your machine completes a
2^28 sized block in less than 45 minutes, than your computer is fast enough
that it really should be processing larger blocks.

The ability to request small blocks should really be reserved for unstable,
slower machines that might have greater potential of crashing before
completing an entire packet. Additionally, those slower machines should
definitely consider enabling checkpointing, to allow blocks that are lost
in the middle of processing to be resumed. Note that clients that use
network shared ini’s and buffers need to use distinct checkpoint files,
so you should use caution if you administer machines in that manner.

:: 05-May-2000 05:29 (Friday) ::

Within the last few days we’ve been getting reports from some users that
their virus scanners have suddenly begun detecting the presence of the
Win32.Weird.12288 virus within DNETC.EXE, DNETC.COM, and DNETC.SCR of the
v2.8007.458b client. This false report is known to occur with the May 1
version of the VET Virus scanner, and we have been assured that the error
has been corrected in their most recent virus signatures. Most users
would probably have updated to the corrected signatures if they had also
updated to signatures that include detection of the ILOVEYOU worm anyways.

:: 04-May-2000 12:58 (Thursday) ::

An updated client source tarball has been made available. It contains
all of the improvements that we have made in the recent beta series of
clients, including an optimized Athlon RC5 core.
http://www.distributed.net/source/

Additionally, a few new utilities have been added to the Add-ons page in
the last few weeks, including a new MooSounds perl script that is usable
on many UNIX platforms. You might want to take a brief look at our download
page again if you haven’t done so in awhile. There might be a useful
utility or two that you didn’t know existed.
http://www.distributed.net/download/addon.html

:: 20-Mar-2000 05:28 (Monday) ::

A few users have expressed interest in finding out the latest status of
the clients, and I’m glad to say that we are getting very close to being
able to release the next batch of clients and proxies. Although we’ve
had the OGR specific problems addressed for quite awhile, we’ve been taking
the opportunity to try to address as many of the other feedback issues
that have been received over the last few months. The upcoming client
release is currently undergoing internal beta testing and we hope to have
more details about their release shortly.

:: 01-Mar-2000 16:50 (Wednesday) ::

I’ve made some modifications to the Faq-o-matic codebase to allow it to
display “updated” icons next to answers that have been recently modified.
This makes it much easier to see things that have been updated within the
last week. As a part of the GNU public license, I’ve contributed my
patches back to the original author and he has indicated that they will
be integrated into the next release. You can check out our FAQ at
http://www.distributed.net/faq/

:: 25-Feb-2000 00:34 (Friday) ::

I’ve rewritten the speed database submission page so that it is much
friendlier. Additionally, the database updating process is now completely
automated, so your entries should now be immediately visible. Go check
it out today by visiting the speed page at http://www.distributed.net/speed/
and clicking on the “Submit” link.

:: 14-Feb-2000 19:03 (Monday) ::

Yes, the OGR contest launch has been moved forward slightly just to give
us a little more time to syncronize all of our upgrades behind the scenes.
It has now been officially set for Tue Feb 15 06:00 UTC.

:: 12-Feb-2000 09:52 (Saturday) ::

This past week distributed.net has been busy with the final preparations
for the official launch of our OGR project. Monday, February 14th will
officially be the first day of the project.

Client version v2.8007.458 will be the minimum build from which OGR results
will be accepted from, even though earlier builds on some platforms included
preliminary beta OGR support. Please be sure to verify all of your
installed client versions.

The website has also been updated with more details regarding OGR and
reference links to other sources on the net. I encourage you all to check
it out! http://www.distributed.net/ogr/

:: 05-Feb-2000 21:42 (Saturday) ::

In an attempt to allow us to keep a more up-to-date FAQ listing available,
I’ve just installed a new FAQ-O-Matic tool that allows anyone to contribute
new Answers to the document, directly from your web browser. Come check
out this great new tool at http://www.distributed.net/~bovine/fom/