[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SEUL: Is it too soon for me to comment?



Hi.  I'm new to seul.  I want to help!  I'm a passable coder, a passable
web designer, a passable ISP ;) and one hell of an evangelist.  :)

Is this a moderated list?  Hope not, I'm about to Comment(tm).  :)

On Sun, 4 Jan 1998, Erik Walthinsen wrote:

> On the other hand, consider Windows, and the type of user you find in front 
> of such a system.  I will use the example of my mom.  She just recently got 

I think that should be the mission statement.  "My Mom needs to use this."
:)

> Had I started her out on a system where she would be presented with an xterm 
> showing vi, she would have stopped right there.  Were I to succeed in getting 

If *I* were presented with an xterm showing vi, I probably would have
stopped right there.  I'd rather have ed.  At least ed has a ? command. 
But I digress. :)

> that my mom is.  If we can reach the other 95% of the market, Windows
> ceases to be an issue, as I have zero doubt that Linux can bulldoze
> Microsoft out of a significant (hopefully >50%) share of the PC OS
> market, with a little work. 

I doubt this.  Right now very few people use Linux for anything serious.
Students, ISP's, a smattering of scientists, and distribution maintainers.
Millions of people use it for hobbies, for learning, but not for preparing
their end-of-month reports or balancing their checkbook.

Until a few more components drop into place, Linux won't bulldoze
Microsoft anywhere.

1) We need more end-user applications.  This is the biggest stumbling
block if you ask me.  Right now, there's Netscape, a couple of Java apps,
Applixware, Quake, and Mathematica.  Most of the 'traditional' scientific
apps that Unix users run don't exist, most of the 'traditional'
productivity/management apps that Windows users run don't exist either.

2) We need better fault tolerance.  Installations in particular.  Red Hat
is as guilty here as anybody if not more.  One wrong move and your whole
install has to be done over.  This is a Bad Thing.  We should probably
also do things like turn on synchronous disk writes by default like
freeBSD does.  One thing SEUL will have to do is get away from the typical
Linux mentality of 'squeeze everything you can get out of the system' and
instead adopt a mentality of 'make it work, right, the first time,
everywhere'.  There will be users who will just turn off the computer.
They can't hose their data in the process.

3) We need better PROGRAM INSTALLERS.  I think an effort should be made to
even automate the installations of programs which aren't freely
distributable.  For example, take the saga of Java on Red Hat 5.  It's
completely and totally broken.  kaffe doesn't work properly, the libraries
are all messed up, and the JDK can't be distributed because of licensing.
xanim is pretty well in the same boat.  You can distribute xanim, but you
can't distribute an xanim that can actually play animations.  These are
just two examples.

Although the programs themselves cannot be distributed, an installer
written by us could.  An installer that would log on to the network,
retrieve the applications, compile or patch them if necessary, and install
them.  All the user has to do is click yes on the license agreement.
Could do this with perl and TCL/TK, probably.

4) We need better dial-up networking.  If Linux wants to have any chance
in the home market, or even in most of the business market, there has to
be a click-and-play dial-up networking.  Red Hat has made lots of progress
in this area.  It still yields terrible throughput, takes all day to
install, doesn't work half the time, and generally is inferior to Windows'
version.  DIP, chat, etc. are adequate.  The configuration is hard.

Ideally, a system that could take a windows' DUN-script and translate it
would be ideal.  Not too hard, either.  Could probably be done in a day
with perl.

5) We need simpler installs.  I think that Red Hat has made some advances
in this area, but there's still a lot of complexity in the install.  It
takes half an hour just to select your packages.  That's if you know what
you want.  And if you pick 'install everything' it breaks.  Windows takes
five minutes, less if you just pick 'typical'.  We need a similar setup.

Also, we should distribute the 'devel' version of every package that's
installed, by default.  There's nothing more annoying then having to go
find libraries.  Especially for a newbie.

If we insist on staying redhat-based, then we should distribute pre-built
kickstart disks.  I don't recommend staying redhat based.

