kill (was: Re: util-linux: orphan)

kill (was: Re: util-linux: orphan)

[Karel Zak]

On Wed, Dec 20, 2006 at 01:42:13AM -0500, Albert Cahalan wrote:
> Karel Zak writes:
> 
> >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.

 We can think about it. I'm not sure with this kind of changes in the
 next 2.13 release. That release should be more about bug fixes and
 code stabilisation. 
 
 I'd like to do some consolidation in 2.14. I also need explore why
 RHEL/FC uses the kill command from util-linux rather that from
 procps. And Suse and Debian?

 Frankly, things around proc/ need more changes. There is area for huge
 improvements. There is also the psmisc project where community duplicate 
 effort and code. 
 
 My dream is stable and useful libproc (with python and perl binding) 
 and one or two packages based on this library. (Yes we have libproc
 in procps, but this library is completely useless outside procps...).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: kill

[Pádraig Brady]

Karel Zak wrote:
> On Wed, Dec 20, 2006 at 01:42:13AM -0500, Albert Cahalan wrote:
>> Karel Zak writes:
>>
>>> 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.

We definitely need less version of kill:

ubuntu: $ dpkg -S `which kill`
procps: /bin/kill

fedora: $ rpm -qf `which kill`
util-linux-2.12p-9.3

fedora: $ type kill
kill is a shell builtin

$ tar tzf coreutils-6.2.tar.gz | grep kill
coreutils-6.2/src/kill.c
coreutils-6.2/man/kill.1
coreutils-6.2/man/kill.x


>  We can think about it. I'm not sure with this kind of changes in the
>  next 2.13 release. That release should be more about bug fixes and
>  code stabilisation. 

agreed.

>  
>  I'd like to do some consolidation in 2.14. I also need explore why
>  RHEL/FC uses the kill command from util-linux rather that from
>  procps. And Suse and Debian?

On a similar note, there are utils in util-linux[-ng] that are
not specific to linux (like look, cal etc.)
There has been the proposal for a new miscutils project
on the coreutils list: http://lists.gnu.org/archive/html/bug-coreutils/2006-11/msg00086.html
for which I am the proposed maintainer of.
Possibly some of these non specific linux utils could be moved there?

cheers,
Pádraig.

Re: kill

[Karel Zak]

On Wed, Dec 20, 2006 at 10:03:36AM +0000, Pádraig Brady wrote:
> Karel Zak wrote:
> > On Wed, Dec 20, 2006 at 01:42:13AM -0500, Albert Cahalan wrote:
> >> Karel Zak writes:
> >>
> >>> 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.
> 
> We definitely need less version of kill:
> 
> ubuntu: $ dpkg -S `which kill`
> procps: /bin/kill
> 
> fedora: $ rpm -qf `which kill`
> util-linux-2.12p-9.3
> 
> fedora: $ type kill
> kill is a shell builtin

 Yes.  ;-)

> >  I'd like to do some consolidation in 2.14. I also need explore why
> >  RHEL/FC uses the kill command from util-linux rather that from
> >  procps. And Suse and Debian?
> 
> On a similar note, there are utils in util-linux[-ng] that are
> not specific to linux (like look, cal etc.)
> There has been the proposal for a new miscutils project
> on the coreutils list: http://lists.gnu.org/archive/html/bug-coreutils/2006-11/msg00086.html
> for which I am the proposed maintainer of.
> Possibly some of these non specific linux utils could be moved there?

 Well, good topic for release 2.14

 No problem move things from one to an other project if the
 destination project is stable and maintained. I'm not sure with a
 *new* project. 
 
 It's attractive start a new project, but everyday I fight with
 unmaintained or really badly maintained things. People should be less
 egoistic when they think about new projects. I think one huge
 maintained project is better than few small unmaintained projects.

 I'd like to be careful with this thing.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: kill

[Alfred M. Szmidt]

    It's attractive start a new project, but everyday I fight with
    unmaintained or really badly maintained things. People should be
    less egoistic when they think about new projects. I think one huge
    maintained project is better than few small unmaintained projects.

The problem is that coreutils is not suitable for `random stuff that
is not part of the core system'; this is not th point of coreutils,
core system utilities for the GNU system and variants.  If you have a
better idea than starting a new project (and it isn't really even
"real" GNU project to begin with), then I'm sure we all would be
interested in hearing your suggestions.

Re: kill

[Karel Zak]

On Wed, Dec 20, 2006 at 10:45:03PM +0100, Alfred M. Szmidt wrote:
>     It's attractive start a new project, but everyday I fight with
>     unmaintained or really badly maintained things. People should be
>     less egoistic when they think about new projects. I think one huge
>     maintained project is better than few small unmaintained projects.
> 
> The problem is that coreutils is not suitable for `random stuff that
> is not part of the core system'; this is not th point of coreutils,
> core system utilities for the GNU system and variants.  If you have a
> better idea than starting a new project (and it isn't really even
> "real" GNU project to begin with), then I'm sure we all would be
> interested in hearing your suggestions.

 Well, from my Linux egoistic point of view there is nothing what I have
 to change with look or cal. 
 
 Yes, I don't have care about others systems and it seems that the
 others systems don't have care about look or cal. I really don't see
 anywhere any real request for this change. 

 Frankly, this thing is real detail from my point of view.
 
    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: kill

[Evan Hunt]

>  Well, from my Linux egoistic point of view there is nothing what I have
>  to change with look or cal. 
>  
>  Yes, I don't have care about others systems and it seems that the
>  others systems don't have care about look or cal. I really don't see
>  anywhere any real request for this change. 

Well, I'm currently working on an improved version of look, and would
prefer it to be OS-agnostic rather than living in a package that has
"linux" in its name.  So I think moving look out of util-linux(-ng)
and into something more generic would be a good thing to do.

I don't have a personal stake in cal, but I do think, like look, that
it's a widely-useful tool and it seems somewhat odd for it to be grouped
in with tools that are platform-specific.

I'd say the same about several other things in util-linux... col, colcrt,
colrm, column, getopt, hexdump, logger, more, namei, pg, rename, rev,
script, ul, and write all seem quite generic.  (Also ddate, though I'd
categorize that as a game rather than a utility anyway.)

                                        eh

Re: splitting util-linux (was: kill)

[Bryan Henderson]

