diff options
| -rw-r--r-- | community/gsoc/project_ideas/cdparanoia.mdwn | 2 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/download_backends.mdwn | 4 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/gnat.mdwn | 2 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/hardware_libs.mdwn | 8 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/libcap.mdwn | 2 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/libdiskfs_locking.mdwn | 2 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/libgtop.mdwn | 2 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/maxpath.mdwn | 4 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/perl.mdwn | 2 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/sound.mdwn | 2 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/xattr.mdwn | 2 | ||||
| -rw-r--r-- | community/gsoc/xorg_ideas.mdwn | 2 |
12 files changed, 17 insertions, 17 deletions
diff --git a/community/gsoc/project_ideas/cdparanoia.mdwn b/community/gsoc/project_ideas/cdparanoia.mdwn index 5215d541..117dc56e 100644 --- a/community/gsoc/project_ideas/cdparanoia.mdwn +++ b/community/gsoc/project_ideas/cdparanoia.mdwn @@ -23,7 +23,7 @@ The goal of this task is fully working cdparanoia in Debian GNU/Hurd. It will require digging a bit into Hurd internals and ATAPI commands, but should be quite doable without any previous knowledge about either. -Possible mentors: +Possible mentors: Samuel Thibault (youpi) Exercise: Look at the implementation of the existing ioctl()s, and try to find something that could be easily added/improved. If you don't see anything diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn index aa4823de..a6e090eb 100644 --- a/community/gsoc/project_ideas/download_backends.mdwn +++ b/community/gsoc/project_ideas/download_backends.mdwn @@ -10,7 +10,7 @@ is included in the section entitled [[meta title="Use Internet Protocol Translators (ftpfs etc.) as Backends for Other Programs"]] -The Hurd design faciliates splitting up large applications into independent, +The Hurd design facilitates splitting up large applications into independent, generic components, which can be easily combined in different contexts, by moving common functionality into separate Hurd servers (translators), accessible trough filesystem interfaces and/or specialized RPC interfaces. @@ -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 a [httpfs +There is already an ftpfs traslator 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 diff --git a/community/gsoc/project_ideas/gnat.mdwn b/community/gsoc/project_ideas/gnat.mdwn index f91a5e61..135c19aa 100644 --- a/community/gsoc/project_ideas/gnat.mdwn +++ b/community/gsoc/project_ideas/gnat.mdwn @@ -19,6 +19,6 @@ requires implementing some explicitely 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. -Possible mentors: +Possible mentors: Samuel Thibault (youpi) Exercise: Fix one of the problems preventing GNAT from working on the Hurd. diff --git a/community/gsoc/project_ideas/hardware_libs.mdwn b/community/gsoc/project_ideas/hardware_libs.mdwn index e3680378..91246e3b 100644 --- a/community/gsoc/project_ideas/hardware_libs.mdwn +++ b/community/gsoc/project_ideas/hardware_libs.mdwn @@ -15,9 +15,9 @@ libusb, libbluetooth, libraw1394 etc. The Hurd presently doesn't support these devices. Nevertheless, all of these programs could still be built -- and most of them would indeed be useful -- -without actual support of these hardware devices. However, as the libraries are -presently not available for Hurd, the programs can't be easily built in Debian -GNU/Hurd due to missing dependencies. +without actual support of these hardware devices, kdebase for instance. However, +as the libraries are presently not available for Hurd, the programs can't be +easily built in Debian GNU/Hurd due to missing dependencies. This could be avoided by providing dummy libraries, which the programs could link against, but which wouldn't actually do any hardware access: instead, they @@ -35,7 +35,7 @@ special previous knowledge, though some experience with build systems would be helpful. Finishing this task will probably require learning a bit about the hardware devices in question, and about Debian packaging. -Possible mentors: +Possible mentors: Samuel Thibault (youpi) Exercise: Get one of the libraries to compile on Debian GNU/Hurd. It doesn't need to report reasonable error codes yet -- just make it build at all for now. diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn index b65ee13c..9e722815 100644 --- a/community/gsoc/project_ideas/libcap.mdwn +++ b/community/gsoc/project_ideas/libcap.mdwn @@ -31,7 +31,7 @@ Some knowledge of POSIX capabilities will need to be obtained, and for the latter part also some knowledge about the Hurd architecture. This project is probably doable without previous experience with either, though. -Possible mentors: +Possible mentors: Samuel Thibault (youpi) Exercise: Make libcap compile on Debian GNU/Hurd. It doesn't need to actually do anything yet -- just make it build at all for now. diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn index 03914078..434e39ba 100644 --- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn +++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn @@ -30,7 +30,7 @@ thus it's not suitable for a GSoC project...) This task requires experience with debugging locking issues in multithreaded applications. -Possible mentors: ? +Possible mentors: Samuel Thibault (youpi) Exercise: If you could actually track down and fix one of the existing locking errors before the end of the application process, that would be excellent. This diff --git a/community/gsoc/project_ideas/libgtop.mdwn b/community/gsoc/project_ideas/libgtop.mdwn index a8a469a2..4f848820 100644 --- a/community/gsoc/project_ideas/libgtop.mdwn +++ b/community/gsoc/project_ideas/libgtop.mdwn @@ -29,6 +29,6 @@ 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 of Debian stuff. -Possible mentors: +Possible mentors: Samuel Thibault (youpi) Exercise: Fix one of the shortcomings in the existing procfs implementation. diff --git a/community/gsoc/project_ideas/maxpath.mdwn b/community/gsoc/project_ideas/maxpath.mdwn index 73b4fa46..797cc0dc 100644 --- a/community/gsoc/project_ideas/maxpath.mdwn +++ b/community/gsoc/project_ideas/maxpath.mdwn @@ -14,7 +14,7 @@ POSIX describes some constants (or rather macros) like PATH_MAX/MAXPATHLEN and similar, which may be defined by the system to indicate certain limits. Many people overlook the *may* though: Systems only should define them if they actually have such fixed limits. The Hurd, following the GNU Coding Standards, -tries to aviod this kind of arbitrary limits, and consequently doesn't define +tries to avoid this kind of arbitrary limits, and consequently doesn't define the macros. Many programs however just assume their presence, and use them unconditionally. @@ -38,6 +38,6 @@ significant number of packages, and make the fixes ready for inclusion in Debian and (where possible) upstream. No Hurd-specific knowledge is needed, nor any other special knowledge aside from general C programming skills. -Possible mentors: +Possible mentors: Samuel Thibault (youpi) Exercise: Fix the PATH_MAX issues in some Debian package. diff --git a/community/gsoc/project_ideas/perl.mdwn b/community/gsoc/project_ideas/perl.mdwn index a22540a8..803f710e 100644 --- a/community/gsoc/project_ideas/perl.mdwn +++ b/community/gsoc/project_ideas/perl.mdwn @@ -24,7 +24,7 @@ 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: +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/sound.mdwn b/community/gsoc/project_ideas/sound.mdwn index 39c4241a..26bb91cb 100644 --- a/community/gsoc/project_ideas/sound.mdwn +++ b/community/gsoc/project_ideas/sound.mdwn @@ -31,7 +31,7 @@ to come up with an appropriate design. Another option would be to evaluate whether a driver that is completely running in user-space is feasible. <!-- TODO. Elaborate. --> -Possible mentors: ? +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 diff --git a/community/gsoc/project_ideas/xattr.mdwn b/community/gsoc/project_ideas/xattr.mdwn index 3499fb5f..ab16dfbb 100644 --- a/community/gsoc/project_ideas/xattr.mdwn +++ b/community/gsoc/project_ideas/xattr.mdwn @@ -41,7 +41,7 @@ with xattrs might help a bit, but shouldn't be really necessary either. Some previous work on xattr support is available in [[GNU_Savannah_patch 5126]], and might serve as a starting point. -Possible mentors: +Possible mentors: Samuel Thibault (youpi) Exercise: Implement support for different inode sizes (other than 128 bytes) in Hurd's ext2fs. diff --git a/community/gsoc/xorg_ideas.mdwn b/community/gsoc/xorg_ideas.mdwn index 0899d20c..153b8bf6 100644 --- a/community/gsoc/xorg_ideas.mdwn +++ b/community/gsoc/xorg_ideas.mdwn @@ -52,7 +52,7 @@ anything useful, but compiles fine on the Hurd. While XFree86 was first ported to the Hurd more than a decade ago, and there are updates now and then to make newer versions of Xorg run as well (see also -the libpciaccess task), the support is quite rudimentary: in particualar, there +the libpciaccess task), the support is quite rudimentary: in particular, there is no support for switching back to the text console while X is running. Implementing this requires creating an interface between the X server and the |