5.5) The Reason For Our Own Distribution.  Frankly, redhat has different
goals.  Redhat's concerned with building a system that can be used by the
typical 'linux user'.  This isn't our target.  Red Hat may have the best
online support, the most updated software, things important to modern
linux users.  But their distribution has other concerns.  It needs to be a
functional server.  It needs to be multi-platform.  It assumes the user is
willing to work to solve problems that may crop up.  It needs to have a
decent development environment.  It needs security.  We don't need any of
this.  We need ease of use, superior reliability, and backwards/windows
compatibility.  They focus on this too, but not as much.  Consider glibc,
and indeed the libc problems that have plagued redhat since the ELF
transition.  And sometimes redhat makes changes that break things.
Consider glibc. :)  We may not have the time, effort, or inclination to
keep up with their changes.

6) We need to not break things.  For example, Red Hat 5 glibc breaks all
kinds of things.  Simple things like Netscape need to work.  With their
Java interpreters.  Without tricks, wrappers, and environment variables. 
This should be one of those 'specialty installers' like I mentioned
before. 

7) We need modular kernels that aren't obtrusive.  I don't know if it's
just me but there's nothing more annoying than having kerneld unload my
CDROM driver while the CD is playing.

8) We need a "my computer" equivalent.  FVWM95 looks like Win95 but it
sure doesn't act like it.  A good file manager is a first step toward the
"no command line" motif (no pun intended).

9) We need a tech support structure.  Just like Microsoft has and Red Hat
is trying to provide.

10 through 185) For (far) down the road, we should try and build a better
Windows emulator.

<digression>

A Windows emulator a la Executor, not a Windows emulator a la Wine. 
Executor is a Macintosh virtual machine.  It interprets or JIT-compiles a
Mac program to run under Windows or Linux.  Their virtual machine was the
easy part and works perfectly, according to their own documentation.  The
MacOS-compatible layer is the hard part, and it still doesn't work
properly. 

We can expect, courtesy of MS marketing, that every computer in existence
will have a legitimate copy of Win95.  This is a luxury that the Executor
team did not have available to them.  An x86 interpreting virtual machine
could provides a virtual machine with com ports, a generic video card, a
generic disk driver, a generic sound card, a generic network card, and
that's all.  It would simply be a translating layer between what windows
likes to see and what the Linux facilities for these things already are. 
One which functioned by interpreting rather than natively running x86
instructions, would not suffer the pains of DOSEmu in dealing with IRQ,
DMA, memory protection, etc.  Basically we reinvent a different wheel.
:)  A look at the Kaffe source and how they do things so quickly would be
most helpful.

The advantage to this is that users can just run Win95 in their happy
virtual machine.  The pains of Wine in figuring out and implementing the
API are avoided.  And it's immune to anything Microsoft might try to do to
break emulators, as happened with Win31 and DR-DOS.

The disadvantage, of course, is that it's as slow as the seven year itch.
But my guess is it would work with a lot less effort.  There's already
8086 emulators.  We just have to make one that looks like a 486 or Pentium
instead.  :)  We'd need the device drivers, a BIOS layer (maybe could use
the existing PC BIOS) and the CPU emulator.  It sounds easier than
emulating the Windows API.  :)

No corporation and precious few home users will ever to use Linux for
anything they use Windows for now unless they are convinced the transition
and backward compatibility will be easy.  Backward compatibility is
probably 50% of the reason Windows 95 sucks and Windows NT doesn't.  One's
backward compatible and one isn't.  It's also the reason everyone uses 95. 
An emulator that crashes randomly and is always three years behind is not
convincing.  An emulator that runs stock Windows 95 out of the box...
that's convincing. 

</digression>

> Throwing people (indiscriminately or not) into such editors as vi or emacs is 
> the surest possible way to scare people back to the known, "intuitive" 

The worst part is that there are already plenty of freely available
x-windows and text-mode editors that are perfectly 'intuitive', at least
as much as the Windows are.

People should never need to directly edit a config file.  Another place
red hat has made great strides.  Are their tools GPL'd?

Microsoft's "Wizard" idea is perfect (even MS can't get everything wrong
;) ).

> underlying knowledge.  Much more serious changes are required in order to 
> directly compete with Windoze, and it sounds to me that there is a large, 
> vocal group of people who do not want Linux 'polluted' by such frivolities. 

A while ago on this list someone mentioned that redhat might take SEUL
"under its wing" and create a redhat-seul and a redhat-standard
distribution.  Maybe.  I still like having our own distribution.

With a little luck, SEUL can soon compete with Redhat for new linux users. 
The next step is to sink the Bismarck... or maybe just the Titanic.  We
can only look ahead, put in some long hours, and hope... :)