Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Call for Mnemonics

10 views
Skip to first unread message

ubc-visi!majka

unread,
Apr 17, 1983, 4:08:11 AM4/17/83
to

I am interested in sentence or rhyme mnemonics for interesting sequences.
For example:

King Phillip came over for good soup.
for: Kingdom Phylum Class Order Family Genus Species
(Taxonomy)

or: Toronto girls can flirt and only quit to chase dwarves.
for: Talc Gypsum Calcite Flurite Appetite Orthoclase Quartz Topaz Corumdum
Diamond
(Hardness)

I recall that a few of these were submitted to net.jokes some time ago, but
I would like to compile a list of them. If you have got a good one, please
mail it to me. I will post a complete list to the net in a few weeks.

Thanks in advance,
Marc Majka [ubc-vision!majka]

ritcv!kar

unread,
Apr 17, 1983, 11:56:59 PM4/17/83
to

In response to the call for mnemonic sentences, here's the version I
heard of the sentence used by many to help them remember sequence of colors
with which resistor values are coded:

Bad boys rape our young girls, but virgins give willingly.

Black 0
Brown 1
Red 2
Orange 3
Yellow 4
Green 5
Blue 6
Violet 7
Gray 8
White 9

Ken Reek, Rochester Institute of Technology
ucbvax!allegra!rochester!ritcv!kar

eagle!karn

unread,
Apr 18, 1983, 2:33:31 AM4/18/83
to
Regarding the mnemonic for resistor color codes, I had learned a slightly
refined version of the same sentence:

Bad boys ruin our young girls, but Violet goes willingly.

Phil

mhb5b!gsp

unread,
Apr 18, 1983, 6:10:54 PM4/18/83
to
In my travels through /usr/src/cmd, I have seen some pretty obscure
algorithms, and some pretty messy code. The programs work, so they
are there, but no one dares tries to change them. My favorite examples
is cal.c, then comes find.c. I once made a minor change in a spelling
correction program and the program did not work. I then found that the
saved original source code would not compile into a working binary. The
worst part was that I was defending in a week and some one on my thesis
committee was on my back to fix the mess I had stepped in. Our local
wizard looked at the code and said, "This function expects a parameter
but is never sent one!" changed it, and the program worked again. My
conclusion is:

Only a perfect program or a really messy program never changes.

The perfect ones are few (perhaps cal is perfect), and unfortunately,
the messy ones are common (insert your favorite here).

Gary Perlman BTL MH 5D-105 (201) 582-3624 [ucbvax!]mhb5b!gsp

ihnss!warren

unread,
Apr 22, 1983, 3:00:30 AM4/22/83
to
I have always heard "Program Entropy" referred to as "bit rot". It
is a serious and ubiquotous phenomenon of computing systems. Any
working program will in time tend to deteriorate if not periodically
cared for. The minimal level of care requires periodic
recompilation and fixing the bugs you discover.

There are several sources of bit rot:

1) Compiler evolution (How many C programs still have things
like "int foo 3;" in them?)

2) Operating system or other execution environment evolution.

3) Random bit errors in the source or object. (How many times
have you really been able to recover a backup copy of
something that you didn't touch in more than 2 years?)

4) Time bombs, like the infamous clock overflow bug that
crashed a large number of OS/360 systems sometime in the
70's.

The major complicating factor is that typically only one person
understood how the original worked and has probably left by the time
that bit rot occurs. Its not clear that she/he still understands
it, even if available for repair.

The only known technique for preventing bit rot is to hermetically
seal the system, preventing the introduction of elements that
promote rot. This is why bit rot is more severe in academic,
research, and program development environments, where the latest
version of everything is always used, than in comercial
environments, where a system gets installed for a purpose and then
just sits there doing that job.

--

Warren Montgomery
ihnss!warren
IH x2494

watcgl!dmmartindale

unread,
Apr 23, 1983, 3:55:09 AM4/23/83
to
Uucp may suffer from bit rot, but it also suffers from having lots of holes
in its code that don't have any guardrails around them.
For example, try getting a transmission error that garbles your system
name during the initial handshaking before the packet driver is operating.
The uucico on the other end will happily talk to you, accept each file
you offer, and then probably throw it away since the machine name it thought
it got isn't in USERFILE. Worst of all, you pay for all the transmission
time to send the stuff before it gets thrown away.

Dave Martindale

amd70!pn

unread,
Apr 25, 1983, 5:18:49 PM4/25/83
to
Don't most USERFILEs allow everyone to do what anyone can do? If they
do, then having the system name garbled during the initial handshake
won't affect anything. Note that if there is noise and the packet driver
is invoked, your transmission costs will probably be higher than normal
because of all the retries, adding insult to injury when the files are
thrown away.

Still a novice at UUCP
Phil Ngai

0 new messages