Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 May 2013 05:06:08 +0400
From: Solar Designer <>
Subject: tested on ancient Linux


FWIW, I've just test-built the current core tree, version, on a
system installed in 1997 (which had few changes made to it since then):
gcc, libc 5.4.38 + my ancient patches, Linux 2.0.40 + my ancient
patches, running on Pentium II (Deschutes) at 400 MHz, 1.6 GB disk (yes,
still working), 768 MB RAM (upgraded some years ago, original size was
less).  This machine is doing some useful work since 1997 (I think its
uptime for these 15+ years is over 99.9%; current is less than a year,
but this system has had its share of jiffies overflows before).

Well, the current core John tree builds and works on this machine fine,
as linux-x86-mmx.  I had to make only the following obvious and expected
changes in the Makefile:

- dropped -Wdeclaration-after-statement from CFLAGS;
- dropped -Os from OPT_INLINE (we even have a comment stating that this
is needed for ancient gcc);
- dropped -lcrypt from LDFLAGS inside the linux-x86-mmx make target
(since libc5 had crypt(3) right in libc, with no libcrypt).

I even tested a --fork=2 run, even though there's only one CPU here.
It worked fine, although due to "Idle = Y" in the default john.conf one
of the processes ended up yielding almost all of its CPU cycles to the
other.  I saw this behavior with overbooked modern systems, too.
I think it's actually fine.

Of course, we don't really care about running new John on ancient Linux
like this, but it serves as a portability test and it could expose bugs.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.