A plan for ending Micro$oft's reign

A plan for ending Micro$oft's reign

Post by Jim Phillip » Sat, 15 Jul 1995 04:00:00



Ok, over the last week or so I've been giving a lot of thought as to what
exactly Linux (or Unix in general) needs to have in order for it to
become more popular than Microsoft Windows.  Last night I stayed up real
late typing out the following document.  Read through it and discuss..
I can provide more detailed info about my ideas upon request..

===========================================================================
Fellow Linux fans,

        For awhile now a debate has been raging as to whether or not Linux
should be shared with the rest of the world.  From what I've seen many
seem to believe that Linux is something that even newbies could use, but
there are those who believe that since Unix in general is more complex than
DOS/Windows, Linux should be reserved for Unix activists..  I'm inclined to
agree with both.  Linux has the potential to become the next great popular
OS, but it is still too complex for the average user.  Here's why:

        * There is still too much reliance on the command line interface.

        * There are insufficient applications available that would be useful.

        * It is too difficult to configure anything (especially X).

        * The GUI isn't simple enough.

        * It's too hard to install anything.

        * No good games.

        Now I'm a command line junkie personally, but most of the people
who haven't yet switched and probably never will are those who rely on
Microsoft Windows to do everything for them.  Now we all pretty much agree
that Windows is a clunky, unreliable GUI.  I've seen nobody arguing that,
except those who have never tried anything else.  We also all agree that
Linux (or Unix in general) is far more stable, and powerful.  But I'll be
the first to admit that Bill Gates has us beat in one area.  Windows is
incredibly easy to use compared to Unix and XFree.  Here's why:

        * Program Manager: an easy to use icon based application launcher.

        * File Manager: a pretty good one especially when compared to what's
                out there for X.

        * Built in Multi-Media: The ability to add new formats to the media
                player is a major plus.

        * Easy to use standardized interface: Many X programs have easy to
                use interfaces, but it seems no two programs use the same
                one.

        * Programmers have a standard toolkit: X has Motif and XView, but
                one's commercial and the other is all too infrequently used.

        * Individually loadable drivers: Linux itself has never had these,
                but is now working towards that goal.  An X interface to
                aid in their configuration will be a must.

        * A host of other little things

        What can we do about this?  Plenty.  I have a plan for the development
of several different programs for X that can help us move towards a standard,
which will blow Microsoft away in terms of usability, power, and
-= hopefully =- popularity.  Let me explain.  For starters, I'd like to
use programs which are already in existance to do much of this.  If it's
already been done, why start over.  In these cases, it would be wise to contact
the author(s) whose program we wish to use and ask for their help in
integrating the program with the new standard.  In areas where nothing
currently exists, we can ask for programmers to help in the creation.  Here's
the general structure I'd like to see:

        * A new Window Manager.  Many of the features of fvwm would be
                useful, and in fact it could be used as a foundation for
                this project.  However we would need to streamline the
                resource file so that on-the-fly changes could be made
                as necessary.  The modular system of fvwm would also
                be useful, and many of it's current modules could be
                ported without many modifications (it's Sound Event and
                Pager modules for example).  Many of fvwm's currently
                built-in functions should also be modulized to cut down
                on overhead.

        * A program manager should be created. I will include more
                details later in this document.

        * A media player. I've found xanim to be very useful so far, but
                it lacks in the area that it's not expandable to include
                new formats except by the author.  More later.

        * A file manager.  Midnight Commander has announced that its new
                version will be written for X.  I'm not exactly sure what
                new features it's touting, but a file viewer would be a
                definate bonus.

        * A programmers' toolkit.  It would contain easy ways to do things
                that both Motif and XView left out.  Such as toolbars, pull
                down menus, OLE, drag-n-drop, multi-media functions, etc..
                Basically all the different specifications of this standard.

        * An Install manager.  This is an idea I believe to be an original
                from me.  More later.

        * Applications that can follow both this standard, and still retain
                the ability to run without it.  Programmer's would be
                encouraged (but not forced) to write programs that would
                use all the features the new standard provides for (ie. OLE,
                drag-n-drop, on-the-fly config, toolbars) which would still
                be able to operate without this "library".

Now, to go into more detail on a few of these things..

First of all, and most importantly, the programmer's toolkit.  This would
have to provide functions to do all the different things the standard
specifies.  In writing this library, we could borrow from both Motif and
XView for what has already been written.  I believe things like buttons,
basic X functions, & etc are written in here.  Stop me if I'm wrong, I'm not
the best programmer, and I really have no X programming experience.  However,
I'm not aware of any functions for doing things like OLE, drag-n-drop, toolbars,
dialog boxes, pull-down menus, on-the-fly configuration, and other high-end
features being included.  As this standard develops, new features could be
added, but here's a few I'd like to see as a start:

        * Object Linking and Embedding
        * Drag 'n' Drop
        * Button Toolbars
        * Pull Down Menus
        * Built-in Icons (for the program manager)
        * Dialog-boxes
        * On-the-fly configuration
        * Printer Interface

Next, the Program Manager.  This could be written either as a module, or
as an application using the toolkit just described.  As a module, it would
have to run from within the new window manager, but could be written smaller
so as not to take up too much overhead.  As a seperate program, it could run
in any window manager (thus allowing the option of using others), but would
be larger due to the fact that the library would have to be linked in.  I
generally envision this as a cross between PCTools Desktop and Norton Desktop.
Either way it should have at least the following features:

        * Program groups
        * Clickable icons to run apps
        * Application Icon's don't necessarily have to be inside a group
        * Groups can contain other groups
        * The ability to drag an icon to and from other apps.
        * Automatic groups for containing up-to-date listings of a users's
                docs or whatever.
        * Whatever else we can think of..

A Media-Viewer.  Like I said before, Xanim is a good start.  However, a better
approach would be to create a general viewer with the basic controls (stop,
play, pause, rewind, fast-forward, loop, etc..) and have it only have two
native formats: A sound format, and a video format.  Then create drivers,
which would convert whatever it is into one of these formats (ie. a driver
for .wav would convert the .wav into the native sound format which would
then be played) or in the case of video with sound, would break the file
into it's two parts as well as convert both parts into the native formats
(ie. .mov would be broken into native sound and native video).  The native
format specs naturally would have to be made public so that new format creators
would be able to write drivers for them (or so third parties could).