I have thought for many years that util-linux is obsolete.  When it
was new, it was a quite helpful distribution of components with which
to build a system.  Today, we have a plethora of giant Linux distros,
sourceforge, and freshmeat.  Such things eliminate most of the
original value in having one big tarball.  In fact, the amalgamation
of unrelated tools now causes more pain than convenience, because you
often want some parts of the package but not others (as evidenced in
the 'kill' discussion).  We also seem to have a maintainership
problem, since there are people who are willing to maintain some
pieces, but less energetic about maintaining the entire package or
working through a central bureaucracy.

Forking of util-linux is the ideal time to improve this.  Just don't
fork the whole package; fork the part you're interested in.  The
discussion I've seen so far shows the interest mainly in the
filesystem tools, so maybe we should just have a new linuxfs-util (and
use linuxfs-devel mailing list).  (Even that would be too big a
package for my taste.  The Minix utilities should be in a package of
their own).

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California

Re: splitting util-linux (was: kill)

[Karel Zak]

On Thu, Dec 21, 2006 at 04:34:00PM +0000, Bryan Henderson wrote:
> I have thought for many years that util-linux is obsolete.  When it
> was new, it was a quite helpful distribution of components with which
> to build a system.  Today, we have a plethora of giant Linux distros
> sourceforge, and freshmeat.  Such things eliminate most of the
> original value in having one big tarball.  In fact, the amalgamation

 That's not 100% true. You need upstream and downstream maintainer for
 every package. You need an infrastructure (scm, mailing list, ...)
 for every package. Maybe it seems like something simple (10 clicks at
 sf.net), but my experience is completely different. Maintainig is
 really boring work and after few months nobody wants to do it... 
 
 Number of well maintained packages is not so big. Believe me, people
 who work on Linux distributions fight with unmaintained projects every
 day.

> of unrelated tools now causes more pain than convenience, because you
> often want some parts of the package but not others (as evidenced in
> the 'kill' discussion).  We also seem to have a maintainership

 Well, kill is nice example where is not problem remove it from
 util-linux (... because procps). 

> problem, since there are people who are willing to maintain some
> pieces, but less energetic about maintaining the entire package or
> working through a central bureaucracy.

 I don't see any problem collaborate with more people. The
 util-linux-ng really could be the area where we can together improve
 basic Linux utils.

 Maybe I'm blind, but why do you think that the code in look, cal, ...
 will be better if you split util-linux into more small packages?

 People usually fork or split projects if they have a problem with
 collaboration. Is it our actual problem? I don't think so.

 The util-linux exists more than 10 year without fatal problems and I
 think it can exist next 10 years.

> Forking of util-linux is the ideal time to improve this.  Just don't
> fork the whole package; fork the part you're interested in.  The

 No, the motivation for new util-linux upstream is that there is more
 than 100 util-linux patches in Suse, Red Hat or Debian. We're
 interested in whole package and we want to merge changes from
 distribution to this upstream and sync code in util-linux with
 kernel. This is necessary step. 

 BTW, it's not so long time ago when schedutils has been incorporated
 to util-linux. It seems that poeple are able to found reasons why merge
 is better than split :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: splitting util-linux (was: kill)

[Albert Cahalan]

On 12/21/06, Karel Zak <kzak@redhat.com> wrote:

> > problem, since there are people who are willing to maintain some
> > pieces, but less energetic about maintaining the entire package or
> > working through a central bureaucracy.
>
>  I don't see any problem collaborate with more people.

Power sharing is difficult.
See also: OpenBSD, DragonflyBSD, XEmacs

>  Maybe I'm blind, but why do you think that the code in look, cal, ...
>  will be better if you split util-linux into more small packages?

As far as I can see, "look" is basically a lame grep.
Is this something we really need?

(meanwhile the "primes" program needed for making some types
of hash function gets lumped in with a bunch of obsolete games!)

I see rdev. If I remember right, that's used for the pre-2.6 kernels
when you use "dd" to put a raw kernel image on a floppy.
Older kernels had a built-in boot loader that needed parameters.
Uh... NOT useful.

Lots of computers don't even have floppy drives anymore.

Aw, let's just go down the list. Going by what Debian ships:

arch -- OK, though people use uname
chkdupexe -- OK, though obscure
ddate -- pure junk
getopt -- needed for bloated shell scripts AFAIK
line -- people use read
mcookie -- buggy, and belongs in X.org
more -- still better-known than "less", sadly
namei -- OK, though obscure and probably broken
pg -- old-timers from SysV are probably addicted
readprofile -- critical dev tool, though obscure
rev -- possibly useful, though obscure
setterm -- useful
whereis -- might make sense on Gentoo or BSD
blockdev -- for disk benchmarks maybe
cfdisk -- important and dangerous to fool with
clock -- perhaps called from boot scripts or GUI tools
cytune -- very obsolete hardware?
dmesg -- critical
elvtune -- useful
fdformat -- for nostalgia?
fdisk -- important and dangerous to fool with
fsck.minix -- for the retro-computing crowd
getty -- might get used on servers for serial consoles (*)
hwclock -- perhaps called from boot scripts or GUI tools
ipcrm -- critical, sadly
ipcs -- critical, sadly
isosize -- belongs with mkisofs, not in util-linux
mkfs -- important and dangerous to fool with
mkfs.minix -- for the retro-computing crowd
mkswap -- needed
pivot_root -- probably belongs here
ramsize -- ?
raw -- obsolete
rdev -- very obsolete
rootflags -- very obsolete
setsid -- eh, bash or xterm does this for you...?
sfdisk -- important and dangerous to fool with
tunelp -- obsolete (new PCs even lack the ports)
vidmode -- very obsolete

*  getty note: yeah I know you need a getty, but everybody
   and their dog wrote at least one getty program, minimum.

>  No, the motivation for new util-linux upstream is that there is more
>  than 100 util-linux patches in Suse, Red Hat or Debian. We're
>  interested in whole package and we want to merge changes from
>  distribution to this upstream and sync code in util-linux with
>  kernel. This is necessary step.

Something like that is what destabilized the other branch of
procps development. Resist the urge to be a patchbot. You
need to fully understand the patches AND SIDE EFFECTS.
If you apply those patches without a test suite, you are doomed.

Re: splitting util-linux (was: kill)

[Bryan Henderson]

>I see rdev. If I remember right, that's used for the pre-2.6 kernels
>when you use "dd" to put a raw kernel image on a floppy.

