Re: Introducing DoudouLinux
First, an apology for my overly-long response. I hope those following
along manage to stick with it and read to the end ... For the rest of
you who are not patient enough, I'll sum up: I find we have a whole lot
more in common than I did at first, and wholly support DoudouLinux
breathing new life back into what started as the Debian Jr. project many
years ago.
On 29/07/11 07:07 PM, Jean-Michel Philippe wrote:
> Another one is that we want to fit a single CD. Our
> first Squeeze build is currently sizing 850MB and we still haven't
> decided how to make it fit 700MB.
This is related to a question that has come up on occasion from Debian
Live users: why aren't there official images to fit CD-sized, and I
think it's worth some careful thought and perhaps we need to develop
some guidelines for people who want to make such a thing. As a Debian
Live developer speaking also from the Debian Pure Blends perspective,
here is some fodder for a draft of such a document. I'd like to get some
feedback from you about it.
- Do not damage the purity of the system for the sake of space savings,
or else you create support problems. For example, one might fully remove
/usr/share/doc and /usr/share/man to achieve some space savings, but
this breaks packages (the file lists say they contain files that they do
not) which could cause future problems (upgrades, package removals,
access to built in Help menu, etc.) If you need this kind of space
savings and it's worth the tradeoff of not having doc on your image, it
is better to repackage to partition the unneeded doc into a separate,
optional doc package that can simply be omitted from the package list
for the image.
- That takes us to the next point: do partition packages with large data
components to include the right amount of data in the image, and get
those changes pushed as far upstream as is appropriate. For example, if
a game is included with a very large, indivisible data component, find
some core data component that still keeps the game entertaining that can
be split from the 'extra' data and co-ordinate
with Debian (better yet, with the game upstream) to have separate
packages for each.
- Do not sacrifice usability by your intended audience for the sake of
space savings. For example, if you turn off automatic install of
recommends, make sure you realize the tradeoffs you're making on a
package by package basis and can live with the resulting decrease in
functionality. You may wish to re-add to your package lists some
recommended packages that you think provide important usability.
- Do ensure dependency relationships affecting footprint of the package
are really appropriate and file bugs as needed. For example, ensure that
every 'Depends' really is vital for the package to operate properly, or
else perhaps it should be softened to 'Recommends' instead.
- Do make metapackages of an appropriate granularity to support
subdivision into smaller parts for N-sized media. (Perhaps -core and
-extra or -full variants.)
One thing I wish Debian Live supported and I'll have to ask the team
about is a simple to use way to specify negative package selections.
That is, if I use Blends metapackages consisting wholly of Recommends,
how do I ensure that those Recommends are installed but *not* specific
Recommends that are too large for our image? If we simply turn off
installation of Recommends, installing such a metapackage will do
nothing. But if we leave automatic installation of Recommends turned on,
the image will be too large.
There are a couple of possible solutions, but neither of which are ideal:
1. Pinning might be used here. Set a -1 pin priority for recommends we
don't want included. My principal objection here has to do with ease of
use: It would be simpler to list in a plain text file the packages we
want to be not included, or have some notational convention used in
package lists to indicate they're not included.
2. Aptitude might be used here. Aptitude supports the notational
convention I've indicated above (suffixing a minus to the package name
says to exclude this package). However, I'm pretty sure that fails with
Debian Live for two reasons. First, we support the choice of install via
apt vs. via aptitude. But second, and most importantly is that the
negative package choice only persists for the current 'aptitude'
command, and since most images are produced by at least a couple of such
commands (one for packages, one for tasks) the exclusions are not fully
obeyed.
> To me it now seems obvious that DoudouLinux CD cannot use Debian Jr.
> package selections as is, but only a subset – because of the CD
> constraint. In the future we intend to offer a multi-language DVD, which
> could use Debian Jr. package selections.
Well, you can see if we had a solution to the Recommends problem, maybe
you could use the Jr. package selections. You would just need to use
pinning, as per option 1 above, to "trim" those selections a bit. But I
would discourage that because of the "Do make metapackages of an
appropriate granularity ..." point, and also because I think the current
metapackages are extremely dated and long overdue for a refresh by
people currently working with children who have a better idea of what
appeals to children from our current offerings. That's where you come
in. Without any technical involvement at all, you could provide the
remnants of the Debian Jr. team (Andreas, me, and anyone else who is
listening in) with metapackage suggestions and it will be a very simple
matter for us to make those changes to the metapackages for you.
> This was also my feelings when I read the Debian Jr. page and certainly
> the main difference in philosophies. Our goal is to reach the standard
> family, which doesn't know anything about computing. Moreover, with the
> emergence of smartphones and their easier interfaces, we believe that
> computers have to change. Finally, we also want to compete with any kind
> of tech-stuff for children, which means we really need to do our best to
> make it attractive.
>
> This is why we want it to be dead easy as gaming consoles or
> smartphones. The question we are still working on is how to lead later
> children into looking at the OS internals while avoiding them asking
> themselves any question about its use. They also have to understand that
> computers are fully programmable, unlike gaming consoles.
Sure. All very valid points, and if you want to work on that now within
Debian, go for it! I can only see good coming out of this.
> I totally agree :). One of our wishes is to provide in the future a
> version for teenagers, another one for families and why not for seniors
> (supposing that we really need to make different versions for these
> audiences). Of course we would reuse a similar simple interface.
Hmm. On our site we have written "By the time children reach their
teens, they should be comfortable with using Debian without any special
modifications." At first this may appear to be too idealistic: Debian in
its current state is "too hard" for the average teen to use on their
own. But remember I was always assuming ready access to a "helper" who
is thoroughly versed in the maintenance and use of Debian, even in the
case of the teen. You seem to want to address autonomous use by non-geek
teens, which is a very ambitious and worthy goal! I considered it beyond
my own abilities and energy level to accomplish this during my tenure
leading the Debian Jr. project.
> The
> reasons why we are targeting children are mainly the following:
>
> * I started to look at how to adapt computers to children few years ago,
> when my children were very young and were starting to look at the computer.
>
> * The only children OS'es currently existing are gaming consoles – which
> are just computers, the world is still lacking a standard, widely-used,
> computer OS for children (of course many attempts based on Linux have
> been made, this is not the subject of this mail!).
And sadly, such consoles lock away the "good bits", the parts of the
system that can be adapted by the user to suit their unique needs. They
are part of large, corporate money-making machinery that aims to keep
users locked in, only using their systems in the ways they envisioned,
stifling much of the creativity and squelching curiosity users might
have otherwise had free reign to develop.
> * This is an opportunity to accustom children to Linux/FLOSS and
> understand that it's just working. They'll then grow with the idea in
> mind that Linux works and rocks – supposedly. By the way, they may
> transmit this feeling to their parents ;).
Amen to that! :)
> I like to say that many large companies do not hesitate to brain-wash
> our children. Why FLOSS should not do the same? So let's start spreading
> FLOSS to the youngest ones :).
I love the way you think.
> NB: to me Debian is the best candidate. This is a community-only
> distribution, one of the most famous ones, this is actually an universal
> operating system ;), and it is supported on many different hardware
> platforms (we are looking at porting DoudouLinux to ARM).
Wow. I'm thrilled to hear you say this and am looking forward to the
outcome of your efforts.
> Sounds good. Unfortunately I fear that many projects are just competing
> on numbers of features, instead of ease of use, learning curve,
> accessibility, coherence, low resources and so. I must say I don't know
> the potential Debian has to change this.
It's a hard thing to predict. I suspect within Debian there will always
be forces pulling in both directions, but that doesn't necessarily put a
barrier in the way for making a system embodying the latter set of
values. I think Debian as an operating system will always remain
malleable enough, and Debian as a project, open enough so that such a
thing could be built without worrying that those veering off in the
opposite direction will obstruct progress.
> However I don't know if our initiative is what everybody needs either.
> There are people who say yes, people who say no, telling that children
> can use a standard computer easily. I tend to think that our design
> principles are universal (provide the user only features that are really
> needed for him to do his job) and could guide any developer in his daily
> work. Just look at how many features you're regularly using in your
> desktop environment and you'll see the gap!
There are those who thrive on chaos and complexity, and there are those
who are overwhelmed and distressed by it and crave something simpler.
That will always be the case. In my earlier work on Debian Jr., I was
coming from the point of view of one who thrives in that environment and
wants to help young people not be afraid, mastering it early on in life
so that when they grow up, they'll be bold and adventurous in their use
of computers. I still think that's a valuable thing to do, and wish
someone else would pick up that idea and develop it further. On the flip
side, even as one who knows and is comfortable with the complexity of
present day Debian systems, I realize that just because I have developed
a tolerance for it doesn't mean it's ideal. I read Pere's recent blog
post with great interest:
http://people.skolelinux.org/pere/blog/What_is_missing_in_the_Debian_desktop__or_why_my_parents_use_Kubuntu.html
I found myself agreeing on these points, that we still have a lot of
ground to cover to making the Linux desktop truly user-friendly. Geeks
and non-geeks alike will benefit from such changes.
> My feeling is that today computers are taught as being a modern
> typewriter that can optionally send mails and read the news on the
> Internet. They are much more than this and this is why we, as
> developers, need to spend time in giving children the opportunity to
> discover what computers really are. Especially because many companies
> want us to just use computers and chain us up to their expensive services.
So true! Preaching to the choir. :)
I'm glad to find that even though our basic approaches have some
differences, we're in harmony over the really important ideas about the
value of the technology we're developing and the need to provide
children with something qualitatively different than the world would
otherwise provide them.
Ben
Reply to: