[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Introducing DoudouLinux

Sorry for the delay to answer, I was quite busy during the past few days. 


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.
Thank you for your valuable support Ben, I was not expecting so much enthusiasm indeed, that's simply great!
- 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, …
No we don't remove documentation, even man pages. I find myself using it so often when I come across an issue that I can't imagine removing it! But maybe one day?
- 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.
You pointed out a real issue we're having with several packages. Currently we haven't done anything to solve it. One idea is to reduce the size of data by resampling or recompressing. For example a music file can be divided by 4 if you resample it at 22kHz instead of 44kHz and convert it from stereo to mono. I saw recently a game which has a data package in high resolution and another one in low resolution. Sounds like a good solution.
Then we have several huge children apps, which come with a lot of images and sounds. Your proposal to split the data package sounds good too, especially because children never use all the features of these apps. Moreover many features may be overlapping between apps and we see that they're overlapping more and more with time.
- 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.
We do not do this systematically but, as we've disabled recommended packages, we're checking software usability as much as possible and we add the missing recommendations whenever required. Maybe we should write a tool to help this kind of investigations.
- 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.
Mmm, it sounds more complicated. Till now I've never supposed that there could be unneeded dependencies, but for sure it may happen. Sometimes I install Synaptic in a Live session and list packages by decreasing order of size. Then I click remove on suspect packages to see what can need such package, I should also ask myself about the relevancy of the dependency. 


- Do make metapackages of an appropriate granularity to support
subdivision into smaller parts for N-sized media. (Perhaps -core and
-extra or -full variants.)
Yes we still have a lot of work to do on packaging, and this will help us manage the CD, the DVD, the ARM version, etc., with the same code base. 


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.
Oh yes, I've been thinking of such feature too :). Thank you for the workarounds, it may be useful. 


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.


Ok, then we'll compare both package sets and tell you.
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.
For sure, the more useful is our work the better. So we'll do our best to work not with but within Debian! Our work on ARM requires that we change our way to work in order to leave the special case of LiveCD's to reach something more universal. 


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.
I don't know what success we could expect (or not) but I see no reason to keep teenagers out of simplicity. The idea is to propose later a successor for their DoudouLinux, when children have grown (and if they don't feel like becoming sysadmins to do it themselves ;) ). However we may find that the difficulty in not the interface but the software selection that may not fit teenager tastes, lot more subject to fashions. 


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.


So true! And so sad.


I love the way you think.


:)
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.


In this case, just let's go!


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.
Indeed I see too many people at work, even engineers, who are afraid of computers because they don't understand their logic or can just use what they believe they know. I'd like children not be afraid of computers, this is why I wanted to avoid the risk of embarrassed answers from parents or, worse, the typical “it's too complicated for you”. 


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.
Yes, and often this is stupid details. For example today I tested DoudouLinux built upon Squeeze, the touchpad could not scroll certainly because Xorg isn't configured for this. We need people to track such details that are annoying for the standard user and often easy to solve. 


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.
I perfectly agree. Finally the only difference seems to be that you have supposed children have a so-called helper to help them get into Debian, as we want children to believe computers are simple, while using Debian – kind of revolution ;). 

Cheers,
JM.
Reply to: