Re: SEUL: Is it too soon for me to comment?

[Erik Walthinsen <omega@omegacs.net>]

> 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.  :)
Cool!  Welcome!

> Is this a moderated list?  Hope not, I'm about to Comment(tm).  :)
Nope, the more the merrier!

> I think that should be the mission statement.  "My Mom needs to use this."
> :)
Advertising slogan, yeah.  We already have the beginnings of a missions 
statement, which generally is more technical.  However, I can see the TV ads 
now: 20's guy walks into a computer store looking for a computer for his
parents.  Salesguy walks up, and directs him towards a machine running
Windoze.  "Sorry, it needs to be running SEUL.  My Mom needs to use this."

;-)

> 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. :)
When I first got around to relearning Unix four years ago, after an absence 
of 4 years from Domain/OS (from Apollo, now HP/Apollo, kindof sortof Unix), I 
deferred it for quite a while specifically because of arcania like vi.  I'm 
now passably conversant in vi, but I still hate it. <asbestos>Pico!</asbestos>

> I doubt this.  Right now very few people use Linux for anything serious.
> Students, ISP's, a smattering of scientists, and distribution maintainers.
But that's the goal of the project.  This does not have to stay this way.

> Millions of people use it for hobbies, for learning, but not for preparing
> their end-of-month reports or balancing their checkbook.
Precisely why Windoze is not for them.  Given a completed SEUL distrib, 
Windoze will seem arcane in comparison.  I hope.

> Until a few more components drop into place, Linux won't bulldoze
> Microsoft anywhere.
We're here to get those components in place.

> 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. [...] All the user has to do is
> click yes on the license agreement.
That, of course, assumes we can ship all the pieces.  One benefit of RPM is 
that you can build srpm's without all the source files being included.  That 
way we can include everything allowed, and grab the rest off the net the 
first chance we get.  I know, this doesn't work for users who may not have a 
net connect of any kind, but given the licensing, it's better than nothing.  
In the case where we *can* include everything, we just do an `rpm -ba 
xanim.spec` and be done with it.  Given appropriate background methods 
(including semi-synchronous writes), this can be done without the user even 
having to wait for it (unlike similar things in Windoze).  If they really 
want to get it done quick, they can 'maximize' the build window and watch it 
chug along, now at a higher priority.

> It still yields terrible throughput
I've always found Linux PPP far superior to Windoze as far as throughput.  It 
has much better handling of all the various aspects of the serial line and 
protocols than M$ could ever hope to write.

> 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.
Very cool idea!  Someone want to take this one?  Like he said, it'd be a 
one-day project, maybe two.

> 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.
I agree, but consider the fact that SEUL will come with full-scale 
applications (office-style stuff) included.  Windoze, lacking any real 
functionality in the base install, is trivial to install (er, you know what I 
mean...) for that very reason.  SEUL, with much more flesh on its bones, will 
be harder to deal with.

> 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.
Certainly, but it still doesn't solve the whole problem.  We'll need some 
mechanism for backtracing through a package's requirements to find 
everything, possibly scanning through major 'net archives, if possible.  
Given 'official' archives, with version control and so on, this is possible, 
and PGP signatures make it safe: "Do you trust seul.org?"  If they reply yes, 
as they actually should have to in order to even install the system in the 
first place (maybe), they can then install stuff from ftp.seul.org or 
anywhere else without worrying.  Netscape does that, it's pretty cool 
actually.

> If we insist on staying redhat-based, then we should distribute pre-built
> kickstart disks.
Do you mean 'kickstart' in the hurricane sense, or do you mean boot disks?  
Either way, we'll quickly change the structure of them quite radically.  
RedHat's install is cool, but it won't cut it for end-user installs.

> I don't recommend staying redhat based.
You'll have to clarify that somewhat.  Do you mean we should start completely 
from scratch, or do you mean start with redhat and diverge, never to resync?

