Commit 5d1a2888 authored by Eric S. Raymond's avatar Eric S. Raymond

/etc cleanup

	* COOKIES, copying.paper, INTERVIEW, MAILINGLISTS, MOTIVATION,
	publicsuffix.txt SERVICE: More deletions suggested by RMS.
parent 9685190b
2014-01-11 Eric S. Raymond <esr@thyrsus.com>
* celibacy.1, sex.6, condom.1, echo.msg: Deleted at RMS's
suggestion. Not lost to posterity as they are part of the
widely distributed funny-manpages collection.
2014-01-11 Fabrice Popineau <fabrice.popineau@gmail.com>
* configure.ac: Read $srcdir/nt/mingw-cfg.site when $MSYSTEM is
......
[Someone sent this in from California, and we decided to extend
our campaign against information hoarding to recipes as well
as software. (Recipes are the closest thing, not involving computers,
to software.)
The story appears to be a myth, according to the Chicago Tribune,
which says that Mrs Fields Cookies hoards the information completely.
Therefore, this recipe can be thought of as a compatible replacement.
We have reports that the cookies it makes are pretty good.]
Someone at PG&E called the Mrs. Fields Cookie office
and requested the recipe for her cookies. They asked
her for her charge card number, and she gave it to them
thinking the cost would be $15 to $25. It turned out
to be $200!
Therefore, this person is giving the recipe to anyone
and everyone she knows (and doesn't know) so that
someone can get use of her $200. Anyway, just keep
passing it on.
Cream together: 2 cups butter
2 cups sugar
2 cups brown sugar
Add: 4 eggs
2 tsp. vanilla
Mix together in
separate bowl: 4 cups flour
5 cups oatmeal (put small
amounts of oatmeal in blender until it turns to
powder. Measure out 5 cups of oatmeal and only
"powderize" that, NOT 5 cups "powderized" oatmeal)
1 tsp salt
2 tsp baking powder
2 tsp baking soda
Mix: All of the above
Add: 24 oz. bag of chocolate chips and
1 finely grated 8 oz Hershey bar (plain)
Add: 3 cups chopped nuts (any kind)
Bake on greased cookie sheet (make golf ball sized balls) and
bake about two inches apart. Bake at 350 degrees for 8 - 10
minutes. DO NOT OVERBAKE. Makes 112.
From: ucdavis!lll-lcc!hplabs!parcvax!bane@ucbvax.berkeley.edu (John R. Bane)
Subject: Re: free cookie foundation?
Hi! I "stole" your very expensive cookie recipe off the net. If you
want to send me your SnailMail address, I'll be glad to send you a
dollar (I would like to suggest this to the net, but I think there is
some netiquette rule against asking for money - or is that only money
for oneself?) to help defray the cost (it's not much, but if EVERYone
who took the recipe sent you a dollar, it would help).
Here also is another cookie recipe which I'm very fond of.
Makes 6-8 dozen
Bake at 375 degrees for ~10 min.
Cream together:
1 cup shortening (I use Weight Watcher's Reduced Calorie Margarine!)
1/4 cup peanut butter (I recommend the non-sugared kind)
1/2 cup sugar
1/2 cup brown sugar
2 eggs
1 teaspoon vanilla
Add:
1/2 cup flour
1 teaspoon soda
1/2 teaspoon salt
2 cups rolled oats (I use the 5-min variety)
1-2 cups chocolate chips (I use 2 cups semi-sweet - ummmm!)
1 cup nuts (I use pecan pieces - don't get them crushed, or the extra
oil will make greasy cookies)
1 cup shredded or flaked coconut
(The nuts were listed as optional and I added the coconut myself, but
I really love them there! You could also add things like m&m's, or
raisins (I don't care for raisins in cookies, but you might). I've
always wanted to try banana chips.)
Mix well. Drop by teaspoonfuls on greased cookie sheet (I use pam).
Bake at 375 degrees for approx. 10 min.
My aunt found this recipe in an Amish book called something like
"Eating Well When The Whole World Is Starving," and although I thought
a cookie recipe was a bit odd for a book like that, they are about the
healthiest a cookie is ever likely to get.
They are also very easy to make (no blending, sifting, rolling, etc.)
and extremely delicious. I get rave reviews and recipe requests whenever
I make them.
- rene
Chocolate Chip Cookies - Glamorous, crunchy, rich with chocolate bits & nuts.
Also known as "Toll House" Cookies ... from Kenneth and Ruth Wakefield's
charming New England Toll House on the outskirts of Whitman, Massachusetts.
These cookies were first introduced to American homemakers in 1939 through
our series of radio talks on "Famous Foods From Famous Eating Places."
Mix Thoroughly :
2/3 cup soft shortening ( part butter )
1/2 cup granulated sugar
1/2 cup brown sugar ( packed )
1 egg
1 tsp vanilla
Sift together and stir in :
1-1/2 cups sifted flour (*)
1/2 tsp soda
1/2 tsp salt
Stir in :
1/2 cup cut-up nuts
6 oz package of semi-sweet chocolate pieces ( about 1-1/4 cups )
(*) for a softer, more rounded cookie, use 1-3/4 cups sifted flour.
Drop rounded teaspoonfuls about 2" apart on ungreased baking sheet. Bake until
delicately browned ... cookies should still be soft. Cool slightly before you
remove them from the baking sheet.
Temperature: 375 F. ( modern oven )
Time: bake 8 - 10 minutes
Amount: 4 - 5 dozen 2" cookies
=====
Personal comments :
I find it tastes better with a mixture of shortening and butter, as they say.
You don't need << all >> of that sugar, and it can be whatever color you want.
The nuts are optional. Feel free to play with the recipe. I put oatmeal in it,
reducing flour accordingly, and sometimes cinnamon.
I also find it useful to grease the cookie sheets.
I think I'm going to go bake some now ...
-- richard
2014-01-11 Eric S. Raymond <esr@thyrsus.com>
* celibacy.1, sex.6, condom.1, echo.msg: Deleted at RMS's
suggestion. Not lost to posterity as they are part of the
widely distributed funny-manpages collection.
* COOKIES, copying.paper, INTERVIEW, MAILINGLISTS, MOTIVATION,
publicsuffix.txt SERVICE: More deletions suggested by RMS.
2014-01-10 Glenn Morris <rgm@gnu.org>
* ORDERS: Replace contents with pointer to emacs.info, mark obsolete.
......
This diff is collapsed.
GNU Project Electronic Mailing Lists and gnUSENET Newsgroups
Last Updated 2006-06-03
Please report improvements to: gnu@gnu.org
See the end of this file for copyright notice and copying conditions
* Mailing list archives
The GNU mailing lists are archived at http://lists.gnu.org.
* Some GNU mailing lists are also distributed as USENET news groups
Certain GNU mailing lists are gated both ways with the gnu.all
newsgroups at uunet. You can tell which they are, because the names
correspond. For instance, bug-gnu-emacs corresponds to gnu.emacs.bug;
info-gnu-emacs, to gnu.emacs.announce; help-gnu-emacs, to
gnu.emacs.help; gnu-emacs-sources, to gnu.emacs.sources. Replacing
`emacs' with some other program in those four examples shows you
the whole pattern.
* How to subscribe to and report bugs in mailing lists
Send requests to be added or removed, to help-gnu-emacs-request (or
info-gnu-request, bug-gdb-request, etc.), NOT to info-gnu-emacs (or
info-gnu, etc.). Most <LIST_NAME>-request addresses are now handled
automagically by GNU Mailman.
If you need to report problems to a human, send mail to gnu@gnu.org
explaining the problem.
Many of the GNU mailing lists are very large and are received by many
people.
If a message you mail to a list is returned from a MAILER-DAEMON (often
with the line:
----- Transcript of session follows -----
don't resend the message to the list. All this return means is that
your original message failed to reach a few addresses on the list. Such
messages are NEVER a reason to resend a piece of mail a 2nd time. This
just bothers all (less the few delivery failures (which will probably
just fail again!)) of the readers of the list with a message they have
already seen. It also wastes computer and network resources.
It is appropriate to send these to the -request address for a list, and
ask them to check the problem out.
* Send Specific Requests for Information to: gnu@gnu.org
Specific requests for information about obtaining GNU software, or GNU
activities in Cambridge and elsewhere can be directed to:
gnu@gnu.org
* General Information about all lists
Do not send very large files to mailing lists; instead put then on a web
page and announce the URL. Good bug reports are short.
See section '* General Information about bug-* lists and ...' for
further details.
The GNU mailing lists and newsgroups, like the GNU project itself, exist
to promote the freedom to share software. So don't use these lists to
promote or recommend non-free software or documentation, like
proprietary books on GNU software. (Using them to post ordering
information is the ultimate faux pas.) If there is no free program to
do a certain task, then somebody should write one! Similarly, free
documentation that is inadequate should be improved--a way in which
non-programmers can make a valuable contribution. See also the article
at <URL:http://www.gnu.org/philosophy/free-doc.html>.
* General Information about info-* lists
These lists and their newsgroups are meant for important announcements.
Since the GNU project uses software development as a means for social
change, the announcements may be technical or political.
Most GNU projects info-* lists (and their corresponding gnu.*.announce
newsgroups) are moderated to keep their content significant and
relevant. If you have a bug to report, send it to the bug-* list. If
you need help on something else and the help-* list exists, ask it.
See section '* General Information about all lists'.
* General Information about help-* lists
These lists (and their newsgroups) exist for anyone to ask questions
about the GNU software that the list deals with. The lists are read by
people who are willing to take the time to help other users.
When you answer the questions that people ask on the help-* lists, keep
in mind that you shouldn't answer by promoting a proprietary program as
a solution. The only real solutions are the ones all the readers can
share.
If a program crashes, or if you build it following the standard
procedure on a system on which it is supposed to work and it does not
work at all, or if an command does not behave as it is documented to
behave, this is a bug. Don't send bug reports to a help-* list; mail
them to the bug-* list instead.
See section '* General Information about all lists'.
* General Information about bug-* lists and reporting program bugs
If you think something is a bug in a program, it might be one; or, it
might be a misunderstanding or even a feature. Before beginning to
report bugs, please read the section ``Reporting Bugs'' in
the GNU Emacs reference manual (or node Bugs in Emacs's
built-in Info system) for a discussion of how and when to send in bug
reports. For GNU programs other than GNU Emacs, also consult their
documentation for their bug reporting procedures. Always include the
version number of the GNU program, as well as the operating system and
machine the program was ran on (if the program doesn't have a version
number, send the date of the latest entry in the file ChangeLog). For
GNU Emacs bugs, type "M-x emacs-version". A debugger backtrace of any
core dump can also be useful. Be careful to separate out hypothesis
from fact! For bugs in GNU Emacs lisp, set variable debug-on-error to
t, and re-enter the command(s) that cause the error message; Emacs will
pop up a debug buffer if something is wrong; please include a copy of
the buffer in your bug report. Please also try to make your bug report
as short as possible; distill the problem to as few lines of code and/or
input as possible. GNU maintainers give priority to the shortest, high
quality bug reports.
Please don't send in a patch without a test case to illustrate the
problem the patch is supposed to fix. Sometimes the patches aren't
correct or aren't the best way to do the job, and without a test case
there is no way to debug an alternate fix.
The purpose of reporting a bug is to enable the bug to be fixed for the
sake of the whole community of users. You may or may not receive a
response; the maintainers will send one if that helps them find or
verify a fix. Most GNU maintainers are volunteers and all are
overworked; they don't have time to help individuals and still fix the
bugs and make the improvements that everyone wants. If you want help
for yourself in particular, you may have to hire someone. The GNU
project maintains a list of people providing such services. It is
found at <URL:http://www.fsf.org/resources/service>.
Anything addressed to the implementers and maintainers of a GNU program
via a bug-* list, should NOT be sent to the corresponding info-* or
help-* list.
Please DON'T post your bug reports on the gnu.*.bug newsgroups! Mail
them to bug-*@gnu.org instead! At first sight, it seems to make no
difference: anything sent to one will be propagated to the other; but:
- if you post on the newsgroup, the information about how to
reach you is lost in the message that goes on the mailing list. It
can be very important to know how to reach you, if there is anything
in the bug report that we don't understand;
- bug reports reach the GNU maintainers quickest when they are
sent to the bug-* mailing list submittal address;
- mail is much more reliable then netnews; and
- if the internet mailers can't get your bug report delivered,
they almost always send you an error message, so you can find another
way to get the bug report in. When netnews fails to get your message
delivered to the maintainers, you'll never know about it and the
maintainers will never see the bug report.
And please DON'T post your GNU bug reports to comp.* or other gnu.*
newsgroups, they never make it to the GNU maintainers at all. Please
mail them to bug-*@gnu.org instead!
* Some special lists that don't fit the usual patterns of help-, bug- and info-
** info-gnu-request@gnu.org to subscribe to info-gnu
gnUSENET newsgroup: gnu.announce
Send announcements to: info-gnu@gnu.org
This list distributes progress reports on the GNU Project. It is also
used by the GNU Project to ask people for various kinds of help. It is
moderated and NOT for general discussion.
** gnu-misc-discuss-request@gnu.org to subscribe to gnu-misc-discuss
gnUSENET newsgroup: gnu.misc.discuss
Send contributions to: gnu-misc-discuss@gnu.org
This list is for serious discussion of free software, the GNU Project,
the GNU Manifesto, and their implications. It's THE place for
discussion that is not appropriate in the other GNU mailing lists and
gnUSENET newsgroups.
Flaming is out of place. Tit-for-tat is not welcome. Repetition
should not occur.
Good READING and writing are expected. Before posting, wait a while,
cool off, and think.
Don't use this group for complaints and bug reports about GNU software!
The maintainers of the package you are using probably don't read this
group; they won't see your complaint. Use the appropriate bug-reporting
mailing list instead, so that people who can do something about the
problem will see it. Likewise, use the help- list for technical
questions.
Don't trust pronouncements made on gnu-misc-discuss about what GNU is,
what FSF position is, what the GNU General Public License is, etc.,
unless they are made by someone you know is well connected with GNU and
are sure the message is not forged.
USENET and gnUSENET readers are expected to have read ALL the articles
in news.announce.newusers before posting.
Remember, "GNUs Not Unix" and "gnUSENET is Not USENET". We have
higher standards!
** gnu-emacs-sources-request@gnu.org to subscribe to gnu-emacs-sources
gnUSENET newsgroup: gnu.emacs.sources
GNU Emacs source code to: gnu-emacs-sources@gnu.org
This list/newsgroup will be for the posting, by their authors, of Emacs
Lisp and C sources and patches that improve GNU Emacs. Its contents
will be reviewed by the FSF for inclusion in future releases of GNU
Emacs.
Please do NOT discuss or request source code here. Use
help-gnu-emacs/gnu.emacs.help for those purposes. This allows the
automatic archiving of sources posted to this list/newsgroup.
Please do NOT post such sources to any other GNU mailing list (e.g
help-gnu-emacs) or gnUSENET newsgroups (e.g. gnu.emacs.help). It's up
to each poster to decide whether to cross-post to any non-gnUSENET
newsgroup (e.g. comp.emacs).
Please do NOT announce that you have posted source code to
gnu.emacs.sources to any other GNU mailing list (e.g. help-gnu-emacs) or
gnUSENET newsgroups (e.g. gnu.emacs.help). People who want to keep up
with sources will read this list/newsgroup. It's up to each poster to
decide whether to announce a gnu.emacs.sources article in any
non-gnUSENET newsgroup (e.g. comp.emacs).
If source or patches that were previously posted or a simple fix is
requested in help-gnu-emacs, please mail it to the requester. Do NOT
repost it. If you also want something that is requested, send mail to
the requester asking him to forward it to you. This kind of traffic is
best handled by e-mail, not by a broadcast medium that reaches millions
of sites.
If the requested source is very long, send mail offering to
send it. This prevents the requester from getting many redundant copies
and saves network bandwidth.
Local variables:
mode: outline
fill-column: 72
End:
Copyright (C) 1999, 2001-2014 Free Software Foundation, Inc.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this file, to deal in the file without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the file, and to
permit persons to whom the file is furnished to do so, subject to
the following condition:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the file.
STUDIES FIND REWARD OFTEN NO MOTIVATOR
Creativity and intrinsic interest diminish if task is done for gain
By Alfie Kohn
Special to the Boston Globe
[reprinted with permission of the author
from the Monday 19 January 1987 Boston Globe]
Verbatim copying and distribution is permitted in any medium
provided this notice is preserved.
In the laboratory, rats get Rice Krispies. In the classroom the top
students get A's, and in the factory or office the best workers get
raises. It's an article of faith for most of us that rewards promote
better performance.
But a growing body of research suggests that this law is not nearly as
ironclad as was once thought. Psychologists have been finding that
rewards can lower performance levels, especially when the performance
involves creativity.
A related series of studies shows that intrinsic interest in a task -
the sense that something is worth doing for its own sake - typically
declines when someone is rewarded for doing it.
If a reward - money, awards, praise, or winning a contest - comes to
be seen as the reason one is engaging in an activity, that activity
will be viewed as less enjoyable in its own right.
With the exception of some behaviorists who doubt the very existence
of intrinsic motivation, these conclusions are now widely accepted
among psychologists. Taken together, they suggest we may unwittingly
be squelching interest and discouraging innovation among workers,
students and artists.
The recognition that rewards can have counter-productive effects is
based on a variety of studies, which have come up with such findings
as these: Young children who are rewarded for drawing are less likely
to draw on their own that are children who draw just for the fun of
it. Teenagers offered rewards for playing word games enjoy the games
less and do not do as well as those who play with no rewards.
Employees who are praised for meeting a manager's expectations suffer
a drop in motivation.
Much of the research on creativity and motivation has been performed
by Theresa Amabile, associate professor of psychology at Brandeis
University. In a paper published early last year on her most recent
study, she reported on experiments involving elementary school and
college students. Both groups were asked to make "silly" collages.
The young children were also asked to invent stories.
The least-creative projects, as rated by several teachers, were done
by those students who had contracted for rewards. "It may be that
commissioned work will, in general, be less creative than work that is
done out of pure interest," Amabile said.
In 1985, Amabile asked 72 creative writers at Brandeis and at Boston
University to write poetry. Some students then were given a list of
extrinsic (external) reasons for writing, such as impressing teachers,
making money and getting into graduate school, and were asked to think
about their own writing with respect to these reasons. Others were
given a list of intrinsic reasons: the enjoyment of playing with
words, satisfaction from self-expression, and so forth. A third group
was not given any list. All were then asked to do more writing.
The results were clear. Students given the extrinsic reasons not only
wrote less creatively than the others, as judged by 12 independent
poets, but the quality of their work dropped significantly. Rewards,
Amabile says, have this destructive effect primarily with creative
tasks, including higher-level problem-solving. "The more complex the
activity, the more it's hurt by extrinsic reward," she said.
But other research shows that artists are by no means the only ones
affected.
In one study, girls in the fifth and sixth grades tutored younger
children much less effectively if they were promised free movie
tickets for teaching well. The study, by James Gabarino, now
president of Chicago's Erikson Institute for Advanced Studies in Child
Development, showed that tutors working for the reward took longer to
communicate ideas, got frustrated more easily, and did a poorer job in
the end than those who were not rewarded.
Such findings call into question the widespread belief that money is
an effective and even necessary way to motivate people. They also
challenge the behaviorist assumption that any activity is more likely
to occur if it is rewarded. Amabile says her research "definitely
refutes the notion that creativity can be operantly conditioned."
But Kenneth McGraw, associate professor of psychology at the
University of Mississippi, cautions that this does not mean
behaviorism itself has been invalidated. "The basic principles of
reinforcement and rewards certainly work, but in a restricted context"
- restricted, that is, to tasks that are not especially interesting.
Researchers offer several explanations for their surprising findings
about rewards and performance.
First, rewards encourage people to focus narrowly on a task, to do it
as quickly as possible and to take few risks. "If they feel that
'this is something I have to get through to get the prize,' they're
going to be less creative," Amabile said.
Second, people come to see themselves as being controlled by the
reward. They feel less autonomous, and this may interfere with
performance. "To the extent one's experience of being
self-determined is limited," said Richard Ryan, associate psychology
professor at the University of Rochester, "one's creativity will be
reduced as well."
Finally, extrinsic rewards can erode intrinsic interest. People who
see themselves as working for money, approval or competitive success
find their tasks less pleasurable, and therefore do not do them as
well.
The last explanation reflects 15 years of work by Ryan's mentor at the
University of Rochester, Edward Deci. In 1971, Deci showed that
"money may work to buy off one's intrinsic motivation for an activity"
on a long-term basis. Ten years later, Deci and his colleagues
demonstrated that trying to best others has the same effect. Students
who competed to solve a puzzle quickly were less likely than those who
were not competing to keep working at it once the experiment was over.
Control plays role
There is general agreement, however, that not all rewards have the
same effect. Offering a flat fee for participating in an experiment -
similar to an hourly wage in the workplace - usually does not reduce
intrinsic motivation. It is only when the rewards are based on
performing a given task or doing a good job at it - analogous to
piece-rate payment and bonuses, respectively - that the problem
develops.
The key, then, lies in how a reward is experienced. If we come to
view ourselves as working to get something, we will no longer find
that activity worth doing in its own right.
There is an old joke that nicely illustrates the principle. An
elderly man, harassed by the taunts of neighborhood children, finally
devises a scheme. He offered to pay each child a dollar if they would
all return Tuesday and yell their insults again. They did so eagerly
and received the money, but he told them he could only pay 25 cents on
Wednesday. When they returned, insulted him again and collected their
quarters, he informed them that Thursday's rate would be just a penny.
"Forget it," they said - and never taunted him again.
Means to and end
In a 1982 study, Stanford psychologist Mark L. Lepper showed that any
task, no matter how enjoyable it once seemed, would be devalued if it
were presented as a means rather than an end. He told a group of
preschoolers they could not engage in one activity they liked until
they first took part in another. Although they had enjoyed both
activities equally, the children came to dislike the task that was a
prerequisite for the other.
It should not be surprising that when verbal feedback is experienced
as controlling, the effect on motivation can be similar to that of
payment. In a study of corporate employees, Ryan found that those who
were told, "Good, you're doing as you /should/" were "significantly
less intrinsically motivated than those who received feedback
informationally."
There's a difference, Ryan says, between saying, "I'm giving you this
reward because I recognize the value of your work" and "You're getting
this reward because you've lived up to my standards."
A different but related set of problems exists in the case of
creativity. Artists must make a living, of course, but Amabile
emphasizes that "the negative impact on creativity of working for
rewards can be minimized" by playing down the significance of these
rewards and trying not to use them in a controlling way. Creative
work, the research suggests, cannot be forced, but only allowed to
happen.
/Alfie Kohn, a Cambridge, MA writer, is the author of "No Contest: The
Case Against Competition," recently published by Houghton Mifflin Co.,
Boston, MA. ISBN 0-395-39387-6. /
GNU Service Directory
---------------------
Please see <http://www.fsf.org/resources/service/> for a list of
people who have asked to be listed as offering support services for
GNU software, including GNU Emacs, for a fee or in some cases at no
charge.
Note added January 2014:
This file is obsolete and will be removed in future.
Please update any links to use the above URL.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment