On 12/20/06, Jan Engelhardt <[email protected]> wrote:
>> I've originally thought about util-linux upstream fork,
>> but as usually an fork is bad step. So.. I'd like to start
>> some discussion before this step.
> ...
>> after few weeks I'm pleased to announce a new "util-linux-ng"
>> project. This project is a fork of the original util-linux (2.13-pre7).
>
> Well, how about giving me a chunk of it? I'd like /bin/kill please.
> I already ship a nicer one in procps anyway, so you can just delete
> the files and call that done. (just today I was working on a Fedora
> system and /bin/kill annoyed me)
How can you ship a "nicer" kill, given that its sole purpose is to accept
kill { -l | -t | {-s SIGNUM | -SIGNAME } somepid [morepids] }
?
I checked compatibility with Solaris, Tru64, probably a few BSDs,
and man pages of many others.
Fedora Core 5 doesn't seem to like this command:
/bin/kill -l 17 19
(which reminds me, I need to add sigqueue support and
maybe tgkill support)
What about merging util-linux and procps?
How? Which way?
As I mentioned before, I was twice disappointed in missing
announcements of util-linux maintainership being up for grabs.
I certainly have a track record for keeping things stable.
Prior to me, procps has a history of being abandoned and
broken. Procps is a fork of the long-dead kmem-ps project.
Procps was then passed to someone who added color and
then disappeared. The prior maintainer picked up the old
code again, no doubt under influence of his employer Red Hat.
I rewrote much of it then, but had trouble getting in all of
my changes. Debian started using my code, which slowly
turned into a fork. Maintainership was passed to somebody
else, without even telling me. That person and his immediate
successor added numerous serious bugs. Inexperience with
the code and the lack of a test suite soon led to that group
being bogged down in problems. One by one, the various
Linux distributions switched over to my version of the code.
So as you may imagine, I'd be rather nervous about letting
procps get into that situation again. Bugs are yucky. Having
multiple committers and no testing is a sure path to ruin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
