:: 05-Oct-1999 19:49 (Tuesday) ::

It’s been a few days since the initial release of our new
self-installer packaging of the Win32 CLI client and we’ve received a
significant amount of good feedback. We’ve taken your responses into
account and have since released an updated version 2.7112.444c of the
CLI self-installer. The actual client is identical to the last one
(and that of the 2.7112.444b zipped version), however some aspects of
the installer have been improved.

Among the things that you may have noticed with our self-installer
Win32 CLI versions is the inclusion of my new “Log Visualizer”
utility. This is actually a separate application that implements all
of the log graphing functionality that was in the original Win32 GUI
client. In addition to improving a number of bugs in the Win32 GUI’s
grapher, since it is a separate application, you can even use it to
view your log files from other rc5des clients on other machines or
platforms. Making the grapher separate also allows you to conserve
memory by not requiring you to have all of the graphing code and log
data loaded while you have the client running all the time.

One of the other exciting aspects about the Log Visualizer is that
full Win32 C++ source code is available for it on our source code
webpage at http://www.distributed.net/source/ This allows experienced
coders to help out by making their own improvements to this valuable
utility and contribute their changes back to the entire
distributed.net community. I encourage interested participants and
Win32 developers and who have spare time to consider helping to
improve it. Inside of its source code distribution zip file is an
initial TODO file listing some possible areas of work. You can email
your modifications back to me and I’ll occasionally update that zip
file with all of the cumulative changes.

We also have a Java Log Visualizer currently in development and will
similarly release source code for it once it has minimal
functionality. We welcome efforts to develop similar utilities for
other platforms! Keep watching for more exciting developments!

:: 19-Sep-1999 13:23 (Sunday) ::

As some of you have noticed, the classic “win32gui” clients have
recently been removed from the clients.html and select.cgi link pages.
The separate “GUI” client was originally deemed necessary because the
only alternative was a console-based version that had a number of
significant limitations:

– required significant user involvement for installation.

– no user interface for client configuration.

– could not be used in environments needing an unobtrusive, hidden
mode of operation that did not interrupt normal logouts

– inability to minimize to the system tray

– no extras, such as “moo sounds” or “log graphing” or pretty
percentage bars.

HOW IT WAS
———-
We have maintained separate releases of both the GUI and CLI Win32
clients for quite awhile now, with our client development focused
around the common CLI-based source code, and the GUI client involving
a fair amount of clever wrappers around it. Although this made
development of the separate versions easier than they would have been
otherwise, there was always a significant delay in the release of the
Win32GUI relative to the equivalent Win32CLI. Additionally, the GUI
client has always suffered from numerous obscure operational bugs
ranging from benign to severe issues.

Meanwhile, each newer release of the common code-base tried to make
incremental code infrastructure changes. This new infrastructure made
construction of other “GUI wrappers” with less effort than what was
necessary to produce the level of integration that the Win32GUI had.
However, because of these major adjustments in the organization of the
common code-base, the Win32GUI began to lag even further behind and
grew kludgier since much of the back-bending efforts that were
previously necessary no longer were. The Win32GUI portion of the code
base really just needed a complete rewrite.

Additionally, the Win32CLI releases had slowly been getting enhanced
with each successive release. The Win32CLI was no longer a console
app at all, and had actually become a GUI-based application itself. A
reasonably friendly textual configuration menu-set was now available
for all clients derived from the common code-base. The Win32CLI was
also able to cleanly start and stop in hidden environments, run as an
NT service, or minimize itself to the system tray. More importantly,
since the new “GUI-ish CLI” was directly compiled from the common
code-base, and the Win32CLI was traditionally one of our primary
development environments, the release delays and obscure GUI-specific
bugs were minimized.

WHAT IS HAPPENING NOW
———————
A new “self-installer” version of the Win32CLI will now be available
for download to make installations simplified. This installer is
nearly identical to the installer that the Win32GUI came packaged in.
Significant effort has been put into making “upgrading” from a prior
Win32GUI installation easy.

