Re: For those in need of some amusement.....

["Robert G. Brown" <bob@xxxxxxx>]

>>>Your email is messed up in my client as well....
>>I guess you need to update your e-mail client as well.
No sir, but the definitive answer is in my reply to your 
message from last night, a rather longish work in pro-
gress.

>>>Html as a text medium for email is a horrid choice. 
>>I disagree.  But that's okay, we are entitled to our 
>>opinions.
The reason HTML is a horrid choice is that (at least as
generated by many programs, including Outlook Express)
the message length is far longer than the contents. This
makes for very poor use of bandwidth; when you have mil-
lions of people sending this stuff, its no wonder band-
width is being soaked up so quickly.

>>>umm, Outlook Express won't run on my linux box, 
>>>although I suppose I could 
>>>get HP Openmail to do the job....
>>Too bad.
Only if you like Outlook, which I don't. IMO not being
able to use Outlook is simply not a problem.

Other issues will be dealt with in due course.

>>Let's take a time out for a specific example.  How about browsing the file 
>>system?  In windows you double click on a filing cabinet ....
>>OTH, in Unix, let's see.  You type ls. ...
Stop! Apples and Oranges. You're comparing a GUI to a CLI, and so propagating
the notion that there isn't a GUI for UNIX.

For the Last 15 years, there has been a GUI platform for UNIX. It's called:

   X-Window (or simply "X"). 

Instances of this system are also known a "X-Servers".

11 Years ago, Sun Microsystems produced a graphical file manager for X.
Runs on any X-platform, available free of charge on most UNIX distributions,
and has all the properties of of the Win9x tool you're writing about, as
well as a few more.

That's an Apples-and-Apples comparison.

Otherwise, please click the "MS-DOS" line on your menu bar, and compare CLI
and CLI, but please don't hand us this.

>>If someone is having problems getting a system running, 
>>assume first that he's an idiot.
I'm not at al sure it's fair to plaster "The Linux community" with 
this kind of labeling; it surely cannot lead to constructive dialog.

At the same time, I know it's not professional to be treated the way
I have by Microsoft, on more than one occasion, on calls I was making
to get problems solved, when I'd already paid for the call. You can 
always seek out alternative support strategies in the Linux environment;
it's proven VERY difficult to do that with some MS products.


It's fortunate that not all KLUG 
>>members have this kind of attitude or Linux would never make it.

>>Because, as I said further down, the time saved in learning curve outweighs 
>>the time lost due to rebooting.
But you're overlooking something. When I've gone through a crash or a 
forced reboot, I have sometimes lost work. I can show you dialogues on
some product installs that don't give the user a chance to shut down 
other tasks in an orderly way prior to system shutdown, which is very
design!

>>Because the most recent failure left my system so crippled that
>>it won't boot. I'm tired of hitting problems every time I do
>>something, and I just don't feel like running it down right now.  
>>God knows what I'm going to have to do to get this thing going again.
You're frustrated, Chris; this is not a rational answer. I see fear
written here, and anger. I do NOT see someone who is working towards
a solution, but someone who is generating catastrophic fantasies. 
Your problem might be TRIVIAL, and it might be hardware problems from
which NO OS can recover. But you don't KNOW, and you haven't looked.

>>... but hey, I'm bitter, it gives me poetic license.
True enough, but no one will attend the poetry recital, and it won't
get you a working system.

>>....How often does your car "crash" and have to be 
>>>"rebooted".  I mean if you are driving down the road and your car just
>>>dies, you will be one pissed off car owner.  Yet it happens to you on your 
>>>computer all the time.
>>But this happens every day to lots of car owners all over the world, doesn't 
>>it?  It's life.  It's accepted.
No, it's NOT accepted, and it's not easy. It's very, VERY traumatic for a
LOT of people, and it's something on the order of a national disaster in slow
motion. Thousands of people are at work in many places, striving to make cars
safer, and automotive standards are a hot topic in many levels of government
and corporate organizations.

>>...the "average" car driver has learned to accept that sometimes things 
>>don't work.  Your car is reliable enough.
Cars are reliable enough so that the risks involved in operating them in
large numbers can be managed, and almost a century has been spent perfecting
the present packaging and technology, with many incremental imporvements and
some major failures.

There's something else that's true about cars, and not computer systems, and
this is one reason risk can be managed. The notion of "operator error" is 
very, very strong. Almost 60% of the motor vehicle fatalities in the last
couple of years were related to the mixture of gasoline and alchohol; others
were related to loss of control due to the environment, or lack of sleep.
What I'm saying here is that "Operator Error" is a large factor in car
crashes, in fact the largest identifiable cause of fatalities. This is why
the industry is structured and insured the way it is.

