Linux-Advocacy Digest #246, Volume #27 Thu, 22 Jun 00 01:13:07 EDT
Contents:
Re: Why We Should Be Nice To Windows Users -was- Neologism of the day ("Rich C")
Re: Linsux as a desktop platform ([EMAIL PROTECTED])
Re: Windows98 ("Bobby D. Bryant")
Re: Stupid idiots that think KDE is a Window Manager
Re: Linux MUST be in TROUBLE ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Rich C" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,talk.bizarre
Subject: Re: Why We Should Be Nice To Windows Users -was- Neologism of the day
Date: Thu, 22 Jun 2000 01:04:11 -0400
"Christopher Smith" <[EMAIL PROTECTED]> wrote in message
news:8irrvl$v5m$[EMAIL PROTECTED]...
>
> "Rich C" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Of course it is. It is still a GUI even in the absence of keyboard
> > shortcuts.
>
> And is just as much a GUI with them, or in the absence of a mouse.
>
It is just as much of a GUI with them, but in the absense of a graphical
input device, it is only half a GUI. And it is only half useful too, as
anyone who's ever tried to operate Windows without a mouse (don't know about
the MAC.)
> [chomp]
>
> > > > It's only HALF a GUI: the output is GUI the input is CLI, because
you
> > have
> > > > to know the shortcuts, or commands, to access the graphical
elements.
> > >
> > > Which is somehow different to knowing you have to move and click the
> mouse
> > > *how*, exactly ?
> >
> > By moving the mouse and clicking buttons it immediately becomes evident
> what
> > the functions do. Trying to empirically discover the keyboard commands
by
> > hitting keys at random, especially in combination, is much more
difficult.
> > In this instance, help or knowledge is required.
>
> But you don't need to. Keyboard commands are highlighted within the GUI
by
> underlined letters on controls and keyboard shortcuts listed in menues.
So where is it highlighted that you need the ALT key to open a menu? Where
is it highlighted that ALT-SPACE opens the control menu? Where is it
highlighted that backspace moves you up to the parent folder?
>
> No more knowledge is needed than that which was needed to figure out hwo
to
> use a mouse in the first place.
So I can sit you down in front of a strange GUI, and, because you know how
to use the mouse, you can figure out EVERY embedded keyboard command without
using help?
I'd love to see that.
>
> > > What's the big different between the input device with 2 buttons, and
> the
> > > one with 102 ?
> >
> > one works with graphical feedback; the other does not. Clicking the
mouse
> > to obtain the proper result depends on WHERE the mouse pointer is
located
> on
> > the screen.
>
> And hitting the keys require hitting the right ones, the difference ?
OK, let's try this a different way. In a given program, an embedded command
will work, *regardless* of where you are in your document, drawing, or
whatever; regardless of where you are in the program. With a mouse, which is
a GUI input device, you NEED the graphical feedback of the mouse pointer to
use it. I don't know how many times I've been able to shut down Windows
_from the keyboard_ when I couldn't even SEE the desktop because of a video
problem. Using the mouse in this case was impossible. The mouse requires
visual feedback to operate. The embedded CLI doesn't. The mouse is a GUI
device. The keyboard is a command device. Understand?
>
> You have to know where to click and you have to know what buttons to
press.
>
> > > > So how would you "tell" the machine where to focus?
> > >
> > > Well in the case of a dialog it would probably be focussed
> automatically.
> > > To switch focus you'd probably say something like the title of the
> window.
> > > I can't say I've put much thought into it - current technology is
*way*
> > too
> > > immature to develop a usable voice control system.
> >
> > If you did, you'd realize that voice control is more conducive to
> generating
> > commands than visual cues, and that something like a retinal scanner
would
> > be a more appropriate input device for a GUI.
>
> All interfaces use commands. With a voice controlled GUI you'd need a
> system with enough programming smarts to be able to determine the context
of
> the command.
That's true. The reason there are no good scripting languages for GUIs is
that it is impossible to translate mouse movements reliably into a command
string. The scripting languages that exist work better when you use embedded
commands rather than mouse input.
>
> > > You certainly wouldn't be doing something like maneuvering a mouse
> cursor
> > > around with voice commands, that's just plain dumb - it'd be like
using
> a
> > > mouse to pick out letters to enter commands into a CLI.
> >
> > My point exactly. :o)
>
> But that's not how you'd use voice control in a GUI - *my* point exactly.
Right. You'd give the computer direct command input--not GUI input.
>
> > > > To me, it is more
> > > > natural to command the machine via voice commands, "Open file FOO in
> > > folder
> > > > BAR." or "Email file FOO to John Doe."
> > >
> > > There's no reason why you couldn't do that with a GUI.
> >
> > But _how_ exactly?
>
> By giving the commands. The *computer* is smart enough to figure out what
> the file FOO is, who John Doe is and what the email program is.
So where did the GUI come into play in all that? You simply gave the
computer commands.
>
> > Once you actually begin to think about it, it becomes
> > unwieldy to manipulate a graphical interface with voice commands.
>
> Only if you make it that way.
Once you eliminate the awkwardness of manipulating the interface
graphically, you've bypassed the GUI and translated voice commands into
embedded CLI commands.
>
> > > > While reading text may indeed be visual, speaking to a computer is
> not.
> > > > Words translate more readily into commands than they do to the "n"th
> > item
> > > in
> > > > a list or a button in a specific place on the screen.
> > >
> > > That would be a really poor way to implement voice control. There's
no
> > > reason to do it like that even with the limits of today's technology.
> >
> > So you might say, "Menu....File.....open......documents
> > folder.....proposals....foo.doc"?
> >
> > Or would you say "Open folder documents, subfolder proposals, file
> FOO.doc"?
> >
> > Which one is more like a command?
>
> They're *all* like commands, that's my point.
>
> > > > Actually, all digital logic consists of a zero state (off) a one
state
> > > (on)
> > > > and the gray area in between where the output is unpredictable.
> > >
> > > That output isn't unpredictable, it's ignored. Ergo the end product
is
> > one
> > > of two things - a 1 or 0.
> >
> > No, it's not ignored. If you have a gate output that can be either a
high
> or
> > a low, and your input is in the gray area, the output MUST by definition
> be
> > a high or a low. Dependent on variables such as ambient temperature,
> supply
> > voltage fluctuations, and manufacturing tolerances in the chip, a given
> > input level in the gray area can cause a high level output or a low
level
> > output, and it is impossible to predict which it will be. Thus the
output
> is
> > unpredictable.
>
> No, it's perfectly predictable - it'll be either a 1 or a 0, nothing else.
> It won't be 0.5, it won't be 1.2.
"Either a 1 or a 0"? ROFL!!! That's some prediction, Mr. Cacey! The point is
not to predict that it will be one of it's allowed states; the point is to
predict WHICH state. If you can't predict WHICH state the output will be
with an out-of-tolerance input, the output is unpredictable. An analogy to
your logic is my saying, "I can predict with absolute certainty that if you
flip a coin it will land either heads or tails."
>
> > > > IMHO, the CLI would be easier to implement and easier to use.
> > >
> > > Easier to implement, certainly.
> > > Easier to use, entirely dependent on implementation.
> >
> > Aren't products that are simple implementations inherently simpler to
use?
>
> No. Compare edlin to something like EDIT.
I found edlin to be a snap.
>
> > > Easier to *learn*, highly doubtful.
> >
> > I think an implementation that is a straightforward translation of one
> > concept into a similar one is easier to learn than one that is
translated
> > from one class of mental activity (aural processing) to another one
> > (visualization.)
>
> But it wouldn't be done like that. You'd be issuing the same commands to
> the GUI, just through a different medium.
Yes, you'd be issuing _commands_. Since you don't seem to understand the
difference between GUI input, where visual feedback of a pointer is integral
to using the device for input, and command input which is independent of
visual feedback--the commands work the same regardless of the cursor
position on the screen, I can't explain the difference to you.
>
> > > Be careful about the distinction between easy to learn and easy to
use,
> > they
> > > are very different things.
> >
> > I think I understand the difference. ;o)
>
> I'm unsure you do.
A GUI is easy to learn, but a CLI is easy to use. Satisfied?
>
> > > Oh I doubt that. That might have been true 5 years ago, but modern
> > machines
> > > are quite fast enough to display GUIs.
> >
> > Yes, but manipulating a graphic display DOES take more processor
overhead,
> > even with a dedicated hardware video processor. So "faster" may not be
> > perceptible to the operator, but there would be more processing time to
do
> > other things.
>
> In an interface, perceptible to the operator is all that really matters.
>
> If someone's reaction time is only 0.15s, what does it matter if the
> operation completes in 0.5s or 0.7s ? They're not going to know the
> difference.
When there is processor-intensive activity going on, the high-overhead GUI
will suffer more than the low-overhead CLI in terms of perceived
sluggishness.
>
> Yes, in the former example the CPU might have a few million cycles spare,
> but what is it going to do with them except twiddle its thumbs ?
>
> > > > No, it's a graphical presentation. How would you "interface" to it?
> > >
> > > Any way you want. DOesn't change the fact it's graphical.
> >
> > But it's only half of the interface.
>
> It's the only half that concerns us. "Graphical" is only referring to the
> presentation.
Wrong. Graphical input refers to the process of using visual feedback to
place the pointer in the proper place to effect the desired input. With
graphical input you CAN'T provide input to the computer without the visual
feedback of the cursor position, whereas with COMMAND input, the cursor
position doesn't matter. I can shut down Windows via the keyboard without
having a working display. With the mouse this is impossible.
>
> > If I defined commands to manipulate the
> > display, I could do so with no visual feedback. i could type "rotate 90"
> or
> > "zoom 200" and predict what the result would be. But If I used mouse
> > commands, I would have to have visual feedback, i.e., know the position
of
> > the pointer, before I could select the zoom command or the rotate
command.
> > Thus the mouse is a graphical input device, while the keyboard is a
> command
> > input device.
>
> They're *both* command input devices.
...that work completely differently. GUI input relies on visual cues.
Keyboard input does not.
>
> Using the mouse to, for example, rotate an image by dragging it is no
> different to using the keyboard arrows to rotate it.
Then do it without looking at the screen. Then go back and see how
successful you were.
>
> > > > Not if you're waiting for the next level of dialog box to appear
> (which
> > > > happens frequently to users with slow systems.)
> > >
> > > No, I don't have to wait - that's my point. The system is fast enough
> to
> > > display whatever the next thing is before I can decide what to do with
> it.
> >
> > Of course. You couldn't possibly decide what to do until you SEE your
> > choices. It's sequential processing, unlike the command line, where you
> give
> > the computer ALL your input at once.
>
> Most all interactive use is sequential processing, so that's really fairly
> irrelevant.
Not at all. (
>
> > > There's nothing I can think of that I do on my system I can't do that
> with
> > > in a GUI. Since 99% of all my use is interactive, the dialogs you
refer
> > to
> > > are essential to actually using the thing.
> > >
> > > Indeed, there's no inherent reason a GUI would exhibit the behaviour
you
> > > have described.
> >
> > Oh, so you've never gotten up from your computer after starting a
lengthy
> > operation, only to come back 5 minutes later and find the computer had
not
> > started the task yet because you neglected to answer a confirmation
> dialog?
>
> Only when that confirmation dialog was relaying important information, eg
> overwriting an existing file.
The importance of the dialog is irrelevant. What IS relevant is that the
lengthy task wasn't started because you got up from the computer too soon.
>
> > Happens to me in Windows ALL the time.
> >
> > >
> > > > > Sure, you can plonk NT4+IE4 on a 486/16 with 12MB of RAM and it'll
> > just
> > > > > about run backwards, but that's not inherently the *GUI's* fault.
> > > >
> > > > In a way, it is, because the GUI is taking resources that are not
> > > abundant,
> > > > thus adding to the lethargy.
> > >
> > > That doesn't hold. By that logic a CLI is bad because it's slow on an
> XT.
> >
> > It would be if there were something faster to run on the XT, but there
> > isn't.
>
> Sure there is. A purpose written program to do whatever it is you want to
> do.
What??? How does such a program replace the OS and the command line
interface? How do you run the program? How do you run OTHER programs?
>
> > The interface should interfere with the execution of the task as
> > little as possible. This is where Microsoft (and Apple to a lesser
extent)
> > fall on their faces: The OS is NOT the end, it is only the means.
>
> The interface doesn't interfere with the task, it provides feedback.
If it's taking up unnecessary resources that the task might need while
providing that feedback, it most certainly IS interfering.
>
> > > > That's why Linux with a CLI runs so well on
> > > > said 486/16 with 12 meg of RAM.
> > >
> > > Well, it runs. I wouldn't call it "well" if you're actually _using_
the
> > > thing.
> >
> > The response time of the interface is negligible in human terms, so I
> would
> > call it running "well." (And I _have_ said 486 running said Linux, so I
> > speak from experience.)
>
> I have one too, and there's not much you'd be doing on it interactively
that
> I could describe as "runs well".
Well, mine serves my web pages, prints my print jobs, and it still runs the
interface just fine.
>
> [chomp]
>
> > > > Now, if
> > > > the menu interface were a *touch screen,* I would agree that that
was
> a
> > > GUI.
> > >
> > > Personally I can't see how it would make a difference. A touch screen
> is
> > > just like having a mouse, without the mouse.
> >
> > Exactly. Successful use of the interface depends on visual cues, i.e.,
> your
> > finger's position relative to the "buttons" you want to press. This is
> just
> > like the mouse, where clicking the button successfully depends on the
> visual
> > cue of whether the pointer is over the button you want.
> >
> > >
> > > How about a touch screen with a keyboard on, say, the bottom half of
it
> ?
> > > Where does that fit in ?
> >
> > It's a GUI, because the "keys" are dependent on graphical display
output.
> If
> > the display moved or the key orientation changed, as a result of program
> > output, your actions relative to those keys would change. What you do in
a
> > GUI is totally dependent on visual feedback.
>
> This is different to a keyboard on your desk _how_, exactly ?
One depends on visual feedback; the other doesn't.
>
> What about two screens, one for display and one for the keyboard ?
Makes no difference.
>
> > > > Not necessarily. There are CLIs where you can simply type "copy" and
> hit
> > > > Enter and the interface will come back with "From:" at which point
you
> > > type
> > > > "foo.txt" and hit Enter and the interface comes back with "To:" Type
> > your
> > > > destination and hit Enter. You don't always have to know the entire
> > > command
> > > > syntax up front to use the interface.
> > >
> > > But you still have to know eg. what the files are.
> >
> > So you do with a GUI. To find a file, you have to know which folder to
> > click. To copy a file, you have to know the file name, or at least a
part
> of
> > it, to select it.
>
> But the files are already there, you just have to pick them. That's
> different from having to know what they are _first_.
>
> > > > The CLI we developed for the security guards (mentioned in a
parallel
> > > thread
> > > > I think) allowed initiation of a conversation by simply typing the
> > command
> > > > string (3 letters) and the system would prompt the user with lists
of
> > > > options for each parameter. Alternately, the entire string could be
> > typed
> > > on
> > > > one line, if the user knew what the options (s)he wanted.
> > >
> > > This is where you move into the fuzzy area. In one way it's a CLI and
> in
> > > another, a GUI.
> >
> > It's not fuzzy if you have 20/20 eyesight ;o) There is no visual
feedback
> in
> > terms of highlights of the default choice; you can't visually pick your
> > options; you have to type the command fragment (from the displayed
list.)
> It
> > is a prompted CLI, NOT a GUI.
>
> You are picking your options. _How_ you pick them is not relevant.
Oh yes it is. If you're using visual cues from the graphical display, you
are using GUI input. If you are typing static commands that are immune to
the state of the display, you are using command input. That's the whole
point. There IS a difference. One is visual, and one is not.
>
> > I think you would call any interface that is intuitive and easy to use a
> > GUI, and any interface that is obscure and unhelpful a CLI. This is
> > prejudicial in my view.
>
> No, I wouldn't. I'd hardly vi intuitive and helpful, but it's a lot more
of
> a GUI than edlin is.
>
> I think you'd call any more efficient method of using a GUI except the
mouse
> a CLI, because you have some inherent need to believe that a CLI is more
> efficient than a GUI. That, to me, is very prejudiced.
No, I don't _need_ to believe a CLI is more efficient. If the windows
keyboard shortcuts were 27 letters each and required three hands to execute,
I would still call them a CLI. I'd also call them stupid and ill-conceived,
but I would still call them a CLI.
>
> However, I don't really see how amateur psychology is relevant.
Of course it's relevant. The key to winning any argument is convincing the
other party he doesn't know what he's talking about.
>
>
-- Rich C.
"Great minds discuss ideas.
Average minds discuss events.
Small minds discuss people."
>
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Wed, 21 Jun 2000 23:56:38 -0500
On Thu, 22 Jun 2000 01:48:29 GMT, [EMAIL PROTECTED] () wrote:
>On Wed, 21 Jun 2000 19:37:36 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>On 21 Jun 2000 18:51:43 -0500, [EMAIL PROTECTED] (Leslie Mikesell)
>>wrote:
>>
>>>In article <[EMAIL PROTECTED]>,
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>>>> What other security is there besides XHost +hostname for limiting who
>>>>>> can redirect your X server or plug into your X server?
>>>>>
>>>>>There are three direct authentication systems: xhost, cookies, and
>>>>>Kerberos.
>>>>>Indirect protection could be developed through the use of a VPN, or for
>>>>>those on a budget, SSL.
>>>>
>>>>Wouldn't it be wonderful if this was easier to set up? Terminal
>>>>Server is a breeze - just install it, and you're then done. Why can't
>>>>Linux be this easy?
>>>
>>>Errr, it is. You just install ssh if you don't already have it
>>>installed and it takes care of the xauthority setup and X
>>>redirection for you when you use it for remote connection. And
>>>of course if you are doing something remotely over a
>>>low bandwidth connection that can be done in character mode
>>>you don't need to bother with the GUI at all.
>>
>>There's nothing easy about it.
>
> Bullshit. It's the default configuration of ssh. What takes
> a clue is figuring how NOT to have that X redirection pipe
> active.
Sorry; here we're defining easy as Windows Terminal Server setup,
where you install it, then install the client, then put in the machine
name of the server on the client, all via the GUI. Compared to that,
I just don't think it's easy.
------------------------------
From: "Bobby D. Bryant" <[EMAIL PROTECTED]>
Subject: Re: Windows98
Date: Wed, 21 Jun 2000 23:00:40 -0500
Bond, James Bond wrote:
> In the
> company I work for we run Win95 on most desktops (some 20000+) and of course
> experience the usual problems - mostly users corrupting their own systems.
Jeez. How many are hors de combat at any given time? How big is the Windows
Reinstallation Staff?
> The company will in the next 2-3 years upgrade all desktops and backends
> (from Novell & GroupWise) to W2k.
Jeez. How much for 20000+ W2K licenses? How much for the hardware upgrades
needed to run it?
> Linux, with its limited and crude desktop
> apps, its complicated man-machine interface (for average users), is simply
> not an option.
That may be true, though perhaps "crude" is overstating it. However, you
overgeneralize:
> Linux is for tinkering. W2k is for work.
No, I do my work on Linux. I recognize that some people think they can't
survive without Office or some other particular application that does not run
on Linux. But that hardly makes Linux a tinkerer's toy. Lots of us don't need
dancing paperclips to do our work.
Indeed, the only way lots of us could do our work on W2K would be to install a
big pile of GNU applications on it.
Bobby Bryant
Austin, Texas
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Stupid idiots that think KDE is a Window Manager
Date: Thu, 22 Jun 2000 05:01:44 GMT
On Wed, 21 Jun 2000 19:56:06 -0400, Jeff Szarka <[EMAIL PROTECTED]> wrote:
>On 21 Jun 2000 16:11:31 -0600, Craig Kelley <[EMAIL PROTECTED]>
>wrote:
>
>>>
>>> I think I like the Microsoft solgan better.
>>
>>I would agree with you, except that *you* started this little flame
>>fest (that's par for your course, IMNSHO).
>
>Maybe I should have said "KDE is not a very good clone of Windows" but
>I do find it pathetic since so many people try to deny what it is. If
>you want to clone the Windows UI, fine... I can see why. It's a very
>solid clone of other UI's over the year. It works very well.
>
>After all, Redhat shipped with that one window manger, the EXACT clone
>of Windows 95 until KDE came along. I forget its name but I'm sure
Actually, it was just a Window Manager that predated Win95
hacked only slightly (as only slight hacking was needed) to
look more like Win95.
All of the essential elements were already in place quite awhile
before '95s release. Infact, there were several entities making
small utilities to give Win 3.x those elements including plug-in
and technetium.
>everyone else knows it.
>
>Linux is trying to clone Windows to become a consumer grade OS. Now if
>only the rest of the OS would try to clone Window's ease of use Linux
>could be sitting on my hard drive right now.
You mean like PCI/USB/SCSI autodetection? GUI configurators for
nearly anything you would want to futz with?
Although, this would still make Linux more of an attempt to
replicate the Macintosh, as all of that was actually working
long before Microsoft ever released a 'kinda working' incomplete
clone.
--
If you know what you want done, it is quite often more useful to
tell the machine what you want it to do rather than merely having
the machine tell you what you are allowed to do.
|||
/ | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
Subject: Re: Linux MUST be in TROUBLE
Reply-To: [EMAIL PROTECTED]
Date: Thu, 22 Jun 2000 05:07:06 GMT
On Tue, 20 Jun 2000 21:21:18 -0400, Aaron Kulkis <[EMAIL PROTECTED]> wrote:
>And yet, even the Version 7 task scheduler (circa 1978) is more
>reliable and less likely to crash than LoseDows. Why is that?
Proof please? I have never heard of Windows crashing in the task
scheduler. Which version of Windows? Versions 3.1, 98, and 2000 have
completely and fudamentally different schedulers. Which ones are
unreliable? Please provide proof that Windows crashes often, or at all, in
the task scheduler.
>Hint fucking hint: Keep it simple, stupid.
Every problem has a solution which is simple, elegant, and wrong. The Unix
task scheduler is an example of this. You can't scheduler real time
threads with a round robin scheduler, for example. There is no version of
Unix which is good at both server applications and real time applications,
though VMS excels at both, because it has a much more complex scheduler.
The main goal of a task scheduler is to make an optimal scheduling
decision, not the actual time involved in scheduling, which is negligible
in all major scheduling algorithms.
>Unix solves the same task much more elegantly, with less overhead.
>
>Keep It Simple, Stupid.
See above.
>The LoseNT scheduler is a CPU hog in itself.
Proof please? Please prepare a list of major operating systems and the
average time spent in the scheduler per time slice. Note that we are not
talking about context switch time, but actual time in the scheduler. It
should be enlightening to see how you've measured this.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
