I've been talking with the author of much of the
procps code, and maintainer of a fork of it called
procps 3.x, and I'll run by you some of our
conversation so you can decide if we should switch to
that procps tree.
----------- recent procps history -------------
In the 3rd party to avoid confusion when people
quote...
First of all, let's be kind to the original maintainer
from
long ago. He dropped the project long ago, for a
second time.
(there was a gradual decline around 1998 to 2000)
Albert Cahalan wrote the "ps" program shipped with all
2.x.x and 3.x.x releases. Work started in 1997. Albert
quietly maintained procps after the original
maintainer
stopped work. ("quietly" to avoid being rude about it)
Debian has been using Albert's code since that time.
In 2001, Rik showed up for the first time. He had lots
of
grand ideas about fixing the project with ESR
philosophy,
but nothing much happened at first. Then in spring
2002,
he starts accepting random patches to do a release
based
on the unmaintained tree in Red Hat's CVS. Now
everything,
even the "PRI" column, uses slow 64-bit math. (no
thought
about what ranges a value could take) Now the top
program
has two columns with the exact same content. (the CPU
number
last used by a process) Now there is a buggy thread
collector
thing.
More seriously, Rik is missing most of the bug fixes
done
in the past 3 years. The debian-unstable users have
been
good about reporting problems on something like 11
archs.
Albert and Craig (the Debian maintainer) then decided:
a. the original maintainer wasn't coming back
b. non-Debian users needed the years of bug fixes
c. Jim's new "top" was better and would be maintained
d. users would be confused by conflicting 2.x.x
releases
Thus the procps-3.0.0 code was placed on SourceForge
and
announced widely. The procps-3.1.1 code is quite good.
http://procps.sf.net/
Note: bugs should be reported via
[EMAIL PROTECTED]
or via the Debian bug tracking system.
------------------- end history note
----------------------
(lines with > are me, rest is Albert Cahalan)
> Do you all keep up with the 2.5 kernel?
Yes. Both versions fully run on 2.5.xx kernels.
Neither version is 100% ahead of the other. Currently:
My vmstat uses 2.5.xx features for speed.
Rik's might have a faster WCHAN on 2.5.xx kernels.
My vmstat reports new 2.5.xx stats.
Rik's top has an extra header line of memory info.
My library has fast & reliable HZ calculation on
2.4.xx and 2.5.xx.
That's pretty even. Maybe I'm ahead by a teeny bit,
but that depends on what is important to you. I'm not
sure it's good to give up a line of top's process
info,
and I'll have to benchmark the WCHAN stuff to see if
it is an improvement worth the memory cost.
Speaking of which, my ps is 2x faster than Rik's one.
(well, they're both mine of course but Rik has old
code)
Most of the other tools have improved greatly as well.
> That's the
> main point to Rik's tree I think. If you do,
> shouldn't other Linux distributors start using your
> procps?
I certainly think so! :-)
There are a few Linux distributors already using it.
Several of the source-package ones are using my
procps.
Slackware switches back and forth; I believe they've
decided to package both.
Of course there's Debian, which started using my code
long before the 3.0.0 release. Debian-woody has my
code.
That's also known as debian-stable and debian-3.0 now,
assuming I didn't get the codewords confused.
I can put you on the announcement mailing list if you
like.
I use [EMAIL PROTECTED] and freshmeat.net for this.
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