Yeah, that's classic Unix.  I don't think it was ever actually used
much for floppy disks, because you can also just put a filesystem and
LILO on a floppy; that's what I've always done.  I didn't know they
eliminated the integrated boot loader in 2.6.

-- 
Bryan Henderson                                   San Jose, California

Re: splitting util-linux (was: kill)

[Albert Cahalan]

On 22 Dec 2006 07:13:47 +0000, Bryan Henderson <bryanh@giraffe-data.com> wrote:
> >I see rdev. If I remember right, that's used for the pre-2.6 kernels
> >when you use "dd" to put a raw kernel image on a floppy.
>
> Yeah, that's classic Unix.  I don't think it was ever actually used
> much for floppy disks, because you can also just put a filesystem and
> LILO on a floppy; that's what I've always done.  I didn't know they
> eliminated the integrated boot loader in 2.6.

My memory of rdev is dim, but I sure do remember putting the kernel
right on the floppy.

The compressed kernel was less than 400 kB.
That allowed for a compressed RAM disk of 1 MB.
I'd place the compressed RAM disk image at an
offset of 400 kB, then somehow indicate this to
the kernel. Maybe it was in the header, but maybe
it was a compile option.

None of this busybox nonsense of course... just
grab regular stuff from /bin and /lib, any file from /etc
that wasn't obviously useless, a real /dev... but then
along came big bad libc 6.

Anyway... this stuff is no longer useful at all.

Re: splitting util-linux (was: kill)

[Bryan Henderson]

>Aw, let's just go down the list. Going by what Debian ships:

>[39 programs]

My system has a more or less complete installation of util-linux, (but
with many programs renamed to yield to other packages and it's a
hybrid of various releases of util-linux because I tend to upgrade
only the parts that need upgrading) and it's got 61 programs in it,
including 4 symbolic links.  So it looks like Debian already
eliminated the more crufty pieces for you.

-- 
Bryan Henderson                                   San Jose, California

Re: splitting util-linux (was: kill)

[Evan Hunt]

> As far as I can see, "look" is basically a lame grep.
> Is this something we really need?

Yes, it is.  If you're looking up matching lines in a very large file,
repeatedly, a binary search can be much, much faster than a linear regular-
expression search.  I've written quite a lot of scripts that used look to
good effect.  Here, check out this factor-300 speedup:

    $ time look borealis
    Borealis
    borealis

    real    0m0.003s
    user    0m0.000s
    sys     0m0.004s

    $ time grep -y borealis /usr/share/dict/words
    Borealis
    borealis

    real    0m0.990s
    user    0m0.944s
    sys     0m0.024s

However, you're right about it being lame.  It only searches at the
beginning of the line, making it useless for files that are sorted on
different fields, can only deal with lexical ordering, etc.

I'm fixing this, which is part of why I ended up in this conversation
in the first place; I want to put the improved version into miscutils.

> more -- still better-known than "less", sadly

Ah, a pet peeve of mine. :)

Why doesn't the 'less' package just install 'more' as a link to 'less'?
SCO did that years ago, and nobody ever missed the old version.  And I got
used to "more" being a decent pager, and now every time I try to use it on
linux, I get this annoying broken version...

Evan Hunt

Re: splitting util-linux (was: kill)

[Karel Zak]

On Thu, Dec 21, 2006 at 11:45:53PM -0800, Evan Hunt wrote:
> 
> > As far as I can see, "look" is basically a lame grep.
> > Is this something we really need?
> 
> However, you're right about it being lame.  It only searches at the
> beginning of the line, making it useless for files that are sorted on
> different fields, can only deal with lexical ordering, etc.

 Yes, the definition of "look" is pretty exact. Who do you think that
 the tool should be work with any other type of files or with
 a different ordering ? Now, it seems like right tool for right job.

> I'm fixing this, which is part of why I ended up in this conversation
> in the first place; I want to put the improved version into miscutils.
> 
> > more -- still better-known than "less", sadly
> 
> Ah, a pet peeve of mine. :)
> 
> Why doesn't the 'less' package just install 'more' as a link to 'less'?

 because some distributions have the 'more' command in the root
 filesystem (/bin) and the 'less' command in /usr/bin.

 But yes, I agree that the 'more' should be die in some future release.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: splitting util-linux (was: kill)

[Evan Hunt]

>  Yes, the definition of "look" is pretty exact. Who do you think that
>  the tool should be work with any other type of files or with
>  a different ordering ? Now, it seems like right tool for right job.

It works well for looking up words in a dictionary file.  It doesn't work
very well for looking up lines in a flat-file database.

Consider a flat file like the following, each line containing a name,
a serial number, and some additional information.  Each time a new
transaction comes in, the serial number is incremented and a record
is added to the end of the file:

John:White:1:...
Mary:Brown:2:...
Fred:Green:3:...

...and so on.  Now, if that file grows very large, it would be useful to
be able to rapidly search it based on the serial number, e.g., something
like this:

$ search -n -t: -k3 97273 <filename>

Right now, the closest you can get to this with a standard unix or linux
tool is to use "look", but that only works if the serial number is the
first field of the file... and even then it doesn't work very well, because
the file has to be lexically sorted, so the serial numbers would all have
to be padded to the same length with leading zeroes.  It's faster than
using awk or grep, but it's a hassle.

I must have written a dozen shell scripts over the years that would have
been faster and easier to write if a tool like this had existed, and I
can't be the only one...

So I've finally gotten around to writing such a tool, and I'm calling
it "search" or "bs" (for "binary search") or something along those lines.
But I figured, well, it's almost identical to "look" when called without
arguments, so why not just supplant the existing "look"?  If it's invoked
as "look <word>", then it looks up the word in /usr/share/dict/words; if
it's invoked as "search -args <word> <filename>" then it's a general-
purpose binary search tool.

I'm still playing with it, but I plan to have it ready to contribute in
another few days.

Evan Hunt

Re: splitting util-linux (was: kill)

[Karel Zak]

On Fri, Dec 22, 2006 at 12:45:21AM -0800, Evan Hunt wrote:


> ...and so on.  Now, if that file grows very large, it would be useful
> to be able to rapidly search it based on the serial number, e.g.,
> something like this:

> $ search -n -t: -k3 97273 <filename>

 Hmm... I can imagine faster things based on possition (so you call seek()) rather
 than on the serial number. But it's completely different topic.

> So I've finally gotten around to writing such a tool, and I'm calling
> it "search" or "bs" (for "binary search") or something along those lines.

 No problem.