A File-Manager.  I mentioned Midnight Commander before.. It's not out yet for
X, so I don't really have anything to base an opinion on, but my guess is it
will be good.  I also said if it doesn't include it, we'll want a built-in
file viewer.  Most people know how this works.. One standard display format
and a filter for converting others.. ie. the viewer would be programmed to
display only jpg and the filters would be written for specific apps (ie
rtf -> jpg)..  Now obviously that specific scenario seems a little odd, but
some other format would be more ideal for the standard..  Authors of an
app which creates one format would then write the filter.. Same concept
as the Media-Viewer but for still images.

A Sound-event manager.  FVWM's already got one, but it could use some
enhancements, such as the ability for other programs to add events to it.

The Install Manager.  I believe this may be an original idea of mine.  I've
never heard of anything like it..  What this is is a client/server program.
The specs for the client will be distributed to programmers, and will be
similar to the Makefile.  Programmers will include in it instructions on what
needs to be configured by the user, how they want the user to be prompted
for this info, etc, compilation info, and installation info.  The server
will be built in to the window-manager, or maybe as a seperate app callable
from any program conforming to the standard (fileman, progman, etc).  It will
control the actual details such as how to display the info given it by the
client.  It will be similar to make in effect.  Thus a user will be able to
pull down a menu from the program manager, select Install App, be asked
where the App is to be installed from, and it will take it from there,
prompting the user for info as needed, and displaying error messages, and
progress meter along the way.  It will be in effect like providing an
install.exe program to all developers and allowing them to create an
install.nfo file or whatever.  Some DOS/Windows app companies already use
one installer for all of their apps making only minor modifications for
individual programs..  Why can't X have something like this?

Disclaimer:
        * I'm aware of the 4D window manager for SGI which has some of
                the feature's i've mentioned.
...

read more »

 
 
 

A plan for ending Micro$oft's reign

Post by Michael Higgin » Sat, 15 Jul 1995 04:00:00


You have a number of good ideas.  Rest assured that other people are
thinking along the same lines ;)

Some thoughts:

Your interface model sounds rather Windows-esque.  I'd personally like
to see a more advanced model.  OpenDoc (upon which OLE could
conceivably be built) springs to mind.  Graphical equivalents to pipes
would be good (NeXT does this, I understand).  The ability to get to a
shell fast would be good for those who want to use it at least part of
the time.  Transparent access to net resources, a la Caldera, would be
good.

As for fvwm's module capability, these exist primarily to develop
extensions to the window manager.  An extension is an application that
needs to be able to query the window manager, and send fvwm commands.
This is done by two pipes.  I can see that this would be useful for
many things, but you don't want to put too much into the window
manager (or even its modules).  I think a program manager could very
well want to be window manager independent.

Title bars are a widget set problem.  The proper thing to do here is
develop an Xt-based widget set.  It would be intriguing to see an
extended version of Athena (which is not too fascinating compared to
Motif, but which has many apps).  Xaw3d exists, and is nice, but is
just as limited as Athena.  

Personally, I don't require a hefty graphical spreadsheet, and I like
*a lot.  But good GUIs are just so much fun to play with, and
pose interesting design problems :)

