Re: Debian for kids
Bdale Garbee wrote:
> In article <38A43352.9DAC438B@mindspring.com> you wrote:
> > "Fool Proof Debian", "Low-Maintenance Debian", "No Hassle Debian"? I
> > can't think of a good term.
> We need to be careful here. My goal isn't any of these things... it's to
> make Debian an operating system my kids *want* to run.
> The note that kicked off this thread talked a bit about the issues of sharing
> a Debian machine with kids, which I suspect is what is leading to the above
> set of concerns... but in my case, it's completely clear that my kids should
> have their own computer(s)... so I'm worried more about making sure the kinds
> of programs they would want to have and run are available. I also agree that
> we could provide a more kid-oriented "desktop environment" with a set of
> features they can latch onto easily without being too limiting long-term.
> Don't laugh, but I bet some desktop themes with cartoon characters, dinosaurs,
> zoo animals, or other things like that which appeal directly to kids would
> have more to do with whether our kids think it's cool running Debian than
> almost anything else we could work on. /o\
> By the way, I don't want my kids to have a completely fool-proof system. They
> aren't fools,
Gosh, I hope you don't think I was suggesting that! And I don't think
"kids" is a derogatory term!
> and it is important that they have the learning experiences that
> go along with fixing things and/or getting help to fix things from time to
> time. One of the great enabling features of an Open Source system is that you
> *can* learn how it all works if you want to. If there are things we can or
> should do to improve Debian's robustness for all users, that's great... I
> sure have spent a lot of late nights trying to make the packages I maintain
> more robust because I think that is generally important, and I don't intend
> to stop... but it isn't a kid-specific issue.
Exactly my point!
> Don't confuse the issues associated with making Debian more attractive and
> useful to kids with the issue of robustness... they may go hand in hand, but
> they are *not* the same thing!
Actually, that's exactly the point I was trying to make, but taking it
from a different direction: that if you were going to do a lot of work
on "robustness" (or ease-of-administration, or non-flexibility), that
that could be generalized. Prior posts talked about some "robustness"
issues, so I thought you might be doing some of that. More of a
"have-y'all-thought-about this?" sort of thing than anything else. More
specifically, I could see huge benefit in something you could run in a
Let me put it another way, then I'll shut up:
If x amount of effort goes into "robustifying", and y amount goes into
doing kid themes, etc.
If you do a "robustify" package, and a "kid" package, both of which
you'd want to install for kids, but are not interdependent, I could see
lots of folks benefitting from the "robustify" package. Now whether
this is worth the (any?) extra effort on your part to separate these
things out, is entirely your call. I don't even know if you planned to
put much effort into "x".
As I said before, good luck.