> But I figured, well, it's almost identical to "look" when called without
> arguments, so why not just supplant the existing "look"?  If it's invoked
> as "look <word>", then it looks up the word in /usr/share/dict/words; if
> it's invoked as "search -args <word> <filename>" then it's a general-
> purpose binary search tool.

 And why we cannot use two tools for these two different jobs/formats? 
 
 I really don't see any reason why we should merge these search tools
 to one monolithic tool. There's many different formats how you can
 organize your data and I think it's normal that we have separated
 tools for every format. 
 
 It really doesn't make sense merge it with 'look' if the 'look' is 
 stupid and simple tool how search in data in files in 
    sort --ignore-case --dictionary-order | uniq
 format. 


  Karel "stubborn" ;-)

-- 
 Karel Zak  <kzak@redhat.com>

Re: splitting util-linux (was: kill)

[Evan Hunt]

>  Hmm... I can imagine faster things based on possition (so you call
>  seek()) rather than on the serial number. But it's completely different
>  topic.

Something like that is coming next, as a matter of fact.  But yes,
different topic.

>  And why we cannot use two tools for these two different jobs/formats? 

Because it's an unnecessary duplication of code, because it's trivially
easy to have my tool run in a "look"-equivalent mode, and because I imagine
there may be some other shell script author out there in the world who's
been using "look" for this purpose for a long time and would be pleased
to find it suddenly having a smarter set of options.

>  I really don't see any reason why we should merge these search tools
>  to one monolithic tool. There's many different formats how you can
>  organize your data and I think it's normal that we have separated
>  tools for every format. 

Then why not different tools for organizing it?  Instead of using 
"sort --ignore-case --dictionary-order --unique", why not have a
single-purpose "dictsort" tool to generate the input for "look"?  ;)

I'm kidding, here, but my point is serious:  Flexible tools that can
serve many purposes are better than inflexible ones that only serve
one, and if you have a flexible tool that serves your purpose equally
well or better, then there's no need to keep the inflexible ones around.

(I'm not sure this conversation still needs to be on the util-linux-ng
list, sorry if I'm hijacking it...)

Evan Hunt

Re: splitting util-linux (was: kill)

[Ian Kent]

On Fri, 2006-12-22 at 09:07 +0100, Karel Zak wrote:
> On Thu, Dec 21, 2006 at 11:45:53PM -0800, Evan Hunt wrote:
> > 
> > > As far as I can see, "look" is basically a lame grep.
> > > Is this something we really need?
> > 
> > However, you're right about it being lame.  It only searches at the
> > beginning of the line, making it useless for files that are sorted on
> > different fields, can only deal with lexical ordering, etc.
> 
>  Yes, the definition of "look" is pretty exact. Who do you think that
>  the tool should be work with any other type of files or with
>  a different ordering ? Now, it seems like right tool for right job.
> 
> > I'm fixing this, which is part of why I ended up in this conversation
> > in the first place; I want to put the improved version into miscutils.
> > 
> > > more -- still better-known than "less", sadly
> > 
> > Ah, a pet peeve of mine. :)
> > 
> > Why doesn't the 'less' package just install 'more' as a link to 'less'?
> 
>  because some distributions have the 'more' command in the root
>  filesystem (/bin) and the 'less' command in /usr/bin.

And because some people remember that stuff like this was done because
"/usr" may have been on a separate partition and this was the place to
put binaries that depended on a larger number of libraries, usually also
in "/usr/lib". Then in recovery situations such as single user mode only
"/" would be mounted. Same story with "/bin/sh" of course.

Those days may be behind us but I still think we should be able to boot
a minimal root filesystem for recovery, but perhaps I'm just old
fashioned.

>  But yes, I agree that the 'more' should be die in some future release.
> 
>     Karel
> 

Re: splitting util-linux (was: kill)

[Karel Zak]

On Fri, Dec 22, 2006 at 01:12:54AM -0500, Albert Cahalan wrote:
> On 12/21/06, Karel Zak <kzak@redhat.com> wrote:
> 
> >> problem, since there are people who are willing to maintain some
> >> pieces, but less energetic about maintaining the entire package or
> >> working through a central bureaucracy.
> >
> > I don't see any problem collaborate with more people.
> 
> Power sharing is difficult.

 Oh.. yes. Good things are difficult :-)

> I see rdev. If I remember right, that's used for the pre-2.6 kernels

 I'm not 100% if wee still need it, but RH and Suse still have
 rdev for ix86. 
 
 rdev = ramsize, rootflags and vidmode (all is implemented in rdev.c)

> Lots of computers don't even have floppy drives anymore.

 and a lot of computers still have floppy drives...

> arch -- OK, though people use uname

 we have tried remove it from FC, but many users still use it.

> chkdupexe -- OK, though obscure

 removed from in FC/RHEL, included in Suse and Debian

> ddate -- pure junk

 yes, strange tool

> line -- people use read

 removed from in FC/RHEL, included in Suse and Debian

> namei -- OK, though obscure and probably broken

 I have patches for this tool. I've played with it last week and
 it's not so bad tool. For example list all permission for a path: 

 namei -m /usr/local/bin/cvscheck 
 f: /usr/local/bin/cvscheck
   drwxr-xr-x /
   drwxr-xr-x usr
   drwxr-xr-x local
   drwxr-xr-x bin
   -rwxr-xr-x cvscheck

 I don't think it's so easily possible with an other tool.

> pg -- old-timers from SysV are probably addicted

 removed from FC/RHEL and Suse, included in Debian

> whereis -- might make sense on Gentoo or BSD

 I often use it :-)

> cytune -- very obsolete hardware?

 ix86 alpha armv4l

> elvtune -- useful

 removed from FC/RHEL, included in Suse, Debian

 elvtune is only useful on older kernels, 2.6 use IO scheduler and
 sysfs tunables. So deprecated tool.

> fdformat -- for nostalgia?

 No, I have feedback that people use it. FC/RHEL also includes
 http://floppyutil.sourceforge.net/ that supports IDE floppies too.

> fsck.minix -- for the retro-computing crowd

 removed from FC/RHEL, included in Suse, Debian

> getty -- might get used on servers for serial consoles (*)

 agetty

> isosize -- belongs with mkisofs, not in util-linux

 probably yes

> mkfs.minix -- for the retro-computing crowd

 removed from FC/RHEL, included in Suse, Debian