>>Now, you may argue that your car doesn't die once a week or that...
Yeah, I'm not sure how applicable any of this is; I'm not sure if the car 
analogy breaks down (although it IS amusing in some quaint ways), or if the 
economics are too different to be useful.

The point is that most car crashes are operator-induced, while the very nature 
of good (stable, reliable, robust, etc.) software is to completely protect the
system from the ignorant or malicious user. Surprise! We find that the vast
majority of computer system "crashes" have nothing to do with operator error,
but with defects and instabilities in the system itself!

At least that's true of one group of OS'es. Linux (and others) seem much
less prone to this kind of problem.

If I'm driving tonight, there are some very real things I can do to stop
from becoming dead soon:

    1. I can leave that bottle of Whiskey in the cupboard.
    2. I can drive more slowly on icy roads.
    3. I can pay attention to traffic signs, and the markings
       on other vehicles.
    4. I can watch out for the nut cases out there that aren't
       doing steps 1-3 above.

>>>Reliability does not have to be sacrificed to give useability.  You've 
>>>bought a PR job I'm afraid.
>>Then, I counter that usability doesn't have to be sacrificed to give 
>>reliability.  But the Linux/UNIX world has done this.  You've bought the
>>PR job on the other side of the fence.
Hold on, guys! guys! You're both ignoring history and competing business
models.

Microsoft does not want to put anything out there that is not perceived as
easily installed, packaged, and complete. In practice, this sometimes results
in software that is almost useless in the first release, but the main stuff 
tends to work, and the packaging is real pretty; install goes nicely, usage
stinks.

GPL adherent developers want to broaden their base of peer reviewers AS 
EARLY in the software development cycle as possible. They release prototype 
code, and a lot of it is shaky stuff; hard to install AND unstable. Only the
idea and the goal is really there. The developer population tends to develop
FIRST, then package, and a lot of software packaging is not as glitzy as what
MS produces. The point is, you don't get to see this evolution in MS products,
since it all happens behind closed doors!

One way to tell that a GPL project is successful is to look for high (1.0 or
over) version numbers, and well-documented and simple installation instructions.
I'm SURE you';ll see "works great, not packaged yet" products on the GPL world,
it quite possibly means that it's not ready for simplified installs yet.

There are some very sophisticated and rock-stable GPL'ed products out there
that install right outta the box. In fact, I've found some distros where
ya have to do something to make 'em GO AWAY when you don't want 'em.

>>When Linux reaches a point where I can use it to do real work without 
>>spending more than 10% of my ramp time learning system administration, 
>>I will reconsider.  Until then, Linux is a hobby.
Chris, if you don't turn on your machine and recover it, you can't use Linux.
If it takes you half an hour to recover, you will reach the 10% in five hours.
So tell us when you've put in 5 hours of productive time (or whatever 10 times 
your recovery time was).

But until then, you'll never get down to that figure, becasue you've logically 
locked yourself out! :)

>>What's to be specific about here?  Large effort ->becoming a unix system 
>>administrator... small payout ->a perfectly stable system.   Obviously, if 
>>you value a perfectly stable system more highly than I do, your payout is 
>>larger, and perhaps outweighs the effort.  I maintain that for most people 
>>this is simply not the case.
Chris, I have a perfectly stable Linux system for the effort of an install.
So do many other people on this mailing list. Is THAT a better sounding payoff?

>>>>If this group would like Bob and I to take this off-line...
Yes, I concur with Chris. My next response will be longer, and I don't
want to belabor these issues in front of the group unless there is an
apetite for them.

>>>Keep the conversation, but fill us in (or drop) the banter about the
>>>(perhaps failed) website project etc. as we can't follow it without more 
>>>information.
>>The website was to present data from a database to the browser.  Two years 
>>ago, the tools didn't appear to be readily available.  Today they are.  I 
>>wrote C code to capture the data and present it to the browser in html 
>>format.  It is (was) functional.  It is not "up".
This seems somewhat oversimplified to me; the tools WERE available, but Chris 
took few or insufficient steps to obtain them, IMO. Still, this very short 
background is close enough to correct to set the context for the website 
project.

My point here is to be that technical completeness or no, satisfactory OS or no, not enough other aspects of putting a successful website on the Internet
were done in this two year timeframe, while studious attempts to do the same
have been very successful in far less time. It is thus inappropriate to point
to the OS as the cause for the delayed project.

                                                         Cheers!
                                                           ---> RGB <---