Re: EDU Distro - was Re: [seul-edu] Linux in Elementry

[Ben Armstrong <synrg@sanctuary.nslug.ns.ca>]

On Thu, Aug 23, 2001 at 10:21:15AM -0700, Samuel Hart wrote:
> Actually.... Debian Jr. is one project we are watching attentively. ;-)

Yes, I did notice that :)

> From a personal and technical standpoint, I would make any Linux EDU distro I 
> was in charge of Debian-based.

I've seen Debian-based distros and wondered what, exactly, is so
divergent about what they are doing that it couldn't have been done
better within Debian itself ... except in the case of Corel, where they
dicked with the licensing of some components (but let's not get started
on that ;)

> > I agree, and debconf is designed to be usable in that fashion: prime it
> > with the variables you want to "pre-answer" and then let 'er rip.
> 
> Right, but debconf, in and of itself, is still far too complicated for the 
> average educator to use.

Eh? But ... the "average educator" would not be using it as I envision
it.  I thought you just finished saying you wanted a turnkey solution?
If you pre-configure the distro to pre-answer all those questions, then
they are never even presented with debconf.  It just happens magically
behind the scenes.

> And that's the key... we need to not gear these things (even in the 
> slightest) towards anyone with any technical skill. In my wife's district, 
> even the supposed computer speciallists are rather naive with respect to 
> computers. The installation and maintenance needs to be as simple as possible 
> (actually, two distros, Progeny and Mandrake make great strides in this area, 
> IMHO).

What's the big barrier to implementing a number of Education-focused
install options in tasksel to preconfigure systems for specific
purposes?  Why does the distro half to be a splinter distro derived from
Debian rather than an option selected at install time?

> > Ugh.  Far better to put the effort into making your chosen distro easily
> > "sub-settable" as Debian already is.
> 
> Naturally, from a technical perspective yes.
> 
> But in practicality, the people in the schools who would be installing and 
> using this software will not have the knowlegde  to activate/deactivate 
> these. So, for them, a choice in pre-set distros should be available.

But I haven't heard compelling arguments yet why a "pre-set" subset that
is a part of Debian proper is not possible.

> You're confusing semantics here.
> 
> I never said make a whole new distro *from scratch*. I just said we shouldn't 
> take an existing distro and add layers upon it (such as requiring them to 
> install a RH/Debian/SuSE/etc. distro, and then apply a layer of educational 
> RPMs/DEBs to it.).

Ah, well happily, I think we are saying the same thing, then. :)

> What we (Tux4Kids) want to do is supply schools & educators a Linux distro 
> (probably based upon and compatible with Debian, since maintenance can be 
> easily automated) which will take all the choices that the end-user probably 
> wont know how to answer already decided for them.

I have a slightly different, but in some ways similar goal with Debian
Jr.  I'm not assuming the end-user doesn't know how to answer.  However,
I would as much as possible like to provide some "configuration aids"
(not for Woody, though) that would make setting things up for children
easier.  Just as the "harden task" automates "security hardening" of
Debian, I'd like to give the user the option to either configure
everything by hand (i.e. by debconf dialogues) or to use what the
Debian Jr. group considers to be reasonable defaults (priming debconf
with responses, as alluded to earlier).

> If you offer the schools a choice of distros they can use (each tailored 
> towards specific needs), then it can make entrance into the schools that much 
> simpler.

I don't see that this needs to be any more complex than selecting
tick-boxes in tasksel at install time, if designed properly.

> A standard installation distro would be for those schools who have staff 
> skilled enough to handle the install.

And the big barrier to providing variations on the standard install
within Debian is ... ?

> A bootable CD-ROM distro, while not offering the same functionality (sound 
> would be /very/ tricky, and for maximum compatibility, you must use the SVGA 
> sever, which usually runs slower for the hardware), can be a very QND 
> (Quick-N-Dirty) solution for schools who don't have sufficiently skilled 
> staff.

I can't really comment with authority on this, having no experience with
trying to preconfigure kernels to auto-detect and run on a variety of
different hardware without intervention by the user.  (I assume that's
the problem which is why SVGA is needed, which is the lowest common
denominator?) But I thought XF4 came with tools that guessed reasonably
well which chipset to use, doing away with the need to use the SVGA
server.

> > Not bad looking.  Uncluttered, simple menus (although I really wonder
> > what "productivity" is going to mean to children :)  Further along in
> > the UI department than Debian Jr. is going to be for Woody.
> 
> Actually, this thing was originally based upon Peanut Linux. The WM is IceWM, 
> and we did make our own custom menus for it. Future incarnations of this will 
> likely be Debian Jr.-based.

The Debian Jr. menu effort went through a discussion phase and never got
realized in code in time for Woody, so it will likely not be included.
It's a level of complexity beyond just writing custom menus, as the Jr.
menus would need to be flexible, responding to installation/removal of
other Jr. components, just as the main Debian menu system is itself.  It
also should work across all wms.

> > Debian Jr. is not a distro.  It's an installation option for Debian. :)
> 
> Again, semantics.

But important to remember.  Making a whole new distro is a whole
different kettle of fish as far as I'm concerned because
responsibilities shift.  Even if it is "Debian-based" you now need to
maintain your own BTS, you have to deal with problems that may arise due
to incompatibilities between your offerings and Debian's, and then lines
are blurred around who is responsible for what, because the end-user
doesn't make the distinction, and then sorting out the bug-reports would
be a bit of a chore ... trying to decide what's you, and what needs to
be forwarded upstream to Debian and/or to the upstream authors of
individual packages.

> A CD shipped with a GUI installer hiding the fact that underneath it holds 
> entirely Debian Jr. packages (and with this option pre-set) is the sort of 
> distro I am talking about.

Necessarily GUI?  I think a simple reduction in the number of questions
that a user has to answer would be sufficient.  But again, who wouldn't
want a "simpler to install" Debian?  If you have some good ideas as to
how to do that, why not work with Debian to get them into the
distribution proper?

Ben
-- 
    nSLUG       http://www.nslug.ns.ca      synrg@sanctuary.nslug.ns.ca
    Debian      http://www.debian.org       synrg@debian.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]