> raw -- obsolete

 Still supported by kernel. We have to keep it in the package.

 (My idea has been remove it from RHEL5, but there is
 still many enterprise users who require it. Things are moving
 slowly...)

> tunelp -- obsolete (new PCs even lack the ports)

 Really? My one week old dell has it.


 There is more odd utils:

 newgrp     - broken, there is better version in shadow-utils 

 (but the version in shadow-utils is broken too. I fixed it one year
 ago, but the patch is in FC/RHEL only :-( Need discussion with
 shadow-utils upstream.


 sln    - removed from FC/RHEL and Debian, included in Suse
        (new version is in glibc)

 shutdown   - removed from all dists (new version for example in
              SysVinit)


 wall - included in Suse (new version in SysVinit)

 scriptreplay  - Perl script ;-( I'm going to rewrite to C. The
            dependence on Perl is ugly for basic system package.
       
 last   - probably removed from all dists (new version in SysVinit)
 

 I think we can mark many of these utils as deprecated in 2.13 release
 and remove it in a future release (2.14). Maybe we can do
 something like

     ./configure --deprecated="list of wanted deprecated utils"

 it means default installation will be without these tools and 
 nostalgic uses will be compile with the --deprecated option.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: splitting util-linux (was: kill)

[Mark Rosenstand]

On Fri, 2006-12-22 at 11:24 +0100, Karel Zak wrote:
> On Fri, Dec 22, 2006 at 01:12:54AM -0500, Albert Cahalan wrote:
> 
> > arch -- OK, though people use uname
> 
>  we have tried remove it from FC, but many users still use it.

Perhaps it could spew a deprecation warning referring to uname so
current users can be spotted, and lead to removal long-term.

Re: splitting util-linux (was: kill)

[Albert Cahalan]

On 12/22/06, Karel Zak <kzak@redhat.com> wrote:

>  I think we can mark many of these utils as deprecated in 2.13 release
>  and remove it in a future release (2.14). Maybe we can do
>  something like
>
>      ./configure --deprecated="list of wanted deprecated utils"
>
>  it means default installation will be without these tools and
>  nostalgic uses will be compile with the --deprecated option.

Can you get all the obsolete stuff into a separate RPM package?
Somebody might actually want tunelp or fdformat, but the vast
majority of us are totally uninterested.

Re: splitting util-linux (was: kill)

[Albert Cahalan]

On 12/22/06, Karel Zak <kzak@redhat.com> wrote:
> On Fri, Dec 22, 2006 at 01:12:54AM -0500, Albert Cahalan wrote:

> > namei -- OK, though obscure and probably broken
>
>  I have patches for this tool. I've played with it last week and
>  it's not so bad tool. For example list all permission for a path:
>
>  namei -m /usr/local/bin/cvscheck
>  f: /usr/local/bin/cvscheck
>    drwxr-xr-x /
>    drwxr-xr-x usr
>    drwxr-xr-x local
>    drwxr-xr-x bin
>    -rwxr-xr-x cvscheck
>
>  I don't think it's so easily possible with an other tool.

The tool claims to let you know where you have too many
symlinks. I guess it could do that from one direction, but
the other direction requires knowledge of undocumented
kernel limits which have changed recently. The recursion
level just went from 5 to 8, and could change again.

> > pg -- old-timers from SysV are probably addicted
>
>  removed from FC/RHEL and Suse, included in Debian

That's probably not nice of you.

> > whereis -- might make sense on Gentoo or BSD
>
>  I often use it :-)

How? Unlike BSD, the OS isn't under /src.

> > cytune -- very obsolete hardware?
>
>  ix86 alpha armv4l

Those are CPUs. The hardware in question is not a CPU.
It's a multi-port serial board.

> > raw -- obsolete
>
>  Still supported by kernel. We have to keep it in the package.
>
>  (My idea has been remove it from RHEL5, but there is
>  still many enterprise users who require it. Things are moving
>  slowly...)

Well make it spew warnings.

> > Lots of computers don't even have floppy drives anymore.
>
>  and a lot of computers still have floppy drives...
...
> > tunelp -- obsolete (new PCs even lack the ports)
>
>  Really? My one week old dell has it.

I guess you got an older model. I just got a Dell XPS 400.

no floppy drive
no serial port
no parallel port
no PS/2 mouse port
no PS/2 keyboard port

I got 7 USB ports instead, not counting ones on the
monitor or keyboard.

The obsolete parts are getting left off because people
haven't been using the ones they have. USB replaces
all of that obsolete crud, generally doing a better job.

You can shove the obsolete stuff into Fedora Extras.

Re: splitting util-linux (was: kill)

[Bryan Henderson]

>>> > tunelp -- obsolete (new PCs even lack the ports)
>>>
>>>  Really? My one week old dell has it.
>
>I guess you got an older model. I just got a Dell XPS 400.
>
>no floppy drive
>no serial port
>no parallel port
>no PS/2 mouse port
>no PS/2 keyboard port
>
> ...
>
>You can shove the obsolete stuff into Fedora Extras.

These obsolete tools cost very little to have available on all Fedora
systems.  And there are plenty of people using modern Fedora on
hardware that was made a few years ago.


-- 
Bryan Henderson                                   San Jose, California

Re: splitting util-linux (was: kill)

[Bryan Henderson]

> That's not 100% true. You need upstream and downstream maintainer for
> every package. You need an infrastructure (scm, mailing list, ...)
> for every package. Maybe it seems like something simple (10 clicks at
> sf.net), but my experience is completely different. Maintainig is
> really boring work and after few months nobody wants to do it... 
> 
> Number of well maintained packages is not so big. Believe me, people
> who work on Linux distributions fight with unmaintained projects every
> day.

If you're willing to do all that work for all of the components of
util-linux, or alternatively if most of the components simply don't
require any maintenance, then the labor-distributing advantage of
splitting isn't there.  And you've obviously determined that you can
distribute one big package more easily than lots of little ones
(myself, I've found the opposite -- I split things up into independent
parts so that I can release in smaller doses).

That still leaves the flexibility hit for users, since it's extra work
to install just what you want or upgrade just one piece without
disturbing other pieces.

But never mind.  I brought it up in case you had thoughts in the same
vein; since you don't, I know emails from me won't change that.

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California

Re: splitting util-linux (was: kill)

[Karel Zak]

On Fri, Dec 22, 2006 at 06:44:21AM +0000, Bryan Henderson wrote:
> > That's not 100% true. You need upstream and downstream maintainer for
> > every package. You need an infrastructure (scm, mailing list, ...)
> > for every package. Maybe it seems like something simple (10 clicks at
> > sf.net), but my experience is completely different. Maintainig is
> > really boring work and after few months nobody wants to do it... 
> > 
> > Number of well maintained packages is not so big. Believe me, people
> > who work on Linux distributions fight with unmaintained projects every
> > day.
> 
> If you're willing to do all that work for all of the components of
> util-linux, or alternatively if most of the components simply don't
> require any maintenance, then the labor-distributing advantage of
> splitting isn't there.  And you've obviously determined that you can

 Yes.

> distribute one big package more easily than lots of little ones
> (myself, I've found the opposite -- I split things up into independent
> parts so that I can release in smaller doses).

 Frankly, maybe 90% of utils in util-linux needn't any real development or
 fixing. These utils are stable for really long time.

 My experience (last two years) is that almost all bug reports are
 about the mount/losetup, login, fdisk and man pages. Also the
 problematic part of the package is NFS code -- but it will be removed
 to nfs-utils (already done in FC6/RHEL5).

 For example list of patches from Fedora Core 6:

        floppy-0.12-locale.patch
        util-linux-2.11y-chsh-103004.patch
        util-linux-2.11y-fdisksegv-103954.patch
        util-linux-2.11y-multibyte.patch
        util-linux-2.11y-procpartitions-37436.patch
        util-linux-2.11y-skipraid2.patch
        util-linux-2.12a-126572-fdiskman.patch
        util-linux-2.12a-16415-rdevman.patch
        util-linux-2.12a-ipcs-84243-86285.patch
        util-linux-2.12a-mountbylabel-dm.patch
        util-linux-2.12a-mount-man-cifs.patch
        util-linux-2.12a-pamsession.patch
        util-linux-2.12a-pamstart.patch
        util-linux-2.12a-partlimit.patch
        util-linux-2.12j-113790-hotkeys.patch
        util-linux-2.12j-managed.patch
        util-linux-2.12j-pamconsole.patch
        util-linux-2.12p-cal-wide.patch
        util-linux-2.12p-col-EILSEQ.patch
        util-linux-2.12p-execl.patch
        util-linux-2.12p-fdformat-ide.patch
        util-linux-2.12p-floppy-generic.patch
        util-linux-2.12p-fstab-man.patch
        util-linux-2.12p-ipcs-typo.patch
        util-linux-2.12p-login-lastlog.patch
        util-linux-2.12p-look-separator.patch
        util-linux-2.12p-lvm2dupes-76467.patch
        util-linux-2.12p-mount-ocfs2.patch
        util-linux-2.12p-mtab-lock.patch
        util-linux-2.12p-swaponsymlink-57300.patch
        util-linux-2.12p-vipw-perm.patch
        util-linux-2.13-arch.patch
        util-linux-2.13-audit-hwclock.patch
        util-linux-2.13-audit-login.patch
        util-linux-2.13-cal-wide.patch
        util-linux-2.13-cramfs-maxentries.patch
        util-linux-2.13-cramfs-zerofiles.patch
        util-linux-2.13-ctrlaltdel-man.patch
        util-linux-2.13-ctty3.patch
        util-linux-2.13-fdisk-b-4096.patch
        util-linux-2.13-fdisk-gpt.patch
        util-linux-2.13-fdisk-isfull.patch
        util-linux-2.13-fdisk-sectors.patch
        util-linux-2.13-hexdump-gcc.patch
        util-linux-2.13-ipcs-shmax.patch
        util-linux-2.13-login-hang.patch
        util-linux-2.13-login-ipv6.patch
        util-linux-2.13-login-pam-acct.patch
        util-linux-2.13-login-timeval.patch
        util-linux-2.13-losetup-all.patch
        util-linux-2.13-losetup-deprecated.patch
        util-linux-2.13-losetup-rdonly.patch
        util-linux-2.13-mkswap-mounted.patch
        util-linux-2.13-mkswap-selinux.patch
        util-linux-2.13-more-CLOEXEC.patch
        util-linux-2.13-moretc.patch
        util-linux-2.13-mount-comment.patch
        util-linux-2.13-mount-context.patch
        util-linux-2.13-mount-man-bugs.patch
        util-linux-2.13-mount-man-nfs4.patch
        util-linux-2.13-mount-man-nfs.patch
        util-linux-2.13-mount-move.patch
        util-linux-2.13-mount-nonfs.patch
        util-linux-2.13-mount-sloppy.patch
        util-linux-2.13-mount-subtree.patch
        util-linux-2.13-mount-twiceloop.patch
        util-linux-2.13-mount-uhelper.patch
        util-linux-2.13-mount-uuid.patch
        util-linux-2.13-namei-logic.patch
        util-linux-2.13-rmparts.patch
        util-linux-2.13-schedutils-man.patch
        util-linux-2.13-schedutils-SCHED_BATCH.patch
        util-linux-2.13-swapon-suspend.patch
        util-linux-2.13-swap-page.patch
        util-linux-2.13-umount-sysfs.patch


 [Not all will be ever merged with upstream of course, there're RH
 specific patches too]
 
    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: kill

[Alfred M. Szmidt]

   > The problem is that coreutils is not suitable for `random stuff
   > that is not part of the core system'; this is not th point of
   > coreutils, core system utilities for the GNU system and variants.
   > If you have a better idea than starting a new project (and it
   > isn't really even "real" GNU project to begin with), then I'm
   > sure we all would be interested in hearing your suggestions.

    Well, from my Linux egoistic point of view there is nothing what I
    have to change with look or cal.

When you speak of the operating system that is basically the GNU
system with Linux added, would you please call it "GNU/Linux"?  If you
call it just "Linux", you're giving the principal developers none of
the credit.

See http://www.gnu.org/gnu/gnu-linux-faq.html for more explanation
about this.

Re: kill

[Martin Mares]

Hello!

> When you speak of the operating system that is basically the GNU
> system with Linux added, would you please call it "GNU/Linux"?  If you
> call it just "Linux", you're giving the principal developers none of
> the credit.

Eh, please stop that. We are here to do real work, not to chatter
about somebody's political or philosophical agenda.

				Have a nice fortnight
-- 
Martin `MJ' Mares                          <mj@ucw.cz>   http://mj.ucw.cz/   
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Immanuel doesn't pun, he Kant.

Re: kill

[Karel Zak]

On Thu, Dec 21, 2006 at 12:39:54PM +0100, Martin Mares wrote:
> 
> > When you speak of the operating system that is basically the GNU
> > system with Linux added, would you please call it "GNU/Linux"?  If you
> > call it just "Linux", you're giving the principal developers none of
> > the credit.

 This is pretty old story... too old for this new mailing list.

> Eh, please stop that. We are here to do real work, not to chatter
> about somebody's political or philosophical agenda.

 Exactly!

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: kill

[Alfred M. Szmidt]

   > When you speak of the operating system that is basically the GNU
   > system with Linux added, would you please call it "GNU/Linux"?
   > If you call it just "Linux", you're giving the principal
   > developers none of the credit.

   Eh, please stop that. We are here to do real work, not to chatter
   about somebody's political or philosophical agenda.

This has nothing to do with politics or philosophy.  It is simply
about giving credit where credit is due.

Re: kill

[Albert Cahalan]

On 12/21/06, Alfred M. Szmidt <ams@gnu.org> wrote:
>    > When you speak of the operating system that is basically the GNU
>    > system with Linux added, would you please call it "GNU/Linux"?
>    > If you call it just "Linux", you're giving the principal
>    > developers none of the credit.
>
>    Eh, please stop that. We are here to do real work, not to chatter
>    about somebody's political or philosophical agenda.
>
> This has nothing to do with politics or philosophy.  It is simply
> about giving credit where credit is due.

In that case, CREDIT IS NOT DUE. The OS name is also
definitely not WHERE credit is due, even if it were due, and
even if it were at all appropriate to demand credit.

I guess you can't admit that, not with an ams@gnu.org email
address at least.

The principal developers are not building a GNU system.
Sometimes "GNU" is a flag of convenience, being a safe
party to assign copyright to. The real work is all done by
Linux users and Linux distributors and the occasional
BSD or Cygwin user. (Cygwin being full of Linux features,
not HURD features)

I see you don't give credit for the HURD, despite the fact
that you swiped TCP/IP and numerous drivers from Linux.
HURD is using Linux for life support, yet no credit???
The hypocrisy is showing. You also don't credit X.org,
BSD, or anything else. Where is the credit???

On top of all that, "GNU" is just a crappy name. As a
word, it's obviously not nice-sounding, even supposing
you do figure out a way to pronounce it. Let's look at
the meaning though: GNU's (recursive nonsense),
Not (negative!) UNIX (referring to the competitor). Eeew.
There's nothing positive about that. It sounds like some
kind of grudge... probably because RMS was pissed off
at UNIX when he invented the term.

So we have inappropriateness, hypocrisy, and an
ugly-sounding (if pronouncable) nonsense name
with serious negative connotations.

Re: kill

[Ian Kent]

On Thu, 2006-12-21 at 17:50 +0100, Alfred M. Szmidt wrote:
>    > When you speak of the operating system that is basically the GNU
>    > system with Linux added, would you please call it "GNU/Linux"?
>    > If you call it just "Linux", you're giving the principal
>    > developers none of the credit.
> 
>    Eh, please stop that. We are here to do real work, not to chatter
>    about somebody's political or philosophical agenda.
> 
> This has nothing to do with politics or philosophy.  It is simply
> about giving credit where credit is due.

If the people on a list like this don't know where the credit for the
products in this package lie then they probably shouldn't be present.

Ian

Re: kill

[Ian Kent]

On Wed, 2006-12-20 at 10:03 +0000, Pádraig Brady wrote:
> Karel Zak wrote:
> > On Wed, Dec 20, 2006 at 01:42:13AM -0500, Albert Cahalan wrote:
> >> Karel Zak writes:
> >>
> >>> 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.
> 
> We definitely need less version of kill:
> 
> ubuntu: $ dpkg -S `which kill`
> procps: /bin/kill
> 
> fedora: $ rpm -qf `which kill`
> util-linux-2.12p-9.3
> 
> fedora: $ type kill
> kill is a shell builtin
> 
> $ tar tzf coreutils-6.2.tar.gz | grep kill
> coreutils-6.2/src/kill.c
> coreutils-6.2/man/kill.1
> coreutils-6.2/man/kill.x
> 

So the question is where should kill live.

And we could probably decide that if we had a quorum of down stream
maintainers on the list.

Anyone?

Ian

Re: kill

[Albert Cahalan]

On 12/20/06, Pádraig Brady <P@draigbrady.com> wrote:
> Karel Zak wrote:
> > On Wed, Dec 20, 2006 at 01:42:13AM -0500, Albert Cahalan wrote:
> >> Karel Zak writes:
> >>
> >>> 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.
>
> We definitely need less version of kill:
>
> ubuntu: $ dpkg -S `which kill`
> procps: /bin/kill
>
> fedora: $ rpm -qf `which kill`
> util-linux-2.12p-9.3
>
> fedora: $ type kill
> kill is a shell builtin
>
> $ tar tzf coreutils-6.2.tar.gz | grep kill
> coreutils-6.2/src/kill.c
> coreutils-6.2/man/kill.1
> coreutils-6.2/man/kill.x

Hey, you left out the bsdutils kill command! That was what
Debian was using prior to the procps one.

> >  We can think about it. I'm not sure with this kind of changes in the
> >  next 2.13 release. That release should be more about bug fixes and
> >  code stabilisation.

Don't try it unless you have a complete test suite.

I'm seriously NOT kidding. Don't try it without a test suite.
This is not a project to be fucking up.

You even have something going against you: there is no
one person who really knows 100% of the code. You're in
a heap of trouble if you start putting in your favorite random
patch sets. You have no clue what you'll be breaking.

I had enough troubles with my own code prior to writing a
huge collection of regression tests. I changed my ways
after the procps release that failed to show processes
whose PID started with a "3". Once you have regression
tests, you can rip up the code with far less fear. Writing
the tests is also a good way to find bugs and an excellent
way to get yourself _really_ familiar with the code. Before
you modify code, always be sure you have test coverage
of anything even remotely related.

> On a similar note, there are utils in util-linux[-ng] that are
> not specific to linux (like look, cal etc.)

I have a "watch" command in procps that I wouldn't mind
getting rid of. It needs updating to be tolerant of color
escape sequences and maybe stuff like double-wide and
combining characters.

> There has been the proposal for a new miscutils project
> on the coreutils list: http://lists.gnu.org/archive/html/bug-coreutils/2006-11/msg00086.html
> for which I am the proposed maintainer of.
> Possibly some of these non specific linux utils could be moved there?

Gee, if we all grab a chunk of util-linux, then there isn't
any need for a util-linux project at all. :-)

Try asking Theodore Ts'o if he'd mind the fs-related stuff.
He's responsible. His ext2/3/4 test suite is why e2fsck
has such high quality.

Re: kill (was: Re: util-linux: orphan)

[Albert Cahalan]

On 12/20/06, Karel Zak <kzak@redhat.com> wrote:
> On Wed, Dec 20, 2006 at 01:42:13AM -0500, Albert Cahalan wrote:

> > Well, how about giving me a chunk of it? I'd like /bin/kill please.
>
>  We can think about it. I'm not sure with this kind of changes in the
>  next 2.13 release. That release should be more about bug fixes and
>  code stabilisation.
>
>  I'd like to do some consolidation in 2.14. I also need explore why
>  RHEL/FC uses the kill command from util-linux rather that from
>  procps. And Suse and Debian?

RHEL/FC probably uses util-linux because that is older.

Debian uses procps.

SuSE is probably dying, having made a deal with some bastards
who've screwed every business "partner" they've ever had.

>  Frankly, things around proc/ need more changes. There is area for huge
>  improvements. There is also the psmisc project where community duplicate
>  effort and code.

Craig Small has talked about handing psmisc to me (he is also
the procps downstream for Debian) but we never really bothered.
I guess we're both fine with the minor duplication.

>  My dream is stable and useful libproc (with python and perl binding)
>  and one or two packages based on this library. (Yes we have libproc
>  in procps, but this library is completely useless outside procps...).

I started a move toward that, adding symbol versioning and such.
Then I realized that the combination of volatile kernel interfaces
and a stable libproc ABI just wouldn't work OK. The various structs
need to change when the kernel changes. Sure, symbol versioning
can "fix" that with one function for each ABI version, but that gets
terribly gross. I also didn't get any answers to my questions about
the version script format, particularly about methods to deprecate
old interfaces gradually and drop them one by one. If you know of
a low-bloat high-performance way to make things work, tell me.

Python itself seems to have versioning problems. The traditional
solution for scripting languages is to parse /bin/ps output; this is
perfectly reasonable because /bin/ps output is meant to be parsable.
In any case, the python interpreter is so buggy that you really
shouldn't be using it. (well, at least don't go anywhere near threads)

Re: kill (was: Re: util-linux: orphan)

[Karel Zak]

On Wed, Dec 20, 2006 at 11:33:53AM -0500, Albert Cahalan wrote:
> SuSE is probably dying, having made a deal with some bastards
> who've screwed every business "partner" they've ever had.

 Please! ... our business is not talk about Novell's business.

> > My dream is stable and useful libproc (with python and perl binding)
> > and one or two packages based on this library. (Yes we have libproc
> > in procps, but this library is completely useless outside procps...).
> 
> I started a move toward that, adding symbol versioning and such.

 We're ***off-topic***... but I think the problem with libproc is not about
 versioning. I see there (exported) global variables, functions like 
 
 void getstat(jiff *restrict cuse, jiff *restrict cice, jiff *restrict
         csys, jiff *restrict cide, jiff *restrict ciow, jiff *r unsigned long
         *restrict pin, unsigned long *restrict pout, unsigned long *restrict
         s_in, unsigned long *restrict unsigned *restrict intr, unsigned
         *restrict ctxt, unsigned int *restrict running, unsigned int
         *restrict blocked, unsigned int *restrict btime, unsigned int
         *restrict processes)
 
 API is not uniform ("esprit de corps") and many others things which
 looks really ugly. 

> old interfaces gradually and drop them one by one. If you know of
> a low-bloat high-performance way to make things work, tell me.

 I think the best docs about shared libs:

    http://people.redhat.com/drepper/dsohowto.pdf

   Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: kill (was: Re: util-linux: orphan)

