Re: SEUL: Observatons

[Michael Peck <mjpeck@mailhost.rsn.hp.com>]

jfm2@club-internet.fr wrote:
> 
>    From: Micah Yoder <yoderm@geocities.com>
>    X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i486)
> 
>    jfm2@club-internet.fr wrote:
>    >
>    > I disagree. The fact is than the VGA server will run with *almost* any
>    > card.  But not all.
>    > There are PCs with NVidia Cards (correct me if I am wrong but that is
>    > a modern card) that won't run with the VGA server.  They will run with
>    > their specific server however.
>    > And there are other cards where the VGA server will only support 320x200.
> 
>    [snip]
>    >
>    > Also 8 meg machines will have a hard time with an X based install.
> 
>    OK, points taken.  Curses it is!
> 
>    > Sorry but here in France day time phone rates for local calls are
>    > about 15 cents for three minutes.  Downloading 100 or 200 megs over a
>    > modem is not viable here.  So until France becomes one of the United
>    > States of America :-) I vote against that.
> 
>    Ouch.  Anyway, I didn't intend for the user to download EVERYTHING that
>    way, only certain software packages that they pick from a list.  Most of
>    the ones they'd want will be included on the CD, but of course, there
>    will be more, and we'll always work to make new things SEUL friendly and
>    put them in "the list".
> 
> Upgrading from the net is a viable proposition at least for small
> packages (Emacs, XFree, XEmacs are definitely out), but a half decent
> Linux installation needs at least 200 Megs of software, that means 100
> Megs once compressed.
> 
> Someone made a software for RedHat than will scan an FTP site and
> upgrade automatically if it finds something newer than whet you have.
> It could be hacked a bit for putting a limit on the size of the
> paxkage.

Not.

There should be two pieces:

1) a tool that retrieves packages from a server in an intelligent and
simple way, and installs them.

2) a tool that installs and configures packages.

This way, no matter how the user gets the package (intranet, CD-ROM,
etc.) it can be installed and configured without going through some
convoluted "retrieve the package" process.

Putting a limit on the size of a package would be patently foolish. It's
not simple, it's not consistent, it's not complete. It's just a
worthless restriction.

Now if you mean that in order to aid automation, rules of size should be
configurable, that's another matter entirely. But it's more complex than
just setting a size ceiling; critical packages would be missed based on
their size while smaller, less-useful, packages would be downloaded
instead.

I personally think software installation should be a two-step process --
that can be shortened to one step. Keep package retrieval and package
installation/configuration separate, as they are for most other
platforms, and offer the ability to do it in one fell swoop. This last
ability should be reserved, however, for high-bandwidth intranets, where
configuration information can be stored on the central server.
Otherwise, automation is fairly useless, and more distracting than
helpful.

This would go well with a sort of "installation/configuration engine"
model. Packages can be stored alongside a configuration script that
tells the installer/configurator how to set them up in conformance with
a company/intranet standard.

MJP
-- 
Michael J. Peck
Hewlett-Packard, Convex Division
mjpeck@convex.com
Opinions expressed above are not necessarily those of my employer.
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------