Linux-Advocacy Digest #267, Volume #27 Fri, 23 Jun 00 00:13:06 EDT
Contents:
Re: Anti-Human Libertarians Oppose Microsoft Antitrust Action (was: Microsoft Ruling
Too Harsh (Donovan Rebbechi)
Re: Processing data is bad! (Leslie Mikesell)
Re: Why We Should Be Nice To Windows Users -was- Neologism of the day ("Rich C")
Re: Microsoft Ruling Too Harsh (Loren Petrich)
Do you people really think that GNU/Linux is a great OS? ("KLH")
Re: Microsoft Ruling Too Harsh (Donovan Rebbechi)
Re: why slashdot.org does not go down? (Jimmy Navarro)
Re: Processing data is bad! (Donovan Rebbechi)
Re: It's all about the microsurfs (Donovan Rebbechi)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Crossposted-To:
alt.fan.rush-limbaugh,misc.legal,talk.politics.misc,alt.politics.libertarian,talk.politics.libertarian,alt.politics.economics,alt.society.liberalism
Subject: Re: Anti-Human Libertarians Oppose Microsoft Antitrust Action (was: Microsoft
Ruling Too Harsh
Date: 23 Jun 2000 03:47:43 GMT
On 23 Jun 2000 03:03:26 GMT, Henry Blaskowski wrote:
>> These are computer *hardware* vendors being coerced, not
>> Microsoft Software stores.
>
>> That's illegal, and with good reason.
>
>What reason? What coercion? Being offered a discount is coercion?
>I'll remember that next time I'm at the grocery store.
This is a straw man. He didn't say that "being offered a discount" is
coercion.
When everyone is offered a discount, it's no longer a discount, it's
something that becomes a must-have if you want to compete. Microsoft's
threat to remove these "discounts" is, because of their power, essentially
a threat to put the company in question out of business ( especially in
more extreme cases where they threatened to refuse to distribute Windows
to the OEM, period )
Clearly, threatening to put an OEM out of business is a restraint of trade.
--
Donovan
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Subject: Re: Processing data is bad!
Date: 22 Jun 2000 22:46:36 -0500
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>>
>> My Type 1 fonts work well enough. Corel Office is merely
>> a Win32 app that's been shoehorned onto Linux. It's hardly
>> a useful comparison.
>
>Yea but it's the only name brand Office suite you guys have to compete
>with MSOffice.
>
>Applix? Most folks have never heard of it.
>
>StarOffice? Bloat to the extreme....
Not much of a problem if you spend the $$$$ you save on RAM or
other hardware upgrades. And 5.2 is just out, promising even
better file compatibility with that other office suite.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: "Rich C" <[EMAIL PROTECTED]>
Subject: Re: Why We Should Be Nice To Windows Users -was- Neologism of the day
Crossposted-To: comp.sys.mac.advocacy,talk.bizarre
Date: Thr, 22 Jun 2000 05:04:11 GMT
"Christopher Smith" <[EMAIL PROTECTED]> wrote in message
news:8irrvl$v5m$[EMAIL PROTECTED]...
>
> "Rich C" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Of course it is. It is still a GUI even in the absence of keyboard
> > shortcuts.
>
> And is just as much a GUI with them, or in the absence of a mouse.
>
It is just as much of a GUI with them, but in the absense of a graphical
input device, it is only half a GUI. And it is only half useful too, as
anyone who's ever tried to operate Windows without a mouse (don't know about
the MAC.)
> [chomp]
>
> > > > It's only HALF a GUI: the output is GUI the input is CLI, because
you
> > have
> > > > to know the shortcuts, or commands, to access the graphical
elements.
> > >
> > > Which is somehow different to knowing you have to move and click the
> mouse
> > > *how*, exactly ?
> >
> > By moving the mouse and clicking buttons it immediately becomes evident
> what
> > the functions do. Trying to empirically discover the keyboard commands
by
> > hitting keys at random, especially in combination, is much more
difficult.
> > In this instance, help or knowledge is required.
>
> But you don't need to. Keyboard commands are highlighted within the GUI
by
> underlined letters on controls and keyboard shortcuts listed in menues.
So where is it highlighted that you need the ALT key to open a menu? Where
is it highlighted that ALT-SPACE opens the control menu? Where is it
highlighted that backspace moves you up to the parent folder?
>
> No more knowledge is needed than that which was needed to figure out hwo
to
> use a mouse in the first place.
So I can sit you down in front of a strange GUI, and, because you know how
to use the mouse, you can figure out EVERY embedded keyboard command without
using help?
I'd love to see that.
>
> > > What's the big different between the input device with 2 buttons, and
> the
> > > one with 102 ?
> >
> > one works with graphical feedback; the other does not. Clicking the
mouse
> > to obtain the proper result depends on WHERE the mouse pointer is
located
> on
> > the screen.
>
> And hitting the keys require hitting the right ones, the difference ?
OK, let's try this a different way. In a given program, an embedded command
will work, *regardless* of where you are in your document, drawing, or
whatever; regardless of where you are in the program. With a mouse, which is
a GUI input device, you NEED the graphical feedback of the mouse pointer to
use it. I don't know how many times I've been able to shut down Windows
_from the keyboard_ when I couldn't even SEE the desktop because of a video
problem. Using the mouse in this case was impossible. The mouse requires
visual feedback to operate. The embedded CLI doesn't. The mouse is a GUI
device. The keyboard is a command device. Understand?
>
> You have to know where to click and you have to know what buttons to
press.
>
> > > > So how would you "tell" the machine where to focus?
> > >
> > > Well in the case of a dialog it would probably be focussed
> automatically.
> > > To switch focus you'd probably say something like the title of the
> window.
> > > I can't say I've put much thought into it - current technology is
*way*
> > too
> > > immature to develop a usable voice control system.
> >
> > If you did, you'd realize that voice control is more conducive to
> generating
> > commands than visual cues, and that something like a retinal scanner
would
> > be a more appropriate input device for a GUI.
>
> All interfaces use commands. With a voice controlled GUI you'd need a
> system with enough programming smarts to be able to determine the context
of
> the command.
That's true. The reason there are no good scripting languages for GUIs is
that it is impossible to translate mouse movements reliably into a command
string. The scripting languages that exist work better when you use embedded
commands rather than mouse input.
>
> > > You certainly wouldn't be doing something like maneuvering a mouse
> cursor
> > > around with voice commands, that's just plain dumb - it'd be like
using
> a
> > > mouse to pick out letters to enter commands into a CLI.
> >
> > My point exactly. :o)
>
> But that's not how you'd use voice control in a GUI - *my* point exactly.
Right. You'd give the computer direct command input--not GUI input.
>
> > > > To me, it is more
> > > > natural to command the machine via voice commands, "Open file FOO in
> > > folder
> > > > BAR." or "Email file FOO to John Doe."
> > >
> > > There's no reason why you couldn't do that with a GUI.
> >
> > But _how_ exactly?
>
> By giving the commands. The *computer* is smart enough to figure out what
> the file FOO is, who John Doe is and what the email program is.
So where did the GUI come into play in all that? You simply gave the
computer commands.
>
> > Once you actually begin to think about it, it becomes
> > unwieldy to manipulate a graphical interface with voice commands.
>
> Only if you make it that way.
Once you eliminate the awkwardness of manipulating the interface
graphically, you've bypassed the GUI and translated voice commands into
embedded CLI commands.
>
> > > > While reading text may indeed be visual, speaking to a computer is
> not.
> > > > Words translate more readily into commands than they do to the "n"th
> > item
> > > in
> > > > a list or a button in a specific place on the screen.
> > >
> > > That would be a really poor way to implement voice control. There's
no
> > > reason to do it like that even with the limits of today's technology.
> >
> > So you might say, "Menu....File.....open......documents
> > folder.....proposals....foo.doc"?
> >
> > Or would you say "Open folder documents, subfolder proposals, file
> FOO.doc"?
> >
> > Which one is more like a command?
>
> They're *all* like commands, that's my point.
>
> > > > Actually, all digital logic consists of a zero state (off) a one
state
> > > (on)
> > > > and the gray area in between where the output is unpredictable.
> > >
> > > That output isn't unpredictable, it's ignored. Ergo the end product
is
> > one
> > > of two things - a 1 or 0.
> >
> > No, it's not ignored. If you have a gate output that can be either a
high
> or
> > a low, and your input is in the gray area, the output MUST by definition
> be
> > a high or a low. Dependent on variables such as ambient temperature,
> supply
> > voltage fluctuations, and manufacturing tolerances in the chip, a given
> > input level in the gray area can cause a high level output or a low
level
> > output, and it is impossible to predict which it will be. Thus the
output
> is
> > unpredictable.
>
> No, it's perfectly predictable - it'll be either a 1 or a 0, nothing else.
> It won't be 0.5, it won't be 1.2.
"Either a 1 or a 0"? ROFL!!! That's some prediction, Mr. Cacey! The point is
not to predict that it will be one of it's allowed states; the point is to
predict WHICH state. If you can't predict WHICH state the output will be
with an out-of-tolerance input, the output is unpredictable. An analogy to
your logic is my saying, "I can predict with absolute certainty that if you
flip a coin it will land either heads or tails."
>
> > > > IMHO, the CLI would be easier to implement and easier to use.
> > >
> > > Easier to implement, certainly.
> > > Easier to use, entirely dependent on implementation.
> >
> > Aren't products that are simple implementations inherently simpler to
use?
>
> No. Compare edlin to something like EDIT.
I found edlin to be a snap.
>
> > > Easier to *learn*, highly doubtful.
> >
> > I think an implementation that is a straightforward translation of one
> > concept into a similar one is easier to learn than one that is
translated
> > from one class of mental activity (aural processing) to another one
> > (visualization.)
>
> But it wouldn't be done like that. You'd be issuing the same commands to
> the GUI, just through a different medium.
Yes, you'd be issuing _commands_. Since you don't seem to understand the
difference between GUI input, where visual feedback of a pointer is integral
to using the device for input, and command input which is independent of
visual feedback--the commands work the same regardless of the cursor
position on the screen, I can't explain the difference to you.
>
> > > Be careful about the distinction between easy to learn and easy to
use,
> > they
> > > are very different things.
> >
> > I think I understand the difference. ;o)
>
> I'm unsure you do.
A GUI is easy to learn, but a CLI is easy to use. Satisfied?
>
> > > Oh I doubt that. That might have been true 5 years ago, but modern
> > machines
> > > are quite fast enough to display GUIs.
> >
> > Yes, but manipulating a graphic display DOES take more processor
overhead,
> > even with a dedicated hardware video processor. So "faster" may not be
> > perceptible to the operator, but there would be more processing time to
do
> > other things.
>
> In an interface, perceptible to the operator is all that really matters.
>
> If someone's reaction time is only 0.15s, what does it matter if the
> operation completes in 0.5s or 0.7s ? They're not going to know the
> difference.
When there is processor-intensive activity going on, the high-overhead GUI
will suffer more than the low-overhead CLI in terms of perceived
sluggishness.
>
> Yes, in the former example the CPU might have a few million cycles spare,
> but what is it going to do with them except twiddle its thumbs ?
>
> > > > No, it's a graphical presentation. How would you "interface" to it?
> > >
> > > Any way you want. DOesn't change the fact it's graphical.
> >
> > But it's only half of the interface.
>
> It's the only half that concerns us. "Graphical" is only referring to the
> presentation.
Wrong. Graphical input refers to the process of using visual feedback to
place the pointer in the proper place to effect the desired input. With
graphical input you CAN'T provide input to the computer without the visual
feedback of the cursor position, whereas with COMMAND input, the cursor
position doesn't matter. I can shut down Windows via the keyboard without
having a working display. With the mouse this is impossible.
>
> > If I defined commands to manipulate the
> > display, I could do so with no visual feedback. i could type "rotate 90"
> or
> > "zoom 200" and predict what the result would be. But If I used mouse
> > commands, I would have to have visual feedback, i.e., know the position
of
> > the pointer, before I could select the zoom command or the rotate
command.
> > Thus the mouse is a graphical input device, while the keyboard is a
> command
> > input device.
>
> They're *both* command input devices.
...that work completely differently. GUI input relies on visual cues.
Keyboard input does not.
>
> Using the mouse to, for example, rotate an image by dragging it is no
> different to using the keyboard arrows to rotate it.
Then do it without looking at the screen. Then go back and see how
successful you were.
>
> > > > Not if you're waiting for the next level of dialog box to appear
> (which
> > > > happens frequently to users with slow systems.)
> > >
> > > No, I don't have to wait - that's my point. The system is fast enough
> to
> > > display whatever the next thing is before I can decide what to do with
> it.
> >
> > Of course. You couldn't possibly decide what to do until you SEE your
> > choices. It's sequential processing, unlike the command line, where you
> give
> > the computer ALL your input at once.
>
> Most all interactive use is sequential processing, so that's really fairly
> irrelevant.
Not at all. (
>
> > > There's nothing I can think of that I do on my system I can't do that
> with
> > > in a GUI. Since 99% of all my use is interactive, the dialogs you
refer
> > to
> > > are essential to actually using the thing.
> > >
> > > Indeed, there's no inherent reason a GUI would exhibit the behaviour
you
> > > have described.
> >
> > Oh, so you've never gotten up from your computer after starting a
lengthy
> > operation, only to come back 5 minutes later and find the computer had
not
> > started the task yet because you neglected to answer a confirmation
> dialog?
>
> Only when that confirmation dialog was relaying important information, eg
> overwriting an existing file.
The importance of the dialog is irrelevant. What IS relevant is that the
lengthy task wasn't started because you got up from the computer too soon.
>
> > Happens to me in Windows ALL the time.
> >
> > >
> > > > > Sure, you can plonk NT4+IE4 on a 486/16 with 12MB of RAM and it'll
> > just
> > > > > about run backwards, but that's not inherently the *GUI's* fault.
> > > >
> > > > In a way, it is, because the GUI is taking resources that are not
> > > abundant,
> > > > thus adding to the lethargy.
> > >
> > > That doesn't hold. By that logic a CLI is bad because it's slow on an
> XT.
> >
> > It would be if there were something faster to run on the XT, but there
> > isn't.
>
> Sure there is. A purpose written program to do whatever it is you want to
> do.
What??? How does such a program replace the OS and the command line
interface? How do you run the program? How do you run OTHER programs?
>
> > The interface should interfere with the execution of the task as
> > little as possible. This is where Microsoft (and Apple to a lesser
extent)
> > fall on their faces: The OS is NOT the end, it is only the means.
>
> The interface doesn't interfere with the task, it provides feedback.
If it's taking up unnecessary resources that the task might need while
providing that feedback, it most certainly IS interfering.
>
> > > > That's why Linux with a CLI runs so well on
> > > > said 486/16 with 12 meg of RAM.
> > >
> > > Well, it runs. I wouldn't call it "well" if you're actually _using_
the
> > > thing.
> >
> > The response time of the interface is negligible in human terms, so I
> would
> > call it running "well." (And I _have_ said 486 running said Linux, so I
> > speak from experience.)
>
> I have one too, and there's not much you'd be doing on it interactively
that
> I could describe as "runs well".
Well, mine serves my web pages, prints my print jobs, and it still runs the
interface just fine.
>
> [chomp]
>
> > > > Now, if
> > > > the menu interface were a *touch screen,* I would agree that that
was
> a
> > > GUI.
> > >
> > > Personally I can't see how it would make a difference. A touch screen
> is
> > > just like having a mouse, without the mouse.
> >
> > Exactly. Successful use of the interface depends on visual cues, i.e.,
> your
> > finger's position relative to the "buttons" you want to press. This is
> just
> > like the mouse, where clicking the button successfully depends on the
> visual
> > cue of whether the pointer is over the button you want.
> >
> > >
> > > How about a touch screen with a keyboard on, say, the bottom half of
it
> ?
> > > Where does that fit in ?
> >
> > It's a GUI, because the "keys" are dependent on graphical display
output.
> If
> > the display moved or the key orientation changed, as a result of program
> > output, your actions relative to those keys would change. What you do in
a
> > GUI is totally dependent on visual feedback.
>
> This is different to a keyboard on your desk _how_, exactly ?
One depends on visual feedback; the other doesn't.
>
> What about two screens, one for display and one for the keyboard ?
Makes no difference.
>
> > > > Not necessarily. There are CLIs where you can simply type "copy" and
> hit
> > > > Enter and the interface will come back with "From:" at which point
you
> > > type
> > > > "foo.txt" and hit Enter and the interface comes back with "To:" Type
> > your
> > > > destination and hit Enter. You don't always have to know the entire
> > > command
> > > > syntax up front to use the interface.
> > >
> > > But you still have to know eg. what the files are.
> >
> > So you do with a GUI. To find a file, you have to know which folder to
> > click. To copy a file, you have to know the file name, or at least a
part
> of
> > it, to select it.
>
> But the files are already there, you just have to pick them. That's
> different from having to know what they are _first_.
>
> > > > The CLI we developed for the security guards (mentioned in a
parallel
> > > thread
> > > > I think) allowed initiation of a conversation by simply typing the
> > command
> > > > string (3 letters) and the system would prompt the user with lists
of
> > > > options for each parameter. Alternately, the entire string could be
> > typed
> > > on
> > > > one line, if the user knew what the options (s)he wanted.
> > >
> > > This is where you move into the fuzzy area. In one way it's a CLI and
> in
> > > another, a GUI.
> >
> > It's not fuzzy if you have 20/20 eyesight ;o) There is no visual
feedback
> in
> > terms of highlights of the default choice; you can't visually pick your
> > options; you have to type the command fragment (from the displayed
list.)
> It
> > is a prompted CLI, NOT a GUI.
>
> You are picking your options. _How_ you pick them is not relevant.
Oh yes it is. If you're using visual cues from the graphical display, you
are using GUI input. If you are typing static commands that are immune to
the state of the display, you are using command input. That's the whole
point. There IS a difference. One is visual, and one is not.
>
> > I think you would call any interface that is intuitive and easy to use a
> > GUI, and any interface that is obscure and unhelpful a CLI. This is
> > prejudicial in my view.
>
> No, I wouldn't. I'd hardly vi intuitive and helpful, but it's a lot more
of
> a GUI than edlin is.
>
> I think you'd call any more efficient method of using a GUI except the
mouse
> a CLI, because you have some inherent need to believe that a CLI is more
> efficient than a GUI. That, to me, is very prejudiced.
No, I don't _need_ to believe a CLI is more efficient. If the windows
keyboard shortcuts were 27 letters each and required three hands to execute,
I would still call them a CLI. I'd also call them stupid and ill-conceived,
but I would still call them a CLI.
>
> However, I don't really see how amateur psychology is relevant.
Of course it's relevant. The key to winning any argument is convincing the
other party he doesn't know what he's talking about.
>
>
-- Rich C.
"Great minds discuss ideas.
Average minds discuss events.
Small minds discuss people."
>
------------------------------
From: [EMAIL PROTECTED] (Loren Petrich)
Crossposted-To:
alt.fan.rush-limbaugh,misc.legal,talk.politics.misc,alt.politics.libertarian,talk.politics.libertarian,alt.politics.economics
Subject: Re: Microsoft Ruling Too Harsh
Date: 23 Jun 2000 03:54:10 GMT
In article <8iujv3$2t4u$[EMAIL PROTECTED]>,
Henry Blaskowski <[EMAIL PROTECTED]> wrote:
>I lean in this same direction, for a very simple reason. When in
>doubt, leave people alone. That means, if two people or groups can
>come to a voluntary, informed consent, it should take an overwhelming
>burden of proof to overturn that, such as clear evidence of direct
>harm. This is rarely if ever shown in anti-trust cases, and certainly
>not in the MS case. Consumers have had many choices all along, even
>in and industry that basically was built, in large part, on the labor
>of the programmers at Microsoft. Yes, they are the leaders, but you
>would expect that because they took many of the early risks. But
>alternatives are readily available, and nobody has shown any use
>of force or fraud.
Although it's certainly true that many of M$'s operating-system
competitors have shot themselves in their (metaphorical) feet, it is also
true that M$ has used underhanded techniques, such as promising products
that they may or may not be willing to ultimately deliver. And also of
not presenting the true nature of the deals it has made with PC makers,
publicly and honestly.
And would using intellectual-property law and contract law to
one's advantage be considered "force"?
--
Loren Petrich Happiness is a fast Macintosh
[EMAIL PROTECTED] And a fast train
My home page: http://www.petrich.com/home.html
------------------------------
From: "KLH" <[EMAIL PROTECTED]>
Subject: Do you people really think that GNU/Linux is a great OS?
Date: Thu, 22 Jun 2000 20:52:05 -0700
Okay, the subject line definitely sounded like flamebait, but its not.
I don't consider GNU/Linux a great OS, just marginally better that
everything else I have used, at least for my needs.
A true advocate would have to admit:
* that the Unix model doesn't extend well into the graphical user
interface
* that having two competing desktop enviroments will be causing
inconveniance to users for years.
* that perhaps we need to get rid of these middle-level C-like languages
that make it easier for even great programmers to introduce memory leaks and
core dumps into large applications that we depend on.
* that there are so many ways in which GNU/Linux can be improved that it
would be useful to start over from scratch and design a new OS light years
ahead of what we have now.
Either a true advocate will admit this or they know something I don't, which
almost certain; so don't badger me about saying it this way.
And for those of you who curiously read "Nt is better" between the lines of
any "GNU/Linux isn't God" posts, please note that: THIS HAS NOTHING TO DO
WITH NT. Sorry for shouting.
But if you look again at my last point you will see what I am suggesting. A
new Operating System that takes what we have learned in watching this OS
grow and uses that experience in creating a great OS.
I guess as a disclaimer I am not much of a programmer (yet) so see this as a
theoretical discussion. It is the kind of discussion that interests me
greatly. I personally want an OS that will cater to all my needs. It would
need to have all the necessary primitives ready to be scripted by something
clean like scheme or python. It would need to have seamless networking and
needs to be written in a language that increases productivity and never
crashes. It will need be based on a GUI that is lightyears ahead of what we
have now...something that provides functionality that both Mac Users and
hard core command-lines users will find as useful as on their usual systems.
It would have to be *that* configurable. But most importantly, it will need
to have a focus and a design that makes the whole OS seem seamless,
extremely powerful, and easy to use for the neophyte by default.
I guess I am asking, do you really think GNU/Linux is a great OS or do you
think there is enough room for improvement for work on a new, largely
incompatible, OS be worthwhile? And if you are in the opinion of the latter,
how would you build such an OS? What programming language would you prefer
it be built on? What other technologies would you want it to use?
Thanks for your time,
Kevin Holmes
"extrasolar"
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Crossposted-To:
misc.legal,talk.politics.misc,alt.politics.libertarian,talk.politics.libertarian
Subject: Re: Microsoft Ruling Too Harsh
Date: 23 Jun 2000 03:56:00 GMT
On 23 Jun 2000 03:01:55 GMT, Henry Blaskowski wrote:
>I lean in this same direction, for a very simple reason. When in
>doubt, leave people alone. That means, if two people or groups can
>come to a voluntary, informed consent, it should take an overwhelming
>burden of proof to overturn that, such as clear evidence of direct
>harm. This is rarely if ever shown in anti-trust cases, and certainly
>not in the MS case.
I disagree. I think that in a lot of cases, what you have is not
"voluntary, informed consent". I think Microsoft have thrown their
wieghht around and used coercion, and I believe the evidence presented
in the trial makes this pretty clear.
>would expect that because they took many of the early risks. But
>alternatives are readily available, and nobody has shown any use
>of force or fraud.
Does coercion count as fraud ?
>the burden of proof should weigh heavily on those who wish to interfere
>with voluntary peaceful consensual agreements, because otherwise, there
>really is nothing off limits.
IMO a lot of the evidence presented in the trial points to several
agreements that are certainly not deserving of the term "peaceful".
>All true monopolies are government sponsored/enforced. The free
>market dominance that is often called a monopoly just means the
>competitors are having trouble understanding the market. But they
No, it doesn't. Take a look at what the definition of a monopoly is
some time. You are wrong, both in the sense of the dictionary definition
and legal definition of "monopoly".
>20% is 1 in five. That is a lot of competitors. It is not a monopoly.
Whether or not something is a monopoly is not determined by the number
of competitors, so in this instance you and the person you are replying to
are both wrong.
--
Donovan
------------------------------
From: Jimmy Navarro <[EMAIL PROTECTED]>
Subject: Re: why slashdot.org does not go down?
Date: Thu, 22 Jun 2000 20:45:16 -0700
May be the question should be, why slashdot.org does not go down?
Because they are not using M$ Windoze NT and IIS.
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Subject: Re: Processing data is bad!
Date: 23 Jun 2000 04:00:53 GMT
On Fri, 23 Jun 2000 02:12:30 GMT, [EMAIL PROTECTED] wrote:
>On Fri, 23 Jun 2000 01:19:01 GMT, [EMAIL PROTECTED] () wrote:
>Yea but it's the only name brand Office suite you guys have to compete
>with MSOffice.
>
>Applix? Most folks have never heard of it.
Most Linux folks have. Most would-be Linux users will hear about it
when they ask what office suites are available. I'm not sure what the
problem is.
--
Donovan
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Subject: Re: It's all about the microsurfs
Date: 23 Jun 2000 04:04:34 GMT
On Fri, 23 Jun 2000 02:09:43 GMT, [EMAIL PROTECTED] wrote:
>Most folks don't. They see HP or Compaq and go for the biggest
>monitor/hard drive and fastest CPU for the buck.
THe people who'd even consider buying an "alternative operating system"
tend also to make fairly informed choices about their computer hardware.
If they're as naive as you seem to believe, they will no doubt end up
with a POS (-;
--
Donovan
------------------------------
** 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
******************************
