* kill (was: Re: util-linux: orphan)
From: Karel Zak @ 2006-12-20 8:57 UTC (permalink / raw)
To: Albert Cahalan; +Cc: List util-linux-ng
In-Reply-To: <787b0d920612192242x3788f4bfh3be846d4188e3767@mail.gmail.com>
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>
^ permalink raw reply
* Re: kill
From: Pádraig Brady @ 2006-12-20 10:03 UTC (permalink / raw)
To: Karel Zak; +Cc: Albert Cahalan, List util-linux-ng, Alfred M. Szmidt, Evan Hunt
In-Reply-To: <20061220085706.GH5971@petra.dvoda.cz>
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.
^ permalink raw reply
* Re: kill
From: Karel Zak @ 2006-12-20 10:45 UTC (permalink / raw)
To: Pádraig Brady
Cc: Albert Cahalan, List util-linux-ng, Alfred M. Szmidt, Evan Hunt
In-Reply-To: <45890A78.1030105@draigBrady.com>
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>
^ permalink raw reply
* Re: kill
From: Ian Kent @ 2006-12-20 15:00 UTC (permalink / raw)
To: Pádraig Brady
Cc: Karel Zak, Albert Cahalan, List util-linux-ng, Alfred M. Szmidt,
Evan Hunt
In-Reply-To: <45890A78.1030105@draigBrady.com>
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
^ permalink raw reply
* Re: kill (was: Re: util-linux: orphan)
From: Albert Cahalan @ 2006-12-20 16:33 UTC (permalink / raw)
To: Karel Zak; +Cc: List util-linux-ng
In-Reply-To: <20061220085706.GH5971@petra.dvoda.cz>
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)
^ permalink raw reply
* Re: kill
From: Albert Cahalan @ 2006-12-20 16:58 UTC (permalink / raw)
To: Pádraig Brady
Cc: Karel Zak, List util-linux-ng, Alfred M. Szmidt, Evan Hunt
In-Reply-To: <45890A78.1030105@draigBrady.com>
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.
^ permalink raw reply
* Re: kill (was: Re: util-linux: orphan)
From: Karel Zak @ 2006-12-20 21:12 UTC (permalink / raw)
To: Albert Cahalan; +Cc: List util-linux-ng
In-Reply-To: <787b0d920612200833h38cd9023ufb1ebba87d4b36ec@mail.gmail.com>
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>
^ permalink raw reply
* Re: kill
From: Alfred M. Szmidt @ 2006-12-20 21:45 UTC (permalink / raw)
To: Karel Zak; +Cc: P, acahalan, util-linux-ng, ethanol
In-Reply-To: <20061220104547.GJ5971@petra.dvoda.cz>
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.
^ permalink raw reply
* Re: kill
From: Karel Zak @ 2006-12-20 23:55 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: P, acahalan, util-linux-ng, ethanol
In-Reply-To: <20061220214503.0BB4744007@Psilocybe.Update.UU.SE>
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>
^ permalink raw reply
* Re: kill (was: Re: util-linux: orphan)
From: Albert Cahalan @ 2006-12-21 2:32 UTC (permalink / raw)
To: Karel Zak; +Cc: List util-linux-ng
In-Reply-To: <20061220211224.GL5971@petra.dvoda.cz>
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.
^ permalink raw reply
* Re: kill
From: Evan Hunt @ 2006-12-21 4:10 UTC (permalink / raw)
To: Karel Zak; +Cc: Alfred M. Szmidt, P, acahalan, util-linux-ng
In-Reply-To: <20061220235519.GN5971@petra.dvoda.cz>
> 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
^ permalink raw reply
* Re: kill
From: Alfred M. Szmidt @ 2006-12-21 10:51 UTC (permalink / raw)
To: Karel Zak; +Cc: P, acahalan, util-linux-ng, ethanol
In-Reply-To: <20061220235519.GN5971@petra.dvoda.cz>
> 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.
^ permalink raw reply
* Re: kill
From: Martin Mares @ 2006-12-21 11:39 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: Karel Zak, P, acahalan, util-linux-ng, ethanol
In-Reply-To: <20061221105142.5DD9C4401E@Psilocybe.Update.UU.SE>
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.
^ permalink raw reply
* Re: kill
From: Karel Zak @ 2006-12-21 15:30 UTC (permalink / raw)
To: Martin Mares; +Cc: Alfred M. Szmidt, P, acahalan, util-linux-ng, ethanol
In-Reply-To: <mj+md-20061221.113626.23750.camellia@ucw.cz>
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>
^ permalink raw reply
* Re: kill
From: Alfred M. Szmidt @ 2006-12-21 16:50 UTC (permalink / raw)
To: Martin Mares; +Cc: kzak, P, acahalan, util-linux-ng, ethanol
In-Reply-To: <mj+md-20061221.113626.23750.camellia@ucw.cz>
> 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.
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Bryan Henderson @ 2006-12-21 16:34 UTC (permalink / raw)
To: ethanol; +Cc: kzak, ams, P, acahalan, util-linux-ng
In-Reply-To: <20061221041033.GB13134@armory.com>
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
^ permalink raw reply
* Re: kill
From: Albert Cahalan @ 2006-12-21 17:38 UTC (permalink / raw)
To: ams; +Cc: Martin Mares, kzak, P, util-linux-ng, ethanol
In-Reply-To: <20061221165003.EA7944400C@Psilocybe.Update.UU.SE>
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.
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Karel Zak @ 2006-12-21 21:53 UTC (permalink / raw)
To: Bryan Henderson; +Cc: ethanol, ams, P, acahalan, util-linux-ng
In-Reply-To: <80765.bryanh@giraffe-data.com>
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>
^ permalink raw reply
* Re: kill
From: Ian Kent @ 2006-12-22 1:37 UTC (permalink / raw)
To: ams; +Cc: Martin Mares, kzak, P, acahalan, util-linux-ng, ethanol
In-Reply-To: <20061221165003.EA7944400C@Psilocybe.Update.UU.SE>
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
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Albert Cahalan @ 2006-12-22 6:12 UTC (permalink / raw)
To: Karel Zak; +Cc: Bryan Henderson, ethanol, ams, P, util-linux-ng
In-Reply-To: <20061221215312.GP5971@petra.dvoda.cz>
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.
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Bryan Henderson @ 2006-12-22 6:44 UTC (permalink / raw)
To: kzak; +Cc: ethanol, ams, P, acahalan, util-linux-ng
In-Reply-To: <20061221215312.GP5971@petra.dvoda.cz>
> 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
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Bryan Henderson @ 2006-12-22 7:13 UTC (permalink / raw)
To: acahalan; +Cc: kzak, ethanol, ams, P, util-linux-ng
In-Reply-To: <787b0d920612212212s1ca3179jf037fc71f3f28498@mail.gmail.com>
>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
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Bryan Henderson @ 2006-12-22 7:23 UTC (permalink / raw)
To: acahalan; +Cc: kzak, ethanol, ams, P, util-linux-ng
In-Reply-To: <787b0d920612212212s1ca3179jf037fc71f3f28498@mail.gmail.com>
>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
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Evan Hunt @ 2006-12-22 7:45 UTC (permalink / raw)
To: Albert Cahalan; +Cc: Karel Zak, Bryan Henderson, ams, P, util-linux-ng
In-Reply-To: <787b0d920612212212s1ca3179jf037fc71f3f28498@mail.gmail.com>
> 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
^ permalink raw reply
* Re: splitting util-linux (was: kill)
From: Karel Zak @ 2006-12-22 7:52 UTC (permalink / raw)
To: Bryan Henderson; +Cc: ethanol, ams, P, acahalan, util-linux-ng
In-Reply-To: <42767.bryanh@giraffe-data.com>
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>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox