tzanger wrote:
> It's my understanding that ECC works on the smallest data width available, which is 64 bits on SDRAM
> anyway. When your P4/2.1G grabs a single byte and there's a cache miss, it fetches the entire row
> (8 bytes) from RAM anyway. Block-based, yes, but no bigger than normal.
Wrong. SDRAM is 64 bit wide, but can be written in units of 8 bit. A read is always 64 bit wide.
A single 8 bit write to ECC RAM becomes a 64 bit read, check ECC, update byte to be written, recalculate ECC, write. So you are going to get a small speed penalty compared to the non ECC case of just a single 8 bit wide write.
The idea with ECC is that the ECC controller (a peace of hardware between the CPU and the RAM) should detect the bit error and correct it "on the fly", so that the application should not
be affected by the bit error at all. You get a speed penalty by doing ECC, because the ECC controller have to calculate a check sum for every write, and check the check sum
for every read. Even worse, the ECC check sum is block based, so the ECC controller have to read the whole block to calculate the check sum even if the CPU only reads a single byte. The same goes for writes. To use ECC you need special
RAM which is 72 bit wide instead of 64 bit, the
extra bits are used for the check sum. This also
explains why ECC RAM is more expensive that non ECC ram.
Known Issues
============
Driver Hangs Under Heavy Traffic Loads
Intel is aware that previously released e1000 drivers may hang under very
specific types of heavy traffic loads. This version includes a workaround
that resets the adapter automatically if a hang condition is detected. This
workaround ensures network traffic flow is not affected when a hang occurs.
This is for the driver verion 4.1.7, released 3/23/2002 (ie. quite new). Older versions had
even bigger problems. This might explain why
the Intel adapter does so bad in this test. I
wish that Intel gets a clue and releases all
card specs and GPLs the existing driver so
that a true (stable) open source
driver could be written and included in the
linux kernel. I think the hardware is OK, but
the drivers sucks.
I must be dreaming, postfix and vsftp in the next redhat. I am going to upgrade my servers to 7.3 when it is ready. Yes, definitely, yes, going to upgrade...
Per the license: "You are hereby granted
permission to copy and distribute the Software
without written agreement from NaN, only for
non-commercial purposes."
Other parts of the software, such as the blender
render daemon, are fully Open Source and Free
Software, released under the new BSD license.
I like C, but I think they got this the wrong way around...
Instead of creating a scripting language out of C, they should have
created a good way to embed html codes in the C source (eg. a
pre-processor and a custom library), and compile the pages to a
cgi program.
This way you will get the best out of both worlds. You can code in
C, and get real compile time checking instead of an interpreter failure
because of a misspelled variable name or keyword. You get the speed
of a compiled program and the C code can contain real html with no escape characters.
With a good library (no libc by default, that is too risky...) you can
get access to apache internals, code in C (that is the whole idea,
isn't it ?) and get super fast performance. The library needs a large
collection of string handling functions.
Many virus scanners don't scan.swf file by default, so you have update your virus signature file (which is automatic on most scanners) and reconfigure your scanner to scan.swf files (unless you already scan all files on your computer).
This means that if advanced.swf viruses are created, they could become a real problem
until system admins wakes up and gets a clue (and that takes a loooong time, look at Code Red)
The parent poster, for example, is trying so hard to impress with his
knowledge of the history of/var (available in pretty much any *nix book),
yet fails miserably when it comes to understanding that there is no gun to
his head forcing home to keep html in/var/www. I agree, I think/var/www
is an odd place for html data, but there's always the option of changing
your http root directory, moving it somewhere else and symlinking back
to/var/www, or a few other options.
I would agree with you, if it only was/var/www, but how about the complete
postfix chroot environment in/var/spool/postfix
(eg./var/spool/postfix/etc/passwd ) ? What about the printer configuration
files in/var/spool/lpd/{printer name}. What about the gdm faces in/var/gdm ?
Heck, how about the compete RPM database in/var/lib/rpm ? This is all
pollution of the/var hierarchy.
In a follow up omega9 writes:
Anyway the point of this post is just to mention that all distros that I'm
aware of that use the/var/www directory for html data do not actually store
it there./var/www/html is a symlink to/usr/local/apache/htdocs by default.
You are lucky, the only distro that I know well (RedHat) stores the html files in/var/www since
RedHat 7.1./var/www/html is a real directory. Which distros are you aware of ?
The/var directory used to be for files that are difficult to
backup to tape, because they varies too much (*see* that's the reason
for its name). A backup of/var used to be outdated after a few hours.
The print spool, the incoming and outgoing mail spool, pid and lock
files and the man file cache are all files that changes rapidly, and in
general does not need to be backed up every day. You need a backup of
its directory structure in case of a disk crash, but doing a complete
backup every night used to be a waste of time.
That is history. Now people
wants to mount/usr read only, so they are slowly moving all
files that must stay on a RW file system from/usr to/var (eg./var/www
for your web site). This is stupid, because you need to do a
backup of some directories in/var but not all. The grand idea of/var
is lost.
My nomination for is Wietse Venema, the author of the postfix mail server.
Why:
Have a look at the source code, it is a textbook example of
how a program should be written. It is just amazing how well
the code is commented (all 100.000 lines of it), and Wietse
is doing a fine job of maintaining the code. The program is
well behaved (also in severe error conditions like out of
memory/disk space, high cpu load, network failures, etc), and
have an excellent reputation for being "virtually bug free"...
Postfix is simply the finest piece of software I have ever
compiled and used, and I hope that the award goes a person because of his exceptionally high software
standards: Wietse Venema.
The glibc limits the file size to 64 bit (9 million terabytes), so unless the POSIX LFS api changes, that is the current maximum file size regardless of the file system (on x86 that is).
A 9 million terabyte file size limit isn't a large problem for me....
Many A/D and D/A converters use sigma-delta converters
(Look for words like: "one bit converter" or
"bit stream", they are variants of this technology).
Most sound cards use these sigma-delta converters, so do many A/D and
D/A cards for PC, especially those with high dynamic range
(many bits...). These converters have excellent linearity,
low distortion, and are inexpensive, but they have a significant
time delay, so you might have more than 1 ms delay in the A/D
converter alone. No real time OS can work around that.
Be sure that you select A/D and D/A converters with "sub ms" time delay.
I have been playing with the 7.2 betas (roswell) since it came out, and
with the 7.2 release for about a week now.
I am very pleased with Redhat 7.2, it has given me very few problems, and
it was the first Linux distribution that installed into my laptop without
any tweaks.
The main enhancements (as visible by the user):
Grub instead of lilo (but you can still use lilo if you want to..).
Grub is a great boot loader, similar to the "boot monitor" of real
Unix hardware. Grub understands the file system, so you do not need
to reinstall Grub every time you update your kernel (like you have to
with lilo). Once you are in the grub boot promt, you can boot any OS on
your system (eg. from a floppy)
Mozilla and Nautilus: (I am a gnome user)
Mozilla 0.9.2.1 is a rather old release, but it was the release chosen
by Netscape for NS6.1 so it is quite good. Nautilus is 1.0.4 + a lot of
patches from RH (Alan Cox ?) to speed things up. Natilus is still somewhat
slow, but I don't use file managers so much, so I don't care. I think that
you should have at least 128 MB ram to run it, is was slow on one of my
test machines with 64MB ram and a sub optimal disk system. Seeing the
speed and stability improvements of Mozilla in the last 6 months, I am
quite confident that Nutilus will be a great file manager (++) in a short
time frame. It is a very good "eye candy", and impresses every Windows
user seeing it. If you for one reason or another, don't like Nautilus,
use the good old GNU Midnight Commander instead (yes it is on the CD).
Kernel, gcc, ptyhon, etc
The kernel is 2.4.7 + a lot of patches. Since RedHat 7.1 is at kernel
2.4.9-6 already, I believe that we will see an updated kernel soon. The
main compiler is RedHats own 2.96 + modifications, and python is at
1.5.2-35. You will find gcc 3.01 and python 2.1.1 on the CD which can
be installed separately. RedHat 8.0 will probably use these as default.
Postfix, Apache:
Redhat has dropped support for Postfix (a sendmail replacement), which
used to be on the Powertools CD. I really don't know why, but I hope
that the next RedHat release will fix this major bug. Apache is the
rock solid 1.3.20.
Executive Summary:
RH7.2 is a polished good distribution. Since it is a.2 version, RedHat
is going to support it for a looong time, and it will become the first
choice for many system administrators for serious linux servers (that is,
until 8.2 is released).
I think it is a bad idea to try to make Linux run Windows executables.
IBM made this mistake with OS/2. OS/2 ran Windows applications almost as
good (some say even better than) on native Windows. The result was that
programmers wrote applications for Windows only, they ran after all on
OS/2 also. Little native OS/2 software was written.
Microsoft made Windows
a moving target (and it still is...), making it impossible for IBM to
have the Windows emulation work in OS/2 for every respin of Windows. The
rest is history, please don't let this happen once again with Linux.
I believe RedHat have the same problems, since RedHat 7.2 has been
ready (even on the mirrors) for some time now, but they will not
distibute it (ie. add the everyone-read bit to the file permissions)
until they have the CDs ready.
The RedHat 7.2 relase is available trough rsync....
*** Welcome to the Purdue University Computer Society RSYNC Server
*** Purdue University, West Lafayette, IN
http://csociety.ecn.purdue.edu/
This archive is available via FTP, HTTP, and RSYNC at:
ftp://csociety-ftp.ecn.purdue.edu/pub/
http://csociety-ftp.ecn.purdue.edu/pub/
rsync://csociety-ftp.ecn.purdue.edu/pub/
*** Welcome to the Purdue University Computer Society RSYNC Server
*** Purdue University, West Lafayette, IN
http://csociety.ecn.purdue.edu/
This archive is available via FTP, HTTP, and RSYNC at:
ftp://csociety-ftp.ecn.purdue.edu/pub/
http://csociety-ftp.ecn.purdue.edu/pub/
rsync://csociety-ftp.ecn.purdue.edu/pub/
Report problems to ftp@csociety.ecn.purdue.edu
receiving file list... done
wrote 106 bytes read 500 bytes 242.40 bytes/sec
total size is 226 speedup is 0.37
Slashdot Mirror
tzanger wrote:
> It's my understanding that ECC works on the smallest data width available, which is 64 bits on SDRAM
> anyway. When your P4/2.1G grabs a single byte and there's a cache miss, it fetches the entire row
> (8 bytes) from RAM anyway. Block-based, yes, but no bigger than normal.
Wrong. SDRAM is 64 bit wide, but can be written in units of 8 bit. A read is always 64 bit wide. A single 8 bit write to ECC RAM becomes a 64 bit read, check ECC, update byte to be written, recalculate ECC, write. So you are going to get a small speed penalty compared to the non ECC case of just a single 8 bit wide write.
Because you turned off the ECC checking ....
The idea with ECC is that the ECC controller (a peace of hardware between the CPU and the RAM) should detect the bit error and correct it "on the fly", so that the application should not be affected by the bit error at all. You get a speed penalty by doing ECC, because the ECC controller have to calculate a check sum for every write, and check the check sum for every read. Even worse, the ECC check sum is block based, so the ECC controller have to read the whole block to calculate the check sum even if the CPU only reads a single byte. The same goes for writes. To use ECC you need special RAM which is 72 bit wide instead of 64 bit, the extra bits are used for the check sum. This also explains why ECC RAM is more expensive that non ECC ram.
jzw of Mozilla/Netscape fame have a hypothetical program called Intertwingle which is (Score:5,Interesting) ....
There must be something wrong with the graphs for the e1000 packet size vs. throughput plot, I believe the axis are reversed.-
Also Intel acknowledges that their e1000 adapter have driver issues under linux. This text is from: ftp://aiedownload.intel.com/df-support/2897/ENG/re adme.txt
Known Issues
============
Driver Hangs Under Heavy Traffic Loads
Intel is aware that previously released e1000 drivers may hang under very
specific types of heavy traffic loads. This version includes a workaround
that resets the adapter automatically if a hang condition is detected. This
workaround ensures network traffic flow is not affected when a hang occurs.
This is for the driver verion 4.1.7, released 3/23/2002 (ie. quite new). Older versions had even bigger problems. This might explain why the Intel adapter does so bad in this test. I wish that Intel gets a clue and releases all card specs and GPLs the existing driver so that a true (stable) open source driver could be written and included in the linux kernel. I think the hardware is OK, but the drivers sucks.
Zeinfeld wrote:
Look at the activecard tags, we switched to them because they are half the price of SecureID and more reliable to boot.
Can these be used with Linux? I couldn't find any info on their web site (www.activcard.com ?)
Yes !!!
postfix-1.1.4-3.i386.rpm
vsftpd-1.0.1-4.i386.rpm
I must be dreaming, postfix and vsftp in the next redhat. I am going to upgrade my servers to 7.3 when it is ready. Yes, definitely, yes, going to upgrade ...
The one thing I am missing in our server room is a plain phone....
>It's already GPLed, Einstien.
Wrong.
from Freshmeat:
Per the license: "You are hereby granted permission to copy and distribute the Software without written agreement from NaN, only for non-commercial purposes."
Other parts of the software, such as the blender render daemon, are fully Open Source and Free Software, released under the new BSD license.
Why not go directly to the source:
http://developer.intel.com/design/intelxscale/
Here is the info on the PXA250 CPU .
You will find specs, datasheets and all the goodies.
My favorite:
http://www.dwheeler.com/secure-programs/
Yes but you are still stuck with code like:
printf("<tr>\n");
printf("<td colspan = \"2\">\n");
printf("<img src=\"/img/myimage.png\" alt=\"comment\" border=\"0\" height=\"100\" width=\"150\">");
Not very readable. We need a preprocessor which embeds the HTML code in C for readability.
I like C, but I think they got this the wrong way around...
Instead of creating a scripting language out of C, they should have created a good way to embed html codes in the C source (eg. a pre-processor and a custom library), and compile the pages to a cgi program.
This way you will get the best out of both worlds. You can code in C, and get real compile time checking instead of an interpreter failure because of a misspelled variable name or keyword. You get the speed of a compiled program and the C code can contain real html with no escape characters.
With a good library (no libc by default, that is too risky ...) you can
get access to apache internals, code in C (that is the whole idea,
isn't it ?) and get super fast performance. The library needs a large
collection of string handling functions.
It was called SnapFS. You can find traces of this in a LWN article. I don't know if the projects still exists, go ahead and google .....
Many virus scanners don't scan .swf file by default, so you have update your virus signature file (which is automatic on most scanners) and reconfigure your scanner to scan .swf files (unless you already scan all files on your computer).
This means that if advanced .swf viruses are created, they could become a real problem
until system admins wakes up and gets a clue (and that takes a loooong time, look at Code Red)
The parent poster, for example, is trying so hard to impress with his knowledge of the history of /var (available in pretty much any *nix book),
yet fails miserably when it comes to understanding that there is no gun to
his head forcing home to keep html in /var/www. I agree, I think /var/www
is an odd place for html data, but there's always the option of changing
your http root directory, moving it somewhere else and symlinking back
to /var/www, or a few other options.
I would agree with you, if it only was /var/www, but how about the complete
postfix chroot environment in /var/spool/postfix
(eg. /var/spool/postfix/etc/passwd ) ? What about the printer configuration
files in /var/spool/lpd/{printer name}. What about the gdm faces in /var/gdm ?
Heck, how about the compete RPM database in /var/lib/rpm ? This is all
pollution of the /var hierarchy.
In a follow up omega9 writes:Anyway the point of this post is just to mention that all distros that I'm aware of that use the /var/www directory for html data do not actually store
it there. /var/www/html is a symlink to /usr/local/apache/htdocs by default.
You are lucky, the only distro that I know well (RedHat) stores the html files in /var/www since
RedHat 7.1. /var/www/html is a real directory. Which distros are you aware of ?
The /var directory used to be for files that are difficult to
backup to tape, because they varies too much (*see* that's the reason
for its name). A backup of /var used to be outdated after a few hours.
The print spool, the incoming and outgoing mail spool, pid and lock files and the man file cache are all files that changes rapidly, and in general does not need to be backed up every day. You need a backup of its directory structure in case of a disk crash, but doing a complete backup every night used to be a waste of time.
That is history. Now people wants to mount /usr read only, so they are slowly moving all
files that must stay on a RW file system from /usr to /var (eg. /var/www
for your web site). This is stupid, because you need to do a
backup of some directories in /var but not all. The grand idea of /var
is lost.
Please stop this trend before it is too late.
http://www.microsoft.com/presspass/exec/valentine/ default.asp
My nomination for is Wietse Venema, the author of the postfix mail server.
Why:
Have a look at the source code, it is a textbook example of how a program should be written. It is just amazing how well the code is commented (all 100.000 lines of it), and Wietse is doing a fine job of maintaining the code. The program is well behaved (also in severe error conditions like out of memory/disk space, high cpu load, network failures, etc), and have an excellent reputation for being "virtually bug free" ...
Postfix is simply the finest piece of software I have ever compiled and used, and I hope that the award goes a person because of his exceptionally high software standards: Wietse Venema.
The glibc limits the file size to 64 bit (9 million terabytes), so unless the POSIX LFS api changes, that is the current maximum file size regardless of the file system (on x86 that is).
A 9 million terabyte file size limit isn't a large problem for me ....
Many A/D and D/A converters use sigma-delta converters (Look for words like: "one bit converter" or "bit stream", they are variants of this technology). Most sound cards use these sigma-delta converters, so do many A/D and D/A cards for PC, especially those with high dynamic range (many bits ...). These converters have excellent linearity,
low distortion, and are inexpensive, but they have a significant
time delay, so you might have more than 1 ms delay in the A/D
converter alone. No real time OS can work around that.
Be sure that you select A/D and D/A converters with "sub ms" time delay.
geirt wrote:
>The kernel is 2.4.7 + a lot of patches. Since RedHat 7.1 is at kernel 2.4.9-6 already, I believe
>that we will see an updated kernel soon.
Well, the new kernel is already out (as well as a new glibc):
-rw-rw-r-- 1 19837 235 5193088 oct 22 01:17 glibc-2.2.4-19.i386.rpm
-rw-rw-r-- 1 19837 235 8964940 oct 22 01:19 glibc-common-2.2.4-19.i386.rpm
-rw-rw-r-- 1 19837 235 10203453 oct 22 01:19 glibc-devel-2.2.4-19.i386.rpm
-rw-rw-r-- 1 19837 235 8903754 oct 22 01:19 glibc-profile-2.2.4-19.i386.rpm
-rw-rw-r-- 1 2220 235 10099400 oct 22 10:33 kernel-2.4.9-7.i386.rpm
-rw-rw-r-- 1 2220 235 4092573 oct 22 10:30 kernel-BOOT-2.4.9-7.i386.rpm
-rw-rw-r-- 1 2220 235 1658513 oct 22 10:32 kernel-doc-2.4.9-7.i386.rpm
-rw-rw-r-- 1 2220 235 1147039 oct 22 10:34 kernel-headers-2.4.9-7.i386.rpm
-rw-rw-r-- 1 2220 235 24577441 oct 22 10:32 kernel-source-2.4.9-7.i386.rpm
-rw-rw-r-- 1 19837 235 520852 oct 22 01:15 mew-1.94.2-12.i386.rpm
-rw-rw-r-- 1 19837 235 30311 oct 22 01:20 nscd-2.2.4-19.i386.rpm
-rw-rw-r-- 1 19837 235 172116 oct 22 01:16 openssh-2.9p2-9.i386.rpm
-rw-rw-r-- 1 19837 235 37105 oct 22 01:16 openssh-askpass-2.9p2-9.i386.rpm
-rw-rw-r-- 1 19837 235 19000 oct 22 01:17 openssh-askpass-gnome-2.9p2-9.i386.rpm
-rw-rw-r-- 1 19837 235 223690 oct 22 01:16 openssh-clients-2.9p2-9.i386.rpm
-rw-rw-r-- 1 19837 235 160517 oct 22 01:16 openssh-server-2.9p2-9.i386.rpm
-rw-rw-r-- 1 19837 235 983005 oct 22 01:16 squid-2.4.STABLE1-6.i386.rpm
-rw-rw-r-- 1 19837 235 938913 oct 22 01:15 util-linux-2.11f-12.i386.rpm
I have been playing with the 7.2 betas (roswell) since it came out, and with the 7.2 release for about a week now.
I am very pleased with Redhat 7.2, it has given me very few problems, and it was the first Linux distribution that installed into my laptop without any tweaks.
The main enhancements (as visible by the user):
Grub instead of lilo (but you can still use lilo if you want to ..).
Grub is a great boot loader, similar to the "boot monitor" of real
Unix hardware. Grub understands the file system, so you do not need
to reinstall Grub every time you update your kernel (like you have to
with lilo). Once you are in the grub boot promt, you can boot any OS on
your system (eg. from a floppy)
Mozilla and Nautilus: (I am a gnome user)
Mozilla 0.9.2.1 is a rather old release, but it was the release chosen by Netscape for NS6.1 so it is quite good. Nautilus is 1.0.4 + a lot of patches from RH (Alan Cox ?) to speed things up. Natilus is still somewhat slow, but I don't use file managers so much, so I don't care. I think that you should have at least 128 MB ram to run it, is was slow on one of my test machines with 64MB ram and a sub optimal disk system. Seeing the speed and stability improvements of Mozilla in the last 6 months, I am quite confident that Nutilus will be a great file manager (++) in a short time frame. It is a very good "eye candy", and impresses every Windows user seeing it. If you for one reason or another, don't like Nautilus, use the good old GNU Midnight Commander instead (yes it is on the CD).
Kernel, gcc, ptyhon, etc
The kernel is 2.4.7 + a lot of patches. Since RedHat 7.1 is at kernel 2.4.9-6 already, I believe that we will see an updated kernel soon. The main compiler is RedHats own 2.96 + modifications, and python is at 1.5.2-35. You will find gcc 3.01 and python 2.1.1 on the CD which can be installed separately. RedHat 8.0 will probably use these as default.
Postfix, Apache:
Redhat has dropped support for Postfix (a sendmail replacement), which used to be on the Powertools CD. I really don't know why, but I hope that the next RedHat release will fix this major bug. Apache is the rock solid 1.3.20.
Executive Summary:
RH7.2 is a polished good distribution. Since it is a .2 version, RedHat
is going to support it for a looong time, and it will become the first
choice for many system administrators for serious linux servers (that is,
until 8.2 is released).
I think it is a bad idea to try to make Linux run Windows executables. IBM made this mistake with OS/2. OS/2 ran Windows applications almost as good (some say even better than) on native Windows. The result was that programmers wrote applications for Windows only, they ran after all on OS/2 also. Little native OS/2 software was written.
Microsoft made Windows a moving target (and it still is ...), making it impossible for IBM to
have the Windows emulation work in OS/2 for every respin of Windows. The
rest is history, please don't let this happen once again with Linux.
I believe RedHat have the same problems, since RedHat 7.2 has been ready (even on the mirrors) for some time now, but they will not distibute it (ie. add the everyone-read bit to the file permissions) until they have the CDs ready.
The RedHat 7.2 relase is available trough rsync ....
$ rsync -av csociety-ftp.ecn.purdue.edu::pub/redhat/redhat/lin ux/7.2/en/iso
... done
n ux/7.2/en/iso/i386/MD5SUM .
... done
*** Welcome to the Purdue University Computer Society RSYNC Server
*** Purdue University, West Lafayette, IN
http://csociety.ecn.purdue.edu/
This archive is available via FTP, HTTP, and RSYNC at:
ftp://csociety-ftp.ecn.purdue.edu/pub/
http://csociety-ftp.ecn.purdue.edu/pub/
rsync://csociety-ftp.ecn.purdue.edu/pub/
Report problems to ftp@csociety.ecn.purdue.edu
receiving file list
dr-x------ 4096 2001/10/05 01:54:02 iso
dr-x------ 4096 2001/10/04 02:01:50 iso/doc
-rw-r--r-- 50 2001/10/04 02:02:00 iso/doc/MD5SUM
-rw-r--r-- 624476160 2001/10/04 00:35:00 iso/doc/enigma-docs.iso
dr-x------ 4096 2001/10/04 02:03:42 iso/i386
-rw-r--r-- 226 2001/10/04 02:04:22 iso/i386/MD5SUM
-rw-r--r-- 680282112 2001/10/04 00:27:19 iso/i386/enigma-SRPMS-disc1.iso
-rw-r--r-- 542537728 2001/10/04 00:29:25 iso/i386/enigma-SRPMS-disc2.iso
-rw-r--r-- 677961728 2001/10/04 00:22:08 iso/i386/enigma-i386-disc1.iso
-rw-r--r-- 669429760 2001/10/04 00:24:42 iso/i386/enigma-i386-disc2.iso
wrote 94 bytes read 691 bytes 314.00 bytes/sec
total size is 3194687764 speedup is 4069665.94
$ rsync -av csociety-ftp.ecn.purdue.edu::pub/redhat/redhat/li
*** Welcome to the Purdue University Computer Society RSYNC Server
*** Purdue University, West Lafayette, IN
http://csociety.ecn.purdue.edu/
This archive is available via FTP, HTTP, and RSYNC at:
ftp://csociety-ftp.ecn.purdue.edu/pub/
http://csociety-ftp.ecn.purdue.edu/pub/
rsync://csociety-ftp.ecn.purdue.edu/pub/
Report problems to ftp@csociety.ecn.purdue.edu
receiving file list
wrote 106 bytes read 500 bytes 242.40 bytes/sec
total size is 226 speedup is 0.37
$ cat MD5SUM
efab549656a1a85ab8fa39eb873eff0e enigma-SRPMS-disc1.iso
70703897af7703b40e41777a3aa186c3 enigma-SRPMS-disc2.iso
cf7bce0c1cdbfedfae29e60aef202f6f enigma-i386-disc1.iso
fd705b3e5d0e37a828db35d21195a9f6 enigma-i386-disc2.iso
Note that the files are dated 2001/10/04