The Win32CLI will also now ship with a WinHelp HLP file to make
introductions easier for first time users. Additionally, the
distributed.net Log Visualizer is a new utility that is based heavily
upon code derived from the log grapher portion of the Win32GUI. Full
source code for the Log Visualizer will be available for download on
our source code page.

Although the last released version of the Win32GUI will continue to
operate for the foreseeable future, there will be no newer versions of it
released, and support questions regarding it will generally recommend
switching to the CLI. The Win32GUI will continue to be available on
our FTP distribution sites, although it will not be in the
“current-clients” directory.

We will continue to list and support GUI clients for the other
operating systems that we currently provide separate GUI clients for
(MacOS and RiscOS), however they too will similarly become unnecessary
once our plans (described below) are fully completed.

THE FUTURE
———-
It had always been part of our plans to try to slowly move away from
producing a separate GUI and CLI versions. This included the Win32GUI
and Win32CLI, the MacOS GUI and FBA clients, OS/2 GUI and CLI clients,
RiscOS GUI and CLI, and possible X11/Gnome/etc-based clients.
Instead, we planned to create “detached” front-end GUI applications
that could be run alongside the traditional CLI clients. This would
prevent the complexity of various OS-specific GUI programming
requirements from affect the design of the common client source pool.
Additionally, this detached mechanism might allow for remote
configuration and monitoring to occur over a local network, which has
always been a popularly requested feature for our clients.

So with all of this said, we will now be diverting our efforts from
attempting to maintain separate GUI-specific versions of our clients
and toward achieving our separated GUI frontend and CLI back-end
model. We are beginning development of an extensible communications
interface that will allow multi-platform GUI configuration utilities
to be constructed and arbitrarily configure and monitor remote or
local clients. The projected availablilty of these new clients cannot
be easily estimated at this time, though we will definitely make
future announcements when further information is known.

:: 16-May-1999 03:36 (Sunday) ::

Well, with my studies done and college graduation done for me
tomorrow, I’m finally able to announce that build 306 of the personal
proxy is making its way onto the FTP mirror sites. Only builds for a
few platforms are currently available, but we should have FreeBSD and
a few of the other Linux builds up within the next day or so.

Since the release of the pre-release beta, we’ve tried to improve the
rate-detection and block-window adjustment by increasing the sampling
period that is considered. There have also been a few modifications
of some of the console messages and the period at which others are
displayed.

We are currently aware of the fact that lurkonly mode does not operate
correctly in this final release of 306 on win32. This problem will be
addressed in a future release.

All users running any previous version of the personal proxy are
highly recommended to upgrade to this new version. All new users are
also recommended to *thoroughly* read the text file that accompanies
the proxy. There are significant, but subtle changes in the proxy’s
operations. Network connectivity compatibility should be greatly
improved, especially for HTTP users, or users who were previously
unable to connect out of their firewall through any other means with
the addition of the new “generic proxy” mode.

Do not ask about the 1000 block limit! Read the documentation!

:: 03-May-1999 03:21 (Monday) ::

As I’ve announced on the proxyper mailing list, a pre-release version
of the next version (build 306) for win32 has been made available for
limited testing by experienced proxy users only. If you download this
test version, please send me feedback at bovine@distributed.net even
if you have no problems with it. You can grab the version from:
http://bruteforce.st.hmc.edu/~jlawson/beta/

There have been lots of buffer improvements to address the input I
received regarding the use of the incrementally updated file-system
based buffering that was used in the 300-304 builds. Additionally,
the networking subsystem has undergone a significant amount of work to
improve compatibility with even more http proxy implementations. I’ve
also added a new network communications protocol, generic proxy, for
people who are able to use a text-protocol to establish a connection
through a gateway machine.

We have already received a number of messages regarding this
pre-release version and have addressed a couple of issues that were
brought to my attention. Remember, if you download, please send me
feedback. Hopefully we will see a release very soon now! :)

:: 31-Mar-1999 05:20 (Wednesday) ::

