Re: Bug#109182: Removing more historical cruft
On Sat, Aug 18, 2001 at 10:38:49PM -0300, Cesar Eduardo Barros uttered: There are a number of binaries which should go into /bin instead of /sbin or /usr/sbin -- the full argument is at http://lists.debian.org/debian-devel/2001/debian-devel-200106/msg00878.html ARGHHH! We've been through this, _ad nausem_. And because the Maintainer doesn't want to change it, someone thought Well, bugger me, I'll force it with Policy. Not Smart.[tm] I have only one thing to add to that list: traceroute should be moved, _not_ to /usr/bin as lots of people claim, but to /bin . It's as necessary and useful as ping to diagnose networking trouble, and /usr might be mounted via NFS through a gateway -- exactly what we want to diagnose. Same for the ipv6 versions of ping and traceroute. No, traceroute should be in /usr/bin. Read the FHS descriptions for /bin, and /usr/bin. traceroute fits the latter. For a counter-argument, look at http://lists.debian.org/debian-devel/2001/debian-devel-200106/msg00945.html (which says only traceroute belongs to bin and not other tools like ifconfig). *sigh* Been there, done that. -- Steve Synthetic Transforming Entity Viable for Exploration and Nocturnal Killing pgpFoct0nNslK.pgp Description: PGP signature
Bug#109182: Removing more historical cruft
On Sat, Aug 18, 2001 at 10:38:49PM -0300, Cesar Eduardo Barros wrote: I have only one thing to add to that list: traceroute should be moved, _not_ to /usr/bin as lots of people claim, but to /bin . It's as necessary and useful as ping to diagnose networking trouble, and /usr might be mounted via NFS through a gateway -- exactly what we want to diagnose. Same for the ipv6 versions of ping and traceroute. I'm sure Herbert Xu would sooner die than do this. Millions of people throughout history have given up their lives (and those of others) in the name of their irrational religions; I don't think we can expect human nature to change now. Still, I wouldn't dream of discouraging you from trying. Even the Catholic Church came around to the notion that Earth goes around the Sun, a few hundred years after burning Giordano Bruno at the stake for espousing the same notion. -- G. Branden Robinson|Men use thought only to justify Debian GNU/Linux |their wrong doings, and speech only [EMAIL PROTECTED] |to conceal their thoughts. http://people.debian.org/~branden/ |-- Voltaire pgpdEI19F3ojv.pgp Description: PGP signature
Bug#109182: Removing more historical cruft
On Sat, Aug 18, 2001 at 10:38:49PM -0300, Cesar Eduardo Barros wrote: I have only one thing to add to that list: traceroute should be moved, _not_ to /usr/bin as lots of people claim, but to /bin . It's as necessary and useful as ping to diagnose networking trouble, and /usr might be mounted via NFS through a gateway -- exactly what we want to diagnose. Same for the ipv6 versions of ping and traceroute. In that case, you'd use ping ga.te.wa.y to check if the gateway's up, and ping nfs.se.rv.er to check if your NFS server is up. If either wasn't up, you'd call networking support, and find out what's going on, since you'd be rather insane to mount /usr from somewhere remote that you don't have control over. Moving traceroute at all has the same problems no matter where it's too, anyway. /sbin is no either than /bin or /usr/bin. ping6 is already in /bin, btw. This isn't a policy matter anyway: it only affects one package (traceroute), so it's something to take up with the maintainer. Personally, I wouldn't, since I don't think the above adds anything particularly profound to the debate. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpPL5eR4yFUw.pgp Description: PGP signature
Bug#108416: Format of short description should be mandated
On Sat, Aug 18, 2001 at 11:05:59PM -0400, Joey Hess wrote: I guess it says something for policy not needing to be used as a stick; a mere 'should' has clearly sufficed. Well, if I downgrade my must not's to should not's, would you second the proposal? -- G. Branden Robinson|It was a typical net.exercise -- a Debian GNU/Linux |screaming mob pounding on a greasy [EMAIL PROTECTED] |spot on the pavement, where used to http://people.debian.org/~branden/ |lie the carcass of a dead horse. pgpJtqUY0qqpi.pgp Description: PGP signature
Bug#109171: Use Maildir format by default
On Sat, Aug 18, 2001 at 08:36:05PM -0300, Cesar Eduardo Barros wrote: Package: debian-policy Version: 3.5.6.0 Severity: wishlist Debian uses the traditional mailbox style by default. However, it has some disadvantages over maildir -- one of them is that it does a non-reversible modification to the message's text if it contains the sequence 'From ' at the beginning of a line. MUAs like mutt also save the user's mail folders in the same problematic format. well, FWIW, one of the first actions I do on newly installed debian systems is to change mail delivery to maildirs My proposal is to: 1. Use the maildir format by default for storage of the user's incoming mail. This means both the MTA must be configured for maildir by default (e.g. in eximconfig) and all the MUAs must be able to grok it without needing any manual configuration elm (so far still very popular) does not work with maildirs. 2. Use the maildir format to store the user folders by default if the user's MUA allows it The issues are: - Debian is about choice. So, of course mailbox vs maildir will end up being a configuration question. Just make maildir the default, please. does not matter much when it is a configuration question :-) - Standards for where to put the user's incoming mail/where in $HOME to put the folders. I believe most programs which use maildir already share common places, but putting them in policy would be good. - Making programs which can't use it yet be able to use it - Somehow making programs able to guess which is the mbox/mdir choice of the day (perhaps using debconf). environmental variable MAIL - Dealing with indecise people who change the default while the system is live that's the biggest problem. Changing the setup on live system is not trivial to automatize. I would just go for exim postinst configuration question, and if somebody wants to switch his system over, he can do it manually -- --- | Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ | | __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Bug#109171: Use Maildir format by default
On Aug 19, Cesar Eduardo Barros [EMAIL PROTECTED] wrote: eximconfig) and all the MUAs must be able to grok it without needing any manual configuration Are you offering to be the one which will patch everything and make the upstream maintainers merge maildir support? And don't forget POP servers too. - Debian is about choice. So, of course mailbox vs maildir will end up being a configuration question. Just make maildir the default, please. No fucking way. - Standards for where to put the user's incoming mail/where in $HOME to put the folders. I believe most programs which use maildir already share common places, but putting them in policy would be good. Looks like a good idea. - Making programs which can't use it yet be able to use it You can do this even without changing policy, you just have to start coding. 2. Benchmarking mbox versus maildir http://www.courier-mta.org/mbox-vs-maildir/ This has to be a joke. Everybody who knows something about mail servers can tell UW-* programs suck. The benchmark only confirms this, not that maildir is faster (it usually is not, and it definitely is not for tipical POP servers). It also does not discuss the effects of caching in real life. insert standard Debian should take the lead, look at the xterm backspace mess and how well Debian handled it, etc Debian should make sensible decisions about use of available technology. The reality is that maildir is only useful on some setups with remote mounted mailboxes and broken NFS locking. -- ciao, Marco
Bug#109171: Use Maildir format by default
In article [EMAIL PROTECTED], Marco d'Itri [EMAIL PROTECTED] wrote: 2. Benchmarking mbox versus maildir http://www.courier-mta.org/mbox-vs-maildir/ This has to be a joke. Everybody who knows something about mail servers can tell UW-* programs suck. The benchmark only confirms this, not that maildir is faster True. (it usually is not, and it definitely is not for tipical POP servers). Still, deleting messages from a mbox-style mailbox means copying the entire mailbox usually at least twice. That can cause a heavy load on your mailserver. Also it is nessecary to scan the entire mbox at startup - readdir() is usually faster (if you skip the stat()) Debian should make sensible decisions about use of available technology. The reality is that maildir is only useful on some setups with remote mounted mailboxes and broken NFS locking. There certainly are mailbox formats that are better than maildir, but IMHO unix-style mbox files isn't one of them. Mike.
Bug#109171: Use Maildir format by default
On Sun, Aug 19, 2001 at 12:51:05PM +, Miquel van Smoorenburg wrote: (it usually is not, and it definitely is not for tipical POP servers). Still, deleting messages from a mbox-style mailbox means copying the entire mailbox usually at least twice. Copying it once and renaming it, surely? Maildir is also a good way to go if you want to have mail shared across two machines that aren't always connected. (Using unison.deb or similar, eg) Debian should make sensible decisions about use of available technology. The reality is that maildir is only useful on some setups with remote mounted mailboxes and broken NFS locking. There certainly are mailbox formats that are better than maildir, but IMHO unix-style mbox files isn't one of them. There are? Any pointers? Cheers, aj, who doesn't really think there's much value in changing the default mailbox format for Debian -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpBHozvefJs2.pgp Description: PGP signature
Bug#109171: Use Maildir format by default
On Sun, Aug 19, 2001 at 01:32:12PM +0200, Marco d'Itri wrote: and broken NFS locking. Is there any other kind? -- G. Branden Robinson| When dogma enters the brain, all Debian GNU/Linux | intellectual activity ceases. [EMAIL PROTECTED] | -- Robert Anton Wilson http://people.debian.org/~branden/ | pgp8LQzkYx7qZ.pgp Description: PGP signature
Bug#109171: Use Maildir format by default
On Sat, Aug 18, 2001 at 08:36:05PM -0300, Cesar Eduardo Barros wrote: Debian uses the traditional mailbox style by default. However, it has some disadvantages over maildir -- one of them is that it does a non-reversible modification to the message's text if it contains the sequence 'From ' at the beginning of a line. MUAs like mutt also save the user's mail folders in the same problematic format. I'm interested in performance differences. A big flaw of the mbox format is that every byte of the file must be read to extract headers of the messages .. i.e. display a list of the messages without necessarily showing any data. Does maildir employ a summarization technique or must an MUA open every single file to extract the mailbox headers?
Bug#109171: Use Maildir format by default
On Sun, Aug 19, 2001 at 08:31:58AM -0700, Aaron Lehmann wrote: On Sat, Aug 18, 2001 at 08:36:05PM -0300, Cesar Eduardo Barros wrote: Debian uses the traditional mailbox style by default. However, it has some disadvantages over maildir -- one of them is that it does a non-reversible modification to the message's text if it contains the sequence 'From ' at the beginning of a line. MUAs like mutt also save the user's mail folders in the same problematic format. I'm interested in performance differences. A big flaw of the mbox format is that every byte of the file must be read to extract headers of the messages .. i.e. display a list of the messages without necessarily showing any data. Does maildir employ a summarization technique or must an MUA open every single file to extract the mailbox headers? See the second reference I gave in the original message... -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED]
Bug#109182: Removing more historical cruft
On Sun, Aug 19, 2001 at 02:52:37PM +1000, Anthony Towns wrote: On Sat, Aug 18, 2001 at 10:38:49PM -0300, Cesar Eduardo Barros wrote: I have only one thing to add to that list: traceroute should be moved, _not_ to /usr/bin as lots of people claim, but to /bin . It's as necessary and useful as ping to diagnose networking trouble, and /usr might be mounted via NFS through a gateway -- exactly what we want to diagnose. Same for the ipv6 versions of ping and traceroute. In that case, you'd use ping ga.te.wa.y to check if the gateway's up, and ping nfs.se.rv.er to check if your NFS server is up. If either wasn't up, you'd call networking support, and find out what's going on, since you'd be rather insane to mount /usr from somewhere remote that you don't have control over. Moving traceroute at all has the same problems no matter where it's too, anyway. /sbin is no either than /bin or /usr/bin. ping6 is already in /bin, btw. This isn't a policy matter anyway: it only affects one package (traceroute), so it's something to take up with the maintainer. Personally, I wouldn't, since I don't think the above adds anything particularly profound to the debate. This proposal was not about traceroute. It was about everything else (ifconfig, route, mke2fs, e2fsck, etc -- everything a normal user runs and yet are at sbin). The traceroute thing was just a footnote. -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED]
Bug#109171: Use Maildir format by default
On Sun, Aug 19, 2001 at 02:17:40PM -0300, Cesar Eduardo Barros wrote: See the second reference I gave in the original message... That tells us that UW-imap sucks. And that's not news.
Bug#109182: Removing more historical cruft
Previously Cesar Eduardo Barros wrote: This proposal was not about traceroute. It was about everything else (ifconfig, route, mke2fs, e2fsck, etc -- everything a normal user runs and yet are at sbin). The traceroute thing was just a footnote. A normal user who runs ifconfig, route or mkfs? That's about as likely as the pope suddenly switching to budaism. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#109171: Use Maildir format by default
On Aug 19, Miquel van Smoorenburg [EMAIL PROTECTED] wrote: (it usually is not, and it definitely is not for tipical POP servers). Still, deleting messages from a mbox-style mailbox means copying the entire mailbox usually at least twice. That can cause a heavy A tipical POP user downloads and deletes all messages every time. load on your mailserver. Also it is nessecary to scan the entire mbox at startup - readdir() is usually faster (if you skip the stat()) In my experience mutt is faster using mbox than maildir on my 300-500 KB inbox. -- ciao, Marco
Bug#108416: Format of short description should be mandated
On Sat, Aug 18, 2001 at 11:06:36PM -0500, Branden Robinson wrote: Well, if I downgrade my must not's to should not's, would you second the proposal? That wasn't addressed to me, but my reaction is the same as it was to the original proposal: this doesn't belong in policy. It belongs in dev-ref or the packaging manual, or some similar set of guidelines for maintainers. Policy is not required to file bugs (minor for typos, wishlist for unaestheticness) against package descriptions. All it does is allow severity escalation. Having some guidelines somewhere would be good, because it would allow us to move towards the goal of greater consistency. But I still say that policy is not the place for such guidelines. That said, here are some specific comments on details of Branden's proposal: * typically be written in a form that completes the following sentence: foo is a package which provides (a/an)... The word typically reveals the flaw here, I think. It should be unless it shouldn't be. This is clearly just a guideline, and not even a firm one, and thus, definitely doesn't belong in policy (even if other parts of the proposal are accepted). * expand acronyms [...] Generally, but not necessarily always, a good idea. IMO. I'd like to see this as a guideline. I do not want to see it made policy. Counter-example: a package named httpd shouldn't necessarily have to exand Hyper Text Transfer Protocol Daemon in the one-liner. We know. And sometimes the expansion of an acronym is a humorous afterthought: Little Instructive New Unixlike Xystem :-) * not attempt to explain or describe things to the user that he or she would most likely already know if he or she wanted to install it (For instance, most people who care anything about python or perl packages know that these are scripting languages [...] Here I strongly disagree. I think the one line description should be targetted at people who _don't_ have any idea what the package is. [should not] repeat the package name [...] Hmm, if any part of this proposal belongs in policy, it's this. But I still think a guideline is sufficient. [should not] refer to the names of other packages, protocols, [etc.] in their canonical forms. A) I think this is backwards (typo, no doubt), and B) doesn't deserve to be more than a guideline. (Plus, I loathe l33t mixed-case names like PostScript and NeXT, and I don't care if it's canonical or not!) Furthermore, what about things like MUA? Arguable a canonical form, but I don't think it belongs in a short description. [should not] use indefinite articles where not necessary. Yuck. I'm not even sure this belongs in guidelines. [should not] use abbreviations Piffle! I'm not going to spell out etcetera. [must not] be identical to the short description of another package. I think that _related_ packages should not have identical short descriptions (e.g. gcc, xemacs), but if two unrelated packages end up with identical short descriptions, I'm not sure it'll kill us. (e.g. graphical mail reader using GTK+ toolkit.) [must not] be longer than 80 chars. Finally something I agree with! :-) cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#109182: Removing more historical cruft
On Sun, Aug 19, 2001 at 02:15:40PM -0300, Cesar Eduardo Barros wrote: This proposal was not about traceroute. It was about everything else Oh yes, very tricky. This subterfuge had us all fooled. Bah! -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#109182: marked as done (Removing more historical cruft)
Your message dated Sun, 19 Aug 2001 16:57:51 -0300 with message-id [EMAIL PROTECTED] and subject line I give up has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Darren Benham (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 19 Aug 2001 01:39:20 + From [EMAIL PROTECTED] Sat Aug 18 20:39:20 2001 Return-path: [EMAIL PROTECTED] Received: from itaipu.nitnet.com.br [200.255.111.241] by master.debian.org with smtp (Exim 3.12 1 (Debian)) id 15YHYb-Bo-00; Sat, 18 Aug 2001 20:39:18 -0500 Received: (qmail 3684 invoked from network); 19 Aug 2001 01:50:24 - Received: from salzburg.nitnet.com.br (HELO flower.cesarb) (200.198.84.62) by itaipu.nitnet.com.br with SMTP; 19 Aug 2001 01:50:24 - Received: from cesarb by flower.cesarb with local (Exim 3.31 #1 (Debian)) id 15YHY9-0001Q8-00; Sat, 18 Aug 2001 22:38:49 -0300 From: Cesar Eduardo Barros [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: Removing more historical cruft X-Reportbug-Version: 1.23 X-Mailer: reportbug 1.23 Date: Sat, 18 Aug 2001 22:38:49 -0300 Message-Id: [EMAIL PROTECTED] Sender: Cesar Eduardo Barros [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Package: debian-policy Version: 3.5.6.0 Severity: wishlist Some time ago (ok, a lot of time ago), lots of things were changed in the filesystem (I can particulary recall the gradual phasing-out and elimination of /usr/tmp and /var/adm). Now I think it's time to go on and move some more things. There are a number of binaries which should go into /bin instead of /sbin or /usr/sbin -- the full argument is at http://lists.debian.org/debian-devel/2001/debian-devel-200106/msg00878.html I have only one thing to add to that list: traceroute should be moved, _not_ to /usr/bin as lots of people claim, but to /bin . It's as necessary and useful as ping to diagnose networking trouble, and /usr might be mounted via NFS through a gateway -- exactly what we want to diagnose. Same for the ipv6 versions of ping and traceroute. For a counter-argument, look at http://lists.debian.org/debian-devel/2001/debian-devel-200106/msg00945.html (which says only traceroute belongs to bin and not other tools like ifconfig). To do it, the only needed things would be a small amount of relative symlinks. After some releases (in Debian time, this means some years), most of the symlinks would go away. Much like /usr/tmp and /var/adm. If this is rejected, I still think that at least traceroute should be moved out of /usr (whether it's /bin or /sbin doesn't matter much when the network is down and /usr is NFS-mounted). -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux flower 2.4.7 #1 Sat Jul 21 20:57:24 BRT 2001 i686 Locale: LANG=en_US.ISO8859-1, LC_CTYPE=en_US.ISO8859-1 Versions of packages debian-policy depends on: ii fileutils 4.1-2 GNU file management utilities. --- Received: (at 109182-close) by bugs.debian.org; 19 Aug 2001 19:58:16 + From [EMAIL PROTECTED] Sun Aug 19 14:58:16 2001 Return-path: [EMAIL PROTECTED] Received: from itaipu.nitnet.com.br [200.255.111.241] by master.debian.org with smtp (Exim 3.12 1 (Debian)) id 15YYi4-0002ho-00; Sun, 19 Aug 2001 14:58:14 -0500 Received: (qmail 17863 invoked from network); 19 Aug 2001 20:09:31 - Received: from salzburg.nitnet.com.br (HELO flower.cesarb) (200.198.84.62) by itaipu.nitnet.com.br with SMTP; 19 Aug 2001 20:09:31 - Received: from cesarb by flower.cesarb with local (Exim 3.31 #1 (Debian)) id 15YYhk-Yd-00 for [EMAIL PROTECTED]; Sun, 19 Aug 2001 16:57:52 -0300 Date: Sun, 19 Aug 2001 16:57:51 -0300 To: [EMAIL PROTECTED] Subject: I give up Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i From: Cesar Eduardo Barros [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] I filed this bug expecting a rational discussion about the moving of other things to /bin (I already gave up on traceroute), like mke2fs (no, there's no real reason why a normal user would want to create a disk image... Even if he has write access to /dev/fd0 and could use dd to write it there... He also can't run UML, so he really has no use for it...). I'm closing this bug to prevent another flamewar like the last one in debian-devel. -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED]
Bug#109182: Removing more historical cruft
A normal user who runs ifconfig, route or mkfs? That's about as likely as the pope suddenly switching to budaism. Is the pope running the Hurd? pgprjM8RHRSLS.pgp Description: PGP signature
Bug#109171: Use Maildir format by default
According to Anthony Towns: On Sun, Aug 19, 2001 at 12:51:05PM +, Miquel van Smoorenburg wrote: (it usually is not, and it definitely is not for tipical POP servers). Still, deleting messages from a mbox-style mailbox means copying the entire mailbox usually at least twice. Copying it once and renaming it, surely? Depends. If you have a quota of 10 MB on /var/spool/mail, you want the temporary copy to be somewhere else, so that means copying back forth between /tmp (or /var/spool/pop, which qpopper uses) and /var/spool/mail. Yes it's those little details that bite you in the end .. Debian should make sensible decisions about use of available technology. The reality is that maildir is only useful on some setups with remote mounted mailboxes and broken NFS locking. There certainly are mailbox formats that are better than maildir, but IMHO unix-style mbox files isn't one of them. There are? Any pointers? mbx isn't too bad - it's like mbox but with an extra index file. Cyrus imap uses a maildir style setup with one file per message but also with an index file so that it doesn't need to scan every message to get the headers or the MIME structure. Both aren't generic (though I think that mutt, exim and pine all support mbx natively) but it shows that better alternatives do exist. MIke.
Bug#109182: Removing more historical cruft
Wichert Akkerman [EMAIL PROTECTED] writes: A normal user who runs ifconfig, route or mkfs? That's about as likely as the pope suddenly switching to budaism. Since the first two's default behaviour is to *query*, and since no special privileges are needed in order to get a reply back, it's not *that* unlikely. Even if the information is readly available elsewhere, those two programs are just handy query tools from a regular user's POV. With one simple command a regular user can find how many interfaces, their type, their status, their capabilities, to some extent their trustworthyness[0] and their load (the fsck, why is this network so slow today?). mkfs is unlikely but not unthinkable, but it depends largely on local policy. Is there a vacancy at the Vatican now? [0] Sorry, I can't recall the proper English word PS: FWIW, before you bring up the edit your PATH argument, I *hate* having /sbin and cousins on my path as they are supposed to contain programs I can't use on non-privileged accounts and I hate writing aliases for the ones that are there but I can use to some extent. But the horse is dead, Jim. -- Marcelo | One day a tortoise will learn how to fly. [EMAIL PROTECTED] | -- (Terry Pratchett, Small Gods)