[Albert Cahalan]

On 12/20/06, Karel Zak <kzak@redhat.com> wrote:
> On Wed, Dec 20, 2006 at 11:33:53AM -0500, Albert Cahalan wrote:

> > I started a move toward that, adding symbol versioning and such.
>
>  We're ***off-topic***... but I think the problem with libproc is not about
>  versioning. I see there (exported) global variables, functions like
>
>  void getstat(jiff *restrict cuse, jiff *restrict cice, jiff *restrict
>          csys, jiff *restrict cide, jiff *restrict ciow, jiff *r unsigned long
>          *restrict pin, unsigned long *restrict pout, unsigned long *restrict
>          s_in, unsigned long *restrict unsigned *restrict intr, unsigned
>          *restrict ctxt, unsigned int *restrict running, unsigned int
>          *restrict blocked, unsigned int *restrict btime, unsigned int
>          *restrict processes)
>
>  API is not uniform ("esprit de corps") and many others things which
>  looks really ugly.

That function illustrates the problem nicely. It didn't always have
so many parameters. Perhaps some day it will use a struct, but
that would make no difference whatsoever. Every time a new data
item gets added, yet another implementation would need to be
created. Probably the old ABI versions would be wrappers around
the latest ABI.

So then, in time, we get 15 different versions of that function.
Having multiple versions is gross. Worse yet, there isn't any
documented and/or legitimate way to eliminate the old versions.
Symbol versioning nests, or at least it does in all documentation.
The latest version thus requires all older versions.

> > old interfaces gradually and drop them one by one. If you know of
> > a low-bloat high-performance way to make things work, tell me.
>
>  I think the best docs about shared libs:
>
>     http://people.redhat.com/drepper/dsohowto.pdf

Of course I read that. It's very sad that that is the best
documentation to be found. Really, it's dreadful.

It doesn't really deal with the practical problems of
maintaining an ABI in the face of volatile requirements.

Also, what if my ABI contains a struct defined by glibc?
The glibc maintainers could change the struct. This is
outside of my control, and may thus break any versioning
that I may do. Even binutils can do this; the GNU hash
stuff in Fedora Core 6 is a perfect example.

There is something far worse than not having a stable ABI.
There is PRETENDING to have a stable ABI, or IMAGINING
that there is a stable ABI.

BTW, any such ABI would need regression tests.