(As a final aside, I'd like to know what the latest is on GnuStep...
last I checked their web page it hadn't changed in a few months.)

-Mike | http://www.veryComputer.com/

      | "For I think that most probably you will then be converted on
         all points to my conception and to my treatment of the subject;
         and this is just what I should value most, since I am convinced
         that you really have a deep interest in the matter."
                                        R. Dedekind (1890)

 
 
 

A plan for ending Micro$oft's reign

Post by Donal K. Fello » Tue, 18 Jul 1995 04:00:00


In article <Pine.PMDF.3.91.950714174447.694162043A-100...@conrad.appstate.edu>,
Jim Phillips  <gh3...@conrad.appstate.edu> wrote:

> Ok, over the last week or so I've been giving a lot of thought as to
> what exactly Linux (or Unix in general) needs to have in order for
> it to become more popular than Microsoft Windows.  Last night I
> stayed up real late typing out the following document.  Read through
> it and discuss..  I can provide more detailed info about my ideas
> upon request..

> For awhile now a debate has been raging as to whether or not Linux
> should be shared with the rest of the world.  From what I've seen
> many seem to believe that Linux is something that even newbies could
> use, but there are those who believe that since Unix in general is
> more complex than DOS/Windows, Linux should be reserved for Unix
> activists..  I'm inclined to agree with both.  Linux has the
> potential to become the next great popular OS, but it is still too
> complex for the average user.  Here's why:

>    * There is still too much reliance on the command line interface.

A CLI is really necessary for some tasks, but the criticism is true.

>    * There are insufficient applications available that would be useful.

TRUE!

>    * It is too difficult to configure anything (especially X).

Configuring X servers properly is a major pain...

>    * The GUI isn't simple enough.

X has several GUIS, all of which can be used at the same time...

>    * It's too hard to install anything.

xmkmf -a && make install

A fancy interface to this would be nice though...

>    * No good games.

Err, some of the games are _too_ good (or at least too addictive :^)

> Now I'm a command line junkie personally, but most of the people who
> haven't yet switched and probably never will are those who rely on
> Microsoft Windows to do everything for them.  Now we all pretty much
> agree that Windows is a clunky, unreliable GUI.  I've seen nobody
> arguing that, except those who have never tried anything else.  We
> also all agree that Linux (or Unix in general) is far more stable,
> and powerful.  But I'll be the first to admit that Bill Gates has us
> beat in one area.  Windows is incredibly easy to use compared to
> Unix and XFree.  Here's why:

>    * Program Manager: an easy to use icon based application launcher.

>    * File Manager: a pretty good one especially when compared to what's
>            out there for X.

I suppose you could start out by writing something based on xfm which
would do these two.

>    * Built in Multi-Media: The ability to add new formats to the media
>            player is a major plus.

Have some central server which knows how to start and control media
players, with a nice and simple text configuration file.

>    * Easy to use standardized interface: Many X programs have easy to
>            use interfaces, but it seems no two programs use the same
>            one.

Something along the lines of Tk would be nice (I implemented
inter-application drag-and-drop this morning, so it isn't too bad :)

>    * Programmers have a standard toolkit: X has Motif and XView, but
>            one's commercial and the other is all too infrequently used.

Tk again.

>    * Individually loadable drivers: Linux itself has never had these,
>            but is now working towards that goal.  An X interface to
>            aid in their configuration will be a must.

Could be written easily.

- Show quoted text -

>    * A host of other little things

> What can we do about this?  Plenty.  I have a plan for the
> development of several different programs for X that can help us
> move towards a standard, which will blow Microsoft away in terms of
> usability, power, and _hopefully_ popularity.  Let me explain.  For
> starters, I'd like to use programs which are already in existance to
> do much of this.  If it's already been done, why start over.  In
> these cases, it would be wise to contact the author(s) whose program
> we wish to use and ask for their help in integrating the program
> with the new standard.  In areas where nothing currently exists, we
> can ask for programmers to help in the creation.  Here's the general
> structure I'd like to see:

>    * A new Window Manager.  Many of the features of fvwm would be
>            useful, and in fact it could be used as a foundation for
>            this project.  However we would need to streamline the
>            resource file so that on-the-fly changes could be made
>            as necessary.  The modular system of fvwm would also
>            be useful, and many of it's current modules could be
>            ported without many modifications (it's Sound Event and
>            Pager modules for example).  Many of fvwm's currently
>            built-in functions should also be modulized to cut down
>            on overhead.

fvwm would be better if (IMHO) it didn't look so much like mwm. XPMs
for title bar buttons, and shrink titles would be very nice. But apart
from that, fvwm is very good.

>    * A program manager should be created. I will include more
>            details later in this document.

>    * A media player. I've found xanim to be very useful so far, but
>            it lacks in the area that it's not expandable to include
>            new formats except by the author.  More later.

xanim should provide the service of being able to play certain
formats, but it should not be called for everything. Let a different
program understand what should be called where...

>    * A file manager.  Midnight Commander has announced that its new
>            version will be written for X.  I'm not exactly sure what
>            new features it's touting, but a file viewer would be a
>            definate bonus.

When you get right down to it, the WinDoze file manager is not too bad
(I've seen far worse)

>    * A programmers' toolkit.  It would contain easy ways to do things
>            that both Motif and XView left out.  Such as toolbars, pull
>            down menus, OLE, drag-n-drop, multi-media functions, etc..
>            Basically all the different specifications of this standard.

I think that a way to create applications without having to delve into
C would speed app development massively...

>    * An Install manager.  This is an idea I believe to be an original
>            from me.  More later.

This should be capable of installing both pre-compiled and source
distributions.

>    * Applications that can follow both this standard, and still retain
>            the ability to run without it.  Programmer's would be
>            encouraged (but not forced) to write programs that would
>            use all the features the new standard provides for (ie. OLE,
>            drag-n-drop, on-the-fly config, toolbars) which would still
>            be able to operate without this "library".

That sounds like static linking to me... :^(

> Now, to go into more detail on a few of these things..

> First of all, and most importantly, the programmer's toolkit.  This
> would have to provide functions to do all the different things the
> standard specifies.  In writing this library, we could borrow from
> both Motif and XView for what has already been written.  I believe
> things like buttons, basic X functions, & etc are written in here.
> Stop me if I'm wrong, I'm not the best programmer, and I really have
> no X programming experience.  However, I'm not aware of any
> functions for doing things like OLE, drag-n-drop, toolbars, dialog
> boxes, pull-down menus, on-the-fly configuration, and other high-end
> features being included.  As this standard develops, new features
> could be added, but here's a few I'd like to see as a start:

>    * Object Linking and Embedding

Catch phrase. What you want to do is to place documents inside other
documents. This takes careful design of the format... (eg. how do I
put a sound file into a plain text doc?)

>    * Drag 'n' Drop

Easy in Tk (see http://www.cs.man.ac.uk/~fellowsd/d+d.tcl)

>    * Button Toolbars

Trivial in Tk

>    * Pull Down Menus

Trivial in Tk

>    * Built-in Icons (for the program manager)

Why build them in? You could make them separate files installed
cleverly by your installer instead...

>    * Dialog-boxes

Simple ones are trivial in Tk. Complex ones will always be complex... :^)

>    * On-the-fly configuration

Trivial in Tk (I seem to be saying this a lot :^)

>    * Printer Interface

Generate postscript, and rely on having ghostscript to hand where the
printer won't take it native...

> Next, the Program Manager.  This could be written either as a
> module, or as an application using the toolkit just described.  As a
> module, it would have to run from within the new window manager, but
> could be written smaller so as not to take up too much overhead.  As
> a seperate program, it could run in any window manager (thus
> allowing the option of using others), but would be larger due to the
> fact that the library would have to be linked in.  I generally
> envision this as a cross between PCTools Desktop and Norton Desktop.
> Either way it should have at least the following features:

>    * Program groups
>    * Clickable icons to run apps

Why _wouldn't_ you have this??

>    * Application Icon's don't necessarily have to be inside a group
>    * Groups can contain other groups

So groups, apps and docs should all be first class objects. This is a
good idea.

>    * The ability to drag an icon to and from other apps.

Easy with drag and drop.

>    * Automatic groups for containing up-to-date listings of a users's
>            docs or whatever.

An excellent idea, but does this refer to all documents on the filing
system, partition or in a particular directory? (solution: make it
configurable)

- Show quoted text -

>    * Whatever else we can think of..

> A Media-Viewer.  Like I said before, Xanim is a good start.
> However, a better approach would be to create a general viewer with
> the basic controls (stop, play, pause, rewind, fast-forward, loop,
> etc..) and have it only have two native formats: A sound format, and
> a video format.  Then create drivers, which would convert whatever
> it is into one of these formats (ie. a driver for .wav would convert
> the .wav into the native sound format which would then be played) or
> in the case of video with sound, would break the file into it's two
> parts

...

read more »

 
 
 

A plan for ending Micro$oft's reign

Post by Jim Phillip » Tue, 18 Jul 1995 04:00:00



> You have a number of good ideas.  Rest assured that other people are
> thinking along the same lines ;)

> Some thoughts:

> Your interface model sounds rather Windows-esque.  I'd personally like
> to see a more advanced model.  

Nothing at all says that this should LOOK like Microsoft..  However it
could still retain a lot of the functionality..

Quote:> OpenDoc (upon which OLE could
> conceivably be built) springs to mind.  Graphical equivalents to pipes
> would be good (NeXT does this, I understand).  The ability to get to a
> shell fast would be good for those who want to use it at least part of
> the time.  Transparent access to net resources, a la Caldera, would be
> good.

I've definately got to look deeper into Caldera.. My access to the net
has been reduced to a VMS shell account recently, so I'm a little stuck
as far as resources.. As far as getting to a shell quickly that would be
simple, add a line into the control menu to say Open XTerm or something
to that effect, but you're right..

Quote:

> As for fvwm's module capability, these exist primarily to develop
> extensions to the window manager.  An extension is an application that
> needs to be able to query the window manager, and send fvwm commands.
> This is done by two pipes.  I can see that this would be useful for
> many things, but you don't want to put too much into the window
> manager (or even its modules).  I think a program manager could very
> well want to be window manager independent.

Yeah, as I thought more about this I tended to steer away from modules..

Quote:> Title bars are a widget set problem.  The proper thing to do here is
> develop an Xt-based widget set.  It would be intriguing to see an
> extended version of Athena (which is not too fascinating compared to
> Motif, but which has many apps).  Xaw3d exists, and is nice, but is
> just as limited as Athena.  

I've also been pointed at Tk..

Quote:> Personally, I don't require a hefty graphical spreadsheet, and I like
>*a lot.  But good GUIs are just so much fun to play with, and
> pose interesting design problems :)

Most definately.. That's about the extent of what I personally want them
for.. They are also great time savers when they work right (something I
found myself saying all the time when dealing with Windoze)..

Quote:> (As a final aside, I'd like to know what the latest is on GnuStep...
> last I checked their web page it hadn't changed in a few months.)

Never heard of it.. What is it?

Jim

 
 
 

A plan for ending Micro$oft's reign

Post by Michael Higgin » Tue, 18 Jul 1995 04:00:00



>> (As a final aside, I'd like to know what the latest is on GnuStep...
>> last I checked their web page it hadn't changed in a few months.)

>Never heard of it.. What is it?

http://www.cosy.sbg.ac.at/comp/os/gnustep/faq.html will explain things
better than I can.  NeXT released the OpenStep specification, which I
gather is their user-interface model.  Lots of people rave about NeXT;
I've never had the opportunity to do more than look over people's
shoulders, so I don't know.

Anyway, GNU is implementing a free version (with display postscript
and everything), but I don't know what the status is.  I should pop
over and see if they've updated anything...

-Mike | http://latifundium.pc.cc.cmu.edu/home/latifundium/higgins/www/

      | "For I think that most probably you will then be converted on
         all points to my conception and to my treatment of the subject;
         and this is just what I should value most, since I am convinced
         that you really have a deep interest in the matter."
                                        R. Dedekind (1890)

 
 
 

A plan for ending Micro$oft's reign

Post by Joshua Edwards Jone » Wed, 19 Jul 1995 04:00:00


An advance apology if I am replying to this twice.. btw, this is really
Jim Phillips.. My newsserver crashed today so I'm having to use a friends
account to keep up..

On 17 Jul 1995, Donal K. Fellows wrote:

> In article <Pine.PMDF.3.91.950714174447.694162043A-100...@conrad.appstate.edu>,
> Jim Phillips  <gh3...@conrad.appstate.edu> wrote:
> >       * There is still too much reliance on the command line interface.

> A CLI is really necessary for some tasks, but the criticism is true.

I can definately agree with you on this one, although there will be those
who want to totally do away with a CLI (Microsoft takes a stab at it with
Win95 even though they leave the "DOS 7.00" in to sooth the wounds..  
While I was still a Windows user those many eons ago, I found myself
frequently shelling to dos to do some of the simple stuff like
pkzip/unzip, etc.. And if I sound like I'm babbling, I am because this
crazy news editor requires that I type more than I include.. ?? Wierd..

> >       * There are insufficient applications available that would be useful.

> TRUE!

I'd like to compile a list of what applications are wanted most..  A
WYSIWYG word processor is an obvious choice.. There was a thread about
this awhile ago.. I wonder if it ever got put together into a real list..

> >       * The GUI isn't simple enough.

> X has several GUIS, all of which can be used at the same time...

You confused me here.. What is your definition of a GUI?  I was referring
to X in general.. Although I guess I'm really saying X with FVWM since
that's the combo I use..

> >       * No good games.

> Err, some of the games are _too_ good (or at least too addictive :^)

Ok, I'll admit Doom is really good, but I don't see a lot of games of
this quality out for Linux.. I know it usually takes a commercial setup
to make these things, but hey, if Id did it, why can't the rest of them?

> >       * File Manager: a pretty good one especially when compared to what's
> >               out there for X.

> I suppose you could start out by writing something based on xfm which
> would do these two.

Well, Midnight Commander is supposed to be announcing a new version for X
soon.. I'd like to see that before writing something entirely new..

> >       * Built in Multi-Media: The ability to add new formats to the media
> >               player is a major plus.

> Have some central server which knows how to start and control media
> players, with a nice and simple text configuration file.

Now here's the one area I think I really disagree with you on.. I'm of
the opinion that if you can get one program to do the work of many, why
fill up your hard drive with all those extra programs?  I'm also
inherently agains native format support..  Why load support for several
formats you're not ever going to use?  So if I'm not going to have 5
programs to view 5 formats, and I'm not going to have one program with
native support for 50 formats when I'm only going to use 5, then the only
other option is one program with driver support for however many formats
I want..  But since it's obvious there will be debate about this, and
that is something I wish to avoid wherever possible, there's nothing says
we can't use some sort of mailcap file maybe have either a line saying
video/* ; media-player
  or
video/avi ; avi-player
video/mpeg ; mpeg-player
etc...

either way is just as extendible technically..i prefer the former, some
may prefer the latter..

> >       * Easy to use standardized interface: Many X programs have easy to
> >               use interfaces, but it seems no two programs use the same
> >               one.

> Something along the lines of Tk would be nice (I implemented
> inter-application drag-and-drop this morning, so it isn't too bad :)

I'll have to take a look into Tk..  I must admit I'm not all that
familiar with it.. It may be that we can use it for the foundation of
this project and extend it as necessary..

> >       * A new Window Manager.  Many of the features of fvwm would be
> >               useful, and in fact it could be used as a foundation for
> >               this project.  However we would need to streamline the
> >               resource file so that on-the-fly changes could be made
> >               as necessary.  The modular system of fvwm would also
> >               be useful, and many of it's current modules could be
> >               ported without many modifications (it's Sound Event and
> >               Pager modules for example).  Many of fvwm's currently
> >               built-in functions should also be modulized to cut down
> >               on overhead.

> fvwm would be better if (IMHO) it didn't look so much like mwm. XPMs
> for title bar buttons, and shrink titles would be very nice. But apart
> from that, fvwm is very good.

What would you suggest it look like??  One feature I was considering
putting in was the ability to allow the user to custom configure his/her
own look (using xpms would be a plus here).. For instance give them some
kind of basic drawing tool that can create and modify certain widgets..
that way although it would still retain the functionality this standard
provides for, it doesn't have to stick to some rigid layout specification..

> >       * A media player. I've found xanim to be very useful so far, but
> >               it lacks in the area that it's not expandable to include
> >               new formats except by the author.  More later.

> xanim should provide the service of being able to play certain
> formats, but it should not be called for everything. Let a different
> program understand what should be called where...

Once again I bring up my previous argument, and stand by my response.. I
also don't necessarily wish to use xanim in it's current structure.. it
may be used as a general model, but would have to be reworked completely
to incorporate drivers..  I'd rather see it with native support for only
one kind of format, and use drivers to view the others..  As a little
example, I've written a real simple script which uses sox and vplay..
I use vplay as my sound player.. It has native support for only .wav
(maybe one or two others)..  I use sox as a sort of driver interface.. I
first send the sound through sox which converts it to a .wav which is
then sent to vplay and sent to my soundcard..  That's exactly what I
propose to do with the media player.. except instead of using only one
really big driver with support for LOTS of formats, use lots of little
drivers with support for only one format..

> >       * A file manager.  Midnight Commander has announced that its new
> >               version will be written for X.  I'm not exactly sure what
> >               new features it's touting, but a file viewer would be a
> >               definate bonus.

> When you get right down to it, the WinDoze file manager is not too bad
> (I've seen far worse)

Ditto, this is one thing that Windows did good.. But I've also seen far
better file managers..  I'm really looking forward to Midnight Commander
for X in case you couldn't tell.. :)

> >       * A programmers' toolkit.  It would contain easy ways to do things
> >               that both Motif and XView left out.  Such as toolbars, pull
> >               down menus, OLE, drag-n-drop, multi-media functions, etc..
> >               Basically all the different specifications of this standard.

> I think that a way to create applications without having to delve into
> C would speed app development massively...

A sort of Visual C for X would be nice..  Or for that matter, simply a
development package which lets you edit, compile, run, and trace/debug a
program all at once would be handy..

> >       * An Install manager.  This is an idea I believe to be an original
> >               from me.  More later.

> This should be capable of installing both pre-compiled and source
> distributions.

Natch.. I wouldn't have it any other way.. :) And it's a simple task
using the method I outlined below..

> >       * Applications that can follow both this standard, and still retain
> >               the ability to run without it.  Programmer's would be
> >               encouraged (but not forced) to write programs that would
> >               use all the features the new standard provides for (ie. OLE,
> >               drag-n-drop, on-the-fly config, toolbars) which would still
> >               be able to operate without this "library".

> That sounds like static linking to me... :^(

You're right here.. As I've thought about it, this does seem a bit
silly.. Shared linking will be a definate bonus.. If a developer wanted
to distribute source code and then have it statically link in a library,
the user will first have to get that library.. And if they get that
library, then the developer might as well use shared linking.. *shrug*
the ultimate paradox.. :)  Oh well.. This will be a great use for ELF..
And it'll allow commercial developers to make one binary and distribute it..

> >       * Object Linking and Embedding

> Catch phrase. What you want to do is to place documents inside other
> documents. This takes careful design of the format... (eg. how do I
> put a sound file into a plain text doc?)

Nobody said this was going to be easy.. :)  But actually, I've been
directed towards OpenDoc.. I'll have to take a look at it and see what
it's got..

> >       * Built-in Icons (for the program manager)

> Why build them in? You could make them separate files installed
> cleverly by your installer instead...

Good point.. it was just a toy idea.. nothing more.. :)

> >       * Printer Interface

> Generate postscript, and rely on having ghostscript to hand where the
> printer won't take it native...

Once again, I'd rather not rely on ghostscript to contain the drivers for
converting ps into device-specific formats.. That means that we have to
rely on ghostscript to keep up to date with new printers.. Better to be
able to allow the printer manufacturers to put out a driver.. Besides, in
this instance, most people are only going to need one driver instead of
having 30 or 40 they're not going to use..

- Show quoted text -

> > Next, the Program Manager.  This could be written either as a

> >       * Program groups
> >       *

...

read more »

 
 
 

A plan for ending Micro$oft's reign

Post by Jim Phillip » Wed, 19 Jul 1995 04:00:00


On 17 Jul 1995, Donal K. Fellows wrote:

> >       * There is still too much reliance on the command line interface.

> A CLI is really necessary for some tasks, but the criticism is true.

I agree with you there.. When I was still a Windows user I found myself
frequently shelling to DOS to do some things.. But some things are faster
and easier with a GUI..

> >       * There are insufficient applications available that would be useful.

> TRUE!

I'd like to see someone compile a list of the different suggestions that
have sprung up as far as just WHAT applications are needed..  A WYSIWYG
word processor is a must.. But we've already got that in Andrew (I didn't
really like Andrew all that much however)..

> >       * It is too difficult to configure anything (especially X).

> Configuring X servers properly is a major pain...

> >       * The GUI isn't simple enough.

> X has several GUIS, all of which can be used at the same time...

You've got me a little confused here..  What is your def. of a GUI?  I
was simply referring to X in general..

> >       * It's too hard to install anything.

> xmkmf -a && make install

> A fancy interface to this would be nice though...

> >       * No good games.

> Err, some of the games are _too_ good (or at least too addictive :^)

Ok, I'll admit, DOOM is a bit addictive, but I haven't seen very many
games of this quality for Linux..  I'll admit that it usually takes a
commercial company to put out this kind of game, but if Id can do it, why
can't others?

> >       * File Manager: a pretty good one especially when compared to what's
> >               out there for X.

> I suppose you could start out by writing something based on xfm which
> would do these two.

Before writing something new, I'd like to check out xmc (Midnight
Commander for X) which is coming soon..

> >       * Built in Multi-Media: The ability to add new formats to the media
> >               player is a major plus.

> Have some central server which knows how to start and control media
> players, with a nice and simple text configuration file.

This would work, but I think that one player with the ability to add new
formats takes less space and resources..  That way we don't have a half
dozen players that can play mpegs and none that play .AVI or whatever..  
What I've already done with sounds for my system is create a script for
Sox to convert a sound into a WAV and then use vplay to play them..
native support for a bunch of file formats is in my opinion a waste of
resources..  The ability instead to turn on and off any of these formats
and only have to load one at a time is a plus..

> >       * Easy to use standardized interface: Many X programs have easy to
> >               use interfaces, but it seems no two programs use the same
> >               one.

> Something along the lines of Tk would be nice (I implemented
> inter-application drag-and-drop this morning, so it isn't too bad :)

Cool, You've started already.. :)

> fvwm would be better if (IMHO) it didn't look so much like mwm. XPMs
> for title bar buttons, and shrink titles would be very nice. But apart
> from that, fvwm is very good.

Wraparound titles when the program is iconized would be nice too.. I
oftentimes run into problems when i iconize a program and it's title is
chopped down into a few letters.

> xanim should provide the service of being able to play certain
> formats, but it should not be called for everything. Let a different
> program understand what should be called where...

I'm not suggesting we use xanim in it's current state..  xanim uses
native support for many formats and is thus not extendible.. rather
native support for one and drivers which can convert others into that one
is something I'd like to see..
And I say again, why have many programs with native support for a few
formats when we can have one program with extendible driver support for
infinite formats..

> >       * A file manager.  Midnight Commander has announced that its new
> >               version will be written for X.  I'm not exactly sure what
> >               new features it's touting, but a file viewer would be a
> >               definate bonus.

> When you get right down to it, the WinDoze file manager is not too bad
> (I've seen far worse)

I'll agree with you there.. Windoze did a good job there.. I too have
seen far worse, but I've also seen far better..  Maybe you can tell that
I'm really looking forward to Midnight Commander for X?

> >       * A programmers' toolkit.  It would contain easy ways to do things
> >               that both Motif and XView left out.  Such as toolbars, pull
> >               down menus, OLE, drag-n-drop, multi-media functions, etc..
> >               Basically all the different specifications of this standard.

> I think that a way to create applications without having to delve into
> C would speed app development massively...

Some kind of Visual C for X would be definately be a plus..  I hadn't
thought of that..

> >       * An Install manager.  This is an idea I believe to be an original
> >               from me.  More later.

> This should be capable of installing both pre-compiled and source
> distributions.

Shouldn't be too difficult to do using the method I outlined below..

> >       * Applications that can follow both this standard, and still retain
> >               the ability to run without it.  Programmer's would be
> >               encouraged (but not forced) to write programs that would
> >               use all the features the new standard provides for (ie. OLE,
> >               drag-n-drop, on-the-fly config, toolbars) which would still
> >               be able to operate without this "library".

> That sounds like static linking to me... :^(

You're right.. that was a silly idea.. :) shared linking is much better..
ELF will be a bonus here.. Especially in the area of commercial
developers..

> >       * Object Linking and Embedding

> Catch phrase. What you want to do is to place documents inside other
> documents. This takes careful design of the format... (eg. how do I
> put a sound file into a plain text doc?)

I never said it'd be easy.. :) However I've been told OpenDoc might be
something to look at for a model..

> >       * Built-in Icons (for the program manager)

> Why build them in? You could make them separate files installed
> cleverly by your installer instead...

Just a neat toy basically :) but you're right..

> >       * Printer Interface

> Generate postscript, and rely on having ghostscript to hand where the
> printer won't take it native...

That was my general plan..  Only gs doesn't have support for a lot of
different printers.. However ps is a good native format to use.. but
instead of using gs, a more driver oriented approach could be used.. That
way, instead of a person having to use a large program to print his file,
a small driver would work instead.. Since gs has already gone through the
trouble of writing in so MANY drivers though, we could use their code in
writing the specific drivers..  This saves everyone from having to wait
until ghostscript comes out with a new version and allows printer
manufacturers the ability to write a specific driver without having to
reveal any technical specifications they don't want to..

> >       * Application Icon's don't necessarily have to be inside a group
> >       * Groups can contain other groups

> So groups, apps and docs should all be first class objects. This is a
> good idea.

Thanx, but I can't take the credit.. PCTools Desktop has been doing this
for awhile, as well as Norton Desktop and numerous others..  I think
Microsoft is probably the only one NOT doing this... *shrug*

> >       * Automatic groups for containing up-to-date listings of a users's
> >               docs or whatever.

> An excellent idea, but does this refer to all documents on the filing
> system, partition or in a particular directory? (solution: make it
> configurable)

Yup.. Once again this could be modeled after any number of replacement
Windows program managers...

> Have a Media Control Message Dispatch Server which receives requests
> to do things with media streams and organises the running of any
> actual applications needed to do that. This makes things easy to
> extend...

Once again it's a matter of having two programs do something that one
could do quite nicely.. This seems to be the one area we disagree on..
Whether to use native support or driver support.. I guess we could do
both.. And allow the user to choose..

> The graphics viewer should work in a 24-bit uncompressed format. Don't
> clobber the future quality of the system without very good reason...

I probably shouldn't have used jpg as an example native image.. :) tiff?  
I don't know.. I'm not really a graphics buff so I don't know what
formats already do this..

> I'd suggest having a very long look at Tk (with Perl or Tcl as a
> scripting language) as it allows access to a powerful GUI without
> having to spend ages fiddling with C...

I definately shall look at Tk.. Thanks for pointing me to it.. If you'd
like to help out, feel free to start making contributions.. At this point
my net resources are fairly limited, but hopefully I will be getting them
improved soon.. I don't know exactly where would be a good place to house
this project.. Know of anyone?

Jim

 
 
 

A plan for ending Micro$oft's reign

Post by Mark R. Andrachek J » Wed, 19 Jul 1995 04:00:00


An app I'd like to see would be an enhanced seyon, with support for
ansi-bbs and other terminal types. Or if someone felt like porting
procomm plus for windows to linux that be nice tooo..... :). Seyon's
good, but I'd like more than just an ascii terminal.

Also, dip can be a bit confusing. I'm no programmer, but how hard
would it be to write an xapp that would take in the user information
in fields, kinda like trumpet, with a help menu, that would then
translate the fields to the appropriate areas of dip?

I need to learn C, a little basic and fortran just don't cut it these
days.

I don't like the idea of a program manager in the windows 3.1 sense.
I like having the full desktop to work with, as in Win95, etc., and
an easy to use installation routine would be nice too.

Just my $.02,

Mark Andrachek, Jr.

 
 
 

A plan for ending Micro$oft's reign

Post by Jim Phillip » Thu, 20 Jul 1995 04:00:00




> : I'd like to see someone compile a list of the different suggestions that
> : have sprung up as far as just WHAT applications are needed..  A WYSIWYG
> : word processor is a must.. But we've already got that in Andrew (I didn't
> : really like Andrew all that much however)..

> Andrew? Is that some sort of word processor for Linux?

Well, actually Andrew is a suite of applications.. One of which is a
WYSIWYG Word processor.. I found it very bulky and unusable though.  
Other people may have different opinions about it..

        Jim

 
 
 

A plan for ending Micro$oft's reign

Post by Stephanos Ormr » Thu, 20 Jul 1995 04:00:00


: I'd like to see someone compile a list of the different suggestions that
: have sprung up as far as just WHAT applications are needed..  A WYSIWYG
: word processor is a must.. But we've already got that in Andrew (I didn't
: really like Andrew all that much however)..

Andrew? Is that some sort of word processor for Linux?

Steven

--


     ____
    /   / /    ___  __     /         __
   /---- /__  /  / /_/ /--/ /^- / / /_
  /     /  / /__/ /__ /__/ /   /_/ __/

      GCS d- -p+ c++ l+ u/- e+/* m-/* s+/- n- h/- f++ g+/- w+++ t++ r-- y+

             Designated Drinker of San Marcos, Republic of Texas

 
 
 

A plan for ending Micro$oft's reign

Post by Edmund H. Ra » Thu, 20 Jul 1995 04:00:00



Quote:>An app I'd like to see would be an enhanced seyon, with support for
>ansi-bbs and other terminal types. Or if someone felt like porting
>procomm plus for windows to linux that be nice tooo..... :). Seyon's
>good, but I'd like more than just an ascii terminal.
> [...]

   No, no, no! One reason I use Linux is that is doesn't force me to use a
GUI. I decidedly wouldn't want Linux to become like (what horrible thought)
M$-Windows or anything like it. I find GUIs offensive, as they tell me I am
so dumb I can't remember a few hundred commands and have to be shown simple
coloured pictures instead. They also assume I'm malformed. But if I really
had three arms, I'd not be sitting here at my terminal, I'd probably be
engaged in some circus show.

   rgds, Eddi
--

               Linux/m68k, the best U**x ever to hit an Atari!
    Distribution of this message via the Microsoft Network is prohibited

 
 
 

A plan for ending Micro$oft's reign

Post by Jim Phillip » Fri, 21 Jul 1995 04:00:00



Quote:

> An app I'd like to see would be an enhanced seyon, with support for
> ansi-bbs and other terminal types. Or if someone felt like porting
> procomm plus for windows to linux that be nice tooo..... :). Seyon's
> good, but I'd like more than just an ascii terminal.

That would be a possibility.  Actually though, seyon could be patched to
use the vga font that comes with DOSEMU which contains the DOS-ANSI
character set..  It wouldn't be too difficult to set that up..  But
you're right, a comm program with a bit more functionality would be nice
(like maybe built-in fax support)..

Quote:> Also, dip can be a bit confusing. I'm no programmer, but how hard
> would it be to write an xapp that would take in the user information
> in fields, kinda like trumpet, with a help menu, that would then
> translate the fields to the appropriate areas of dip?

dip is designed as a script parser, so there would always be some degree
of writing scripts.. I think twinsock probably has some degree of this as
well, but a xutility to aid in the configuration of the dip server part of
it would be real nice..

Quote:> I don't like the idea of a program manager in the windows 3.1 sense.
> I like having the full desktop to work with, as in Win95, etc., and
> an easy to use installation routine would be nice too.

We've pretty much already shied away from the win3.1 program manager
design. A full desktop is what I at least am looking at..

Quote:> Just my $.02,

Your change sir..

Jim

 
 
 

A plan for ending Micro$oft's reign

Post by John M. Morr » Sat, 22 Jul 1995 04:00:00



: That would be a possibility.  Actually though, seyon could be patched to
: use the vga font that comes with DOSEMU which contains the DOS-ANSI
: character set..  It wouldn't be too difficult to set that up..  But
: you're right, a comm program with a bit more functionality would be nice
: (like maybe built-in fax support)..

Sorry, but other than the fact that both faxing and telecom involve
the modem, what other things do the two tasks share in common?  Since
you feel this need for one big bloated do-all program, could you share
your vision?

Not really trying to flame ya, but hoping to rattle your cage enough
that you will start thinking.  It takes awhile for us ex-windoze/
ms-dog users to adjust to the *NIX way.  One of the major ideas of
which is: Don't build one large tool to do the same job as two smaller
ones, since it is much easier to switch out one of the smaller ones
for something better.

: dip is designed as a script parser, so there would always be some degree
: of writing scripts.. I think twinsock probably has some degree of this as
: well, but a xutility to aid in the configuration of the dip server part of
: it would be real nice..

Check out Yggdrasil Plug & Play Linux.  It has exactly that, plus
simple fill in the dialog box setup for printing and pulling a
newsfeed.

John M.                  This post was 100% M$ Free!

 
 
 

A plan for ending Micro$oft's reign

Post by Jim Phillip » Sun, 23 Jul 1995 04:00:00



>    No, no, no! One reason I use Linux is that is doesn't force me to use a
> GUI. I decidedly wouldn't want Linux to become like (what horrible thought)
> M$-Windows or anything like it. I find GUIs offensive, as they tell me I am
> so dumb I can't remember a few hundred commands and have to be shown simple
> coloured pictures instead. They also assume I'm malformed. But if I really
> had three arms, I'd not be sitting here at my terminal, I'd probably be
> engaged in some circus show.

Nobody ever said you had to use a GUI, but there are plenty of people out
there who do like them to some extent, and this is for them..

Jim

 
 
 

A plan for ending Micro$oft's reign

Post by Donal K. Fello » Wed, 26 Jul 1995 04:00:00






>>> * The GUI isn't simple enough.

>> X has several GUIS, all of which can be used at the same time...

>You confused me here.. What is your definition of a GUI?  I was referring
>to X in general.. Although I guess I'm really saying X with FVWM since
>that's the combo I use..

A GUI is all those things like buttons, menus, scrollbars, etc. A
mouse pointer and graphics does not constitute a GUI!

XView is a GUI. Tk is a GUI. The Athena Widgets (with Xt) form a
GUI, as does Motif when combined with Xt.

Quote:>>> * Built in Multi-Media: The ability to add new formats to the media
>>>   player is a major plus.

>> Have some central server which knows how to start and control media
>> players, with a nice and simple text configuration file.

[ Munch ]
> But since it's obvious there will be debate about this, and
>that is something I wish to avoid wherever possible, there's nothing says
>we can't use some sort of mailcap file maybe have either a line saying
[ Munch ]

>either way is just as extendible technically..i prefer the former, some
>may prefer the latter..

A mailcap file would be the sort of thing I had in mind (either apps
could have the code in to understand it themselves, or they could pass
messages to a central server which understood things for them) except
that we'd probably want to have more than just a view command for each
file type in the file (at least an edit command as well)

Quote:>>> * A new Window Manager.  Many of the features of fvwm would be
>>>   useful, and in fact it could be used as a foundation for
>>>   this project.
[ Munch ]

>> fvwm would be better if (IMHO) it didn't look so much like mwm. XPMs
>> for title bar buttons, and shrink titles would be very nice. But apart
>> from that, fvwm is very good.

>What would you suggest it look like??  One feature I was considering
>putting in was the ability to allow the user to custom configure his/her
>own look (using xpms would be a plus here).. For instance give them some
>kind of basic drawing tool that can create and modify certain widgets..
>that way although it would still retain the functionality this standard
>provides for, it doesn't have to stick to some rigid layout specification..

Have a look at

  http://www.cs.man.ac.uk/~fellowsd/twm.look.gif

This is a window under a fairly heavily customised tvtwm.
Unfortunatly, the wm is so bugridden that I wouldn't recommend it to
anyone else. Fvwm is better, but it doesn't support my preferred look,
so I don't use it.

Quote:>>> * A programmers' toolkit.  It would contain easy ways to do things
>>>   that both Motif and XView left out.  Such as toolbars, pull
>>>   down menus, OLE, drag-n-drop, multi-media functions, etc..
>>>   Basically all the different specifications of this standard.

>> I think that a way to create applications without having to delve into
>> C would speed app development massively...

>A sort of Visual C for X would be nice..  Or for that matter, simply a
>development package which lets you edit, compile, run, and trace/debug a
>program all at once would be handy..

Motif has menus and drag-n-drop, and toolbars are trivial (virtually
all my apps have them, at very little development cost). Persuading me
that C programming can be good under any circumstances (where
performance is not a key factor) is an uphill task...

- Show quoted text -

Quote:>>> * Applications that can follow both this standard, and still retain
>>>   the ability to run without it.  Programmer's would be
>>>   encouraged (but not forced) to write programs that would
>>>   use all the features the new standard provides for (ie. OLE,
>>>   drag-n-drop, on-the-fly config, toolbars) which would still
>>>   be able to operate without this "library".

>> That sounds like static linking to me... :^(

>You're right here.. As I've thought about it, this does seem a bit
>silly.. Shared linking will be a definate bonus.. If a developer wanted
>to distribute source code and then have it statically link in a library,
>the user will first have to get that library.. And if they get that
>library, then the developer might as well use shared linking.. *shrug*
>the ultimate paradox.. :)  Oh well.. This will be a great use for ELF..
>And it'll allow commercial developers to make one binary and distribute it..

I'm all for commercial development for Linux. (Heck, I wouldn't mind
even _M$_ building their apps for Linux. Not a cat in Hell's chance of
me ever buying them though... :^)  But I don't want this to be the
only way.

All you need to do is to get the distributions to include your
library. Then there won't be any problems with availability (everyone
will have it :^) so everyone will be able to dynamically link against
it.

Quote:>>> * Printer Interface

>> Generate postscript, and rely on having ghostscript to hand where the
>> printer won't take it native...

>Once again, I'd rather not rely on ghostscript to contain the drivers for
>converting ps into device-specific formats.. That means that we have to
>rely on ghostscript to keep up to date with new printers.. Better to be
>able to allow the printer manufacturers to put out a driver.. Besides, in
>this instance, most people are only going to need one driver instead of
>having 30 or 40 they're not going to use..

What you want then is Ghostscript with loadable output drivers? I
suppose it could be done. GS has the advantage that it makes the print
engine exactly the same as the document preview engine (unless you are
rich enough to have a REAL printer :^)

Donal. (darn, this post is still too long...)
--
Donal K. Fellows, (at work)          |  Donal K. Fellows, (at home)
Dept. of Computer Science,           |  6, Randall Place, Heaton,
University of Manchester             |  Bradford, BD9 4AE
U.K.      Tel: ++44-161-275-6137     |  U.K.          Tel: ++44-1274-401017

-------------------------------------------------------------------------------
           See my home page at   http://www.cs.man.ac.uk/~fellowsd/
  My WWW pages are now available by mail. Send mail to me with the Subject:
                      WWW-Mail: whatever_URL_you_want

 
 
 

1. The Beginning Of The End For Micro$oft Reign Of Terror



http://newsforge.com/newsforge/02/06/14/1316203.shtml

"In a move that appears to be a coup for Michael Robertson et al,
Wal-Mart's online store is offering eight different Microtel PCs with
LindowsOS included. The computers sell for USD$299 to $599 and ship in
one to seven days."

This is actually quite an interesting move. It'll be even more
interesting if these systems show up at retail locations. Promotion of
non-Windows systems by large retailers represents an end-run around the
major OEMs (who are all in Microsoft's pocket, of course). If this sort
of thing catches on, it's not too hard to imagine normal user types
actually walking out of stores with Linux boxes. That sort of thing
would spell big trouble for Microsoft.

[removing totally irrelevant newsgroups, adding linux.advocacy]

--
Right now the Internet gives an awfully good imitation of providing superhuman
intelligence capability, both in terms of the total hardware that is out there
and the fact that the 'net has all these human-equivalent peripheral devices
called "users" that can be appropriated in a distributed way to attack problems.
                    --Vernor Vinge

2. fvwm95 / Desktop / FvwmBanner / Taskbar (A few Questions)

3. dsniff under AIX

4. Micro$oft Reign Of Terror

5. termcap or terminfo

6. Why winUsers don't use Linux (Re: The Beginning Of The End For Micro$oft Reign Of Terror)

7. Restricting processcreation on Solaris 2.6./ CGI-wrapper.

8. HELP--MICRO$OFT WORKS WHILE LINUX DOESN'T--LET'S FIX THAT

9. End to Gates' Reign?

10. Micro$oft exec says all os's insecure ... forgets about VMS!

11. Micro$oft Internet Exploder: Let's stay with Netscape -

12. Micro$oft Intellimouse (ps/2 version) - middle button doesn't work