Linux-Advocacy Digest #700, Volume #27           Sat, 15 Jul 00 18:13:05 EDT

Contents:
  Re: one step forward, two steps back.. (Pete Goodwin)
  Re: Linsux as a desktop platform (ZnU)
  Re: Linsux as a desktop platform (John Jensen)
  Re: one step forward, two steps back.. (Pete Goodwin)
  Re: Would a M$ Voluntary Split Save It? (Leslie Mikesell)
  Re: Linux is blamed for users trolling-wish. (T. Max Devlin)
  Re: Would a M$ Voluntary Split Save It? (Leslie Mikesell)
  Re: Richard Stallman's Politics (was: Linux is awesome! (Leslie Mikesell)

----------------------------------------------------------------------------

Subject: Re: one step forward, two steps back..
From: [EMAIL PROTECTED] (Pete Goodwin)
Date: Sat, 15 Jul 2000 20:49:57 GMT

[EMAIL PROTECTED] (MH) wrote in <8kprc3$38k$[EMAIL PROTECTED]>:

>RH still insists that my external modem is missing on each boot, (when
>it's there), sometimes the sound works, sometimes it doesn't. Half of
>what I installed is buried somewhere - not on the menus.  The default
>installs I think are a good idea. Trouble is, some of them leave you
>hanging with a useless setup or bomb out trying to deliver the latter,
>or won't let you setup things they didn't install very easily.
>Having said that, however, it has improved for a novice.

On my system, if I forget to switch on my external modem, the Linux startup 
detects this and asks if it can remove the device!

>The window managers are trying to emulate windows. It isn't working.
>Neither Gnome or KDE comes close. I can see the point of trying, but if
>you're going to do it, do it right or don't do it at all. It's not
>right. The menu systems are a complete mess. Why does gnome have to
>automagically plaster that useless bar across the bottom by default no
>matter what WM you use? I know these things can be configured by hand in
>the config files, .. but I thought we were doing GUIs here, remember?
>Drag and drop support? Nope. Half baked at best. We're doing GUIs here,
>remember? We're better than windows, remember? Not at gui's your not.
>Not even in the same ballpark in the same league, in the same decade.

Ah, someone who agrees with me!

>Memory useage. When I ran Linux last, it was RH 5.1 on a P100 with 64MBs
>of ram. This box would NEVER swap. I was running Afterstep for the WM.
>Even that terrible excuse for a browser NN, when running with three or
>four other apps...no swap. none.. nada. I loved it. Now? HA. KDE, NN
>only, on a PPRO 200 with 96MBs of ram- I'm generating 50+ MB swap files.
>Not only that, the system does not seem much faster than the P100. The
>MS bloat syndrome has come home to roost. As I have said before, Linux
>was agile, and stable because it was lean and well tuned. The apps
>(small & lean) most people ran were tried and true. Now the $$ has taken
>over and wants the desktop. They're trying to emulate windows. It isn't
>going to work. You run big GUI based apps on top of big GUI'd window
>managers and you have created the same problems you have in windows.
>Only worse because windows has had years 'tuning' this slop to the point
>that it's getting practically stable now. --well, in windows terms any
>way! 

The Gnome and KDE desktops are probably getting to where MOTIF was several 
years ago. They descovered a lot of heavy memory usage and reinvented 
'gadgets' to replace 'widgets' that consumed a window, whereas gadgets 
don't. Down went the memory usage.

Pete

------------------------------

From: ZnU <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Sat, 15 Jul 2000 20:50:39 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
wrote:

> Said ZnU in comp.os.linux.advocacy; 
>    [...]
> >> http://www.uk.research.att.com/~dmi/linux-srt/wm.html
> >
> >This is just an easy interface for switching task priorities. Such 
> >things have been around forever, and have never gained much popularity.
> 
> Well if no one mentions them when some clueless idiot on Usenet starts
> spouting off about CMT and insists that the user needs and easy
> interface for switching task priorities, how come it doesn't occur to
> anyone in an *advocacy* group that nobody thinks to mention that "such
> things have been around forever," how the fuck are they supposed to gain
> popularity?

Many people mentioned that utilities were available to reprioritize 
tasks under PMT OSes. If it took them some time, it was probably because 
your understanding of the basics is so flawed that it wouldn't have 
meant much to you.

Of course, it shouldn't surprise me that you apparently didn't notice. 
You've ignored just about everything that has been said in this thread, 
and now that everyone has been driven to the end of their patience and 
said as much, you've become hostile.

-- 
The number of UNIX installations has grown to 10, with more expected.
    -- The Unix Programmer's Manual, 2nd Edition, June 1972

ZnU <[EMAIL PROTECTED]> | <http://znu.dhs.org>

------------------------------

From: John Jensen <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: 15 Jul 2000 20:58:10 GMT

ZnU <[EMAIL PROTECTED]> writes:

: Huh? It was pointed out that Apple probably didn't implement PMT because 
: the original Mac didn't have the RAM. The fact that a later Mac with 
: more RAM was on the market before the Amiga shipped doesn't make any 
: difference -- Mac OS had already been written.

I'm sure it's possible that it was a memory tradeoff, but I have a nagging
suspicion that a lot of the Mac crew were ex-Apple II programmers without
any PMT experience.  IOW, it is possible that there was a cultural
element.

John

------------------------------

Subject: Re: one step forward, two steps back..
From: [EMAIL PROTECTED] (Pete Goodwin)
Date: Sat, 15 Jul 2000 21:00:13 GMT

[EMAIL PROTECTED] wrote in
<[EMAIL PROTECTED]>: 

>Install is actually superior to Windows IMHO.

In what way? Installing Mandrake 7.0/7.1 the only real difference was the 
number of reboots - Windows seems to require a few, Mandrake just one.

>I agree, but development is plodding on and they are all getting
>better with each new version. Aside from bug fixes and cycle sucking
>animation, what has changed about the Windows desktop in the last 5
>years?

The big jump in the Windows desktop was with Windows 95. Previously the 
controls available were pretty naff. With the addition of the List control,  
Tree control, Rich Text and a few others it has made it easier to create 
good GUI's.

MOTIF had a whole set of controls but no equivalent to List or Tree. 
However it had controls that could attach to each other, something not 
available in Windows (but available in Delphi!).

>Active desktop (or whatever it is called?)? That's the first thing
>users typically turn off.

Yes, Active Desktop. Along with a whole bunch of other features, like 
animated menues, (Windows 2000) fadin/out menues, hidden files etc.

>Some folks like to do everything manually, and for them these WM's
>offer that level of control.

I'm still investigating KDE. I'm not sure I like the two toolbars - why not 
one?

>My PERSONAL opinion is that Linux should focus on the server/technical
>user market and should forget going for the desktop.

Then it will remain in the background and never challenge Microsoft.

Pete

------------------------------

From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: 
comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: 15 Jul 2000 16:01:19 -0500

In article <W1_b5.8053$[EMAIL PROTECTED]>,
Daniel Johnson <[EMAIL PROTECTED]> wrote:

>> I brought up some actual widely used protocols on the hope
>> that you could say something meaningful about them instead
>> of your usual unfounded rants about how bad protocols that have
>> been designed by groups of well-informed people are.
>
>I didn't say that, actually. I have tried to avoid harping on
>the *bad* open protocols out there, because I don't think it's
>relevant: I am not questioning whether such protocols are
>good or not, but whether they amounts to interoperability, all by
>themselves.

If you follow them, how might you fail to interoperate in a
way that can't be correctly diagnosed and fixed on the
side causing the failure?

>Oh yes. This is one of the standards everyone else
>had to adopt because they wanted to use the internet,
>and Unix won't understand *your* protocols, so
>you've got to learn its.

Learn?  In the case of proprietary proprietary protocols
perhaps you mean guess... Or maybe license.  Unix does
some of those as well as following the correct standards.

>
>[snip- agreement! We can't have that. Must snip.]
>> >You mean SMTP the *most popular* one, and thus
>> >everyone ought to use it, right?
>>
>> It is the one you can use without pre-arrangement.
>
>This is sounding very like Windows.

Really?  Can I run windows on my Sparc without pre-arrangement? 

>[snip]
>> >I suspect the devil is in the details, really.
>>
>> Of course it is possible to get them wrong, but that turns
>> out not to be a problem when you can easily replace a buggy
>> implementation with any other version you like.  If you
>> are stuck with a proprietary protocol with only one version
>> any problem is fatal.
>
>I wouldn't say that. The thing I would wish to avoid is
>being stuck with *any* protocol, open or not.

What do you mean by that?  For any two things to interoperate
you must use some protocol, so that's not a choice.  The choice
is whether to use a secret proprietary one where you have no
way of diagnosing problems or using it from a different
vendor's OS, or a public one that anything can implement
and use correctly.

>[snip]
>>
>> There is no need to force anyone to use open protocols. They
>> are always the best choice.
>
>You do say this, but I don't buy it. They *may* be the best
>choice, some of the time, but clearly not all of the
>time.
>
>It's too much to expect the standards bodies to get it
>right all the time.

Of course not, but they update them and add new ones as
necessary.  Just like the proprietary versions, except
the goal is to enhance cross-platform interoperation
instead of breaking it like the proprietary versions
do when a competitor figures out the last changes.

>> Perhaps you can name a few of these systems that will not
>> interoperate via SMTP.  I can't think of any offhand.  I don't
>> think it was developed under unix and it makes no particular
>> concessions to unix systems.
>
>I doubt there are any left; the Internet has become too
>important, and Unix has leveraged this to shove its protocols
>down everyone's throat.

Why do you keep shortening the huge list of systems that
use standard protocols to just 'unix'?  Are you really
that much in awe of it's capabilities?

>[snip]
>>
>> One for each purpose for public interchange.  Additional ones can
>> be used for private purposes where the standards are unsuitable
>> in some way or where the intent is actually to restrict interoperation.
>> However, since the standard protocols have been developed to
>> meet the usual needs, it is unusual to need anything else.
>
>I see, so you are saying that everyone ought to be made to use
>your favored protocol for "public" interchage; ie, I can have
>LAN Manager on my LAN, but I can't be permitted to have people
>outside my company dial into it, right?

I mean you can dictate which proprietary protocols must be
used to the set of people under your control.  You can
also offer a set of other protocols to anyone you want.
However, you can't expect to find a common ground unless
you follow open standards.  Something else might work
or it might not.

>Or do you just mean "Internet" when you say "public"?

That's the biggest interconnected group and thus the
most likely means.  But it turns out that internet protocols
work just as well in a private network too, and private
networks end up being interconnected all the time as
companies buy and sell each other.  After such a transition
whoever is in control can force everyone to replace their
non-conforming protocols - or if everyone followed standards
in the first place they could plug the networks together
and be done.

>[snip]
>> >Sure it is. You say it isn't because it isn't what Unix does, and for
>> >you, "interoperable" is synonymous with Unix.
>>
>> How can something interoperate if you have to change the other end?
>
>Well, first you change the other end, then you interoperate.
>
>It's not *that* hard, really.

When are you going to supply my Sparc will all the necessary
changes?  

>'Course, if you have this plug in stuff I've been going on about,
>you can change *your* end instead. This is often a lot easier!
>
>(Indeed, sometimes it is necessary: there are times
>when you *can't* change the other end.)

You should never need to change the other end. With open
protocols the other end takes care of itself.

>[snip]
>> >Where do they say this?
>> >
>> >I betcha they are saying something *else* is impossible, not this:
>> >Something like using Windows 2000 Actice Directory servers
>> >with NetWare clients, perhaps.
>>
>> I believe it is the win2k kerberized domain controller scheme
>> that they can't match.
>
>That suggests the limitation is in NetWare, if it can't do the
>things Active Directory can do.

No, it suggests that there are secret and proprietary things
carefully designed to prevent anyone else from being able
to do them in Active Directory.  That kind of thing is
good for the vendor at the expense of the user.  Why would
anyone use it?

  Les Mikesell
   [EMAIL PROTECTED]

------------------------------

From: T. Max Devlin <[EMAIL PROTECTED]>
Crossposted-To: alt.sad-people.microsoft.lovers,alt.destroy.microsoft
Subject: Re: Linux is blamed for users trolling-wish.
Date: Sat, 15 Jul 2000 17:10:14 -0400
Reply-To: [EMAIL PROTECTED]

Said David Petticord in alt.destroy.microsoft; 
   [...]
>I'll put my $0.02 in even though I know it will head into a discussion over
>defining "tough question" to mean a question a MSCE can't answer.
>You'll know this has happened when I post the response "OK, You win."

Sure.  Let's make sure we don't make any allowances for the possibility
of modifying our thinking.

>A real-life situation...
>
>A client calls me up complaining he got a Dr. Watson the night before.  He
>tried but couldn't make it happen again.  I walked him through using the
>Dr. Watson control panel to enabling logging.  For good measure, I told
>him to wave a dead chicken over his head and maybe the problem
>won't happen again, but if it did, to call me.
   [...]
>It turns out the Dr. Watson log file pointing to an application that
>used UDP ports which are normally free in a Microsoft only
>network. The vendor (not Microsoft) provided an upgraded
>executable that moved the UDP port used and added
>protections against future overlaps.
>
>To some, an explanation of "if you look at the documentation
>provided to you, it clearly states this application assumes an
>isolated subnet or, at least, free use of the following UDP ports."
>sounds like so much double talk and whining.  It so happens the
>client in this situation could grasp my explanation and agreed
>he shared responsibility for the problem.  He was delighted
>that we provided a solution that didn't require him to reconfigure
>his network (he out-sourced his IT department and it isn't as
>accommodating).
>
>The point...

Dave, you know I respect you.  But I'm going to have to point out that
you *really* missed the point of that long, ugly conversation I had with
Nathanial.

>Yes, it is easy to point to most professional fields and accuse
>some of "being a quack", "practicing voodoo economics", etc.
>This has a lot to do with the difficulty of the average person
>differentiating between an honest assessment and double talk.
>Most professionals tend to shy away from telling paying
>customers "I don't have a clue." and start listing the possible
>problems which could be described as "shuffling" to a
>casual observer.

Actually, David, your point illustrated my issue so clearly and loudly
that I thought, for a second, you were making it up.

Replacing an executable?  Why the hell would an executable have a port
hard coded into it?  Particularly a UDP port?  Most especially a UDP
port that is only assumed to be "unused on a Microsoft only network"?
This is such an amazingly stupid, incredibly moronic, outrageously
UNACCEPTABLE mistake, that it completely overshadows any discussion of
typical "shuffling".  That MCSEs begin with "common cause" lists, or
even "likely cause" lists, is an example of just what I'm talking about,
not merely the *appearance* of shuffling to avoid saying "I don't know."
I'm not concerned with how they handle it when they don't know, or even
have a clue.  My previous comments were meant to indicate that my
concern is the fact that this is the only position they are generally
in, and they don't recognize that as disfunctional.

But hard-coded port goofs resulting in app crashes, and documenting
them, without even distributing the fixed executable....  There's your
voodoo, that's the dead chicken.  "Deep magic" in the Microsoft world is
stupid mistakes like using a hard coded UPD port.  OF COURSE the vendor
provided an "upgrade" that doesn't make the even stupider mistake of
simply moving it, but finally implements (we would hope, but
unfortunately can't assume, if they are so stupid as to have the problem
to begin with) "protections against future overlaps".  What does that
mean, that they do it correctly now, or have figured out some other
innovative way to screw up?

And the customer *agreed he shared responsibility for the problem*!!!!

No, David, not only didn't the customer share responsibility for the
problem, the vendor should pay *him* for the loss in time and
reliability their absolutely utter and incomprehensible incompetence
caused.

THIS is why Windows failures are random.  You never know who is going to
be the bonehead today.  If this had happened in the Unix world (which,
of course, it might have; stupid people write software on Unix, too, and
I've known people to not understand how ports are supposed to be used),
everybody, EVERYBODY would immediately and without malice or reasonable
doubt know who fucked up, and it SURE as hell never would have been
suggested that it was the user.

Why the HELL didn't he just get an error saying "UDP Port N in use."  A
Dr. Watson crash?  And he had to send the decode to you, just to get the
first clue what was going wrong?

I can't tell you how incensed I am by this behavior, and its
presentation as SOP in the Windows world.  Apparently, the problems are
more widely spread than I thought, and even more rarely recognized.  I
haven't had a good couple of days to begin with, but I'm really
beginning to think that maybe I've been trying to be nice at the expense
of being taken seriously.  Maybe most of you people are clueless, and
don't have the first idea of the fundamental principles of PC computing
and internetworking.

The problem of Windows, and almost all of the problems of modern
technology, and much of the problem of modern business, can be charged
with one proposition: encouragement of cluelessness.  Intentionally
fostering or supporting cluelessness on the part of others in order to
benefit your own ends.  Its evil, goddamnit.  Its wrong.

Your example, I think, is still an example of waving dead chickens and
voodoo, though not as directly as my earlier descriptions.  But it is
practices and products like this which make voodoo so acceptable when it
does happen, and they are waving dead chickens.  Because if it took Dr.
Watson to clear up an obvious failure on the developer's part of this
simple and obvious nature, and so fundamentally indicative of an utter
lack of understanding or reasoning on "the Windows community's" part of
the nature and practice of TCP/IP ports which they wished to exploit*,
and the user was still convinced to blame himself, and your
documentation which so clearly hides** the obvious problem....

I'm about ready to give up entirely.  It seems to me that my points are
so obvious.  Sure, I know they sound outrageous, even off-the-wall, that
they're difficult to accept at face value, that even conscientious
skepticism would question them before considering acceptance.  But it
just seems to be that even when the evidence is presented, people
just... don't... look at it.  Or even look for it. Or even see it when
its pointed out.

Encouragement of cluelessness is a *bad* thing.  A Very Bad Thing.


* I use the term 'exploit' here in an entirely un-prejudicial sense.
However, it is worth noting that wanting to gain benefit from some
common facet of internetworking today, such as TCP/IP ports, without
bothering to understand them well enough to even use them correctly, let
along cause problematic behavior to the user and potentially to others
using the same facility, is well within the more pejorative sense of the
term "exploit", and may be considered appropriate in that light.

** The figure "clearly hide" seems quite appropriate.  The very fact
that the text was in the documentation indicates that SOMEONE knew in
advance how problematic this behavior could have been.  In point of
fact, even a "private subnet" could have the same problem, as a
developer is not supposed to make assumptions about what other
applications may be using the same TCP/IP facility, even if it could be
assumed that the system will not participate directly in the global
Internet.  Presenting a user with the information considering UDP ports
is certainly correct behavior.  Giving them no facility for avoiding
conflicts, even if they are aware of the problem, speaks of shoddy
products.  The additional lack of mention of what results to expect when
such problems occur...  these constitute reprehensible conduct, as far
as I am concerned.

I think many people would have known before reading such documents that
if no mention of ability to change the ports used was made, the product
should be considered unacceptable for any commercial or professional
implementations, at least.  But leaving it encumbant on the end user to
understand the condition, recognize the information, deal with an
application crash without explanation, and still be unable to in any way
improve the situation besides get the new magic spell based on your
reading of the runes...

If someone knew enough about UDP ports to know that conflicts could
occur, and rather than correct the problem, you merely sought to
mitigate responsibility by listing potential conflicts, without even
explaining what behavior would result if they occur, and certainly
without making any allowances for handling it gracefully, and that such
ungraceful handling is not just common but the default in Windows...

Again, hard-coded ports have been known to happen in Unix.  But nobody
would consider it anything but cluelessness on the obviously newbie
developer's part, even for a second.  No properly written application
should ever hard-code a port number, and no application which does
should be considered either properly written or acceptable to the
consumer.  The idea a hard-coded port is meaningless to begin with; the
exact opposite of the purpose for using port numbers as they are
implemented in TCP/IP.

And you know what?  Its Microsoft's fault, entirely.  They're the ones
that wrote winsock.dll, and they're the ones who completely eradicated
the ability to handle TCP/IP ports sanely, by their design.  Even the
clueless developer who screwed up in this case by hard coding is
relatively blameless, when troubleshooting the encouragement of
cluelessness which actually caused this problem.  I'm not saying Windows
should have implemented Unix's inet.d and services facilities.  They
should have done a lot better than that.  But they didn't even bother to
try.  In no small part, I'm sure, because they didn't want the system to
be open, accessible, and able to be treated as a public facility, as
TCP/IP properly is.

Encouragement of cluelessness.  That's the real problem.  What passes
for troubleshooting and problem correction on Windows isn't anything
more than waving dead chickens and voodoo, pretending to be black magic.

A new entry for the T. Max lexicon, right under "virtual == not":

voodoo == virtual black magic

--
T. Max Devlin
Manager of Research & Educational Services
Managed Services
[A corporation which does not wish to be identified]
[EMAIL PROTECTED]
-[Opinions expressed are my own; everyone else, including
   my employer, has to pay for them, subject to
    applicable licensing agreement]-


====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
=======  Over 80,000 Newsgroups = 16 Different Servers! ======

------------------------------

From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: 
comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: 15 Jul 2000 16:14:49 -0500

In article <a2_b5.8056$[EMAIL PROTECTED]>,
Daniel Johnson <[EMAIL PROTECTED]> wrote:

>[snip]
>> >> Why not?
>> >
>> >Hmmm. If you really think MS is charitable like this, why don't
>> >you support them?
>>
>> The price is not so relevant as the quality.
>
>I see. So why does MS upset you so? Is it *so* bad for MS
>to offer low-quality, cheap goods?

I think what really bothers me is the deceptive representation.
If the advertising mentioned that the products only worked
part of the time, or maybe mentioned the engineering
effort that went into *not* working with competitors products
it would seem more reasonable.

I suppose automobile manufacturers have a right to build
cars that crash for no reason too, but you can't expect
the customers to be happy when that comes as a surprise. 

  Les Mikesell
   [EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: gnu.misc.discuss
Subject: Re: Richard Stallman's Politics (was: Linux is awesome!
Date: 15 Jul 2000 16:20:24 -0500

In article <[EMAIL PROTECTED]>,
T. Max Devlin  <[EMAIL PROTECTED]> wrote:

>>>I would point out that its up to you to provide reason to believe it is
>>>a practical issue.  You have attempted to do so and have found fault
>>>with your reasoning because of your assumptions that one must be free to
>>>profiteer in order to earn profit.
>>
>>I've said no such thing.  I've said you can't give away GPL'd
>>code in many contexts.
>
>Which?

If you have built something that includes a GPL'd component
and anything else under different restrictions, you can't
give it away, even if the other component is itself freely
available or the recipient already has it.

  Les Mikesell
   [EMAIL PROTECTED]

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.advocacy) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Advocacy Digest
******************************

Reply via email to