I don't have the energy to continue this at length. Debian Jr. is about making Debian better for kids. We discuss and try various software with them. We respond when things are broken and file bug reports and make feature requests. We test new versions of software when these problems are fixed or features are implemented. This isn't involvement in F/OSS?
Don't for a minute think that I *avoid* talking about the distinction between free as in freedom vs. beer (in whatever terms I think they will grasp). All of our children have grown up steeped in an environment where free software is widely used, Dad talks about his work with Debian, why he does what he does, and how it is different.
I'm sure my kids will all grow in time to really understand what F/OSS is about, even if it's a bit hazy at ages 7 and 10. One of my teens, at age 17, has already a fairly firm grasp on it and this influences her choices, in spite of the fact that she does not live with us so her contact with F/OSS growing up was mostly on weekend visits which have gotten fewer and further between as she has grown older. Now that she has a laptop of her own, she has chosen to install Ubuntu on it, and while she initially had it dual-booted with Windows, she reports that she finds herself using it so little, she wonders if she should just reclaim the space for Ubuntu.
But now we have veered quite far from the original article which is in itself coherent in its argument and does not need to be bolstered by any of these footnotes. Clearly you have an axe to grind, and if you feel the need to continue, go ahead. I'm not interested in further discussion about it.
1. I'm not proposing to _push_ any agenda on anyone.
Your agenda is apparently to involve kids somehow in either the production of software or things that go with the software (or as you say, give them this opportunity). Being broad-minded about this, you don't prescribe any kind of F/OSS at all. Nevertheless, it's still an agenda and has some influence.
But anyway, I think it's an important lesson to learn early. Not even "learn" as in "get to _my_ conclusion", but decide for yourself if that's what you want to do.
Yes, there are learning opportunities along the way. I don't place a low value on these. But I also am cautious to stress them or try to arrange these play sessions in such a way as to cause these outcomes. Again, you demonstrate a broad-minded attitude about it: "decide for yourself". Well and good. But the issues that you raise are fairly heady and I'd be surprised to observe any children paying them any attention until they have grown a bit more in age and experience.
I certainly don't propose to force anyone in any direction, much less any of the emotional stuff you write.
You're misrepresenting me now. I you have associated the word "agenda" with how people can tend to "push" or "force" agendas. I never used those words or claimed that's what you had in mind. Rather, I see people unconsciously guided by agendas in their interactions with children, and this spoils any value those interactions might have otherwise had.
As for the "emotional stuff" you vaguely and dismissively refer to, I assume you meant "experiencing the joy and frustration" with them? If you cannnot connect with them at least in some basic way, you have no hope of discovering the intrinsic value of sharing their play. Children often lack the ability to articulate exactly what precisely pleases or bothers them. It is often the non-verbal cues that tell us the most about how effective or ineffective software is for them. So on the one hand, being attuned to these emotional factors is necessary for the play session to work at all, and on the other, these same cues (on later reflection) feed back into the development process to make improvements.
I just propose to give them a chance to discover it for themselves, if they feel inclined their way.
And in this much of what you said, I agree.
2. I fail to see how crippling a tool makes it any better in any of the aspects you've mentioned.
This is over my head. Before Sandbox, we had no exposure to this kind of tool (except my 14 year-old son had some familiarity with Sauerbraten). I don't know any of the other software you mentioned. We came at it with virtually no preconceptions or expectations of superiority over any other tool. All we wanted to do was play and have fun with it. We did this and were delighted. A pleasant consequence of this was some valuable feedback into the software development process. I thought it was noteworthy to write about this.
My approach includes the possibility of coding, if anyone feels so inclined. Yours doesn't. Why is the latter better?
I am... stunned. How did you read that into my response? I explicitly stated that it is a good thing if they *do* get interested in programming or modding. In no way do I exclude that possibility.
3. What on Earth does it have to do with involvement in Open Source, then, if there is no source involved, and no chance to see for themselves if they actually want to share theirs?
F/OSS has two sides: technical and social. Children can be involved in the social side long before they have a full appreciation of the technical side. Both sides are equally valuable. No code is written in a social vacuum. To dismiss non-coding activities around F/OSS as being unimportant while exalting contact with the sourc
No, I think you miss the point I made in my article, or are at least veering off in a different direction. When we play with free software with children, it should not about the educational outcomes or preparing them for a career. Those things will happen anyway all on their own, and perhaps not in a way you carefully planned, either. But if that's all you are thinking about, if that is your primary motive, it will warp your relationship with the children. Instead of experiencing each joy and frustration along with them, instead of getting to know them better, you'll waste the moment pushing your own agenda on them. Best case, you'll impart something of value to them in spite of yourself. Worst case, they'll see you have some ulterior motive, something to sell them, and will be put off by it and lose interest.
In any case, most kids won't grow up to be programmers. Kids aren't just tabula rasas on whom we write some noble future purpose. Kids are people. They have their own thoughts and feelings, their own souls. Respect them. Get to know them. Be a meaningful part of their lives. Do you love free software and have a passion for it? Then draw them into your world by involving them in what you do, not because of the utility of such involvement, but because you value them and want to give them something special out of your heart.
And yes, if using the software sparks an interest in them to program or to mod or whatever, that is a good thing. But don't let that be the only reason you engage in the exercise. Do it because when you share your world with them sincerely and show them you respect them as human beings, you are giving them what they need most.
Read the quote from my article in context. There is more happening here than just giving kids free software to play with. Our approach with Debian Jr. is to observe children using the software, respond to their needs and wants, and work with package maintainers and upstream developers: providing notes/videos of the sessions, chatting with them, filing bugs, making feature requests, and trying new releases. So yes, the children take an active role in the software development process. We involve them in these ways in dialog with free software developers; they learn at an early age that they are accessible and are listening to their requests.
It may appear that there is nothing novel in this approach. Others have mentioned focus groups, which have been around for a long time. However, this is nothing so serious and formal as that. Focus groups have agendas. Our informal play sessions are just for the fun of it. Naturally, we are pleased when our suggestions make it back into the software. But in the meantime, just engaging kids as they play in discussion with developers is rewarding in and of itself for all parties involved.
There was never 100% agreement about the "custom distribution" term, but it seems to be here to stay now.
The term "subproject" is too broad. There are many Debian subprojects (QA, X Strike Force, etc.) that aren't CDDs.
On the other hand, the term "metapackage" is too narrow. A metapackage is merely a package with no actual content, consisting just of a description, dependencies and minimal doc (changelog, copyright, README).
A CDD is more than that, since it is a complete solution for some set of users who want to use Debian in a particular situation, not just a metapackage. Thus, in CDD projects we try to address menus, groups, permissions, default configuration for applications, what material should be on a CDD install CD. What extra CDs (if any) could be provided, and so forth. On top of that, we're in constant dialogue with other groups of developers within Debian to try to make our work mesh with theirs. Thus, Debian Jr. has an interest in what is happening with Debian Edu., Debian Desktop, etc.
So, while some misunderstandings are inevitable with this term, I don't like either of your suggested alternatives, and I have a hard time thinking of any better term that both accurately describes what it is, and is readily understood by the uninitiated.
As for xpilot-ng in Debian Jr., we'll see how that goes in the coming year. Debian Jr. is pretty much now how it will be in sarge, since major changes in package dependencies messes with what goes onto what CD, something I don't think is welcome this late in the game. -- synrg at debian dot org
You can't differentiate the two by what they aim to provide. Custom Debian Distributions aim to provide "parts of debian all rolled up into one" as well. Ultimately, you will see CDDs with Knoppix "live CD" capabilities, which several of us have already expressed an interest in making a reality.
The big difference is that CDDs are entirely self-contained within Debian, with all of the benefits to developers and users that entails. (See my other comments in this thread.) -- synrg at debian dot org
From the developer's perspective, by making a Custom Debian Distribution, my project, Debian Jr., can afford to focus strictly on making Debian better for children, and not have to worry about providing a whole new infrastructure that is necessary for a Debian derivative.
From the user's perspective, they are going right to the source for support and bug reporting, rather than filtering everything through a third party. They don't need to worry about whether package foo from Debian main will work with their Debian derivative or not. And if package foo *does* break, someone is actually on the hook for fixing it, whereas with a derivative you're likely to encounter this:
User: Package 'foo' is broken when I use it with Debian derivative 'bar'. Help!
Derivative developer: Sorry, that's your problem. We don't maintain 'foo'.
Debian developer: Sorry, that's your problem, I don't run 'bar', so I can't debug it.
Emdebian is attractive for much the same reasons
that Debian attracted me five years ago. Namely,
anyone can get involved. Besides, these guys are are committed to the philosophy of free software development, and that is important to me.
They are moving along now, and are daily cranking changes through CVS that I have been tracking closely and trying out myself. I really hope the community gets behind them and helps them get where they want to go.
I have started playing with CML2+OS and have used
it to build a small rootfs for my 386sx/20 8M DECpc mouldering in the corner. There have been a few snags, but thanks to some help from these guys on channel #emdebian on irc.debian.org, I was able
to work thru them and (mostly) boot the thing for the first time last night. Once I'm done, I will have breathed new life into this old iron, which will serve as a utility on my growing home network. It's a great learning experience. In the end, I hope I will have contributed something of value back to the Emdebian project.
Slashdot Mirror
I don't have the energy to continue this at length. Debian Jr. is about making Debian better for kids. We discuss and try various software with them. We respond when things are broken and file bug reports and make feature requests. We test new versions of software when these problems are fixed or features are implemented. This isn't involvement in F/OSS?
Don't for a minute think that I *avoid* talking about the distinction between free as in freedom vs. beer (in whatever terms I think they will grasp). All of our children have grown up steeped in an environment where free software is widely used, Dad talks about his work with Debian, why he does what he does, and how it is different.
I'm sure my kids will all grow in time to really understand what F/OSS is about, even if it's a bit hazy at ages 7 and 10. One of my teens, at age 17, has already a fairly firm grasp on it and this influences her choices, in spite of the fact that she does not live with us so her contact with F/OSS growing up was mostly on weekend visits which have gotten fewer and further between as she has grown older. Now that she has a laptop of her own, she has chosen to install Ubuntu on it, and while she initially had it dual-booted with Windows, she reports that she finds herself using it so little, she wonders if she should just reclaim the space for Ubuntu.
But now we have veered quite far from the original article which is in itself coherent in its argument and does not need to be bolstered by any of these footnotes. Clearly you have an axe to grind, and if you feel the need to continue, go ahead. I'm not interested in further discussion about it.
1. I'm not proposing to _push_ any agenda on anyone.
Your agenda is apparently to involve kids somehow in either the production of software or things that go with the software (or as you say, give them this opportunity). Being broad-minded about this, you don't prescribe any kind of F/OSS at all. Nevertheless, it's still an agenda and has some influence.
But anyway, I think it's an important lesson to learn early. Not even "learn" as in "get to _my_ conclusion", but decide for yourself if that's what you want to do.
Yes, there are learning opportunities along the way. I don't place a low value on these. But I also am cautious to stress them or try to arrange these play sessions in such a way as to cause these outcomes. Again, you demonstrate a broad-minded attitude about it: "decide for yourself". Well and good. But the issues that you raise are fairly heady and I'd be surprised to observe any children paying them any attention until they have grown a bit more in age and experience.
I certainly don't propose to force anyone in any direction, much less any of the emotional stuff you write.
You're misrepresenting me now. I you have associated the word "agenda" with how people can tend to "push" or "force" agendas. I never used those words or claimed that's what you had in mind. Rather, I see people unconsciously guided by agendas in their interactions with children, and this spoils any value those interactions might have otherwise had.
As for the "emotional stuff" you vaguely and dismissively refer to, I assume you meant "experiencing the joy and frustration" with them? If you cannnot connect with them at least in some basic way, you have no hope of discovering the intrinsic value of sharing their play. Children often lack the ability to articulate exactly what precisely pleases or bothers them. It is often the non-verbal cues that tell us the most about how effective or ineffective software is for them. So on the one hand, being attuned to these emotional factors is necessary for the play session to work at all, and on the other, these same cues (on later reflection) feed back into the development process to make improvements.
I just propose to give them a chance to discover it for themselves, if they feel inclined their way.
And in this much of what you said, I agree.
2. I fail to see how crippling a tool makes it any better in any of the aspects you've mentioned.
This is over my head. Before Sandbox, we had no exposure to this kind of tool (except my 14 year-old son had some familiarity with Sauerbraten). I don't know any of the other software you mentioned. We came at it with virtually no preconceptions or expectations of superiority over any other tool. All we wanted to do was play and have fun with it. We did this and were delighted. A pleasant consequence of this was some valuable feedback into the software development process. I thought it was noteworthy to write about this.
My approach includes the possibility of coding, if anyone feels so inclined. Yours doesn't. Why is the latter better?
I am ... stunned. How did you read that into my response? I explicitly stated that it is a good thing if they *do* get interested in programming or modding. In no way do I exclude that possibility.
3. What on Earth does it have to do with involvement in Open Source, then, if there is no source involved, and no chance to see for themselves if they actually want to share theirs?
F/OSS has two sides: technical and social. Children can be involved in the social side long before they have a full appreciation of the technical side. Both sides are equally valuable. No code is written in a social vacuum. To dismiss non-coding activities around F/OSS as being unimportant while exalting contact with the sourc
No, I think you miss the point I made in my article, or are at least veering off in a different direction. When we play with free software with children, it should not about the educational outcomes or preparing them for a career. Those things will happen anyway all on their own, and perhaps not in a way you carefully planned, either. But if that's all you are thinking about, if that is your primary motive, it will warp your relationship with the children. Instead of experiencing each joy and frustration along with them, instead of getting to know them better, you'll waste the moment pushing your own agenda on them. Best case, you'll impart something of value to them in spite of yourself. Worst case, they'll see you have some ulterior motive, something to sell them, and will be put off by it and lose interest.
In any case, most kids won't grow up to be programmers. Kids aren't just tabula rasas on whom we write some noble future purpose. Kids are people. They have their own thoughts and feelings, their own souls. Respect them. Get to know them. Be a meaningful part of their lives. Do you love free software and have a passion for it? Then draw them into your world by involving them in what you do, not because of the utility of such involvement, but because you value them and want to give them something special out of your heart.
And yes, if using the software sparks an interest in them to program or to mod or whatever, that is a good thing. But don't let that be the only reason you engage in the exercise. Do it because when you share your world with them sincerely and show them you respect them as human beings, you are giving them what they need most.
Read the quote from my article in context. There is more happening here than just giving kids free software to play with. Our approach with Debian Jr. is to observe children using the software, respond to their needs and wants, and work with package maintainers and upstream developers: providing notes/videos of the sessions, chatting with them, filing bugs, making feature requests, and trying new releases. So yes, the children take an active role in the software development process. We involve them in these ways in dialog with free software developers; they learn at an early age that they are accessible and are listening to their requests.
It may appear that there is nothing novel in this approach. Others have mentioned focus groups, which have been around for a long time. However, this is nothing so serious and formal as that. Focus groups have agendas. Our informal play sessions are just for the fun of it. Naturally, we are pleased when our suggestions make it back into the software. But in the meantime, just engaging kids as they play in discussion with developers is rewarding in and of itself for all parties involved.
There was never 100% agreement about the "custom distribution" term, but it seems to be here to stay now.
The term "subproject" is too broad. There are many Debian subprojects (QA, X Strike Force, etc.) that aren't CDDs.
On the other hand, the term "metapackage" is too narrow. A metapackage is merely a package with no actual content, consisting just of a description, dependencies and minimal doc (changelog, copyright, README).
A CDD is more than that, since it is a complete solution for some set of users who want to use Debian in a particular situation, not just a metapackage. Thus, in CDD projects we try to address menus, groups, permissions, default configuration for applications, what material should be on a CDD install CD. What extra CDs (if any) could be provided, and so forth. On top of that, we're in constant dialogue with other groups of developers within Debian to try to make our work mesh with theirs. Thus, Debian Jr. has an interest in what is happening with Debian Edu., Debian Desktop, etc.
So, while some misunderstandings are inevitable with this term, I don't like either of your suggested alternatives, and I have a hard time thinking of any better term that both accurately describes what it is, and is readily understood by the uninitiated.
As for xpilot-ng in Debian Jr., we'll see how that goes in the coming year. Debian Jr. is pretty much now how it will be in sarge, since major changes in package dependencies messes with what goes onto what CD, something I don't think is welcome this late in the game.
--
synrg at debian dot org
You can't differentiate the two by what they aim to provide. Custom Debian Distributions aim to provide "parts of debian all rolled up into one" as well. Ultimately, you will see CDDs with Knoppix "live CD" capabilities, which several of us have already expressed an interest in making a reality.
The big difference is that CDDs are entirely self-contained within Debian, with all of the benefits to developers and users that entails. (See my other comments in this thread.)
--
synrg at debian dot org
From the developer's perspective, by making a Custom Debian Distribution, my project, Debian Jr., can afford to focus strictly on making Debian better for children, and not have to worry about providing a whole new infrastructure that is necessary for a Debian derivative.
From the user's perspective, they are going right to the source for support and bug reporting, rather than filtering everything through a third party. They don't need to worry about whether package foo from Debian main will work with their Debian derivative or not. And if package foo *does* break, someone is actually on the hook for fixing it, whereas with a derivative you're likely to encounter this:
User: Package 'foo' is broken when I use it with Debian derivative 'bar'. Help!
Derivative developer: Sorry, that's your problem. We don't maintain 'foo'.
Debian developer: Sorry, that's your problem, I don't run 'bar', so I can't debug it.
--
synrg at debian dot org
Isn't the HP MP3130 more than twice as expensive
as the ~$1000 units based on this technology predicted by Doherty?
Eh? Refusing?
Last I checked, PGI was in stable, testing and unstable. (But then, last I checked PGI wasn't finished yet, either.)
I have started playing with CML2+OS and have used it to build a small rootfs for my 386sx/20 8M DECpc mouldering in the corner. There have been a few snags, but thanks to some help from these guys on channel #emdebian on irc.debian.org, I was able to work thru them and (mostly) boot the thing for the first time last night. Once I'm done, I will have breathed new life into this old iron, which will serve as a utility on my growing home network. It's a great learning experience. In the end, I hope I will have contributed something of value back to the Emdebian project.
Thanks for Emdebian, and good luck with it!