> 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.
Amen!  I didn't even think about the fact that it's changing quite rapidly to 
keep up with the bleeding edge.  You're right, that is something we'll have 
to be very careful with.  Once we find something that's stable, we should 
stick with it.  Newer versions aren't always better.  Luckily, the 
combination of RPM and our CVS repository will help us immensely when it 
comes to dealing with these issues.

> 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.
hehehe...  There are fixes for that, but they probably involve changes to 
both conf.modules and the source for any given cd player.  Note that this is 
a big issue: if we start tinkering with stuff to make it work just right, 
whether it's just right in general or just right for SEUL, we end up with a 
set of packages that are tied to SEUL, and everything else, well, YMMV.  
Hence the need for two things: exhaustive documentation of *everything* we 
change, down to the slightest little gotcha, and some method for validating 
packages that aren't distributed by ourselves.

> 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).
Well, "my computer" is kinda flaky, there are better metaphors to use, IMO.  
But yeah, a couple good file managers (so users can choose an alternate if 
they get tired of the standard, *and* figure out how to switch [should be 
very easy]).

> 9) We need a tech support structure.  Just like Microsoft has and Red Hat
> is trying to provide.
By far the hardest of them all.  I haven't even thought much about how to do 
that yet.  Will one of these days... :)

> 10 through 185) For (far) down the road, we should try and build a better
> Windows emulator.
[ snip ]
A good idea, but as you say, it would be painfully slow.  The only really 
good way to do it would be to throw a limited AI engine at the asm, figure 
out roughly what it's doing, isolate things very carefully, and maybe even 
'recompile' it into an ELF binary with calls to similarly recompiled DLL's... 
Sounds messy, and probably not feasible, so I wouldn't hold my breath.

I agree that people aren't gonna switch unless they can be assured that their 
apps will work, but there's only one way to do so realistically: get enough 
Linux users out there who aren't tied to legacy apps to pressure companies 
into porting.  Then legacy apps become available in native versions, and 
presto!, you're problem goes away.  And there are relatively trivial ways to 
get a Windoze program to compile for X.  TWIN is a library from Willows 
(http://www.willows.com) that does just that.  And it's GPL'd!

> People should never need to directly edit a config file.  Another place
> red hat has made great strides.  Are their tools GPL'd?
Yeah, they're GPL'd.  PHT did TurboLinux (a hacked version of RedHat) and 
included (and modified I think) their tools.

> Microsoft's "Wizard" idea is perfect (even MS can't get everything wrong
> ;) ).
True, M$ does have some good ideas.  The wizard idea is something that I'd 
like to implement in the context of our help system, which even have a
working proof-of-concept prototype of!  Some of the stuff I've learned in the 
last week (including most of Perl) will be very useful in making structural 
adjustments to the concept, and make it a perfect system for mixing help, 
control-panel, and wizard stuff all in one.

> 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.
That was me... :)  I'm now of the mind that it should definitely be a 
separate distribution, with no intent of merging with the current/future 
RedHat distribution.  However, I would hesitate to divorce ourselves
completely from RedHat.  When things stabilize, and we are ready to upgrade, 
we will most likely turn to the latest stable RedHat release for a starting 
point, especially if we were to be moving from libc5 to glibc2 ourselves.

The issue, however, is what happens when we make significant changes to the 
structure of the system.  RedHat's packages no longer become useful, so we're 
on our own.  Doing this with the whole system would be a nightmare, though 
not unmanageable.  I think I'd prefer to keep somewhat in sync with the 
latest stable (still 4.2 at this point, IMHO) release.

As far as RedHat "taking us under their wing", this would probably be a bad 
idea.  If that were the case, a decision would have to be made whether to 
keep SEUL and RedHat separate distributions, even though 'sold' by the same 
company.  And we'd have the issue of who has control over the project.  If 
RedHat were to handle SEUL, perhaps even hiring some of us, we would then 
have bosses, and they theirs, and we no longer have control.  I'd hate that, 
personally.  That's why Linus works for Transmeta, not RedHat (nothing 
against RedHat, really!  but that's just what happens).

> 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... :)
Long hours they be.  Not much longer, however, as I start school tomorrow. :(

TTYL,
    Omega

     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user