Re: Trimming priority:standard
Hi, Le Tue, Sep 23, 2014 at 07:22:11PM +0200, Marco d'Itri a écrit : On Sep 23, Ralf Jung p...@ralfj.de wrote: I've seen multiple machines, including older machines of myself, to be under full disk load for at least several minutes due to (some form of) locate - every time the cronjob runs. The slowdown was noticeable, This is hard to believe, since the cron job uses ionice -c3. I had a similar experience with ‘tracker’, GNOME's equivalent of locate, which also runs under ionice. Unfortunately I can not recall if during the years I used the systems where the slowdown was noticeable I had changed something relevant in the configuration of the hard drive (like running a hdparm command) or if it was pristine. The common thing between these machines was a loud and slow hard drive: I never had this problem with a SSD (but again, on SSD I run more recently installed systems where I am sure that I never used hdparm). Anyway, the point I want to make is that we should trust Ralf when he reports that full disk load slows his machine despite cron jobs using ionice, although this is probably a corner case. Just to clarify, it should be slowed my machine - my current machine has an SSD and no form of locate installed, all this is experience from 2 or more years ago. Since then I made sure that the experience does not repeat ;-) Kind regards Ralf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54228df7.4050...@ralfj.de
Re: Trimming priority:standard
]] Josh Triplett Tollef Fog Heen wrote: ]] Josh Triplett - mlocate. We don't need a locate in standard; anyone who actually uses locate (and wants the very significant overhead of running a locate daemon) can easily install this. There is no «locate daemon» in mlocate. s/daemon/cron job/g Then I disagree with your claim about «very significant overhead». Even on spinning rust, mlocate is pretty quick since it does a good bunch of optimisations to avoid re-indexing unchanged directories. Maybe your perception has been marred by slocate and the original locate, which at least used not to have such optimisations? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnq6hlbp@aexonyam.err.no
Re: Trimming priority:standard
Hi, s/daemon/cron job/g Then I disagree with your claim about «very significant overhead». Even on spinning rust, mlocate is pretty quick since it does a good bunch of optimisations to avoid re-indexing unchanged directories. Maybe your perception has been marred by slocate and the original locate, which at least used not to have such optimisations? I've seen multiple machines, including older machines of myself, to be under full disk load for at least several minutes due to (some form of) locate - every time the cronjob runs. The slowdown was noticeable, whenever locate did it's job, tasks like starting Firefox or listing large directories got significantly slower. If this were done on battery, the remaining runtime would drain much quicker than necessary. Has mlocate already been the default in Squeeze? Maybe there were some improvements during the last year or so - uninstalling (all forms of) locate is pretty much the first thing I do on any Debian machine someone not experienced in Debian puts in front of me (together with exim, nfs, rpcbind). Hence I wouldn't even notice if this improved. Finally, even if mlocate improved the situation significantly, many people installing Debian (if not most of them) will have mlocate installed (if you don't know exactly what you are doing, you *will* select something called standard tools) without ever using it. So even the slightest amount of work it does, is wasted. Kind regards Ralf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54211f01.3070...@ralfj.de
Re: Trimming priority:standard
On Sep 23, Ralf Jung p...@ralfj.de wrote: I've seen multiple machines, including older machines of myself, to be under full disk load for at least several minutes due to (some form of) locate - every time the cronjob runs. The slowdown was noticeable, This is hard to believe, since the cron job uses ionice -c3. -- ciao, Marco signature.asc Description: Digital signature
Re: Trimming priority:standard
Le Tue, Sep 23, 2014 at 07:22:11PM +0200, Marco d'Itri a écrit : On Sep 23, Ralf Jung p...@ralfj.de wrote: I've seen multiple machines, including older machines of myself, to be under full disk load for at least several minutes due to (some form of) locate - every time the cronjob runs. The slowdown was noticeable, This is hard to believe, since the cron job uses ionice -c3. Hi Marco and everybody, I had a similar experience with ‘tracker’, GNOME's equivalent of locate, which also runs under ionice. Unfortunately I can not recall if during the years I used the systems where the slowdown was noticeable I had changed something relevant in the configuration of the hard drive (like running a hdparm command) or if it was pristine. The common thing between these machines was a loud and slow hard drive: I never had this problem with a SSD (but again, on SSD I run more recently installed systems where I am sure that I never used hdparm). Anyway, the point I want to make is that we should trust Ralf when he reports that full disk load slows his machine despite cron jobs using ionice, although this is probably a corner case. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140923223434.ga9...@falafel.plessy.net
Re: Trimming priority:standard
On 17 Sep 2014, at 07:58, Ansgar Burchardt ans...@debian.org wrote: That's why *both* should be installed by default. Then everybody will be happy. To keep the (bad) joke going, I was going to suggest gnu zile be made standard, but even *that* is pretty big. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9281c8a0-c119-4a9e-a2ca-0cb9bc31e...@debian.org
Re: Trimming priority:standard
On 17 Sep 2014, at 08:24, envite env...@rolamasao.org wrote: Having one easy text editor in command line is necessary. Both nano or joe will make that target. None of emacs nor vi does: they are not as easy. I really think *some* vi implementation should be in standard. It's true, those who don't know vi find it unusable, but sadly the reverse is also true. I'd be genuinely shocked (and somewhat hamstrung) to ever log into a Linux machine of any type and not find a vi. Looking at package sizes I'm surprised to see nvi is larger than gnu zile (karma for my previous bad joke). There's also a vi in busybox I believe, similar size. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9898e31e-34d6-48d8-bb21-e2003c2a8...@debian.org
Re: Trimming priority:standard
Noel Torres env...@rolamasao.org writes: On Tuesday, 16 de September de 2014 22:17:51 Joerg Jaspert escribió: On 13698 March 1977, Didier Raboud wrote: One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. Or we could just call it standard system. Could we make sure the full vim is in that then? I miss it on every new installation and I'm quite sure that's not uncommon. ONLY if we put emacs there too, cos I miss that way more than any vi* ever. With vi actually being the first thing to get removed, so that would be better way out of standard *IMO* (*lala*) Trying to start another flamewar? Let's stop this here. There are vi lovers and emacs lovers, and having the freedom to choose is great. That's why *both* should be installed by default. Then everybody will be happy. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/851traivhk@tsukuyomi.43-1.org
Re: Trimming priority:standard
Sorry for top-posting Installing both is a waste of bandwidth (for netinst) and disk space. There are lovers of both, but most desktop users will never see any of the two. Having one easy text editor in command line is necessary. Both nano or joe will make that target. None of emacs nor vi does: they are not as easy. Regards Noel Enviado de Samsung Mobile Mensaje original De: Ansgar Burchardt ans...@debian.org Fecha:17/09/2014 7:58 (GMT+00:00) Para: debian-devel@lists.debian.org Asunto: Re: Trimming priority:standard Noel Torres env...@rolamasao.org writes: On Tuesday, 16 de September de 2014 22:17:51 Joerg Jaspert escribió: On 13698 March 1977, Didier Raboud wrote: One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. Or we could just call it standard system. Could we make sure the full vim is in that then? I miss it on every new installation and I'm quite sure that's not uncommon. ONLY if we put emacs there too, cos I miss that way more than any vi* ever. With vi actually being the first thing to get removed, so that would be better way out of standard *IMO* (*lala*) Trying to start another flamewar? Let's stop this here. There are vi lovers and emacs lovers, and having the freedom to choose is great. That's why *both* should be installed by default. Then everybody will be happy. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/851traivhk@tsukuyomi.43-1.org
Re: Trimming priority:standard
Le mardi, 16 septembre 2014, 23.17:51 Joerg Jaspert a écrit : On 13698 March 1977, Didier Raboud wrote: One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. Or we could just call it standard system. Could we make sure the full vim is in that then? I miss it on every new installation and I'm quite sure that's not uncommon. ONLY if we put emacs there too (…) Apparently I just need to learn to use the 'nocompatible' option for vim, sorry for the noise. OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3592821.OyjbmjOk0H@gyllingar
Re: Trimming priority:standard
Theodore Ts'o writes (Re: Trimming priority:standard): That being said, if there are Debian users who are not Unix-heads, they aren't going to miss any of these. What if we create a tasksel task called Unix that installs these traditional Unix commands from the BSD 4.x era? It would include dc, m4, /usr/dict/words, telnet, etc. This is a good idea. `ed' (my pet peeve) ought to be on the list. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21529.36251.644581.261...@chiark.greenend.org.uk
Re: Trimming priority:standard
On Sep 16, James McCoy james...@debian.org wrote: The very informed/knowledgeable user isn't the one that soured my perception of the choice to have vim-tiny provide /usr/bin/vim. It's Still, as I explained it is very useful since the footprint of the full vim is an order of magnitude bigger. It is not clear to me what you are trying to solve by killing vim-tiny. -- ciao, Marco signature.asc Description: Digital signature
Re: Trimming priority:standard
On Sunday, 14 de September de 2014 17:04:10 Stefano Zacchiroli escribió: On Sat, Sep 13, 2014 at 11:17:34AM -0700, Josh Triplett wrote: I'm not arguing that standard should have nothing in it; it should have things that the vast majority of users will 1) expect to find present without having to install them and 2) actually use or care about. I sympathize with the sentiment, but AFAICT the only way to implement such a specification would be to actually *ask* our users, and (by definition) a thread on -devel cannot work to that end. It seems to me that the only way to implement that spec would be something like a broadly advertised user survey, with specific questions about the packages you are interested in. Cheers. Here it can come back my idea about a desktop survey/poll app. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Trimming priority:standard
On 13698 March 1977, Didier Raboud wrote: One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. Or we could just call it standard system. Could we make sure the full vim is in that then? I miss it on every new installation and I'm quite sure that's not uncommon. ONLY if we put emacs there too, cos I miss that way more than any vi* ever. With vi actually being the first thing to get removed, so that would be better way out of standard *IMO* (*lala*) -- bye, Joerg buxy I wish mrvn stopped supporting 3.0 (quilt), it's a recipe for failure -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ioknxo1s@gkar.ganneff.de
Re: Trimming priority:standard
On Tuesday, 16 de September de 2014 22:17:51 Joerg Jaspert escribió: On 13698 March 1977, Didier Raboud wrote: One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. Or we could just call it standard system. Could we make sure the full vim is in that then? I miss it on every new installation and I'm quite sure that's not uncommon. ONLY if we put emacs there too, cos I miss that way more than any vi* ever. With vi actually being the first thing to get removed, so that would be better way out of standard *IMO* (*lala*) Trying to start another flamewar? Let's stop this here. There are vi lovers and emacs lovers, and having the freedom to choose is great. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: Trimming priority:standard
Tollef Fog Heen wrote: ]] Josh Triplett - mlocate. We don't need a locate in standard; anyone who actually uses locate (and wants the very significant overhead of running a locate daemon) can easily install this. There is no «locate daemon» in mlocate. s/daemon/cron job/g - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140915074646.GA20730@thin
Re: Trimming priority:standard
Am Freitag, den 12.09.2014, 08:59 +0200 schrieb Fabian Greffrath: apt-listchanges aptitude aptitude-common at bash-completion bc dc bind9-host Why is aptitude still in this list? This has not been answered yet?! - Fabian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410775651.31175.11.ca...@greffrath.com
Re: Trimming priority:standard
On Fri, Sep 12, 2014 at 03:44:46AM +0200, Adam Borowski wrote: You want 'nc myserver 25', as 'telnet myserver 25' will misbehave on 0xff bytes. A malicious server can do pretty surprising things to you, too. You're both wrong; you want swaks(1). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140915133648.ga22...@bryant.redmars.org
Re: Trimming priority:standard
On Fri, Sep 12, 2014 at 06:27:38PM +0100, Simon McVittie wrote:
On 12/09/14 18:19, Theodore Ts'o wrote:
One thought... there will probably be trademark concerns with unix.[1]
So we might have to choose a name for the tasksel task to be someting
like unix-like.
Perhaps
task-traditional -- Traditional Unix utilities
I quite like that. My main objection with task 'unix' is it'll be confusing for
users who are not really sure what it is, but think that it must be important.
My less important objection is I have a hobby source package 'unix' which is
the v7 UNIX sources (so far only ed/sed have been made to work on modern
systems; the work was all done by David Jones and not me). I will almost
certainly never upload this package, but I do occasionally daydream about
/usr/lib/unix/{sed,ed,cat} etc.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915134207.gb22...@bryant.redmars.org
Re: Trimming priority:standard
On Fri, Sep 12, 2014 at 03:49:11PM +0200, Thorsten Glaser wrote: bc is the standard Unix calculator, normally a dc frontend, and used in *a lot* of scripts. Is there any way of verifying or even reasonably estimating how common it is used? *Within* debian, sadly it's hard to ascertain via codesearch as 'bc' is too short, but /bc = http://codesearch.debian.net/search?q=%2Fbc I must admit I've never seen it used in 3rd party scripts in my entire career as a sysadmin. And yes, bc is also the primary interactive calculator, for things beyond what $((…)) can do. We've got python in priority:standard. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140915135328.gc22...@bryant.redmars.org
Re: Trimming priority:standard
Hi, On Montag, 15. September 2014, Jonathan Dowland wrote: Perhaps task-traditional -- Traditional Unix utilities I quite like that. FWIW, me too. (I also liked task-unix or task-unix-like, but less.) Thanks for cleaning up priority:standard! cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Trimming priority:standard
On Mon, 2014-09-15 at 14:53 +0100, Jonathan Dowland wrote: On Fri, Sep 12, 2014 at 03:49:11PM +0200, Thorsten Glaser wrote: bc is the standard Unix calculator, normally a dc frontend, and used in *a lot* of scripts. Is there any way of verifying or even reasonably estimating how common it is used? *Within* debian, sadly it's hard to ascertain via codesearch as 'bc' is too short, but /bc = http://codesearch.debian.net/search?q=%2Fbc I must admit I've never seen it used in 3rd party scripts in my entire career as a sysadmin. It is used in one place in a Linux kernel build (kernel/time/timeconst.bc). Ben. And yes, bc is also the primary interactive calculator, for things beyond what $((…)) can do. We've got python in priority:standard. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Re: Trimming priority:standard
Hi, Jonathan Dowland: On Fri, Sep 12, 2014 at 03:49:11PM +0200, Thorsten Glaser wrote: bc is the standard Unix calculator, normally a dc frontend, and used in *a lot* of scripts. Is there any way of verifying or even reasonably estimating how common it is used? *Within* debian, sadly it's hard to ascertain via codesearch as 'bc' is too short, but /bc = http://codesearch.debian.net/search?q=%2Fbc I must admit I've never seen it used in 3rd party scripts in my entire career as a sysadmin. I've seen lots of it, in old scripts which need(ed) to work[*] without the benefit of POSIX-shell-isms, let alone bash-. [*] For some value of work. They tend to plod along without regard for error conditions. bash's set -o pipefail should have been the default from the beginning. But I digress. And yes, bc is also the primary interactive calculator, for things beyond what $((…)) can do. We've got python in priority:standard. And perl, which has the advantage of an '-e' switch. Or [m]awk, which is even Required (is there still a reason for that?). -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140915161647.ga2...@smurf.noris.de
Re: Trimming priority:standard
James McCoy wrote: I keep contemplating packaging ex-vi and advocating to replace vim-tiny with that. After all, the intent is to have something providing /usr/bin/vi, as one expects to have on a *nix system, so why not have it actually be vi? The package is already done. apt-cache show nvi Bob signature.asc Description: Digital signature
Re: Trimming priority:standard
On Mon, Sep 15, 2014 at 10:56:16AM -0600, Bob Proulx wrote: James McCoy wrote: I keep contemplating packaging ex-vi and advocating to replace vim-tiny with that. After all, the intent is to have something providing /usr/bin/vi, as one expects to have on a *nix system, so why not have it actually be vi? The package is already done. apt-cache show nvi That's an odd answer to why not have it actually be vi?. Sure, nvi is a vi-clone, but it's not the actual vi. Whether that really matters much to anyone is a different question. It's worth noting that nvi was the package that previously filled the role for providing /usr/bin/vi, before vim-tiny replaced it. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140915194645.go26...@freya.jamessan.com
Re: Trimming priority:standard
James McCoy wrote: Bob Proulx wrote: James McCoy wrote: I keep contemplating packaging ex-vi and advocating to replace vim-tiny with that. After all, the intent is to have something providing /usr/bin/vi, as one expects to have on a *nix system, so why not have it actually be vi? The package is already done. apt-cache show nvi That's an odd answer to why not have it actually be vi?. Sure, nvi is a vi-clone, but it's not the actual vi. Whether that really matters much to anyone is a different question. I guess as to whether it is the actual vi or not depends upon your perspective. vi was developed by Bill Joy released with BSD. But due to the licensing of Unix system BSD rewrote all of the license encumbered code for BSD. nvi replaced vi on BSD systems. From my memory I also remember one of the problems was the vi crypto included in the original vi code which back-in-the-day prevented vi from being exported. The crypto code was not included in nvi. Soo... If you are a BSD person then nvi is the real vi. It's worth noting that nvi was the package that previously filled the role for providing /usr/bin/vi, before vim-tiny replaced it. Feature creep? Bob signature.asc Description: Digital signature
Re: Trimming priority:standard
Am 13.09.2014 um 12:58 schrieb Didier 'OdyX' Raboud: Le vendredi, 12 septembre 2014, 13.55:53 Joey Hess a écrit : Theodore Ts'o wrote: One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. Or we could just call it standard system. Could we make sure the full vim is in that then? I miss it on every new installation and I'm quite sure that's not uncommon. At least vim-tiny should provide /usr/bin/vim, so a 'vim' executable is actually available on the standard system. I would be fine with the stripped-down vim from vim-tiny if at least 'vim filename' would work. At the moment I pretty often end up either installing full vim or replacing 'vim' with 'vim.basic' on the commandline. jonas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/541746ec.2020...@freesources.org
Re: Trimming priority:standard
Bob Proulx b...@proulx.com writes: James McCoy wrote: I keep contemplating packaging ex-vi and advocating to replace vim-tiny with that. After all, the intent is to have something providing /usr/bin/vi, as one expects to have on a *nix system, so why not have it actually be vi? The package is already done. apt-cache show nvi Note that nvi is orphaned in Debian and appears to be somewhat moribund upstream, and we're carrying a large number of patches for it. The package could definitely use some love, if anyone feels like diving in, probably both upstream and Debian (but definitely Debian) could use help. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq94obit@hope.eyrie.org
Re: Trimming priority:standard
On Mon, Sep 15, 2014 at 06:16:47PM +0200, Matthias Urlichs wrote: And perl, which has the advantage of an '-e' switch. Or [m]awk, which is even Required (is there still a reason for that?). AWK is mentioned in the Single UNIX Specification as one of the mandatory utilities of a Unix operating system. Moreover, we made perl to be essential. As James Troup once said, to not to do it also for good old awk would be criminal. https://lists.debian.org/debian-policy/1998/02/msg00180.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916003146.ga9...@cantor.unex.es
Re: Trimming priority:standard
I wonder whether the POV in this discussion is right. I have the impression that the discussion is about the removal of old packages. Squeeze had 91 standard packages, now there are 108. The latest one: doc-debian. When libsqlcipher0 (1) hit standard I also had doubts that its functionality justifies the standard criteria (2). 1: https://packages.debian.org/sid/libsqlcipher0 2: https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54178f03.90...@gmx.de
Re: Trimming priority:standard
On Mon, Sep 15, 2014 at 10:07:08PM +0200, Jonas Meurer wrote: Am 13.09.2014 um 12:58 schrieb Didier 'OdyX' Raboud: Le vendredi, 12 septembre 2014, 13.55:53 Joey Hess a écrit : Theodore Ts'o wrote: One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. Or we could just call it standard system. Could we make sure the full vim is in that then? I miss it on every new installation and I'm quite sure that's not uncommon. At least vim-tiny should provide /usr/bin/vim, so a 'vim' executable is actually available on the standard system. I would be fine with the stripped-down vim from vim-tiny if at least 'vim filename' would work. Many people were not fine with that and complained about unexpected behavior (i.e., their normal vim config blowing up in their face) when running vim from vim-tiny. That's why I made the choice to have vim-tiny stop providing the /usr/bin/vim alternative. You can see more discussion about my stance in #681012 and related bug reports referenced therein. As I said in my other reply, the intent of vim-tiny is to provide a vi command. The fact that it is using Vim to do so is the means, not the end. At the moment I pretty often end up either installing full vim or replacing 'vim' with 'vim.basic' on the commandline. Which is fine, because you actually want something that behaves like most people would expect Vim to, not something that behaves more like vi. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Re: Trimming priority:standard
On Sep 16, James McCoy james...@debian.org wrote: As I said in my other reply, the intent of vim-tiny is to provide a vi command. The fact that it is using Vim to do so is the means, not the end. I think it's more complex than this: I like vim-tiny because I can use it on small images without wasting space for the dependencies, and after setting nocompatible it's as much as good as regular vim for system administration tasks. -- ciao, Marco signature.asc Description: Digital signature
Re: Trimming priority:standard
On Tue, Sep 16, 2014 at 03:54:21AM +0200, Marco d'Itri wrote: On Sep 16, James McCoy james...@debian.org wrote: As I said in my other reply, the intent of vim-tiny is to provide a vi command. The fact that it is using Vim to do so is the means, not the end. I think it's more complex than this: I like vim-tiny because I can use it on small images without wasting space for the dependencies, and after setting nocompatible it's as much as good as regular vim for system administration tasks. The very informed/knowledgeable user isn't the one that soured my perception of the choice to have vim-tiny provide /usr/bin/vim. It's rather the people that know enough to get by on Vim and be comfortable installing various plugins, but don't really delve much deeper into Vim. They setup a new computer, deploy their dotfiles somehow, run vim and then see things not working because only vim-tiny is installed, so a bug gets filed. So while I agree that being able to flip the switch to have /usr/bin/vi act more like a typical Vim install for that editing session is useful, I don't agree the same to be true about vim-tiny also providing /usr/bin/vim. A standard install provides /usr/bin/vi and if you happen to know it's provided via a stripped down build of Vim, then feel free to take advantage of that. Otherwise, actively install Vim to get what is going to behave as expected. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Re: Trimming priority:standard
Hi, from personal experience, I agree that the packages with priority standard need to be reconsidered. I don't really care about bc, dc, w3m and similar tools - I never use then, but then, they only need a few KiB so I wouldn't mind if they were installed nontheless. However, there are 4 packages which, I think, are actively problematic: at, exim, nfs, and locate. - at. Trivially installed by anyone actually using it, but we don't need one more daemon running on everyone's system just to watch for jobs via a service that almost nobody uses. Exactly. There's no point in this daemon running all the time on machines where they will never be used. It's not significant, but it's just a complete waste. - exim4. - nfs-common and rpc-bind. Just like at, these packages just install processes that will needlessly sit around and do nothing at all on most machines. Those admins that actually want mail and/or NFS can easily get them anyway (and they may choose another MTA), most people won't even know they have them running. Unlike at, these two additionally open ports, thereby increasing the attack surface of newly installed systems. I don't think it is a good idea to have open ports (and no firewall) on a newly installed system. However, I don't know enough about their respective default configuration to judge how large the risk of an attack is. Besides, the considerations regarding at apply here as well. - mlocate. We don't need a locate in standard; anyone who actually uses locate (and wants the very significant overhead of running a locate daemon) can easily install this. Finally, I think this one is actively harmful. I've had to tell a bunch of my friends to remove this package after they asked me why their Debian system, from time to time, triggered huge bursts of disk activity. That's the opposite of the feeling of control many like about Linux, and Debian in particular: The system is doing something it was not asked for, for no good purpose (as far as the user is concerned), and without an obvious way to figure out what's going on and how to stop it. I sure hope there is at least something in place to stop this from running when the machine is on battery... I removed these four packages from a bunch of systems where they were installed accidentally, and either served no purpose or were actually annoying the user (i.e., locate). They are also the reason why I tell everybody *not* to select Standard system utilities during the Debian installation: It's better to start without some basic utilities and install them as needed, than to have a bunch of stuff doing things on the system that you don't know about... So, please, restrict Standard system utilities to packages that don't open ports or regularly create significant system load without obvious gain for the average user. If possible, avoid everything that runs a daemon which does nothing if the user doesn't know about it (unlike daemons like, for example, ntp - which I'd be happy to see in standard). From my experience, nothing like this is what people expect when selecting Standard system utilities. Kind regards Ralf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54155f58.4060...@ralfj.de
Re: Trimming priority:standard
On Sat, Sep 13, 2014 at 11:17:34AM -0700, Josh Triplett wrote: I'm not arguing that standard should have nothing in it; it should have things that the vast majority of users will 1) expect to find present without having to install them and 2) actually use or care about. I sympathize with the sentiment, but AFAICT the only way to implement such a specification would be to actually *ask* our users, and (by definition) a thread on -devel cannot work to that end. It seems to me that the only way to implement that spec would be something like a broadly advertised user survey, with specific questions about the packages you are interested in. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Trimming priority:standard
Le vendredi, 12 septembre 2014, 13.55:53 Joey Hess a écrit : Theodore Ts'o wrote: One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. Or we could just call it standard system. Could we make sure the full vim is in that then? I miss it on every new installation and I'm quite sure that's not uncommon. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3087012.x4OgC7KCFP@gyllingar
Re: Trimming priority:standard
On Sat, Sep 13, 2014 at 12:58:04PM +0200, Didier 'OdyX' Raboud wrote: Le vendredi, 12 septembre 2014, 13.55:53 Joey Hess a écrit : Theodore Ts'o wrote: One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. Or we could just call it standard system. Could we make sure the full vim is in that then? I keep contemplating packaging ex-vi and advocating to replace vim-tiny with that. After all, the intent is to have something providing /usr/bin/vi, as one expects to have on a *nix system, so why not have it actually be vi? Then I could drop all the annoying packaging we had to add (and I have to maintain) to the vim packages, although it did help find some corner cases in handling of diversions, and stop getting annoyed at people complaining about vim-tiny. I miss it on every new installation and I'm quite sure that's not uncommon. Then install vim (or one of the other more featured binary packages) when you uninstall vim-tiny nano. Just because the package is included as part of the install doesn't mean you have to use it. I'm sure there are plenty of people that remove vim-tiny and install some other non-vi(m) editor too. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Re: Trimming priority:standard
]] Josh Triplett - mlocate. We don't need a locate in standard; anyone who actually uses locate (and wants the very significant overhead of running a locate daemon) can easily install this. There is no «locate daemon» in mlocate. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m2egvd1rkg@rahvafeir.err.no
Re: Trimming priority:standard
Just wait for systemd-emacs. It would obsolete... all of gnuserv! Silly people. https://aur.archlinux.org/packages/systemd-emacs-daemon/ http://www.emacswiki.org/emacs/EmacsAsDaemon#toc8 https://lists.gnu.org/archive/html/bug-gnu-emacs/2014-01/msg00996.html -- bye, Joerg It's not that I'm afraid to die, I just don't want to be there when it happens. -- Woody Allen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8738bvssoz@gkar.ganneff.de
Re: Trimming priority:standard
On 12/09/2014 18:41, Josh Triplett wrote: ...I think this makes more sense: *neither* version of Make should have priority standard. Bug filed. [And lots of other utility also requested to be removed from Standard priority..] When I see that 'make' and other well-known programs should not be installed on a system where we want standard Unix utilities to be there, I ask myself what standard Unix utilities are. I know that it can be easily installed with apt-get. But I appreciate to have a bunch of classic utilities to be installed when I ask for the standard utilities to be installed. Some tweak to the list can/should be done. But do not restrict the list to the essential ones (or provide a new task for standard-but-non-essential ones) Some reflexions: I agree with you on at (and any other proposal to decrease the number of daemons) and dc. But I see lots of people around me using bc for very small calculus. I also think that having the mailx program installed is a good thing, not for regular use but for occasional use when going on a unix system where we do not know what is installed exactly (in this case, I try in order mutt, mailx, less, more, cat) Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54146b47.4070...@free.fr
Re: Trimming priority:standard
El vie, 12 de sep 2014 a las 10:12 , Theodore Ts'o ty...@mit.edu
escribió:
On Fri, Sep 12, 2014 at 03:12:47PM +0100, Simon McVittie wrote:
(Admittedly, cron has to be Priority:important anyway, to support
logrotate - until/unless someone adds a logrotate.timer for
systemd, and
makes its cron job early-return if systemd is pid 1.)
It's inevitable that systemd will subsume cron, with an incompatible
configuration file format. :-)
logrotate uses /etc/cron.{hourly,daily,weekly,yearly}/$jobname format,
so systemd-cron can subsume cron's functionality (wrt to logrotate),
and they will both use the same lack of a configuration file format (in
favor of a directory format) :)
Best,
--
Cameron
Re: Trimming priority:standard
Vincent Danjean wrote: On 12/09/2014 18:41, Josh Triplett wrote: ...I think this makes more sense: *neither* version of Make should have priority standard. Bug filed. [And lots of other utility also requested to be removed from Standard priority..] When I see that 'make' and other well-known programs should not be installed on a system where we want standard Unix utilities to be there, I ask myself what standard Unix utilities are. I know that it can be easily installed with apt-get. But I appreciate to have a bunch of classic utilities to be installed when I ask for the standard utilities to be installed. Some tweak to the list can/should be done. But do not restrict the list to the essential ones (or provide a new task for standard-but-non-essential ones) I'm not arguing that standard should have nothing in it; it should have things that the vast majority of users will 1) expect to find present without having to install them and 2) actually use or care about. So, for instance, iputils-ping is priority important, because it'd be shocking to not have ping. man-db is priority important and info is priority standard, because documentation is useful to have by default, especially since you might need it while figuring out why you can't install packages or connect to the network. On the other hand, while make is widely used to build packages, and occasionally for other purposes, it hardly seems like the kind of utility you'd expect to find on a system without explicitly installing it. Particularly since we *don't* provide compilers as part of standard (nor should we). Some reflexions: I agree with you on at (and any other proposal to decrease the number of daemons) and dc. But I see lots of people around me using bc for very small calculus. Sure, but how many people expect it to exist without installing it? And on top of that, how many people will end up using bc rather than (for instance) gnome-calculator? And among engineers, personally I see far more people firing up their programming language REPL of choice to do math in a more familiar environment. I also think that having the mailx program installed is a good thing, not for regular use but for occasional use when going on a unix system where we do not know what is installed exactly (in this case, I try in order mutt, mailx, less, more, cat) The problem with mailx isn't with the package itself, but that it depends on a functioning MTA, which I'd like to get removed from standard as a daemon that very few users will actually use or care about. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140913181732.GA13698@thin
Re: Trimming priority:standard
apt-listchanges aptitude aptitude-common at bash-completion bc dc bind9-host Why is aptitude still in this list? Please keep telnet. - Fabian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410505179.20708.3.ca...@greffrath.com
Re: Trimming priority:standard
Adam Borowski kilob...@angband.pl writes: What would you guys say about cutting some cruft from priority:standard? Yay. bind9-host dnsutils host libbind9-90 libdns100 libisc95 liblwres90 Is the BIND libraries pulled in just because of 'host'? Seems rather heavy to me. Anyway, the 'host' package seems to be superseded by 'bind9-host' so the former could go? /Simon signature.asc Description: PGP signature
Re: Trimming priority:standard
Quoting Russ Allbery (2014-09-12 04:41:19) wamerican provides /usr/share/dict/words, which is widely used in a variety of strange places you wouldn't expect, like random test suites. How about the more generic (but also slightly larger) miscwords for that instead. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Trimming priority:standard
Adam Borowski wrote: What would you guys say about cutting some cruft from priority:standard? Yes please! I've been poking at this for a while, trying to reduce the number of installed-by-default packages; I've filed quite a few bugs, some of which have gotten fixed. The current list is: apt-listchanges aptitude aptitude-common at bash-completion bc dc bind9-host dnsutils host libbind9-90 libdns100 libisc95 liblwres90 bsd-mailx bzip2 libcwidget3 libsasl2-2 libsasl2-modules-db db5.1-util libdb5.3 debian-faq doc-debian exim4 exim4-base exim4-config exim4-daemon-light file libmagic1 gettext-base libasprintf0c2 locales libgnutls26 libgnutls-deb0-28 libgnutls-openssl27 libgpm2 libkeyutils1 krb5-locales libgssapi-krb5-2 libgssrpc4 libk5crypto3 libkadm5clnt-mit9 libkadm5srv-mit9 libkdb5-7 libkrad0 libkrb5-3 libkrb5support0 libcap2 libclass-isa-perl libedit2 libevent-2.0-5 libgc1c2 libgcrypt11 libgcrypt20 libgpg-error0 libgssglue1 libidn11 liblockfile-bin liblockfile1 libnfsidmap2 librpcsecgss3 libswitch-perl libtasn1-6 libtirpc1 libxml2 lsof m4 make-guile mime-support mlocate mutt ncurses-term ftp telnet nfs-common libldap-2.4-2 openssh-client libp11-kit0 patch libpci3 pciutils perl perl-modules procmail python-apt python python-minimal python-support python2.7 python-reportbug reportbug rpcbind wamerican libsqlcipher0 libsqlite3-0 libwrap0 info install-info texinfo time libtokyocabinet9 ucf w3m libwgdb0 whois libxapian22 xz-utils I'd start with: * dc: a RPN calculator is pretty esoteric, bc is for normal people. Just filed a bug for that one. I'd actually argue that both bc and dc should become optional. normal people don't use command-line calculators at all, and people who do use command-line calculators spell that python or ghci or ruby or node or $(()) or pick-your-favorite-REPL-here. * db5.1-util: we're on db5.3, and I don't see much util here. Already fixed in unstable (5.1.29-9); the override file just needs updating. From the PTS: There were override disparities found in suite unstable: db5.1-util: Override says database - standard, .deb says oldlibs - optional None of the db*-util packages should be standard; libdb* should only be pulled in by programs that need it, and the utilities shouldn't be pulled in at all. * m4: a really obscure language. Used basically only for autoconf scripts, and that use is covered by autoconf's dependency. Not *that* obscure, but it certainly doesn't need to appear in standard. * texinfo: 'info' should be enough for most uses. I filed that one a long time ago, and the maintainers fixed it a long time ago (priority optional now); the override file just needs fixing. Getting rid of texinfo would also drop several perl library packages from the default install. * telnet: dead for 19 years. Used only by those who misspell 'nc' and hope for no 0xff bytes. Given the rarity of telnet for login, and the common use of telnet for a text connection to random ports, how insane would it be to make interactive invocation of telnet default to being clean and transparent (without the crazy escape characters), and require an explicit option to *enable* non-transparent operation? (Yeah, I realize that's called nc, but fingers take a while to retrain.) Also, it's sad that netcat-traditional is priority important, rather than netcat-openbsd, which has far more useful features (for instance, proxy support). * wamerican: what use is a wordlist with no users? Lots of things want /usr/share/dict/words; it doesn't seem unreasonable for standard, though it certainly shouldn't have a higher priority than that. On the other hand, I'd nominate 'locales' for priority:important. Needed for working UTF-8 support. Not needed; just set LANG=C.UTF-8, provided by libc-bin (Essential: yes). We should do that by default. Other packages which should not live in standard: - at. Trivially installed by anyone actually using it, but we don't need one more daemon running on everyone's system just to watch for jobs via a service that almost nobody uses. - bc, along with dc, as mentioned above. - host, a transitional package. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645437 - bsd-mailx. Any package that uses this will depend on it. Very few people use this as a mail reader, and it's trivially installed for people who have scripts that invoke it (rather than the more common case of invoking sendmail). And this doesn't work at all without an installed or configured MTA, another good reason to give it the boot. - liblockfile-bin and liblockfile1. Within standard, only bsd-mailx depends on these. - procmail. Anyone using this can trivially install it, but it's far from common, and it wouldn't be shocking for a system (particularly a system other than a mail server) to not have it preinstalled. - exim4. The vast majority of desktop users ignore this completely and read their mail using mail clients that speak IMAP
Re: Trimming priority:standard
* Josh Triplett j...@joshtriplett.org, 2014-09-12, 00:55: - gettext-base. Supports internationalized shell scripts; anything using this depends on it, and nothing in standard or above does. select-editor uses it: #728612 (I can't fathom why this tool exists in the first place.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912081115.ga7...@jwilk.net
Re: Trimming priority:standard
Josh Triplett j...@joshtriplett.org writes: Now that libc-bin contains C.UTF-8, which we should make the default locale, [...] It would be nice to get Debian's support for C.UTF-8 pushed to upstream glibc. At present, it's patched in by some (not all) distributions, which means that upstream authors can't rely on it being available. For some of my software it'd be really useful to have a predictable UTF-8 locale for running tests, etc. There's a glibc RFE bug filed in response to a Fedora discussion: https://sourceware.org/bugzilla/show_bug.cgi?id=17318 -- Adam Sampson a...@offog.org http://offog.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/y2afvfx6phh@cartman.at.offog.org
Re: Trimming priority:standard
Josh Triplett j...@joshtriplett.org writes: - make-guile. More of a question than a recommendation for a change, but why is this standard and make optional, rather than the other way around? Is this mostly about naming? GNU Make has guile-support by default, so I would say that 'make' should be with Guile and if desired for some reason, there could be a 'make-noguile' that is built without guile. A bigger question: is 'make' really necessary in priority:standard? Presumably anything requiring it will depend on it. - mlocate. We don't need a locate in standard; anyone who actually uses locate (and wants the very significant overhead of running a locate daemon) can easily install this. +1 It is for desktops. - nfs-common and rpc-bind. Anyone using NFS can install these, but NFS is not anywhere close to common enough to appear in priority standard. +1 Right now rpcbind is listening on the network in a default jessie install, and I don't like that. /Simon signature.asc Description: PGP signature
Re: Trimming priority:standard
On Fri, 12 Sep 2014, Josh Triplett wrote: * dc: a RPN calculator is pretty esoteric, bc is for normal people. Just filed a bug for that one. I'd actually argue that both bc and dc should become optional. *no*! bc is the standard Unix calculator, normally a dc frontend, and used in *a lot* of scripts. I’m ambiguous about GNU dc (since GNU bc does not use it, and I’ve seen fewer – still not none – scripts using it), but if there is no bc or ed on a system, it’s Windows or something. And yes, bc is also the primary interactive calculator, for things beyond what $((…)) can do. * telnet: dead for 19 years. Used only by those who misspell 'nc' and hope for no 0xff bytes. Also, it's sad that netcat-traditional is priority important, rather than netcat-openbsd, which has far more useful features (for instance, Agreed that netcat-openbsd (*not* netcat-traditional!) should supersede telnet (because of 0xFF, but also because nc is line-buffered and telnet is unbuffered), but again, removing telnet is against the expectations of most Unix users. On the other hand, I'd nominate 'locales' for priority:important. Needed for working UTF-8 support. Not needed; just set LANG=C.UTF-8, provided by libc-bin (Essential: yes). We should do that by default. Agree. And if that should ever *not* be enough, “locales” also isn’t and you need “locales-all” instead. (I’ve seen random PHP webapplications break if locales-all was not installed, with segfaults and all…) - at. Trivially installed by anyone actually using it, but we don't need one more daemon running on everyone's system just to watch for jobs via a service that almost nobody uses. Eh sorry? at+cron are standard Unix. - bc, along with dc, as mentioned above. Absolutely no. - host, a transitional package. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645437 Right, but bind9-host is really heavy… - bsd-mailx. Any package that uses this will depend on it. Very few people use this as a mail reader, and it's trivially installed for people who have scripts that invoke it (rather than the more common case of invoking sendmail). And this doesn't work at all without an installed or configured MTA, another good reason to give it the boot. Agreed; prio:standard should probably not pull in this (and, via it (and only it, IIRC), one of the MTAs, the discussion of which to choose is political). But then, an MTA configured to listen and deliver locally, and send mails out, belongs to a standard system… - procmail. Anyone using this can trivially install it, but it's far from common, and it wouldn't be shocking for a system (particularly a system other than a mail server) to not have it preinstalled. Agreed. procmail seems to be a GNU phenomenon anyway; I’ve not seen it on a non-GNU OS, unless the admin or a user was already a fan of it. - w3m. Very few people use text-based web browsers, and we should not have one in standard. At least not w3m but lynx, which is the standard text browser; w3m is also really… weird to use. - make-guile. More of a question than a recommendation for a change, but why is this standard and make optional, rather than the other way around? oO this is new… - mlocate. We don't need a locate in standard; anyone who actually uses locate (and wants the very significant overhead of running a locate daemon) can easily install this. Disagree, locate should be there. - nfs-common and rpc-bind. Anyone using NFS can install these, but NFS is not anywhere close to common enough to appear in priority standard. ACK. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1409121542260.7...@tglase.lan.tarent.de
Re: Trimming priority:standard
On Thu, Sep 11, 2014 at 07:41:19PM -0700, Russ Allbery wrote: * telnet: dead for 19 years. Used only by those who misspell 'nc' and hope for no 0xff bytes. * wamerican: what use is a wordlist with no users? Both of these fall under the anyone familiar with UNIX would go 'where the hell is X' if the package isn't installed provision, I think. Yes, nc is better than telnet, but telnet is part of a *lot* of people's finger memory, and I think removing the package violates the principle of least surprise here. It's not very large. A large number of these packages would fall into this category. Arguably this would include dc and m4. (Trivia fact: dc predates the C programming language, and it has macros, conditionals, and looping constructs. :-) That being said, if there are Debian users who are not Unix-heads, they aren't going to miss any of these. What if we create a tasksel task called Unix that installs these traditional Unix commands from the BSD 4.x era? It would include dc, m4, /usr/dict/words, telnet, etc. wamerican provides /usr/share/dict/words, which is widely used in a variety of strange places you wouldn't expect, like random test suites. True, but that's a developer thing. The argument can be used for m4 and dc as well --- that they can be used all sorts of places you don't expect. - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912135601.ga23...@thunk.org
Re: Trimming priority:standard
On 12/09/14 14:56, Theodore Ts'o wrote: What if we create a tasksel task called Unix that installs these traditional Unix commands from the BSD 4.x era? It would include dc, m4, /usr/dict/words, telnet, etc. I was just about to suggest that myself. at, cron, an MTA, and locate seem good candidates for that task too. (Admittedly, cron has to be Priority:important anyway, to support logrotate - until/unless someone adds a logrotate.timer for systemd, and makes its cron job early-return if systemd is pid 1.) S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5412ff5f.5040...@debian.org
Re: Trimming priority:standard
Le 12/09/2014 15:49, Thorsten Glaser a écrit : On Fri, 12 Sep 2014, Josh Triplett wrote: [...] bc is the standard Unix calculator, normally a dc frontend, and used in *a lot* of scripts. [...] Eh sorry? at+cron are standard Unix. [...] But then, an MTA configured to listen and deliver locally, and send mails out, belongs to a standard system… Hi, I agree that all those tools belong to a standard UNIX system. However, is that among our goals to provide people with a standard UNIX system by default? Do our users care? These tools really make sense only for a subset of our users (mostly, network administrators). Our desktop users don't care for any of those, as long as they are pulled in transparently when required by the stuff they actually use. The same holds for telnet: most users have no clue what to do with it. As an example, on my laptop, nobody ever uses any of theses tools. I don't read local mail. I send mail using SMTP. I don't write that many shell scripts, using higher end languages that don't need bc for doing maths. I do care for locate, though. Not that I care much personally about trimming prio:standard, but why not move a lot of this stuff to a standard UNIX-like task (or whatever you want to call it) instead? Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Trimming priority:standard
On Fri, 12 Sep 2014, Thibaut Paumard wrote: I agree that all those tools belong to a standard UNIX system. However, is that among our goals to provide people with a standard UNIX system by This is not about “by default”, but it *is* the definition of priority:standard in Debian. And yes, it’s reasonable. bye, //mirabilos -- Why don't you use JavaScript? I also don't like enabling JavaScript in Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1409121622480.7...@tglase.lan.tarent.de
Re: Trimming priority:standard
Le 12/09/2014 16:23, Thorsten Glaser a écrit : On Fri, 12 Sep 2014, Thibaut Paumard wrote: I agree that all those tools belong to a standard UNIX system. However, is that among our goals to provide people with a standard UNIX system by This is not about “by default”, but it *is* the definition of priority:standard in Debian. No, it's not. The actual definition is very vague and does not refer to UNIX at all: standard These packages provide a reasonably small but not too limited character-mode system. This is what will be installed by default if the user doesn't select anything else. It doesn't include many large applications. https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities Kind regards, Thibaut. -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Re: Trimming priority:standard
Simon McVittie wrote: On 12/09/14 14:56, Theodore Ts'o wrote: What if we create a tasksel task called Unix that installs these traditional Unix commands from the BSD 4.x era? It would include dc, m4, /usr/dict/words, telnet, etc. I was just about to suggest that myself. at, cron, an MTA, and locate seem good candidates for that task too. +1. Makes a lot of sense, I agree. Maybe also move across: bind9-host dnsutils host bsd-mailx lsof (?) patch (?) procmail time (?) whois -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xsryk-0004gl...@mail.einval.com
Re: Trimming priority:standard
Le 12/09/2014 16:33, Thibaut Paumard a écrit : Le 12/09/2014 16:23, Thorsten Glaser a écrit : On Fri, 12 Sep 2014, Thibaut Paumard wrote: I agree that all those tools belong to a standard UNIX system. However, is that among our goals to provide people with a standard UNIX system by This is not about “by default”, but it *is* the definition of priority:standard in Debian. No, it's not. The actual definition is very vague and does not refer to UNIX at all: My bad. It's the important priority that mentions UNIX. -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Re: Trimming priority:standard
On Fri, 12 Sep 2014, Thibaut Paumard wrote: No, it's not. The actual definition is very vague and does not refer to Oh, my bad. I confused this with priority:important then. So we should probably *raise* the priority of things like bc, ed, etc. to important. bye, //mirabilos -- 15:41⎜Lo-lan-do:#fusionforge Somebody write a testsuite for helloworld :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1409121637170.7...@tglase.lan.tarent.de
Re: Trimming priority:standard
Le 12/09/2014 16:37, Thorsten Glaser a écrit : On Fri, 12 Sep 2014, Thibaut Paumard wrote: No, it's not. The actual definition is very vague and does not refer to Oh, my bad. I confused this with priority:important then. So we should probably *raise* the priority of things like bc, ed, etc. to important. That, or change Policy to reflect current expectations. Perhaps those priorities don't make that much sense nowadays. Debian has really become the Universal OS by know, tasks are better suited to represent what is considered important, standard or optional in different fields of endeavor. Kind regards. signature.asc Description: OpenPGP digital signature
Re: Trimming priority:standard
On Fri, 12 Sep 2014, Josh Triplett wrote: * telnet: dead for 19 years. Used only by those who misspell 'nc' and hope for no 0xff bytes. A slight exaggeration. A client that uses the actual telnet protocol is still invaluable for managing various fairly stupid devices. Given the rarity of telnet for login, and the common use of telnet for a text connection to random ports, how insane would it be to make interactive invocation of telnet default to being clean and transparent (without the crazy escape characters), and require an explicit option to *enable* non-transparent operation? I'd regard that as highly inconvenient. More inconvenient than retraining fingers to nc (although I'm biased since I've already done that). Regardless, this is in no way an argument for keeping telnet in standard. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1409121556060.18...@pandora.retrosnub.co.uk
Re: Trimming priority:standard
On Fri, Sep 12, 2014 at 02:36:09PM +0200, Simon Josefsson wrote: Josh Triplett j...@joshtriplett.org writes: - make-guile. More of a question than a recommendation for a change, but why is this standard and make optional, rather than the other way around? Is this mostly about naming? GNU Make has guile-support by default, so I would say that 'make' should be with Guile and if desired for some reason, there could be a 'make-noguile' that is built without guile. No, I think it makes sense for make to not have Guile support, and make-guile to have Guile. That way, the version of make pulled in by existing dependencies (and build-essential) does not guarantee Guile support, and packages depending on Guile support must depend on make-guile explicitly. I more wondered whether the default version of Make in stanard should have Guile support. However... A bigger question: is 'make' really necessary in priority:standard? Presumably anything requiring it will depend on it. ...I think this makes more sense: *neither* version of Make should have priority standard. Bug filed. - mlocate. We don't need a locate in standard; anyone who actually uses locate (and wants the very significant overhead of running a locate daemon) can easily install this. +1 It is for desktops. - nfs-common and rpc-bind. Anyone using NFS can install these, but NFS is not anywhere close to common enough to appear in priority standard. +1 Right now rpcbind is listening on the network in a default jessie install, and I don't like that. Exactly. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912164158.GA3271@thin
Re: Trimming priority:standard
On Fri, Sep 12, 2014 at 03:12:47PM +0100, Simon McVittie wrote: (Admittedly, cron has to be Priority:important anyway, to support logrotate - until/unless someone adds a logrotate.timer for systemd, and makes its cron job early-return if systemd is pid 1.) It's inevitable that systemd will subsume cron, with an incompatible configuration file format. :-) - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912171230.gb23...@thunk.org
Re: Trimming priority:standard
* Theodore Ts'o ty...@mit.edu, 2014-09-12, 13:12: It's inevitable that systemd will subsume cron, with an incompatible configuration file format. :-) I'm looking forward for systemd-mta. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912171850.ga8...@jwilk.net
Re: Trimming priority:standard
One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. [1] http://www.unix.org/trademark.html - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912171923.gc23...@thunk.org
Re: Trimming priority:standard
On 12/09/14 18:19, Theodore Ts'o wrote: One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. Perhaps task-traditional -- Traditional Unix utilities ? Or Un*x if you're that worried. (The ambiguous meaning of tradition - either well-established practices that all right-thinking people should follow or obsolete things that are only here because they always used to be - is entirely intentional. :-) S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54132d0a.1000...@debian.org
Re: Trimming priority:standard
On Thu, 11 Sep 2014, Russ Allbery wrote: wamerican provides /usr/share/dict/words, which is widely used in a variety of strange places you wouldn't expect, like random test suites. If size is an issue, I'd also be OK with migrating wamerican-small to standard (0.5M installed), and wamerican (1M installed) to optional. This would also require some work besides just changing priority, as whatever package is in standard should not depend on dictionaries common, and manage the symlink itself; wamerican currently does this. -- Don Armstrong http://www.donarmstrong.com He no longer wished to be dead. At the same time, it cannot be said that he was glad to be alive. But at least he did not resent it. He was alive, and the stubbornness of this fact had little by little begun to fascinate him -- as if he had managed to outlive himself, as if he were somehow living a posthumous life. -- Paul Auster _City of Glass_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912173254.gr7...@rzlab.ucr.edu
Re: Trimming priority:standard
Theodore Ts'o wrote: One thought... there will probably be trademark concerns with unix.[1] So we might have to choose a name for the tasksel task to be someting like unix-like. Or we could just call it standard system. -- see shy jo signature.asc Description: Digital signature
Re: Trimming priority:standard
Theodore Ts'o wrote: On Fri, Sep 12, 2014 at 03:12:47PM +0100, Simon McVittie wrote: (Admittedly, cron has to be Priority:important anyway, to support logrotate - until/unless someone adds a logrotate.timer for systemd, and makes its cron job early-return if systemd is pid 1.) It's inevitable that systemd will subsume cron, with an incompatible configuration file format. :-) There's already a systemd-cron generator, which consumes crontab and cron.d files and generates .timer units. (And .timer is a perfectly compatible configuration file format: it's compatible with .service file syntax. ;) Which is actually rather useful, since you can then use all the same syntax to control the launched program.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912174837.GA1348@jtriplet-mobl1
Re: Trimming priority:standard
On Sep 12, 2014, at 07:18 PM, Jakub Wilk wrote: I'm looking forward for systemd-mta. It's inevitable. ;) http://catb.org/jargon/html/Z/Zawinskis-Law.html -Barry signature.asc Description: PGP signature
Re: Trimming priority:standard
On 09/12/2014 02:27 PM, Barry Warsaw wrote: On Sep 12, 2014, at 07:18 PM, Jakub Wilk wrote: I'm looking forward for systemd-mta. It's inevitable. ;) http://catb.org/jargon/html/Z/Zawinskis-Law.html -Barry Just wait for systemd-emacs. It would obsolete... all of gnuserv!
Re: Trimming priority:standard
Hi, Huh. I have been waiting for emacs/lisp/systemd.el Manoj On September 12, 2014 7:49:45 PM PDT, John Goerzen jgoer...@complete.org wrote: On 09/12/2014 02:27 PM, Barry Warsaw wrote: On Sep 12, 2014, at 07:18 PM, Jakub Wilk wrote: I'm looking forward for systemd-mta. It's inevitable. ;) http://catb.org/jargon/html/Z/Zawinskis-Law.html -Barry Just wait for systemd-emacs. It would obsolete... all of gnuserv! -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Trimming priority:standard
Hi, Edward Allcutt: On Fri, 12 Sep 2014, Josh Triplett wrote: * telnet: dead for 19 years. Used only by those who misspell 'nc' and hope for no 0xff bytes. A slight exaggeration. A client that uses the actual telnet protocol is still invaluable for managing various fairly stupid devices. So use nc -t if you need it. Better to make the unsafe behavior explicit. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140913040434.gf19...@smurf.noris.de
Trimming priority:standard
Meow! What would you guys say about cutting some cruft from priority:standard? The current list is: apt-listchanges aptitude aptitude-common at bash-completion bc dc bind9-host dnsutils host libbind9-90 libdns100 libisc95 liblwres90 bsd-mailx bzip2 libcwidget3 libsasl2-2 libsasl2-modules-db db5.1-util libdb5.3 debian-faq doc-debian exim4 exim4-base exim4-config exim4-daemon-light file libmagic1 gettext-base libasprintf0c2 locales libgnutls26 libgnutls-deb0-28 libgnutls-openssl27 libgpm2 libkeyutils1 krb5-locales libgssapi-krb5-2 libgssrpc4 libk5crypto3 libkadm5clnt-mit9 libkadm5srv-mit9 libkdb5-7 libkrad0 libkrb5-3 libkrb5support0 libcap2 libclass-isa-perl libedit2 libevent-2.0-5 libgc1c2 libgcrypt11 libgcrypt20 libgpg-error0 libgssglue1 libidn11 liblockfile-bin liblockfile1 libnfsidmap2 librpcsecgss3 libswitch-perl libtasn1-6 libtirpc1 libxml2 lsof m4 make-guile mime-support mlocate mutt ncurses-term ftp telnet nfs-common libldap-2.4-2 openssh-client libp11-kit0 patch libpci3 pciutils perl perl-modules procmail python-apt python python-minimal python-support python2.7 python-reportbug reportbug rpcbind wamerican libsqlcipher0 libsqlite3-0 libwrap0 info install-info texinfo time libtokyocabinet9 ucf w3m libwgdb0 whois libxapian22 xz-utils I'd start with: * dc: a RPN calculator is pretty esoteric, bc is for normal people. * db5.1-util: we're on db5.3, and I don't see much util here. * m4: a really obscure language. Used basically only for autoconf scripts, and that use is covered by autoconf's dependency. * texinfo: 'info' should be enough for most uses. * telnet: dead for 19 years. Used only by those who misspell 'nc' and hope for no 0xff bytes. * wamerican: what use is a wordlist with no users? On the other hand, I'd nominate 'locales' for priority:important. Needed for working UTF-8 support. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140911235407.ga9...@angband.pl
Re: Trimming priority:standard
On Sep 12, Adam Borowski kilob...@angband.pl wrote: What would you guys say about cutting some cruft from priority:standard? I like your plan (even if I have some doubts about telnet). -- ciao, Marco signature.asc Description: Digital signature
Re: Trimming priority:standard
On Friday, September 12, 2014 02:43:09 Marco d'Itri wrote: On Sep 12, Adam Borowski kilob...@angband.pl wrote: What would you guys say about cutting some cruft from priority:standard? I like your plan (even if I have some doubts about telnet). Personally, I use telnet pretty routinely. Generally when I'm acting as a human pretending to be an MTA for troubleshooting purposes. I would find it pretty surprising to find it absent. The rest of the plan seems reasonable to me. Scott K signature.asc Description: This is a digitally signed message part.
Re: Trimming priority:standard
On Thu, Sep 11, 2014 at 08:53:59PM -0400, Scott Kitterman wrote: On Friday, September 12, 2014 02:43:09 Marco d'Itri wrote: On Sep 12, Adam Borowski kilob...@angband.pl wrote: What would you guys say about cutting some cruft from priority:standard? I like your plan (even if I have some doubts about telnet). Personally, I use telnet pretty routinely. Generally when I'm acting as a human pretending to be an MTA for troubleshooting purposes. I would find it pretty surprising to find it absent. You want 'nc myserver 25', as 'telnet myserver 25' will misbehave on 0xff bytes. A malicious server can do pretty surprising things to you, too. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912014446.ga11...@angband.pl
Re: Trimming priority:standard
Adam Borowski kilob...@angband.pl writes: I'd start with: * dc: a RPN calculator is pretty esoteric, bc is for normal people. * db5.1-util: we're on db5.3, and I don't see much util here. * m4: a really obscure language. Used basically only for autoconf scripts, and that use is covered by autoconf's dependency. * texinfo: 'info' should be enough for most uses. +1 on these. * telnet: dead for 19 years. Used only by those who misspell 'nc' and hope for no 0xff bytes. * wamerican: what use is a wordlist with no users? Both of these fall under the anyone familiar with UNIX would go 'where the hell is X' if the package isn't installed provision, I think. Yes, nc is better than telnet, but telnet is part of a *lot* of people's finger memory, and I think removing the package violates the principle of least surprise here. It's not very large. wamerican provides /usr/share/dict/words, which is widely used in a variety of strange places you wouldn't expect, like random test suites. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ha0dlfw0@hope.eyrie.org
Re: Trimming priority:standard
Scott Kitterman deb...@kitterman.com writes: Personally, I use telnet pretty routinely. Generally when I'm acting as a human pretending to be an MTA for troubleshooting purposes. I would find it pretty surprising to find it absent. Try nc. It works pretty well. :) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d2b1lfv6@hope.eyrie.org
Re: Trimming priority:standard
]] Russ Allbery Scott Kitterman deb...@kitterman.com writes: Personally, I use telnet pretty routinely. Generally when I'm acting as a human pretending to be an MTA for troubleshooting purposes. I would find it pretty surprising to find it absent. Try nc. It works pretty well. :) Telnet has the nice feature of telling you what's happening (trying to connect, connected, etc), something nc needs -v to do. Purely a convenience/finger macro problem of course, but I suspect telnet's being used because people have typed it for the better part of 20 or 30 years. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m2lhpp1mte@rahvafeir.err.no
