From 310ab4ef7a065764e271321d53d93ebe6d5b5b90 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 03:39:55 +0100 Subject: gsoc: first very rough take on main page for 2010 --- community/gsoc/2009.mdwm | 53 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 community/gsoc/2009.mdwm (limited to 'community/gsoc') diff --git a/community/gsoc/2009.mdwm b/community/gsoc/2009.mdwm new file mode 100644 index 00000000..ce3b26fb --- /dev/null +++ b/community/gsoc/2009.mdwm @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Google Summer of Code"]] + +# 2009 + +The GNU Hurd project this year unfortunately is not in the list of accepted +mentoring organizations. + +However, don't despair! This doesn't mean that you'd not be allowed to work on +your favorite GNU Hurd project. For one, there's the possibility that a slot +for your project can be allocated under the [auspices of the GNU +project](http://www.gnu.org/software/soc-projects/). Second, we're of course +always open to introducing newcomers to the world of the GNU Hurd outside of +any Google Summer of whatever project. Just pick a task from the list pointed +to below on this page and get in touch with us! + + + +The applications have been evaluated and the following student has +been accepted: + + * [[Sergiu Ivanov|scolobb]] + + +# History + +2006 and 2007 we participated in GSoC under the umbrella of the GNU project, +getting one slot each year. + + + +In 2008 we successfully participated on our own, no longer within the GNU +project. Read about our five students' success on the [[2008]] page. + + +# Joining in + +If these successes got you interested in contributing some larger part yourself - +in your free time or maybe in next years Google Summer of Code - +please have a look at our [[project_ideas]] and read up about [[contributing]]. + +Also, feel free to ask your questions at one of our +[[regular_IRC_meetings|IRC#regular_meetings]]. -- cgit v1.2.3 From 55f5f76c4b211f693f345827bc67164fd43f2225 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 03:40:25 +0100 Subject: gsoc: update questions in organisation application form for 2010 Note: The *answers* aren't updated yet! --- community/gsoc/organization_application.mdwn | 84 +++++++++++++--------------- 1 file changed, 38 insertions(+), 46 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 9fe3a420..5fdf3837 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -8,22 +8,10 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -* Link ID: - -hurd - -* Group Name: +* Organization Name: GNU Hurd -* Home Page URL: - -http://hurd.gnu.org - -* Public Email: - -bug-hurd@gnu.org - * Description: The Hurd project is a loose community of people sharing a common interest in @@ -71,7 +59,15 @@ contact with the most distinguished researchers in that field from the microkernel operating system groups, and have written a couple of [research papers](http://walfield.org/). -* Why is your group applying to participate? What do you hope to gain by participating? +* Home Page: + +http://hurd.gnu.org + +* Main Organization License: + +GNU General Public License (GPL) + +* Why is your organization applying to participate in GSoC 2010? What do you hope to gain by participating? The primary goal of course is to find and introduce new long-term contributors to the project. @@ -90,25 +86,7 @@ progress is. Last but not least, we hope the participation will have a positive effect on our community -- new impulses, increased communication etc. -* What is the main public mailing list for your group? - -bug-hurd@gnu.org, see http://lists.gnu.org/mailman/listinfo/bug-hurd - -* Where is the main IRC channel for your group? - -\#hurd on freenode.net - -* What criteria do you use to select the members of your group? Please be as specific as possible. - -The most important criterium is that the person is involved in the project for -some time, knowing the ways; so he can actually instruct the student; and if -there are tough technical questions he can't answer himself, he knows whom to -ask. - -It's also important that the mentors are reliable and helpful, so the students -won't be left on their own with any problems they face. - -* Has your group participated previously? If so, please summarize your involvement and any past successes and failures. +* Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. In 2006 and 2007, we participated under the umbrella of the GNU project, getting one slot each @@ -143,27 +121,39 @@ hoped of course, but probably as much as can be realistically expected... All in all, the participation was a considerable amount of work, but it was definitely worth it :-) -* If your group has not previously participated, have you applied in the past? If so, for what sort of participation? +* If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. --- +* If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? -* What license does your organization use? - -GNU General Public License (GPL) +-- -* What is the URL to the ideas list of your organization? +* What is the URL for your ideas page? http://www.gnu.org/software/hurd/community/gsoc/project_ideas.html -* What is the main development mailing list for your group? +* What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2010. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. bug-hurd@gnu.org, see http://lists.gnu.org/mailman/listinfo/bug-hurd -* What is the application template you would like contributors to your organization to use. +* What is the main IRC channel for your organization? + +\#hurd on freenode.net + +* Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2010 site. [[student_application_form]] -* What is your plan for dealing with disappearing contributors? +* What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible: + +The most important criterium is that the person is involved in the project for +some time, knowing the ways; so he can actually instruct the student; and if +there are tough technical questions he can't answer himself, he knows whom to +ask. + +It's also important that the mentors are reliable and helpful, so the students +won't be left on their own with any problems they face. + +* What is your plan for dealing with disappearing students? The plan is mostly to avoid that happening in the first place. For that, we will be particularily careful with the selection of the students: Making sure @@ -183,7 +173,7 @@ state where it is useful even if not finished. We will also try to limit damage by insisting that students regularily check in their work, so that we get partial results at least if someone disappears. -* What is your plan for dealing with disappearing members? +* What is your plan for dealing with disappearing mentors? As our mentors all have been with the project for some time, the risk of them disappearing is not too big. If one of them disappears nevertheless, it's not a @@ -193,7 +183,7 @@ We will encourage the students to keep discussions public as much as possible, keeping private conversations with the mentors to a minimum, so the transition should go smoothly. -* What steps will you take to encourage contributors to interact with your community before, during, and after the program? +* What steps will you take to encourage students to interact with your project's community before, during and after the program? We try to make it very clear that we expect the students to get into regular contact with us before the end of the student selection process, and won't @@ -213,12 +203,14 @@ part in other conversations, not directly related to their projects, as well. After the program we continue the regular meetings, still discussing the projects: The application of the code created, future directions etc. -* What will you do to ensure that your accepted contributors stick with the project after the program concludes? +* What will you do to ensure that your accepted students stick with the project after GSoC concludes? We will try to invite all participating students to a conference afterwards, where we will discuss the projects, as well as other Hurd-related topics. We hope this will motivate them to follow up on the work they have done during the program, and generally help keeping them involved. -* Please select your backup group administrator. +* Is there anything else you would like to tell the Google Summer of Code program administration team? : + +* Backup Admin (Link ID): -- cgit v1.2.3 From deebcc9437efa170c6d3b2e6e1bbd03b0cbbe73b Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 03:42:08 +0100 Subject: gsoc/project_ideas: add note on DDE being mostly done, and drop from list --- community/gsoc/project_ideas.mdwn | 1 - community/gsoc/project_ideas/driver_glue_code.mdwn | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index aaaa68c3..96d93869 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -78,7 +78,6 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/language_bindings" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/virtualization" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/file_locking" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/driver_glue_code" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/server_overriding" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/tcp_ip_stack" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/nfs" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn index e1b8d22e..a4462133 100644 --- a/community/gsoc/project_ideas/driver_glue_code.mdwn +++ b/community/gsoc/project_ideas/driver_glue_code.mdwn @@ -44,3 +44,5 @@ ethernet) from a recent system, and try to port it to run in the existing driver framework in GNU Mach. Completing the port might be too involved for the exercise; but it's pretty likely that you will find something else to improve in the glue code while working on this... + +*Status*: Zheng Da is working on DDE, and has mostly completed the initial port. -- cgit v1.2.3 From 00694aaf8930b2ba39f00abd335b9c2f2b16d71b Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 04:01:31 +0100 Subject: gsoc/orgianization_application: Use mission statement in description --- community/gsoc/organization_application.mdwn | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 5fdf3837..a2c65581 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -14,9 +14,10 @@ GNU Hurd * Description: -The Hurd project is a loose community of people sharing a common interest in -developing the Hurd kernel, which is the official kernel of the [GNU operating -system](http://gnu.org). +The mission of the Hurd project is to create a general-purpose kernel suitable +for the [GNU operating system](http://gnu.org), which is viable for everyday +use, and gives users and programs as much control over their computing +environment as possible. When the Hurd was originally started in 1990, it was the last missing major component for a complete GNU system. Today Linux and other free kernels are -- cgit v1.2.3 From 5c995d0a03534252cddba2fc2debf9ef1676df3a Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 05:04:35 +0100 Subject: gsoc/organization_application: improve wording Most notably, don't write in the past about things that we do regularily. Also all kinds of other changes in wording. --- community/gsoc/organization_application.mdwn | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index a2c65581..32a76b1c 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -77,7 +77,7 @@ Aside from that, it is a way to make progress with tasks that require an amount focused work, that is hard to do for volunteers working in their spare time only. -Also it is a good possibility to get valuable input from new people, as well as +Also it is a good opportunity to get valuable input from new people, as well as spreading technical and other knowledge about the Hurd among actual and potential contributors. More generally, participation should help raising awareness among people who might know about the existence of the Hurd, but @@ -156,8 +156,8 @@ won't be left on their own with any problems they face. * What is your plan for dealing with disappearing students? -The plan is mostly to avoid that happening in the first place. For that, we -will be particularily careful with the selection of the students: Making sure +The plan is mostly to avoid that happening in the first place. To this end, we +are particularily careful with selection of students: Making sure that they have no other obligations during that time; that they are motivated enough; that they actually have the necessary skills to complete the task; that they fit in our community. @@ -191,24 +191,25 @@ contact with us before the end of the student selection process, and won't consider their applications otherwise. This way we know that the students are able and willing to communicate with us in the first place. -After the selection, the regular contact will be kept up: We require the +After selection, the regular contact is kept up: We require the students to participate in weekly IRC meetings, where we ask the students actively about the work they do, problems they face, decisions they take etc. -Furthermore, we will ask them to hang around on IRC most of the time while +Furthermore, we ask them to hang out on IRC most of the time while working on their projects, so we keep in close contact. We also require the students to join our main development mailing list, so any -design questions etc. can be discussed there. We will encourage them to take +design questions etc. can be discussed there. We encourage them to take part in other conversations, not directly related to their projects, as well. -After the program we continue the regular meetings, still discussing the -projects: The application of the code created, future directions etc. +After the program we continue the regular meetings, discussing the further +development of their original projects; as well as new projects, after the +original ones are done. * What will you do to ensure that your accepted students stick with the project after GSoC concludes? -We will try to invite all participating students to a conference afterwards, -where we will discuss the projects, as well as other Hurd-related topics. We -hope this will motivate them to follow up on the work they have done during the +We try to invite all participating students to meet us at conferences afterwards, +where we discuss the projects, as well as other Hurd-related topics. This should +keep them motivated to follow up on the work they have done during the program, and generally help keeping them involved. * Is there anything else you would like to tell the Google Summer of Code program administration team? : -- cgit v1.2.3 From 29af850b17ac62bd784afd36a4e97378b699f353 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 05:08:39 +0100 Subject: gsoc/organization_application: update on past participation Somewhat different question; updates for last year; and extra question for explicit head count. Generally change emphasis of text from praising participation as a distinct organisation, to praising our own past achievments. --- community/gsoc/organization_application.mdwn | 42 ++++++++++++---------------- 1 file changed, 18 insertions(+), 24 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 32a76b1c..1f499f5a 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -93,37 +93,31 @@ In 2006 and 2007, we participated under the umbrella of the GNU project, getting one slot each year. -The 2006 participation was mostly a failure. After some intitial work -(available in CVS), the student disappeared -- moving to another country and -other personal issues from what we heard. - -The 2007 participation was a considerable success. The student was very bright -and dedicated. We got some code, as well as a lot of ideas, which we continued -discussing after the end of GSoC, and he intends to put into code as well in -the future. - In 2008 we participated as an organisation on our own for the first time. This -turned out extremely beneficial: Not only did it give us much better -possibilities to find and select good students, as we hoped. We also get a lot -more applications, mostly of good or excellent quality. - -We ended up with four slots. (We didn't request more, because we were not sure -whether we would be able to mentor them properly, and generally didn't want to -overdo it on our first "full" participation.) There was also a fifth student, -who worked on his project in spite of not getting a slot. +turned out extremely beneficial: With the better visibility, we get a lot +more applications (more than 20), mostly of good or excellent quality. -All five students were pretty successful, most of them completing or almost -completing the original goals -- some even exceeding them. Even our weakest -student, after serious struggling in the beginning, did quite well in the end. +In 2009, we were rejected as an organisation, so we participated under the GNU +umbrella again. -Two students are still regularily working on the Hurd -- not as much as we -hoped of course, but probably as much as can be realistically expected... +While the 2006 student disappeared midway, in all the later years all of our +students were successful -- including even one who worked on his project in +spite of not getting a slot. Half of them are regular Hurd contributors now. -All in all, the participation was a considerable amount of work, but it was -definitely worth it :-) +Selecting the most promising students, as well as suitable mentors, turned out +to be the most tricky part of GSoC participation -- but we learned our lesson +after the first failure: We didn't have any students that didn't meet our +expectations since then, and we also believe our mentoring is exceptionally +good now -- one project that was in serious trouble, turned out well after all, +due to effective mentor intervention. * If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. +2008: 4/4 + +(+1 inofficial in 2008) +(under GNU umbrella: 2006: 0/1; 2007: 1/1; 2009: 1/1) + * If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? -- -- cgit v1.2.3 From f51a0c39bf3b5634351b99d904cd4d5cd53eceaf Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 05:14:48 +0100 Subject: gsoc/organization_application: different syntax for including list info URL --- community/gsoc/organization_application.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 1f499f5a..4766d961 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -128,7 +128,7 @@ http://www.gnu.org/software/hurd/community/gsoc/project_ideas.html * What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2010. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. -bug-hurd@gnu.org, see http://lists.gnu.org/mailman/listinfo/bug-hurd +bug-hurd@gnu.org ( http://lists.gnu.org/mailman/listinfo/bug-hurd ) * What is the main IRC channel for your organization? -- cgit v1.2.3 From 6acdf22e58dbb922d39ea9f377e21f2332c0e194 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 05:16:49 +0100 Subject: gsoc/organization_application: meeting up to twice a week --- community/gsoc/organization_application.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 4766d961..476bd1f2 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -186,7 +186,7 @@ consider their applications otherwise. This way we know that the students are able and willing to communicate with us in the first place. After selection, the regular contact is kept up: We require the -students to participate in weekly IRC meetings, where we ask the students +students to participate in IRC meetings up to twice a week, where we ask the students actively about the work they do, problems they face, decisions they take etc. Furthermore, we ask them to hang out on IRC most of the time while working on their projects, so we keep in close contact. -- cgit v1.2.3 From 05109af3cf7d59a0203d6ca09c469921190bf2bb Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 05:18:02 +0100 Subject: gsoc/organization_application: conference invitation is not only measure to keep students motivated Make it explicit that we do that *in addition* to the continued IRC meetings -- it's not the major bit. --- community/gsoc/organization_application.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 476bd1f2..abdfcff5 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -201,7 +201,8 @@ original ones are done. * What will you do to ensure that your accepted students stick with the project after GSoC concludes? -We try to invite all participating students to meet us at conferences afterwards, +In addition to keeping up the regular IRC meetings, +we try to invite all participating students to meet us at conferences afterwards, where we discuss the projects, as well as other Hurd-related topics. This should keep them motivated to follow up on the work they have done during the program, and generally help keeping them involved. -- cgit v1.2.3 From 751c59af07e496994ce140333d779ec267d36b06 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 05:22:49 +0100 Subject: gsoc/organization_application: shorten bit on awareness in "why" question Drop the second sentence, which explicitely talks about raising awareness about the Hurd -- I fear it makes it sound like we treat GSoC as some kind of advertising program... --- community/gsoc/organization_application.mdwn | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index abdfcff5..b2ec557d 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -79,10 +79,7 @@ only. Also it is a good opportunity to get valuable input from new people, as well as spreading technical and other knowledge about the Hurd among actual and -potential contributors. More generally, participation should help raising -awareness among people who might know about the existence of the Hurd, but -otherwise having very little idea what the project is all about, and how its -progress is. +potential contributors. Last but not least, we hope the participation will have a positive effect on our community -- new impulses, increased communication etc. -- cgit v1.2.3 From 16f30908a3f67573bee3648bc4220d47b80234b5 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 06:31:19 +0100 Subject: gsoc/student_application_form: more emphasis on additional requirements being mandatory --- community/gsoc/student_application_form.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/student_application_form.mdwn b/community/gsoc/student_application_form.mdwn index 84070cbf..954507d5 100644 --- a/community/gsoc/student_application_form.mdwn +++ b/community/gsoc/student_application_form.mdwn @@ -21,7 +21,8 @@ title yourself of course -- but surely this isn't hard, if you were able to come up with your own project idea :-) Submitting the application form is only part of the deal: we expect a few other -things on top of that. Lacking these, the application is not complete, and we +things on top of that, as explained below. This is important, so please take +it seriously -- without these things, the application is not complete, and we won't consider it. One of the things we expect is that you contact us directly as soon as possible -- cgit v1.2.3 From 899869fd2ebf41654fd149641e10c3c88468c544 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 06:33:47 +0100 Subject: gsoc/student_application_form: be slightly more explicit about time constraints Hopefully this will make it somewhat clearer that we are serious about this, but without sounding too accusatory... --- community/gsoc/student_application_form.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/student_application_form.mdwn b/community/gsoc/student_application_form.mdwn index 954507d5..3f696ca4 100644 --- a/community/gsoc/student_application_form.mdwn +++ b/community/gsoc/student_application_form.mdwn @@ -191,8 +191,8 @@ intend to make sure you will be able to dedicate sufficient time to your project nevertheless? Please be open about this, and also mention things you are not yet sure about. -We can be flexible about time arrangements; but we need to know about any -possible obstacles up front. +We can be flexible about time arrangements; but we absolutely need to know about any +possible obstacles up front. Surprises on that score are not acceptable. * How do you intend to make sure that your code will keep on being maintained and supported properly after the end of the GSoC program? -- cgit v1.2.3 From 63e0c9c3b6ae08c5501628db19fe5afa72bfc42d Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 06:36:50 +0100 Subject: gsoc/student_application_form: wording and punctuation fixes/improvements --- community/gsoc/student_application_form.mdwn | 35 +++++++++++++++------------- 1 file changed, 19 insertions(+), 16 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/student_application_form.mdwn b/community/gsoc/student_application_form.mdwn index 3f696ca4..5862bce3 100644 --- a/community/gsoc/student_application_form.mdwn +++ b/community/gsoc/student_application_form.mdwn @@ -31,41 +31,44 @@ One of the things we expect is that you contact us directly as soon as possible in particular allows for very informal conversations. (Note though that we are not all in the same time zone, and people generally -don't stare at the IRC screen all the time -- it can take quite a long time -until somebody replies: even several hours. Don't get discouraged by that: Just +don't stare at the IRC screen all the time: it can take quite a long time +until somebody replies -- even several hours. Don't get discouraged by that. Just be patient and hang on, or try again later.) Contacting us as soon as possible is crucial, as regular communication is the single most important factor for a successful GSoC project. We need to see that -you are able and willing to talk to us regularily. Also it allows us getting to -know you much better than the application form alone could. +you are able and willing to talk to us regularily. Also, we get to +know you much better this way than what the application form alone would allow us to. -You shouldn't be at a loss for reason to contact us. You ought to discuss your -project and application with us for exmple: You will gain a much better idea -about the project, our expectations etc. -- in short, you will be able to +You shouldn't be at a loss for reasons to contact us. You ought to discuss your +project and application with us for exmple -- you will gain a much better idea +about the project, our expectations etc. In short, you will be able to submit a better application right from the beginnig, saving both yourself and us some tedious roundtrips :-) Also, if you really want to get involved with the Hurd project, there are -surely many things you will want to know :-) All in all, you should have ample +surely many things you will want to know -- after all, it's a fascinating +project, with a fascinating architecture etc., right? :-) + +All in all, you should have ample causes to get in touch during the application period. Bonus points if you also participate in discussions not directly related to your project. The other thing necessary to complete your application is making a change to -some part of the Hurd code, and submitting a patch with the change. (If you are +some part of the Hurd code, and submitting a patch implementing that change. (If you are not sure what that means, ask us!) This is important, as it shows that you have everything set up to start hacking -on the project (source code, tool chain, testing environment etc.), and that -you have all kinds of qualifications necessary to successfully finish the -project: general programming abilities; working in the Hurd environment; +on the project (source code, tool chain, testing environment etc.); and that +you have all kinds of qualifications necessary to successfully finish your +project: general programming skills; working in the Hurd environment; submitting patches and reacting to feedback; finding and/or asking for any information you need; and so on. Don't get us wrong: We absolutely do *not* demand that you have and know all this up front. After all, the idea of GSoC is to *introduce* you to free software development in general, and to our project specifically :-) We are -willing to help you with anything you will need to create the patch -- you just +eager to help you with anything you will need to create the patch -- you just need to ask! We actively encourage you to contact us whenever you have any doubts. Don't be @@ -73,7 +76,7 @@ afraid that we will think worse of you when you ask too much. On the contrary: this is an occasion for you to show us that whenever there is something you don't know yet, you are able to learn quickly, and know how to ask for help :-) -As for the kind of change we want: Ideally, it would be some real improvement +As for the kind of change we want: ideally, it would be some real improvement (bug fix or new feature) in a part of the Hurd related to the specific project you want to work on. (This is not always possible though -- in that case, a useful change to some unrelated part of the Hurd would also do, or perhaps some @@ -104,7 +107,7 @@ And now that you are prepared to face the enemy, here we go :-) * Please describe the task of the project you want to work on, in your own words. Be as specific as possible. It's not sufficient to rephrase the -description from the project ideas page; show us that you actually understand +description from the project ideas page -- show us that you actually understand what this task involves! Read the available documentation (and possibly code) if necessary. And don't hesitate to ask us if you have any doubts :-) @@ -117,7 +120,7 @@ ready to be merged to mainline. Experience shows that adding the "final touches" necessary for that, tends to take up quite a lot of time -- there are always some bugs here and there, some misunderstandings about how things are supposed to work, build system issues, missing documentation, forgotten bits, -and so on. Thus, the schedule should suppose that a larger part of the main +and so on. Thus, the schedule should assume that a larger part of the main implementation work will be done by midterm! Also note that by the beginning of the summer session, you need to be able to -- cgit v1.2.3 From 140a155d907a3e44fd69822b418e2397db52747c Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 07:18:39 +0100 Subject: gsoc/student_application_form: add question about contact information --- community/gsoc/student_application_form.mdwn | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'community/gsoc') diff --git a/community/gsoc/student_application_form.mdwn b/community/gsoc/student_application_form.mdwn index 5862bce3..e1cab6c4 100644 --- a/community/gsoc/student_application_form.mdwn +++ b/community/gsoc/student_application_form.mdwn @@ -105,6 +105,10 @@ you are unsure about something. And now that you are prepared to face the enemy, here we go :-) +* Please supply your contact information here: full name, email address, IRC +nick, Jabber ID, phone number, etc. -- anything we might need to recognize you +and to keep in touch. + * Please describe the task of the project you want to work on, in your own words. Be as specific as possible. It's not sufficient to rephrase the description from the project ideas page -- show us that you actually understand -- cgit v1.2.3 From 73457ea1f5ac3663bfc6890de97f87823fa493a4 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 07:26:11 +0100 Subject: gsoc/student_application_form: add question for introduction --- community/gsoc/student_application_form.mdwn | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'community/gsoc') diff --git a/community/gsoc/student_application_form.mdwn b/community/gsoc/student_application_form.mdwn index e1cab6c4..dcf9909c 100644 --- a/community/gsoc/student_application_form.mdwn +++ b/community/gsoc/student_application_form.mdwn @@ -109,6 +109,10 @@ And now that you are prepared to face the enemy, here we go :-) nick, Jabber ID, phone number, etc. -- anything we might need to recognize you and to keep in touch. +* Introduce yourself: who are you, where are you from, what do you do, how did +you get here... Don't write a long essay here -- just a bunch of basic facts +you think we should know, so we get some idea whom we are talking to :-) + * Please describe the task of the project you want to work on, in your own words. Be as specific as possible. It's not sufficient to rephrase the description from the project ideas page -- show us that you actually understand -- cgit v1.2.3 From 86c987aaf3d5013406755f2f142ae271d8c4754b Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 08:16:38 +0100 Subject: gsoc/organization_application: half the packages? 65% now! --- community/gsoc/organization_application.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index b2ec557d..3df9e719 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -46,7 +46,7 @@ approach. To offer these possibilities, the Hurd uses a true multiserver microkernel architecture. That makes it quite unique: The Hurd is the only general-purpose multiserver microkernel system in development today that is nearly ready for -everyday use, and offering almost perfect UNIX compatibility. (More than half +everyday use, and offering almost perfect UNIX compatibility. (Almost 65% of the packages in the Debian repository are available for the Hurd.) All other existing true microkernel systems are either research projects not nearly complete enough for actual use, or limited to embedded systems and other -- cgit v1.2.3 From e62808aad8db5f675010edf9bc409c3120765a37 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 10 Mar 2010 08:17:05 +0100 Subject: gsoc/organization_application: minor rewording --- community/gsoc/organization_application.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 3df9e719..ee8259b2 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -47,7 +47,7 @@ To offer these possibilities, the Hurd uses a true multiserver microkernel architecture. That makes it quite unique: The Hurd is the only general-purpose multiserver microkernel system in development today that is nearly ready for everyday use, and offering almost perfect UNIX compatibility. (Almost 65% -of the packages in the Debian repository are available for the Hurd.) All other +of all packages in the Debian repository are available for the Hurd.) All other existing true microkernel systems are either research projects not nearly complete enough for actual use, or limited to embedded systems and other special purposes, or both. -- cgit v1.2.3 From 178c1c37ab90f9693785af0a876ca816d8b7733e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 10 Mar 2010 08:42:45 +0100 Subject: community/gsoc: Clean up a bit. community/gsoc/2009: Tidy up. hurd/translator/unionfs: Mention that unionmount has been worked on as a GSoC 2009 project. --- community/gsoc.mdwn | 6 +++-- community/gsoc/2009.mdwm | 53 -------------------------------------------- community/gsoc/2009.mdwn | 23 +++++++++++++++++++ hurd/translator/unionfs.mdwn | 6 ++++- 4 files changed, 32 insertions(+), 56 deletions(-) delete mode 100644 community/gsoc/2009.mdwm create mode 100644 community/gsoc/2009.mdwn (limited to 'community/gsoc') diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index aa5a7c5b..1d93b37c 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -27,7 +28,8 @@ getting one slot each year. In 2008 we successfully participated on our own, no longer within the GNU project. Read about our five students' success on the [[2008]] page. -In 2009 we participated under the GNU umbrella with one slot again. +The next year, we participated under the GNU umbrella with one slot again. +Read about it on the [[2009]] page. # Joining in diff --git a/community/gsoc/2009.mdwm b/community/gsoc/2009.mdwm deleted file mode 100644 index ce3b26fb..00000000 --- a/community/gsoc/2009.mdwm +++ /dev/null @@ -1,53 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -[[!meta title="Google Summer of Code"]] - -# 2009 - -The GNU Hurd project this year unfortunately is not in the list of accepted -mentoring organizations. - -However, don't despair! This doesn't mean that you'd not be allowed to work on -your favorite GNU Hurd project. For one, there's the possibility that a slot -for your project can be allocated under the [auspices of the GNU -project](http://www.gnu.org/software/soc-projects/). Second, we're of course -always open to introducing newcomers to the world of the GNU Hurd outside of -any Google Summer of whatever project. Just pick a task from the list pointed -to below on this page and get in touch with us! - - - -The applications have been evaluated and the following student has -been accepted: - - * [[Sergiu Ivanov|scolobb]] - - -# History - -2006 and 2007 we participated in GSoC under the umbrella of the GNU project, -getting one slot each year. - - - -In 2008 we successfully participated on our own, no longer within the GNU -project. Read about our five students' success on the [[2008]] page. - - -# Joining in - -If these successes got you interested in contributing some larger part yourself - -in your free time or maybe in next years Google Summer of Code - -please have a look at our [[project_ideas]] and read up about [[contributing]]. - -Also, feel free to ask your questions at one of our -[[regular_IRC_meetings|IRC#regular_meetings]]. diff --git a/community/gsoc/2009.mdwn b/community/gsoc/2009.mdwn new file mode 100644 index 00000000..6efeb839 --- /dev/null +++ b/community/gsoc/2009.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Google Summer of Code 2009"]] + +The GNU Hurd project unfortunately was not in the list of accepted +mentoring organizations. + +We did get one slot from the GNU project's. + +The applications have been evaluated and the following student has +been accepted: + + * [[Sergiu Ivanov|scolobb]] -- working on a *[[VFS-style union + mount|hurd/translator/unionmount]]* functionality; [Google's project + page](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/karlberry/t124022551214). diff --git a/hurd/translator/unionfs.mdwn b/hurd/translator/unionfs.mdwn index 331ad19f..d1e3868b 100644 --- a/hurd/translator/unionfs.mdwn +++ b/hurd/translator/unionfs.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -73,6 +74,9 @@ both for comparision.) The ethernet multiplexer shall serve as an example use case -- any changes necessary to allow using it with the union mount functionality are also to be considered part of the task. +[[Sergiu Ivanov|scolobb]] has been working on this as a [[Google Summer of Code +2009 project|community/gsoc/2009]]. + ## Implementation ### Source -- cgit v1.2.3 From 5a615978181a1b8d85326d8cf3137ed4b0b46bf7 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 10 Mar 2010 08:56:44 +0100 Subject: community/gsoc/project_ideas/driver_glue_code: Add a link to Zheng Da's status page. --- community/gsoc/project_ideas/driver_glue_code.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn index a4462133..4e1dab90 100644 --- a/community/gsoc/project_ideas/driver_glue_code.mdwn +++ b/community/gsoc/project_ideas/driver_glue_code.mdwn @@ -45,4 +45,5 @@ driver framework in GNU Mach. Completing the port might be too involved for the exercise; but it's pretty likely that you will find something else to improve in the glue code while working on this... -*Status*: Zheng Da is working on DDE, and has mostly completed the initial port. +*Status*: [[Zheng Da|zhengda]] is working on DDE, and has mostly completed the +initial port. -- cgit v1.2.3 From 6eb6d5314e303379debbef82921a215ef2b00d98 Mon Sep 17 00:00:00 2001 From: Carl Fredrik Hammar Date: Wed, 10 Mar 2010 16:19:06 +0100 Subject: Fix typos and spelling on GSoC pages --- community/gsoc/project_ideas.mdwn | 2 +- community/gsoc/project_ideas/disk_io_performance.mdwn | 12 ++++++------ community/gsoc/project_ideas/download_backends.mdwn | 4 ++-- community/gsoc/project_ideas/driver_glue_code.mdwn | 6 +++--- community/gsoc/project_ideas/dtrace.mdwn | 6 +++--- community/gsoc/project_ideas/file_locking.mdwn | 2 +- community/gsoc/project_ideas/gnat.mdwn | 4 ++-- community/gsoc/project_ideas/gnumach_cleanup.mdwn | 6 +++--- community/gsoc/project_ideas/language_bindings.mdwn | 4 ++-- community/gsoc/project_ideas/lexical_dot-dot.mdwn | 2 +- community/gsoc/project_ideas/libcap.mdwn | 2 +- community/gsoc/project_ideas/libdiskfs_locking.mdwn | 4 ++-- community/gsoc/project_ideas/libgtop.mdwn | 4 ++-- community/gsoc/project_ideas/mtab.mdwn | 6 +++--- .../project_ideas/namespace-based_translator_selection.mdwn | 8 ++++---- community/gsoc/project_ideas/nfs.mdwn | 4 ++-- community/gsoc/project_ideas/package_manager.mdwn | 2 +- community/gsoc/project_ideas/procfs.mdwn | 2 +- community/gsoc/project_ideas/secure_chroot.mdwn | 6 +++--- community/gsoc/project_ideas/server_overriding.mdwn | 4 ++-- community/gsoc/project_ideas/sound.mdwn | 2 +- community/gsoc/project_ideas/tcp_ip_stack.mdwn | 2 +- community/gsoc/project_ideas/tmpfs.mdwn | 2 +- community/gsoc/project_ideas/unionfs_boot.mdwn | 2 +- community/gsoc/project_ideas/virtualization.mdwn | 6 +++--- community/gsoc/project_ideas/vm_tuning.mdwn | 4 ++-- community/gsoc/project_ideas/xattr.mdwn | 2 +- community/gsoc/student_application_form.mdwn | 12 ++++++------ 28 files changed, 61 insertions(+), 61 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 96d93869..2046db9e 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -39,7 +39,7 @@ Try to find something to improve in the relevant code, by looking at known issues in the [Savannah bug tracker](http://savannah.gnu.org/bugs/?group=hurd); by running the code and testing stuff; and by looking through the code. If you don't find anything, try with some related code -- if you task involves -translator programming, make some improvement to an existing translor; if it +translator programming, make some improvement to an existing translator; if it involves glibc hacking, make an improvement to glibc; if it involves driver hacking, make an improvement to the driver framework; and so on... Makes sense, doesn't it? :-) diff --git a/community/gsoc/project_ideas/disk_io_performance.mdwn b/community/gsoc/project_ideas/disk_io_performance.mdwn index bb047308..b6c857b0 100644 --- a/community/gsoc/project_ideas/disk_io_performance.mdwn +++ b/community/gsoc/project_ideas/disk_io_performance.mdwn @@ -11,21 +11,21 @@ is included in the section entitled [[!meta title="Disk I/O Performance Tuning"]] The most obvious reason for the Hurd feeling slow compared to mainstream -systems like GNU/Linux, is very slow harddisk access. +systems like GNU/Linux, is very slow hard disk access. The reason for this slowness is lack and/or bad implementation of common -optimisation techniques, like scheduling reads and writes to minimalize head +optimization techniques, like scheduling reads and writes to minimize head movement; effective block caching; effective reads/writes to partial blocks; reading/writing multiple blocks at once; and read-ahead. The [[ext2_filesystem_server|hurd/translator/ext2fs]] might also need some -optimisations at a higher logical level. +optimizations at a higher logical level. The goal of this project is to analyze the current situation, and implement/fix -various optimisations, to achieve significantly better disk performance. It +various optimizations, to achieve significantly better disk performance. It requires understanding the data flow through the various layers involved in -disk acces on the Hurd ([[filesystem|hurd/virtual_file_system]], +disk access on the Hurd ([[filesystem|hurd/virtual_file_system]], [[pager|hurd/libpager]], driver), and general experience with -optimising complex systems. That said, the killing feature we are definitely +optimizing complex systems. That said, the killing feature we are definitely missing is the read-ahead, and even a very simple implementation would bring very big performance speedups. diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn index 749597a6..f794e814 100644 --- a/community/gsoc/project_ideas/download_backends.mdwn +++ b/community/gsoc/project_ideas/download_backends.mdwn @@ -19,7 +19,7 @@ Download protocols like FTP, HTTP, BitTorrent etc. are very good candidates for this kind of modularization: a program could simply use the download functionality by accessing FTP, HTTP etc. translators. -There is already an ftpfs traslator in the Hurd tree, as well as an [httpfs +There is already an ftpfs translator in the Hurd tree, as well as an [httpfs translator on hurdextras](http://www.nongnu.org/hurdextras/#httpfs); however, these are only suitable for very simple use cases: they just provide the actual file contents downloaded from the URL, but no additional status information @@ -35,7 +35,7 @@ The goal of this project is to design a suitable interface, implement it for at least one download protocol, and adapt apt-get (or some other program) to use this as a backend. -This task requires some design skills and some knowlegde of internet protocols, +This task requires some design skills and some knowledge of internet protocols, to create a suitable interface. Translator programming knowledge will have to be obtained while implementing it. diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn index 4e1dab90..4e1e338c 100644 --- a/community/gsoc/project_ideas/driver_glue_code.mdwn +++ b/community/gsoc/project_ideas/driver_glue_code.mdwn @@ -11,8 +11,8 @@ is included in the section entitled [[!meta title="New Driver Glue Code"]] -Although a driver framework in userspace would be desirable, presently the Hurd -uses kernel drivers in the microkernel, +Although a driver framework in user space would be desirable, presently the Hurd +uses kernel drivers in the micro kernel, [[GNU_Mach|microkernel/mach/gnumach]]. (And changing this would be far beyond a GSoC project...) @@ -23,7 +23,7 @@ this project is to redo the glue code, so we can use drivers from current Linux versions, or from one of the free BSD variants. While it would be certainly possible to create custom glue code again, a more -sustainable and probably also easier approch is to use +sustainable and probably also easier approach is to use [[DDE]] instead -- it already does the hard work of providing an environment where the foreign drivers can run, and has the additional advantage of being externally maintained. diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn index 93c2a5f3..25e6db29 100644 --- a/community/gsoc/project_ideas/dtrace.mdwn +++ b/community/gsoc/project_ideas/dtrace.mdwn @@ -16,9 +16,9 @@ problems, these are mostly just guesses. Better understanding what really causes bad performance is necessary to improve the situation. For that, we need tools for performance measurements. While all kinds of more -or less specific profiling tools could be convieved, the most promising and +or less specific profiling tools could be conceived, the most promising and generic approach seems to be a framework for logging certain events in the -running system (both in the microkernel and in the Hurd servers). This would +running system (both in the micro kernel and in the Hurd servers). This would allow checking how much time is spent in certain modules, how often certain situations occur, how things interact, etc. It could also prove helpful in debugging some issues that are otherwise hard to find because of complex @@ -34,7 +34,7 @@ with integrating existing components as well as low-level programming. Possible mentors: Samuel Thibault (youpi) -Exercise: In lack of a good exercise directly related to this taks, just pick +Exercise: In lack of a good exercise directly related to this task, just pick one of the kernel-related or generally low-level tasks from the bug/task trackers on savannah, and make a go at it. You might not be able to finish the task in a limited amount of time, but you should at least be able to make a diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn index af010c98..0159b091 100644 --- a/community/gsoc/project_ideas/file_locking.mdwn +++ b/community/gsoc/project_ideas/file_locking.mdwn @@ -10,7 +10,7 @@ is included in the section entitled [[!meta title="Fix and Complete File Locking Support"]] -Over the years, [[UNIX]] has aquired a host of different file locking mechanisms. +Over the years, [[UNIX]] has acquired a host of different file locking mechanisms. Some of them work on the Hurd, while others are buggy or only partially implemented. This breaks many applications. diff --git a/community/gsoc/project_ideas/gnat.mdwn b/community/gsoc/project_ideas/gnat.mdwn index b7f2ea62..97a4a552 100644 --- a/community/gsoc/project_ideas/gnat.mdwn +++ b/community/gsoc/project_ideas/gnat.mdwn @@ -15,9 +15,9 @@ also a number of other Debian packages depending on GNAT, and thus not buildable on the Hurd. The goal of this project is getting GNAT fully working in Debian GNU/Hurd. It -requires implementing some explicitely system-specific stuff in GNAT, and maybe +requires implementing some explicitly system-specific stuff in GNAT, and maybe fixing a few other problems. Good knowledge of Ada is a must; some Hurd -knowledge will have to be aquired while working on the project. +knowledge will have to be acquired while working on the project. Possible mentors: Samuel Thibault (youpi) diff --git a/community/gsoc/project_ideas/gnumach_cleanup.mdwn b/community/gsoc/project_ideas/gnumach_cleanup.mdwn index e75c9d3e..954e1242 100644 --- a/community/gsoc/project_ideas/gnumach_cleanup.mdwn +++ b/community/gsoc/project_ideas/gnumach_cleanup.mdwn @@ -10,8 +10,8 @@ is included in the section entitled [[!meta title="GNU Mach Code Cleanup"]] -Although there are some attempts to move to a more modern microkernel -alltogether, the current Hurd implementation is based on +Although there are some attempts to move to a more modern micro kernel +altogether, the current Hurd implementation is based on [[GNU_Mach|microkernel/mach/gnumach]], which is only a slightly modified variant of the original CMU [[microkernel/Mach]]. @@ -19,7 +19,7 @@ Unfortunately, Mach was created about two decades ago, and is in turn based on even older BSD code. Parts of the BSD kernel -- file systems, [[UNIX]] [[mechanism]]s like processes and signals, etc. -- were ripped out (to be implemented in [[userspace_servers|hurd/translator]] instead); while other mechanisms were -added to allow implementing stuff in userspace. +added to allow implementing stuff in user space. ([[Pager_interface|microkernel/mach/external_pager_mechanism]], [[microkernel/mach/IPC]], etc.) diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn index 8b493e19..a27b0d30 100644 --- a/community/gsoc/project_ideas/language_bindings.mdwn +++ b/community/gsoc/project_ideas/language_bindings.mdwn @@ -30,10 +30,10 @@ Several approaches are possible when creating such bindings. One way is simply to provide wrappers to all the available C libraries ([[hurd/libtrivfs]], [[hurd/libnetfs]] etc.). While this is easy (it requires relatively little consideration), it may not be the optimal solution. It is preferable to hook in at a lower level, thus -being able te create interfaces that are specially adapted to make good use of +being able to create interfaces that are specially adapted to make good use of the features available in the respective language. -These more specialised bindings could hook in at some of the lower level +These more specialized bindings could hook in at some of the lower level library interfaces ([[hurd/libports]], [[hurd/glibc]], etc.); use the [[microkernel/mach/MIG]]-provided [[microkernel/mach/RPC]] stubs directly; or even create native stubs directly from the interface definitions. The diff --git a/community/gsoc/project_ideas/lexical_dot-dot.mdwn b/community/gsoc/project_ideas/lexical_dot-dot.mdwn index 764cd37f..e0dabc01 100644 --- a/community/gsoc/project_ideas/lexical_dot-dot.mdwn +++ b/community/gsoc/project_ideas/lexical_dot-dot.mdwn @@ -22,7 +22,7 @@ resolution. Some application already use lexical resolution internally for that reason. It is generally agreed that many problems could be avoided if the standard filesystem lookup calls used lexical resolution as well. The compatibility -problems probably would be negligable. +problems probably would be negligible. The goal of this project is to modify the filename lookup mechanism in the Hurd to use lexical resolution, and to check that the system is still fully diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn index 10ca508e..875b462f 100644 --- a/community/gsoc/project_ideas/libcap.mdwn +++ b/community/gsoc/project_ideas/libcap.mdwn @@ -14,7 +14,7 @@ libcap is a library providing the API to access POSIX capabilities. These allow giving various kinds of specific privileges to individual users, without giving them full root permissions. -Although the Hurd design should faciliate implementing such features in a quite +Although the Hurd design should facilitate implementing such features in a quite natural fashion, there is no support for POSIX capabilities yet. As a consequence, libcap is not available on the Hurd, and thus various packages using it can not be easily built in Debian GNU/Hurd. diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn index 2a08b387..570a9581 100644 --- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn +++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn @@ -18,8 +18,8 @@ faulty paths causing these lockups. The task is systematically checking the [[hurd/libdiskfs]] code for this kind of locking issues. To achieve this, some kind of test harness has to be implemented: For -exmple instrumenting the code to check locking correctness constantly at -runtime. Or implementing a unit testing framework that explicitely checks +example instrumenting the code to check locking correctness constantly at +runtime. Or implementing a unit testing framework that explicitly checks locking in various code paths. (The latter could serve as a template for implementing unit checks in other parts of the Hurd codebase...) diff --git a/community/gsoc/project_ideas/libgtop.mdwn b/community/gsoc/project_ideas/libgtop.mdwn index ef1b2bcb..14304de2 100644 --- a/community/gsoc/project_ideas/libgtop.mdwn +++ b/community/gsoc/project_ideas/libgtop.mdwn @@ -24,9 +24,9 @@ The goal of this project is a fully functional libgtop in Debian GNU/Hurd. Some application(s) using it also need to be ported, e.g. gnome-system-monitor. Some bits of this work are easy, others need some digging into Hurd internals. -This task doesn't require any specific previous knowlegde (besides of general +This task doesn't require any specific previous knowledge (besides of general C/UNIX programming skills of course); but during the course of the project, -some knowlegde about Hurd internals will have to be obtained, along with a bit +some knowledge about Hurd internals will have to be obtained, along with a bit of Debian stuff. Possible mentors: Samuel Thibault (youpi) diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn index 60dde525..a60a8038 100644 --- a/community/gsoc/project_ideas/mtab.mdwn +++ b/community/gsoc/project_ideas/mtab.mdwn @@ -22,7 +22,7 @@ is no central place keeping track of mounts. As a consequence, there is currently no easy way to obtain a listing of all mounted file systems. This also means that commands like `df` can only work on -explicitely specified mountpoints, instead of displaying the usual listing. +explicitly specified mountpoints, instead of displaying the usual listing. One possible solution to this would be for the translator startup mechanism to update the `mtab` on any `mount`/`unmount`, like in traditional systems. @@ -31,7 +31,7 @@ with passive translators, i.e., translators that are not presently running, but set up to be started automatically whenever the node is accessed? Probably these should be counted among the mounted filesystems; but how to handle the `mtab` updates for a translator that is not started yet? Generally, being -centralized and event-based, this is a pretty unelegant, non-hurdish solution. +centralized and event-based, this is a pretty inelegant, non-hurdish solution. A more promising approach is to have `mtab` exported by a special translator, which gathers the necessary information on demand. This could work by @@ -64,7 +64,7 @@ other filtering rules might be desirable. After taking decisions on the outstanding design questions, the student will implement both the actual [[mtab_translator|hurd/translator/mtabfs]], and the -necessery interface(s) for gathering the data. It requires getting a good +necessary interface(s) for gathering the data. It requires getting a good understanding of the translator mechanism and Hurd interfaces in general. Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar) diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn index d40d73ac..67e3fc28 100644 --- a/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn +++ b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn @@ -8,7 +8,7 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title="Namspace-based Translator Selection"]] +[[!meta title="Namespace-based Translator Selection"]] The main idea behind the Hurd is to make (almost) all system functionality user-modifiable ([[extensible_system|extensibility]]). This includes a @@ -26,7 +26,7 @@ file, and presents a virtual file with the uncompressed contents. Or the other way around. Or a translator that presents an [[XML_file_as_a_directory_tree|hurd/translator/xmlfs]]. Or an mbox as a set of individual files for each mail ([[hurd/translator/mboxfs]]); or ever further -breaking it down into headers, body, attachements... +breaking it down into headers, body, attachments... This gets even more powerful when translators are used as building blocks for larger applications: A mail reader for example doesn't need backends for @@ -40,7 +40,7 @@ There are a few problems with the way translators are set, though. For one, once a translator is set on a node, you always see the translated content. If you need the untranslated contents again, to do a backup for example, you first need to remove the translator again. Also, having to set a translator -explicitely before accessing the contents is pretty cumbersome, making this +explicitly before accessing the contents is pretty cumbersome, making this feature almost useless. A possible solution is implementing a mechanism for selecting translators @@ -61,7 +61,7 @@ place of the original ones. In the long run it's probably desirable to have the mechanism implemented in the standard name lookup mechanism, so it will be available globally, and avoid -the overhead of a proxy; but for the beginnig the proxy solution is much more +the overhead of a proxy; but for the beginning the proxy solution is much more flexible. The goal of this project is implementing a prototype proxy; perhaps also a diff --git a/community/gsoc/project_ideas/nfs.mdwn b/community/gsoc/project_ideas/nfs.mdwn index 683287f7..e7c18324 100644 --- a/community/gsoc/project_ideas/nfs.mdwn +++ b/community/gsoc/project_ideas/nfs.mdwn @@ -11,12 +11,12 @@ is included in the section entitled [[!meta title="Improved NFS Implementation"]] The Hurd has both NFS server and client implementations, which work, but not -very well: File locking doesn't work properly (at least in conjuction with a +very well: File locking doesn't work properly (at least in conjunction with a GNU/Linux server), and performance is extremely poor. Part of the problems could be owed to the fact that only NFSv2 is supported so far. (Note though that locking on the Hurd is problematic in general, not only in -conjuction with NFS -- see the [[file_locking]] task.) +conjunction with NFS -- see the [[file_locking]] task.) This project encompasses implementing NFSv3 support, fixing bugs and performance problems -- the goal is to have good NFS support. The work done in diff --git a/community/gsoc/project_ideas/package_manager.mdwn b/community/gsoc/project_ideas/package_manager.mdwn index 43e53f7c..23304f6b 100644 --- a/community/gsoc/project_ideas/package_manager.mdwn +++ b/community/gsoc/project_ideas/package_manager.mdwn @@ -37,7 +37,7 @@ came about. There are no global databases of any kind. (Some things might require caching for better performance, but this must happen transparently.) The core of this approach is formed by [[hurd/translator/stowfs]], which -creates a traditional unix directory structure from all the files in the +creates a traditional Unix directory structure from all the files in the individual package directories. But this only handles the lowest level of package management. Additional mechanisms are necessary to handle stuff like dependencies on other packages. diff --git a/community/gsoc/project_ideas/procfs.mdwn b/community/gsoc/project_ideas/procfs.mdwn index 85eec43c..d4760aae 100644 --- a/community/gsoc/project_ideas/procfs.mdwn +++ b/community/gsoc/project_ideas/procfs.mdwn @@ -33,7 +33,7 @@ interfaces.) This project requires learning [[hurd/translator]] programming, and understanding some of the internals of process management in the Hurd. It should not be too hard coding-wise; and the task is very nicely defined by the -exising Linux `/proc` interface -- no design considerations necessary. +existing Linux `/proc` interface -- no design considerations necessary. **Note**: We already have several applications for this task. diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn index 0a08bbf5..feb30a7c 100644 --- a/community/gsoc/project_ideas/secure_chroot.mdwn +++ b/community/gsoc/project_ideas/secure_chroot.mdwn @@ -16,10 +16,10 @@ good, as it allows easily escaping the `chroot`, for example by use of [[passive_translators|hurd/translator]]. Many solutions have been suggested for this problem -- ranging from simple -workaround changing the behaviour of passive translators in a `chroot`; -changing the context in which passive translators are exectuted; changing the +workaround changing the behavior of passive translators in a `chroot`; +changing the context in which passive translators are executed; changing the interpretation of filenames in a chroot; to reworking the whole passive -translator mechanism. Some involving a completely different approch to +translator mechanism. Some involving a completely different approach to `chroot` implementation, using a proxy instead of a special system call in the filesystem servers. diff --git a/community/gsoc/project_ideas/server_overriding.mdwn b/community/gsoc/project_ideas/server_overriding.mdwn index 80beab4c..c35d88de 100644 --- a/community/gsoc/project_ideas/server_overriding.mdwn +++ b/community/gsoc/project_ideas/server_overriding.mdwn @@ -14,7 +14,7 @@ The main idea of the Hurd is that every user can influence almost all system functionality ([[extensible_system|extensibility]]), by running private Hurd servers that replace or proxy the global default implementations. -However, running such a cumstomized subenvironment presently is not easy, +However, running such a customized subenvironment presently is not easy, because there is no standard mechanism to easily replace an individual standard server, keeping everything else. (Presently there is only the [[hurd/subhurd]] method, which creates a completely new system instance with a completely @@ -40,7 +40,7 @@ mechanism would have to check an override table on each lookup, and apply the desired replacement whenever a match is found. Another approach would be server-side overrides. Again there are various -variants. The actual servers themself could provide a mechanism to redirect to +variants. The actual servers themselves could provide a mechanism to redirect to other servers on request. (3) Or we could use some more generic server-side namespace overrides: Either all filesystem servers could provide a mechanism to modify the namespace they export to certain clients (4), or proxies could be diff --git a/community/gsoc/project_ideas/sound.mdwn b/community/gsoc/project_ideas/sound.mdwn index b92f76da..8411831b 100644 --- a/community/gsoc/project_ideas/sound.mdwn +++ b/community/gsoc/project_ideas/sound.mdwn @@ -36,7 +36,7 @@ Possible mentors: Samuel Thibault (youpi) Exercise: This project requires kernel (driver framework) hacking as well as some Hurd server hacking; so the exercise should involve either of these, or even both. You could for example port some newer driver to run in the existing -framework (see the [[device_driver|driver_glue_code]] project descrption), or +framework (see the [[device_driver|driver_glue_code]] project description), or try to make some fix(es) to the [unfinished random device implementation](http://savannah.gnu.org/patch/?6088) created by Michael Casadevall. diff --git a/community/gsoc/project_ideas/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn index b56bff51..735c8bbb 100644 --- a/community/gsoc/project_ideas/tcp_ip_stack.mdwn +++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn @@ -21,7 +21,7 @@ more flexibly. Rather than just having the standard socket interface, plus some lower-level hooks for special needs, there are explicit (perhaps filesystem-based) interfaces at all the individual levels; special application can just directly access the desired layer. All kinds of packet filtering, -routing, tunneling etc. can be easily achieved by stacking compononts in the +routing, tunneling etc. can be easily achieved by stacking components in the desired constellation. Implementing a complete modular network stack is not feasible as a GSoC diff --git a/community/gsoc/project_ideas/tmpfs.mdwn b/community/gsoc/project_ideas/tmpfs.mdwn index 93215d07..63b4effe 100644 --- a/community/gsoc/project_ideas/tmpfs.mdwn +++ b/community/gsoc/project_ideas/tmpfs.mdwn @@ -15,7 +15,7 @@ actual disk storage, but only by anonymous memory, i.e. lives in the RAM (and possibly swap space). A simplistic way to implement such a memory filesystem is literally creating a -ramdisk, i.e. simply allocating a big chunck of RAM (called a memory store in +ramdisk, i.e. simply allocating a big chunk of RAM (called a memory store in Hurd terminology), and create a normal filesystem like ext2 on that. However, this is not very efficient, and not very convenient either (the filesystem needs to be recreated each time the ramdisk is invoked). A nicer solution is diff --git a/community/gsoc/project_ideas/unionfs_boot.mdwn b/community/gsoc/project_ideas/unionfs_boot.mdwn index 6c83092b..d9f1a9e1 100644 --- a/community/gsoc/project_ideas/unionfs_boot.mdwn +++ b/community/gsoc/project_ideas/unionfs_boot.mdwn @@ -11,7 +11,7 @@ is included in the section entitled [[!meta title="Allow Using unionfs Early at Boot"]] In [[UNIX]] systems, traditionally most software is installed in a common directory -hierachy, where files from various packages live beside each other, grouped by +hierarchy, where files from various packages live beside each other, grouped by function: user-invokable executables in `/bin`, system-wide configuration files in `/etc`, architecture specific static files in `/lib`, variable data in `/var`, and so on. To allow clean installation, deinstallation, and upgrade of diff --git a/community/gsoc/project_ideas/virtualization.mdwn b/community/gsoc/project_ideas/virtualization.mdwn index 3a677306..822b8d99 100644 --- a/community/gsoc/project_ideas/virtualization.mdwn +++ b/community/gsoc/project_ideas/virtualization.mdwn @@ -25,7 +25,7 @@ desired constellations. The goal is to create a set of powerful tools for managing at least one desirable virtualization scenario. One possible starting point could be the [[hurd/subhurd]]/[[hurd/neighborhurd]] mechanism, which allows a second almost totally -independant instance of the Hurd in parallel to the main one. +independent instance of the Hurd in parallel to the main one. While subhurd allow creating a complete second system instance, with an own set of Hurd servers and [[UNIX]] daemons and all, there are also situations where it is @@ -35,8 +35,8 @@ to create such a subenvironment with a single command would be very helpful. It might be possible to implement (perhaps as a prototype) a wrapper using existing tools (chroot and [[hurd/translator/unionfs]]); or it might require more specific tools, -like some kind of unionfs-like filesytem proxy that mirrors other parts of the -filesystem, but allows overriding individual locations, in conjuction with +like some kind of unionfs-like filesystem proxy that mirrors other parts of the +filesystem, but allows overriding individual locations, in conjunction with either chroot or some similar mechanism to create a subenvironment with a different root filesystem. diff --git a/community/gsoc/project_ideas/vm_tuning.mdwn b/community/gsoc/project_ideas/vm_tuning.mdwn index 9e802188..ecc5f9f4 100644 --- a/community/gsoc/project_ideas/vm_tuning.mdwn +++ b/community/gsoc/project_ideas/vm_tuning.mdwn @@ -14,7 +14,7 @@ Hurd/[[microkernel/Mach]] presently make very bad use of the available physical system. Some of the problems are inherent to the system design (the kernel can't distinguish between important application data and discardable disk buffers for example), and can't be fixed without fundamental changes. Other -problems however are an ordinary lack of optimisation, like extremely crude +problems however are an ordinary lack of optimization, like extremely crude heuristics when to start paging. (See for example.) Many parameters are based on assumptions from a time when typical machines had like 16 MiB of RAM, or simply have been set to @@ -23,7 +23,7 @@ arbitrary values and never tuned for actual use. The goal of this project is to bring the virtual memory management in Hurd/Mach closer to that of modern mainstream kernels (Linux, FreeBSD), by comparing the implementation to other systems, implementing any worthwhile improvements, and -general optimisation/tuning. It requires very good understanding of the Mach +general optimization/tuning. It requires very good understanding of the Mach VM, and virtual memory in general. This project is related to [[!GNU_Savannah_task 5489]]. diff --git a/community/gsoc/project_ideas/xattr.mdwn b/community/gsoc/project_ideas/xattr.mdwn index 55961547..7178d826 100644 --- a/community/gsoc/project_ideas/xattr.mdwn +++ b/community/gsoc/project_ideas/xattr.mdwn @@ -21,7 +21,7 @@ fields in the inode to store Hurd-specific metadata: most notable passive translator settings. As these fields are Hurd-specific, they can't be accessed by the standard methods from Linux for example, so it's not possible to fully work with a Hurd filesystem on GNU/Linux (copy, backup etc.); and also, even -when on Hurd, only tools that explicitely support the Hurd-specific information +when on Hurd, only tools that explicitly support the Hurd-specific information can handle them. Using extended attributes instead of custom fields for the Hurd-specific diff --git a/community/gsoc/student_application_form.mdwn b/community/gsoc/student_application_form.mdwn index dcf9909c..ba339dc9 100644 --- a/community/gsoc/student_application_form.mdwn +++ b/community/gsoc/student_application_form.mdwn @@ -37,14 +37,14 @@ be patient and hang on, or try again later.) Contacting us as soon as possible is crucial, as regular communication is the single most important factor for a successful GSoC project. We need to see that -you are able and willing to talk to us regularily. Also, we get to +you are able and willing to talk to us regularly. Also, we get to know you much better this way than what the application form alone would allow us to. You shouldn't be at a loss for reasons to contact us. You ought to discuss your -project and application with us for exmple -- you will gain a much better idea +project and application with us for example -- you will gain a much better idea about the project, our expectations etc. In short, you will be able to -submit a better application right from the beginnig, saving both yourself and -us some tedious roundtrips :-) +submit a better application right from the beginning, saving both yourself and +us some tedious round trips :-) Also, if you really want to get involved with the Hurd project, there are surely many things you will want to know -- after all, it's a fascinating @@ -174,12 +174,12 @@ the application process. * Do you have a permanent internet connection, especially during the time of the summer session? Are you able and willing to hang out on the Hurd IRC -channel regularily? (As in: Running the IRC client more or less permanently and +channel regularly? (As in: Running the IRC client more or less permanently and checking for activity now and then.) If it turns out that your mentor lives in a different time zone, could you shift your day/night rhythm to better match that of your mentor and other Hurd developers? -Hint: Hanging out on the channel regularily during the application process +Hint: Hanging out on the channel regularly during the application process would be a good start :-) * When does your university term end, when are your exams, and when does the -- cgit v1.2.3 From b9ca19e2ff05a00e7f1bc26176e4e6ad1028b03f Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 10 Mar 2010 16:20:12 +0100 Subject: community/gsoc/2007: New. --- community/gsoc.mdwn | 8 ++++---- community/gsoc/2007.mdwn | 16 ++++++++++++++++ 2 files changed, 20 insertions(+), 4 deletions(-) create mode 100644 community/gsoc/2007.mdwn (limited to 'community/gsoc') diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index 1d93b37c..b8d843ff 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -20,12 +20,12 @@ and the [[project_ideas]] list. # History -2006 and 2007 we participated in GSoC under the umbrella of the GNU project, +In 2006 and [[2007]], we participated in GSoC under the umbrella of the GNU +project, getting one slot each year. - - -In 2008 we successfully participated on our own, no longer within the GNU +In the following year, we successfully participated on our own, not only as a +suborganization of the GNU project. Read about our five students' success on the [[2008]] page. The next year, we participated under the GNU umbrella with one slot again. diff --git a/community/gsoc/2007.mdwn b/community/gsoc/2007.mdwn new file mode 100644 index 00000000..fa22f785 --- /dev/null +++ b/community/gsoc/2007.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Participated under the umbrella of the GNU project, getting one slot: + + * Carl Fredrik Hammar has been working on [[hurd/libchannel]]; [Google's + project + page](http://code.google.com/soc/2007/gnu/appinfo.html?csaid=44FB3FD69C665A08). -- cgit v1.2.3 From 7f786419b9c8026a8ab9e36b04fd4cadaf1fb527 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Thu, 11 Mar 2010 00:55:16 +0100 Subject: Add more information --- community/gsoc/project_ideas/debian_installer.mdwn | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas/debian_installer.mdwn b/community/gsoc/project_ideas/debian_installer.mdwn index ca10a61e..d182c4ee 100644 --- a/community/gsoc/project_ideas/debian_installer.mdwn +++ b/community/gsoc/project_ideas/debian_installer.mdwn @@ -21,6 +21,15 @@ Some preliminary work has been done, see The goal is to have the Debian Installer fully working on the Hurd. It requires relatively little Hurd-specific knowledge. +A lot of the "non-Linux support" part of the project has already been done thanks to a previous GSoC, so at least no ground reason should bar the project. A lot of the required udebs are already in Debian or are pending upload, so that building an image and booting it does already work. A preliminary list of what remains is + +* Add initrd support to GNU Mach, unless youpi does it before :) This should not be very complicated by re-using the iopl driver code. +* hurdify genext2fs to handle 4096 block size by default (see bug #562999) and support translator entries. +* Port busybox. This needs to be synchronized with kfreebsd people, who have probably already done some work, but that seemingly still hasn't been merged. In the meanwhile, youpi has a version with most of it disabled so a d-i image can actually be built. +* Port keyboard-setup to configure the xkb driver of the Hurd console + +As a starting point, students might wish to look at the current Debian installer source and build process. + Possible mentors: Samuel Thibault (youpi) -Exercise: Try to get one piece of the installer running on Hurd. +Exercise: Fix a couple of Hurd issues in busybox. -- cgit v1.2.3 From 1b076ae5402eae01a4630b4a617b806806f899ce Mon Sep 17 00:00:00 2001 From: Carl Fredrik Hammar Date: Thu, 11 Mar 2010 13:23:12 +0100 Subject: Spell it `microkernel' --- community/gsoc/project_ideas/driver_glue_code.mdwn | 2 +- community/gsoc/project_ideas/dtrace.mdwn | 2 +- community/gsoc/project_ideas/gnumach_cleanup.mdwn | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn index 4e1e338c..9c063e9f 100644 --- a/community/gsoc/project_ideas/driver_glue_code.mdwn +++ b/community/gsoc/project_ideas/driver_glue_code.mdwn @@ -12,7 +12,7 @@ is included in the section entitled [[!meta title="New Driver Glue Code"]] Although a driver framework in user space would be desirable, presently the Hurd -uses kernel drivers in the micro kernel, +uses kernel drivers in the microkernel, [[GNU_Mach|microkernel/mach/gnumach]]. (And changing this would be far beyond a GSoC project...) diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn index 25e6db29..4a46cf38 100644 --- a/community/gsoc/project_ideas/dtrace.mdwn +++ b/community/gsoc/project_ideas/dtrace.mdwn @@ -18,7 +18,7 @@ causes bad performance is necessary to improve the situation. For that, we need tools for performance measurements. While all kinds of more or less specific profiling tools could be conceived, the most promising and generic approach seems to be a framework for logging certain events in the -running system (both in the micro kernel and in the Hurd servers). This would +running system (both in the microkernel and in the Hurd servers). This would allow checking how much time is spent in certain modules, how often certain situations occur, how things interact, etc. It could also prove helpful in debugging some issues that are otherwise hard to find because of complex diff --git a/community/gsoc/project_ideas/gnumach_cleanup.mdwn b/community/gsoc/project_ideas/gnumach_cleanup.mdwn index 954e1242..4aef0d1b 100644 --- a/community/gsoc/project_ideas/gnumach_cleanup.mdwn +++ b/community/gsoc/project_ideas/gnumach_cleanup.mdwn @@ -10,7 +10,7 @@ is included in the section entitled [[!meta title="GNU Mach Code Cleanup"]] -Although there are some attempts to move to a more modern micro kernel +Although there are some attempts to move to a more modern microkernel altogether, the current Hurd implementation is based on [[GNU_Mach|microkernel/mach/gnumach]], which is only a slightly modified variant of the original CMU [[microkernel/Mach]]. -- cgit v1.2.3 From 3efc2c0ed4e4cf1154603cd83e68f8e4132ed347 Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 11 Mar 2010 15:24:10 +0100 Subject: gsoc/oranization_application: not "almost" 65% -- it's actually more than 65 --- community/gsoc/organization_application.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index ee8259b2..6a6389d8 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -46,7 +46,7 @@ approach. To offer these possibilities, the Hurd uses a true multiserver microkernel architecture. That makes it quite unique: The Hurd is the only general-purpose multiserver microkernel system in development today that is nearly ready for -everyday use, and offering almost perfect UNIX compatibility. (Almost 65% +everyday use, and offering almost perfect UNIX compatibility. (About 65% of all packages in the Debian repository are available for the Hurd.) All other existing true microkernel systems are either research projects not nearly complete enough for actual use, or limited to embedded systems and other -- cgit v1.2.3 From 74ee772de9661c54fe7658589f79e520bb8e0171 Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 12 Mar 2010 15:31:12 +0100 Subject: gsoc/organisation_application: fix some typos spotted by tschwinge --- community/gsoc/organization_application.mdwn | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 6a6389d8..471f3bdc 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -82,7 +82,7 @@ spreading technical and other knowledge about the Hurd among actual and potential contributors. Last but not least, we hope the participation will have a positive effect on -our community -- new impulses, increased communication etc. +our community -- new impulses, increased communication, etc. * Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. @@ -91,7 +91,7 @@ we participated under the umbrella of the GNU project, getting one slot each year. In 2008 we participated as an organisation on our own for the first time. This -turned out extremely beneficial: With the better visibility, we get a lot +turned out extremely beneficial: with the better visibility, we got a lot more applications (more than 20), mostly of good or excellent quality. In 2009, we were rejected as an organisation, so we participated under the GNU @@ -103,7 +103,7 @@ spite of not getting a slot. Half of them are regular Hurd contributors now. Selecting the most promising students, as well as suitable mentors, turned out to be the most tricky part of GSoC participation -- but we learned our lesson -after the first failure: We didn't have any students that didn't meet our +after the first failure: we didn't have any students that didn't meet our expectations since then, and we also believe our mentoring is exceptionally good now -- one project that was in serious trouble, turned out well after all, due to effective mentor intervention. @@ -169,7 +169,7 @@ their work, so that we get partial results at least if someone disappears. As our mentors all have been with the project for some time, the risk of them disappearing is not too big. If one of them disappears nevertheless, it's not a -problem for us: We have enough mentors, and someone else will take over. +problem for us: we have enough mentors, and someone else will take over. We will encourage the students to keep discussions public as much as possible, keeping private conversations with the mentors to a minimum, so the transition @@ -182,14 +182,14 @@ contact with us before the end of the student selection process, and won't consider their applications otherwise. This way we know that the students are able and willing to communicate with us in the first place. -After selection, the regular contact is kept up: We require the +After selection, the regular contact is kept up: we require the students to participate in IRC meetings up to twice a week, where we ask the students -actively about the work they do, problems they face, decisions they take etc. +actively about the work they do, problems they face, decisions they take, etc. Furthermore, we ask them to hang out on IRC most of the time while working on their projects, so we keep in close contact. We also require the students to join our main development mailing list, so any -design questions etc. can be discussed there. We encourage them to take +design questions, etc. can be discussed there. We encourage them to take part in other conversations, not directly related to their projects, as well. After the program we continue the regular meetings, discussing the further -- cgit v1.2.3 From b6a58c6837b338eb3661580d9e76b47e764f1489 Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 12 Mar 2010 15:54:47 +0100 Subject: gsoc/organization_application: Improve wording Mostly based on suggestions from tschwinge. --- community/gsoc/organization_application.mdwn | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 471f3bdc..a376ffaa 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -77,7 +77,7 @@ Aside from that, it is a way to make progress with tasks that require an amount focused work, that is hard to do for volunteers working in their spare time only. -Also it is a good opportunity to get valuable input from new people, as well as +Also, the Google Summer of Code is a good opportunity to get valuable input from new people, as well as spreading technical and other knowledge about the Hurd among actual and potential contributors. @@ -98,8 +98,8 @@ In 2009, we were rejected as an organisation, so we participated under the GNU umbrella again. While the 2006 student disappeared midway, in all the later years all of our -students were successful -- including even one who worked on his project in -spite of not getting a slot. Half of them are regular Hurd contributors now. +students were successful -- even including one who worked on his project in +spite of not getting an official slot. Half of them are regular Hurd contributors now. Selecting the most promising students, as well as suitable mentors, turned out to be the most tricky part of GSoC participation -- but we learned our lesson @@ -149,7 +149,7 @@ won't be left on their own with any problems they face. The plan is mostly to avoid that happening in the first place. To this end, we are particularily careful with selection of students: Making sure -that they have no other obligations during that time; that they are motivated +that they have no other major obligations during that time; that they are motivated enough; that they actually have the necessary skills to complete the task; that they fit in our community. @@ -163,7 +163,7 @@ project can perhaps be scaled down, or at least wrapped up to bring it in a state where it is useful even if not finished. We will also try to limit damage by insisting that students regularily check in -their work, so that we get partial results at least if someone disappears. +their work to our source repositories, so that we get partial results at least if someone disappears. * What is your plan for dealing with disappearing mentors? @@ -178,15 +178,15 @@ should go smoothly. * What steps will you take to encourage students to interact with your project's community before, during and after the program? We try to make it very clear that we expect the students to get into regular -contact with us before the end of the student selection process, and won't +contact with us early during the student selection process already, and won't consider their applications otherwise. This way we know that the students are able and willing to communicate with us in the first place. After selection, the regular contact is kept up: we require the students to participate in IRC meetings up to twice a week, where we ask the students actively about the work they do, problems they face, decisions they take, etc. -Furthermore, we ask them to hang out on IRC most of the time while -working on their projects, so we keep in close contact. +Furthermore, we ask them to be available on IRC while working on their +projects, so we can communicate easily. We also require the students to join our main development mailing list, so any design questions, etc. can be discussed there. We encourage them to take -- cgit v1.2.3 From ea716c653fd6daf08c77e06f433b90e80922ec91 Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 12 Mar 2010 17:08:38 +0100 Subject: gsoc/organisation_application: completely new take on focused work aspect --- community/gsoc/organization_application.mdwn | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index a376ffaa..f2910d0b 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -73,11 +73,15 @@ GNU General Public License (GPL) The primary goal of course is to find and introduce new long-term contributors to the project. -Aside from that, it is a way to make progress with tasks that require an amount of -focused work, that is hard to do for volunteers working in their spare time -only. - -Also, the Google Summer of Code is a good opportunity to get valuable input from new people, as well as +The mentor-student setup, together with the period of focused work during the +summer session, also offer a unique opportunity for kick-starting innovative +new projects apart from mainline development, which are hard to fit in among +the normal day-to-day development work. This is particularily important for the +Hurd, as innovative uses are crucial to show the benefits of the unique +architecture. Several such projects came into being through the GSoC program +over the past years. + +Moreover, the Google Summer of Code is a good opportunity to get valuable input from new people, as well as spreading technical and other knowledge about the Hurd among actual and potential contributors. -- cgit v1.2.3 From 3fe2f81d9c0750f555badbb9dd1139c5f836d4d9 Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 12 Mar 2010 17:29:13 +0100 Subject: gsoc/organisation_application: further rewording in "why participate?" section --- community/gsoc/organization_application.mdwn | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index f2910d0b..7023af65 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -70,8 +70,9 @@ GNU General Public License (GPL) * Why is your organization applying to participate in GSoC 2010? What do you hope to gain by participating? -The primary goal of course is to find and introduce new long-term contributors -to the project. +The primary goal of our participation is of course to find and introduce new long-term contributors +to the Hurd. We are trying to optimise for this in our student selection +process, our mentoring approach, and our choice of project ideas. The mentor-student setup, together with the period of focused work during the summer session, also offer a unique opportunity for kick-starting innovative @@ -81,11 +82,9 @@ Hurd, as innovative uses are crucial to show the benefits of the unique architecture. Several such projects came into being through the GSoC program over the past years. -Moreover, the Google Summer of Code is a good opportunity to get valuable input from new people, as well as +Last but not least, GSoC participation always yields a lot of valuable input from new people, and helps spreading technical and other knowledge about the Hurd among actual and -potential contributors. - -Last but not least, we hope the participation will have a positive effect on +potential contributors. It has a very positive effect on our community -- new impulses, increased communication, etc. * Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. -- cgit v1.2.3 From b593f5bd39ef21e58ff90cec504493dd653608e1 Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 12 Mar 2010 17:42:29 +0100 Subject: gsoc/organization_application: Reword section on partial results As we don't focus our participation on code produced during the summer, partial code is also not the major consideration when a project fails. --- community/gsoc/organization_application.mdwn | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 7023af65..2df2311f 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -162,11 +162,11 @@ time if things go wrong. If a student disappears in spite of that, there is little we can do. Of course we will try to contact him and find out what the problem is; whether the -project can perhaps be scaled down, or at least wrapped up to bring it in a -state where it is useful even if not finished. - -We will also try to limit damage by insisting that students regularily check in -their work to our source repositories, so that we get partial results at least if someone disappears. +project can perhaps be scaled down, or otherwise salvaged, so that the effort +already invested in the student and the project is not wasted. We also try to +make sure that all important design discussions are archieved, and that all +code produced is suitable for upstream inclusion from the beginning -- to allow +others to pick up the project if necessary, without having to start from zero. * What is your plan for dealing with disappearing mentors? -- cgit v1.2.3 From 3f316983c4d4ccafdf4a56645f22588e8c50dca8 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 12 Mar 2010 19:41:27 +0100 Subject: community/gsoc/organization_application: Add my Link ID for Backup Admin purposes. --- community/gsoc/organization_application.mdwn | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 2df2311f..6775a854 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -211,3 +212,4 @@ program, and generally help keeping them involved. * Backup Admin (Link ID): +tschwinge -- cgit v1.2.3 From de8c9d0ecabe8917e22963c43615b123dc1e5c20 Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 12 Mar 2010 21:33:09 +0100 Subject: gsoc/organization_application: rework description of Hurd project Almost completely rewrote most of the description, dropping the politics, and focusing on the points I have been trying to emphasise in my recent Hurd presentations. --- community/gsoc/organization_application.mdwn | 72 +++++++++++++--------------- 1 file changed, 34 insertions(+), 38 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 6775a854..8ec61c12 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -20,46 +20,42 @@ for the [GNU operating system](http://gnu.org), which is viable for everyday use, and gives users and programs as much control over their computing environment as possible. -When the Hurd was originally started in 1990, it was the last missing major -component for a complete GNU system. Today Linux and other free kernels are -available to fill this gap, and the combination of GNU and Linux (often -[incorrectly](http://www.gnu.org/gnu/why-gnu-linux.html) called just "Linux") -is in wide use. However, the Hurd is still interesting due to its unique -design, better fitting the GNU philosophy than traditional monolithic kernels -like Linux. - -The GNU GPL guarantees that all users of software published under this license -get the legal permission to adapt the software they are using according to -their wishes, and also get the source code and other tools necessary to put -this permission to use. However, in traditional operating systems, the kernel -and related low-level system software are protected from normal users, and -cannot be easily modified; only the system administrator has power over these. - -The Hurd offers special mechanisms that allow any user to change almost all of -the system functionality he uses, without affecting the rest of the system, and -thus easily (at runtime) and without any special permissions. - -This ability to run subenvironments more or less independant from the rest of -the system, can be classified as a very sophisticated [lightweight -virtualization](http://tri-ceps.blogspot.com/2007/10/advanced-lightweight-virtualization.html) -approach. - -To offer these possibilities, the Hurd uses a true multiserver microkernel -architecture. That makes it quite unique: The Hurd is the only general-purpose -multiserver microkernel system in development today that is nearly ready for -everyday use, and offering almost perfect UNIX compatibility. (About 65% -of all packages in the Debian repository are available for the Hurd.) All other -existing true microkernel systems are either research projects not nearly -complete enough for actual use, or limited to embedded systems and other -special purposes, or both. - -Marcus Brinkmann and Neal Walfield from the Hurd project are working at the -bleeding edge of microkernel operating system research. They have been in -contact with the most distinguished researchers in that field from the +In traditional operating systems, most system functionality is provided by the +kernel, and thus cannot be easily modified. The Hurd on the other hand -- +following the GNU spirit of giving users more control over the software they +use -- implements a unique design, which makes it feasible to change almost +everything, down to the core features of the system. + +While on other systems, such changes would require a lot of effort and special +privileges to rebuild the system core, with the Hurd this is not necessary: the +extensible architecture enables users (or applications) to simply modify their +local system environment at any time, while leaving the rest of the system in +place. + +The most obvious example is the completely decentralized VFS mechanism: it can +be extended in almost any imaginable way, simply by setting up suitable server +processes (translators). Not only does this empower users, but also it helps +application development: desktop environments such as GNOME for example, when +making use of these possibilities, wouldn't need to create their own VFS +mechanism -- they simply could extend the system VFS to suit their needs. + +One major element of the design which enables this extensibility, is the use of +a true multiserver microkernel architecture. The Hurd is quite unique in being +the only general-purpose multiserver microkernel system in development today, +that is nearly ready for everyday use, and offering almost perfect UNIX +compatibility. (About 65% of all packages in the Debian repository are +available for the Hurd.) The "general-purpose" and "everyday use" bits are +decisive here: all other existing true microkernel systems are either research +projects not nearly complete enough for actual use; or limited to embedded +systems and other special purposes; or both. + +Marcus Brinkmann and Neal Walfield, while working on improvements to the Hurd +design, pushed at the forefront of microkernel operating system research. They +worked with the most distinguished researchers in this field from the [L4](http://l4hq.org/) and [EROS](http://www.eros-os.org/eros.html)/[Coyotos](http://www.coyotos.org/) -microkernel operating system groups, and have written a couple of [research -papers](http://walfield.org/). +microkernel operating system groups, and published a couple of [research +papers](http://walfield.org/) as well in this process. * Home Page: -- cgit v1.2.3 From 05e87d4aa96f445642914346436ebfe2e8bdbc7c Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 12 Mar 2010 21:53:16 +0100 Subject: gsoc/organisation_application: minor rewording --- community/gsoc/organization_application.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'community/gsoc') diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 8ec61c12..8e672af1 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -157,7 +157,7 @@ Also, we will make sure that we are constantly in contact with the students -- asking about progress, discussing technical issues, etc. -- so we can act in time if things go wrong. -If a student disappears in spite of that, there is little we can do. Of course +If a student disappears in spite of all this, there is little we can do. Of course we will try to contact him and find out what the problem is; whether the project can perhaps be scaled down, or otherwise salvaged, so that the effort already invested in the student and the project is not wasted. We also try to -- cgit v1.2.3 From e91198942e583256fe2221014de05a0d528e422c Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sun, 14 Mar 2010 23:35:15 +0100 Subject: Add information on what already works --- community/gsoc/project_ideas/debian_installer.mdwn | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas/debian_installer.mdwn b/community/gsoc/project_ideas/debian_installer.mdwn index d182c4ee..43682e8b 100644 --- a/community/gsoc/project_ideas/debian_installer.mdwn +++ b/community/gsoc/project_ideas/debian_installer.mdwn @@ -23,12 +23,18 @@ requires relatively little Hurd-specific knowledge. A lot of the "non-Linux support" part of the project has already been done thanks to a previous GSoC, so at least no ground reason should bar the project. A lot of the required udebs are already in Debian or are pending upload, so that building an image and booting it does already work. A preliminary list of what remains is -* Add initrd support to GNU Mach, unless youpi does it before :) This should not be very complicated by re-using the iopl driver code. -* hurdify genext2fs to handle 4096 block size by default (see bug #562999) and support translator entries. -* Port busybox. This needs to be synchronized with kfreebsd people, who have probably already done some work, but that seemingly still hasn't been merged. In the meanwhile, youpi has a version with most of it disabled so a d-i image can actually be built. -* Port keyboard-setup to configure the xkb driver of the Hurd console + * Add initrd support to GNU Mach, unless youpi does it before :) This should not be very complicated by re-using the iopl driver code. + * hurdify genext2fs to handle 4096 block size by default (see bug #562999) and support translator entries. + * Port busybox. This needs to be synchronized with kfreebsd people, who have probably already done some work, but that seemingly still hasn't been merged. In the meanwhile, youpi has a version with most of it disabled so a d-i image can actually be built. + * Port keyboard-setup to configure the xkb driver of the Hurd console -As a starting point, students might wish to look at the current Debian installer source and build process. +As a starting point to get a grasp at how the debian installer is built, students might wish to look at the current Debian installer source and build process on Linux: + + * svn co svn://svn.debian.org/d-i/trunk/installer/ + * cd installer/build + * make build_monolithic + +The same can be done on hurd-i386 but a few non-uploaded packages are needed, see http://people.debian.org/~sthibault/hurd-i386/README-d-i Possible mentors: Samuel Thibault (youpi) -- cgit v1.2.3 From ea9e81001100ebd3f7c00a7854e5d03f554fa919 Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 26 Mar 2010 20:29:01 +0100 Subject: gsoc/ideas/valgrind: Rewrite according to recent IRC discussion Note: I have doubts about the exercise task too... Probably needs revisiting. --- community/gsoc/project_ideas/valgrind.mdwn | 71 +++++++++++++++++++++++++++--- 1 file changed, 66 insertions(+), 5 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn index 319d33a7..c6fc7459 100644 --- a/community/gsoc/project_ideas/valgrind.mdwn +++ b/community/gsoc/project_ideas/valgrind.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,12 +8,73 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title="Porting valgrind to the Hurd"]] +[[!meta title="Porting Valgrind to the Hurd"]] -Valgrind is a very powerful tool to debunk bugs. However, in order to do so, it needs deep knowledge of the behavior of kernel traps. In the case of GNU/Hurd, there is a bunch of system calls that GNU Mach handles directly, but also all the MIG RPCs (Remote Procedure Calls) which return their result either inline or through memory allocated by the kernel. +[Valgrind](http://valgrind.org/) is an extremely useful debugging tool for memory errors. +(And some other kinds of hard-to-find errors too.) +Aside from being useful for program development in general, +a Hurd port will help finding out why certain programs segfault on the Hurd, +although they work on Linux. +Even more importantly, it will help finding bugs in the Hurd servers themselfs. -The goal is thus to teach valgrind the exact semantics of all MIG RPCs, most probably in an automatic way from the .defs files. +To keep track of memory use, +Valgrind however needs to know how each system call affects the validity of memory regions. +This knowledge is highly kernel-specific, +and thus Valgrind needs to be explicitely ported for every system. -As a starter, students can try to teach valgrind a couple of Linux ioctls, as this will make them learn how to use the read/write primitives of valgrind. +Such a port involves two major steps: +making Valgrind understand how kernel traps work in general on the system in question; +and how all the individual kernel calls affect memory. +The latter step is where most of the work is, +as the behaviour of each single system call needs to be described. + +Compared to Linux, +Mach (the microkernel used by the Hurd) has very few kernel traps. +Almost all system calls are implemented as RPCs instead -- +either handled by Mach itself, or by the various Hurd servers. +All RPCs use a pair of mach\_msg() invocations: +one to send a request message, and one to receive a reply. +However, while all RPCs use the same mach\_msg() trap, +the actual effect of the call varies greatly depending on which RPC is invoked -- +similar to the ioctl() call on Linux. +Each request thus must be handled individually. + +Unlike ioctl(), +the RPC invocations have explicit type information for the parameters though, +which can be retrieved from the message header. +By analyzing the parameters of the RPC reply message, +Valgrind can know exactly which memory regions are affected by that call, +even without specific knowledge of the RPC in question. +Thus implementing a general parser for the reply messages +will already give Valgrind a fairly good approximation of memory validity -- +without having to specify the exact semantic of each RPC by hand. + +While this should make Valgrind quite usable on the Hurd already, it's not perfect: +some RPCs might return a buffer that is only partially filled with valid data; +or some reply parameters might be optional, +and only contain valid data under certain conditions. +Such specific semantics can't be deduced from the message headers alone. +Thus for a complete port, +it will still be necessary to go through the list of all known RPCs, +and implement special handling in Valgrind for those RPCs that need it. + +The goal of this task is at minimum to make Valgrind grok Mach traps, +and to implement the generic RPC handler. +Ideally, specific handling for RPCs needing it should also be implemented. + +Completing this project will require digging into Valgrind's handling of system calls, +and into Hurd RPCs. +It is not an easy task, but a fairly predictable one -- +there shouldn't be any unexpected difficulties, +and no major design work is necessary. +It doesn't require any specific previous knowledge: +only good programming skills in general. +On the other hand, +the student will obtain a good understanding of Hurd RPCs while working on this task, +and thus perfect qualifications for Hurd development in general :-) Possible mentors: Samuel Thibault (youpi) + +Exercise: As a starter, +students can try to teach valgrind a couple of Linux ioctls, +as this will make them learn how to use the read/write primitives of valgrind. -- cgit v1.2.3 From f36cdb3cafb743de763ed217ef3260c12b15ab2d Mon Sep 17 00:00:00 2001 From: antrik Date: Sat, 27 Mar 2010 13:14:28 +0100 Subject: gsoc/ideas: grow a Python option to the former Perl task --- community/gsoc/project_ideas.mdwn | 2 +- community/gsoc/project_ideas/perl.mdwn | 30 ----------------------- community/gsoc/project_ideas/perl_python.mdwn | 34 +++++++++++++++++++++++++++ 3 files changed, 35 insertions(+), 31 deletions(-) delete mode 100644 community/gsoc/project_ideas/perl.mdwn create mode 100644 community/gsoc/project_ideas/perl_python.mdwn (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 2046db9e..c07e5def 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -101,7 +101,7 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/gnat" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/hardware_libs" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/cdparanoia" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/perl" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/perl_python" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/valgrind" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/perl.mdwn b/community/gsoc/project_ideas/perl.mdwn deleted file mode 100644 index bfe1968e..00000000 --- a/community/gsoc/project_ideas/perl.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -[[!meta title="Improving Perl Support"]] - -Perl is available on the Hurd, but there are quite a lot of test suite -failures. These could be caused by problems in the system-specific -implementation bits of Perl, and/or shortcomings in the actual system -functionality which Perl depends on. - -The goal of this project is to fix all of these problems if possible, or at -least some of them. Some issues might require digging quite deep into Hurd -internals, while others are probably easy to fix. - -Note that while some Perl knowledge is probably necessary to understand what -the test suite failures are about, the actual work necessary to fix these -issues is mostly C programming -- in the implementation of Perl and/or the -Hurd. - -Possible mentors: Samuel Thibault (youpi) - -Exercise: Make some improvement to Perl support on the Hurd, e.g. fixing one of -the known test suite failures. diff --git a/community/gsoc/project_ideas/perl_python.mdwn b/community/gsoc/project_ideas/perl_python.mdwn new file mode 100644 index 00000000..2ecfe106 --- /dev/null +++ b/community/gsoc/project_ideas/perl_python.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Improving Perl or Python Support"]] + +Perl and Python are available on the Hurd, but there are quite a lot of test suite +failures. These could be caused by problems in the system-specific +implementation bits of Perl/Python, and/or shortcomings in the actual system +functionality which Perl/Python depends on. + +The student applying for this project can pick either Perl or Python, +whichever he is more comfortable with. +(Perl is higher priority though; and there are more failures too.) + +The goal then is to fix all of the problems with the chosen language if possible, or at +least some of them. Some issues might require digging quite deep into Hurd +internals, while others are probably easy to fix. + +Note that while some Perl/Python knowledge is probably necessary to understand what +the test suite failures are about, the actual work necessary to fix these +issues is mostly C programming -- in the implementation of Perl/Python and/or the +Hurd. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Make some improvement to Perl/Python support on the Hurd, e.g. fixing one of +the known test suite failures. -- cgit v1.2.3 From c676d817508dde90a301788f95799e1159d9978b Mon Sep 17 00:00:00 2001 From: antrik Date: Sat, 27 Mar 2010 17:31:56 +0100 Subject: gsoc: new idea: fixing testsuite failures --- community/gsoc/project_ideas.mdwn | 1 + community/gsoc/project_ideas/testsuites.mdwn | 52 ++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+) create mode 100644 community/gsoc/project_ideas/testsuites.mdwn (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index c07e5def..ca10c8a2 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -102,6 +102,7 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/hardware_libs" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/cdparanoia" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/perl_python" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/valgrind" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/testsuites.mdwn b/community/gsoc/project_ideas/testsuites.mdwn new file mode 100644 index 00000000..4f8d43fc --- /dev/null +++ b/community/gsoc/project_ideas/testsuites.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Fix Compatibility Problems Exposed by Testsuites"]] + +A number of software packages come with extensive testsuites. +Some notable ones are Perl, Python, GNU Coreutils, and glib. +While these testsuites were written mostly to track regressions in the respective packages, +some of the tests fail on the Hurd in general. + +While in some cases these might point to wrong usage of system interfaces, +most of the time such failures are actually caused by shortcomings in Hurd's implementation of these interfaces. +These shortcomings are often not obvious in normal use, +but can be directly or indirectly responsible for all kinds of failures. +The testsuites help in isolating such problems, +so they can be tracked down and fixed. + +This task thus consists in running some of the mentioned testsuites +(and/or any other ones that come to mind), +and looking into the causes of failures. +The goal is to analyze all failures in one or more of the listed testsuites, +to find out what shortcomings in the Hurd implementation cause them (if any), +and to fix at least some of these shortcomings. + +Note that this task somewhat overlaps with the [[Perl/Python task|perl_python]] listed above. +Here the focus however is not on improving the support for any particular program, +but on fixing general problems in the Hurd. + +This is a very flexible task: +while less experienced students should be able to tackle at least a few of the easier problems, +other issues will be challenging even for experienced hackers. +No specific previous knowledge is required for this task; +only fairly decent C programming skills. +While tracking down the various issues, +the student will be digging into the inner workings of the Hurd, +and thus gradually gaining the knowledge required for Hurd development in general. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Take a stab at one of the testsuite failures, +and write a minimal testcase exposing the underlying problem. +Actually fixing it would be a bonus of course -- +but as it's hard to predict which issues will be easy and which will be tricky, +we will already be satisfied if the student makes a good effort. +(We hope to see some discussion of the problems in this case though :-) ) -- cgit v1.2.3 From 061ccb4858a2ac58af5663d0ff24bf6033427f19 Mon Sep 17 00:00:00 2001 From: antrik Date: Sat, 27 Mar 2010 17:46:10 +0100 Subject: gsoc/ideas/perl_python: borrow better exercise suggestion from testsuites idea --- community/gsoc/project_ideas/perl_python.mdwn | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'community/gsoc') diff --git a/community/gsoc/project_ideas/perl_python.mdwn b/community/gsoc/project_ideas/perl_python.mdwn index 2ecfe106..34e877ab 100644 --- a/community/gsoc/project_ideas/perl_python.mdwn +++ b/community/gsoc/project_ideas/perl_python.mdwn @@ -30,5 +30,9 @@ Hurd. Possible mentors: Samuel Thibault (youpi) -Exercise: Make some improvement to Perl/Python support on the Hurd, e.g. fixing one of -the known test suite failures. +Exercise: Take a stab at one of the testsuite failures, +and write a minimal testcase exposing the underlying problem. +Actually fixing it would be a bonus of course -- +but as it's hard to predict which issues will be easy and which will be tricky, +we will already be satisfied if the student makes a good effort. +(We hope to see some discussion of the problems in this case though :-) ) -- cgit v1.2.3