Linux-Advocacy Digest #703, Volume #28 Mon, 28 Aug 00 05:13:05 EDT
Contents:
Re: Inferior Engineering of the Win32 Platform - was Re: Linsux as a desktop
platform (D. Spider)
Re: Inferior Engineering of the Win32 Platform - was Re: Linsux as a desktop
platform (D. Spider)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (D. Spider)
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Inferior Engineering of the Win32 Platform - was Re: Linsux as a desktop
platform
Date: Mon, 28 Aug 2000 09:01:19 GMT
It appears that on Mon, 28 Aug 2000 11:47:29 +1000, "Christopher
Smith" <[EMAIL PROTECTED]> wrote:
>
>"D. Spider" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> <snip>
>> >If you want to support a claim Win95 is poorly engineered, you either
>> >have
>> >to provide some examples of a "better engineered" product that
>> >provides the
>> >same services whilst operating under the same restrictions or, at the
>> >very
>> >least, give a credible explanation of how it could be done.
>>
>> Well you have to first at least make a guess what the design goals
>> are.
>
>They were generally accepted to be:
>Runs as many DOS and Win16 applications as possible
>Runs Win32 apps
>Can use DOS drivers
>Runs in 4MB of RAM
>Has pre-emptive scheduling
It only fails on one of those then - the RAM requirements, obviously.
>> None of the various Windows incarnations touch unix for
>> stability, security, or power of course, but for many of them it's not
>> reasonable to count that against them. It is clearly not a design goal
>> of Windows95 to be exceptionally stable for instance. More of a case
>> in this regard could be made against NT Server - whether it was an
>> explicit design goal or not to provide a robust and powerful platform
>> relative to the hardware investment, given what it's marketed as, it
>> should have been. Running video drivers in kernel space, and having no
>> gui-less operating mode, are arguably major design flaws for any
>> server OS.
>
>Major design flaws ? I'd call them minor implementation issues.
>
>Video drivers in kernel space - largely irrelevant if you a) use the VGA
>drivers (which you should) and b) don't actually use the GUI on the server
>(similarly, like you should).
Even if you do that (which, you are correct, you should) you are still
dealing with a resource cost and a stability cost imposed by the
decision to integrate (what should be) an utterly non-essential
component into the kernel. Even the VGA driver takes memory, cpu
cycles (even when not in use) and yes even the VGA driver sometimes
fouls up and when it does it takes the whole OS down with it. For any
serious use, that is a major design flaw on a server. The more serious
the application, the more glaring the flaw is.
>GUI-less operating mode - again, largely irrelevant since it uses very
>little memory which will be swapped out anyway. If your server is affected
>by the marginal overhead of NT sitting at the login screen, then your server
>is way underpowered.
>
>Largely theoretical problems, blown _way_ out of proportion.
I don't think so. In the real world economics is important for most
people. If you need a P166 to do what I can do with a 386, that's an
economic advantage in my favour. If you need to upgrade hardware twice
as often because your OS is bloated with stuff you don't use, that's
an economic advantage in my favour. If your service is down because of
crashes on a regular basis, and mine is not, then all other things
being equal consumers will favour my service. And if the service in
question is mission critical, those crashes go from a fairly mild
nuisance to a major issue.
>> But another area is not so debateable. Ease-of-learning and ease of
>> use are clearly design goals of any general purpose GUI. All Win32
>> implementations have done fairly poorly in that field.
>
>Compared to what ? And what *relevant* data are you going to use to back
>that up ?
As is clear below, compared to MS own guidelines, generally accepted
principles of usability, Windows 3.1, Mac OS versions 7-9, and
NeXTstep. There are probably other comparisons, but those are the ones
that I have the experience to make personally.
>> All recent
>> versions of Mac OS (prior to 10, which I haven't worked with yet, and
>> seems to have some major issues from what I have read) have been
>> greatly superior in terms of GUI design. The NeXT boxes were clearly
>> superior as well. Windows 3.1 was in many ways superior in terms of
>> GUI design for that matter, although it's technical limitations
>> (particularly in terms of heap space) crippled it.
>
>I wouldn't call MacOS greatly superior in terms of UI. Both GUIs have good
>points and bad points. NeXT I have very little personal experience with,
>and won't comment on.
Well, whether you would call it that or not, it's demonstrably true,
both in abstract and concrete. In abstract, it is a much better match
to the principles of human engineering, in concrete, they are
demonstrably better in terms of the time that someone with no previous
experience takes to learn to use them, and how quickly people that use
them can accomplish standard tasks. This is the result of the fact
that Apple focused very much on usability, a very large amount of the
research done on the subject has been sponsored by Apple, and their
earlier interfaces reflected this very clearly.
Now this is one of many ways that you can judge usability. Most *nix
folks are quite happy with their boxes, which are far worse than MSWin
in this regard - because they accept a steep learning curve in return
for power and flexibility, and because the problems in GUI design
rarely affect them because they don't actually use GUIs much if at
all. So usability isn't the be all and end all of computer design, I
grant that. It is, however, a VERY important component of designing a
general purpose GUI that's intended to be the only or the primary
means for the user to interface with the box. So in the case of
Windows I don't think it's at all unfair to judge with this yardstick.
>> Examples of these problems are not hard to find. Start with the
>> placement of the window control widgets -
>> minimise-maximise/restore-close clustered together is a poor design.
>> The Mac OS9 and prior layout, placing close on the opposite corner
>> from the others is a better design.
>
>For such a "poor design" it seems to have been used almost everywhere else,
>not to mention in the upcoming OS X. If it is noticably worse, only a
>minority seem to realise that.
Many Mac fans are outraged about it actually.
Seemingly minor mistakes like that, keep in mind, don't make a
computer unusable, that should go without saying. But they make it
harder to use, less accessible to Joe User, in a small way perhaps,
but it's undeniably real. Even seasoned computer professionals
occasionally click the close button in windows when they meant to
maximise, and not everyone is a seasoned professional. It can cause
the loss of work, a rise in blood pressure, etc. The whole aim of
human usability is to avoid layouts that encourage this, and placing
the close button in a spot isolated from other controls is a simple
and straightforward way to do that.
>> The placement of the menus - the Windows design where they are placed
>> below the top window border is clearly an inferior design to the Mac
>> placement of the menus along the top edge of the desktop.
>
>That I'll have to disagree on. I find menus in Windows to be better at
>higher resolutions and with multiple monitors. This may have something to
>do with the low mouse tracking speed of MacOS, however. Pop-up menus under
>the mouse are probably the most efficient method, but have discoverability
>issues.
"Context menus" are great, but that doesn't obviate the usability
problems with the main menu bar. Consider the difference in the fine
muscle movement to activate the menu bar with a mouse on the Windows
box compared to the Mac. With the Windows style, you have a relatively
small target to aim for, a rectangle a few pixels on a side. It's
usually around 7-8 times as wide as it is deep. Because of that lack
of depth, the typical movement to access it is to grab the mouse,
wheel it quickly to the menu and overshoot, then reverse direction and
move back more slowly until it is located. With the Mac layout, you
have a rectangle, the same width, but with *infinite depth.* You
simply cannot overshoot the thing, and therefore the reversal and the
second, slower movement is completely avoided.
Small thing? Perhaps. But it's precisely the type of small touch that
differentiates a poor gui and a good one. And to someone that is NOT a
geek, it is often a much more significant difference than you or I
would see it as.
>> The windows task-bar/start-menu" is another bundle of joy for the UI
>> critic. The MS Interface guidelines even explicitly not that cascading
>> menus quickly become unwieldy, and should be limited to 2 layers when
>> used at all - yet a cascading menu with far more layers is the
>> centerpiece of their desktop!
>
>The standard Start menu has, IIRC, exactly 2 layers above "Programs".
But Programs is a layer itself, meaning you typically have a 3 layer
menu, and in many cases 4. Sometimes even more.
>> To edit this menu, an inconsistent
>> version of explorer is used, and good luck finding it.
>
>To edit the Start Menu, you drag and drop to it. Ever since IE4 was
>released, which was quite some time ago. A free upgrade, no less.
That sounds good, you should try using it sometime though. There is no
apparent way to control where on the menu you are dropping to, and
more importantly, editing does not simply mean adding. Pruning off
extraneous entries, moving things from place to place, are essential
parts of editing, and there is no "intuitive" way to do these things.
>The Apple menu is no better (worse, in some cases), and _still_ doesn't have
>drag & drop to it.
>
>> Ever try to drag and drop to an app running on the taskbar? Again,
>> they went to the trouble to describe how drag and drop should work in
>> their own guidelines, then disregard those guidelines entirely
>> themselves.
>
>Which guidelines are disregarded ? You can't drag and drop directly to the
>button for perfectly good reasons, and the dialog you get when you try to
>explains exactly how to do it properly.
Drag and drop 101 - you select an object, press and hold mouse-1, drag
to destination, and release. That's how it's supposed to work, and
that's what the guidelines say.
But you can't do that if your destination is a minimised task on the
taskbar. That's violating their guidelines. Drag-and-drop is supposed
to be just that, not
drag-and-hover-a-few-seconds-then-drag-some-more-and-finally-drop. And
it isn't, except in this one case. A consistent interface would work
here, instead of popping up an error message.
>> The taskbar tray doesn't even pretend to have any guidelines for use -
>> some objects there are manipulable one way, some another, there is no
>> way to access them from the keyboard, and no visual clues as to their
>> use are required - although some choose to display "tooltips" at
>> least.
>
>The only probably I have with the tray per se is that you can't access it
>from the keyboard. When a thousand and one developers choose a thousand and
>one different ways to utilise it, there's not much Microsoft can do.
There isn't? Then why are so many other things developers do
standardised?
The fact is, MS has full control over Windows, they write the
standards for the logo program (which has 1! mention of a UI issue
btw, but not because they didn't have any choice) they write the
development tools and so forth. If they wanted to make the tray
objects respond in standard ways, they could easily have made that so.
They either didn't care, which I find hard to believe, or, more
likely, they simply don't have anyone that understands human
engineering in the offices where these decisions were made.
>> Consistency - MS tools are hideously inconsistent in dozens of areas.
>> In most apps, for instance, alt-e f (menu-edit find) activates the
>> find function. But in notepad, it's alt-s f (menu-find search.)
>
>More examples would be nice. Ctrl+F is the standard shortcut for "Find".
"Standard" by whose standards? That's the biggest problem with Windows
from the human engineering standpoint - there are too many "standards"
for the same thing - not in the sense that you can do things either
way often, but in the sense that you can do things one way here and
there but not in the third place. Alt-e f worked fine with windows 3.1
programs, and still works in some windows programs, but not in others.
Why create a new standard when the old one worked fine? And if you are
going to do so, why not at least do it so that both will work, instead
of forcing the user to find out by trial and error which program will
accept one and which the other?
>Notepad is definitely an odd one out - but it's not hard finding them for
>other OSes as well. Notepad is really just a text control with a menu,
>nothing more (which is hwy it's limited to 64k files in Win9x).
Sure, it's not hard to find this sort of thing on other OSs, I think I
mentioned that despite all the problems with Windows on this point,
it's still a far stretch ahead of any Unix in that respect. That
doesn't mean it's good.
>> You close (alt-f c) a window, you exit (alt-f x) an application. Well,
>> at least in Win3.1 you did. In 95 and later, that's still usually
>> true, but not always - another consistency problem detracting from
>> useability, and very typical.
>
>"Not always" ? Again, it's not hard to find a few counter-examples in other
>OSes, as well.
How many other OSes aim to make an "intuitive" GUI for Joe User
though?
>> The Win95 common dialogs are bad enough (an inexplicable step back
>> from the Win3.1 common dialogs in terms of UI design) but then MS puts
>> out the Office package, which contains it's own unique and different
>> implementations instead of using the common dialogues.
>
>1. What's wrong with the Win9x common dialogs ?
Already posted an extensive critique, with illustrations.
http://www.iarchitect.com/file95.htm
>2. The Office ones are pretty much the same, with a few additions.
>
>> More on the common dialogues, a major usability nightmare even in
>> comparison with the 3.1 version, can be found at
>> http://www.iarchitect.com/file95.htm - in fact anyone interested in UI
>> design should probably take some time to take note of the UI mistakes
>> documented here. Most concern MSWindows, but Apple and *nix get some
>> time too... *nix mostly gets let off easy for the fact that no one
>> expects it to have a good UI, but with recent developments,
>> particularly the hype regarding things like GNOME and KDE that is
>> changing.
>
>I've never been particularly impressed with that site. They seem to have a
>distinct anti-windows bent. Many of the problems they note in Windows
>common dialogs also rear their head in MacOS dialogs, yet there is no such
>comment.
>
>Indeed, many of the complaints they have about the windows command dialogs I
>personally consider good things.
Did you see the piece on Quicktime? I don't think they pull any
punches on Apple, but at least until recently, Apple has been the
number one employer of human engineering GUI specialists, and has
listened to them, so they have have fewer problems. I'm not at all
sure what you mean about the dialogues.
There are some issues with GUI design where the needs of the power
user and the needs of the other sort of user conflict, I will grant
that for sure. But you should be more specific if you mean to
establish anything beyond that.
BTW, I'm not typing this on a Mac, I've never bought a Mac, and I
likely never will. I have used them when a friend had one, and I've
used them at work, and I've never particularly taken to them because I
don't like to be *stuck* in the GUI - whatever other problems Win95
has, at least there is still a DOS box (although there are constant
rumours it will dissappear - if it does, the OS will cease to have any
advantage over a Mac for me.)
But I can be objective about it. Macs definately have a superior GUI
in terms of ease of use and other human engineering concerns. For me,
personally, that isn't a great thing, but for anyone that wants to
build a box for general use it definately should be. And anyone
wanting to do that would be well advised to read up on human
engineering, on GUI design principles, and realise that cloning
Windows is shooting oneself in the foot, because it isn't a very good
example of GUI design at all. Look at the older Mac interface, or the
Next boxes even better, since they had a mix of beginner friendliness
and power-user friendliness, where the Mac has always had the former
but much less of the latter.
#####################################################
My email address is posted for purposes of private
correspondence only. Consent is expressly NOT given
to receive advertisements, or bulk mailings of any
kind.
Since Deja.com will not archive my messages without
altering them for purposes of advertisement, deja.com
is barred from archiving my messages.
#####################################################
------------------------------
From: [EMAIL PROTECTED] (D. Spider)
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Inferior Engineering of the Win32 Platform - was Re: Linsux as a desktop
platform
Date: Mon, 28 Aug 2000 09:01:24 GMT
It appears that on Sun, 27 Aug 2000 23:49:54 -0500, "Erik Funkenbusch"
<[EMAIL PROTECTED]> wrote:
>"D. Spider" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> <snip>
>> >If you want to support a claim Win95 is poorly engineered, you either
>> >have
>> >to provide some examples of a "better engineered" product that
>> >provides the
>> >same services whilst operating under the same restrictions or, at the
>> >very
>> >least, give a credible explanation of how it could be done.
>>
>> Well you have to first at least make a guess what the design goals
>> are. None of the various Windows incarnations touch unix for
>> stability, security, or power of course, but for many of them it's not
>> reasonable to count that against them. It is clearly not a design goal
>> of Windows95 to be exceptionally stable for instance.
>
>No, Windows 95's design goal was to provide maximum backwards compatibility
>with Windows 3.x while providing maximum 32 bit API support (which includes
>multitasking). Where those two contradict, Backwards compatibility has a
>higher priority. Also, Win9x's design goal was to run on the same hardware
>that typical Windows 3.x machines were running on in 1995 and be as fast, or
>faster than Windows 3.x. All of which it achieved.
It certainly did not provide backwards compatibility with Win3.1 in
terms of user interface, and it certainly did NOT run as fast as
Win3.1 on the same machine. I was responsible for about 40 machines at
the time, I am not just making stuff up. The one major advantage it
did have, and the reason why it was adopted at all in my shop, was the
expanded heap allocations, which solved a lot of major problems in
3.1. Machines that ran large complicated windows programs, using heap
space extravagantly, like SPSS or Borland C, simply had to have it.
The others didn't, and so I had the two running side by side on
exactly the same hardware to observe.
>> More of a case
>> in this regard could be made against NT Server - whether it was an
>> explicit design goal or not to provide a robust and powerful platform
>> relative to the hardware investment, given what it's marketed as, it
>> should have been. Running video drivers in kernel space, and having no
>> gui-less operating mode, are arguably major design flaws for any
>> server OS.
>
>Arguably. Lots of things run in kernel space on various Unix servers.
>Linux now has a new kernel space web server. There are telnet servers that
>run in kernel space and sockets that run in kernel space.
Which may or may not be a good idea, but the admin has control of
that, and can run such a program or not. If he does, a case can be
made for it, for instance on a single purpose web server, using mature
code, you get a speed benefit to the one application that is the boxes
reason for being, with very little cost. That argument cannot be made
concerning video drivers, because they are not the servers reason for
being, they are not part of its job description at all. The resources
devoted to the web server would be used in any case - the resources
devoted to the video routines would not. Any instability resulting
from the web server can at least be balanced against improved server
performance - but the video routines offer nothing at all to balance
the instability they can cause.
>> But another area is not so debateable. Ease-of-learning and ease of
>> use are clearly design goals of any general purpose GUI. All Win32
>> implementations have done fairly poorly in that field. All recent
>> versions of Mac OS (prior to 10, which I haven't worked with yet, and
>> seems to have some major issues from what I have read) have been
>> greatly superior in terms of GUI design. The NeXT boxes were clearly
>> superior as well. Windows 3.1 was in many ways superior in terms of
>> GUI design for that matter, although it's technical limitations
>> (particularly in terms of heap space) crippled it.
>
>This is highly debateable. "ease of use" is a subjective measurement.
>You're reading apples propoganda. Lots of people seem to think that OS/2's
>WPS is easy to use. My experience has been opposite.
It's not a purely subjective measurement. Past experience definately
plays a part in any subjective evaluation of it, but that simply means
you must use non-subjective measurements - adherence to the basic
principles of human engineering, and controls for the past experiences
and preferences of test subjects.
>> Examples of these problems are not hard to find. Start with the
>> placement of the window control widgets -
>> minimise-maximise/restore-close clustered together is a poor design.
>> The Mac OS9 and prior layout, placing close on the opposite corner
>> from the others is a better design.
>
>Again, this is subjective. I don't find them to be a poor design at all.
>Anywhere you put them, people will accidentally hit them.
But placing them in one configuration will drastically increase the
chances vs another configuration.
>> The placement of the menus - the Windows design where they are placed
>> below the top window border is clearly an inferior design to the Mac
>> placement of the menus along the top edge of the desktop.
>
>You say this without explaining why this is "clearly superior".
>
>Actually, I believe the Mac design is clearly inferior. The apple design
>forces you to move the mouse to the top of the screen everytime you want to
>use a menu. With the Windows design, if your window is not maximized, you
>must only move the mouse to the top of the window.
>
>Why is this "clearly inferior"?
I explained this in another post (and many of the other issues you
raise,) but briefly, the target area for a windows style menu control
is say (ballpark figure) 1/4"x1/8", whereas the effective target area
for an equivelent menu control in the mac style is 1/4"xinfinity. It
doesn't take a genius to see which one can be hit the quickest and
easiest, and which one may require much more detailed, careful, and
time consuming mouse manipulation.
As to moving the mouse farther to get to the menu, while that is true,
the more relevant issue is not the absolute distance traveled, but the
difficulty of hitting the target, and the time it takes to do so. A
very small, but precise, movement may be harder to do, and take more
time and attention to accomplish, than a very large one in some cases.
This is one. By making sure the menu is always on a screen edge, the
Mac designers insured that the window controls were effectively very
big targets, without squandering screen space by actually making them
big. Also, since they are always in the same place, motor memory
quickly memorises them, much the same way someone that is used to
keyboarding can activate functions with keystrokes much faster than
they can reach for a mouse.
>> Ever try to drag and drop to an app running on the taskbar? Again,
>> they went to the trouble to describe how drag and drop should work in
>> their own guidelines, then disregard those guidelines entirely
>> themselves.
>
>And what part of the guideline does this violate? I notice your arguments
>are getting to be more hand waving than substance as your argument rolls on.
No, it's not. See the other post. Drag-and-drop is not the same as
Drag-and-hover-and-then-drag-some-more-and-drop. The application in
this case is totally different from any other use of drag and drop.
>> The taskbar tray doesn't even pretend to have any guidelines for use -
>> some objects there are manipulable one way, some another, there is no
>> way to access them from the keyboard, and no visual clues as to their
>> use are required - although some choose to display "tooltips" at
>> least.
>
>That's entirely application defined. The taskbar tray might not be used for
>interaction at all. It might just be a visual notification.
Precisely.
>> You close (alt-f c) a window, you exit (alt-f x) an application. Well,
>> at least in Win3.1 you did. In 95 and later, that's still usually
>> true, but not always - another consistency problem detracting from
>> useability, and very typical.
>
>There is a certain amount of inconsistency here. But I've seen lots of Mac
>apps that use inconsistent interfaces in the past as well.
I never said Macs are the be-all and end-all. I pointed to them as an
example of a better implementation of a GUI. At least until recently,
these things were exceptions to the rule, a rule that Apple worked
very hard to formulate, define, and enforce. None of which is true
with windows.
>> The Win95 common dialogs are bad enough (an inexplicable step back
>> from the Win3.1 common dialogs in terms of UI design) but then MS puts
>> out the Office package, which contains it's own unique and different
>> implementations instead of using the common dialogues.
>
>Which end up in the next version of the OS. Windows 2000 has the Office
>style common dialogs.
>
>What exactly is so bad about them? More hand waving?
It's silly to make a common dialogue then not use it in your own
application. Other than that, most of the criticisms that apply to the
95 common dialogues hold true. The windows 3.1 common dialogues were
much better designed.
>> More on the common dialogues, a major usability nightmare even in
>> comparison with the 3.1 version, can be found at
>> http://www.iarchitect.com/file95.htm - in fact anyone interested in UI
>> design should probably take some time to take note of the UI mistakes
>> documented here. Most concern MSWindows, but Apple and *nix get some
>> time too... *nix mostly gets let off easy for the fact that no one
>> expects it to have a good UI, but with recent developments,
>> particularly the hype regarding things like GNOME and KDE that is
>> changing.
>
>Ahh yes. The user interface hall of shame. Some of it I can agree with,
>other things are simply stupid. The author is himself rather arrogant,
>proclaiming that things like buttons are intended to be shortcuts to menu
>items and that they don't belong in a dialog (I guess he doesn't expect the
>user to be able to exit or cancel). Buttons are shortcuts to functionality
>which may or may not be present in the menu (not everything should be a menu
>item, otherwise you end up with thousands of menu entries).
You misrepresent him. The primary objection to toolbar buttons in a
dialogue is that they don't keyboard shortcuts - not a problem in a
regular program window because the menus themselves contain the same
functions and DO have shortcuts.
>He also makes the proclamation that seperate windows for folders and files
>is the correct way of doing things. I disagree. A single, unified
>interface is much easier to learn and use than seperate ones. Apple
>understands this, which is why their finder has a unified interface.
How is one to maintain context in a hierarchical file system without
seeing the hierarchy? How much time does one want to spend every day
scrolling past directories to find the files? Isn't the point of the
entire dialogue to find a file?
I think you are very wrong here. The method of having different panes
for files and for a context tree makes much more sense, at least as
long as we use hierarchical file systems. You don't even need to have
windows 3.1 around to see it on - explorer in win95 uses the two paned
approach, and for a very good reason. That context is important.
>> If the actual shipping products don't match the hype there will be a
>> backlash. I believe that's already starting to happen. An incomplete
>> and inconsistent clone of a bad GUI is inevitably going to be a worse
>> GUI, and a GUI that is any worse than Windows simply will not make Joe
>> User happy - it's just going to convince him that "linux sucks."
>
>Nothing will ever be perfect. Rules or not.
>
>
>
No, nothing will be perfect, but anyone aiming for a mass market
should consider the needs of that market in their design.
#####################################################
My email address is posted for purposes of private
correspondence only. Consent is expressly NOT given
to receive advertisements, or bulk mailings of any
kind.
Since Deja.com will not archive my messages without
altering them for purposes of advertisement, deja.com
is barred from archiving my messages.
#####################################################
------------------------------
** 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
******************************
