On Thu, Dec 13, 2001 at 01:22:01AM -0800, Thomas Bushnell, BSG wrote:
> Anthony Towns <aj@azure.humbug.org.au> writes:
> > What does it take to get this damn message across to people? Do you
> > assume that "No Junk Mail" signs have an "(Unless it's too much effort)"
> > rider or something? If not, why do you assume M-F-T headers and the list
> > guidelines in the developers-reference do? What the hell is the deal?
> I use emacs and gnus. If you were to make those programs support the
> header in question, then I'll follow it, quite automagically.
Uh, it's the program you've chosen to use; it's no one else's
responsibility to make it match list policy. And hell, we've even gone
out of our way to use a standard header to make this easy for you.
I repeat: why do you think there's some "(Unless it's too much effort)"
rider?
> And I can also try to remember your preference. But I'm not going to
> bend over backwards to deal with a nonstandard header. Can I suggest
> that you use mail software which enables you to avoid duplicates?
No, because the duplicates are useful when they're deliberate: they
let me see mails that I specifically need to see easily. When they're
just done automatically.
> > I don't really think that helps. The worst case scenario is something like
> > having every manpage (or infopage) come up with a different free software
> > manifesto of dubious worth that's never allowed to be removed from the
> > document; not today, not tomorrow, not when the original author dies,
> > and probably not even x years after the author's death if the documents
> > maintained, and x ever becomes fixed again.
> Yes, that does suck. But this is an argument against only some cases,
> not all. Can we make a prudential judgment about whether the entity
> in question is likely to remain around?
I don't think that's particularly relevant, and nor do I think we can
make a useful judgement about it.
> > Is that the sort of environment -- where you can't customise that
> > particular feature of your environment -- really reminscent of the sort
> > of freedoms we espouse? I don't think it is, personally.
> I agree. The question is: how much of a deal-breaker is it?
Are you trying to sell me a car?
Taking a moral principle and thinking about what would happen if everyone
did it is one way of seeing whether it's a good moral to have or not. In
this case, it seems to me that adding invariant texts to documentation
is something that takes away our freedom.
By comparison an OS where everything is BSD licensed, or GPLed isn't so
bad, whereas one with every component licensed differently would be fine
for most things, but would still suck in some ways.
> > If we're going to move the document around, it seems better just to put
> > it in non-free. Having to `apt-get install debian-political' to get at
> > (eg) the emacs manual, doesn't seem like a real service to users.
> Putting emacs in non-free is a service to users?
Yes, it is. And this isn't about emacs, it's about its docs.
> If emacs is split
> into two packages, then either way the user has to install something
> new.
The question isn't installing two packages (people already do that for
apache and apache-doc, eg), it's about working out that emacs' docs are
in a package called "emacs21-doc" versus "debian-political".
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
"Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
see http://azure.humbug.org.au/~aj/armadillos.txt
Attachment:
pgpmpprSn7tu_.pgp
Description: PGP signature