* kill (was: Re: util-linux: orphan) [not found] <787b0d920612192242x3788f4bfh3be846d4188e3767@mail.gmail.com> @ 2006-12-20 8:57 ` Karel Zak 2006-12-20 10:03 ` kill Pádraig Brady 2006-12-20 16:33 ` kill (was: Re: util-linux: orphan) Albert Cahalan 0 siblings, 2 replies; 36+ messages in thread From: Karel Zak @ 2006-12-20 8:57 UTC (permalink / raw) To: Albert Cahalan; +Cc: List util-linux-ng 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-20 8:57 ` kill (was: Re: util-linux: orphan) Karel Zak @ 2006-12-20 10:03 ` Pádraig Brady 2006-12-20 10:45 ` kill Karel Zak ` (2 more replies) 2006-12-20 16:33 ` kill (was: Re: util-linux: orphan) Albert Cahalan 1 sibling, 3 replies; 36+ messages in thread 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 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-20 10:03 ` kill Pádraig Brady @ 2006-12-20 10:45 ` Karel Zak 2006-12-20 21:45 ` kill Alfred M. Szmidt 2006-12-20 15:00 ` kill Ian Kent 2006-12-20 16:58 ` kill Albert Cahalan 2 siblings, 1 reply; 36+ messages in thread 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 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-20 10:45 ` kill Karel Zak @ 2006-12-20 21:45 ` Alfred M. Szmidt 2006-12-20 23:55 ` kill Karel Zak 0 siblings, 1 reply; 36+ messages in thread From: Alfred M. Szmidt @ 2006-12-20 21:45 UTC (permalink / raw) To: Karel Zak; +Cc: P, acahalan, util-linux-ng, ethanol 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-20 21:45 ` kill Alfred M. Szmidt @ 2006-12-20 23:55 ` Karel Zak 2006-12-21 4:10 ` kill Evan Hunt 2006-12-21 10:51 ` kill Alfred M. Szmidt 0 siblings, 2 replies; 36+ messages in thread From: Karel Zak @ 2006-12-20 23:55 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: P, acahalan, util-linux-ng, ethanol 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-20 23:55 ` kill Karel Zak @ 2006-12-21 4:10 ` Evan Hunt 2006-12-21 16:34 ` splitting util-linux (was: kill) Bryan Henderson 2006-12-21 10:51 ` kill Alfred M. Szmidt 1 sibling, 1 reply; 36+ messages in thread From: Evan Hunt @ 2006-12-21 4:10 UTC (permalink / raw) To: Karel Zak; +Cc: Alfred M. Szmidt, P, acahalan, util-linux-ng > 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 [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-21 4:10 ` kill Evan Hunt @ 2006-12-21 16:34 ` Bryan Henderson 2006-12-21 21:53 ` Karel Zak 0 siblings, 1 reply; 36+ messages in thread From: Bryan Henderson @ 2006-12-21 16:34 UTC (permalink / raw) To: ethanol; +Cc: kzak, ams, P, acahalan, util-linux-ng 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 [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-21 16:34 ` splitting util-linux (was: kill) Bryan Henderson @ 2006-12-21 21:53 ` Karel Zak 2006-12-22 6:12 ` Albert Cahalan 2006-12-22 6:44 ` Bryan Henderson 0 siblings, 2 replies; 36+ messages in thread From: Karel Zak @ 2006-12-21 21:53 UTC (permalink / raw) To: Bryan Henderson; +Cc: ethanol, ams, P, acahalan, util-linux-ng 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 [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-21 21:53 ` Karel Zak @ 2006-12-22 6:12 ` Albert Cahalan 2006-12-22 7:13 ` Bryan Henderson ` (3 more replies) 2006-12-22 6:44 ` Bryan Henderson 1 sibling, 4 replies; 36+ messages in thread From: Albert Cahalan @ 2006-12-22 6:12 UTC (permalink / raw) To: Karel Zak; +Cc: Bryan Henderson, ethanol, ams, P, util-linux-ng 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 [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 6:12 ` Albert Cahalan @ 2006-12-22 7:13 ` Bryan Henderson 2006-12-22 9:06 ` Albert Cahalan 2006-12-22 7:23 ` Bryan Henderson ` (2 subsequent siblings) 3 siblings, 1 reply; 36+ messages in thread From: Bryan Henderson @ 2006-12-22 7:13 UTC (permalink / raw) To: acahalan; +Cc: kzak, ethanol, ams, P, util-linux-ng >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 [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 7:13 ` Bryan Henderson @ 2006-12-22 9:06 ` Albert Cahalan 0 siblings, 0 replies; 36+ messages in thread From: Albert Cahalan @ 2006-12-22 9:06 UTC (permalink / raw) To: Bryan Henderson; +Cc: kzak, ethanol, ams, P, util-linux-ng 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 6:12 ` Albert Cahalan 2006-12-22 7:13 ` Bryan Henderson @ 2006-12-22 7:23 ` Bryan Henderson 2006-12-22 7:45 ` Evan Hunt 2006-12-22 10:24 ` Karel Zak 3 siblings, 0 replies; 36+ messages in thread From: Bryan Henderson @ 2006-12-22 7:23 UTC (permalink / raw) To: acahalan; +Cc: kzak, ethanol, ams, P, util-linux-ng >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 [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 6:12 ` Albert Cahalan 2006-12-22 7:13 ` Bryan Henderson 2006-12-22 7:23 ` Bryan Henderson @ 2006-12-22 7:45 ` Evan Hunt 2006-12-22 8:07 ` Karel Zak 2006-12-22 10:24 ` Karel Zak 3 siblings, 1 reply; 36+ messages in thread From: Evan Hunt @ 2006-12-22 7:45 UTC (permalink / raw) To: Albert Cahalan; +Cc: Karel Zak, Bryan Henderson, ams, P, util-linux-ng > 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 [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 7:45 ` Evan Hunt @ 2006-12-22 8:07 ` Karel Zak 2006-12-22 8:45 ` Evan Hunt 2006-12-22 12:32 ` Ian Kent 0 siblings, 2 replies; 36+ messages in thread From: Karel Zak @ 2006-12-22 8:07 UTC (permalink / raw) To: Evan Hunt; +Cc: Albert Cahalan, Bryan Henderson, ams, P, util-linux-ng 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> ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 8:07 ` Karel Zak @ 2006-12-22 8:45 ` Evan Hunt 2006-12-22 11:03 ` Karel Zak 2006-12-22 12:32 ` Ian Kent 1 sibling, 1 reply; 36+ messages in thread From: Evan Hunt @ 2006-12-22 8:45 UTC (permalink / raw) To: Karel Zak; +Cc: Albert Cahalan, Bryan Henderson, ams, P, util-linux-ng > 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 8:45 ` Evan Hunt @ 2006-12-22 11:03 ` Karel Zak 2006-12-22 16:52 ` Evan Hunt 0 siblings, 1 reply; 36+ messages in thread From: Karel Zak @ 2006-12-22 11:03 UTC (permalink / raw) To: Evan Hunt; +Cc: Albert Cahalan, Bryan Henderson, ams, P, util-linux-ng 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> ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 11:03 ` Karel Zak @ 2006-12-22 16:52 ` Evan Hunt 0 siblings, 0 replies; 36+ messages in thread From: Evan Hunt @ 2006-12-22 16:52 UTC (permalink / raw) To: Karel Zak; +Cc: Albert Cahalan, Bryan Henderson, ams, P, util-linux-ng > 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 8:07 ` Karel Zak 2006-12-22 8:45 ` Evan Hunt @ 2006-12-22 12:32 ` Ian Kent 1 sibling, 0 replies; 36+ messages in thread From: Ian Kent @ 2006-12-22 12:32 UTC (permalink / raw) To: Karel Zak Cc: Evan Hunt, Albert Cahalan, Bryan Henderson, ams, P, util-linux-ng 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 > ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 6:12 ` Albert Cahalan ` (2 preceding siblings ...) 2006-12-22 7:45 ` Evan Hunt @ 2006-12-22 10:24 ` Karel Zak 2006-12-22 14:50 ` Mark Rosenstand ` (2 more replies) 3 siblings, 3 replies; 36+ messages in thread From: Karel Zak @ 2006-12-22 10:24 UTC (permalink / raw) To: Albert Cahalan; +Cc: Bryan Henderson, ethanol, ams, P, util-linux-ng 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> ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 10:24 ` Karel Zak @ 2006-12-22 14:50 ` Mark Rosenstand 2006-12-22 17:38 ` Albert Cahalan 2006-12-25 20:03 ` Albert Cahalan 2 siblings, 0 replies; 36+ messages in thread From: Mark Rosenstand @ 2006-12-22 14:50 UTC (permalink / raw) To: Karel Zak; +Cc: Albert Cahalan, util-linux-ng 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 10:24 ` Karel Zak 2006-12-22 14:50 ` Mark Rosenstand @ 2006-12-22 17:38 ` Albert Cahalan 2006-12-25 20:03 ` Albert Cahalan 2 siblings, 0 replies; 36+ messages in thread From: Albert Cahalan @ 2006-12-22 17:38 UTC (permalink / raw) To: Karel Zak; +Cc: Bryan Henderson, ethanol, ams, P, util-linux-ng 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 10:24 ` Karel Zak 2006-12-22 14:50 ` Mark Rosenstand 2006-12-22 17:38 ` Albert Cahalan @ 2006-12-25 20:03 ` Albert Cahalan 2006-12-25 22:50 ` Bryan Henderson 2 siblings, 1 reply; 36+ messages in thread From: Albert Cahalan @ 2006-12-25 20:03 UTC (permalink / raw) To: Karel Zak; +Cc: Bryan Henderson, ethanol, ams, P, util-linux-ng 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-25 20:03 ` Albert Cahalan @ 2006-12-25 22:50 ` Bryan Henderson 0 siblings, 0 replies; 36+ messages in thread From: Bryan Henderson @ 2006-12-25 22:50 UTC (permalink / raw) To: acahalan; +Cc: kzak, ethanol, ams, P, util-linux-ng >>> > 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-21 21:53 ` Karel Zak 2006-12-22 6:12 ` Albert Cahalan @ 2006-12-22 6:44 ` Bryan Henderson 2006-12-22 7:52 ` Karel Zak 1 sibling, 1 reply; 36+ messages in thread From: Bryan Henderson @ 2006-12-22 6:44 UTC (permalink / raw) To: kzak; +Cc: ethanol, ams, P, acahalan, util-linux-ng > 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 [flat|nested] 36+ messages in thread
* Re: splitting util-linux (was: kill) 2006-12-22 6:44 ` Bryan Henderson @ 2006-12-22 7:52 ` Karel Zak 0 siblings, 0 replies; 36+ messages in thread From: Karel Zak @ 2006-12-22 7:52 UTC (permalink / raw) To: Bryan Henderson; +Cc: ethanol, ams, P, acahalan, util-linux-ng 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-20 23:55 ` kill Karel Zak 2006-12-21 4:10 ` kill Evan Hunt @ 2006-12-21 10:51 ` Alfred M. Szmidt 2006-12-21 11:39 ` kill Martin Mares 1 sibling, 1 reply; 36+ messages in thread From: Alfred M. Szmidt @ 2006-12-21 10:51 UTC (permalink / raw) To: Karel Zak; +Cc: P, acahalan, util-linux-ng, ethanol > 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-21 10:51 ` kill Alfred M. Szmidt @ 2006-12-21 11:39 ` Martin Mares 2006-12-21 15:30 ` kill Karel Zak 2006-12-21 16:50 ` kill Alfred M. Szmidt 0 siblings, 2 replies; 36+ messages in thread From: Martin Mares @ 2006-12-21 11:39 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: Karel Zak, P, acahalan, util-linux-ng, ethanol 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-21 11:39 ` kill Martin Mares @ 2006-12-21 15:30 ` Karel Zak 2006-12-21 16:50 ` kill Alfred M. Szmidt 1 sibling, 0 replies; 36+ messages in thread From: Karel Zak @ 2006-12-21 15:30 UTC (permalink / raw) To: Martin Mares; +Cc: Alfred M. Szmidt, P, acahalan, util-linux-ng, ethanol 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-21 11:39 ` kill Martin Mares 2006-12-21 15:30 ` kill Karel Zak @ 2006-12-21 16:50 ` Alfred M. Szmidt 2006-12-21 17:38 ` kill Albert Cahalan 2006-12-22 1:37 ` kill Ian Kent 1 sibling, 2 replies; 36+ messages in thread From: Alfred M. Szmidt @ 2006-12-21 16:50 UTC (permalink / raw) To: Martin Mares; +Cc: kzak, P, acahalan, util-linux-ng, ethanol > 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-21 16:50 ` kill Alfred M. Szmidt @ 2006-12-21 17:38 ` Albert Cahalan 2006-12-22 1:37 ` kill Ian Kent 1 sibling, 0 replies; 36+ messages in thread From: Albert Cahalan @ 2006-12-21 17:38 UTC (permalink / raw) To: ams; +Cc: Martin Mares, kzak, P, util-linux-ng, ethanol 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-21 16:50 ` kill Alfred M. Szmidt 2006-12-21 17:38 ` kill Albert Cahalan @ 2006-12-22 1:37 ` Ian Kent 1 sibling, 0 replies; 36+ messages in thread From: Ian Kent @ 2006-12-22 1:37 UTC (permalink / raw) To: ams; +Cc: Martin Mares, kzak, P, acahalan, util-linux-ng, ethanol 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-20 10:03 ` kill Pádraig Brady 2006-12-20 10:45 ` kill Karel Zak @ 2006-12-20 15:00 ` Ian Kent 2006-12-20 16:58 ` kill Albert Cahalan 2 siblings, 0 replies; 36+ messages in thread 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 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 [flat|nested] 36+ messages in thread
* Re: kill 2006-12-20 10:03 ` kill Pádraig Brady 2006-12-20 10:45 ` kill Karel Zak 2006-12-20 15:00 ` kill Ian Kent @ 2006-12-20 16:58 ` Albert Cahalan 2 siblings, 0 replies; 36+ messages in thread 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 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 [flat|nested] 36+ messages in thread
* Re: kill (was: Re: util-linux: orphan) 2006-12-20 8:57 ` kill (was: Re: util-linux: orphan) Karel Zak 2006-12-20 10:03 ` kill Pádraig Brady @ 2006-12-20 16:33 ` Albert Cahalan 2006-12-20 21:12 ` Karel Zak 1 sibling, 1 reply; 36+ messages in thread From: Albert Cahalan @ 2006-12-20 16:33 UTC (permalink / raw) To: Karel Zak; +Cc: List util-linux-ng 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 [flat|nested] 36+ messages in thread
* Re: kill (was: Re: util-linux: orphan) 2006-12-20 16:33 ` kill (was: Re: util-linux: orphan) Albert Cahalan @ 2006-12-20 21:12 ` Karel Zak 2006-12-21 2:32 ` Albert Cahalan 0 siblings, 1 reply; 36+ messages in thread From: Karel Zak @ 2006-12-20 21:12 UTC (permalink / raw) To: Albert Cahalan; +Cc: List util-linux-ng 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 [flat|nested] 36+ messages in thread
* Re: kill (was: Re: util-linux: orphan) 2006-12-20 21:12 ` Karel Zak @ 2006-12-21 2:32 ` Albert Cahalan 0 siblings, 0 replies; 36+ messages in thread From: Albert Cahalan @ 2006-12-21 2:32 UTC (permalink / raw) To: Karel Zak; +Cc: List util-linux-ng 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 [flat|nested] 36+ messages in thread
end of thread, other threads:[~2006-12-25 22:58 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <787b0d920612192242x3788f4bfh3be846d4188e3767@mail.gmail.com>
2006-12-20 8:57 ` kill (was: Re: util-linux: orphan) Karel Zak
2006-12-20 10:03 ` kill Pádraig Brady
2006-12-20 10:45 ` kill Karel Zak
2006-12-20 21:45 ` kill Alfred M. Szmidt
2006-12-20 23:55 ` kill Karel Zak
2006-12-21 4:10 ` kill Evan Hunt
2006-12-21 16:34 ` splitting util-linux (was: kill) Bryan Henderson
2006-12-21 21:53 ` Karel Zak
2006-12-22 6:12 ` Albert Cahalan
2006-12-22 7:13 ` Bryan Henderson
2006-12-22 9:06 ` Albert Cahalan
2006-12-22 7:23 ` Bryan Henderson
2006-12-22 7:45 ` Evan Hunt
2006-12-22 8:07 ` Karel Zak
2006-12-22 8:45 ` Evan Hunt
2006-12-22 11:03 ` Karel Zak
2006-12-22 16:52 ` Evan Hunt
2006-12-22 12:32 ` Ian Kent
2006-12-22 10:24 ` Karel Zak
2006-12-22 14:50 ` Mark Rosenstand
2006-12-22 17:38 ` Albert Cahalan
2006-12-25 20:03 ` Albert Cahalan
2006-12-25 22:50 ` Bryan Henderson
2006-12-22 6:44 ` Bryan Henderson
2006-12-22 7:52 ` Karel Zak
2006-12-21 10:51 ` kill Alfred M. Szmidt
2006-12-21 11:39 ` kill Martin Mares
2006-12-21 15:30 ` kill Karel Zak
2006-12-21 16:50 ` kill Alfred M. Szmidt
2006-12-21 17:38 ` kill Albert Cahalan
2006-12-22 1:37 ` kill Ian Kent
2006-12-20 15:00 ` kill Ian Kent
2006-12-20 16:58 ` kill Albert Cahalan
2006-12-20 16:33 ` kill (was: Re: util-linux: orphan) Albert Cahalan
2006-12-20 21:12 ` Karel Zak
2006-12-21 2:32 ` Albert Cahalan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox