summaryrefslogtreecommitdiff
path: root/community
diff options
context:
space:
mode:
authorSamuel Thibault <samuel.thibault@ens-lyon.org>2011-01-09 23:34:42 +0100
committerSamuel Thibault <samuel.thibault@ens-lyon.org>2011-01-09 23:34:42 +0100
commitf3df65ce34153357d28bee621bdf49b61e68b182 (patch)
tree25ac416b157b010ca2f942dac5c5ba0b38a924ac /community
parent09184ae09c44c052a207aa5c6dc8ce9cf61a343f (diff)
parent3bbe62327128ce85829a4cb2fb429bd8f21b4d75 (diff)
Merge branch 'master' of flubber:~hurd-web/hurd-web
Diffstat (limited to 'community')
-rw-r--r--community/gsoc/project_ideas.mdwn13
-rw-r--r--community/gsoc/project_ideas/disk_io_performance.mdwn36
-rw-r--r--community/gsoc/project_ideas/language_bindings.mdwn2
-rw-r--r--community/gsoc/project_ideas/libcap.mdwn8
-rw-r--r--community/gsoc/project_ideas/libcap/details.mdwn8
-rw-r--r--community/gsoc/project_ideas/libdiskfs_locking.mdwn41
-rw-r--r--community/gsoc/project_ideas/secure_chroot.mdwn11
-rw-r--r--community/gsoc/project_ideas/valgrind.mdwn80
-rw-r--r--community/meetings.mdwn7
-rw-r--r--community/meetings/debconf10.mdwn9
-rw-r--r--community/meetings/fosdem_2011.mdwn31
-rw-r--r--community/meetings/ghm2010.mdwn8
-rw-r--r--community/weblogs/ArneBab/niches_for_the_hurd.mdwn39
-rw-r--r--community/weblogs/ArneBab/tasks-for-the-hurd.mdwn63
14 files changed, 165 insertions, 191 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index ca10c8a2..649e05c1 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -1,12 +1,13 @@
-[[!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
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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
We offer a wide range of possible projects to choose from. If you have an idea
not listed here, we'd love to hear about it!
@@ -81,10 +82,10 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H
[[!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]]
-[[!inline pages="community/gsoc/project_ideas/libdiskfs_locking" show=0 feeds=no actions=yes]]
+[[!inline pages="open_issues/locking" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/pthreads" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]]
-[[!inline pages="community/gsoc/project_ideas/disk_io_performance" show=0 feeds=no actions=yes]]
+[[!inline pages="open_issues/performance/io_system" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/vm_tuning" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/mtab" show=0 feeds=no actions=yes]]
[[!inline pages="community/gsoc/project_ideas/gnumach_cleanup" show=0 feeds=no actions=yes]]
@@ -105,4 +106,4 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H
[[!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]]
+[[!inline pages="open_issues/valgrind" show=0 feeds=no actions=yes]]
diff --git a/community/gsoc/project_ideas/disk_io_performance.mdwn b/community/gsoc/project_ideas/disk_io_performance.mdwn
deleted file mode 100644
index b6c857b0..00000000
--- a/community/gsoc/project_ideas/disk_io_performance.mdwn
+++ /dev/null
@@ -1,36 +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="Disk I/O Performance Tuning"]]
-
-The most obvious reason for the Hurd feeling slow compared to mainstream
-systems like GNU/Linux, is very slow hard disk access.
-
-The reason for this slowness is lack and/or bad implementation of common
-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
-optimizations at a higher logical level.
-
-The goal of this project is to analyze the current situation, and implement/fix
-various optimizations, to achieve significantly better disk performance. It
-requires understanding the data flow through the various layers involved in
-disk access on the Hurd ([[filesystem|hurd/virtual_file_system]],
-[[pager|hurd/libpager]], driver), and general experience with
-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.
-
-Possible mentors: Samuel Thibault (youpi)
-
-Exercise: Look through all the code involved in disk I/O, and try something
-easy to improve. It's quite likely though that you will find nothing obvious --
-in this case, please contact us about a different exercise task.
diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn
index 460b380b..c8a02390 100644
--- a/community/gsoc/project_ideas/language_bindings.mdwn
+++ b/community/gsoc/project_ideas/language_bindings.mdwn
@@ -20,7 +20,7 @@ However, in practice this is not as easy as it should, because creating
translators and other servers is quite involved -- the interfaces for doing
that are not exactly simple, and available only for C programs. Being able to
easily create simple translators in RAD languages is highly desirable, to
-really be able to reap the advantages of the Hurd architecture.
+really be able to reap the [[advantages]] of the Hurd architecture.
Originally Lisp was meant to be the second system language besides C in the GNU
system; but that doesn't mean we are bound to Lisp. Bindings for any popular
diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn
index 1346203d..18c49c48 100644
--- a/community/gsoc/project_ideas/libcap.mdwn
+++ b/community/gsoc/project_ideas/libcap.mdwn
@@ -1,12 +1,12 @@
-[[!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
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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
[[!meta title="Implementing libcap"]]
@@ -33,7 +33,7 @@ probably doable without previous experience with either, though.
David Hedberg applied for this project in 2010,
and though he didn't go through with it,
-he fleshed out many [[libcap/details]].
+he fleshed out many [[details]].
Possible mentors: Samuel Thibault (youpi)
diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn
index aa27a84e..85695978 100644
--- a/community/gsoc/project_ideas/libcap/details.mdwn
+++ b/community/gsoc/project_ideas/libcap/details.mdwn
@@ -5,8 +5,8 @@ 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
[[!meta title="Details on implementing libcap"]]
@@ -59,7 +59,7 @@ Each process has a three bit fields representing each of the three
sets (P, E and I). Each bit field is currently built up of two (32
bit) integers to be able to hold the 33 currently defined capabilities
(see linux/capability.h). Each process further has a bounding set which
-bounds the permitted set. Two syscalls handles the setting and getting
+bounds the permitted set. Two [[system call]]s handles the setting and getting
of capabilities; *capset* and *capget*. Some related functionality
can also be controlled by calling *prctl*: the right to read/drop the
bounding capabilities (PR_CAPBSET_READ/PR_CAPBSET_DROP) and whether
@@ -428,7 +428,7 @@ the following (also detailed somewhat in the same article):
* Execute process as root (or setuid) to gain all capabilities.
-* Use the prctl system call to enable keepcaps for the process
+* Use the prctl [[system call]] to enable keepcaps for the process
(same(?) effect as enabling SECURE_NO_SETUID_FIXUP for the process).
keepcaps should be off by default.
diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
deleted file mode 100644
index 0618bbe6..00000000
--- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn
+++ /dev/null
@@ -1,41 +0,0 @@
-[[!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="Fix libdiskfs Locking Issues"]]
-
-Nowadays the most often encountered cause of Hurd crashes seems to be lockups
-in the [[hurd/translator/ext2fs]] server. One of these could be traced
-recently, and turned out to be a lock inside [[hurd/libdiskfs]] that was taken
-and not released in some cases. There is reason to believe that there are more
-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
-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...)
-
-(A systematic code review would probably suffice to find the existing locking
-issues; but it wouldn't document the work in terms of actual code produced, and
-thus it's not suitable for a GSoC project...)
-
-[Linux' *sparse*](https://sparse.wiki.kernel.org/) could be worth looking at.
-
-This task requires experience with debugging locking issues in multithreaded
-applications.
-
-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
-might be rather tough though, so probably you need to talk to us about an
-alternative exercise task...
diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn
index feb30a7c..57739861 100644
--- a/community/gsoc/project_ideas/secure_chroot.mdwn
+++ b/community/gsoc/project_ideas/secure_chroot.mdwn
@@ -1,17 +1,18 @@
-[[!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
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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
[[!meta title="Secure chroot Implementation"]]
As the Hurd attempts to be (almost) fully [[UNIX]]-compatible, it also implements a
-`chroot()` system call. However, the current implementation is not really
+`chroot` [[system call]]. However, the current implementation is not really
good, as it allows easily escaping the `chroot`, for example by use of
[[passive_translators|hurd/translator]].
@@ -20,7 +21,7 @@ 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 approach to
-`chroot` implementation, using a proxy instead of a special system call in the
+`chroot` implementation, using a proxy instead of a special [[system call]] in the
filesystem servers.
See <http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity.html>
diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn
deleted file mode 100644
index c6fc7459..00000000
--- a/community/gsoc/project_ideas/valgrind.mdwn
+++ /dev/null
@@ -1,80 +0,0 @@
-[[!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="Porting Valgrind to the Hurd"]]
-
-[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.
-
-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.
-
-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.
diff --git a/community/meetings.mdwn b/community/meetings.mdwn
index ecd0e465..939d5269 100644
--- a/community/meetings.mdwn
+++ b/community/meetings.mdwn
@@ -6,20 +6,21 @@ 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
[[!meta title="Meetings with Hurd developer attendance"]]
# Upcoming
+ * [[FOSDEM_2011]]
* [[Self-organised]]
# Past
* [[DebConf10]]
* [[GNU Hackers Meeting in the Hague 2010|ghm2010]]
- * [[FOSDEM 2010]]
+ * [[FOSDEM_2010]]
* [[EuroSys_2009]]
* [[FOSDEM_2008]]
* [[Weekend_at_stesie's|stesie_2007-10-12]]
diff --git a/community/meetings/debconf10.mdwn b/community/meetings/debconf10.mdwn
index bafd7de0..3b83a8cc 100644
--- a/community/meetings/debconf10.mdwn
+++ b/community/meetings/debconf10.mdwn
@@ -16,5 +16,12 @@ License|/fdl]]."]]"""]]
[[!ymlfront data="""
-banck_hurd: "presentation (including video) by Michael Banck: [*Debian GNU/Hurd -- Past. Present. And Future?*](http://penta.debconf.org/dc10_schedule/events/595.en.html) ([slides](http://people.debian.org/~mbanck/debian-hurd.pdf))"
+
+banck_hurd:
+
+ "presentation (including video) by Michael Banck: [*Debian GNU/Hurd -- Past.
+ Present. And
+ Future?*](http://penta.debconf.org/dc10_schedule/events/595.en.html)
+ ([slides](http://people.debian.org/~mbanck/debian-hurd.pdf))"
+
"""]]
diff --git a/community/meetings/fosdem_2011.mdwn b/community/meetings/fosdem_2011.mdwn
new file mode 100644
index 00000000..76a02c0a
--- /dev/null
+++ b/community/meetings/fosdem_2011.mdwn
@@ -0,0 +1,31 @@
+[[!meta copyright="Copyright © 2006, 2007, 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="FOSDEM 2011"]]
+
+<http://fosdem.org/2011>
+
+FOSDEM will take place on February 5th/6th at the Université Libre de
+Bruxelles.
+
+
+# Who and When
+
+[[!table class="table_style_1" data="""
+"Name","Attending","Arrival","Return","Share room with us"
+"Neal Walfield","yes","Friday noon","Monday noon","yes"
+"[[Thomas Schwinge|tschwinge]]","no","n/a","n/a","n/a"
+"""]]
+
+
+# What
+
+<http://lists.gnu.org/archive/html/bug-hurd/2010-12/msg00019.html>
diff --git a/community/meetings/ghm2010.mdwn b/community/meetings/ghm2010.mdwn
index e216bfe4..b7d7e880 100644
--- a/community/meetings/ghm2010.mdwn
+++ b/community/meetings/ghm2010.mdwn
@@ -16,5 +16,11 @@ License|/fdl]]."]]"""]]
[[!ymlfront data="""
-walfield_hurd: "video of the presentation by Neal Walfield: [*GNU/Hurd: It's About Freedom (Or: Why you should care)*](http://audio-video.gnu.org/video/ghm2010/GNU-Hurd_-_Its_About_Freedom,_Or_Why_you_should_care.ogv)"
+
+walfield_hurd:
+
+ "video of the presentation by Neal Walfield: [*GNU/Hurd: It's About Freedom
+ (Or: Why you should
+ care)*](http://audio-video.gnu.org/video/ghm2010/GNU-Hurd_-_Its_About_Freedom,_Or_Why_you_should_care.ogv)"
+
"""]]
diff --git a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
index 6f0af07e..5febe7b6 100644
--- a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
+++ b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
@@ -131,7 +131,9 @@ that's KDEs fabled network transparency on the filesystem / shell level (where i
* add temporary filesystems anywhere via `settrans -a NODE /hurd/ext2fs`
-* make everything temporarily writeable without really changing it via [[hurd/translator/unionfs]].
+* On-demand mounted filesystems via a passive translator which unmounts the filesystem when it isn’t used for some time.
+
+* make everything temporarily writeable without really changing it via [[hurd/translator/unionfs]]. Store the changes on an external device.
* Read tar archives and mbox files via `ls foo.tar.gz,,tarfs` and `ls foo.mbox,,mboxfs`, respectively → [[hurd/translator/nsmux]].
@@ -157,7 +159,7 @@ aren't possible.
* elegantly mount iso images and similar as unprivileged user.
- Other useful stuff:
- * Install deb-packages from an ftp server via 'dpkg -iO ftp://foo/bar/*.deb'
+ * Install deb-packages from an ftp server via 'dpkg -iO ftp://foo/bar/package.deb'
* remount a filesystem readonly as regular user: fsysopts /foo -r
* give a process additional group and user permissions at runtime:
$ groups
@@ -195,10 +197,6 @@ aren't possible.
# once the subhurd closes.
$ subdo --no-lasting-changes ./virus
-- Running parts of the Hurd on different computers, maybe even with shared servers on
-dedicated hardware (Cloud Computing when the servers can be made to migrate from
-between computers). Maybe this should be placed in "need a lot of coding".
-
- subhurds for quickly adapting the whole system without bothering others.
- Define your personal environment via translators, so you can easily take it with
@@ -230,8 +228,6 @@ traditional systems in this reagard, but in fact surpass them.
- The possibility to create more efficient and powerful desktop environments.
-- Multicore systems (need to fixup Mach for SMP)
-
- Currently to offer CPU time to some project (like the World Community Grid), it is
necessary to install a program from them, and they can then do only what that proram
allows them to - which leads to reinventing a processing environment instead of just
@@ -248,6 +244,12 @@ level. Programs only have to display the given files and quickly update the
state of their own files, so the programs stay very easy. The translator could
notify the program when something changes.
+- Multicore systems (need to fixup Mach for SMP)
+
+- Running parts of the Hurd on different computers, maybe even with shared servers on
+dedicated hardware (Cloud Computing when the servers can be made to migrate from
+between computers). Maybe this should be placed in "need a lot of coding".
+
### Unfeasible ideas
@@ -328,13 +330,32 @@ Each participant:
("must", because in a community people can do what they perceive as important, and
telling someone to stop what he's doing is no option (in my opinion))
+**Result: We talk about the niches we can already fulfill :)**
+
Things to do
------------
todo-item -> niches for which it is useful.
+*This might be useful for the next GSoC.*
+
### Easy
-- Port debian packages to the Hurd -> mainly tinkerers, but also any other niche.
+- Port debian packages to the Hurd -> currently mainly tinkerers, but also any other niche. In the long run this is necessary for every user. Easy start for devs.
+- Document easier access to low-level functions via translators, one function at a time. -> tinkerers.
+- get nsmux ready for regular users by setting it up in the LiveCDs by default. -> show tinkerers what it can do.
+
+### Complex
+- A filesystem-based package manager: Unionmounting packages. With filterfs from nsmux packages any user should be able to selectively disable any package without affecting the system of others. Simple active translators can add packages. -> clean design and more freedom for tinkerers to setup test environments: “Does this also work with XY disabled?”
+- Enable subhurds for regular users via a subdo command: A framework for confining individual applications. -> tinkerers for testing their work.
+- Define your personal environment via translators, so you can easily take it with
+you ⇒ system on a USB stick. Would work great with a filesystem based package manager. -> ?
+
+### Huge
+
+- Get Hurd/GNU Mach ready for efficient multicore usage. -> multicore
+- Running parts of the Hurd on different computers, maybe even with shared servers on
+dedicated hardware (Cloud Computing when the servers can be made to migrate from
+between computers). -> multicore on steroids :)
diff --git a/community/weblogs/ArneBab/tasks-for-the-hurd.mdwn b/community/weblogs/ArneBab/tasks-for-the-hurd.mdwn
new file mode 100644
index 00000000..bf6224b2
--- /dev/null
+++ b/community/weblogs/ArneBab/tasks-for-the-hurd.mdwn
@@ -0,0 +1,63 @@
+Tasks for the Hurd
+==================
+
+*These tasks are compiled from the
+ [[community/weblogs/ArneBab/niches_of_the_hurd]] and
+ [[community/weblogs/ArneBab/what_we_need]]. The first asked “where
+ can the Hurd find niches where it is the biggest fish in the pond,
+ and how?” while the second asked “what do we still need to make the
+ Hurd usable for most of its developers as system for their day-to-day
+ tasks?”.*
+
+*This might be useful for the next GSoC. Please feel free to edit
+ and/or migrate it mercilessly :)*
+
+### Easy
+
+- Port debian packages to the Hurd -> currently mainly tinkerers, but
+ also any other niche. In the long run this is necessary for every
+ user. Easy start for devs.
+- Document easier access to low-level functions via translators, one
+ function at a time. -> tinkerers.
+- get nsmux ready for regular users by setting it up in the LiveCDs by
+ default. -> show tinkerers what it can do.
+- Test on modern machines. If it doesn’t work, file a bug:
+ [info](http://www.mail-archive.com/bug-hurd@gnu.org/msg19105.html).
+
+
+### Complex
+
+- A filesystem-based package manager: Unionmounting packages. With
+ filterfs from nsmux packages any user should be able to selectively
+ disable any package without affecting the system of others. Simple
+ active translators can add packages. -> clean design and more
+ freedom for tinkerers to quickly setup test environments: “Does this
+ also work with XY disabled?” ⇒ rapid testing for different base
+ systems.
+- Enable subhurds for regular users via a subdo command: A framework
+ for confining individual applications. -> tinkerers for testing
+ their work.
+- Define your personal environment via translators, so you can easily
+ take it with you ⇒ system on a USB stick. Would work great with a
+ filesystem based package manager -> use the capabilities of a system
+ and all its installed packages without having to give up your own
+ custom environment.
+
+- Implement USB support, maybe using DDE or DDEkit -> prerequisite to system on USB.
+- Add Wireless support, maybe via DDE.
+- Add sound support via a sound translator.
+- Add SATA support.
+- Stabilize Xorg, so it can run fast for days.
+- Add PPPoE capablilities.
+- Debug NFS for climm, w3m and git.
+- Port a full-featured browser (i.e. Firefox).
+- (Graphical Desktop and switching between console and X) or full
+ featured high-resultion console which doesn’t need X (and emacs :)
+ ).
+
+### Huge
+
+- Get Hurd/GNU Mach ready for efficient multicore usage. -> multicore
+- Running parts of the Hurd on different computers, maybe even with
+ shared servers on dedicated hardware (Cloud Computing when the servers
+ can migrate between computers). -> multicore on steroids :)