Linux-Advocacy Digest #155, Volume #27           Sun, 18 Jun 00 01:13:05 EDT

Contents:
  Re: Why We Should Be Nice To Windows Users -was- Neologism of the day ("Rich C")
  Re: An Example of how not to benchmark ("Colin R. Day")
  Re: Dealing with filesystem volumes (Lawrence DčOliveiro)
  Re: What UNIX is good for. ("Colin R. Day")
  Re: Dealing with filesystem volumes (Lawrence DčOliveiro)
  Re: Dealing with filesystem volumes (Lawrence DčOliveiro)
  Re: Dealing with filesystem volumes (Lawrence DčOliveiro)
  Re: Claims of Windows supporting old applications are reflecting reality  ("Colin R. 
Day")
  Re: The Tholenbot  is becoming a Mutlu! (was: Microsoft invites Canada south) 
(tholenbot)
  Re: Claims of Windows supporting old applications are reflecting reality  ("Colin R. 
Day")
  Re: Processing data is bad! ("Colin R. Day")
  Re: Linux is awesome! ("Colin R. Day")
  Re: Why X is better than Terminal Server ("Colin R. Day")

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

From: "Rich C" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,talk.bizarre
Subject: Re: Why We Should Be Nice To Windows Users -was- Neologism of the day
Date: Sun, 18 Jun 2000 00:05:08 -0400

"Christopher Smith" <[EMAIL PROTECTED]> wrote in message
news:8ihaic$up3$[EMAIL PROTECTED]...
>
> "Rich C" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > So then the old Red Hat installation program where you had to tab tab
tab
> to
> > the "OK" box and then press Enter is a GUI? or for that matter the old
DOS
> > text editor is a GUI? (It had "buttons" of sorts.) The information was
> > "presented" in a graphical form, but you had to use keyboard commands to
> > make a selection. Are you saying that all these old DOS and text mode
> Linux
> > programs are GUIs???
>
> *I* would say that, yes.
>
> Once you get into text mode stuff though, it can get quite fuzzy.  If, for
> example, you had a scale of 1 - 5 to measure from "CLIness" to "GUIness",
> I'd say (for something like text editors):
>
> sed (or, say, edlin) = 1
> vi = 2
> emacs (or, say, wordperfect) = 3
> DOS EDIT = 4
> Word (for Windows) = 5
>
> Like anything to do with computers and definitions, what something is
> *defined* as is vastly different to what that same thing is commonly
> *accepted* as.  You can't just classify something CLI or GUI, because what
a
> CLI is and what a GUI is very vague.

Not to mention the fact that they can be combined into one interface, with
elements of both types present, as with Windows and its keyboard shortcuts.
It's only vague because you refuse to take it apart and identify each
component as belonging to one class or the other. Instead you are calling a
"primarily" graphical interface a GUI and everything that goes along with
it. That's like (to use a dreaded automotive analogy) calling a trailer part
of the car just because it's hitched up.

>
> > > A Graphical User Interface is just that - it has absolutely zero to do
> > with
> > > how you then manipulate said interface.
> >
> > I don't believe this is true. I think "GUI" defines the interface, which
> > consists of output AND input.
>
> However, restricting "GUI" input to mouse only is silly.
>
> Is a Windows system running without a mouse somehow *not* a GUI ?

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.

>
> > > For example, where is voice control going to fit in ?  CLI or GUI ?
> >
> > I would hate to tell my computer to "Click that OK button over
> there....no,
> > not that one, up a little....no not that one either.....THERE! That's
the
> > one......CLICK IT!!!"
>
> Well, you wouldn't, you'd say "OK" and the machine would (hopefully)
> automatically do it to the button that was in the window in focus.

So how would you "tell" the machine where to focus? 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."

>
> > I think voice control will define a whole new interface, but, since
voice
> > "commands" translate into words more readily than into images (if a
> picture
> > is worth a thousand words, it will take a thousand words to define it) i
> > think it will be more consistent with a CLI.
>
> Not really, because a CLI is more typified by having to know what the
> commands and manipulations are before you actually perform them (eg you
have
> to know what "ls" is and what it does, to see a file list), whereas a GUI
is
> typified by having the "options" presented, and you pick one (eg, click on
a
> folder and you see what's in it).

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.

>
> Of course, real life usage falls in between those two extremes.  Nothing
is
> ever black and white when it comes to computers (somewhat ironic, when you
> consider they're basically just a big collection of on/off switches :).

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.

>
> Voice control could manipulate a GUI *or* a CLI just as easily.

IMHO, the CLI would be easier to implement and easier to use.

>
> > > Again, how a user manipulates an interface is entirely separate as to
> > > whether that interface is graphical, command line or whatever.
> > >
> >
> > I don't buy this argument. As I've said above, the interface consists of
> > INPUT as well as output. For example, there were menus long before there
> > were GUIs. The menu driven interface is NOT a GUI (or maybe by your
> > definition it is.) The only thing the GUI added to menus was the ability
> to
> > point to a menu item and click it as opposed to scrolling up and down
the
> > menu list and hitting Enter.
>
> The other big thing a "traditional" GUI added was more screen estate and
> layered windows.

If there were no GUIs, do you think we'd still be operating text mode
displays at 80x25 or 80x50? There would surely be room for multiple windows
side by side, or tabbed such that one could be brought from the back to the
front with ease. This had actually already started with DOS before Windows
took over.

>
> Of course, there's no reason you couldn't do that in text mode.  It'd
really
> be a step backwards, though.

"Backwards" is dependent on which way you're facing. It would certainly be
faster.

>
> > > You are equating a command line with the keyboard.  It just ain't so.
> >
> > You are saying a graphical presentation is a GUI, when THAT just ain't
so.
>
> Well, it is a *Graphical* User Interface.

No, it's a graphical presentation. How would you "interface" to it?

[snip]

>
> My point was I've never had to wait for the machine to complete one task
> before I perform the next.  The bottleneck in the system is quite clearly
> *me* and my reaction speed.

Not if you're waiting for the next level of dialog box to appear (which
happens frequently to users with slow systems.) What's worse, if you're
doing things by GUI on a slow system, you've got to stick around and pay
attention to what the system is doing, because you've got to continuously
click dialog boxes as they come up. With a CLI, once you do the
"preprocessing" you mentioned elsewhere, you can get up and get coffee and
let the computer do it's thing (or, in my case, move to another system and
start something else.)

>
> 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's why Linux with a CLI runs so well on
said 486/16 with 12 meg of RAM.

>
> > > I would call it that, yes.  A CLI is a command *line* interface that
> > relies
> > > on you knowing the commands, how they operate and what the results
will
> > be.
> > > CLIs are almost always typified by very little user feedback
(relatively
> > > speaking), and less information being presented at any given time.
> >
> > So in your definition, a Menu-driven interface is a GUI, right?
>
> Pretty much.  Although, again, it's still shades of grey.  A menu that is
> always there (eg, DOS EDIT) is "more" of a GUI than one which you have to
> specifically activate to use (eg Emacs, Wordperfect).

I'll buy that the *PRESENTATION* is graphical, because the user *sees* what
the selected command or item is, but the input is command-oriented. Now, if
the menu interface were a *touch screen,* I would agree that that was a GUI.

[snip]

> No, you're misunderstanding.  With a CLI you have to know what you want to
> do *and how to do it* before you can do it.  Eg you have to know that you
> want a directory listing and you have to know the command "ls" before you
> can get a directory listing.

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.

>
> Yes, with a keyboard shortcut you need to know what it is, but that
doesn't
> change the fundamental difference in that the GUI presents you with the
> things it can do and you do them and with a CLI you don't have the
"options"
> presented.

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.

>
> For want of a better description, GUIs are passive interfaces and CLIs are
> active interfaces (from the point of the user, from the point of the
system
> it's reversed).
>
> > > However, I doubt your average MacAdvocate would agree with that :).
> >
> > I'm not a MacAdvocate and I don't agree with it either. IMHO, a
text-based
> > menu-driven interface is NOT a GUI. Perhaps it needs its own class
> > definition, but to me, it is more a CLI than a GUI.
>
> Well, I'd call it more of a GUI than a CLI.
>
> Text based interfaces fit in between the extreme of a CLI and a GUI.
>
> > > > What about the old WordPerfect 5.1 which had a mouse and
> > > > menu interface? Was that a GUI?
> > >
> > > Like most things in computing, it's all fuzzy shades of grey.  Parts
of
> WP
> > I
> > > would call a CLI, but the menues a GUI.
> >
> > The fuzziness seems to be where we disagree: what category do menus fit
> > into?
>
> Depends on how they are implemented.
>
> > > > I guess I am saying YES, GUI == mouse and CLI == keyboard.
> > >
> > > Well I must say that I think that's a silly definition to use :).
Like
> I
> > > said before, where would a voice control system fit into this ?
> >
> > Not at all. Like I said, a user interface includes both INPUT and
output.
> As
> > for voice control, see my response above.
> >
> > >
> > > How about keyboard alternatives ?
> >
> > Keyboard alternatives to what?
>
> As in alternative types of keyboards.  Like those funny "chord" things
that
> are like two controls, one for each hand with 5 buttons on each and you
> press them in certain combinations to get letters, numbers, punctuation
etc.
>

Don't know. I'd have to think about that. I guess if you're forming commands
with the keyboard, it's a CLI interface (keyboard); if you're using it to
choose an area of a graphical display, or select an item based on its
position on the screen, it's just another mouse.
>


-- Rich C.
"Great minds discuss ideas.
Average minds discuss events.
Small minds discuss people."




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

From: "Colin R. Day" <[EMAIL PROTECTED]>
Subject: Re: An Example of how not to benchmark
Date: Sun, 18 Jun 2000 00:02:37 -0400

Pete Goodwin wrote:

> [EMAIL PROTECTED] wrote in <8iets4$1f5$[EMAIL PROTECTED]>:
>
> >BTW, you probably could have saved yourself the recompile --- see the
> >README file in the download directory:
> >
> >   The file pve-vc6.zip contains a Visual C++ v6 compile of
> >   PVENGINE.EXE. Under most circumstances, this compile is noticably
> >   faster than the Watcom compile provided in the standard distribution,
> >   as the expense of slight less stability.
> >
> >I don't think I'd like my ray tracer to have stability problems. Do you?
>
> Except that's not what I built. I built the UNIX version with VC++ V6.0 and
> modified the config.h to suit. The version they are talking may have
> stability problems but mine is a much smaller build.

VC++ will compile to UNIX?

Colin Day


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

From: Lawrence DčOliveiro <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Dealing with filesystem volumes
Date: Sun, 18 Jun 2000 16:16:51 +1200

In article <8htk0a$8td$[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] (Dave Vandervies) wrote:

>One difference is that (if I'm interpreting the description correctly)
>it assumes that if a volume is mounted as `My Files' on one system, it
>will be mounted as `My Files' on _any_ other system it happens to be
>moved to; I can mount a filesystem as `/usr/local' on one computer and
>as '/mnt/goofy/usr/local' on another using the Unix model.  Being able
>to do this has made life a lot easier on more than one occasion.

The only advantages of this would seem to be a direct result of 
limitations of UNIX itself--for example, the special meaning of 
pathnames like "/usr/local". There are no such "reserved" pathnames on 
MacOS (not even the names of the System Folder or the System or Finder 
files are hard-coded anywhere).

Thus it is quite clear that this "feature" of referring to an object on 
a removable filesystem by different names on different systems is in 
fact a drawback, since it doesn't allow you to store stable object 
references on that volume, or indeed on any other.

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

From: "Colin R. Day" <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.advocacy
Subject: Re: What UNIX is good for.
Date: Sun, 18 Jun 2000 00:18:06 -0400

Tim Palmer wrote:


> >
> >>or even a good LOGO interporator.
> >
> >Oh yeah, I want Win2K just to allow kids to program in LOGO!
> >
> >Brilliant!
> >
> >(IMO, one would be better off buying a used Amiga for that sort
> >of thing, or perhaps an old Mac II.
>
> But not UNIX beacause LOGO is far too advanced for UNIX!
>

Logo is available for Linux. I have ucblogo-4.6-2. Now, MicroWorlds
might be a problem.


> >Oh gosh.  You're *really* reaching if you have to go that far back!
> >UUCP died out 5 years ago, if I'm not mistaken; Unix boxes have
> >understood how to find the Internet host for a particular email
> >address for at least that long.
>
> 5 years ago.. Did this have anything to do with the rellease of Windows 95? Wasn't 
>enough to
> get rid of VI, though.
>

I would suspect not. As for getting rid of vi, isn't that why we have emacs :-)?

>
> >
> >>and look at this it's real kewl! If you want to chat, with the other
> >>users you can type "write",
> >
> >Or 'irc'.  (Hey, Unix users can read RFC1459 too. :-) )
>
> Same thing. Ugly-ass VT100 crap. Try MIRC. UNIX doesn't even come close.
>
> >
> >>but you'll always be the only user logged in anyway. Oh, and the CD drive,
> >>sound card, scanner, printer, modem, graffics card, and floppy
> >>drive arent' working annymore
> >
> >They aren't?
> >
> >Lessee.
> >
> >cdrom: /dev/cdrom
> >Floppy: /dev/fd0, /dev/fd1, /dev/fd[01][DH]*
> >Sound card: various, typically /dev/audio, /dev/sequencer, /dev/dsp,
> >/dev/midi*, and /dev/mixer.
> >Printer: /dev/lp*
> >Modem: /dev/modem (symbolic link) or /dev/ttyS* (unless it's a WinModem,
> >   which sucks anyway)
>
> So you went out and found the obscure hardware that Linux does support.  Good for 
>you. The rest
> of us want an OS that supports the hardware we alreaddy have. Linux doesn't even 
>come cloase
> in hardwair support. Windows beats _any_ UNIX hands down.
>

Almost any external modem is supported. In fact, all I had to do for mine
was plug it in and use modemtool to set the symlink for /dev/modem.

Colin Day


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

From: Lawrence DčOliveiro <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Dealing with filesystem volumes
Date: Sun, 18 Jun 2000 16:19:45 +1200

In article <8htlbb$5q3$[EMAIL PROTECTED]>, James Lee 
<[EMAIL PROTECTED]> wrote:

>In comp.os.ms-windows.advocacy Lawrence D1Oliveiro 
><[EMAIL PROTECTED]> wrote:
>
>> b) Mount points (all UNIXes and Linsux).
>> Pros: Pretends to make all your volumes look like a single filesystem.
>> Cons: Only *pretends* to make all your volumes look like a single 
>> filesystem (all kinds of within-file-system-only things don't work, like 
>> hard links). Notoriously error-prone: Copy files to a mount point 
>> directory when the volume isn't actually mounted, then mount it, 
>> and--where did those files go? Not only are they on the wrong volume, 
>> but you can't even access them until you dismount the second volume 
>> again!
>> Verdict: Incompletely thought-out idea. How come the Linux folks are so 
>> focused on being so faithful to UNIX, when they could be *fixing* some 
>> of those long-standing, well-known UNIX problems?
>
>Haven't you heard of automount and autofs?
>It automatically mounts it when accessed
>and unmount it when not in used for some time.

Instead of solving the problem, all that does is spread it across two 
machines--you have exactly the same problem of non-stable filesystem 
object references on the server machine as you did previously on the 
client machine.

This is why MacOS-style volume-based filesystem references are better.

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

From: Lawrence DčOliveiro <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Dealing with filesystem volumes
Date: Sun, 18 Jun 2000 16:23:36 +1200

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

>Linux is aimed at POSIX-compliance and the old standard filesystem.

Who uses POSIX any more?

>We certainly wouldn't like it if critical utilities like Sendmail,
>XFree86, and such suddenly would stop working.

Why not fix those programs to work with a more modern filesystem? I 
know--because they would then break on UNIXes still using the old 
filesystem. So what you're saying is you're stuck in a vicious circle, 
where you can't fix the OS because the apps will break, and you can't 
fix the apps because the OS will break?

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

From: Lawrence DčOliveiro <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Dealing with filesystem volumes
Date: Sun, 18 Jun 2000 16:30:32 +1200

In article <[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] (Darren Winsper) wrote:

>On Tue, 13 Jun 2000 22:10:20 +1200, Lawrence D1Oliveiro
><[EMAIL PROTECTED]> wrote:
>
>> Under UNIX, the mount point is part of the file path, remember. Consider 
>> a CD-ROM called "My Photos", with a file on it called "Fred the Cat". On 
>> a UNIX system, you might or might not be able to use the pathname 
>> "/cdrom/Fred the Cat". And what if you have both a CD-ROM and a 
>> CD-writer drive attached (as I do), and you put the CD in the latter? 
>
>/mnt/cdrw and /mnt/cdrom.  At least that's how it would work on this
>guy's system.  Oh, and it would likely be /mnt/cdrom/Fred\ The\ Cat.
>
>There is also nothing stopping you from using /cdrom and /cdrw.

That proves my point: on Windows and UNIX systems, there is no stable 
form of reference that you can use that works the same from one system 
to another, or even one drive to another. On the Mac, the pathname "My 
Photos:Fred the Cat" is still valid whether you put the CD in the CD-ROM 
drive or in the CD writer.

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

From: "Colin R. Day" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: Claims of Windows supporting old applications are reflecting reality 
Date: Sun, 18 Jun 2000 00:33:41 -0400

John Wiltshire wrote:

> On Sat, 17 Jun 2000 15:22:17 -0700, <[EMAIL PROTECTED]> wrote:
>
> >
> >Marc Schlensog <[EMAIL PROTECTED]> wrote in message
> >news:8igl2f$6c9$10$[EMAIL PROTECTED]...
> >>
> >> John Wiltshire <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
> >> [EMAIL PROTECTED]
> >> [Snip]
> >> > The NT 3.x is quite similar in design to Linux/XF4 if you look at it.
> >> > Wonder how long it takes them to move X into the kernel to improve
> >> > speed?  ;-)
> >>
> >> I hope this never will!
> >
> >I concur fully with this sentiment, NEVER!  Why lock Linux into X?  What
> >about any other windowing system that may be devloped.  X is sepperate from
> >unix, always has been and I hope always will be.  X can run on almost any
> >operating system and it not dependent on unix.  Unix can run X or can run
> >without it, unix can run any other GUI written for it as well.
>
> Ask yourself honestly if anyone is going to develop another windowing
> system before the kernel gets rewritten?  The amount of effort
> required and the fact there would be zero apps supporting it make the
> effort very futile.
>
> Secondly, how does a kernel module for X lock Linux into X any more
> than it is at the moment?  Linux isn't locked into IDE drives and yet
> they are in the kernel.

It isn't so much the lock in as the sacrifice of stability for speed.

>
>
> I think you've blinded yourself to the possibilities.  There's a
> kernel httpd at the moment which is frighteningly fast.  Why not X?
>

Perhaps the fragility of GUI code?

Colin Day


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

From: tholenbot <[EMAIL PROTECTED]>
Crossposted-To: 
comp.sys.mac.advocacy,comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: The Tholenbot  is becoming a Mutlu! (was: Microsoft invites Canada south)
Date: Sun, 18 Jun 2000 00:38:59 -0400

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

> tholenbot wrote:
>  
> > Fish are irrelevant, Jacques.  Your reading comprehension problems are
> > relevant.
> > 
> > In any event, to use your metaphor, tholenbot always bites when someone
> > responds to its messages.  There is no record, as far as I am aware, of
> > tholenbot failing to respond to a message.  If you had decent tholenbot
> > comprehension skills, you would have recognized this fact.
> 
> That was typical Hasan B. Mutlu

On what basis do you make this claim?
>  
> > Take it up with Dave Tholen.  Or maybe Tholen is Mutlu in disguise, or
> > vice versa?  Do you have any sample Mutlu posts available with header
> > information?  Perhaps a comparison is in order.
> 
> And so was this.

I see you failed to answer the question.  How predictable.

> And this too:

Evidence, please.
  
> > Then why do you seem so proud of your discovery that tholenbot behaves
> > like a bot?
> 
> But this is Eliza:

Incorrect.  It is Eliza-like, but it was not Eliza.
 
> > What makes you think that the half that is there isn't worn out already?
> 
> 
> This again is typical Mutlu:

Prove it, if you think you can.
  
> > Illogical, given that you were replying to me, and I am not Hasan B.
> > Mutlu.  Do you understand how Usenet works, Jacques?
> > 
> > Also illogical, given that above you referred to this person as the
> > "late" Hasan B. Mutlu.  Do you frequently attempt to converse with the
> > dead, Jacques?  More evidence of your illogical behavior.  Of course,
> > that is par for your course.
> 
> Now, how would Tholen the Bot know about Hasan B. Mutlu?
>
> Elementary, my dear Ahmed Cosar, just do Altavista search
> on "Hasan B. Mutlu".  Here are a few URLs:
> 
> http://imperium.lenin.ru/~verbit/scs/Mutlu_whatis.html
> 
> http://www.jaedworks.com/shoebox/zumabot.html
> 
> http://www.kkc.net/eyenet/1994/net0728.htm

You overlook the possibility that tholenbot learned about Hasan B. Mutlu 
from Jacques Guy.

Meanwhile, you fail to recognize that tholenbot can distinguish between 
a turkey and Turkey.  Of course, that is predictable, coming from 
someone who lacks decent bot comprehension skills.

-- 
Prove that it's just a flesh wound, if you think you can.

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

From: "Colin R. Day" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: Claims of Windows supporting old applications are reflecting reality 
Date: Sun, 18 Jun 2000 00:41:05 -0400

John Wiltshire wrote:


>
> As for X windowing and Motif windows being separate things, do you
> really understand X?
>

Motif is a widget library, and one can run motif applications on X,
just as one can run qt or gtk apps on X.

Colin Day


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

From: "Colin R. Day" <[EMAIL PROTECTED]>
Subject: Re: Processing data is bad!
Date: Sun, 18 Jun 2000 00:44:39 -0400

Aaron Kulkis wrote:

> "Colin R. Day" wrote:
> >
> > JEDIDIAH wrote:
> >
> > > On Fri, 16 Jun 2000 19:52:03 -0400, Jeff Szarka <[EMAIL PROTECTED]> wrote:
> > > >On Fri, 16 Jun 2000 17:13:22 +0100, 2:1 <[EMAIL PROTECTED]>
> > > >wrote:
> > > >
> > > >>and tell you exactly hoe many text files I have. Now can anyone tell me
> > > >>how to do that under Windows?
> > > >
> > > >Start - Search (or Find) - Files - *.txt ?
> > >
> > >         Nope, that will just tell you how many files you have
> > >         that end it .txt.
> >
> > What, a text file whose name doesn't end in "*.txt"? You'll
> > confuse him, Jedi.
> >
> > BTW would you count *.ini and *.bat files as test files?

oops, should be text files.

>
>
> text files?
>
> are they HUMAN READABLE?

*.bat files are somewhat like shell scripts, and as far as I
can tell, *.ini files are like config files. They are human readable,
and they are not binaries.


Colin Day


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

From: "Colin R. Day" <[EMAIL PROTECTED]>
Subject: Re: Linux is awesome!
Date: Sun, 18 Jun 2000 00:50:21 -0400

[EMAIL PROTECTED] wrote:

> The computer using world..And you knew exactly what I meant.

No, I didn't. And if this is how you use a computer, I can see why
you find Windows easier than Linux.

>
>
> On Sat, 17 Jun 2000 00:29:53 -0400, "Colin R. Day"
> <[EMAIL PROTECTED]> wrote:
>
> >[EMAIL PROTECTED] wrote:
> >
> >
> >>
> >> Yea and 90 percent of the world is using it..
> >>
> >
> >Do 5.4 billion (90% of 6 billion) people even have computers?
> >
> >
> >Colin Day

Colin Day


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

From: "Colin R. Day" <[EMAIL PROTECTED]>
Subject: Re: Why X is better than Terminal Server
Date: Sun, 18 Jun 2000 01:06:48 -0400

Jeff Szarka wrote:

> On Sat, 17 Jun 2000 07:35:06 -0400, mlw <[EMAIL PROTECTED]> wrote:
>
> >The only people who seem to dislike X, are those that don't know X. Yes,
> >it is not as fast as it could be, but it is pretty fast. Accelerated
> >versions of X are quite fast.
> >
> >What is X?
>
> I'm going to forward a copy of this message to my grandmother and see
> what she thinks of X. The amount of the market that actually cares
> about such things is very small. My grandmother (and her friends) make
> up the other 90%  Which market do you want?

We want an OS that is not dumbed down to your grandmother.

>
>
> People hate X becuase it's ugly and slow. They don't care why it's
> ugly and slow, they just know it is.

X isn't ugly, as you don't get to see X. KDE, Gnome. Afterstep can
be beautiful or ugly.

Colin Day


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


** 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