:: 16-Jan-2000 21:03 (Sunday) ::

I have just resigned from distributed.net.

Please understand that the organization has done nothing to prompt this.
I am leaving for purely personal reasons, which I’d rather not discuss
publicly, and have no hard feelings whatsoever towards the organization
or any of its members.

Keep on cracking.

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

Now that -453 is out, and a number of the most troubling bugs have been
squashed, we’ve issued a press release concerning the Mac client. You
can find it here:

http://www.distributed.net/pressroom/press-2000-jan-11-macclient.txt

For download URLs to the new clients, see Moose’s plan.

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

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

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

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

:: 22-Dec-1999 02:41 (Wednesday) ::

Some users have reported a perceived CSC speed drop between b2 and the
-450 release of the Mac client. Michael Feiri, the client’s author,
clarifies that this decrease is only perceived, and that there is no
actual decrease in crunching speed.

“AFAIR in the b2 version we didnt do any yielding during a benchmark,
but rather hogged the entire CPU. Now we do yield during benchmarks,
which is likely the cause for the performance decrease you have seen.
The actual CSC crunchers were left untouched between b2 and b9. So the
normal cracking in the release should be as fast as in b2 because even
in b2 we already yielded during normal crunching.”

:: 21-Dec-1999 03:01 (Tuesday) ::

…and out it goes…

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

Just about every major issue relating to the Mac OS client I just signed
& uploaded is covered in the Read Me.

And so, after about a month of blood, sweat and code on the part of
Michael Feiri and Don ‘Dakidd’ Bruder, we have a Mac client that builds
from the common code and is easily updated. The Mac port is here to
stay. Next up: a faceless background application…

:: 18-Dec-1999 08:02 (Saturday) ::

Today is variety day as regards Mac OS port status updates.

The ‘cli’ client (for lack of a better term to describe what is
currently in beta) will not after all contain an Edit menu for copypaste
purposes. The SIOUX window is something to look at and (in configure
mode) use with the keyboard; it is not part of a graphical user
interface. A planned GUI app will gleefuly accept to all the clicks you
hurl at it. Until then, you can copypaste from a log.

Pre-8.0 compatibility is in the works. All linkages to Appearance stuff
has just been chucked, though networking issues remain. Bless Open
Transport.

Fractional build 449 of the Mac client does not contain the AltiVec CSC
core. That is why your CSC rates on G4s suck. It is also (I think) why
the client chooses the wrong CSC core on your cute little grey machines.
Rest assured this will change prior to the release.

More news as it happens, or very slightly delayed…