Great SWT Program

java-programmer, Great SWT Program In article <email***@***.com>,
<email***@***.com> wrote:
> On Sep 17, 5:43 am, email***@***.com <email***@***.com> wrote:
> > Just out of curiosity, have you ever used vim or gvim? what do
> > you normally use for editing text -- or does it depend on the use
> > of the text (e.g., an IDE if it's source code, a word processor
> > if it's a formatted document)?
>
> It depends on the circumstances, but it's always something sane.

So, do you mean to imply by this that you've never used vim or gvim?
Just asking.

> That
> means a) its interface was designed and developed sometime after the
> invention of the mouse;

Presumably true of gvim, since it allows a lot of operations to be
done using a mouse.

> b) said interface is NOT just bolted on over
> something archaic (no doubt with half the wingnuts loose and the other
> half missing);

It seems to me that the actual operations involved in editing
text files haven't changed that much -- find, insert, delete,
etc. -- so a program that was able to perform them with a primitive
interface should be equally capable of performing them with a more
sophisticated interface, and the fact that the underlying code has
been in use for many years might improve the odds that any bugs
have been found and fixed.

I repeat -- have you ever used any of these tools you're slamming?

> c) the authors have indeed heard of and applied CUA so
> someone who knows how to use normal software can immediately be
> productive using theirs, and only learn the different/additional
> features vs. other similar applications; and

So apparently you've changed your mind about "CUA" being a
cryptic term?

( http://groups.google.com/group/comp.emacs/msg/7bbbe22873f7f9ac )

> d) there's no retro/
> nostalgic stuff going on -- it's not designed by people who pine for
> the days when 640K really was enough for anybody. :)

Well, when Mr. Gates (?) was saying that, I was probably still
mostly ignorant of the PC world; I started out on mainframes,
and it took a long time for me to regard PCs as anything but
toys. (Then again, I think one could make a case for the idea
that the way most people use them these days *is* as toys.
But I digress.)

I do pine for the days when more people believed in the Unix idea
of tools being simple programs that did simple jobs well [*] and
could be combined under the user's control to do more complex jobs.
But -- "yeah well".

[*] Rather than attempting to do everything the programmer and/or
the marketing department can think of, with mixed success.

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

java-programmer >> Great SWT Program In article <email***@***.com>,
<email***@***.com> wrote:
> On Sep 17, 5:43 am, email***@***.com <email***@***.com> wrote:
> > Just out of curiosity, have you ever used vim or gvim? what do
> > you normally use for editing text -- or does it depend on the use
> > of the text (e.g., an IDE if it's source code, a word processor
> > if it's a formatted document)?
>
> It depends on the circumstances, but it's always something sane.

So, do you mean to imply by this that you've never used vim or gvim?
Just asking.

> That
> means a) its interface was designed and developed sometime after the
> invention of the mouse;

Presumably true of gvim, since it allows a lot of operations to be
done using a mouse.

> b) said interface is NOT just bolted on over
> something archaic (no doubt with half the wingnuts loose and the other
> half missing);

It seems to me that the actual operations involved in editing
text files haven't changed that much -- find, insert, delete,
etc. -- so a program that was able to perform them with a primitive
interface should be equally capable of performing them with a more
sophisticated interface, and the fact that the underlying code has
been in use for many years might improve the odds that any bugs
have been found and fixed.

I repeat -- have you ever used any of these tools you're slamming?

> c) the authors have indeed heard of and applied CUA so
> someone who knows how to use normal software can immediately be
> productive using theirs, and only learn the different/additional
> features vs. other similar applications; and

So apparently you've changed your mind about "CUA" being a
cryptic term?

( http://groups.google.com/group/comp.emacs/msg/7bbbe22873f7f9ac )

> d) there's no retro/
> nostalgic stuff going on -- it's not designed by people who pine for
> the days when 640K really was enough for anybody. :)

Well, when Mr. Gates (?) was saying that, I was probably still
mostly ignorant of the PC world; I started out on mainframes,
and it took a long time for me to regard PCs as anything but
toys. (Then again, I think one could make a case for the idea
that the way most people use them these days *is* as toys.
But I digress.)

I do pine for the days when more people believed in the Unix idea
of tools being simple programs that did simple jobs well [*] and
could be combined under the user's control to do more complex jobs.
But -- "yeah well".

[*] Rather than attempting to do everything the programmer and/or
the marketing department can think of, with mixed success.

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

java-programmer >> Great SWT Program email***@***.com wrote:
> I started out on mainframes,
> and it took a long time for me to regard PCs as anything but
> toys. (Then again, I think one could make a case for the idea
> that the way most people use them these days *is* as toys.
> But I digress.)

I hate when the computer's down and I have to find an actual deck of cards and
make enough room on my desk for the solitaire game.

--
Lew

java-programmer >> Great SWT Program
<email***@***.com> wrote in message
news:email***@***.com...
> < deep sigh > I probably should just let this go, but:

Yes, you should.

Do you honestly think you'll get a positive response?

java-programmer >> Great SWT Program In article <email***@***.com>,
<email***@***.com> wrote:
> On Sep 17, 6:18 am, email***@***.com <email***@***.com> wrote:
> > I wouldn't put it that way. The way I remember the discussion, you
> > said you had observed real-world damage resulting from something
> > that happened in Usenet, without providing any details. To me
> > that sounds like your saying "I can't provide details, but take
> > my word for it, it can happen." Given how frequently I disagree
> > with your summaries of what other people say, I wasn't willing to
> > do that. I'm not saying you're not right to not share details,
> > just that without them .... <shrug>
>
> In other words, either I break a confidence or you assume I'm lying.
> Nice. :P

"Assume you're lying"? No. I'm just very skeptical about whether,
if I knew the whole story, I'd agree with your assessment. And in
truth, even if you were to share details, I wouldn't feel confident
that I was hearing all sides of the story. I don't accuse you
of deliberate lies. But we've established on many occasions that
the way you perceive the world is different from how I perceive it.

> > It occurs to me that in writing the above paragraph I may have
> > grouped together an assortment of bad experiences with vaguely
> > GUI-related things, none of which are really related to using a
> > GUI to configure something. The bad experiences that come to mind
> > mostly have to do with trying to switch back and forth between
> > different versions of some GUI-ish program (GNOME and OpenOffice
> > are the examples that come to mind). What seems to happen is
> > that the newer version silently changes configuration files in
> > a way that presumably reflects changes from the older version.
> > Sometimes these changes break things.
>
> Well, duh. Running two different versions of something sharing one
> configuration file or one of almost anything else is just *asking* for
> trouble. Each of them should be installed separately, with its own
> version of the configuration file. Or you should pick a version you
> prefer and stick to it.

It may be asking for trouble, but it's not that easy to avoid in
the setup at my current place of employment, in which we have a
couple of dozen Linux systems sharing a password/file/etc. server.
Users' home directories, which is where the configuration files
live (where else?!), are shared by all machines. When we do
the yearly software (and sometimes hardware) upgrades, it often
happens that there's a period of some days or weeks during which
some of the machines are running the old stuff and some are
running the new stuff. It's those periods in which the trouble I
described arises, because typically the applications use the same
user-specific configuration files (e.g., /home/someuser/.gnome/*).
If you want to say that no software can be expected to behave
reasonably in those circumstances, I won't argue. If you want
to say that it's suboptimal to not upgrade all the machines at
the same time, I won't argue with that either, but personpower
for doing upgrades is finite.

> I have multiple versions of one tool over here (GTKRadiant, a 3D-game-
> level editing tool; versions 1.2ish and 1.5ish IIRC) but they are
> installed in separate directories, each with its own copy of its
> settings files; they appear not to clobber anything important
> belonging to one another.

When you say "settings file", do you mean a system-wide file, or
a per-user file?

> > Okay: Your mileage varies from mine. (It sounds like you might
> > be basing what you say on bad experiences with some text-based
> > newsreader. Care to say which one? Just curious.)
>
> More a made-up example. ALL unix commandline apps appear to behave in
> a similar fashion. Error messages are terse and cryptic where they
> aren't absent. Doing anything nontrivial requires multiple trips to
> the help. Even navigating the help requires trips to the help!
> Something as basic as browsing some hypertext should be obvious right?
> Arrows/pgup/dn/home/end [ snip ]

Yeah. Lack of a consistent interface is a problem, though again,
I think there's more commonality than your description suggests.
I doubt we're going to agree about that, though.

> Of course your fumblings might provoke unexpected behavior that's
> worse than just a beep or no-effect or an error message. Ctrl+F might
> activate some arcane mode for doing some unspecified thing from which
> there's no obvious escape except Ctrl+C and start all over, for
> instance.

And this doesn't happen in GUI tools? I hear these stories about
MS Word .... (Yes, I have used the program, but any time I have
to do more than very simple things with it, I very carefully go
through all the options/settings menus I can find and turn off
most of the auto-this and auto-that, so I'm not sure I've really
ever gotten the full "Word does weird things!" effect. As for
why I do that .... When I was first presented with a Windows
system and, um, "strongly encouraged"? to use Word, I realized
pretty quickly that I wasn't going to learn it very well by just
trying things. So I bought a book, and the book started out by
telling me about all the wonderful auto-whatever features, and
after I stopped making faces, I figured out how to turn them off,
and .... But I digress. Or do I?)

> Basically, none of the stuff, not even the help viewer, works until
> you've actually read the help for everything in advance as one might
> the manual for hooking up a stereo. Help is for reference and advanced
> how-to stuff; if the user needs it to even do the basics then there's
> a problem. If the help browser itself isn't dead easy to use and
> "normal" in behavior then the user is sunk from the get-go.

As opposed to being sunk a little later .... I think one of the
things that annoys me about GUI tools is that they somehow give the
impression (to me anyway, and I don't *think* I'm alone in this)
that anyone can use them, even to do tasks they don't understand
(setting up networking, say, or working with a CVS repository in
Eclipse [*]).

[*] Something I've been making off-and-on attempts to figure out,
and -- well, maybe if I read through all the online help carefully
I'd do better, but just dipping into it, mostly what I get is
a sense that somehow they're trying to express not-that-simple
technical ideas in non-technical language ("team", "share project",
etc., etc.). Clearly this is a case in which background reading
is needed, but .... Well, I digress again.

> Only the
> guys who designed the system and whatever elite and cloistered guild
> has descended from them through chains of apprenticeship can do more
> than get the thing to run and then boggle in puzzled annoyance when it
> won't do anything useful. Indeed, in any system with idiosyncratic
> help (or none at all) the guild mentality is evident -- the only way
> in being apparently to apprentice with a live tutor. Is this a tool,
> or is it an exclusive club? Is its design based pragmatically around
> getting a useful task done, or around the same philosophy that informs
> signs on treehouses saying "NO GIRLZ ALOWD -- GURLS SUC!" ... (you may
> have been on the receiving end of that a time or three when you were
> younger, so hopefully you can relate!)

Curiously enough, I've had little personal experience with the "no
girlz allowed!" mentality. Maybe it has to do with not being very
girly. Or maybe I just don't notice.

Your point about a guild mentality is all too true; I rather *like*
the feeling of being part of a somewhat exclusive club, but I'm not
sure that's really something to boast about. Then again, it seems
natural enough to be a little smug about being able to do something
not everyone can do. Write Java programs, for example. :-)?

> In any event, configuration done by hand-hacking (hidden functionality
> again -- nothing in the program UI indicates that you can change
> behavior XXX!), cryptic error messages, unsearchable help, help that
> provides no how-to information, help that reads like stereo
> instructions, etc. all clearly indicate a lack of attention to
> usability. [ snip ]

Well .... It's not that you don't have a point; you do. But for
some tools I'm willing to accept a certain amount of novice-hostile
behavior if I get expert-friendliness in return. I think. I'm not
sure when I last had to get up to speed with such a tool ....

The other thing I like about configuring by editing text files is
that *you know where the configuration information is stored* --
so you can back it up before making changes, and it's potentially
much easier to track what you actually did than if you were
pointing and clicking through menus. Or that's my mileage, anyway.

> Ultimately, even if you get semi-proficient, and the help is of the
> verbose variety these applications basically provide a thousand
> drawers full of various tools, all with opaque fronts and cryptic one-
> letter labels, and somewhere a manual describing which one is in which
> drawer, where a modern one just lets you see and reach for the tools
> you want when you want them. If you want the drill you reach for the
> drill, rather than the manual which says there's a drill in a drawer
> labeled, for some reason, J. If you want to see what's available you
> look over all the tools and if you want to use one you use it right
> there, rather than having to look through a *catalog* of tools and
> then switch to another task and place an order for one there. :P

Well .... I don't know. I'm not sure there's such a huge
difference between looking through a manual and pointing and
clicking one's way through a lot of menus and tabs. And don't get
me started on the little icons. Which one does what? Who knows?
Sure, put the mouse over one, wait a few seconds, and probably
some moderately explanatory text will appear. That wasn't the one
you wanted? Move the mouse, wait a few seconds. Move again, wait.
Maybe you get used to it.

[ snip ]

> Of course the fact that the chauffeur can apparently see out the
> windows but forces me to ride blindfolded doesn't help. You can't even
> get oriented in those old interfaces; you must have a precise memory
> of exactly what state the software is in or nothing will work as
> expected.

You do? Once again I think we must be talking about different
software. Example: the (in)famous two modes (insert and command)
of vi. "Real" vi (and vim in compatibility mode) doesn't provide
any cues about which mode you're in, which is the situation
you describe. But vim (in its default mode) does, with the text
"--INSERT--" at the bottom of the screen when you're in input mode.

Oh wait. That's cheating, right? talking about how a current
text-mode program behaves, rather than how its ancestor of some
decades ago behaved?

I wonder, too, if what you describe might be something of a
YMMV thing reflecting different styles of thought or something:
What I'm thinking is that some people seem to have no trouble
remembering shortish strings of meaningless data, such as phone
numbers, while others apparently would have to work hard to do
that.

> > No, I don't really use many of those -- I use a lot of text-mode
> > tools, but since one of the things I like about them is that they
> > *are* text-mode, why would I use a GUI-fied version of them?
>
> I suppose you also prefer rotary-dial phones? :P Seems silly to eschew
> great advances in user-interface technology that can make things a lot
> easier.

In my opinion, most of these advances are most helpful for tasks
you haven't done before or don't do often. For such tasks,
I agree that it can be pretty nice to be able to point and
click through menus rather than reading man pages and editing
configuration files. For tasks I do often -- and that's most
of what I use those text-mode tools for -- well, for example,
I find it faster to type ":w<return>" to save a file than to
click on a little floppy-disk icon.

> > Specific tools I can remember having trouble with are mentioned
> > earlier. Maybe they *are* poor GUI tools; I'm certainly not the
> > best person to judge.
>
> Well Eclipse certainly isn't. I don't know why it got hosed to the
> point of needing hand-hacking some files to get it working again. Oh,
> wait, I *do* have a pretty good guess: hand-hacking of the same files
> messed them up in the first place, perhaps. :)

I can't say "you're wrong" because that would be an insult, right?

But the occasions I'm vaguely remembering -- and it's altogether
possible I'm confusing Eclipse with another IDE (Together
from Borland) -- did not result from attempts to operate on
configuration files with other tools. I'd be happier if that were
possible, but before attempting it I usually make a backup copy of
the -- well, with Eclipse usually the whole workspace directory,
since I don't really know where the configuration files are kept --
and if things go wrong with the "edit outside Eclipse" experiment,
I'm apt to conclude that it's not going to work, and just replace
the messed-up workspace with the backup.

[ snip ]

> > Could be. I've had enough practice that I don't have a lot of
> > trouble with the mechanics (and have been very happy to discover
> > that many of these GUI things are a lot more keyboard-drivable
> > than they at first appear to be).
>
> Why? Is your mouse really that unreliable? For a lot of things (e.g.
> navigating to an arbitrary point in a document) the mouse is way
> faster than keyboard navigation, or *shudder* using the search-n-pray
> method.

It's not the mouse that's unreliable; it's me. I find keyboard
navigation is almost as fast (especially if I can get to the
right spot with a search), and much more reliable -- getting
the cursor placed on precisely the right spot on the screen is
not something I do very well. More practice using a mouse might
help -- or it might cause me to know more than I'd like to about
repetitive stress injuries.

> > I think what I'm not so good
> > at is guessing where to find, in a complicated menu structure,
> > something useful for the task I have in mind. Online help is
> > sometimes excellent, sometimes frustratingly inadequate.
>
> This problem plagues help systems in general. Often they lack how-to
> information and provide either very little, or a ton of reference
> information useful for someone who already knows the how-to stuff.

That (ton of reference information) might actually be helpful.
What make me rant is "help" that tries to express technical
concepts in non-technical language. Eclipse's explanation of how
to work with CVS repositories comes to mind.

> That said, at least a gui lets you browse around and find whatever you
> are searching for, and you can easily remember where it is. It's much
> easier to remember a *place* than it is to remember "Ctrl-Meta-H, X,
> Z, Q, <enter>" and shit like that!

I don't find it difficult to remember the keystroke combinations
I use regularly, and for stuff I don't use regularly -- it's hard
to be sure, but I don't know that having done something with a
GUI makes it easier for me to remember -- I think I'd be more
apt to just remember that the task can be done and there's a menu
*somewhere* (possibly not in the same place it was the last time
I did the task -- GUI designers seem to like to tinker with this
stuff from release to release.

This is something else I like about a command-line / text-files
approach to configuring things -- there's a better chance that,
for something you don't do often but have done successfully at
least once, there will be a record somewhere of what you did,
so you can repeat it. (Or if it didn't work, a record of what
you tried.)

> A decent gui also puts obvious/frequent/contextually relevant stuff in
> easy reach (e.g. toolbar) and has a logical organization to its menus.
> Document saving and loading, printing, and other stuff like that goes
> in File, etc.
>
> > Well, yeah, kind of .... A lot of them these days provide
> > some kind of text menu to help new users, and there are a
> > lot of keystrokes that do the same thing in many applications.
>
> That's like putting the little numbers onto a formerly-blank stick
> shift instead of noticing that a few decades ago they invented this
> nifty thing called an "automatic transmission". :P

I think you won't be surprised to hear that I rather like stick
shifts too.

> Typical old-skool

Misspelling for no good reason I can think of, except to make
something you don't like look bad.

> unix software: stick shift with the groove pattern
> on the head of the stick, but no labels there. There's a 500-page
> behemoth of a manual in the glove compartment with a labeled version
> of the groove pattern on page 217. The table of contents lists "Shift
> diagram" in between "Starter" and "Tire rotation" but does not give
> page numbers for anything, just the list of things contained, in
> alphabetical order. Riffling through the whole thing is needed to find
> anything. There's probably some kind of arcane indexing system you've
> overlooked, but you'll at least need to riffle through the whole thing
> to find *that*. The actual contents are not in any obvious (e.g.
> alphabetical) order so binary search isn't an option. (The computer
> version: you have a page down command, and, if you're lucky, a page up
> command. There may be a search command but you're damned if you know
> of it; it certainly isn't reached via any of the usual suspects like
> ctrl+F. And since you can only go one page at a time, binary search
> isn't an option, however it's organized.)

How would binary search be useful anyway?

And I thought everyone knew that to search for text you type "/"
and the text .... Sort of a :-).

> What you just described: the diagram is directly on the stick head.

Sure. Isn't that helpful? I think it is.

> There is still a 500-page manual with no page numbering.

For a stick shift?

> What was invented about 25 years ago and is used on every sane
> operating system and even on the Macintosh(!): an automatic shift --
> just put the darn thing in drive and hit the gas. No need to worry
> your head about the internals. The manual is 150 pages and has a TOC
> and index of the normal sort; you can actually find stuff in it in
> under an hour and even in under a minute!

And sometimes the stuff you find is actually helpful. Sometimes.

> Poorer GUI systems: there's an automatic shift, but the transmission
> grinds and breaks down sometimes. The manual lacks a TOC or an index
> because it's only 15 pages long and basically says "fiddle with the
> stick and the pedals to make it go". It still works, though, and
> intuitively,

Talk about a word that pushes my buttons! Do you know the
oft-cited remark about how the only truly intuitive interface is
the nipple, and everything else is learned?

Actually I think it *is* true that what you learn from operating
one typical GUI application is apt to make the next one seem
more "intuitive". But I claim that the same is true of the old
text-mode applications as well.

> and when the transmission goes, you just push a button
> for an instant free replacement, although you also mysteriously find
> yourself back at the last major intersection you'd crossed.

And with the contents of the glove compartment gone, and the
collection of Post-It notes on the visor discarded .... I'm
not quite sure where I'm going with that analogy, if anywhere!

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

java-programmer >> Great SWT Program email***@***.com wrote:
> It may be asking for trouble, but it's not that easy to avoid in
> the setup at my current place of employment, in which we have a
> couple of dozen Linux systems sharing a password/file/etc. server.
> Users' home directories, which is where the configuration files
> live (where else?!), are shared by all machines. When we do

Is that to say, /home/fooperson resides on a particular server, and is mapped
to each other node through NFS or some other remote-mounting mechanism?

> the yearly software (and sometimes hardware) upgrades, it often
> happens that there's a period of some days or weeks during which
> some of the machines are running the old stuff and some are
> running the new stuff. It's those periods in which the trouble I

That puzzles me. The PATH directories should be shared, thus rendering it
impossible for correctly-mapped nodes to run different things.

Still, I suppose it's always inevitable that some config information is
specific to a node. But days or weeks worth?

> described arises, because typically the applications use the same
> user-specific configuration files (e.g., /home/someuser/.gnome/*).
> If you want to say that no software can be expected to behave
> reasonably in those circumstances, I won't argue. If you want
> to say that it's suboptimal to not upgrade all the machines at
> the same time, I won't argue with that either, but personpower
> for doing upgrades is finite.

I'd want to say that a more normal upgrade procedure should be in place, since
one admin should be able to manage upwards of a hundred nodes, by industry
average. Clearly the fault lies in the process, that it should take more than
about an hour to upgrade the entire network.

The problem here doesn't seem like personpower, it seems like brainpower.
Sounds like you need a patch to the sysadmin.

Am I missing something here?

--
Lew

java-programmer >> Great SWT Program In article <email***@***.com>,
<email***@***.com> wrote:
> On Sep 17, 6:35 am, email***@***.com <email***@***.com> wrote:

[ snip ]

> > That you apparently translate "I think
> > you have a distorted view of the world" into "you hallucinate"
> > puzzles me, to the point that this will probably be my last post
> > on this subject, since it seems that there is little prospect of
> > anything resembling clear communication.
>
> Not when you apparently draw a distinction between one phrase that
> means "not seeing things as they really are" and another phrase that
> means "not seeing things as they really are". :P Or at least, normally
> means that. Apparently you're not using the same dictionary
> definitions of some words as I am.

Apparently not. Please point me to a dictionary whose definitions
make the words equivalent, interchangeably, equally insulting,
what have you. I just consulted the definitions given by the
online Merriam-Webster (http://www.merriam-webster.com) [*], and
the don't use the exact words you do, nor do their definitions
seem to me to be equivalent, only somewhat similar.

[*] No claims about it being best, just one I can access fairly
easily.

In part the difference I perceive is one of degree rather than
kind. But there's also a subtle difference of kind -- "you
hallucinate" means you see things that aren't there at all,
while "you have a distorted view" means that you see things
that are there, but in a way that's a little, or a lot, off.

[ snip ]

> > Fair enough. I'd consider it rude and cruel to make fun of
> > illness of any kind; I'm not sure I can honestly claim to have
> > never stooped to that, but I try not to. (Pointing out an
> > illness is not, in my thinking, the same as making fun of it.)
>
> In this case there is no illness anyway; perhaps you think there is,
> but if so, you are mistaken.

Could be. But you also could be mistaken. You might not notice
that spider on your back either, when someone else might.

Look, I know how annoying it can be to have someone else claim
to know the insides of your head better than you do yourself --
a long-ago college friend majoring in psychology used to try that
with me -- but in some cases it's probably true. Not saying you're
one of them, just that in general it seems to me to be possible.

[ snip ]

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

java-programmer >> Great SWT Program In article <FOeJi.35106$email***@***.com>,
Mike Schilling <email***@***.com> wrote:
>
> <email***@***.com> wrote in message
> news:email***@***.com...
> > < deep sigh > I probably should just let this go, but:
>
> Yes, you should.
>
> Do you honestly think you'll get a positive response?

< hangs head in embarrassment > .... No, probably not. Apparently
I'm having trouble letting well enough (ill enough?) alone.

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

java-programmer >> Great SWT Program In article <email***@***.com>,
Lew <email***@***.com> wrote:
> email***@***.com wrote:
> > It may be asking for trouble, but it's not that easy to avoid in
> > the setup at my current place of employment, in which we have a
> > couple of dozen Linux systems sharing a password/file/etc. server.
> > Users' home directories, which is where the configuration files
> > live (where else?!), are shared by all machines. When we do
>
> Is that to say, /home/fooperson resides on a particular server, and is mapped
> to each other node through NFS or some other remote-mounting mechanism?

That's it. The top-level directory for home directories is
physically located on a disk connected to a "file server";
the other machines NFS-mount the relevant partition as /users,
and for example blmblm's home directory would be /users/blmblm.

> > the yearly software (and sometimes hardware) upgrades, it often
> > happens that there's a period of some days or weeks during which
> > some of the machines are running the old stuff and some are
> > running the new stuff. It's those periods in which the trouble I
>
> That puzzles me. The PATH directories should be shared, thus rendering it
> impossible for correctly-mapped nodes to run different things.

They should be? Maybe (see below for comments about patching the
sysadmin). They're not. Each machine has its own copy of /bin,
/usr, etc. -- the normal Unix/Linux setup, including /home. What's
shared is the directory with the actually-in-use home directories
(NFS-mounted /users). Password information -- I think we use NIS.

> Still, I suppose it's always inevitable that some config information is
> specific to a node. But days or weeks worth?
>
> > described arises, because typically the applications use the same
> > user-specific configuration files (e.g., /home/someuser/.gnome/*).
> > If you want to say that no software can be expected to behave
> > reasonably in those circumstances, I won't argue. If you want
> > to say that it's suboptimal to not upgrade all the machines at
> > the same time, I won't argue with that either, but personpower
> > for doing upgrades is finite.
>
> I'd want to say that a more normal upgrade procedure should be in place, since
> one admin should be able to manage upwards of a hundred nodes, by industry
> average. Clearly the fault lies in the process, that it should take more than
> about an hour to upgrade the entire network.
>
> The problem here doesn't seem like personpower, it seems like brainpower.
> Sounds like you need a patch to the sysadmin.
>
> Am I missing something here?
>

Hard to say, and this is more topic drift, but if we're doing
things all wrong, I'd be glad to hear better ideas ....

About patching the sysadmin, well, these are my friends we're
talking about here, but yeah, it could be in order. It probably
won't happen, though -- we're a small department at a small school,
and we don't have a full-time sysadmin for the Linux systems,
getting by with part-time efforts from several people who are
reasonably clueful but probably would not claim guru status.

The upgrade process as currently done -- I don't know the details,
but as I understand it, it involves replacing the entire contents
of each client's local disk using -- Norton Ghost maybe? Most of
the clients dual-boot Windows and Linux. I'm not sure how this
could be done remotely.

When you say it should take about an hour to upgrade the entire
network, what do *you* mean? We do have a system for remotely
applying smaller patches to all the Linux systems, which works
reasonably well despite being something of a crude hack.

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

java-programmer >> Great SWT Program email***@***.com wrote:
> When you say it should take about an hour to upgrade the entire
> network, what do *you* mean? We do have a system for remotely
> applying smaller patches to all the Linux systems, which works
> reasonably well despite being something of a crude hack.

Your environment differs quite a bit from the one I envisioned when I spouted off.

I pictured a business with several dozen nodes and a paid administrator not
really coordinating everything. You present a reality of a cooperative,
self-trained group of intelligent individuals doing the best they can with
what they can scrounge. That's a very different business model.

For common utilities and the like, things like /usr/sbin/alternatives can ease
the burden. It lets workstations default to a common net-wide directory,
which you'd mount either to /usr/bin/ or some arbitrary directory like
/usr/common/bin/, while letting individual workstations or accounts override
to a specific, explicit version. That private version, of course, would be
outside the sysadmin's responsibility.

You put in each person's .profile or /etc/profile the PATH entry to the shared
directory. Similarly, you can set JAVA_HOME, CVSROOT and other important
envars to shared or commonly-linked/mounted directories.

This is a logical extension of what you're already doing with /users/.

OS patches are a different matter. I'd probably cron a regular {yum,apt,...}
run for each node, in your type of situation.

System administration is one of the Dark Arts.

--
Lew

java-programmer >> Great SWT Program In article <email***@***.com>,
Lew <email***@***.com> wrote:
> email***@***.com wrote:
> > When you say it should take about an hour to upgrade the entire
> > network, what do *you* mean? We do have a system for remotely
> > applying smaller patches to all the Linux systems, which works
> > reasonably well despite being something of a crude hack.
>
> Your environment differs quite a bit from the one I envisioned when I
> spouted off.
>
> I pictured a business with several dozen nodes and a paid administrator not
> really coordinating everything. You present a reality of a cooperative,
> self-trained group of intelligent individuals doing the best they can with
> what they can scrounge. That's a very different business model.

With regard to human resources, that's a very good description of
our situation. Getting approval for reasonable hardware purchases
seems to be less of a problem. I have no real complaints, though.

> For common utilities and the like, things like /usr/sbin/alternatives can ease
> the burden. It lets workstations default to a common net-wide directory,
> which you'd mount either to /usr/bin/ or some arbitrary directory like
> /usr/common/bin/, while letting individual workstations or accounts override
> to a specific, explicit version. That private version, of course, would be
> outside the sysadmin's responsibility.

The other thing I didn't say is that the couple of dozen machines
in question are deployed in classroom/lab settings and intended
for general use, rather than being people's personal desktop
machines. (We have some of those, too, but they get upgraded
mostly by request of the "owner".) For the classroom/lab
machines, there's not a lot of call for different machines
to be configured differently. As for putting /usr/bin in a
network-mounted directory -- yeah, that's appealing in its way,
but wouldn't it be a potential performance bottleneck?

I'd apologize for boring everyone, but I get the feeling our
setup is different enough from what most people have and imagine
that maybe describing it is at least a little horizon-broadening
for someone. Or not.

> You put in each person's .profile or /etc/profile the PATH entry to the shared
> directory. Similarly, you can set JAVA_HOME, CVSROOT and other important
> envars to shared or commonly-linked/mounted directories.
>
> This is a logical extension of what you're already doing with /users/.
>
> OS patches are a different matter. I'd probably cron a regular {yum,apt,...}
> run for each node, in your type of situation.

Yeah .... Well, we don't try very hard to keep up with all
available updates; we do well to build and deploy one tested
configuration per year, with other changes/fixes done only to
meet a specific need.

> System administration is one of the Dark Arts.

No kidding. It's something I wish I knew more about, but I have
a feeling the only way to get good at it is to spend years in the
trenches. Something else to do in my copious spare time? :-)

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

java-programmer >> Great SWT Program email***@***.com wrote:
> On Sep 21, 9:07 pm, Arne Vajh鴍 <email***@***.com> wrote:
>> email***@***.com wrote:
>>> On Sep 16, 9:41 pm, Arne Vajh鴍 <email***@***.com> wrote:
>>>> email***@***.com wrote:
>>>>> On Sep 16, 8:19 pm, Arne Vajh鴍 <email***@***.com> wrote:
>>>>> [snip false insults]
>>>>> I hate to sound like "Ed" here but: Fuck off. :P
>>> [snip repetitious BS]
>> [repeats it again]

What you try to snip out is:

#The uuencode format start with:
# begin
# 3 octal digits with mode
# filename

> I snipped it for a reason, jackass! I don't *want* your nasty
> implications about me being repeated. In fact you can take all the
> nasty things you believe about me and shove them up your ass! :P

I can not see what this is about you.

It is easy verifiable facts about a well known format.

Or are you claiming that your name is uuencode ??

:-)

Arne

java-programmer >> Great SWT Program On Sep 22, 3:16 pm, Lars Enderin <email***@***.com> wrote:
> email***@***.com skrev:
>
> > On Sep 21, 9:07 pm, Arne Vajh鴍 <email***@***.com> wrote:
> >> email***@***.com wrote:
> >>> On Sep 16, 9:41 pm, Arne Vajh鴍 <email***@***.com> wrote:
> >>>> email***@***.com wrote:
> >>>>> On Sep 16, 8:19 pm, Arne Vajh鴍 <email***@***.com> wrote:
> >>>>> [snip false insults]
> >>>>> I hate to sound like "Ed" here but: Fuck off. :P
> >>> [snip repetitious BS]
> >> [repeats it again]
>
> > I snipped it for a reason, jackass! I don't *want* your nasty
> > implications about me being repeated. In fact you can take all the
> > nasty things you believe about me and shove them up your ass! :P
>
> > Now go away and leave me alone.
>
> There were no nasty implications by Arne.

Yes, there were. He is trying to imply that I'm an idiot. He's simply
not saying it directly. Regardless, his purpose is clearly hostile,
since why the hell else would he imply such a thing? It's time for him
to shut up. You, too.

[snip repetition of basically the same stuff Arne was saying]

Why do you both feel the need to repeat the same stuff over and over
and over? Simply to I have to repeat my response over and over as
well? You're just wasting all of our time.

java-programmer >> Great SWT Program On Sep 22, 3:23 pm, email***@***.com <email***@***.com> wrote:
> In article <email***@***.com>,
>
> <email***@***.com> wrote:
> > On Sep 17, 5:43 am, email***@***.com <email***@***.com> wrote:
> > > Just out of curiosity, have you ever used vim or gvim? what do
> > > you normally use for editing text -- or does it depend on the use
> > > of the text (e.g., an IDE if it's source code, a word processor
> > > if it's a formatted document)?
>
> > It depends on the circumstances, but it's always something sane.
>
> So, do you mean to imply by this that you've never used vim or gvim?

Not by choice.

> It seems to me that the actual operations involved in editing
> text files haven't changed that much -- find, insert, delete,
> etc. -- so a program that was able to perform them with a primitive
> interface should be equally capable of performing them with a more
> sophisticated interface, and the fact that the underlying code has
> been in use for many years might improve the odds that any bugs
> have been found and fixed.

Of course, if the interface is not a reasonably normal and modern one,
that these functions are low in saturated bugs won't necessarily mean
much to the users that are damned if they can even discover that those
functions even exist. :P

> > c) the authors have indeed heard of and applied CUA so
> > someone who knows how to use normal software can immediately be
> > productive using theirs, and only learn the different/additional
> > features vs. other similar applications; and
>
> So apparently you've changed your mind about "CUA" being a
> cryptic term?

Eh? I've now got familiarity with the term. So?

> Well, when Mr. Gates (?) was saying that, I was probably still
> mostly ignorant of the PC world; I started out on mainframes,
> and it took a long time for me to regard PCs as anything but
> toys. (Then again, I think one could make a case for the idea
> that the way most people use them these days *is* as toys.
> But I digress.)

I have the feeling some people regard anything that's delivered as a
finished, polished product with a case bearing some controls
constituting a proper user interface, instead of as a bunch of circuit
boards whose "user interface" consists of toggle switches and jumpers,
as "mere toys". :P

> I do pine for the days when more people believed in the Unix idea
> of tools being simple programs that did simple jobs well [*] and
> could be combined under the user's control to do more complex jobs.
> But -- "yeah well".

Said user having to basically program them for them to do anything,
and not being able to simply *use* them. A Unix for carpenters would
give you a power hammer held by a robot that could be programmed in
some idiosyncratic hammer-wielding-robot-specific language while
neglecting to provide a plain old hammer you could simply pick up in
one hand and hit nails with. Hammering one nail in to hang a picture
would require learning a scripting language of fifty or sixty commands
first. :P

Of course, the tendency of Windoze and (especially) Mac systems to
provide a small plastic hammer unsuited to either single heavy-duty
nails or to industrial-scale construction without providing anything
bigger or more automated might also be viewed as a problem.

> [*] Rather than attempting to do everything the programmer and/or
> the marketing department can think of, with mixed success.

Unix isn't a stranger to creeping featurism. The filesystem itself, X,
and emacs all come to mind. :)

java-programmer >> Great SWT Program On Sep 22, 5:39 pm, email***@***.com <email***@***.com> wrote:
> In article <FOeJi.35106$email***@***.com>,
>
> Mike Schilling <email***@***.com> wrote:
>
> > <email***@***.com> wrote in message
> >news:email***@***.com...
> > > < deep sigh > I probably should just let this go, but:

[said some stuff about how she was not meaning to insult me by
comparing me to a child]

Making such comparisons is something that obviously is going to be
considered insulting by adults. :P

> < hangs head in embarrassment > .... No, probably not. Apparently
> I'm having trouble letting well enough (ill enough?) alone.

And now again slyly suggesting I'm mentally ill or something. I
suppose you're going to follow up and claim not to have insulted me
here, either? Of course this is right after a series of posts where
you kept suggesting to our mutual audience that I hallucinate, or am
delusional, or something of the sort and then denying having done so
as well...

java-programmer >> Great SWT Program On Sep 23, 1:51 pm, Arne Vajh鴍 <email***@***.com> wrote:
> email***@***.com wrote:
> > On Sep 21, 9:07 pm, Arne Vajh鴍 <email***@***.com> wrote:
> >> email***@***.com wrote:
> >>> On Sep 16, 9:41 pm, Arne Vajh鴍 <email***@***.com> wrote:
> >>>> email***@***.com wrote:
> >>>>> On Sep 16, 8:19 pm, Arne Vajh鴍 <email***@***.com> wrote:
> >>>>> [snip false insults]
> >>>>> I hate to sound like "Ed" here but: Fuck off. :P
> >>> [snip repetitious BS]
> >> [repeats it again]
>
> What you try to snip out is:

[snip]

STOP IT. I am not amused. Your hostility toward me is as baffling as
it is unwelcome. Killfile me and stop posting about me to newsgroups,
or simply stop posting about me to newsgroups. Now.

java-programmer >> Great SWT Program On Sep 22, 4:57 pm, email***@***.com <email***@***.com> wrote:
> "Assume you're lying"? No. I'm just very skeptical about whether,
> if I knew the whole story, I'd agree with your assessment. And in
> truth, even if you were to share details, I wouldn't feel confident
> that I was hearing all sides of the story. I don't accuse you
> of deliberate lies. But we've established on many occasions that
> the way you perceive the world is different from how I perceive it.

If that is so, then it is not I who is perceiving it inaccurately.

> It may be asking for trouble, but it's not that easy to avoid in
> the setup at my current place of employment, in which we have a
> couple of dozen Linux systems sharing a password/file/etc. server.
> Users' home directories, which is where the configuration files
> live (where else?!), are shared by all machines. When we do
> the yearly software (and sometimes hardware) upgrades, it often
> happens that there's a period of some days or weeks during which
> some of the machines are running the old stuff and some are
> running the new stuff.

Ultimately it still results from the old version and the new version
trying to share files. If one looked for ~\fooSoft\1.1\foo.rc and the
other for ~\fooSoft\2.0\foo.rc, they wouldn't collide. (The new one
also wouldn't inherit the old one's settings without the user
importing them manually, but it would apparently save a lot of
headaches too!)

Alternatively, either the config files could be local to the machines
with the software binaries, or the software binaries global with the
config files. Centrally storing the config files without centrally
storing the binaries is probably asking for trouble regardless. Since
central binaries means the machines all turn into paperweights if the
network goes down, locally installing the binaries makes sense, so
local config files also make sense. Central storage of user documents
still makes sense if users need to access them from multiple machines.

Of course, some config settings will be user-variable preferences. In
that case, they may need to be centralized anyway. And then there
should be different ones for different versions as initially
described.

> > I have multiple versions of one tool over here (GTKRadiant, a 3D-game-
> > level editing tool; versions 1.2ish and 1.5ish IIRC) but they are
> > installed in separate directories, each with its own copy of its
> > settings files; they appear not to clobber anything important
> > belonging to one another.
>
> When you say "settings file", do you mean a system-wide file, or
> a per-user file?

There's no distinction in this case; it's a single-user machine.

> Yeah. Lack of a consistent interface is a problem, though again,
> I think there's more commonality than your description suggests.
> I doubt we're going to agree about that, though.

The only commonality I recall observing is that they all deviate
equally from standard user-interface guidelines, key-bindings, and the
like. Ctrl+C is never copy. F1 is never help. F3 is never search. Page
up and page down never actually do what their names describe.
Backspace and delete may or may not work. Arrow keys may or may not
work. The mouse may even work, on a GUI-capable machine, but often
won't do squat. The alphanumeric keys, space, and enter can actually
be counted on to do the expected; function keys and page up/down can
actually be counted on to do nothing; Ctrl+C can be counted on to be a
quit command (instead of a copy command); and that's about it for
commonalities, in my experience. With each other or with typical
Windows or Mac software (modulo command/option for alt/ctrl in the
case of Mac software). Even the GUI apps have niggling little quirks
with e.g. minimize behavior or (especially) focus change/tab order.
Drop down menus, input fields, and even the simple check box usually
offer up some surprising or nonstandard behavior some of the time.

Of course, it's not like Windows software is perfect. The behavior of
Home and End is pretty random -- sometimes Home does the expected
(jump as far as possible left) and sometimes it instead acts as a
super-Page Up, for instance. Focus behavior isn't perfectly consistent
either -- overlap two Explorer windows with files in two columns in
each one, half-overlapped so the right column of window A overlaps the
left column of window B, and try to drag a file from the right column
of window B to the right column of window A. Sometimes clicking on the
file in window B brings that window to the front, hiding the intended
destination, and sometimes only releasing the mouse button while still
in window B will do so; it seems to behave somewhat randomly. Once in
a while a control will behave egregiously badly -- attempting a common
and typical operation fails in dramatic and broken ways. I've seen a
combobox in one app frequently spectacularly screw up apparently due
to a broken implementation of autocomplete: typing anything that
started with the same letter as any autocomplete entry and hitting
Enter would enter the wrong thing, because on the first letter it
would drop down the autocomplete list and then decide later that your
enter keypress was to submit that instead of what you'd actually
typed. More usually, if you keep typing and diverge from the items in
the autocomplete history it will accept what you actually typed, but
in this one case anything that triggered the autocomplete drop-down
had to be typed in, but then submitted by mouse instead of Enter
keypress to work. Sometimes text fields respond to tab-home-type-some-
stuff by replacing everything originally in the box instead of
prepending the new typing, usually those that auto-select everything
on focus. Hitting home should jump to the start of the text field and
deselect everything but doesn't always in particular cases.

Nevertheless, such behavior is the exception on Windows. On Unix GUI
apps (and Windoze ports of same) it's the rule. And when it comes to
console apps, the only exceptions to "anything goes" seem to be a few
places that strictly and consistently depart from standard Windows/Mac
usage, unfortunately including the standard help key and two very
commonly used and useful standard navigation keys.

> And this doesn't happen in GUI tools? I hear these stories about
> MS Word .... (Yes, I have used the program, but any time I have
> to do more than very simple things with it, I very carefully go
> through all the options/settings menus I can find and turn off
> most of the auto-this and auto-that, so I'm not sure I've really
> ever gotten the full "Word does weird things!" effect. As for
> why I do that .... When I was first presented with a Windows
> system and, um, "strongly encouraged"? to use Word, I realized
> pretty quickly that I wasn't going to learn it very well by just
> trying things. So I bought a book, and the book started out by
> telling me about all the wonderful auto-whatever features, and
> after I stopped making faces, I figured out how to turn them off,
> and .... But I digress. Or do I?)

Word is not the best example, because of the 800-pound-gorilla effect
that kicks in whenever Microsoft is involved. I doubt you'd have had
this trouble with Notepad (even though that's also of MS origin!) or
OO Writer.

> As opposed to being sunk a little later .... I think one of the
> things that annoys me about GUI tools is that they somehow give the
> impression (to me anyway, and I don't *think* I'm alone in this)
> that anyone can use them, even to do tasks they don't understand
> (setting up networking, say, or working with a CVS repository in
> Eclipse [*]).

I'm not sure what this means. It's certainly not the case that anyone
actually CAN use them even to do things they don't know how to do,
unless the tool can completely automate the process and autodetect
everything, which is rarely the case.

It is often the case that they remove needless complications and bring
related things together in one place -- setting up PPPoE involves
filling in a "questionnaire" detailing the things that are actually
parameters of the process, and the computer does all the rest, instead
of the user having to separately find and hand-hack half a dozen text
files in cryptic machine-readable formats according to arcane
instructions that cannot actually be located anywhere, but nonetheless
apparently exist, if only in the system's designer's head
someplace. :)

> [*] Something I've been making off-and-on attempts to figure out,
> and -- well, maybe if I read through all the online help carefully
> I'd do better, but just dipping into it, mostly what I get is
> a sense that somehow they're trying to express not-that-simple
> technical ideas in non-technical language ("team", "share project",
> etc., etc.). Clearly this is a case in which background reading
> is needed, but .... Well, I digress again.

It may be a case of them having tried to dumb-down something technical
and not actually amenable to being dumbed down. The error at the
opposite extreme from excessively sophisticating-up something basic,
such as, say, text editing, until it comes to resemble rocket
science. :P

Setting up CVS can probably never be simplified to "just push this
button and away you go". On the other hand, text editing should
probably never be complexified beyond "just push this button and type
into the box, and navigate and such in the normal way" ...

> Your point about a guild mentality is all too true; I rather *like*
> the feeling of being part of a somewhat exclusive club, but I'm not
> sure that's really something to boast about.

Not more powerful is the Dark Side; but more seductive it is. But once
you start down the Dark Path, forever will it dominate your destiny!

> Then again, it seems
> natural enough to be a little smug about being able to do something
> not everyone can do. Write Java programs, for example. :-)?

Sometimes it's something "naturally difficult". Actual programming,
for example.

But it seems screwy when it's something "artificially difficult".

It's a big accomplishment to climb Mount Everest. On the other hand,
it's still damned stupid of anyone to decide unnecessarily to locate a
7-11 way up there where almost no-one can reach it.

It's a big accomplishment to program complex software yourself. On the
other hand, it's just plain brain-damaged if some text editor,
newsreader, or whatever basically has to be programmed in its own
idiosyncratic scripting language just to use the darn thing, instead
of getting out of the way so the user can get their *real* work
accomplished.

Some game software makes the same sort of mistake, I find. Certain
RPGs particularly. You end up with "work" to do to, say, generate a
pile of ammunition or money or something, only to get pestered by
random encounters when you're "at work" instead of actually off
adventuring or whatever. :P

In a way, it's even like a sort of spam. It's intrusive and unwelcome.
You want to check the latest posts at some webboard or browse for and
download some file or find and read some information, and every other
mouse click leads to a popup or three, every other link seems to
gratuitously go via a "splash page" covered in ads instead of directly
to its nominal target, and no page at all isn't plastered with
animated GIFs and Flash. Needless to say, you get Firefox and adblock
or you go insane.

Unix tools seem to have a different motive, if they have one at all,
but again the interface (or lack thereof) intrudes on your simply
getting on with your task, whatever that may be, and keeps you
conscious of the interface itself. Most of your attention and thought
ends up being focused on how to navigate the interface. Generally with
exactly zero visual cues with which to navigate, too -- they subscribe
to the "drop people blindfolded into the middle of a hedge maze"
theory of navigation and interface design. Usually having selected
flora on the basis of having eight-inch thorns, since obviously a
blindfolded person will be unable to appreciate colorful flowers and
foliage! Regardless, it's hard to focus on (let alone be very
productive with) one's main task when one is constantly having to
concern themselves consciously with the interface and, often, what
passes for the help file. Instead of "editing text" or "reading news"
you're "using vi" or "using trn" or whatever, as determined by your
attentional focus. It doesn't become transparent and get out of the
way. If you find "using vi" fun or challenging that's one thing. If
you just want to "edit text" on the other hand being forced to do so
is liable to get very annoying very fast.

> Well .... It's not that you don't have a point; you do. But for
> some tools I'm willing to accept a certain amount of novice-hostile
> behavior if I get expert-friendliness in return. I think. I'm not
> sure when I last had to get up to speed with such a tool ....

The problem being that you really *can't*, save perhaps with a live
tutor, as near as I can figure. Unless you designed it to begin with I
suppose; then you'll know it inside and out. Often that seems to be
necessary; knowing the internals instead of just the problem domain
seems necessary to use a lot of that software. In some areas that's
more or less unavoidable; those are the very areas where you say GUI
tools keep coming up short (network configuration, etc.) but even
there a proper GUI tool can streamline the process and organize it
visually into a series of parametrized steps (the "setup wizard"
design, at setup, and a tabbed dialog at later times when changing
something), as well as provide a specialized editing tool (that
dialog) that does validation and gives immediate feedback in some
areas. Hand-hacking the config file(s) versus using a well-designed
such tool is akin to using a plain text editor on a Java file versus
using Eclipse, with its on-the-fly linting of the code and
autocomplete capabilities. Only more so, since usually there are much
tighter constraints on what's valid, and what you're entering isn't
Turing-complete! Just numbers with certain range limits, etc.

> The other thing I like about configuring by editing text files is
> that *you know where the configuration information is stored* --
> so you can back it up before making changes, and it's potentially
> much easier to track what you actually did than if you were
> pointing and clicking through menus. Or that's my mileage, anyway.

This is a point, but it points more to an issue with common GUI
implementations of such things than with the GUI concept. The GUI
configuration editor could tell you where the file is, or even provide
backup/rollback functionality directly. That they often don't is
shoddy, I must admit. Of course there are tricks -- use the
configuration editor and then search system-wide for files modified in
the last five minutes right afterward and you'll probably find it in
the small number of hits; if not, it's probably using the registry
(ick). Ordinary Joes shouldn't have to resort to such tricks of
course. Again a problem of implementation, not of concept.

> Well .... I don't know. I'm not sure there's such a huge
> difference between looking through a manual and pointing and
> clicking one's way through a lot of menus and tabs.

There is, if the latter is well-organized; finding something in a
linear text is O(n) versus O(log n) for a tree structure. (This
assumes a printed manual, or a help system that lacks hypertext/search/
etc. functionality, or in which such functionality is nontrivial to
discover and use; the usual situation with unix documentation, IOW.
Search also suffers from the possibility that the document is not
written with searches by n00bs in mind; if the solution is described
purely in solution-domain terms without a good description of the
problem it solves in problem-domain terms accompanying it, it will not
be found by someone who doesn't know the solution, but only knows the
problem; it will be found by someone who remembers part of the
solution or the gist of it and needs to retrieve the details, which is
the only target audience typically considered by unix documentation
writers, unfortunately. Put more simply, people search for the
question, not the answer, and if the answer appears somewhere but not
right after the question...)

> And don't get
> me started on the little icons. Which one does what? Who knows?
> Sure, put the mouse over one, wait a few seconds, and probably
> some moderately explanatory text will appear. That wasn't the one
> you wanted? Move the mouse, wait a few seconds. Move again, wait.
> Maybe you get used to it.

Generally, the ones you use you learn to recognize, and they take up
less space than text menus would (and as a result, can be right in the
main window instead of needing an additional menu-title click to
reveal first). The images should generally communicate what they do.
They don't always do it very well. Many have been standardized to some
extent (cut, paste, new, open, print, etc.; browsers' back, refresh,
home, etc.) but many have not. This area may mature further in the
future. Again many apps admittedly could use improvement. At least you
*can* browse the available functionality and find stuff, and once you
know where something is find it again very easily, without resorting
to the help!

> You do? Once again I think we must be talking about different
> software. Example: the (in)famous two modes (insert and command)
> of vi. "Real" vi (and vim in compatibility mode) doesn't provide
> any cues about which mode you're in, which is the situation
> you describe. But vim (in its default mode) does, with the text
> "--INSERT--" at the bottom of the screen when you're in input mode.

One case in which they fixed the "bug" it seems. There are surely lots
of other places where that sort of thing is still extant. There's only
so much information that can be displayed at once on an 80x24 text
terminal, after all; within the constraints of the older display
devices (and emulations of same) there's limited real estate to spend
on keeping the user oriented.

Emacs (some version or another) certainly provides some issues along
similar lines -- with no tabs/taskbar/analogous structure, for
example, and no Windows menu, there's no way to see at a glance what
documents are open. Just the one or two you see, or several dozen
more? Who the hell knows? There's probably some way to rotate through
them all, but it sure as hell ain't ctrl-tab, and opening the help to
find out what it is will alter the very thing I'm seeking to measure,
since the help doesn't open in a separate system-help-browser
application...

It can also be in the state of a long meta-sequence being half-
entered. (Windows apps admittedly suffer from the equivalent problem
fairly often -- if they think alt has been tapped, subsequent keyboard
entry may unexpectedly trigger menus or annoying beeping instead of
working as expected.) The upside is leaving the app with such a thing
half-done is uncommon. And at least Windows lets you back out of this
state with one ESC keypress. Emacs as I recall seems to do nothing
until you hit ESC a few more times, and then beeps and prints
something like "Unrecognized command: M-Esc Esc" or some such. :P

Browser-type programs too: they may be navigating line-by-line or link
(or occurrence of search term) by link, and it won't be obvious which.

GUI apps have a big advantage here in that when there are modes, they
can be indicated by changing the mouse pointer in a communicative
manner. Paint program tools are the obvious example, though the
toolbar's depressed button also provides a visual cue.

Of course, the worst unix offender of all time has to be the shell
itself, rather than vi, emacs, or anything else. For a long time, at
least, the standard was apparently to display a completely rudimentary
shell prompt with no indication whatsoever as to where you were in the
filesystem. Contrast

C:\Dir\Subdir>_

with

%>_

Which is more useful here? Of course you could configure the unix
prompt -- if you could find out how from the help system. You could
get some information with "cd" or see if you were somewhere
recognizable with "ls". Puts me in mind of fumbling around in a dark
house with a flashlight looking for the light switch. With large and
heavy pieces of furniture here and there about the place. And the bulb
in the fixture probably burnt out. And on attempting to replace it,
finding that it doesn't have a standard screw base at all, but some
kinky mechanism with a half-dozen pins and clams that have to be
worked with tweezers. In the dark. With the tweezers located at the
other end of the place somewhere, with miles of darkened hallways and
treacherous staircases to traverse in the dark to reach them and
return with them. Oh, and in case I forgot to mention it, all of this
has to be done in the dark, and the batteries in the flashlight seem
to be going dim. :)

(Admittedly, old DOS versions defaulted to a useless C> prompt barely
conveying more information than %>, but DOS fixed that a lot sooner
than I recall unix of any sort doing so!)

Flow control in the terminals created another issue; something of a
trilemma. Say you had a text file displayed partially on the screen
with no visible prompt. What is it doing? Is it a) waiting for XON? b)
waiting for you to hit space or down-arrow (but surely not page-down,
no, never would page-down do the obvious)? or c) just plain hung? :P

> I wonder, too, if what you describe might be something of a
> YMMV thing reflecting different styles of thought or something:
> What I'm thinking is that some people seem to have no trouble
> remembering shortish strings of meaningless data, such as phone
> numbers, while others apparently would have to work hard to do
> that.

It's designing software to cater to the type of autistic savants that
can memorize *a whole damn phone book full of such numbers* and
remember exactly who each one calls that bugs me. The UI for emacs
appears to be designed for autistic savants, in particular. :P

One or a few such things is one thing. Forty thousand is something
else entirely.

GUIs have a clear advantage in usability here, all other things (such
as commonly-used-command-set size) being equal, because the normal
human brain is geared toward remembering place-associations and
geography. If you saw it once you can navigate to the same place
again. Our ancestors found this handy when they had to locate good
watering holes, bushes with various medicinal leaves and edible
berries, and other such useful things in their environment. Most of
those objects stay put; their locations are fairly stable on
timescales comparable to a human lifespan or so. Phone books and
similar such things have appeared, by contrast, in the evolutionary
blink of an eye. People cope with the primitive interface of the phone
system (and it is damned archaic; all we could do to improve it so far
was *touch-tone*?! Talk about legacy apps!) mainly because most of the
times they only have a handful of numbers they use at all often, and
of course they need to look up manually some directory entry somewhere
in every other case, which is annoying and tedious. The phone system
is in need of a major redesign; converging the phone into the computer/
PDA is likely to be part of any such redesign, and then it will be as
easy and convenient (and cheap, even at long distances, hopefully) as
email and the web, complete with bookmarking. (Speed dial? Address
books in cell phones? What a joke. Mainly due to the terrible user
interface forced on the designers by only having ten or twelve heavily-
overloaded buttons instead of a 101-key keyboard to work with in the
input-device area, and a tiny LCD screen or none at all for an output
device. Usually there's not even any way to make it "remember who just
called me/I just called and dial them whenever I hit autodial 1" or
something of the sort; you need to type the number in manually to set
it up. If it's a caller rather than callee you may not even *know* the
goddamn number. :P)

> In my opinion, most of these advances are most helpful for tasks
> you haven't done before or don't do often. For such tasks,
> I agree that it can be pretty nice to be able to point and
> click through menus rather than reading man pages and editing
> configuration files. For tasks I do often -- and that's most
> of what I use those text-mode tools for -- well, for example,
> I find it faster to type ":w<return>" to save a file than to
> click on a little floppy-disk icon.

I find it faster to type Ctrl+S than to do either, and *much* slower
to go traipsing through even a well-designed and familiar help browser
than to click on an icon. ;)

Common actions usually have keyboard shortcuts -- from the sounds of
it, shorter ones than unix tools. And then the menus and buttons
provide alternatives, for when you don't know the shortcut yet or
forgot it. Menus usually indicate the shortcuts of items that have
them. Shortcuts for generic, domain-independent actions like "save"
are standardized (e.g. Ctrl+S, and Ctrl+A for save-with-new-name)
instead of idiosyncratically different per application. Shortcuts are
generally control+something chords or else alt, x, y, z sequences and
never clash with potential ordinary-typing keystrokes or other usages,
barring a few applications that have no ordinary typing involved in
their normal use (text fields in dialogs notwithstanding), so mainly
graphics-editing tools.

Of course, sometimes there's an action that while commonly done
annoyingly lacks a short ctrl+X type shortcut and only has a longer
alt, this, that type sequence, and rarely something fairly frequent
requires working with a dialog to do. These just show that poor UI
design can happen with GUI tools as well. Even then, GUI tools at
least offer the poor user much more scope for recovering from these,
and from the user's own goofs such as may occur! Sometimes the user
may be helpless to do something really quickly, or to fix things
easily after an error, but they're much less likely to be helpless to
do/find something at all, or to even know what went wrong after an
error.

> But the occasions I'm vaguely remembering -- and it's altogether
> possible I'm confusing Eclipse with another IDE (Together
> from Borland) -- did not result from attempts to operate on
> configuration files with other tools. I'd be happier if that were
> possible, but before attempting it I usually make a backup copy of
> the -- well, with Eclipse usually the whole workspace directory,
> since I don't really know where the configuration files are kept --
> and if things go wrong with the "edit outside Eclipse" experiment,
> I'm apt to conclude that it's not going to work, and just replace
> the messed-up workspace with the backup.

Smart. As for where the configuration files are kept, you can probably
find out from the documentation or by just poking around and
exploring. The good news is that for most ordinary purposes you don't
actually *have* to. Contrast that with just about anything unixy I can
recall running across...

As for how they got hosed, if you kept diligent backups of config
files and restored them at the first sign of trouble, and this didn't
fix/avert the disaster, I'd guess it was a bug. Made by Borland.
Eclipse just doesn't seem to be prone to that kind of thing.

Bugs happen. I am fairly certain they are not exclusive to Windows
software, if perhaps more common in Microsoft's own software than in
many other companies' or in open source. This could happen with a unix
tool as well, and if you don't know a whole lot about how and where it
stores this stuff and in what format, you're just as hosed. It's just
the unix tool probably won't even start and function normally until
you've already learned that stuff and acted on it in some particular
way; Windows tool users tend to have the luxury of ignoring such
details until and unless something stops working and only then having
to worry about what's under the hood.

Cars used to require hand-cranking some gadget under the hood to start
the engine, as I recall, but obviously now there's a control in the
driver's interface area to do this instead. Only when they break down
is it now necessary to fiddle around under the hood, or get out and
push or something. Software on the other hand seems to be where cars
where in the early 20th century -- around when this sort of thing was
just changing over. Only with some makers already having introduced
automatic gearshifts too. I guess software and computing develops
faster, but older models have about the same turn-over curve, with ten-
plus-year-old models still being driven in not insignificant numbers
in both cases.

> It's not the mouse that's unreliable; it's me. I find keyboard
> navigation is almost as fast (especially if I can get to the
> right spot with a search), and much more reliable -- getting
> the cursor placed on precisely the right spot on the screen is
> not something I do very well. More practice using a mouse might
> help -- or it might cause me to know more than I'd like to about
> repetitive stress injuries.

I don't find a GUI browser provides any disadvantage there. You can
still arrow up and down, and (ugh) search; you can also use the scroll
bar to jump to a proportional place in the document (e.g. 1/4 of the
way down) in a consistent way, and to page up and down, and simply to
*see* where the hell you are in the document and get a gauge of how
big the document is. And you can jump within the portion displayed,
using the mouse, to select any area by hand. Even click in vicinity
and hit arrows a couple times is much faster than hit up-arrow 17
times, right-arrow 43 times, then shift-right-arrow 21 times...

And of course you can move a page at a time with the keyboard in a
consistent, natural, and reliable way with the page up and page down
keys. Space also works. But there's no more "how the hell do I go up?"
issues -- "is it -? backspace? just quit and start over from the top,
even?!" And search is, as it should be given the typing and target-
specific actions involved, a last resort. Particularly as using it to
navigate within a document is limited to what you've already read in
detail, and, with reduced usefulness, what you've skimmed. If I want
to jump to the bottom of a document it's easy with a scrollbar and
mouse. How do I do that with search unless I've read the whole thing
before and memorized some likely-unique phrase near the end? Also, if
you get the search slightly wrong you go nowhere. If you get the
mousing slightly wrong you end up near where you wanted to go and it's
easy to nudge it the rest of the way where it should go. The GUI way,
you miss your exit and take the next and circle back and get there a
bit later. The unix way, you miss your exit and the next exit is
somewhere between Omaha, Nebraska and fucking Timbuktu, or even a
great-circle all the way around to back where you started from. :P

> That (ton of reference information) might actually be helpful.

Sure, but if you're looking for concise information regarding "how to
do X" it's not helpful for that particular task. Reference material
and tutorial material are by their nature fairly different from one
another in content and structure. Consider javadocs. Those tell you a
great deal about specific library functionality but do they help if
you want to know how to compile? The fastest way to store references
to a bunch of Foos and remove the duplicates? Nope -- the one is
completely outside their scope; the other is documented with Set and
HashSet in particular but there's nothing in the front page view of
the docs that would naturally lead a querent there who didn't already
have at least passing familiarity with Java, and with the java.util
package in particularly. And though you could in theory answer that
question and learn a lot more besides by reading the whole shebang
from cover to cover, who but the aforementioned autistic savant is at
all likely to even be *capable* of doing so without going batshit long
before they were done?

Fortunately there's also Sun's Java tutorial and other material geared
toward n00bs or specific how-to questions. (And this newsgroup, and
google).

Point being, reference material has use within a certain scope, but
sometimes the vendors of certain software products fail to provide
anything with use beyond that scope. Sun doesn't seem to be among
them, fortunately.

> What make me rant is "help" that tries to express technical
> concepts in non-technical language. Eclipse's explanation of how
> to work with CVS repositories comes to mind.

This can be an issue. It's probably trying to be both of the above
types of help at the same time, and failing at both. Badly-written
help is unfortunately not that rare, any more than is completely-
missing help (of one or both types).

> I don't find it difficult to remember the keystroke combinations
> I use regularly, and for stuff I don't use regularly -- it's hard
> to be sure, but I don't know that having done something with a
> GUI makes it easier for me to remember -- I think I'd be more
> apt to just remember that the task can be done and there's a menu
> *somewhere* (possibly not in the same place it was the last time
> I did the task -- GUI designers seem to like to tinker with this
> stuff from release to release.

Rearranging things in the GUI from one version to the next is indeed
objectionable. Ideally there would be separate interface
versions/"deep skins" (that go beyond looks to things like control and
menu organization) and engine releases, and you could choose to
upgrade only the engine. Software architected as I suggested earlier
in this thread would have this occur naturally.

On the other hand, your own complaints about old and new versions of
something puking when forced to share one copy of the configuration
file indicate that the unix equivalent of your GUI-software complaint
does occur -- they gratuitously change something and make the format
of some file or another not forward- or backward-compatible (or even
neither).

> This is something else I like about a command-line / text-files
> approach to configuring things -- there's a better chance that,
> for something you don't do often but have done successfully at
> least once, there will be a record somewhere of what you did,
> so you can repeat it. (Or if it didn't work, a record of what
> you tried.)

That sounds to me like it would seem more useful in theory than it
would prove to be in fact. First, this "record" would take the form of
a copy of the configuration file with the change you made. This is
likely to not exist, as it's likely to have been clobbered by the next
change; certainly you're implying something was changed, then changed
back, and now the user wants to change it again. If they backed up the
file when they made the change back, the backup when they changed
something else later on is likely to have clobbered THAT copy. And
even if a copy survives, an old copy of some obscure configuration
file gathering dust in a now-disused corner of the file system is
likely to sit there for eternity, being copied now and again when
everything is migrated to new hardware, and perhaps also onto numerous
backup discs or tapes, without ever again being seen or noticed by a
human being. Finding it would require guessing that such a thing
existed and then searching for it. Probably manually, since automated
search only works when you have a good idea (including some exact,
accurate text strings) what you're looking for, and in this particular
case if you remembered what was in the file you wouldn't need to find
it anyway! And, of course, once you DID, by some miracle, find it,
what you DON'T have is a diff between the two versions showing exactly
what you'd changed. And of course any tandem changes to other files
won't be apparent. If you recreate what turns out to have been only
half (or a third, or whatever) of some previous change instead of all
of it, you'll probably just hose the system thoroughly. Backups
certainly seem warranted; too bad you can't do anything with them if
the machine won't even boot now, or the partition with the renamed
copy of the last known-good configuration is the one that now refuses
to mount, or whatever.

> > That's like putting the little numbers onto a formerly-blank stick
> > shift instead of noticing that a few decades ago they invented this
> > nifty thing called an "automatic transmission". :P
>
> I think you won't be surprised to hear that I rather like stick
> shifts too.

No. Unix and stick shifts both cater to the sort who like to
micromanage everything instead of just getting on with the job at a
default coarse granularity and only getting nitty-gritty when there's
a problem or exception of some sort.

In funny ways they both automate one thing and don't automate the
other. Unix stuff is much more amenable to automating particular data
manipulation tasks and whatnot, but forces the user to micromanage the
system and, basically, *program* it to do anything (with a large
library of pre-existing subroutines at least -- if not one with
anything as comprehensive and easily navigable as Java's javadocs PLUS
tutorial to guide you through it!); if the user wants a single common
task to be done by hitting a single key, they need to program this
behavior in first! Windows and its ilk on the other hand far better
automate the user's tasks of finding their way around the system and
making it do things, but do a poorer job of supporting automating the
things themselves.

For example, rename a huge batch of files to add a "foo_" prefix.

Unix (command-line): Getting to the files is a chore, and a long
arcane command must be typed to rename a file once there. However,
this command can be generalized or a script file easily used to rename
the whole lot in one shot.

Windows (eschewing use of a DOS box): Getting to the files is easy and
renaming one is as simple as click, f2, type new name, enter. However,
renaming the whole lot entails click, f2, home, "foo_", enter, click,
f2, home, "foo_", enter...

Windows (with DOS box): Find the files easily. Select path of
directory from a text field at the top of the Explorer window. Open
command prompt, put in "cd " and paste, and there's a long arcane
"for" command that can be typed to do the batch rename.

Windows, no DOS box, don't care about the new names *except* for the
prefix: select all of the files, hit f2, and type "foo_.ext". Result
will be foo_.ext, foo_ (2).ext, foo_ (3).ext ...

Unix (with some X WM): Probably allows a Windows-style ability to
navigate to the files and rename one of them easily by hand without
much arcana.

It seems the GUI systems support both automating at the UI level and
automating at the data manipulation level, but not at the same time.
The non-GUI systems only support automating at the data manipulation
level.

There's a lesson here. Perhaps that we need a kind of visual or
gestural language capable of the rich semantics of a scripting
language.

AI software was demoed a few years back (as a Java applet!) that could
draw analogies between two sequences. Perhaps this kind of AI is key:
a user could rename a few files with "foo_" prepending and then hit
some "automate" key. The system will then examine the last few user
actions and look for a pattern. The last few commands were file
renames. The sequences of old and new names, side by side, have a
discernible analogical relationship in that they all differ pairwise
in an algorithmically-specifiable way -- one single algorithm can
generate the output sequence from the input sequence and isn't just a
lookup table. Ergo, show the user a preview of the results of applying
this to the whole available scope; the directory containing all the
files the user just renamed. Perhaps the user renames a few files and
hits say F9, and all the other files' names change to show a
differently-colored "foo_" at the start. The user can scroll around
and such. If they go to take any other action in that window they're
prompted to accept or reject the changes. (Until then it's dimmed to
indicate it's all temporarily read-only.)

Of course this could screw up in some subtle way. So can "replace
all".

In the specific case of batch renaming, in fact, it's probably the
same thing under the hood: the analogy-discovering part outputs a
regular expression representing the change in a parametric way, which
used as a regexp replace would have transformed all of the original
names of the renamed files to their corresponding post-rename names,
and isn't just a lookup table special-casing each one.

In other situations, particularly with non-text data being
manipulated, it's going to be something more general, though a lot of
the times it might still be the case that the output "script" can be
treated as a finite automaton working over some kind of regular
grammar in some symbol space.

> How would binary search be useful anyway?

To find something in alphabetical/whatever order, given the absence of
a (known) way to automate the search, but a way to scroll decently
rapidly through the document.

> And I thought everyone knew that to search for text you type "/"
> and the text .... Sort of a :-).

Yeah, when it's not ctrl+S, or ctrl+F, or M-x s, or alt-Q, or control-
shift-J, or ... (but rarely ctrl+F, and *never* F3!)

Not that it would be quite so bad if it weren't both not documented in
any obvious place nor readily discoverable by any other means. It's
often not obvious that any kind of search is supported. Honestly, even
on DOS I find most text-file-echoing things to be very clumsy to use
for anything but linear reading of very short documents. Notepad on
the other hand does quite nicely -- you can see where you are and how
big the document is at a glance, you can move around at any speed and
(since Windows 95) you don't even have to do so blindfolded as it
visually scrolls as you go; you can search, of course, and if you
don't yet know that it's *universally* accessible via ctrl+F and F3,
you can use the menus to both find out and actually do a search; and
of course plain old up- and down-arrow work, and (*gasp*) Page Up and
Page Down too! There's no shortage of navigational options, both
mouse- and keyboard-based. If you still can't find your way around the
document, it's either fucking huge and too undifferentiated for search
(what is it, a logfile, and you're not looking for something
exceptional even???) or you're as blind as a bat or as dumb as a
post. :)

> > There is still a 500-page manual with no page numbering.
>
> For a stick shift?

For a Unix app. If it's anything whose functional domain is at all
complex (e.g. server configuration or 3D dataset manipulation rather
than, say, mere text editing or file renaming) it's going to be 1500
pages or more. :P

> Talk about a word that pushes my buttons! Do you know the
> oft-cited remark about how the only truly intuitive interface is
> the nipple, and everything else is learned?

Consider it shorthand for "you can actually see what the hell you're
doing and where the hell you are, and what tools are sitting on the
workbench in front of you" then. :)

> Actually I think it *is* true that what you learn from operating
> one typical GUI application is apt to make the next one seem
> more "intuitive". But I claim that the same is true of the old
> text-mode applications as well.

Doubtful, since the only consistent rule among them all is
inconsistency -- aside from the absolute and inviolable ban on making
any kind of use of page up, page down, function keys, or (usually)
delete, and making ctrl+C quit rather than copy. :P

java-programmer >> Great SWT Program On Sep 22, 5:17 pm, email***@***.com <email***@***.com> wrote:
> > Not when you apparently draw a distinction between one phrase that
> > means "not seeing things as they really are" and another phrase that
> > means "not seeing things as they really are". :P Or at least, normally
> > means that. Apparently you're not using the same dictionary
> > definitions of some words as I am.
>
> Apparently not. Please point me to a dictionary whose definitions
> make the words equivalent, interchangeably, equally insulting,
> what have you. I just consulted the definitions given by the
> online Merriam-Webster (http://www.merriam-webster.com) [*], and
> the don't use the exact words you do, nor do their definitions
> seem to me to be equivalent, only somewhat similar.
>
> [*] No claims about it being best, just one I can access fairly
> easily.
>
> In part the difference I perceive is one of degree rather than
> kind. But there's also a subtle difference of kind -- "you
> hallucinate" means you see things that aren't there at all,
> while "you have a distorted view" means that you see things
> that are there, but in a way that's a little, or a lot, off.

Any suggestion that I have a malfunctioning perceptual system at all,
independent of the details of the supposed malfunction, suggests
"dangerous" mental illness and is insulting. And untrue. Doesn't
matter whether you're suggesting it sees entire extra objects, fails
to see objects that are there (beyond the normal limitations of the
system vis-a-vis angular range, blind spots, spatial resolution
limits, waveband, what-have-you), altered versions of what's there
(colors reversed, wavy lines over everything, whatever) or what.

If I see something, (unless I'm asleep) it's there. And whatever I'm
seeing is a good approximation to whatever it is that's there, modulo
the normal limitations. At any rate my observations are at least as
trustworthy as an average human's. It might be flashing on and off in
the infrared (say, a TV remote with a button being pushed repeatedly),
and I won't see that, but nobody will without special equipment. On
the other hand if I tell you it has a rather shabby green plastic case
and the battery compartment door is taped in place, you can rest
assured that it has a rather shabby green plastic case and that yes,
indeed, the battery compartment door is taped in place.

If you see it differently, then it's quite likely to be you who sees
it "abnormally". Maybe it looks brownish -- likely red/green color
blindness. Maybe you don't see the tape -- probably you're just not
lined up right to see that side of it, but if you are, I hate to tell
you this but you're obviously in need of the services of an
optometrist. If you can't infer that it's an old, beat-up one and that
the repeated button-clicking is probably because something in it
indeed no longer works, then it may be another sort of professional
help that you could use. :)

> Could be. But you also could be mistaken. You might not notice
> that spider on your back either, when someone else might.

There is no illness.

If there were, there would be symptoms, more or less by definition. It
is highly unlikely I would have completely avoided noticing these,
given I'd be around consistently when they manifested, much more so
than anyone else.

> Look, I know how annoying it can be to have someone else claim
> to know the insides of your head better than you do yourself --
> a long-ago college friend majoring in psychology used to try that
> with me -- but in some cases it's probably true.

In this case, it's flatly impossible. You have no specialized
knowledge, nor any knowledge about me save by what I type here, which
of course could be constructed so as to suggest anything I choose
anyway. From it you can infer nothing save that there's an entity
possessed of general intelligence and ability to process natural
language in a sophisticated way with control over a particular gmail
account and an evident interest in Java. :P

And yet here you claim to be able to diagnose something, despite no
patient examination, no patient history, no functional neuroimaging
results, and basically no other evidence with which to draw any kind
of conclusion. Not even some pseudoscientific quackery such as a
Rorschacht ink-blot result or a horoscope, tea leaves, entrails, or
something like that!

Quackery, schmackery. You're basically claiming to be psychic; perhaps
specifically telepathic. As an extraordinary claim, such requires
extraordinary evidence to convince me, and, I hope, anyone else
reading this.

Until then, it's a safe bet (on purely probabilistic grounds, as well
as them's-the-facts grounds) that the suggestion that I'm wacko is
false. She might as well open the phone book to a random page and,
blindfolded, stab a finger at a random spot on it and say "He's going
to be the next Jeffrey Dahmer". Which will probably be disturbing news
for the customers of Harry's Hardware, 147 Eastbrook Dr., 571-9334,
"We have discounts on Michelin tires and GM parts!" whose half-column
ad she just fingered as the "next Jeffrey Dahmer". ;)

> Not saying you're one of them, just that in general it seems to me to be possible.

Yeah, and a random name from the phone book might be the next Ted
Bundy. It's possible. Only it's not very likely, and in this specific
instance I can say with authority that it's not true at all.

If you believe otherwise, then believe this, too: next week's
Powerball lotto numbers will be 2, 7, 17, 39, 57, and 3. Really, they
will!

Moving along now...

java-programmer >> Great SWT Program email***@***.com wrote:
> On Sep 22, 3:16 pm, Lars Enderin <email***@***.com> wrote:
>> email***@***.com skrev:
>>
>>> On Sep 21, 9:07 pm, Arne Vajh鴍 <email***@***.com> wrote:
>>>> email***@***.com wrote:
>>>>> On Sep 16, 9:41 pm, Arne Vajh鴍 <email***@***.com> wrote:
>>>>>> email***@***.com wrote:
>>>>>>> On Sep 16, 8:19 pm, Arne Vajh鴍 <email***@***.com> wrote:
>>>>>>> [snip false insults]
>>>>>>> I hate to sound like "Ed" here but: Fuck off. :P
>>>>> [snip repetitious BS]
>>>> [repeats it again]
>>> I snipped it for a reason, jackass! I don't *want* your nasty
>>> implications about me being repeated. In fact you can take all the
>>> nasty things you believe about me and shove them up your ass! :P
>>> Now go away and leave me alone.
>> There were no nasty implications by Arne.
>
> Yes, there were. He is trying to imply that I'm an idiot. He's simply
> not saying it directly. Regardless, his purpose is clearly hostile,
> since why the hell else would he imply such a thing? It's time for him
> to shut up. You, too.

There are drugs today that can help you.

--
John W. Kennedy
"There are those who argue that everything breaks even in this old dump
of a world of ours. I suppose these ginks who argue that way hold that
because the rich man gets ice in the summer and the poor man gets it in
the winter things are breaking even for both. Maybe so, but I'll swear I
can't see it that way."
-- The last words of Bat Masterson

java-programmer >> Great SWT Program On Sep 23, 10:07 pm, "John W. Kennedy" <email***@***.com> wrote:
> > Yes, there were. He is trying to imply that I'm an idiot. He's simply
> > not saying it directly. Regardless, his purpose is clearly hostile,
> > since why the hell else would he imply such a thing? It's time for him
> > to shut up. You, too.
>
> There are drugs today that can help you.

I know. Every time I log on and check news and, particularly, this
thread, I find myself reaching for the Tylenol bottle. :P

java-programmer >> Great SWT Program email***@***.com wrote:
> On Sep 22, 3:16 pm, Lars Enderin <email***@***.com> wrote:
>> email***@***.com skrev:
>>
>>> On Sep 21, 9:07 pm, Arne Vajh鴍 <email***@***.com> wrote:
>>>> email***@***.com wrote:
>>>>> On Sep 16, 9:41 pm, Arne Vajh鴍 <email***@***.com> wrote:
>>>>>> email***@***.com wrote:
>>>>>>> On Sep 16, 8:19 pm, Arne Vajh鴍 <email***@***.com> wrote:
>>>>>>> [snip false insults]
>>>>>>> I hate to sound like "Ed" here but: Fuck off. :P
>>>>> [snip repetitious BS]
>>>> [repeats it again]
>>
>>> I snipped it for a reason, jackass! I don't *want* your nasty
>>> implications about me being repeated. In fact you can take all the
>>> nasty things you believe about me and shove them up your ass! :P
>>
>>> Now go away and leave me alone.
>>
>> There were no nasty implications by Arne.
>
> Yes, there were. He is trying to imply that I'm an idiot.

Rather, that you were mistaken about a bit of largely-obsolete trivia. Not
the same thing.