I’ve managed to get several portions of the website finally cleaned up
and updated this weekend. Most visibly this includes our old source
code distribution page, now at http://www.distributed.net/source/
instead of /cores/ as it was before. There will probably be an
updated bundling of our public source sometime in the near future,
though I can’t give you a precise estimate of when.

Also made more prominent links to some of the more obscure pages on
our site. The unmaintained news pages are now gone and replaced by
our single History & Timeline page.

I have also made available some of the vectorized Encapsulated
PostScript (EPS) images of a few of my favorite cartoon cow pictures.
These EPS versions can be enlarged to extremely large resolutions
without pixelation effects. The original low-res bitmaps from which
those were derived contributed to many of our graphics, including the
client application icon used on the Windows, MacOS, OS/2, and RISC OS
GUI clients. You can grab them from http://www.distributed.net/logos/
These might be useful to people planning on submitting poster entries
in our design contest (but you’ll still need to be creative to win).
See http://www.distributed.net/poster.html for details.

In general, things have been rather busy for me since I am a senior
and will be graduating from Harvey Mudd College this May and have been
fussing with job choices and such. Furthermore, I’ll be traveling to
Eindhoven, The Netherlands next Monday for a full week with my
teammates to compete in the ACM International Finals
http://acm.baylor.edu/acmicpc/, so I’ve been tied up with preparations
for that as well.

I’m hoping to be able to get the next build of the personal proxy
released before I leave, otherwise it’ll probably get released when I
come back. There are a number of new features that I’m sure many of
you will greatly welcome.

:: 15-Jan-1999 12:40 (Friday) ::

Build 303 of the personal proxy should begin to become available for
the regular platforms soon. This new build addresses a few issues
that users have been bringing to my attention. Specifically, the few
that I can recall off the top of my head are:

– temporarily disabled logcompressor until buffer corruption can be
completely resolved.
– buffers will autorepair when validation fails.
– updated documentation and sample ini files to more closely reflect
available options and command line arguments
– proxy no longer attempts to window as many block requests if the
additional needed number is low.
– pidfile now contains correct pid when -detach is used.
– much major internal reworking of DES handling code that was being
developed in a separate CVS branch to accommodate EFF macrospace
distribution has been merged into the main proxy code.
– block alignment issue addressed to ensure that blocks crossing the
boundary are not distributed.
– cumulative block totals have been added to the end of the contest
status lines that are periodically printed (“tot=xxx”)
– the contest status lines are now printed every 30 seconds by
default, but this should now be adjustable via the ini file option
[misc]/statusperiod
– additional logic to allow the proxy to intelligently discard DES
blocks from non-active contests added.

It is believed that the execution of the logcompressor may have been
contributing to the corruption of buffers, however we are still trying
to test this hypothesis, since it does not seem completely definite.
Until the issue can be resolved, automatic log compression has been
disabled, but log rotation should still occur. Regardless, buffers
should automatically repair when the proxy detects the condition to be
severe enough.

Unfortunately, I will be out of town all this weekend through Monday
evening, which means that I will not be present for the start of the
contest. I will instead be enjoying my 21st birthday snow-boarding on
the slopes. However, I have confidence that my cow-orkers at
distributed.net can handle the contest start smoothly.

Although I believe this build to be much improved over the original
build 300, I continue to urge users who are still running a build 280
and are not comfortable running code that is still under development
and testing are encouraged to continue running their build 280 until
all issues are resolved.

However, if you have already taken the leap to the build 300 series,
you are highly recommended to upgrade to this latest version when your
platform’s build becomes available.

Thanks again for your support! Please continue to look for problems
and send them to me as you find them.

:: 11-Jan-1999 23:20 (Monday) ::

okie dokey. after reading through all of the helpful feedback that I
received in response to the 300 and 301 releases, I am releasing a new
build 302 which attempts to correct as many of the issues that I have
been able to verify.

windows nt service installation should work now.

blocks should be requested up to maxready now, connections still
triggered by minready.

documentation for ignoredip section updated.

no longer attempts to request des blocks when des is closed.

-repair and -unlock should no longer hang if your buffers have loops
in them anymore.

lots of possibly problems that could lead to buffer corruption have
been fixed.

contest start times that have already passed are no longer given to
clients when they connect.

console output now indicates which contest when blocks are requested,
received, delivered, etc.

proxy should no longer request infinitely many blocks when your buffer
thresholds are too low.

keyserver/bindip now actually works.

many issues that could cause invalid size blocks to be saved or given
to clients have also been addressed.

If you are running 300/301, it is greatly recommended that you upgrade
to 302 (be sure to run the -repair option first) as soon as possible.
Users who are still running a build 280 and are not comfortable
running code that is still under development and testing are
encouraged to continue running their build 280 until all issues are
resolved.

Continue to look for problems and send them to me as you find them.

:: 04-Jan-1999 11:33 (Monday) ::

okay, build 300 of the personal proxy for win32 and linux-x86 are
making their way to our mirror sites for downloadability. Builds for
a few other popular platforms will be made available in a few hours.
Please note that these build 300 proxies will not be able to
communicate to upstream servers until they are upgraded to build 300
as well (which will begin to occur today). Drop me a note if you find
any problems.

:: 03-Jan-1999 10:43 (Sunday) ::

well, as much as we hate to have to do this, it looks like we’ll have
to postpone the test contest again, but this time until (at least)
Tuesday 9:00 Pacific. The main motivations behind this is that we
still don’t believe that sufficient numbers of people were able to yet
download and install the recently released clients due to their late
release. There have also been a number of last minute technical
details that we have had to worry about. We will also hope to start
releasing the build 300 personal proxies sometime today (Sunday).
We’re hoping that delaying will also give more people the opportunity
to participate since the delay would also move the test contest into
the middle of the work week. Keep your eyes open for later details.

:: 03-Jan-1999 00:22 (Sunday) ::

well, finishing touches on the new proxy code is being handled right
now. There were a few minor issues that we found still needed to be
addressed before we felt confident releasing the new proxies.

The new proxies will begin numbering at build 300 and the most
significant changes are probably unnoticeable to the user, since they
are mostly code restructuring issues that will make it significantly
easier to support additional types of contests in the future. I’ve
tried to keep the ini configuration format mostly the same as the
previous build 280 proxies. You’ll also probably notice changes to
the console messages, but the block-done log format is unchanged,
since that is really the only file that we intend to be machine
parsed. If any of you have written proxy console log parsers, you’ll
probably have to make accommodations for the changed messages.

Another significant change is the fact that support for handling
blocks much larger than 32-bits has been supported. Although even the
v2.7103 clients do not support the ability to request blocks that
large, the clients will eventually be made to require communication
with a build 300 or above proxy. Currently the ability of the build
300 proxies to internally support these larger blocks allows them to
need to make fewer requests to your upstream keyserver.

Additionally, block counting in the new build 300 proxies is now
normalized to represent the actual number of 2**28 blocks. This means
that your block thresholds in your ini file will now truly be an
accurate measurement of the amount of work that you have, rather than
the number of work packets (of varying size).

There have also been changes to allow the new “quick start”
(scheduledupdate) feature in which build 300 proxies and v2.7103
clients will be able to receive the time at which the next contest is
expected to start, and cause your proxies and clients to automatically
attempt a connection if they are in lurk or online mode.

At the request of many, online/offline/lurk/lurkonly modes have been
added to the proxy (lurk/lurkonly only available on win32). SIGALRM
will force a connection, while SIGHUP will only reread the ini file.
A new logrotate type of “startup” has been added, causing the proxy to
rename any previous logs to logname.x (x is the next available decimal
number that doesn’t collide with an existing filename). The
workperiod has been eliminated in favor of “connectperiod” (workperiod
originally controlled a number of timed activities in addition to
connections). The buffer files are no longer mirrored replicas of
memory–they are now truly just overflowed blocks (a configurable
number of key packets are held in memory, default to about 16 or
something).

There are probably tons of other little changes that you’ll notice
after the initial release gets out there. We’ve tried to test things
thoroughly, but I’m sure a number of issues will be discovered during
this upcoming test contest. Keep those clients cracking!