Re: Off switch blues

In article <uce-D76880.17284631102008@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Gregory Weston <uce@xxxxxxxxxx> wrote:

In article <barmar-8DFE7A.15223831102008@xxxxxxxxxxxxxxxxxxxxx>,
Barry Margolin <barmar@xxxxxxxxxxxx> wrote:

In article <uce-202D2B.11051431102008@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Gregory Weston <uce@xxxxxxxxxx> wrote:

In article <barmar-6D292D.20524630102008@xxxxxxxxxxxxxxxxxxxxx>,
Barry Margolin <barmar@xxxxxxxxxxxx> wrote:

But it's defeats the object of a quick shut down / restart
cycle
if I have to unplug all usb (and prehaps firewire as well)
devices. I say: it's not a feature it's a bug.

Bugs are by definition unintended behavior. You're describing
intended behavior. The fact that you don't like it doesn't make
it a bug. If you can document that this does more harm than good
in the general case, the proper term is a misfeature.

What you're describing is an implementation bug.

Not in this case. In this case it's a correct implementation of a
justified design.

What I meant was that when you said that a bug is "unintended
behavior",
you were referring to implementation bugs.

Please don't tell me what I meant. It's quite rude, especially when it
contradicts what I've told you I meant.

Your message was very clear about what you meant, you gave a precise
definition. I was just pointing out that this definition did not apply
in the context, because the previous poster was using the word in a
different sense than your definition.

AKA: A wrong sense. That's why I responded with a correction and offered
alternative terminology. The definition I gave *is* the definition of
"bug" in the context of computers. The fact that some people misuse it
doesn't change the meaning, just as the meaning of "niggardly" isn't

If enough people misuse it, it DOES change the meaning. Many words we
use today don't mean what they means a few centuries ago, and in some
cases just a few decades ago. "Computer hacker" doesn't mean what it
meant when I was in college 25 years ago; back then I would have been
proud to call myself one, now it has taken on negative connotations due
to the way most people use it.

changed by people who think it's an ethnic slur. As I wrote before, if
you can demonstrate that an intended behavior is in general a net
liability, you can call it a misfeature. There is no term for "doesn't
act the way this one guy in Sheboygan expected it to." Nor should there
be.

So what's the word for "doesn't act the way many (maybe even most) users
would expect"? I guess we could say "counter-intuitive behavior", but
that doesn't roll off the tongue as easily as "bug". Perhaps we could
just say "wrong".

Suppose the specifications for a word processor say that the Edit->Copy
command should cut, and Edit->Cut should copy. If you're the programmer
and you implement this, you haven't done anything wrong. But whoever
wrote that specification certainly did. Few users would expect these
commands to behave this way. This is clearly a bug in the specification
(except maybe in some exceptional cases, like the program is intended as
an April Fool's Day joke).



There are other types of
bugs, for which that is not the definition. A design bug could be
defined as unwanted or unexpected (by the user) behavior.

You're using a very loose definition of the term "bug" when you start
talking about deviations from user expectation. It largely depends on
how well-founded the user's expectations were in the first place.

Yes, the word "bug" has a loose definition.

But it doesn't. It means unintended behavior.

The dictionary on my Mac says "an error in a computer program or
system". There are lots of kinds of errors.

But going with your definition, who decides what's intended? It
obviously didn't do what the OP intended. When I put my laptop to
sleep, close the lid, and unplug the keyboard, it's because I intend to
STOP using it. I don't intend for it to wake back up until I open the
lid. It doesn't wake up if I unplug it in the first few seconds (while
it's still in the process of going to sleep), but if I wait too long
(when it actually achieves sleep) it wakes back up. That makes me think
that the designers didn't really intend that unplugging a keyboard
should always wake up the computer.

I believe that this is an unintended side effect of the hardware
requirement that the computer wake up to check what kind of USB event it
received.

What it means to a software
or hardware developer is different from what it means to an end user,
especially if he wan't included in the process of writing the
specifications. He has no way of knowing what the intended behavior is,
his only point of view is the end user documentation (does any manual
that comes with a Mac go into this level of detail) and his intuitive
expectations. It's simply not reasonable to expect a discussion in this
group to refer to the kind of bug you defined.

Then a different word should be used, because what you're describing is,
simply, not a bug. There have to be definitions, because if there aren't
there's no way to have meaningful communication. There's no sensible way
the definition of bug could encompass every situation where the behavior
of a piece of software deviates from the unjustified expectations of any
single user because *every* single user has a different set of
expectations. Where's the bug when one person expected the observed
behavior and another didn't? If you can give a supportable answer to
that question - perhaps some explanation of how such a bug could ever be
fixed, since otherwise there's no point in even identifying it - I'll
accept that "bug" can be used they way you describe.


What Apple *could* do is wake up, notice that the event was just a
disconnection, and then go back to sleep automatically since that
obviously can't be an intentional way to wake the computer.

Why is that obvious? Serious question. How do you know that nobody would
ever want their machine to actually do something significant in response
to a device being removed from the bus even if the machine happened to
be asleep when it happened.

It seems like common sense to me. What possible reason could someone
want for removing a device to wake the machine from sleep?

I don't pretend to have perfect knowledge of everything every user or
peripheral developer in the world might want to do in response to some
random system event. Perhaps it's something as simple as wanting to log
the fact that it happened. Considering the range of hardware than can
today be hooked up via USB, let's say I simply don't feel comfortable
pronouncing that there might be some event to which no one could
possibly want to react.

So it logs that it happened and goes back to sleep, like I said.

The issue isn't that it wakes up (the USB architecture effectively
requires this), the problem is that it STAYS awake, even though the user
hasn't taken any action that could reasonably be interpreted as wanting
to use the computer. He hasn't typed anything, opened the lid, or moved
the mouse.

You can always come up with weird cases that 0.1% of the time might be a
reason to wake up, but that doesn't mean it's a good idea to implement
the system that way. Default behavior should handle the normal cases,
not one-in-a-million situations that few users would expect.

--
Barry Margolin, barmar@xxxxxxxxxxxx
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
.