staff blogs staff keep (relatively) up-to-date logs of their activities in .plan files. These were traditionally available via finger, but we've put them on the web for easier consumption.


mfeiri [05-Sep-2004 @ 17:01]

Filed under: Uncategorized @ 17:01 +00:00

:: 05-Sep-2004 17:01 GMT (Sunday) ::

A couple of months ago I held a lecture about “Cheating in public
distributed computing” at the 20th Chaos Communication Congress, one of
the biggest annual hacker conferences in Europe. I discussed the impact of
cheating on distributed computing projects and illustrated several
possible ways to handle the problem. The slides are now available under a
CC license. Additionally I have formulated 3 basic “anti-cheat” rules that
anyone should read before starting a public distributed computing project.

You’ll find everything at


mfeiri [16-Aug-2004 @ 04:11]

Filed under: Uncategorized @ 04:11 +00:00

:: 16-Aug-2004 04:11 GMT (Monday) ::

I am pleased to announce the immediate availability of festog, an all new
cruncher to search optimal and near optimal golomb rulers.
Festog is a complete rewrite from scratch but it uses and extends (!)
techniques learned from many previous efforts by different people and
organizations. Festog stands for “FEiris Successor TO Garsp” which is a
hint to its main ancestor, the currently dominant cruncher called “Garry’s
Adaptation of Rado’s Search Priciples”.
I started to work on this rewrite in January 2002. In September of 2002
the first working code was previewed internally at,
already including a 64bit version and entirely new ways of computing
constraints that limit the backtracking during the search for OGRs. Now,
after more than 2.5 years in the making, I feel that it is time to share
the results with the public.

Festog is now freely available as source code under a BSD license from

A number of lessons learned in festog have already been used to enhance
the existing garsp cruncher in dnetc. But festog represents a whole new
platform that can use much more powerful constraints, that make it possible
to skip significant parts of the search space.

I have run a short sample stub 25/3-2-15-26-30-4 to show the difference on
my 1.25 GHz PowerBook G4:
dnetc needs 48 minutes to check 54 billion nodes to finish this stub
festog needs 9 minutes to check 7 billion nodes to finish this stub

Unfortunately these powerful constraints make festog incompatible with the
crunchers that are currently in use at Therefore festog
can not be used in dnetc anytime soon. But if you are as excited about
festog as I am, you can send me an email at and participate
in a quick (maybe a couple of months) search for nogr20+48 using festog.


mfeiri [14-Aug-2004 @ 02:24]

Filed under: Uncategorized @ 02:24 +00:00

:: 14-Aug-2004 02:24 GMT (Saturday) ::

Just to make this clear. No, I’m afraid I cant simply build one more
client for macos classic. I have moved on to Mac OS X and I do honestly
not feel at home in Mac OS 9 anymore. Since my Titanium PowerBook died a
couple of months ago I dont even have a computer that can boot into Mac OS
9 anymore. My new Aluminium PowerBook can run Mac OS 9 in the Classic
Environment, but I rarely use this feature at all. And my old PowerBook
Duo 230 cannot boot Mac OS 9 either :-)
Additionally I think that there is probably a lot of “bitrot” [0] that
will need to be taken care of before a new client for macos could even be
built. Sorry.

Let me try to explain what it takes to resurrect the port of dnetc to

First you will need to have a working development environment to build
dnetc. An old copy of Metrowerks CodeWarrior Pro or a free copy of Apples
abandoned MPW Toolkit [1] will do. If you use Codewarrior you should take
care to get a version that supports 68k. Additionally you should get the
MrC Compiler Plugin[2] , because MrC often generated faster code than some
of the old versions of CodeWarriors own compiler.

Now, the biggest problem when porting dnetc to macos is its reliance on a
lot of unix APIs, especially in the realm of networking. In order to stay
close to the mainline dnetc codebase we have tried to use GUSI [3] to be
able to use these features under macos. Unfortunately this solution was
never without problems and GUSI seems to be orphaned now too.
Another problem are hard to trace bugs that might be related to the
unconventional way of doing multiprocessor aware threading in macos. Take
a look at bugzilla [4] and search for bugs related to macos to get an
Additionally a prospective porter would need to be able to take care of
various particularities of the old Mac OS, including the testing of the
cooperative multitasking, packaging the builds (resource forks, memory
assignment, old compression formats,…) and maintaining custom code to
make dnetc a proper citizen in a macos environment.

If you want to try it, the tarball with our public client source code [5]
should be a good place to start a new port or to resurrect the old one.



mfeiri [12-Aug-2004 @ 03:06]

Filed under: Uncategorized @ 03:06 +00:00

:: 12-Aug-2004 03:06 GMT (Thursday) ::

I never used my .plan before, but some people might know that I used to
maintain the macos and macosx builds of dnetc during the last couple of
years. My interest has shifted towards writing an all new OGR cruncher and
Didier Levet, aka kakace, took over the maintenance of the macosx port.
Didier is doing a fantastic job! But the port to macos – e.g. System 7.x,
Mac OS 8.x and Mac OS 9.x – is now abandoned. If anyone out there feels
motivated to resurrect this port please contact me at