Choice of toolkits concerning "typical" vs. Debian Jr. CDD

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

Let's move this to debian-custom, as it really has more to do with CDDs in
general than Debian Jr. in particular.

On Tue, 24 Apr 2007 08:25:24 +0200 (CEST)
Andreas Tille <tillea@rki.de> wrote:
> Why?

You asked here why I say metapackages work well for me.  I don't really
know what to say.  I simply have not had any trouble with them that
seemed worth the effort to change.  At various times in the project I
thought a change was needed, but at this time it works well enough, is
simple to look after, and none of my users are telling me "look, this
really doesn't work well at all".  So, why not?

> Well, doing per-user changes is more than a CDD can cope with.  It is
> just the work of a local administrator - at least if I understand you
> correctly.

Precisely.  Observing my own family, I have found that the work of a local
administrator is mostly what is required to keep a system flexible and
meeting the needs of all individual family members.  Forcing one set of
choices globally on the whole family would be the BOFH approach.  It might
make sense for a workplace, a school or other environment where a system
is tailored for one particular purpose, but the home is quite different.
In the home we have leisure time to spare, time to pursue enjoying the
Debian system in all of its glorious adaptability.  I can see the logic in
creating an /etc/junior/skel as a starting point for this journey, but not
in making debconf and /etc changes that force one set of choices on all
users.  Even in cases where our users have the luxury of devoting entire
systems to use exclusively by children, who is to say that our own choices
will reflect the choices of all parents?  For instance, while I find the
Disneyfication of systems for children repugnant, and therefore have a
bias to make a distinctively different Debian Jr. system in opposition to
this popular trend, whose interests would this really serve: my users, or
my own?  I recognize the diversity of values in the families out there
who might use Debian Jr.  One family wants filtering, another doesn't.
One objects to the mild gore xpenguins, another doesn't.  I can choose
some "safe" defaults for the starting point, but I would rather leave as
many options open as possible, making it clear to the children's
administrators that it is up to them to assist each child in solving
their problems in a way that jives with their own values and that is
sensitive to their particular needs.  To have this flexibility,
individuation not only from family to family, but from member to member
within the family is essential, and that means per-user customization.

> I'm afraid I do not fully understand your concerns and I even don't
> know what you regard as "typical" CDD and what the differences are
> between this typical concept and Debian Jr.   Could you try to be a
> little bit more verbose to let me understand the problem.  My concern
> is that if there is only _one_ "typical" CDD that uses cdd-dev than
> the word "typical" is not used apropriately and this is my concern.

Debian Jr.: a home system with a default package selection and some
initial default child's accounts settings which then are modified by
the administrator to suit their child users as they grow according to
their own tastes and values.

A "typical" CDD: a Debian system devoted to some particular purpose,
tailored by the CDD project to meet those particular needs, where the
choices of the CDD project will meet the majority of the needs of their
users.

It is not that Debian Jr. does not qualify as a CDD, but I actively
avoid making choices for the children and administrators as much as
possible, preferring instead to keep them well informed about issues
and equip them with suggestions for solving their own problems rather
than solving them for them.  So yes, there is a subtle difference of
philosophy here that calls for a difference choice in technology to
support it.

> IMHO there are two reasons:
>    1. If all CDDs have so different needs that there is no chance to
>       base them on a common toolkit, it makes no sense to continue
>       development of cdd-dev.

That is a large extrapolation from my argument.  I have singled out
Debian Jr. as different not because I believe *all* CDDs have such
different needs, but because of a difference of philosophy that has
grown in my mind over the past seven years to the point where I now
recognize that somehow my project doesn't quite fit the mold.

>    2. The toolkit cdd-dev is just not flexible enough and has to be
>       enhanced to enable more CDDs that will justify the attribute
>       "typical".

Since you started out saying "doing per-user changes is more than a
CDD can cope with," and I have said that making a Debian system truly
work well for a child has very much to do with making per-user changes,
I don't see what changes to cdd-dev would make it more suitable for use
by the Debian Jr. project.  That is not to say that none of the issues
that CDDs face are of any relevance to the Jr. project anymore.  On the
contrary, we still have:

- an established identity as a distinct group that our users can come
  to for support, that cares about their needs and works within Debian
  to meet them;

- a selection of packages chosen to be suitable for child users (handled
  in the project by metapackages, with some notion to also use debtags
  more intelligently, and perhaps to revisit tasks again);

- a live CD / install CD, which most CDDs have and which we are
  currently implementing built on the work of the Debian-live project;

- a growing documentation base (mostly in form of the wiki at the
  moment, with much more material available to us to fill it out from
  the collected wisdom of our users over the years in our mailing
  list archive);

- developers who care about the packages we have selected for our
  users, who keep them in good shape and work actively with upstreams
  to improve them.

I could go on.  With little to no technology here that is specific to
CDDs, the project does very well to adhere to the core ideals of a CDD.

> That's why I'm keen on hearing your opinion about the differences
> you see to decide whether reason 1. or 2. applies.

In summary, neither applies.  Concerning 2, I am sure quite a number of
CDDs could use cdd-dev.  I am not sure why they have not.  There does
seem to be quite a lot of re-inventing of the wheel happening here, but
this is not altogether unsual for Debian in general.  How and why any
given package gets attention while other, arguably better designed
packages get relegated to the sidelines continues to be a mystery to
me.  It seems to depend not only on technical excellence, but also on
good fortune and the whims and fashions of the day.

Concerning 1, I support your efforts with cdd-dev and wish you well.
I know you put some effort into the initial cdd-dev conversion of the
Jr. metapackages and am sorry we never did use it, but what at the
time you did it was probably 90% neglect on my part and 10% doubt
about whether the toolkit was going to truly meet our needs has now
been dramatically reversed: Debian Jr. is no longer being neglected,
and I am now firmly resolved that the technical choices we have made
are sufficient for our needs.  The rest of the work of the Debian Jr.
project will plot a course that veers slightly off from that of the
"typical" CDD, while at the same time holding in common with them a
shared strong sense of our core principles: that to make Debian work
for a particular user population, you need not fork Debian, that
everything can and should be done within Debian itself, and that in
the end, a CDD is all about doing our best to uphold the social
contract with our particular users, not about the particular
technologies chosen to do that.

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