On Mon, 31 Oct 2005, Hari Bhaskaran wrote:
Hi,
I am trying to setup a RAID-1 setup for the boot/root partition. I got
the setup working, except what I see with some of my tests leave me
less convinced that it is actually working. My system is debian 3.1
and I am not using the raid-setup
On Mon, 31 Oct 2005, Hari Bhaskaran wrote:
So that DEVICE paritions line was really supposed to be there? Hehe... I
thought it was just a
help message and replaced it with DEVICE /dev/hda1 /dev/hdc1 :)
you can use DEVICE /dev/hda1 /dev/hdc1 ... but then mdadm scans will
only consider those
On Tue, 25 Oct 2005, Piotr Nowacki wrote:
Hi,
I have been using rsync to copy data between remote sites,
so I have most of my data already copied.
Is there any way to create rdiff-backup metadata of existing bacup
done wiyh rsync, and then to continue using rdiff-backup to make
On Tue, 25 Oct 2005, Ben Escoto wrote:
It's a good idea, and one that someone else has suggested before. The
checksums would be stored in the mirror-metadata file. I don't even
think it would be hard to implement. And there could be a --verify
switch to go through the repository and make
On Mon, 24 Oct 2005, Jeff Breidenbach wrote:
First of all, if the data is mostly static, rsync might work faster.
Any operation that stats the individual files - even to just look at
timestamps - takes about two weeks. Therefore it is hard for me to see
rsync as a viable solution, even
On Mon, 24 Oct 2005, Jeff Breidenbach wrote:
Dean, the comment about write-mostly is confusing to me. Let's say
I somehow marked one of the component drives write-mostly to quiet it
down. How do I get at it? Linux will not let me mount the component
partition if md0 is also mounted. Do you
Package: spell
Version: 1.0-15
try this:
% echo a b c a
% spell a
it hangs forever...
i dunno, but the source code looks like it has some confusion with pin vs.
pout... the patch below seems to fix it.
-dean
--- spell-1.0/spell.c.dg2005-10-22 11:26:24.0 -0700
+++
Package: clamav-freshclam
Version: 0.87-1
a couple times a month i find a freshclam which has been stuck on a read
from fd 4 for a few days... fd 4 is its network socket, and it seems to be
stuck in the middle of a tcp session, probably the other end has
disappeared. there really should be an
On Fri, 14 Oct 2005, Carsten Lorenz wrote:
Since we want to backup one tera-byte of data this would last more than a
week.
i've never looked closely at why the first backup is so slow -- and i've
heard the report from lots of folks... i tend to use rsync for the initial
backup, and then use
On Thu, 13 Oct 2005, Golden Butler wrote:
./test-bkp: line 2: 20700 Segmentation fault rdiff-backup -v7
--print-statistics /home/golden/testy
you know, a segfault is very unlikely to be an rdiff-backup problem.
i'd be more tempted to blame the C compiler (which could be miscompiling
-backup, python, and gcc compiler, so
that I can reinstall again. Reinstalling the O.S. is not an option.
dean gaudet wrote:
On Thu, 13 Oct 2005, Golden Butler wrote:
./test-bkp: line 2: 20700 Segmentation fault rdiff-backup -v7
--print-statistics /home/golden/testy
Package: libpam-modules
Version: 0.79-2
if /etc/environment does NOT exist then logins/etc fail with a pam_setcred
critical error. (this is NOT a repeat of the other bugs related to
/etc/environment just fixed in 0.79-2 :)
-dean
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
Package: linux-image-2.6.12-1-686-smp
Version: 2.6.12-7
usb audio worked in -6... but as of -7 i'm getting this in dmesg when the
module is inserted:
snd_usb_audio: Unknown symbol __compound_literal.170
snd_usb_audio: Unknown symbol __compound_literal.89
snd_usb_audio: Unknown symbol
Package: linux-image-2.6.12-1-686-smp
Version: 2.6.12-7
usb audio worked in -6... but as of -7 i'm getting this in dmesg when the
module is inserted:
snd_usb_audio: Unknown symbol __compound_literal.170
snd_usb_audio: Unknown symbol __compound_literal.89
snd_usb_audio: Unknown symbol
Package: clamav-freshclam
Version: 0.87-1
please add a MAILTO=root at the top of /etc/cron.d/clamav-freshclam so
that any output from freshclam failures goes to root rather than to the
clamav user...
thanks
-dean
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
ah, wait i see you add a clamav: root to /etc/aliases... works fine
except for those of us using MTAs which don't support /etc/aliases. i'm
satisfied enough making a local mod to my own crontab then... go ahead and
close this out, sorry.
-dean
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Package: at
Version: 3.1.9
when launching atd it's preferable to clean the environment -- in
particular things like SSH* env vars or even LOGNAME can leak into the
environment of the daemon. i've seen this cause problems such as atd
sending mail as 'dean' rather than 'root' when i restart it.
On Thu, 8 Sep 2005, Moritz Naumann wrote:
Warning: su: Permission denied
not sure where that's coming from, rdiff-backup won't invoke su on its
own.
I also tried removing /home/backupschizo/schizo/ and then retrying
rdiff-backup with the usage given by backupninja. However, this gave
On Mon, 5 Sep 2005, Kingsley G. Morse Jr. wrote:
Hi,
What may have caused the following stack traces,
and how might they be fixed?
They seemed to happen at about the same time as
upgrading several Debian linux packages.
the upgrade was happening while rdiff-backup was running? did you
On Mon, 5 Sep 2005, Adrian Bunk wrote:
> How do you put pressure on hardware manufacturers for getting them to
> release the specs?
>
> If they are able to write "supported by Linux" on their products anyway
> because there's a driver that runs under NdisWrapper?
that's specious... they can
On Mon, 5 Sep 2005, Adrian Bunk wrote:
How do you put pressure on hardware manufacturers for getting them to
release the specs?
If they are able to write supported by Linux on their products anyway
because there's a driver that runs under NdisWrapper?
that's specious... they can put
Package: rssh
Version: 2.2.3-2
rssh logs about everything it's read from the config file... i'm getting
6+ lines every single rssh session. this is maybe useful when you're
debugging, but it's certainly too much information to log at LOG_INFO
setting every single session... this patch lowers
On Fri, 19 Aug 2005, Steve Clement wrote:
Also calling 1.0 stable is a bit poor as it seems we haven't tested it
enough :(
i dunno... i've been using 0.13.x since forever, and top of CVS since i
gained commit privs... and it's always been stable enough for me.
what you're seeing now is a
On Fri, 19 Aug 2005, Noah wrote:
Probably this error was caused because the first rdiff-backup session
into a new directory failed. If this is the case it is safe to delete
the rdiff_backup_data directory because there is no important
information in it.
yeah do what the error message
On Thu, 18 Aug 2005, Davy Durham wrote:
Is this serious? I get a few like this while backing up..
UpdateError var/log/secure Updated mirror temp file
./var/log/rdiff-backup.tmp.1685 does not match source
unfortunately there's always a race condition when backing up from a live
hi...
i've run into this a bunch of times, but decided to look at it more
closely today. i use IDE disks in md raid1 and/or raid5, and when one
disk is dying or dead it tends to make the entire system unusable.
i don't really fault md here, because i'm pretty sure there are some
fundamental
On Thu, 18 Aug 2005, Folkert van Heusden wrote:
> Doesn't that one also use copying? I've also heard that using mmap is
> expensive due to pagefaulting. I've found, for example, that copying a
> 1.3GB file using read/write instead of mmap & memcpy is seconds faster.
why would you memcpy if
On Thu, 18 Aug 2005, Folkert van Heusden wrote:
Doesn't that one also use copying? I've also heard that using mmap is
expensive due to pagefaulting. I've found, for example, that copying a
1.3GB file using read/write instead of mmap memcpy is seconds faster.
why would you memcpy if you're
hi...
i've run into this a bunch of times, but decided to look at it more
closely today. i use IDE disks in md raid1 and/or raid5, and when one
disk is dying or dead it tends to make the entire system unusable.
i don't really fault md here, because i'm pretty sure there are some
fundamental
Package: fail2ban
Version: 0.5.2-1
if you ask fail2ban to use SYSLOG for logging it'll try to log to
localhost:514 ... which isn't typically enabled on a debian system.
the below patch fixes this to use /dev/log, and allows the user to
optionally change the syslog-facility in the config file
On Tue, 16 Aug 2005, Charles Duffy wrote:
http://arctic.org/~dean/rdiff-backup/unattended.html
Not workable in my situation:
- The instructions from the page in question require work to be done on
a per-server basis. I need to support tens to hundreds (and possibly
someday thousands) of
On Tue, 16 Aug 2005, Colonel Hell wrote:
I just went thru a couple of papers describing RAID6.
I dunno how relevant this discussion grp is for the qry ...but here I go :)
...
I couldnt figure out why is P+Q configuration better over P+q' where
q' == P. What I mean is instead of calculating
On Tue, 16 Aug 2005, Troels Arvin wrote:
Hello,
After upgrading to v. 1.0, I consistently get the following warning when
backing up:
Warning: ownership cannot be changed on filesystem at
/backup-data/backup3/hosts/HOSTNAME/_home/rdiff-backup-data
I'm backing up in to a directory owned
On Mon, 15 Aug 2005, john stultz wrote:
Something that I think would be helpful in the FAQ would be howto for moving
from using rsync to rdiff-backup, pointing out some of the subtle differences
between the arguments.
Currently I mirror nightly two partitions to a firewire disk using:
this is a cool idea... a couple comments:
- it would be cool if this were available to other libpcap users...
perhaps as a new verb ssh_client so we could use not ssh_client
and/or (blahblah) and not ssh_client. more typing than just -H
though.
- the values returned by getenv are actually
On Wed, 10 Aug 2005, steve roussey wrote:
> socket to shut down. Apache has a workaround called lingering_close()
> that tries to address broken SO_LINGER implementations, but it also blocks."
apache 1.x is single threaded / forked, so yeah it blocks. the
implementation is there because very
On Wed, 10 Aug 2005, steve roussey wrote:
socket to shut down. Apache has a workaround called lingering_close()
that tries to address broken SO_LINGER implementations, but it also blocks.
apache 1.x is single threaded / forked, so yeah it blocks. the
implementation is there because very few
On Sun, 7 Aug 2005, Trevor Cordes wrote:
Any array that is a superset of other arrays (a multilevel array) must
set to non-autodetect. Use fdisk to change the parition type to 83
(standard linux), NOT fd (linux raid autodetect).
you know i'd be worried setting it to 0x83 will cause troubles
On Mon, 25 Jul 2005, Marc Ballarin wrote:
> Hmm, just did. I even tried the rather minimalistic configuration below.
> Still no C3. (And what seems even stranger: no C1.)
there's no point to going into C1 if the C2 entry/exit latencies are
acceptable. (winxp generally never uses C1 if C2 is
On Mon, 25 Jul 2005, Marc Ballarin wrote:
Hmm, just did. I even tried the rather minimalistic configuration below.
Still no C3. (And what seems even stranger: no C1.)
there's no point to going into C1 if the C2 entry/exit latencies are
acceptable. (winxp generally never uses C1 if C2 is
On Sun, 17 Jul 2005, Michael Berg wrote:
The latest libpam-umask (0.02) encounters a SIGSEGV (Segmentation fault)
this is because of some unfortunate code that i don't even think should be
in the module... it's a result of the per-user umask support. it
segfaults for any user which does
here's my patch.
sorry it's large because i think that per-user umask should be optional,
so i've done most of the work to make that happen... now you have to
specify user as an argument to pam_umask.so... as it happens it has to
be the first argument, because arguments are processed
On Sun, 17 Jul 2005, Michael Berg wrote:
The latest libpam-umask (0.02) encounters a SIGSEGV (Segmentation fault)
this is because of some unfortunate code that i don't even think should be
in the module... it's a result of the per-user umask support. it
segfaults for any user which does
here's my patch.
sorry it's large because i think that per-user umask should be optional,
so i've done most of the work to make that happen... now you have to
specify user as an argument to pam_umask.so... as it happens it has to
be the first argument, because arguments are processed
On Mon, 18 Jul 2005, [EMAIL PROTECTED] wrote:
Unless I do the following I get the Meaningless use of exression
from the compiler:
diff -ru openssl-0.9.8/crypto/bn/bn_recp.c
openssl-0.9.8-QNX/crypto/bn/bn_recp.c
--- openssl-0.9.8/crypto/bn/bn_recp.c 2005-04-26 22:53:13.0 +0400
On Mon, 18 Jul 2005, Richard Levitte - VMS Whacker wrote:
Incorrect. The compiler will see 'if(dv) ; if(rem) ; return(ret)'.
That's perfectly OK.
oops :)
-dean
__
OpenSSL Project
On Wed, 13 Jul 2005, Chris Wedgwood wrote:
> On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote:
>
> > windows xp base rate is 100Hz... but multimedia apps can ask for
> > almost any rate they want (depends on the hw capabilities). i
> > recall seeing rates >
On Wed, 13 Jul 2005, Chris Wedgwood wrote:
> On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote:
> > "My expectation is if we want to beat the competition, we'll want
> > the ability to go *under* 100Hz."
>
> What does Windows do here?
windows xp base rate is 100Hz... but multimedia
On Wed, 13 Jul 2005, Chris Wedgwood wrote:
On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote:
My expectation is if we want to beat the competition, we'll want
the ability to go *under* 100Hz.
What does Windows do here?
windows xp base rate is 100Hz... but multimedia apps can
On Wed, 13 Jul 2005, Chris Wedgwood wrote:
On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote:
windows xp base rate is 100Hz... but multimedia apps can ask for
almost any rate they want (depends on the hw capabilities). i
recall seeing rates 1200Hz when you launch some
Package: login
Version: 1:4.0.3-36
this bug has been introduced since 1:4.0.3-35 ... perhaps related to the
fix for #314727.
with zsh as your shell, this sequence is busted:
dotlark:~% su -m
Password:
[EMAIL PROTECTED]:~# suspend
zsh: suspended su -m
i'm pretty sure this is because bash and tcsh create their own process
group at startup, and zsh doesn't... so zsh shares the same process group
as the su process.
suppose we have this pstree fragment:
zsh(4782,dean)---su(4788,root)---zsh(4789)
both pids 4788 and 4789 have pgrp 4788.
ok this is gross... but this seems to fix the problems. at first i tried
just adding the setpgrp... but with that the su'd zsh doesn't ever seem to
wake up.
so i threw in the TIOCSPGRP calls to pass the tty pgrp to the su'd zsh...
and that fixes it.
it looks like bash calls TIOCSPGRP
On Mon, 11 Jul 2005, Alexander Gattin wrote:
As I already said, I'd just prefer to block/ignore several signals
like TSTP. Most probably I'll do the same as in upstream --
block everything (except TERM and ALRM) until exit...
yeah after i stopped hacking and went to bed this popped into my
On Wed, 6 Jul 2005, Guy Harris wrote:
So presumably -X should suppress the print_default() calls in
link-layer printers (i.e., the
if (!xflag !qflag)
print_default(...);
calls). I'll look at doing that, unless somebody objects.
Should -A do so as well?
hmm... -Xq or -Aq
On Fri, 8 Jul 2005, Guy Harris wrote:
On Jul 5, 2005, at 9:46 PM, dean gaudet wrote:
i also think the 3.9 behaviour needs some slight modifications, so
i'vemade two changes on top of your patch Guy.
Well, on top of one of the versions of my patch; it's not the version
that got
On Tue, 5 Jul 2005, Romain Francoise wrote:
dean gaudet [EMAIL PROTECTED] writes:
this problem has been submitted upstream (tracking info at
http://sourceforge.net/tracker/index.php?func=detailaid=1232347group_id=53066atid=469575)
You might want to ask on -workers, I'm not sure anyone
the -A flag prints hex rather than ascii-only... i think the following
patch is necessary.
-dean
p.s. i submitted a bug/patch but it's been suggested that nobody monitors
the sourceforge bug/patch thingers :)
--- tcpdump-3.9.1/tcpdump.c 2005-07-05 14:09:05.0 -0700
+++
| API addition: typedef direction_t is new
| is now defined at /usr/include/pcap.h:123:
| typedef enum
| {
| D_INOUT = 0,
| D_IN = 1,
| D_OUT = 2,
| } direction_t;
shouldn't that be pcap_direction_t? otherwise i can imagine some
namespace collision occuring...
-dean
-
On Tue, 5 Jul 2005, Michael Richardson wrote:
-BEGIN PGP SIGNED MESSAGE-
dean == dean gaudet [EMAIL PROTECTED] writes:
dean the -A flag prints hex rather than ascii-only... i think the
dean following patch is necessary.
dean case 'A': - ++xflag; ++Xflag
On Tue, 5 Jul 2005, Guy Harris wrote:
Guy Harris wrote:
Here's a patch that has separate routines for -A, -x, and -X, and
that separately tests Aflag, xflag, and Xflag, and gives them all
appropriate names.
Ok, *here's* the patch.
It also changes -A not to print the \n\t stuff before the
On Mon, 4 Jul 2005, Alejandro Bonilla wrote:
>Do you think that the kernel will STOP, HOLD and park the head in less than
> a second? OR on the time we need?
this is why the windows driver uses heuristics to decide when the laptop
is possibly unstable and *may* fall soon... because it takes
On Mon, 4 Jul 2005, Alejandro Bonilla wrote:
Do you think that the kernel will STOP, HOLD and park the head in less than
a second? OR on the time we need?
this is why the windows driver uses heuristics to decide when the laptop
is possibly unstable and *may* fall soon... because it takes
Package: tcpdump
Version: 3.9.0.cvs.20050614-1
this problem has been submitted upstream (tracking info at
http://sourceforge.net/tracker/index.php?func=detailaid=1232347group_id=53066atid=469575)
the -A flag no longer prints the ascii minus the hex like it did in
3.8.x... while i'm a bit
On Fri, 1 Jul 2005, Hunter Matthews wrote:
...
File /usr/lib64/python2.2/site-packages/rdiff_backup/librsync.py,
line 95, in _add_to_inbuf
new_in = self.infile.read(blocksize)
File /usr/lib64/python2.2/gzip.py, line 163, in read
self._read(readsize)
File
the following patch fixes the chroot problem. it retains cap_sys_chroot
for a few lines longer in the code -- note there is a subsequent call
already in the code which removes all capabilities except cap_sys_time.
-dean
--- ntp-4.2.0a+stable/ntpd/ntpd.c.orig 2005-06-29 14:01:31.0
Package: ntp
Version: 1:4.2.0a+stable-8
gcc generates several type punning warnings while compiling ntp and it's
probably best to disable strict-aliasing to avoid the possibility of
incorrect optimisations. i didn't study the source to see if the type
punning could be avoided... that should
Package: ntp-server
Version: 1:4.2.0a+stable-8
i'd prefer to not have local modifications to /etc/init.d/ntp-server ... i
add -L -i /var/chroot/ntpd on my boxes. the patch below adds support
for /etc/default/ntp-server which allows the OPTIONS and RUNASUSER to be
modified.
i also made the
On Thu, 28 Apr 2005, Konrad Podloucky wrote:
Apparently SELinux uses extended attributes and rdiff-backup tries to
clear all attributes from temp files it creates during transfer (at least
that's what I concluded). However the security.selinux attribute can not
be removed (at least not by
On Mon, 27 Jun 2005, Hunter Matthews wrote:
Were there any ideas on this? Can anyone else restore to Tiger?
your problem looks the same as bug #12949 ...
https://savannah.nongnu.org/bugs/index.php?func=detailitemitem_id=12949
i see a patch for that bug
Package: openssh-server
Version: 1:4.1p1-4
openssh 4.x now tries to append to /var/log/btmp (on bad passwords for
example), but it's excessively anal about the permissions on that file. it
doesn't permit group or other to have any of read/write/execute.
the default debian setup is this:
On Mon, 2 May 2005, Clint Silvester wrote:
This is with 0.9.7, but I don't see it using that in any of the gcc
commands when it's compiling. The configure script says
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large
Package: libc6
Version: 2.3.2.ds1-20
i've started seeing entries like this in my syslog:
Apr 21 09:48:06 twinlark curl: gethostby*.getanswer: asked for
ethereal.net.nyud.net IN A, got type 39
type 39 is a DNAME record http://www.faqs.org/rfcs/rfc2672.html, and
DNAMEs are apparently in use by
Package: libc6
Version: 2.3.2.ds1-20
i've started seeing entries like this in my syslog:
Apr 21 09:48:06 twinlark curl: gethostby*.getanswer: asked for
ethereal.net.nyud.net IN A, got type 39
type 39 is a DNAME record http://www.faqs.org/rfcs/rfc2672.html, and
DNAMEs are apparently in use by
i got the following bug from 2.4.30 while trying to hot add a device
tonight...
i was trying to replace a disk in a 3-way raid1 -- the existing disks are
sda, sdb, and i was replacing sdc. each of these disks has 3 partitions,
each with a raid1.
due to an improper shutdown the raids were
On Tue, 29 Mar 2005, Jay Lan wrote:
> The fork_connector is not designed to solve accounting data collection
> problem.
>
> The accounting data collection must be done via a hook from do_exit().
by the time do_exit() occurs the parent may have disappeared... you do
need to record something at
On Tue, 29 Mar 2005, Jay Lan wrote:
The fork_connector is not designed to solve accounting data collection
problem.
The accounting data collection must be done via a hook from do_exit().
by the time do_exit() occurs the parent may have disappeared... you do
need to record something at
On Fri, 25 Mar 2005, Guillaume Thouvenin wrote:
...
> The lmbench shows that the overhead (the construction and the sending
> of the message) in the fork() routine is around 7%.
...
> + /*
> + * size of data is the number of characters
> + * printed plus
On Fri, 25 Mar 2005, Guillaume Thouvenin wrote:
...
The lmbench shows that the overhead (the construction and the sending
of the message) in the fork() routine is around 7%.
...
+ /*
+ * size of data is the number of characters
+ * printed plus one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sat, 5 Mar 2005 19:07:33 -0800
Source: libapache-mod-iptos
Binary: libapache-mod-iptos
Architecture: source i386
Version: 1.1-1
Distribution: unstable
Urgency: low
Maintainer: dean gaudet [EMAIL PROTECTED]
Changed-By: dean gaudet
Package: elinks
Version: 0.10.2-2
i have a cronjob which runs links -dump http://foo/; ... it worked fine
until this week when i upgraded and started getting this:
ELinks: Permission denied
i tried strace and it said this:
open(/dev/stdin, O_RDONLY|O_NOCTTY) = -1 EACCES (Permission denied)
i
Package: diff
Version: 2.8.1-10
as of 2.8.1-10 diff has reverted to braindamaged posix behaviour:
% diff -u0 a1 a2
diff: `-0' option is obsolete; use `-U 0'
diff: Try `diff --help' for more information.
zsh: exit 2 diff -u0 a1 a2
if i revert to 2.8.1-9 it works fine.
i didn't see anything
one further change to consider -- run /etc/cron.daily/ntp-server as user
ntp instead of root. maybe stick a line like this in it:
[ `/usr/bin/id -un` = ntp ] || exec /bin/su -s /bin/sh ntp $0
(or use /etc/cron.d/ntp-server which can specify a username)
-dean
--
To UNSUBSCRIBE,
On Tue, 28 Dec 2004, Andy Polyakov wrote:
aes-586.pl module is committed to CVS now [see
http://cvs.openssl.org/rlog?f=openssl/crypto/aes/asm/aes-586.pl]. Take
Special note about instruction choice in commentary section for
consideration even for AMD64. Merry Christmas to everybody:-)
rainy day.
-dean
SUBMISSION TYPE: TSU
SUBMITTED BY: dean gaudet
SUBMITTED FOR: dean gaudet
POINT OF CONTACT: [EMAIL PROTECTED]
PHONE and/or FAX: (408) 919-3086
MANUFACTURER: openssl
PRODUCT NAME/MODEL #: 0.9.8-dev
ECCN: 5D002
Index: crypto/aes/asm/aes-586.pl
On Tue, 21 Dec 2004, Andy Polyakov wrote:
SHA-1: Dean already worked on this, using SSE2.
So far Dean has been working on 32-bit codes. The reason he refers to Opteron
is rather because it's another SSE2-capable CPU to compare with, than 64-bit
one. Right?
right -- i was just trying all
On Mon, 20 Dec 2004, Marc Bevand wrote:
SHA-1: Dean already worked on this, using SSE2.
it looks like the openssl cvs HEAD generally beats my sha1 code for 32-bit
x86 platforms in most cases now, and generally ties my sha256 code when
compiled with gcc... nice work Andy.
here's some data i
On Fri, 19 Nov 2004, Alexis Sukrieh wrote:
I'm maintaining an unofficial package, apache-lingerd [1].
It's a new flavour of the official Debian apache source tree.
it's been more than 4 years since i last had to remember all the details
surrounding linger... but the main reason apache does
On Wed, 27 Oct 2004, Daniel Quinlan wrote:
Dean thinks the bugzilla license is onerous:
i have a bug to report, but i refuse to agree to the ASLv2 just to report
a bug. i suggest you guys stop being so anal.
I think that's not unreasonable. I modified bugzilla to say:
#
when --max-conn-per-child=1 spamd children should drop root completely as
early as possible. actually i'd also suggest that when $setuid_to_user
you default $clients_per_child to 1 rather than 200 ... the extra paranoia
is worth more than the possibility of perf gain for most folks.
sorry --
Package: rdiff-backup
Version: 0.13.4-3
rdiff-backup --server --restrict-read-only /tmp permits backups of
/tmp/foo -- this is expected according to the docs.
rdiff-backup --server --restrict-read-only / does not permit backups of
any subdirectory -- this looks like an oversight, the docs
Package: apt
Version: 0.5.27
auto-clean should be an alias for autoclean... autoclean is the only
option which is two words not separated by a -. (i.e. contrast build-dep,
dist-upgrade, ...)
or perhaps someday after i mistype this a bazillion more times i'll learn
to stop trying auto-clean
On Sun, 15 Aug 2004, Miquel van Smoorenburg wrote:
I'd say that's a bug in xdm, it should be at S95 or so.
there are other S99 scripts as well... on my systems i find:
S99fetchmail
S99rmnologin
S99stop-bootlogd
S99xdm
it's really only by luck that S99stop-bootlogd is almost last. that's why
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 29 Jan 2004 20:28:49 +0100
Source: libapache-mod-iptos
Binary: libapache-mod-iptos
Architecture: source i386
Version: 1.0-3
Distribution: unstable
Urgency: low
Maintainer: dean gaudet [EMAIL PROTECTED]
Changed-By: dean gaudet
On Fri, 5 Dec 2003, Marco Gerards wrote:
dean gaudet [EMAIL PROTECTED] writes:
at http://arctic.org/~dean/crypto/sha1.html you'll find a coreutils
patch which includes a new implementation of SHA1 using SSE2 hardware for
a speedup ranging from 1.2x to 1.9x depending on which SSE2-capable
at http://arctic.org/~dean/crypto/sha1.html you'll find a coreutils
patch which includes a new implementation of SHA1 using SSE2 hardware for
a speedup ranging from 1.2x to 1.9x depending on which SSE2-capable CPU is
used.
there's a complication to compiling this code -- it requires the intel
this conditional for i386 is not required with any recent GCC (probably
anything 3.x)... in fact it's undesirable because the asm forces the use
of a variable rotation, which steals the %ecx register from many more
useful purposes in this code.
the patch below results in an 8% speedup on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sat, 08 Nov 2003 18:03:58 +0100
Source: libapache-mod-iptos
Binary: libapache-mod-iptos
Architecture: source i386
Version: 1.0-2
Distribution: unstable
Urgency: low
Maintainer: dean gaudet [EMAIL PROTECTED]
Changed-By: dean gaudet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 14 Oct 2003 01:27:45 -0700
Source: libapache-mod-iptos
Binary: libapache-mod-iptos
Architecture: source i386
Version: 1.0-1
Distribution: unstable
Urgency: low
Maintainer: dean gaudet [EMAIL PROTECTED]
Changed-By: dean gaudet
On Fri, 20 Jun 2003, Ben Laurie wrote:
dean gaudet wrote:
hi there, i tried sending this ages ago but i guess some spam filters
probably lost it... i see i have to be subscribed to post stuff.
Actually, I've been sitting on it waiting for some free time to take a
look :-)
cool :) sorry
501 - 600 of 1643 matches
Mail list logo
