linux-kernel - Re: util-linux: orphan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Dec 2006 12:27:15 -0500
From:	"Albert Cahalan" <acahalan@...il.com>
To:	"Jan Engelhardt" <jengelh@...ux01.gwdg.de>
Cc:	kzak@...hat.com, hvogel@...e.de, olh@...e.de, hpa@...or.com,
	linux-kernel@...r.kernel.org, arekm@...en.pl,
	util-linux-ng@...r.kernel.org
Subject: Re: util-linux: orphan

On 12/20/06, Jan Engelhardt <jengelh@...ux01.gwdg.de> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/