diff options
Diffstat (limited to 'community')
37 files changed, 3831 insertions, 0 deletions
diff --git a/community/02may08minutes.mdwn b/community/02may08minutes.mdwn new file mode 100644 index 00000000..9c99a8e7 --- /dev/null +++ b/community/02may08minutes.mdwn @@ -0,0 +1,39 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +- madrazr wanted a wiki to keep track of progress. antrik suggested: + http://www.bddebian.com/~wiki/community/gsoc/ and that everyone use + that to keep track of their progress. bddebian was poked about git + accounts on flubber.bddebian.com + +- antrik/youpi talked about the mailing lists. + Debian GNU/Hurd (installer, etc): http://lists.debian.org/debian-hurd + bug-hurd, etc + +- Don't be afraid to post to the lists. There's no need to send the + post for review first. Generally people on the list are the same as + people on IRC + +- various docs links were posted: + http://angg.twu.net/the_hurd_links.html + http://www.gnu.org/software/hurd/docs.html + +- youpi posted a survey of some of the reasons why packages don't work + on Hurd: http://lists.debian.org/debian-hurd/2007/07/msg00000.html + and http://lists.debian.org/debian-hurd/2007/07/msg00001.html + +- andrei posted + http://web.cecs.pdx.edu/~trent/gnu/hurd/hurd-talk.tar.gz an archive + of hurd-folks + +- antrik is happy with communication in general + +- wiki pages for each of the projects should be created sometime this + week diff --git a/community/16may08minutes.mdwn b/community/16may08minutes.mdwn new file mode 100644 index 00000000..8adb838c --- /dev/null +++ b/community/16may08minutes.mdwn @@ -0,0 +1,21 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +* **madrazr** said that web commits for the wiki stall forever (more than half an hour); the reason is unknown. **antrik** said that it is not much of a problem if the problems with git access are solved. + +* It was explained that the wiki server is not a very fast machine, which runs Hurd, hence the delay. + +* Everybody agreed on the fact that there is much school/university work to do, since it's the end of the term now; students have little time to work on their projects. + +* The idea to use git and github for the projects was suggested. + +* **antrik** remarked that the summer session starts pretty soon and that it is time to tackle open design questions and decide where to start actual coding. The task to do that was assigned as a homework till the next meeting. + +* the official GSoC students talked about the start of program gift by Google. diff --git a/community/25april08minutes.mdwn b/community/25april08minutes.mdwn new file mode 100644 index 00000000..3f2c0313 --- /dev/null +++ b/community/25april08minutes.mdwn @@ -0,0 +1,61 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +- People agreed that some small projects should be done to during the bonding + period: ideas that floated around were fixing some of the build failures or + looking at the new debian installer. + http://unstable.buildd.net/buildd/hurd-i386_Failed.html + http://unstable.buildd.net/index-hurd-i386.html + For some context: + http://dept-info.labri.fr/~thibault/tmp/graph-radial.ps + Don't pick something that looks too critical, it'll probably be too hard + +- Antrik was ok with not having a formal weekly report as long as the + repositories are growing and the students are around + +- Discussion about scms. It's ok to have your own, you'll get you own branch, + just make sure to make your own repository public. There was some talk about + not checking in one huge commit at the end + +- Copyright assignments to the FSF are required for most of hurd and other gnu + projects. http://lists.gnu.org/archive/html/bug-hurd/2008-03/msg00175.html + is your friend. Fill it out 3 times: Mach, Hurd, glibc. It's ok if you're + not planning on working on all of these. Email to fsf-records@gnu.org + +- Non-SoC students were offered some compensation for doing their projects + anyway. They were far more interested in the fact that they would be doing + worthwhile work than financial compensation + +- It was agreed that regular meetings would be a good idea. Once a + week, especially in the bonding period. + +- In general it was agreed that conversations shouldn't stay between just + mentors and their students, that it's better to keep everything out in the + open + +- Non-SoC students were assigned mentors, though it was agreed that they would + be mostly a primary contact and that most conversations should be kept + public + +- Discussion turned back to the meetings, the usual back and forth about the + timeslot. Fridays at 19 UTC was decided as the meeting time. + +- It was suggested that students look into writing documentation/guides for + hurd, for example cross-compiling hurd on gentoo, as a way to get more + familliar. + +- Andrei will set up a google calendar for organizing meetings. + +- Antrik noted that IRC is good for quick questions but serious ones should go + to the mailing list to get everyone involved. + +And so the first meeting was concluded. + + diff --git a/community/chug.mdwn b/community/chug.mdwn new file mode 100644 index 00000000..173d0125 --- /dev/null +++ b/community/chug.mdwn @@ -0,0 +1,3 @@ +Mail me if you are interested! + +-- [[Main/GrantBow]] - 11 Oct 2002 diff --git a/community/communication.mdwn b/community/communication.mdwn new file mode 100644 index 00000000..d2eccceb --- /dev/null +++ b/community/communication.mdwn @@ -0,0 +1,40 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +The GNU Hurd community comprises of a crowd of people living in different areas +of the whole world. For that, having regular working-[[meetings]] -- usually +one of the more productive ways of coordination works -- is not easily +possible. + +The two key resources most often used for communication are the Debian and GNU +[[mailing_lists]], as well as [[IRC]]. + +These are measures of communication that work (compared to, e.g., a one-to-one +telephone call) one-to-many. It is important to not send email only to a +single person, but in a way that several people can see your questions and +reasonings. (There are exceptions, of course. Administrative stuff usually +need not be discussed in public.) It often happens that -- if you send email +only to a single developer -- someone is unavailable for some days and can't +answer to your email, but another person could easily have done so. Also, when +discussing matters in public, others can learn from it (while reading, or +eventually even taking part in the discussions), transform the results into +real documentation, etc. Efficient using of scarce resources. Start +discussions on public mailing lists/public IRC channels instead of sending +discussing with single developers. And always use *reply to all* instead of +*reply* when answering to email. + +If you're interested in keeping up with current events and taking part in +discussions, you'll want to join the [[mailing_lists/bug-hurd]] mailing list or +have a look at its [archives](http://lists.gnu.org/archive/html/bug-hurd/). + +Even if you're a beginner (we've also been, and some of us even still +remember), don't hesitate to make the first move and make active use of these +resources. But -- of course -- please try to adhere to the conventions as +described on the [[mailing_lists]] and [[IRC]] pages. diff --git a/community/da.mdwn b/community/da.mdwn new file mode 100644 index 00000000..e15aade1 --- /dev/null +++ b/community/da.mdwn @@ -0,0 +1,110 @@ +# Zheng Da + +Email: zhengda1936 at gmail dot com + +Project: Network virtualization for subhurds etc. + +The [code](http://www.assembla.com/spaces/VNetHurd/trac_subversion_tool). + +The [[howto]] shows the instructions of setting up the virtual network in hurd and subhurd. + +--- + +## The design and the implementation + +### The requirements: +* to implement a mechanism which help pfinet servers communicate with each other. For example, if pfinet 1 has IP A and pfinet 2 has IP B, the packet sent by pfinet 1 with destination address IP B should be received by pfinet 2. +* Sub-hurd should be able to use this mechanism to communicate with each other. +* Meanwhile this mechanism should allow non-privileged the user to start his own pfinet. + + +### The possible approach is to use the multiplexer and the filter. +The multiplexer's roles are: + +1. to create some virtual network interface, so pfinet can send packets to it. +2. to receive the packet from pfinet, and forward the packet to other pfinets in hurd +3. or forward the packet to the real network device in the kernel and send it to the network. + +A filter translator is needed to enforce the policies between the interface and the pfinet server. For example, the filter can control which packets can be delivered to the pfinet server, and which packets can be sent to the network interface. The filter can also guard the network traffic and drop illegal packets (forged by some malicious users) from pfinet or some other programs. + + +### To create a virtual network interface: +* Implement the RPC interface defined in device.defs. +* The multiplexer works as a translator and other programs can get the port to it by calling file_name_port(). +* Other programs can use this port as a master device port to open the virtual interface. + + +### The routing inside the multiplexer: +* when the multiplexer gets a packet, it forwards it to every interface. +* BPF is ported to the multiplexer. BPF delivers the packet to the right pfinet (according to the filter set by the pfinet) just as the BPF in Mach does. +* All packets are forwarded to the interface which the multiplexer sits on. + + +### The implementation of the filter translator: +* The filter works as a proxy, forwarding the packet between the interface and the pfinet server. +* BPF is also ported to the filter translator. There are two filers in the translator, one for outgoing packets, the other for incoming packets. +* Only one pfinet can connect to the translator at a time. + + +--- + +## TODO +### Coding + + - make subhurds running without root privileges + - merge BPF rules from the filter translator and the multiplexer + +--- + +## Completed tasks + +### Coding + +The patch of glibc (pfinet server overriding) is [here](http://www.assembla.com/spaces/VNetHurd/documents/aJidqKp6ur3z-Nab7jnrAJ/download/A%20patch%20of%20glibc). + +The patch of pfinet (open the virtual network interface) is [here](http://www.assembla.com/spaces/VNetHurd/documents/aWqYwYATKr3BBOab7jnrAJ/download/patch%20of%20pfinet%201%20(to%20use%20the%20virtual%20interface)). + +The patch of pfinet (fix pfinet to use the proper filter rule) is [here](http://www.assembla.com/spaces/VNetHurd/documents/besb-qATKr3AIxab7jnrAJ/download/patch%20of%20pfinet%202%20(to%20add%20an%20IP%20filter)). + +The patch of pfinet (set the mach device in the promiscuous mode) is [here](http://www.assembla.com/spaces/VNetHurd/documents/bEovN6ATKr3B8uab7jnrAJ/download/patch%20of%20pfinet%203%20(to%20set%20the%20mach%20device%20into%20the%20promiscuous%20mode)). + +The patch of boot (open the virtual network interface) is [here](http://www.assembla.com/spaces/VNetHurd/documents/cWkeEixHar3AdKab7jnrAJ/download/A%20patch%20of%20boot). + +The patch of gnumach (set the network device into the promiscuous mode) is [here](http://www.assembla.com/spaces/VNetHurd/documents/b0eLzUxHmr3ymXab7jnrAJ/download/A%20patch%20of%20gnumach). + +the multiplexer: + +- Create multiple virtual network interfaces. +- Port BPF to the multiplexer. +- Finish the routing among the pfinet servers. + +the filter translator: + +- Forward the packet between the interface and the pfinet server. +- Filter the packet. + +the proxy of the proc server: + +- Forward all requests from the process to its proc server. +- The proxy doesn't do any real work except returning the host private port and the master device port of the proxy (shown as an example). + +the devnode translator: + +- Create a device file to help open the network device. + + +### The Code Read + +- boot + +### Documentation Read + + +- [A Programmer's Guide to the Mach System Calls](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machsys.doc) +- [Meet Mach](http://www.stepwise.com/Articles/Technical/MeetMach.html) by James Scott +- [A Programmer's Guide to the Mach User Environment](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machuse.doc), the MIG part +- Part of The GNU Mach Reference Manual and The GNU Hurd Reference Manual +- The Hurd, a presentation by Marcus Brinkmann +- Towards a New Strategy of OS Design, an architectural overview by Thomas Bushnell, BSG. +- GNU/Hurd User's Guide +- The Hurd Hacking Guide diff --git a/community/dhug.mdwn b/community/dhug.mdwn new file mode 100644 index 00000000..02a404cf --- /dev/null +++ b/community/dhug.mdwn @@ -0,0 +1,7 @@ +The Dunedin (GNU/)Hurd Users Group is a small group of currently 2 people in Dunedin, New Zealand. + +At the moment our main role is producing the CD install images, mainly thanks to Philip Charles. + +Mail me if you want info or want to get in contact. + +-- [[Main/AndrewMitchell]] - 16 Oct 2002 diff --git a/community/facebook.mdwn b/community/facebook.mdwn new file mode 100644 index 00000000..b5340224 --- /dev/null +++ b/community/facebook.mdwn @@ -0,0 +1,12 @@ +[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + +There is [a Facebook group for the Hurd](http://www.facebook.com/group.php?gid=5141429597). If you're on Facebook, join it and say hello. + diff --git a/community/flavioc.mdwn b/community/flavioc.mdwn new file mode 100644 index 00000000..9c9af71d --- /dev/null +++ b/community/flavioc.mdwn @@ -0,0 +1,126 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +Name: Flávio Cruz + +Email: flaviocruz at gmail dot com + +Some [Hurd stuff](http://opensvn.csie.org/leic/hurd/) + +And code: [cl-hurd](http://freehg.org/u/flavioc/cl-hurd/) + +hg clone [http://freehg.org/u/flavioc/cl-hurd/](http://freehg.org/u/flavioc/cl-hurd/) + +## Summer session + +Creating an extensible translator library in lisp using the mig generated stubs. + +### What's done + +- The library for writing translators is mostly written. +- This library is intended to implement virtual filesystems. Examples are: translators were data is located in a local file (like zipfs, tarfs, rarfs, ...), single file translators (that do content filtering, output of a command, etc), network based filesystems (ftpfs, httpfs, ...), proxy filesystems (like hostmux, usermux, etc..) +- It's possible to specialize the basic translator library and implement new translator classes. This is done using CLOS. +- There is a tree-translator class that makes the managing of a node tree very easy, doing all the work for us, through a simple directory API and implementing the directory callbacks for us. +- There is a simple example (something like zipfs) translator that can expose the directories and file contents of a ZIP file. +- More translator examples include: + - /dev/null translator. + - /dev/zero translator. + - translator that creates a symlink node. + - tmpfs like translator. + - a translator that does proxying between clients and the underlying translator returning all data in upper-case. + - a translator that watches for changes in a file describing the file system structure. + - an IRC translator. + - a categorizer translator: creates a virtual directory containing files listed in a file, each file is categorized with a script. For example, a script can output the music author (in an mp3 file) and then all files will be categorized by author. +- Translator options (manipulated through fsysopts) have a simple and easy to use API. +- All the Mach port manipulation API is available. +- It's possible to send and receive messages. Simple example: +<pre> + (let* ((spec-mixed (make-message-spec :fields '(:string :integer :char :string :integer :real))) + (msg-mixed (make-message :spec spec-mixed)) + (port (port-allocate :right-receive))) + (send-message msg-mixed :remote port :data (list "abc" 42 #\b "cba" 314 3.14)) + (receive-message msg-mixed :source port) ; This returns T on success. + (get-message msg-mixed))) ; Returns '("abc" 42 #\b "cba" 314 3.14) +</pre> +- New message types (like :string, :integer) can be implemented, providing a powerful extension mechanism. +- Creation of symlinks and symlink path resolution. +- Creation of character/block devices, fifos and sockets. +- Patch that opens stdin + stdout to /dev/null. +- Project has been separated into 5 ASDF installable systems: + - hurd-common + - mach + - hurd + - hurd-translator + - tree-translator +- Test cases are now written. + + +### What needs to be done + +- Fix fsys-getroot (block happens in trivfs based translators, when they do RPC's to me when I call fsys_getroot to them) and fetch-root (for passive translators). +- Make the library multithreaded (blocked by the pthread conversion project and the unavailable thread support in CLISP) +- Use the socket stubs? +- More documentation + + +### Project dependencies + +- CLISP +- [CFFI](http://common-lisp.net/project/cffi/) (apt-get installable) +- [Flexi streams](http://www.weitz.de/flexi-streams/) (apt-get installable) +- [Trivial garbage](http://www.cliki.net/trivial-garbage) (not in debian repositories) +- [cl-zip](http://common-lisp.net/project/zip/) (only needed for the zip translator) +- [cl-irc](http://common-lisp.net/project/cl-irc/) (for the irc translator) + + +## To do + +### Documentation +- Manually Bootstrapping a Translator + +### Translation +- Translate the Hurd website to Portuguese? + +## Completed tasks + +### Patches +- http://alioth.debian.org/tracker/index.php?group_id=30628&atid=410472 + - libsvg patch accepted. +- Adapted glibc patch (http://www.schwinge.homeip.net/~thomas/tmp/glibc-patches/0009-2007-07-22-version-of-init-first.c_vs._GCC_4.1.patch.patch) + - http://opensvn.csie.org/leic/hurd/patches/glibc-init-first.patch +- Patch to remove some GNUMach IPC warnings and minor cleanup: + - http://opensvn.csie.org/leic/hurd/patches/gnumach-ipc-warnings.patch +- Website patches that correct some encountered typos: + - http://opensvn.csie.org/leic/hurd/patches/hurd-talk-typo.patch + +### Documentation read + +- GNU/Hurd User's Guide, an introduction to the important concepts and software of the GNU system, written for new users, AKA "GNUbies." +- Towards a New Strategy of OS Design, an architectural overview by Thomas Bushnell, BSG. +- The Hurd, a presentation by Marcus Brinkmann. +- The Hurd Hacking Guide. +- The GNU Mach Reference Manual +- The GNU Hurd Reference Manual +- The Unofficial GNU Mach IPC beginner's guide +- Mach IPC without MIG +- CFFI User's Manual + +### Before selection + +- Uptime program in C and Lisp using CFFI. +- Hello translator. + +## Misc + +### Lisp implementations that run on Hurd + +- Clisp +- ECL +- ? diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn new file mode 100644 index 00000000..bab00748 --- /dev/null +++ b/community/gsoc.mdwn @@ -0,0 +1,108 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +The GNU Hurd project has successfully participated in the +[Google Summer of Code 2008](http://code.google.com/soc/2008/hurd/about.html)! + +All in all we had five students working on a diverse selection of five projects +from our [[ideas_list|gsoc/project_ideas]], and the students as well as the mentors +did a great job! + +## Projects + +* [[Sergiu_Ivanov|scolobb]] worked on **namespace-based translator selection**. + Although he wasn't an official (sponsored) GSoC student, he worked on his + project quite as steady as the other students (except for a two week + vacation). The project however was hampered by various misunderstandings, + wrong assumptions, and several major redesigns during the course of the work + -- which is probably more our fault than the student's. In the end, though, he + completed nsmux (the main namespace proxy handling the magic filename + lookups, running dynamic translators on demand); he still works on + finishing the translator stack filtering necessary to implement some of the + desired functionality (accessing files while skipping existing translators). + +* [[Zheng_Da|da]] worked on **network virtualization** and some related topics. In + spite of many open design question in the beginning, he did a lot of good + work -- finishing not only the ethernet multiplexer and filter translators, + which form the core of his project, but also a glibc patch to allow + overriding the standard socket servers with environment variables; the + devnode translator and a pfinet patch to allow accessing network devices + through device files; support for setting the network device in promiscuous + mode in gnumach; a pfinet patch to use BPF for the packet filtering instead + of the old Mach packet filters, and also to set a proper filter rule that + really only passes the required packages to pfinet; a patch for the subhurd + boot program to allow giving arbitrary virtual devices to the subhurd; and a + proxy for the proc server, which allows running unmodified programs with a + pseudo device master port instead of the real one -- providing some of the + subhurd functionality without having to start a complete new system instance. + He is still working on fixing some remaining issues, and on allowing subhurds + to be run by normal users. + +* [[Flavio_Cruz|flavioc]] was working on **Lisp bindings for the Hurd interfaces**, + and did a great job: Not only did he implement bindings for all low-level + interfaces as well as higher-level libraries for easy creation of translators + and other hurdish programs, but also a whole bunch of sample + translators based on these bindings, some of them quite useful on their own + account. He also fixed a few bugs in the Hurd he found along the way. + Presently he is doing some further improvements, like additional abstractions + and more sample translators. + +* [Andrei Barbu](http://csclub.uwaterloo.ca/~abarbu/hurd/) was working on + **porting a kernel instrumentation framework** like dtrace or SystemTap. He + implemented the necessary kernel infrastructure (and some nice general + improvements along the way), making it possible to create tracing programs by + hand; however, only at the end of the summer he realized that SystemTap is + really extremely Linux-specific (while dtrace was ruled out already at the + setout because of licensing problems), so there is no nice frontend yet. + Unfortunately he was not able to continue work beyond the official deadline + because of his PhD. + +* [[Madhusudan.C.S|procfs]] was working on a **new procfs implementation**, to + allow running existing programs based on Linux procfs out of the box. He + managed to implement all the necessary information bits, so the most + important procfs programs now work; and also fixed the procps program suite + to actually build on the Hurd. There are still some major bugs left, though. + Aside from fixing the remaining bugs, he now works on adding some more + information bits that are nontrivial to implement, and on fixing libgtop to + work for us as well. + +## IRC meetings + +Since the selection of the students on we have had regular GSoC IRC meetings, +every Friday 19:00 UTC. + +Minutes from some of the meetings: [[25April08Minutes]], [[02May08Minutes]], [[16May08Minutes]] + +We decided to keep up the meetings after the end of official GSoC, so things +can be properly wrapped up for upstream submission; but also because the +students want to continue discussing progress with their ongoing work, +problems, future directions etc. + +I also think that regular IRC meetings are a good thing in general. + +As always, the meetings are not only for (former) GSoC students and mentors, +but open to any interested party :-) + +If someone of you is lurking around here and would like to contribute, +but feel that you could do so better under formal mentoring: Please +speak up at the meeting! :-) + +## History + +2006 and 2007 we participated in GSoC under the umbrella of the GNU project, +getting one slot each year. + +<!-- TODO. Extend. --> + +## 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]]. diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn new file mode 100644 index 00000000..ca844fff --- /dev/null +++ b/community/gsoc/organization_application.mdwn @@ -0,0 +1,210 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +* What is your Organization's Name? + +GNU Hurd + +* What is your Organization's Homepage? + +http://hurd.gnu.org + +* Describe your organization. + +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). + +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. (More than half +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 +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 +[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/). + +* Why is your organization applying to participate in GSoC 2008? What do you +hope to gain by participating? + +For one, 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 it is a good possibility 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. + +Last but not least, we hope the participation will have a positive effect on +our community -- new impulses, increased communication etc. + +* Did your organization participate in previous GSoC years? If so, please +summarize your involvement and the successes and failures of your student +projects. + +We did not participate as an organisation on our own so far. 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. + +We decided to participate as an own organisation this year, as we believe that +will give us much better possibilities to find and select good students. + +* If your organization has not previously participated in GSoC, have you +applied in the past? If so, for what year(s)? + +We didn't apply as as organisation so far. + +* What license does your project use? + +Most of the code in the Hurd servers and the Hurd-specific glibc parts is +licensed GPLv2 or later; it might move to GPLv3 soon. Some components (mostly +the TCP/IP stack and parts of the ext2fs driver) are based on Linux code and +thus GPLv2 only. + +The microkernel (gnumach) is covered by the three-clause BSD license. (And some +minor variations of same...) + +* URL for your ideas page + +[[project_ideas]] + +* What is the main development mailing list for your organization? + +bug-hurd@gnu.org, see http://lists.gnu.org/mailman/listinfo/bug-hurd + +* Where 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. + +[[student_application_form]] + +* Who will be your backup organization administrator? Please enter their Google +Account address. We will email them to confirm, your organization will not +become active until they respond. + +bddebian at gmail + +* What criteria did you use to select these individuals as mentors? 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. + +* Who will your mentors be? Please enter their Google Account address separated +by commas. If your organization is accepted we will email each mentor to invite +them to take part. + +antrik at gmx.net, benasselstine at gmail, samuel.thibault at ens-lyon.org, +glguida at gmail, neal, marcus, ... + +* 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 +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. + +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 +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, so that we get partial results at least if someone disappears. + +* 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 +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 +should go smoothly. + +* What steps will you take to encourage students to interact with your +project's community before, during and after the program? + +As part of the application process, we will ask students to answer very +specific questions about our organisation and the project they chose, which +they won't be able to answer without contacting us and discussing details +already during the application phase. This way we make sure we only get +studends able and willing to communicate with us. + +During the program, we will be asking the students actively about the work they +do, problems they face, decisions they take etc. + +After the program we will continue discussing the projects, and ask the +students to take part in these discussions. + +* 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. diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn new file mode 100644 index 00000000..c4b665b7 --- /dev/null +++ b/community/gsoc/project_ideas.mdwn @@ -0,0 +1,1015 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +This list offers a wide range of tasks: From rather straightforward to pretty +involved ones; from low-level kernel hacking (drivers, VM) to high-level +translators; from fixing bugs, implementing new functionality based on existing +interfaces, to creating totally new mechanisms. + +If you have questions regarding the projects, or if there is more than one that +you are interested in and you are unsure which to choose, don't hesitate to +[[contact_us|communication]]. + +Most project descriptions mention a possible exercise related to the respective +task. Doing this exercise is part of the application process -- the purpose is +to get more familiar with the stuff you will need to complete the project and +with the Hurd community. Contact us if you encounter any difficulties -- we +will assist you with as well as we can :-) + +Please report on the progress you make with the exercise. This allows us to get +a better picture of how well you can cope with the task; as well as how well +you manage the necessary communication with us :-) + +The exercise is part of the application process, but it's perfectly OK if you +do it only after handing in the first version of your application. (The +experience you get with the exercise should help you to further improve your +application afterwards...) In general, don't hesitate too long -- the sooner +you submit your first proposal, the sooner we can give feedback! + +Take a look at our [[application_template|student_application_form]] to get an +idea what your application should contain. + + +## Bindings to Other Programming Languages + +The main idea of the Hurd design is giving users the ability to easily +modify/extend the system's functionality ([[extensible_system|extensibility]]). +This is done by creating [[filesystem_translators|hurd/translator]] and other +kinds of Hurd servers. + +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. + +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 +high-level language, that helps quickly creating simple programs, are highly +welcome. + +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 +the features available in the respective language. + +These more specialised 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 task is to create easy to use Hurd bindings for a language of the student's +choice, and some example servers to prove that it works well in practice. This +project will require gaining a very good understanding of the various Hurd +interfaces. Skills in designing nice programming interfaces are a must. + +There has already been some [earlier work on Python +bindings](http://www.sigill.org/files/pytrivfs-20060724-ro-test1.tar.bz2), that +perhaps can be re-used. Also some work on [Perl +bindings](http://www.nongnu.org/hurdextras/#pith) is availabled. + +### Lisp + +Most Lisp implementations provide a Foreign Function Interface (FFI) that +enables the Lisp code to call functions written in another language. +Specifically, most implementations provide an FFI to the C ABI (hence giving +access to C, Fortran and possibly C++). + +Common Lisp has even a portability layer for such FFI, +[CFFI](http://common-lisp.net/project/cffi/), so that you can write bindings +purely in Lisp and use the same binding code on any implementation supported by +CFFI. + +Many Scheme implementation also provide an FFI. [Scheme48](http://www.s48.org/) +is even the implementation used to run scsh, a Scheme shell designed to provide +instant access to POSIX functions. +[Guile](http://www.gnu.org/software/guile/guile.html) is the GNU project's +Scheme implementation, meant to be embeddable and provide access to C. At least +[Gambit](http://dynamo.iro.umontreal.ca/~gambit/), +[Chicken](http://www.call-with-current-continuation.org/), +[Bigloo](http://www-sop.inria.fr/mimosa/fp/Bigloo/) and +[PLT](http://www.plt-scheme.org/) are known to provide an FFI too. + +With respect to the packaging and dependencies, the good news is that Debian +comes handy: 5 Common Lisp implementations are packaged, one of which has +already been ported to Hurd (ECL), and CFFI is also packaged. As far as Scheme +is concerned, 14 [R5RS](http://www.schemers.org/Documents/Standards/R5RS/) +implementations are provided and 1 [R6RS](http://www.r6rs.org/). + +Possible mentors: Pierre THIERRY (nowhere_man) for Common Lisp or Scheme, and perhaps Python + +Exercise: Write some simple program(s) using Hurd-specific interfaces in the +language you intend to work on. For a start, you could try printing the system +uptime. A more advanced task is writing a simple variant of the hello +translator (you can use the existing C imlementation as reference), +implementing only open() and read() calls. Don't only write an implementations +using the existing C libraries (libps, libtrivfs), but also try to work with +the MiG-generated stubs directly. If you are ambitious, you could even try to +write your own stubs... + +*Status*: Flavio Cruz has completed [[Lisp_bindings|flavioc]] for GSoC 2008! + + +## Virtualization Using Hurd Mechanisms + +The main idea behind the Hurd design is to allow users to replace almost any +system functionality ([[extensible_system|extensibility]]). Any user can easily +create a subenvironment using some custom [[servers|hurd/translator]] instead +of the default system servers. This can be seen as an +[[advanced_lightweight_virtualization|hurd/virtualization]] mechanism, which +allows implementing all kinds of standard and nonstandard virtualization +scenarios. + +However, though the basic mechanisms are there, currently it's not easy to make +use of these possibilities, because we lack tools to automatically launch the +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. The current +implementation has serious limitations though. A subhurd can only be started by +root. There are no communication channels between the subhurd and the main one. +There is no mechanism for safe sharing of hardware devices. Fixing this issues +could turn subhurds into a very powerful solution for lightweight +virtualization using so-called logical partitions. (Similar to Linux-vserver, +OpenVZ etc.) + +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 +desirable to have a smaller subenvironment, living withing the main system and +using most of its facilities -- similar to a chroot environment. A simple way +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 +either chroot or some similar mechanism to create a subenvironment with a +different root filesystem. + +It's also desirable to have a mechanism allowing a user to set up such a custom +environment in a way that it will automatically get launched on login -- +practically allowing the user to run a customized operating system in his own +account. + +Yet another interesting scenario would be a subenvironment -- using some kind +of special filesystem proxy again -- in which the user serves as root, being +able to create local sub-users and/or sub-groups. + +This would allow the user to run "dangerous" applications (webbrowser, chat +client etc.) in a confined fashion, allowing it access to only a subset of the +user's files and other resources. (This could be done either using a lot of +groups for individual resources, and lots of users for individual applications; +adding a user to a group would give the corresponding application access to the +corresponding resource -- an advanced [[ACL]] mechanism. Or leave out the groups, +assigning the resources to users instead, and use the Hurd's ability for a +process to have multiple user IDs, to equip individual applications with sets +of user IDs giving them access to the necessary resources -- basically a +[[capability]] mechanism.) + +The student will have to pick (at least) one of the described scenarios -- or +come up with some other one in a similar spirit -- and implement all the tools +(scripts, translators) necessary to make it available to users in an +easy-to-use fashion. While the Hurd by default already offers the necessary +mechanisms for that, these are not perfect and could be further refined for +even better virtualization capabilities. Should need or desire for specific +improvements in that regard come up in the course of this project, implementing +these improvements can be considered part of the task. + +Completing this project will require gaining a very good understanding of the +Hurd architecture and spirit. Previous experience with other virtualization +solutions would be very helpful. + +Possible mentors: Olaf Buddenhagen (antrik) + +Exercise: Make some modification to the "boot" programm used to start subhurds. +(More specific suggestions welcome... :-) ) + +*Status*: Zheng da has has implemented [[network_virtualization|da]] (an +important prerequisite for unprivileged subhurds) for GSoC 2008, along with +various other interesting bits, including a mechanism to override socket +servers; a proc proxy that allows running processes/subenvironments with a +pseudo device master port; and a mechanism to pass arbitrary virtual devices to +a subhurd. He is still working on running subhurds by normal users. + + +## Namspace-based Translator Selection + +The main idea behind the Hurd is to make (almost) all system functionality +user-modifiable ([[extensible_system|extensibility]]). This includes a +user-modifiable filesystem: the whole filesystem is implemented decentrally, by +a set of filesystem servers forming the directory tree together, a +[[hurd/virtual_file_system]]. These filesystem servers are called +[[translators|hurd/translator]], and are the most visible feature of the Hurd. + +The reason they are called translators is because when you set a translator on +a filesystem node, the underlying node(s) are hidden by the translator, but the +translator itself can access them, and present their contents in a different +format -- translate them. A simple example is a +[[gunzip_translator|hurd/translator/storeio]], which can be set on a gzipped +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... + +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 +understanding various mailbox formats anymore. All formats can be parsed by +special translators, and the mail reader gets the data as a uniform, directly +usable filesystem structure. Translators can also be stacked: If you have a +compressed mailbox for example, first apply a gunzip translator, and then an +mbox translator on top of that. + +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 +feature almost useless. + +A possible solution is implementing a mechanism for selecting translators +through special filename attributes. For example you could use +`index.html.gz,,+` and `index.html.gz,,-` to choose between translated and +untranslated versions of a file. Or you could use `index.html.gz,,u` to get +the contents of the file with a gunzip translator applied automatically. You +could also use attributes on whole directory trees: `.,,0/` would give you a +directory tree corresponding to the current directory, but with any translators +disabled, for doing a backup. And `site,,u/*.html.gz` would present a whole +directory tree of compressed HTML files as uncompressed files. + +One benefit of the Hurd's flexibility is that it should be possible to +implement such a mechanism without touching the existing Hurd components: +Rather, just implement a special proxy, that mirrors the normal filesystem, but +is able to interpret the special extensions and present transformed files in +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 +flexible. + +The goal of this project is implementing a prototype proxy; perhaps also a +first version of the global variant as proof of concept, if time permits. It +requires good understanding of the name lookup mechanism, and translator +programming; but the implementation should not be too hard. Perhaps the hardest +part is finding a convenient, flexible, elegant, hurdish method for mapping the +special extensions to actual translators... + +Possible mentors: Olaf Buddenhagen (antrik) + +Exercise: Try to make some modification to the existing unionfs and/or firmlink +translators. (More specific suggestions welcome... :-) ) + +*Status*: Sergiu Ivanov has been working *voluntarily* on +[[namespace-based_translator_selection|scolobb]], as an inofficial GSoC 2008 +participant! Not all the desired functionality is in place yet; work is +ongoing. + + +## Fix File Locking + +Over the years, [[UNIX]] has aquired 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. + +The goal is to make all file locking mechanisms work properly. This requires +finding all existing shortcomings (through systematic testing and/or checking +for known issues in the bug tracker and mailing list archives), and fixing +them. + +This task will require digging into parts of the code to understand how file +locking works on the Hurd. Only general programming skills are required. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Find one of the existing issues, either by looking at the task/bug +trackers on savannah, or by trying things out yourself; and take a go at it. +Probably you wont' be able to fix the problem in a limited amount of time, but +you should be able to do a detailed analysis of the issue at least. + + +## `procfs` + +Although there is no standard (POSIX or other) for the layout of the `/proc` +pseudo-filesystem, it turned out a very useful facility in GNU/Linux and other +systems, and many tools concerned with process management use it. (`ps`, `top`, +`htop`, `gtop`, `killall`, `pkill`, ...) + +Instead of porting all these tools to use [[hurd/libps]] (Hurd's official method for +accessing process information), they could be made to run out of the box, by +implementing a Linux-compatible `/proc` filesystem for the Hurd. + +The goal is to implement all `/proc` functionality needed for the various process +management tools to work. (On Linux, the `/proc` filesystem is used also for +debugging purposes; but this is highly system-specific anyways, so there is +probably no point in trying to duplicate this functionality as well...) + +The [[existing_partially_working_procfs_implementation|hurd/translator/procfs]] +can serve as a starting point, but needs to be largely rewritten. (It should +use [[hurd/libnetfs]] rather than [[hurd/libtrivfs]]; the data format needs to +change to be more Linux-compatible; and it needs adaptation to newer system +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. + +**Note**: We already have several applications for this task. + +Possible mentors: Olaf Buddenhagen (antrik) + +Exercise: Add or fix one piece in the existing procfs translator. + +*Status*: Madhusudan.C.S has implemented a new, fully functional [[procfs]] for +GSoC 2008. He is still working on some outstanding issues. + + +## New Driver Glue Code + +Although a driver framework in userspace would be desirable, presently the Hurd +uses kernel drivers in the microkernel, +[[GNU_Mach|microkernel/mach/gnumach]]. (And changing this would be far beyond a +GSoC project...) + +The problem is that the drivers in GNU Mach are presently old Linux drivers +(mostly from 2.0.x) accessed through a glue code layer. This is not an ideal +solution, but works quite OK, except that the drivers are very old. The goal of +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. + +Using [ddekit](http://demo.tudos.org/dsweeper_tutorial.html) instead of our +own glue code can be explored as a possible alternative approach. + +This is a doable, but pretty involved project. Experience with driver +programming under Linux (or BSD) is a must. (No Hurd-specific knowledge is +required, though.) + +This is [[GNU_Savannah_task 5488]]. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Try porting one driver from Linux 2.6 to run in the old framework. +The port needn't be elegant or complete; but it would be nice if you could get +it to work at least partially... + + +## Server Overriding Mechanism + +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, +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 +independent set of servers.) + +The goal of this project is to provide a simple method for overriding +individual standard servers, using environment variables, or a special +subshell, or something like that. + +Various approaches for such a mechanism has been discussed before. +Probably the easiest (1) would be to modify the Hurd-specific parts of [[hurd/glibc]], +which are contacting various standard servers to implement certain system +calls, so that instead of always looking for the servers in default locations, +they first check for overrides in environment variables, and use these instead +if present. + +A somewhat more generic solution (2) could use some mechanism for arbitrary +client-side namespace overrides. The client-side part of the filename lookup +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 +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 +used that mirror the default namespace but override certain locations. (5) + +Variants (4) and (5) are the most powerful. They are intimately related to +chroots: (4) is like the current chroot implementation works in the Hurd, and +(5) has been proposed as an alternative. The generic overriding mechanism could +be implemented on top of chroot, or chroot could be implemented on top of the +generic overriding mechanism. But this is out of scope for this project... + +In practice, probably a mix of the different approaches would prove most useful +for various servers and use cases. It is strongly recommended that the student +starts with (1) as the simplest approach, perhaps augmenting it with (3) for +certain servers that don't work with (1) because of indirect invocation. + +This tasks requires some understanding of the Hurd internals, especially a good +understanding of the file name lookup mechanism. It's probably not too heavy on +the coding side. + +This is [[GNU_Savannah_task 6612]]. Also there are quite a bit of emails +discussing this topic, from a last year's GSoC application -- see +<http://lists.gnu.org/archive/html/bug-hurd/2007-03/msg00050.html>, +<http://lists.gnu.org/archive/html/bug-hurd/2007-03/msg00114.html>, +<http://lists.gnu.org/archive/html/bug-hurd/2007-06/msg00082.html>, +<http://lists.gnu.org/archive/html/bug-hurd/2008-03/msg00039.html>. + +Possible mentors: Olaf Buddenhagen (antrik) + +Exercise: Come up with a glibc patch that allows overriding one specific +standard server using method (1). + +*Status*: Overriding of socket servers through environment variables has been +implemented by Zheng Da for GSoC 2008, as part of his +[[network_virtualization|da]] project. + + +## `dtrace` Support + +One of the main problems of the current Hurd implementation is very poor +performance. While we have a bunch of ideas what could cause the performance +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 +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 +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 +interactions. + +The most popular framework for that is Sun's dtrace; but there might be others. +The student has to evaluate the existing options, deciding which makes most +sense for the Hurd; and implement that one. (Apple's implementation of dtrace +in their Mach-based kernel might be helpful here...) + +This project requires ability to evaluate possible solutions, and experience +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 +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 +detailed analysis of the issue. + +*Status*: Andei Barbu was working on +[SystemTap](http://csclub.uwaterloo.ca/~abarbu/hurd/) for GSoC 2008, but it +turned out too Linux-specific. He implemented kernel probes, but there is no +nice frontend yet. + + +## Hurdish TCP/IP Stack + +The Hurd presently uses a [[TCP/IP_stack|hurd/translator/pfinet]] based on code from an old Linux version. +This works, but lacks some rather important features (like PPP/PPPoE), and the +design is not hurdish at all. + +A true hurdish network stack will use a set of stack of [[hurd/translator]] processes, +each implementing a different protocol layer. This way not only the +implementation gets more modular, but also the network stack can be used way +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 +desired constellation. + +While the general architecture is pretty much given by the various network +layers, it's up to the student to design and implement the various interfaces +at each layer. This task requires understanding the Hurd philosophy and +translator programming, as well as good knowledge of TCP/IP. + +This is [[GNU_Savannah_task 5469]]. + +Possible mentors: ? + +Exercise: Make some modification to the existing pfinet implementation. (More +specific suggestions welcome... :-) ) + + +## 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 +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. + +This project encompasses implementing NFSv3 support, fixing bugs and +performance problems -- the goal is to have good NFS support. The work done in +a previous unfinished GSoC project can serve as a starting point. + +Both client and server parts need work, though the client is probably much more +important for now, and shall be the major focus of this project. + +This task, [[GNU_Savannah_task 5497]], has no special prerequisites besides general programming skills, and +an interest in file systems and network protocols. + +Possible mentors: ? + +Exercise: Make a go at one of the known issues in the NFS client. You might not +be able to finish this in the limited amount of time, but you should at least +be able to make a detailed analysis of the issue. + + +## 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 +exmple instrumenting the code to check locking correctness constantly at +runtime. Or implementing a unit testing framework that explicitely checks +locking in various code paths. (The latter could serve as a template for +implementing unit checks in other parts of the Hurd codebase...) + +This task requires experience with debugging locking issues in multithreaded +applications. + +Possible mentors: ? + +Exercise: Hack libdiskfs to keep count of the number of locks currently held. + + +## Convert Hurd Libraries and Servers to pthreads + +The Hurd was originally created at a time when the [pthreads +standard](http://www.opengroup.org/onlinepubs/009695399/basedefs/pthread.h.html) +didn't exist yet. Thus all Hurd servers and libraries are using the old +[[cthreads|hurd/libcthreads]] package that came with [[microkernel/Mach]], +which is not compatible with [[pthreads|hurd/libpthread]]. + +Not only does that mean that people hacking on Hurd internals have to deal with +a non-standard thread package, which nobody is familiar with. Although a +pthreads implementation for the Hurd was created in the meantime, it's not +possible to use both cthreads and pthreads in the same program. Consequently, +pthreads can't presently be used in any Hurd servers -- including translators. + +Some work already has been done once on converting the Hurd servers and +libraries to use pthreads, but that work hasn't been finished. It is available +as [[GNU_Savannah_task 5487]] and can of course be used to base the new work +upon. + +The goal of this project is to have all the Hurd code use pthreads. Should any +limitations in the existing pthreads implementation turn up that hinder this +transition, they will have to be fixed as well. + +One possible option is creating a wrapper that implements the cthreads +interfaces on top of pthreads, to ease the transition -- but it might very well +turn out that it's easier to just change all the existing code to use pthreads +directly. This is up to the student. Such a wrapper has been proposed as +[[GNU_Savannah_task 7895]] and its implementation would be a useful +starting-point. + +This project requires relatively little Hurd-specific knowledge. Experience +with multithreaded programming in general and pthreads in particular is +required, though. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Take some small piece of code using ctreads and convert it to +pthreads. + + +## Sound Support + +The Hurd presently has no sound support. Fixing this, [[GNU_Savannah_task +5485]], requires two steps: the first is to port some other kernel's drivers to +[[GNU_Mach|microkernel/mach/gnumach]] so we can get access to actual sound +hardware. The second is to implement a userspace server ([[hurd/translator]]), +that implements an interface on top of the kernel device that can be used by +applications -- probably OSS or maybe ALSA. + +Completing this task requires porting at least one driver (e.g. from Linux) for +a popular piece of sound hardware, and the basic userspace server. For the +driver part, previous experience with programming kernel drivers is strongly +advisable. The userspace part requires some knowledge about programming Hurd +translators, but shouldn't be too hard. + +Once the basic support is working, it's up to the student to use the remaining +time for porting more drivers, or implementing a more sophisticated userspace +infrastructure. The latter requires good understanding of the Hurd philosophy, +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: ? + +Exercise: Take a newer driver for a device in one of the subsystems we already +implement (disk or network) from a newer Linux version, or some other operating +system, and try to port it so that it runs in the existing driver framework. +The port needn't be elegant or complete; but it would be nice if you could get +it to work at least partially... + + +## 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. + +The reason for this slowness is lack and/or bad implementation of common +optimisation techniques, like scheduling reads and writes to minimalize 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. + +The goal of this project is to analyze the current situation, and implement/fix +various optimisations, 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]], +[[pager|hurd/libpager]], driver), and general experience with +optimising 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: ? + +Exercise: Make some modification in at least one of the components involved in +disk I/O. (More specific suggestions welcome... :-) ) + + +## VM Tuning + +Hurd/[[microkernel/Mach]] presently make very bad use of the available physical memory in the +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 +heuristics when to start paging. (See <http://lists.gnu.org/archive/html/bug-hurd/2007-08/msg00034.html> 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 +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 +VM, and virtual memory in general. + +This project is related to [[GNU_Savannah_task 5489]]. + +Possible mentors: ? + +Exercise: Make some modification to the existing VM code. You could try to find +a piece of code that can be improved with simple code optimization, for +example. + + +## `mtab` + +In traditional monolithic system, the kernel keeps track of all mounts; the +information is available through `/proc/mounts` (on Linux at least), and in a +very similar form in `/etc/mtab`. + +The Hurd on the other hand has a totally +[[decentralized_file_system|hurd/virtual_file_system]]. There is no single +entity involved in all mounts. Rather, only the parent file system to which a +mountpoint ([[hurd/translator]]) is attached is involved. As a result, there +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. + +One possible solution to this would be for the translator startup mechanism to +update the `mtab` on any `mount`/`unmount`, like in traditional systems. +However, there are same problems with this approach. Most notably: what to do +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 an 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. + +A more promising approach is to have `mtab` exported by a special translator, +which gathers the necessary information on demand. This could work by +traversing the tree of translators, asking each one for mount points attached +to it. (Theoretically, it could also be done by just traversing *all* nodes, +checking each one for attached translators. That would be very inefficient, +though. Thus a special interface is probably required, that allows asking a +translator to list mount points only.) + +There are also some other issues to keep in mind. Traversing arbitrary +translators set by other users can be quite dangerous -- and it's probably not +very interesting anyways what private filesystems some other user has mounted. +But what about the global `/etc/mtab`? Should it list only root-owned +filesystems? Or should it create different listings depending on what user +contacts it?... + +That leads to a more generic question: which translators should be actually +listed? There are different kinds of translators: ranging from traditional +filesystems ([[disks|hurd/libdiskfs]] and other actual +[[stores|hurd/translator/storeio]]), but also purely virtual filesystems like +[[hurd/translator/ftpfs]] or [[hurd/translator/unionfs]], and even things that +have very little to do with a traditional filesystem, like a +[[gzip_translator|hurd/translator/storeio]], +[[mbox_translator|hurd/translator/mboxfs]], +[[xml_translator|hurd/translator/xmlfs]], or various device file translators... +Listing all of these in `/etc/mtab` would be pretty pointless, so some kind of +classification mechanism is necessary. By default it probably should list only +translators that claim to be real filesystems, though alternative views with +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 +understanding of the translator mechanism and Hurd interfaces in general. + +Possible mentors: Olaf Buddenhagen (antrik) + +Exercise: Create a simple translator using libnetfs, that only allows creating +directories and attaching other translators. + + +## GNU Mach Code Cleanup + +Although there are some attempts to move to a more modern microkernel +alltogether, 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]]. + +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. +([[Pager_interface|microkernel/mach/external_pager_mechanism]], +[[microkernel/mach/IPC]], etc.) + +Also, Mach being a research project, many things were tried, adding lots of +optional features not really needed. + +The result of all this is that the current code base is in a pretty bad shape. +It's rather hard to make modifications -- to make better use of modern hardware +for example, or even to fix bugs. The goal of this project is to improve the +situation. + +The task starts out easy, with fixing compiler warnings. Later it moves on to +more tricky things: removing dead or unneeded code paths; restructuring code +for readability and maintainability. + +This task requires good knowledge of C, and experience with working on a large +existing code base. Previous kernel hacking experience is an advantage, but +not really necessary. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Create a few simple patches that fix some of the compiler warnings, +rework a piece of ugly code etc. + + +## `xmlfs` + +Hurd [[translators|hurd/translator]] allow presenting underlying data in a +different format. This is a very powerful ability: it allows using standard +tools on all kinds of data, and combining existing components in new ways, once +you have the necessary translators. + +A typical example for such a translator would be xmlfs: a translator that +presents the contents of an underlying XML file in the form of a directory +tree, so it can be studied and edited with standard filesystem tools, or using +a graphical file manager, or to easily extract data from an XML file in a +script etc. + +The exported directory tree should represent the DOM structure of the document, +or implement XPath, or both, or some combination thereof (perhaps XPath could +be implemented as a second translator working on top of the DOM one) -- +whatever works well, while sticking to XML standards as much as possible. + +Ideally, the translation should be reversible, so that another, complementary +translator applied on the expanded directory tree would yield the original XML +file again; and also the other way round, applying the complementary translator +on top of some directory tree and xmlfs on top of that would yield the original +directory again. However, with the different semantics of directory trees and +XML files, it might not be possible to create such a universal mapping. Thus +it is a desirable goal, but not a strict requirement. + +The goal of this project is to create a fully usable XML translator, that +allows both reading and writing any XML file. Implementing the complementary +translator also would be nice if time permits, but is not mandatory part of the +task. + +The [[existing_partial_(read-only)_xmlfs_implementation|hurd/translator/xmlfs]] +can serve as a starting point. + +This task requires pretty good designing skills. Good knowledge of XML is also +necessary. Learning translator programming will obviously be necessary to +complete the task. + +Possible mentors: Olaf Buddenhagen (antrik) + +Exercise: Make some modification to the existing xmlfs translator, and write a +shell script that uses xmlfs to extract some interesting information from an +.odt document. (More specific suggestions welcome... :-) ) + + +## 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 +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 +software packages, GNU/Linux distributions usually come with a package manager, +which keeps track of all files upon installation/removal in some kind of +central database. + +An alternative approach is the one implemented by GNU Stow: each package is +actually installed in a private directory tree. The actual standard directory +structure is then created by collecting the individual files from all the +packages, and presenting them in the common `/bin`, `/lib`, etc. locations. + +While the normal Stow package (for traditional UNIX systems) uses symlinks to +the actual files, updated on installation/deinstallation events, the Hurd +[[hurd/translator]] mechanism allows a much more elegant solution: +[[hurd/translator/stowfs]] (which is actually a special mode of +[[hurd/translator/unionfs]]) creates virtual directories on the fly, composed +of all the files from the individual package directories. + +The problem with this approach is that unionfs presently can be launched only +once the system is booted up, meaning the virtual directories are not available +at boot time. But the boot process itself already needs access to files from +various packages. So to make this design actually usable, it is necessary to +come up with a way to launch unionfs very early at boot time, along with the +root filesystem. + +Completing this task will require gaining a very good understanding of the Hurd +boot process and other parts of the design. It requires some design skills +also to come up with a working mechanism. + +Possible mentors: ? + +Exercise: Try to write a dummy server that is started instead of ext2fs on +system boot, and starts the actual ext2fs in turn. + + +## Fix `tmpfs` + +In some situations it is desirable to have a file system that is not backed by +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 +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 +having a real [[hurd/translator/tmpfs]], which creates all filesystem +structures directly in RAM, allocating memory on demand. + +The Hurd has had such a tmpfs for a long time. However, the existing +implementation doesn't work anymore -- it got broken by changes in other parts +of the Hurd design. + +There are several issues. The most serious known problem seems to be that for +technical reasons it receives [[microkernel/mach/RPC]]s from two different +sources on one [[microkernel/mach/port]], and gets mixed up with them. Fixing +this is non-trivial, and requires a good understanding of the involved +mechanisms. + +The goal of this project to get a fully working, full featured tmpfs +implementation. It requires digging into some parts of the Hurd, incuding the +[[pager_interface|hurd/libpager]] and [[hurd/translator]] programming. This +task probably doesn't require any design work, only good debugging skills. + +Possible mentors: ? + +Exercise: Take a go at one of the existing issues in tmpfs. You may not be able +to finish this in the limited amount of time, but you should at least be able +to do a detailed analysis of the problem. + + +## Lexical `..` Resolution + +For historical reasons, [[UNIX]] filesystems have a real (hard) `..` link from each +directory pointing to its parent. However, this is problematic, because the +meaning of "parent" really depends on context. If you have a symlink for +example, you can reach a certain node in the filesystem by a different path. If +you go to `..` from there, UNIX will traditionally take you to the hard-coded +parent node -- but this is usually not what you want. Usually you want to go +back to the logical parent from which you came. That is called "lexical" +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. + +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 +functional afterwards. This task requires understanding the filename resolution +mechanism. It's probably a relatively easy task. + +See also [[GNU_Savannah_bug 17133]]. + +Possible mentors: ? + +Exercise: Make some modification to the name lookup mechanism. (More specific +suggestions welcome... :-) ) + + +## 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 +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 +interpretation of filenames in a chroot; to reworking the whole passive +translator mechanism. Some involving a completely different approch to +`chroot` implementation, using a proxy instead of a special system call in the +filesystem servers. + +The task is to pick and implement one approach for fixing chroot. + +This task is pretty heavy: it requires a very good understanding of file name +lookup and the translator mechanism, as well as of security concerns in general +-- the student must prove that he really understands security implications of +the UNIX namespace approach, and how they are affected by the introduction of +new mechanisms. (Translators.) More important than the acualy code is the +documentation of what he did: he must be able to defend why he chose a certain +approach, and explain why he believes this approach really secure. + +Possible mentors: ? + +Exercise: Make some modification to the chroot mechanism. (More specific +suggestions welcome :-) ) + + +## Hurdish Package Manager for the GNU System + +Most GNU/Linux systems use pretty sophisticated package managers, to ease the +management of installed software. These keep track of all installed files, and +various kinds of other necessary information, in special databases. On package +installation, deinstallation, and upgrade, scripts are used that make all kinds +of modifications to other parts of the system, making sure the packages get +properly integrated. + +This approach creates various problems. For one, *all* management has to be +done with the distribution package management tools, or otherwise they would +loose track of the system state. This is reinforced by the fact that the state +information is stored in special databases, that only the special package +management tools can work with. + +Also, as changes to various parts of the system are made on certain events +(installation/deinstallation/update), managing the various possible state +transitions becomes very complex and bug-prone. + +For the official (Hurd-based) GNU system, a different approach is intended: +making use of Hurd [[translators|hurd/translator]] -- more specifically their +ability to present existing data in a different form -- the whole system state +will be created on the fly, directly from the information provided by the +individual packages. The visible system state is always a reflection of the +sum of packages installed at a certain moment; it doesn't matter how this state +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 +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. + +The goal of this task is to create these mechanisms. + +Possible mentors: Ben Asselstine (bing) + +Exercise: Write a translator that observes a directory tree using +dir_notify_changes(), and presents a file with a log of changes. + + +## Port the Debian Installer to the Hurd + +The primary means of distributing the Hurd is through Debian GNU/Hurd. +However, the installation CDs presently use an ancient, non-native installer. +The situation could be much improved by making sure that the newer *Debian +Installer* works on the Hurd. + +Some preliminary work has been done, see +<http://wiki.debian.org/DebianInstaller/Hurd>. + +The goal is to have the Debian Installer fully working on the Hurd. It +requires relatively little Hurd-specific knowledge. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Try to get one piece of the installer running on Hurd. diff --git a/community/gsoc/student_application_form.mdwn b/community/gsoc/student_application_form.mdwn new file mode 100644 index 00000000..d2ddd3ea --- /dev/null +++ b/community/gsoc/student_application_form.mdwn @@ -0,0 +1,92 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +Some of the questions might seem quite intimidating at first. But don't +despair. Most certainly you won't be able to answer all of them right away -- +this is intentional. The goal is *not* to prove that you already know +everything. Rather, we want to see that you are willing to do your howework: To +do some actual research to find the necessary answers. + +Most likely you won't be able to get all answers without contacting us +directly. (On [[IRC]] or using [[mailing_lists]].) This is intentional as well. +We want to see that you are able and willing to communicate with us, to get the +information you need. This is also a chance for us to get to know you a bit :-) + +Also keep in mind that you do not need to give perfect answers when you first +hand in your application. The application process allows us to give feedback; +to request further input on anything that we need. + +With these explanations, we hope the questions don't look so scary anymore :-) + +**Note:** The application Form is [limited to 7500 +characters](http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_student_app). +This is not much. You will need to put some of your information on an external +server, and link to that. + +* 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 +what this task involves! Read the available documentation (and possibly code) +if necessary. And don't hesitate to ask us if you have questions :-) + +* Give a preliminary schedule for your work. The exact dates will obviously be +only guesses; but try to be specific about all the individual steps you will +have to do to complete the task. + +* What things will you have to learn to be able to complete the project? What +do you already know? + +* Why did you choose this project idea? What do you consider most appealing +about it? + +* Please describe your previous programming experience in detail. What +languages do you use? How long have you been programming, and how much? What +kind of programs have you written? What kind of programming (and related) work +are you enjoying most? + +* Have you been involved in any free software ("Open Source") projects yet? +Which projects, how long, and in what way have you been involved? + +* Please try to describe your understanding of how a free software project +works, how people interact in the community. Include anything specific you know +about the Hurd project. How do you imagine your interaction with the community +during GSoC? + +* Have you been active in the Hurd project/Hurd community before? In what way? + +* Are you running or have you run a Hurd system yet? What did you do with it? +How was your experience? + +* Have you ever compiled parts of the Hurd -- including the Hurd +servers/libraries, glibc, gnumach, or some standalone traslator? Which ones, +and how? Please go into details. + +* Please briefly describe the Hurd, including the goals, architecture etc. + +* What makes you interested in the Hurd? Why do you want to work on it? What is +your vision of it's future development? + +* Are you subscribed to bug-hurd@gnu.org, or other Hurd-related mailing lists? +Do you have general experience with mailing list communication? + +* Are you using the #hurd IRC channel on freenode? Are you familiar with IRC in +general? Do you have a permanent internet connection, and/or access to one +during the summer? + +* In what time zone do you live? Would you be able and willing to shift your +day/night rhythm to better match that of other Hurd developers, if necessary? + +* When are the exams and vacations at your University? + +* How much time do you intend to spend on your GSoC project per day/week during +the summer months? What other major activities will you engage in during the +summer? (Moving apartments, longer vacations, other obligations, etc.) If any, +how do you intend to make sure you will be able to dedicate sufficient time to +your project nevertheless? diff --git a/community/howto.mdwn b/community/howto.mdwn new file mode 100644 index 00000000..3f0d0d13 --- /dev/null +++ b/community/howto.mdwn @@ -0,0 +1,95 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + + +This document briefly introduces how to set up the virtual network and connect the subhurd with the main hurd. + + +### 1. Set up the virtual network. + +####1.1 Patch and install GNU Hurd, GNU Mach and the GNU C library. + +Step 1: Get the Hurd and compile it. + + cvs -z3 -d:ext:username@cvs.savannah.gnu.org:/sources/hurd co -r zhengda-soc2008-virt-branch + + +Step 2: apply the [patch](http://www.assembla.com/spaces/VNetHurd/documents/b0eLzUxHmr3ymXab7jnrAJ/download/A%20patch%20of%20gnumach) on the GNU Mach. + +In order to connect the virtual network created in hurd with the external network, we need this patch. It enables the Hurd to set the Mach device into the promiscuous mode, so the real device can accept the packet that goes to the virtual device in hurd. +(This step is optional if we are only interested in creating a internal virtual network.) + +Step 3: apply the [patch](http://www.assembla.com/spaces/VNetHurd/documents/aJidqKp6ur3z-Nab7jnrAJ/download/A%20patch%20of%20glibc) on glibc. + +This patch enables the user to override the default socket server by using the environment variables SOCK_SERV_DIR or SOCK_SERV_%d (%d is the domain of the socket server). + + +#### 1.2 Set up the Hurd components to build the virtual network. + +In this section, I show how to create two virtual interfaces and run three pfinet servers. I assume that the source code of Hurd is in /root/hurd. + +Step 4: create the network device file in /dev with devnode. +The network device file is used to help other translators open the device. + + # settrans -acfg /dev/eth0 /root/hurd/devnode/devnode -d eth0 + +Step 5: create the virtual network device with eth-multiplexer. + +eth-multiplexer is responsible to create the virtual network device and dispatch the packet to the right clients that connect to the virtual device. It also connects the virtual network and the external network. + + # settrans -acfg /root/multiplexer /root/hurd/eth-multiplexer/eth-multiplexer -v 2 -i /dev/eth0 + +Step 6: create the network device files for the virtual network device with devnode. + + # settrans -acfg /dev/veth0 /root/hurd/devnode/devnode -d veth0 -M /root/multiplexer + # settrans -acfg /dev/veth1 /root/hurd/devnode/devnode -d veth1 -M /root/multiplexer + +Step 7: setup the filter translator eth-filter on the network device. This step is optional. +eth-filter is used to set up the traffic policy on the network device. + + # settrans -acfg /dev/fveth0 /root/hurd/eth-filter/eth-filter -i /dev/veth0 -S 192.168.8.0/24 -R 192.168.8.0/24 + # settrans -acfg /dev/fveth1 /root/hurd/eth-filter/eth-filter -i /dev/veth1 -S 192.168.8.0/24 -R 192.168.8.0/24 + +Step 8: setup the pfinet server on the virtual network device. + + # settrans -afgc /root/socket0/2 /root/hurd/pfinet/pfinet -i /dev/fveth0 -a 192.168.8.10 -g 192.168.8.1 -m 255.255.255.0 + # settrans -afgc /root/socket1/2 /root/hurd/pfinet/pfinet -i /dev/fveth1 -a 192.168.8.11 -g 192.168.8.1 -m 255.255.255.0 + # settrans -afgc /root/socket2/2 /root/hurd/pfinet/pfinet -i /dev/fveth1 -a 192.168.8.12 -g 192.168.8.1 -m 255.255.255.0 + + +#### 1.3 Run the command with the customized pfinet server. + +Step 9: Set environment variables to use the customized pfinet server. + +The environment variable of SOCK_SERV_DIR is used to override all socket servers and SOCK_SERV_%d to override a specific socket server. %d after SOCK_SERV_ is the domain of the protocol that the socket server supports. The environment variable SOCK_SERV_%d has the higher priority than SOCK_SERV_DIR. + + # export SOCK_SERV_2=/root/socket1/2 + +If the modified glibc isn't installed as the system default C library, set LD_LIBRARY_PATH environment. + + # export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/the/path/of/glibc + +We can run any command now, for example, ping. + +A SHELL script is provided to run all translators I mentioned automatically: http://www.assembla.com/spaces/VNetHurd/documents/c2W71ABser3AIxab7jnrAJ/download/runmultiplexer. To use this script, the user must specify the source of the hurd tree (the default value is /root/hurd) and the path of the servers (the default value is /root) where they should be created. This script is only used to test all translators I mentioned above and shows all steps to set up the virtual network. + + +### 2. Connect the subhurd with the main hurd. + +In the main hurd, we still need to do Step 1-9. +We run subhurd, + + # /root/hurd/boot/boot -m eth0=/dev/fveth0 -m eth1=/dev/fveth1 servers.boot /dev/hd1s1 + +In the subhurd, we do Step 1, 4, 8. +Step 4: # settrans -acfg /dev/veth0 /root/hurd/devnode/devnode -d veth0 +Step 8: # settrans -afgc /servers/socket/2 /root/hurd/pfinet/pfinet -i /dev/veth0 -a 192.168.8.20 -g 192.168.8.1 -m 255.255.255.0 + +Now we can communicate from the subhurd with any pfinet server of the main Hurd that runs in the virtual network. diff --git a/community/hurdbr.mdwn b/community/hurdbr.mdwn new file mode 100644 index 00000000..d28e25f7 --- /dev/null +++ b/community/hurdbr.mdwn @@ -0,0 +1,11 @@ +Hurd Br is a brasilian, portuguese speaking, HUG. + +Hurd Br � um grupo de usu�rios de l�ngua portuguesa, principalmente brasileiros, do GNU/Hurd. + +Nossa lista de discuss�o �: <http://www.freelists.org/list/hurd-br> + +Creio que o prop�sito principal do grupo nesse momento � fazer com que o Hurd rode em cima do L4 :-), e mostrar que � poss�vel n�s termos um sistema livre que use um microkernel avan�ado (segunda gera��o)! + +-- [[Main/PietroFerrari]] - 03 Sep 2003 + +-- [[Main/RafaelK]] - 05 Oct 2004 diff --git a/community/livejournal.mdwn b/community/livejournal.mdwn new file mode 100644 index 00000000..9b845d9b --- /dev/null +++ b/community/livejournal.mdwn @@ -0,0 +1,6 @@ +Pop over to <http://www.LiveJournal.org> where I have [created a community](http://www.livejournal.com/community/gnu_hurd/). You can do the following to show your support: + +* list GNU/Hurd as one of your "Interests". You can even click through to make your interest visible to others, listing your name in the results of a related search with others that are interested. +* Subscribe to the gnu\_hurd community + +-- [[Main/GrantBow]] - 27 Feb 2004 diff --git a/community/meetings.mdwn b/community/meetings.mdwn new file mode 100644 index 00000000..b4a5a7b3 --- /dev/null +++ b/community/meetings.mdwn @@ -0,0 +1,24 @@ +[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + +# Upcoming + +* [[Self-organised_2008]] + +# Past + +* [[FOSDEM_2008]] +* [[Weekend_at_stesie's|stesie_2007-10-12]] +* [[FOSDEM_2007]] +* [[RMLL_2006]] +* [[FOSDEM_2006]] +* [[RMLL_2005]] +* [[FOSDEM_2005]] +* ... diff --git a/community/meetings/fosdem_2005.mdwn b/community/meetings/fosdem_2005.mdwn new file mode 100644 index 00000000..984c6637 --- /dev/null +++ b/community/meetings/fosdem_2005.mdwn @@ -0,0 +1,16 @@ +[[meta copyright="Copyright © 2006, 2008 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]]."]]"""]] + +<http://fosdem.org/2005> + +[Article on KernelTrap](http://kerneltrap.org/node/5122) + +[FOSDEM 2005 Hurd Developers' +Mini-Symposium](http://people.debian.org/~neal/FOSDEM-2005/) diff --git a/community/meetings/fosdem_2006.mdwn b/community/meetings/fosdem_2006.mdwn new file mode 100644 index 00000000..c775b658 --- /dev/null +++ b/community/meetings/fosdem_2006.mdwn @@ -0,0 +1,246 @@ +[[meta copyright="Copyright © 2006, 2007, 2008 +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]]."]]"""]] + +<http://fosdem.org/2006> + +FOSDEM will take place on February 25th/26th at the Université Libre de +Bruxelles. + +# Who And When + +<!-- TODO. Use the table plugin. See `fosdem_2007.mdwn'. --> +<table border="1" cellpadding="1" cellspacing="0"> + <tr> + <th bgcolor="#99CCCC"><strong>Name</strong></th> + <th bgcolor="#99CCCC"><strong>Attending</strong></th> + <th bgcolor="#99CCCC"><strong>Arrival</strong></th> + <th bgcolor="#99CCCC"><strong>Return</strong></th> + <th bgcolor="#99CCCC"><strong>Share room with us</strong></th> + </tr> + <tr> + <td>[[AurelienJarno]]</td> + <td> yes </td> + <td> Sat </td> + <td> Sun </td> + <td> probably </td> + </tr> + <tr> + <td>[[BasWijnen]]</td> + <td> yes </td> + <td> Fri </td> + <td> Sun </td> + <td> yes </td> + </tr> + <tr> + <td>[[ChristopherBodenstein]]</td> + <td> yes </td> + <td> N/A </td> + <td> N/A </td> + <td> no </td> + </tr> + <tr> + <td>[[GianlucaGuida]]</td> + <td> yes </td> + <td> Sat </td> + <td> Mon </td> + <td> yes </td> + </tr> + <tr> + <td>[[GuillemJover]]</td> + <td> yes </td> + <td> Fri </td> + <td> Sun </td> + <td> yes </td> + </tr> + <tr> + <td>[[IsabelHuenig]]</td> + <td> no </td> + <td> N/A </td> + <td> N/A </td> + <td> N/A </td> + </tr> + <tr> + <td>[[JeroenDekkers]]</td> + <td> yes </td> + <td> ? </td> + <td> ? </td> + <td> no </td> + </tr> + <tr> + <td>[[JohanRydberg]]</td> + <td> no </td> + <td> N/A </td> + <td> N/A </td> + <td> N/A </td> + </tr> + <tr> + <td>[[JordiMallach]]</td> + <td> yes </td> + <td> N/A </td> + <td> N/A </td> + <td> no </td> + </tr> + <tr> + <td>[[MartinMichlmayr]]</td> + <td> yes </td> + <td> Fri </td> + <td> Sun </td> + <td> yes </td> + </tr> + <tr> + <td>[[MarcoGerards]]</td> + <td> yes </td> + <td> Thu </td> + <td> Sun </td> + <td> yes </td> + </tr> + <tr> + <td>[[MarcusBrinkmann]]</td> + <td> yes </td> + <td> Fri </td> + <td> Sun </td> + <td> yes </td> + </tr> + <tr> + <td>[[MatthieuLemerre]]</td> + <td> probably not </td> + <td> ? </td> + <td> ? </td> + <td> yes, if coming </td> + </tr> + <tr> + <td>[[MichaelAblassmeier]]</td> + <td> probably not </td> + <td> Fri </td> + <td> Sun </td> + <td> yes, if coming </td> + </tr> + <tr> + <td>[[MichaelBanck]]</td> + <td> yes </td> + <td> Fri </td> + <td> Sun </td> + <td> yes </td> + </tr> + <tr> + <td>[[NealWalfield]]</td> + <td> yes </td> + <td> Fri </td> + <td> Sun </td> + <td> yes </td> + </tr> + <tr> + <td>[[OgnyanKulev]]</td> + <td> yes </td> + <td> Thu </td> + <td> Sun </td> + <td> yes </td> + </tr> + <tr> + <td>[[PeterDeSchrijver]]</td> + <td> yes </td> + <td> N/A </td> + <td> N/A </td> + <td> no </td> + </tr> + <tr> + <td>[[OlafBuddenhagen]]</td> + <td> yes </td> + <td> Fri </td> + <td> ? </td> + <td> yes </td> + </tr> + <tr> + <td>[[RobertLemmen]]</td> + <td> no </td> + <td> N/A </td> + <td> N/A </td> + <td> N/A </td> + </tr> + <tr> + <td>[[SamuelThibault]]</td> + <td> no </td> + <td> N/A </td> + <td> N/A </td> + <td> N/A </td> + </tr> + <tr> + <td>[[SoerenSchulze]]</td> + <td> no </td> + <td> N/A </td> + <td> N/A </td> + <td> N/A </td> + </tr> + <tr> + <td>[[Stefan_Siegl|stesie]]</td> + <td> yes </td> + <td> Thu </td> + <td> Mon </td> + <td> yes </td> + </tr> + <tr> + <td>[[Thomas_Schwinge|tschwinge]]</td> + <td> yes </td> + <td> Thu </td> + <td> Mon </td> + <td> yes </td> + </tr> + <tr> + <td>[[TheDuck]]</td> + <td> yes </td> + <td> Fri </td> + <td> Sun </td> + <td> no (with [[HurdFr]]) </td> + </tr> +</table> + + +# General + +There will be a [Keysigning +party](http://wiki.fosdem.org/tiki-index.php?page=KeySigningParty). + + +# Youth Hostel + +<http://www.vjh.be/jeugdherbergen/brussel/main1-5n7-1.htm> + +<http://link2.map24.com/?street0=Heilige%20Geeststraat&zip0=1000&city0=Br%FCssel&state0=&country0=be&name0=&lid=43c26f81&ol=de-de> + +Heilige Geeststraat 2 + +1000 Brüssel + +Phone: +32(0)2 511 04 36 + +Fax: +32(0)2 512 07 11 + +<brussel@vjh.be> + + +# What + +We don't have a Developers Room at FOSDEM, but we could book a meeting room at +the hostel (40 EUR for half a day) + +There is a pre-FOSDEM meeting on Friday night in the Roi d'Espagne on Grand +Place + + +# Photos + +Gianluca: <http://it.gnu.org/~gianluca/images/FOSDEM2006/> + +Michael: <http://people.debian.org/~mbanck/photos/fosdem_2006/> + +Ogi: <http://debian.fmi.uni-sofia.bg/~ogi/gallery/20060318-fosdem2006/> + +Stefan: <http://brokenpipe.de/misc/images/index.cgi?d=fosdem-2006> diff --git a/community/meetings/fosdem_2007.mdwn b/community/meetings/fosdem_2007.mdwn new file mode 100644 index 00000000..c320c1fc --- /dev/null +++ b/community/meetings/fosdem_2007.mdwn @@ -0,0 +1,144 @@ +[[meta copyright="Copyright © 2006, 2007, 2008 +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]]."]]"""]] + +<http://fosdem.org/2007> + +FOSDEM will take place on February 24th/25th at the Université Libre de +Bruxelles. + +# Who And When + +[[table class="table_style_1" data=""" +"Name","Attending","Arrival","Return","Share room with us" +"[[AlfredoBeaumont]]","no","n/a","n/a","n/a" +"[[AndrewResch]]","no","n/a","n/a","n/a" +"[[BenAsselstine]]","no","n/a","n/a","n/a" +"[[Barry_de_Freese|bddebian]]","undecided; help convince the boss","?","?","?" +"[[BasWijnen]]","no","n/a","n/a","n/a" +"[[ChristopherBodenstein]]","?","?","?","?" +"[[ColinLeitner]] and<br />KaroRilling","yes","2007-02-23<br />late","2007-02-26","**yes<br />(two persons)**" +"[[CyrilBrulebois]]","yes","2007-02-23<br />late","?","no (HurdFR)" +"Gaël Le Mignot","no","n/a","n/a","n/a" +"[[GianlucaGuida]]","no","n/a","n/a","n/a" +"[[GuillaumeLibersat]]","yes","?","?","no (HurdFR)" +"[[GuillemJover]]","no","n/a","n/a","n/a" +"[[JeroenDekkers]]","yes","2007-02-22<br />15:30","2007-02-26","**yes**" +"[[JohanRydberg]]","no","n/a","n/a","n/a" +"[[JordiMallach]]","?","?","?","?" +"[[Main/TheDuck]]","yes","2007-02-23<br />late","?","no (HurdFR)" +"[[MarcPoulhies]]","no","n/a","n/a","n/a" +"[[MarcoGerards]]","most probably not","n/a","n/a","n/a" +"[[MarcusBrinkmann]]","yes","2007-02-<strike>22</strike>**23**<br />12:38","2007-02-<strike>26</strike>**25**<br />19:00","**yes**" +"[[MatthieuLemerre]]","no","n/a","n/a","n/a" +"[[ManuelMenal]]","?","?","?","?" +"[[MichaelBanck]]","yes","2007-02-22<br />12:10","2007-02-26<br />11:05","**yes**" +"[[NealWalfield]]","no","n/a","n/a","n/a" +"[[NicolasCenta]]","yes","?","?","no (HurdFR)" +"[[OgnyanKulev]]","no","n/a","n/a","n/a" +"[[OlafBuddenhagen]]","yes","probably 2007-02-22<br />14:32","2007-02-26","**yes**" +"[[PeterDeSchrijver]]","yes","?","?","no" +"[[RichardBraun]]","yes","2007-02-23<br />late","?","no (HurdFR)" +"[[RolandMcGrath]]","?","?","?","?" +"[[SamuelThibault]]","yes","2007-02-24<br />10h17","2007-02-25<br />19h43","**yes**" +"[[SoerenSchulze]]","yes","2007-02-23<br />20:03","2007-02-25","**yes**" +"[[Stefan_Siegl|stesie]]","yes","2007-02-22<br />12:10","2007-02-26<br />11:05","**yes**" +"[[ThomasBushnell]]","?","?","?","?" +"[[Thomas_Schwinge|tschwinge]]","yes","2007-02-22<br />12:10","2007-02-26<br />11:05","**yes**" +"[[TimRetout]]","yes","2007-02-23<br />lunchtime","2007-02-25<br />evening","no" +"[[TomBachmann]]","no","n/a","n/a","n/a" +"[[WouterVanHeyst]]","yes","2007-02-22<br />15:30","2007-02-26","**yes**" +"""]] + +[[HurdFR]] page: <http://wiki.hurdfr.org/index.php/FOSDEM2007> + + +# General + +There will be a keysigning party, see <http://fosdem.org/2007/keysigning>. + + +# Accommodation + +## A-XL flathotel + +<http://www.axlflathotel.be/fr/tarifs.html> + +Fully booked. + + +## Youth hostel _Bruegel_ + +<http://www.vjh.be/jeugdherbergen/brussel/mainE.htm> + +Heilige Geeststraat 2 +1000 Brussels +Phone: +32(0)2 511 04 36 +Fax: +32(0)2 512 07 11 +<brussel@vjh.be> + +[Map via Google maps](http://maps.google.com/maps?f=q&hl=en&q=Heilige+Geeststraat+2,+1000+Brussels,+Belgium&sll=50.846056,4.344578&sspn=0.022599,0.086517&ie=UTF8&om=1&z=15&ll=50.843942,4.351444&spn=0.0113,0.043259&iwloc=cent). +[Map via Map24](http://link2.map24.com/?street0=Heilige%20Geeststraat&zip0=1000&city0=Br%FCssel&state0=&country0=be&name0=&lid=43c26f81&ol=de-de). + +Been there in 2006. It was okay. + +[[SamuelThibault]] booked rooms at ~ 18.60€ there: + +[[table class="table_style_1" data=""" +"Night of...","Persons" +"2007-02-22","<strike>7</strike>**6**" +"2007-02-23","10" +"2007-02-24","11" +"2007-02-25","<strike>9</strike>**8**" +"""]] + +i.e including sdschulze, who hereby confirms + +We need someone (not me, since I'm arriving on Saturday) to get the keys before +20:00. Reservations last until 16:00, so either he gets the keys before 16:00, +or I'll just need to call for confirming the reservation + + +## Sleep Well Youth Hostel + +<http://www.sleepwell.be/> + +Fully booked. + + +## Youth Hostel Can Gogh + +<http://chab.be/> + +No under 18-ers and over 35-ers allowed. + +FULL + + +## Auberge de Jeunesse Jacques Brel + +<http://www.laj.be/html/fr/auberges/brel/aubergesbrel_01.htm>. + +Samuel knows that one and liked it. + +FULL + + +# What + +We don't have a Developers Room at FOSDEM. + +There is again a pre-FOSDEM meeting on Friday night in the Roi d'Espagne on +Grand Place, see <http://fosdem.org/2007/beerevent>. + + +# Photos + +Stefan: <http://brokenpipe.de/misc/images/index.cgi?d=fosdem-2007> diff --git a/community/meetings/fosdem_2008.mdwn b/community/meetings/fosdem_2008.mdwn new file mode 100644 index 00000000..47d7771a --- /dev/null +++ b/community/meetings/fosdem_2008.mdwn @@ -0,0 +1,181 @@ +[[meta copyright="Copyright © 2006, 2007, 2008 +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]]."]]"""]] + +<http://fosdem.org/2008> + +FOSDEM will take place on February 23rd/24th at the Université Libre de +Bruxelles. + + +# Who And When + +[[table class="table_style_1" data=""" +"Name","Attending","Arrival","Return","Share room with us" +"Alfredo Beaumont","?","?","?","?" +"Andrew Resch","?","?","?","?" +"Ben Asselstine","?","?","?","?" +"[[Barry_de_Freese|bddebian]]","?","?","?","?" +"[[Bas_Wijnen|baswijnen]] and girlfriend","yes","Friday","Monday","yes (two)" +"Christian Dietrich","no","n/a","n/a","n/a" +"Christopher Bodenstein","?","?","?","?" +"Colin Leitner","no","n/a","n/a","n/a" +"Cyril Brulebois","?","?","?","?" +"Daniel Wagner","?","?","?","?" +"Fredrik Hammar","?","?","?","?" +"Gaël Le Mignot","?","?","?","?" +"[[Gianluca_Guida|GianlucaGuida]]","yes","Thursday","Monday","yes" +"Guillaume Libersat","?","?","?","?" +"Guillem Jover","?","?","?","?" +"Jeff Bailey","?","?","?","?" +"Jeroen Dekkers","?","?","?","?" +"Johan Rydberg","?","?","?","?" +"Jordi Mallach","?","?","?","?" +"Marc Dequènes","?","?","?","?" +"Marc Poulhies","?","?","?","?" +"Marco Gerards","?","?","?","?" +"Marcus Brinkmann","yes","Friday, 17:00","Monday, 12:00","yes" +"Mark Kettenis","?","?","?","?" +"Matthieu Lemerre","?","?","?","?" +"Manuel Menal","?","?","?","?" +"[[Michael_Banck|MichaelBanck]]","yes","Friday, 17:00","Monday, 14:00","yes" +"Neal Walfield","yes","Friday, 15:20","Monday, 12:00","yes" +"Nicolas Centa","?","?","?","?" +"Ognyan Kulev","?","?","?","?" +"Olaf Buddenhagen","yes","Fr 15:27/15:32/15:36 (nord/central/midi)","Mo 12:09 (central)","yes" +"Peter de Schrijver","?","?","?","?" +"Richard Braun","no","n/a","n/a","n/a" +"Roland McGrath","?","?","?","?" +"[[Samuel_Thibault|SamuelThibault]]","yes","Thursday","Monday","yes" +"[[Soeren_Schulze|SoerenSchulze]]","yes","Friday 19:43/19:46 Midi/Central","Sunday 13:14 Central","yes" +"[[Stefan_Siegl|stesie]]","no","n/a","n/a","n/a" +"Thomas Bushnell","?","?","?","?" +"[[Thomas_Schwinge|tschwinge]]","yes","Friday, 17:00","Monday, 14:00","yes" +"Tim Retout","plans to go","?","?","no" +"[[Tom_Bachmann|tombachmann]]","?","?","?","?" +"[[Vikram_Vincent|vincentvikram]]","no","n/a","n/a","n/a" +"Wouter van Heyst","?","?","?","?" +"Yoshinori K. Okuji","?","?","?","?" +"""]] + +# Accommodation + +(Large) evening counts: + +[[table class="table_style_1" data=""" + , Bas, Gianluca, Marcus, Michael, Neal, Olaf, Samuel, Soeren, Thomas, Total +Thu 21, , 1? , *<strike>1</strike>*, , , , 1 , , *<strike>1</strike>*, *<strike>4</strike>* 2 +Fri 22, 2 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,10 +Sat 23, 2 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,10 +Sun 24, 2 , 1 , 1 , 1 , 1 , 1 , 1 , *<strike>1</strike>*, 1 , *<strike>10</strike>* 9 +"""]] + +## The Moon Hotel + +Samuel booked rooms at The Moon Hotel, Rue de la Montagne 4B + +- one triple room for the night of Thirsday 21 +- two double rooms and two triple rooms for the nights of Friday 22, Saturday 23 and Sunday 24. +(these were the last rooms of the hotel) + +i.e. 3+10*3 nights for a total cost of 1104€, which makes 33.5€/night. + +in each room there is a double bed, so some people will have to be "couples". + +Breakfast is included, there is hotspot wifi + +check-in can be between 13:00 and 00:00, departure is before 11:00 + + +## A-XL flathotel + +<http://www.axlflathotel.be/fr/tarifs.html> + + +## Youth hostel _Bruegel_ + +<http://www.vjh.be/jeugdherbergen/brussel/mainE.htm> + +Heilige Geeststraat 2 +1000 Brussels +Phone: +32(0)2 511 04 36 +Fax: +32(0)2 512 07 11 +<brussel@vjh.be> + +[Map via Google maps](http://maps.google.com/maps?f=q&hl=en&q=Heilige+Geeststraat+2,+1000+Brussels,+Belgium&sll=50.846056,4.344578&sspn=0.022599,0.086517&ie=UTF8&om=1&z=15&ll=50.843942,4.351444&spn=0.0113,0.043259&iwloc=cent). +[Map via Map24](http://link2.map24.com/?street0=Heilige%20Geeststraat&zip0=1000&city0=Br%FCssel&state0=&country0=be&name0=&lid=43c26f81&ol=de-de). + +Been there in 2006 and 2007. It was okay. + +Rooms at ~ 18.60€ + +gaah, Full! + +<!-- +[[SamuelThibault]] booked rooms at ~ 18.60€ there: + +[[table class="table_style_1" data=""" +"Night of...","Persons" +"2007-02-22","<strike>7</strike>**6**" +"2007-02-23","10" +"2007-02-24","11" +"2007-02-25","<strike>9</strike>**8**" +"""]] + +i.e including sdschulze, who hereby confirms +--> + +We need someone to get the keys before +20:00. Reservations last until 16:00, so either he gets the keys before 16:00, +or we just need to call for confirming the reservation + +[[I|tschwinge]] seem to remember something that in 2007 the Madame at the +reception wasn't really happy with us arriving later than 16:00 even with +having had confirmed that via a phone call. + + +## Sleep Well Youth Hostel + +<http://www.sleepwell.be/> + +Overbooked + +## Youth Hostel Can Gogh + +<http://chab.be/> + +No under 18-ers and over 35-ers allowed. + + +## Auberge de Jeunesse Jacques Brel + +<http://www.laj.be/html/fr/auberges/brel/aubergesbrel_01.htm>. + +Samuel knows that one and liked it. antrik too :-) + +Unfortunately it's already full + + +# What + +There will be a keysigning party, see <http://fosdem.org/2008/keysigning>. + +We don't have a Developers Room at FOSDEM. + +There is again a pre-FOSDEM meeting on Friday night, see <http://fosdem.org/2008/beerevent>. + +Both Neal and Bas would be happy to show their recent kernel works. + + +<!-- +# Photos + +Put links to your photos here. +--> diff --git a/community/meetings/rmll_2006.mdwn b/community/meetings/rmll_2006.mdwn new file mode 100644 index 00000000..74ad21c9 --- /dev/null +++ b/community/meetings/rmll_2006.mdwn @@ -0,0 +1,108 @@ +[[meta copyright="Copyright © 2006, 2007, 2008 +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]]."]]"""]] + +The 7th Rencontres Mondiales du Logiciel Libre (also known as Libre Software +Meeting) will be held on July 4th-8th 2006 in Vandoeuvre-les-Nancy. + +There won't be a track of OS-related talks as it has been last year, see +<http://lists.gnu.org/archive/html/bug-hurd/2006-06/msg00005.html>. + +Dorms have to be reserved on <http://resa.rmll.info/> as soon as possible. + +# Who And When + +<!-- TODO. Use the table plugin. See `fosdem_2007.mdwn'. --> +<table border="1" cellpadding="1" cellspacing="0"> + <tr> + <th bgcolor="#99CCCC"><strong>Name</strong></th> + <th bgcolor="#99CCCC"><strong>Attending</strong></th> + <th bgcolor="#99CCCC"><strong>Arrival</strong></th> + <th bgcolor="#99CCCC"><strong>Return</strong></th> + </tr> + <tr> + <td>[[JeroenDekkers]]</td> + <td> perhaps </td> + <td> ? </td> + <td> ? </td> + </tr> + <tr> + <td>[[ManuelMenal]]</td> + <td> perhaps </td> + <td> ? </td> + <td> ? </td> + </tr> + <tr> + <td>[[MarcoGerards]]</td> + <td> no </td> + <td> n/a </td> + <td> n/a </td> + </tr> + <tr> + <td>[[MarcusBrinkmann]]</td> + <td> probably not </td> + <td> n/a </td> + <td> n/a </td> + </tr> + <tr> + <td>[[MichaelBanck]]</td> + <td> probably not </td> + <td> n/a </td> + <td> n/a </td> + </tr> + <tr> + <td>[[NealWalfield]]</td> + <td> perhaps </td> + <td> ? </td> + <td> ? </td> + </tr> + <tr> + <td>[[PeterDeSchrijver]]</td> + <td> no </td> + <td> n/a </td> + <td> n/a </td> + </tr> + <tr> + <td>[[OlafBuddenhagen]]</td> + <td> ? </td> + <td> ? </td> + <td> ? </td> + </tr> + <tr> + <td>[[SamuelThibault]]</td> + <td> yes </td> + <td> ? </td> + <td> ? </td> + </tr> + <tr> + <td>[[SoerenSchulze]]</td> + <td> perhaps </td> + <td> ? </td> + <td> ? </td> + </tr> + <tr> + <td>[[Stefan_Siegl|stesie]]</td> + <td> no </td> + <td> n/a </td> + <td> n/a </td> + </tr> + <tr> + <td>[[Thomas_Schwinge|tschwinge]]</td> + <td> perhaps </td> + <td> ? </td> + <td> ? </td> + </tr> + <tr> + <td>[[YoshinoriOkuji]]</td> + <td> perhaps </td> + <td> ? </td> + <td> ? </td> + </tr> +</table> diff --git a/community/meetings/self-organised_2008.mdwn b/community/meetings/self-organised_2008.mdwn new file mode 100644 index 00000000..dc86afc2 --- /dev/null +++ b/community/meetings/self-organised_2008.mdwn @@ -0,0 +1,50 @@ +[[meta copyright="Copyright © 2008 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="Self-organised meeting, somewhere in 2008"]] + +This meeting will be held in a to-be-determined place, at a to-be-determined time. This page hopes to help finding a good time and place, and finding out who wants to come. + +# Who wants to come? + +Please add yourself here. + +* [[Bas_Wijnen|baswijnen]] (no preference for specific times) +* [[Thomas_Schwinge|tschwinge]] +* [[Tom_Bachmann|tombachmann]] (weekend in the middle of germany would be preferred) +* [[Gianluca_Guida|GianlucaGuida]] (wherever, whenever) + +# Who will come? + +* (to be filled in when the date is set) + +# When is a good time? + +Please add any suggestions here, and add to your name above if that time is good for you. + +# Where is a good place? + +## Somewhere in Germany + +This likely has the benefit of being relatively close to most people + +## Somewhere in Italy + +This likely has the benefit of better weather. ;-) + +## Venice (Italy) + +This certainly has the benefit of being in an awesome place. :-) Perhaps we shouldn't care too much about that, since we're mostly busy with ourselves anyway. Or perhaps we should: beauty helps creativity (wow, I should use this as my next catch-phrase to convince a girl to stay with me: I will fail again, but with style! Gianluca). + +# What will we do? + +There will be talks with discussions: + +* Bas will give a talk about Capability-microkernel-based operating systems, with an emphasis on how this can be useful for the Hurd. The talk hopes to get people enthousiastic for the concept, and it will be tried to keep it interesting for people who are not yet familiar with the concepts. diff --git a/community/meetings/stesie_2007-10-12.mdwn b/community/meetings/stesie_2007-10-12.mdwn new file mode 100644 index 00000000..8559c662 --- /dev/null +++ b/community/meetings/stesie_2007-10-12.mdwn @@ -0,0 +1,23 @@ +[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + +On the weekend 2007-10-12 to 14 [[Stefan_Siegl|stesie]] invited Hurd people. +Colin Leitner and [[Thomas_Schwinge|tschwinge]] came, as well as novice +Christian Dietrich. [[Michael_Banck|MichaelBanck]] also joined in for one +evening. + +Stefan and Christian mainly worked on [[hurd/translator/pfinet]] and +[DHCP](http://lists.gnu.org/archive/html/bug-hurd/2007-10/msg00036.html), +Michael on the [orbit2 +issue](http://lists.debian.org/debian-hurd/2007/09/msg00067.html) and Colin and +Thomas on PAE support for GNU Mach, amongst other things. + +Pictures can be found at +<http://brokenpipe.de/misc/images/index.cgi?d=hackend-200710>. diff --git a/community/orkut.mdwn b/community/orkut.mdwn new file mode 100644 index 00000000..2e7aae09 --- /dev/null +++ b/community/orkut.mdwn @@ -0,0 +1,3 @@ +As of March 6, 2004 the Gnu/Hurd community on <http://www.orkut.com/> has a membership of 89 people. An invitation from a current Orkut member is required to register with the Orkut site and join us. + +-- [[Main/GrantBow]] - 06 Mar 2004 diff --git a/community/procfs.mdwn b/community/procfs.mdwn new file mode 100644 index 00000000..1139c718 --- /dev/null +++ b/community/procfs.mdwn @@ -0,0 +1,395 @@ +[[meta copyright="Copyright © 2008 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="GNU/Linux compatible procfs"]] + +[[!toc ]] +---- + + Project Name +---- + +GNU/Linux compatible procfs pseudo-filesystem + +------ + + Project Description +---- +I wish to provide a sophisticated procfs pseudo-filesystem to “the Hurd”. An implementation of /proc pseudo-filesystem already exists in hurdextras repository. After skimming through the code it is clear that it needs a lot +of rework and tuning. Experiences from GNU/Linux have proven procfs to be a very useful facility in implementing +many of the process management tools. So the goal of this project is to rework on the existing procfs on “the Hurd” +so that its not only reliable and robust but also more importantly it is fully compatible with the GNU/Linux procfs. +The project thus aims at making the GNU/Linux process management tools like top, sysctl, kill, +skill, nice, snice, pgrep, free, tload, uptime, fuser, killall, pidof, pstree, etc., to run out of the box. + +------ + + Mentor +---- + +Olaf Buddenhagen + +------ + + Project Schedule +---- + +##### 1. Initial preparation and migration (Community Bonding Period: has already started – May 25th) + + This phase involves improving my translator programming skills by gaining + hands-on experience in it and becoming well versed in it. I will also go + through the Hurd code to understand its architecture in depth and will read + documentations related to obtaining process related information in Hurd. + This phase also involves the migration of existing procfs to use libnetfs. + +##### 2. Analysis and Design (May 26th – June 11th ) + + This phase involves the analysis of previous migration. Also involves + interacting with the mentor, the Hurd community and other people involved + in development of ps. tools to draw the exact design of the proposed procfs + including the algorithms required for coding. + +##### 3. Coding Stage I (June 12th – June 22nd ) + + Finishing up the migration to libnetfs based on the finalized design and + making necessary changes to the existing procfs. Coding up to + /proc/<pid>/exe in the features list. + +##### 4. Coding Stage II (June 23rd – July 13th) + + Involves coding of the features from /proc/<pid>/environ, up to + /proc/<pid>/maps. These contain most of the information required for ps. + tools and hence form the heart of the project. Will be completed by + mid-term evaluation deadline. + +##### 5. Coding Stage III (July 14th – July 26th ) + + Coding the rest of the features in the list including any necessary + features that may be added in the analysis phase. + +##### 6. Final Testing and evaluation (July 27th – August 8th ) + + Closely interacting with the community and requesting them to help me + in overall testing and reviewing and making changes as per their + suggestions. Also involves testing with the ps. tools and consolidating + the documentation. + +##### 7. Packaging and Wrap-up (August 9th - August 18th ) + + Final phase of testing and fixing remaining bugs. Working with the + community to merge the project with the CVS HEAD of Hurd. Documentation + reviews, making necessary changes as per the suggestions and wrapping + up the documentation. + +------ + + Deliverables +---- + +1. /proc filesystem that uses libnetfs. Using this library makes it easier for implementing a large set of functionalities and hence makes the implementation robust. +2. The core GNU/Linux compatible /proc filesystem with functionalities to support and provide information for ps. tools like procps, psmisc etc. + +Non-code deliverables include an exhaustive Documentation. This documents the code of the Hurd's procfs which explains in detail the implementation of each of the functionalities of procfs implemented +during the course of this project. + +------ + + Code Repository +---- + +[http://github.com/madhusudancs/procfs/tree/master](http://github.com/madhusudancs/procfs/tree/master) + +Clone URL: [git://github.com/madhusudancs/procfs.git](git://github.com/madhusudancs/procfs.git) + +------ + + Progress +---- + +1. Packages Ported: [http://www.madhusudancs.info/parted-hurdi386 parted-1.7.1] +2. Packages Porting in progress: autogen_1:5.9.4-1. Error installing texlive-bin. Error tracked to some post installation scripts of texlive-bin. Problem seems to be in fmutil. Trying to debug. +3. Have to start coding libnetfs skeleton for procfs translator. + +**Target for next week** + + Task To be completed by Status Now + + 1. Finish Defining the necessary netfs call backs 25-05-2008 Completed + 2. Create Directories for each process with pid directory name 27-05-2008 Completed + 3. Create stat file for each process within this directory and<br/> + put atleast 1 information into it 31-05-2008 In Progress + +**Documentations Read/Reading** + +1. [Hurd Hacking Guide](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) (Have Concentrated mainly on Translator part) +2. [Linux Kernel Implementation of procfs](http://users.sosdg.org/~qiyong/lxr/source/Documentation/filesystems/proc.txt) + +**Code Being Read** + +1. libps +2. libnetfs +3. [procfs implementation in Linux kernel](http://users.sosdg.org/~qiyong/lxr/source/fs/proc/) +4. ftpfs (In Hurd main) +5. cvsfs (In Hurd extras) +6. xmlfs (In Hurd extras) +7. httpfs (In Hurd extras) +8. gopherfs (In Hurd extras) +9. libfuse (In Hurd extras) +10. procfs (libtrivfs based, In Hurd extras) + +------ + + Post Mid-Term Road Map +---- + + +####Already Implemented + +#####File - /proc/<PID>/stat + +* pid + +* comm + +* state + +* ppid + +* pgrp + +* session + +* tty_nr + +* tpgid + +* minflt +> The number of minor faults the process has made which have not required loading a memory page +> from disk. + +* majflt +> The number of major faults the process has made which have required loading a memory page from +> disk. + +* utime +> The number of jiffies that this process has been scheduled in user mode. + +* stime +> The number of jiffies that this process has been scheduled in kernel mode. + +* priority +> The standard nice value, plus fifteen. The value is never negative in the kernel. + +* num_threads +> Number of threads in this process. + +* starttime +> The time in jiffies the process started after system boot. + +* vsize +> Virtual memory size in bytes. + +* rss +> Resident Set Size: number of pages the process has in real memory, minus 3 for administrative +> purposes. This is just the pages which count towards text, data, or stack space. This does not +> include pages which have not been demand-loaded in, or which are swapped out. + +* itrealvalue +> The time in jiffies before the next SIGALRM is sent to the process due to an interval timer. + +* nswap +> Number of pages swapped (not maintained). + +* cnswap +> Cumulative nswap for child processes (not maintained). + +* flags +> PF_* fields defined in (Not Linux compatible, but nearly says the something Linux says) + +* nice +> The nice value ranges from 19 to -19. + +* cutime +> The number of jiffies that this process’s waited-for children have been scheduled in user +> mode. + +* cstime +> The number of jiffies that this process’s waited-for children have been scheduled in kernel mode. + +#####File - /proc/<PID>/statm + +* size +> total program size + +* resident +> resident set size + +* lib +> library + +* dt +> dirty pages + +####I already know the where the information is exactly available. + +#####Other Per-PID Files + +#####* /proc/<PID>/exe + +#####* /proc/<PID>/environ + +#####Non Per-PID Files + +#####* /proc/version + + +####I know where the information is available roughly, but need to look in detail to extract the exact information. + +* cminflt +> The number of minor faults that the process’s waited-for children have made. + +* cmajflt +> The number of major faults that the process’s waited-for children have made. + +* signal +> The bitmap of pending signals. + +* blocked +> The bitmap of blocked signals. + +* sigignore +> The bitmap of ignored signals. + +* sigcatch +> The bitmap of caught signals. + +* policy +> Scheduling policy. + +#####File - /proc/<PID>/statm + +* text +> text (code) + +#####Other Per-PID Files + +#####* /proc/<PID>/cwd + +####The information may be available, but needs to be searched to know where it will be. + +#####File - /proc/<PID>/stat + +* rlim +> Current limit in bytes on the rss of the process (usually 4294967295 on i386). + +* startcode +> The address above which program text can run. + +* endcode +> The address below which program text can run. + +* startstack +> The address of the start of the stack. + +* kstkesp +> The current value of esp (stack pointer), as found in the kernel stack page for the process. + +* kstkeip +> The current EIP (instruction pointer). + +* exit_signal +> Signal to be sent to parent when we die. + +#####File - /proc/<PID>/statm + +* share +> shared pages + +* data +> data/stack + +#####Other Per-PID File + +#####* /proc/<PID>/root + +#####Non Per-PID Files + +#####* /proc/stat + +#####* /proc/meminfo + +####I fear information may not be available. + +#####File - /proc/<PID>/stat + +* wchan +> This is the "channel" in which the process is waiting. It is the address of a system call, and +> can be looked up in a namelist if you need a textual name. (If you have an up-to-date +> /etc/psdatabase, + +* processor +> CPU number last executed on. + +* rt_priority +> Real-time scheduling priority + +* delayacct_blkio_ticks +> Aggregated block I/O delays, measured in clock ticks (centiseconds). + + +###Newly added to Roadmap(but these were the original goals of the project) + +#### procps tools need to be ported so that they run on top of the procfs + +> ##### pgrep - Done +> ##### pkill - Done +> ##### killall - Done +> ##### pstree - Done +> ##### top - Mostly Done (except per-PID shared memory field, and non per-PID caches and buffers field) +> ##### free - Mostly Done (Ditto from above) +> ##### htop - Mostly Done (Ditto again) +> ##### watch - Done +> ##### tload - I think it is done. (Need someone to test it) +> ##### libgtop - In progress +> ##### gnome-system-moitor - In progress + + + +------ + + Code Updates +---- + +1. May, 14, 2008 +2. May, 18, 2008 +3. May, 28, 2008 +4. June, 1, 2008 +5. June, 2, 2008 +6. June, 4, 2008 +7. June, 5, 2008 (3 commits, 00:30 HRS, 02:30 HRS, 11:15HRS, all in IST) +8. June, 9, 2008 +9. June, 19, 2008 (Targets 1 and 2 successfully accomplished. Duration between the commits became inevitably longer because of the large amount of time spent on debugging the code.) + +------ + + Contact Details +---- + +Name : Madhusudan.C.S + +Email : [madhusudancs@gmail.com](mailto:madhusudancs@gmail.com) + +Blog : [http://www.madhusudancs.info](http://www.madhusudancs.info/) + +Detailed proposal: [http://www.madhusudancs.info/gnu-hurd-procfs-proposal](http://www.madhusudancs.info/gnu-hurd-procfs-proposal) + +Google Summer of Code Site Link: [Abstract](http://code.google.com/soc/2008/hurd/appinfo.html?csaid=D2E9266819D2EEF9) + + diff --git a/community/scolobb.mdwn b/community/scolobb.mdwn new file mode 100644 index 00000000..2de8eb4f --- /dev/null +++ b/community/scolobb.mdwn @@ -0,0 +1,134 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +# scolobb + +Sergiu Ivanov, interested non-student + +Mail: <mailto:unlimitedscolobb@gmail.com> + +Project: Namespace-based translator selection + +--- + +## Current Task + +Write the filesystem proxy for namespace-based translator selection (*nsmux*). + +The code is at <http://github.com/scolobb/nsmux/tree/master>. + +--- + +###Did this week + +* Modified the node cache so that it maintains shadow nodes alive. + +###Plans for the next week + +* Implement the shutting down of translator stacks when *nsmux* is asked to go away (in case **antrik** considers that necessary). + +* Make *nsmux* provide the access to the translator stack of the real node, in case a translator (mainly, a filter) should ask for its underlying node to be opened in O_NOTRANS mode. + +--- + +###Current Status + +####DONE: + +* The skeleton which mirrors the filesystem. + +* Provide proxy nodes (modify the standard version of netfs_S_dir_lookup). + +####TODO: + +* Create the generic filtering translator. + +* Create the translator '0' (providing the untranslated version of the + node). + +* Create the "recursive wrappers" for one-node translators. + +* Create special translators for the main proxy so that its functionality + should be complete. + +* Implement sharing of dynamic translator stacks where possible. + +* Make dynamic translators go away as soon as they are not required. + +* Refine the skeleton in several places so that it should become faster + and more reliable. + +* Kill bugs. + +* Integrate nsmux upstream. + +* Solve the libtrivfs stacking issue. + +* Patch libnetfs (it does not support file_get_translator_cntl, for + instance). + +--- + +###Progress + +####8: Fri Sep 19: + +> Modified the ncache so that it now maintains shadow nodes (and directory nodes too, it is a side effect at the moment) alive. + +####7: Sat Aug 30 - Fri Sep 5: + +> Added the code for shutting down dynamic translator stacks. + +####6: Mon Aug 4 - Fri Aug 29: + +> Implemented the proxy nodes. + +####5: Thu Jul 24 - Thu Jul 24: + +> Created a *libnetfs*-based one-node translator, working exactly like the *libtrivfs*-based translator I had written before; the former, however, can be included in a translator stack. + +####4: Tue Jul 22 - Thu Jul 24: + +> Attempted to make a *libtrivfs*-based translator to be able to be stacked upon itself (to be able to receive a translator on top of itself, more exactly); attempted to borrow some code from *libnetfs* but this didn't bring any results. + +####3: Sun Jul 20 - Tue Jul 22: + +> Implemented the possibility to propagate a translator on all files belonging to a directory 'dir' in the request of the type 'dir,,x/'. + +####2: Thu Jul 17 - Fri Jul 18: + +> Extended the lookup code in *nsmux* to allow for looking up nodes like 'file,,x' and added the possibility to escape the double-comma in the following way: ',,,'. + +####1: Mon Jul 12 - Tue Jul 13: + +> Implemented a simple *libtrivfs*-based translator to test the lookup code for *nsmux*. + +####0: Sat Jul 12 - Sat Jul 12: + +> Made small changes to the code of *filterfs* to fit the needs of *nsmux*. + +--- + +## Completed Tasks + +####2: Sat May 3 - Fri Jul 17: + +> Write a translator that should filter the contents of the directory it is set on according to some property. The property can be an arbitrary command. + +> The code is at <http://github.com/scolobb/filterfs/tree/master>. + +####1: Mon Apr 28 - Wed Apr 30: + +> Wrote a Python extension module in C for retreiving the uptime. The module is based on the code of *w*. + +####0: Sun Apr 27: + +> Followed the code of *dmesgd* (<http://www.bddebian.com/junk/dmesgd/>) kindly offered by **bddebian** and rewrote it from scratch as a tutorial. + diff --git a/community/self-organised_2008.mdwn b/community/self-organised_2008.mdwn new file mode 100644 index 00000000..01b25578 --- /dev/null +++ b/community/self-organised_2008.mdwn @@ -0,0 +1,11 @@ +[[meta copyright="Copyright © 2008 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 redir=meetings/self-organised_2008]] diff --git a/community/thug.mdwn b/community/thug.mdwn new file mode 100644 index 00000000..721c5aaf --- /dev/null +++ b/community/thug.mdwn @@ -0,0 +1,25 @@ +# <a name="Toronto_GNU_Hurd_User_Group"> </a> Toronto (GNU/)Hurd User Group + +We are the first of the [[WebHome]] [[UserGroups]], and consequently the biggest! Our name is a slight misnomer, since we have plenty of members who live outside of Toronto, Ontario, Canada. We have a members in the Kitchener/Waterloo area who are about two hours from Toronto (by automobile,) and a member in Oakland, California, USA who is about two hours from Toronto (by aeroplane.) + +We are also expanding our reach. Currently our core members range in location from Montreal, PQ. to Waterloo, On. + +## <a name="Membership"> Membership </a> + +Anyone can join! Just find us, and help contribute. + +## <a name="Services"> Services </a> + +Currently, we maintain a [Savannah](http://savannah.gnu.org) project site at <http://savannah.nongnu.org/projects/thug>. + +As well, our web page links to lots of useful [documentation](http://www.nongnu.org/thug/docs.html). + +## <a name="Contact_us"> Contact us </a> + +Our website can be found at: <http://www.nongnu.org/thug/>. + +You can typically find us in the #thug channel on the Official GNU IRC network (irc.gnu.org). + +As well, we have a mailing list at [thug at gnu dot org](http://mail.gnu.org/mailman/listinfo/thug). + +-- [[Main/SimonLaw]] - 25 May 2002 diff --git a/community/weblogs.mdwn b/community/weblogs.mdwn new file mode 100644 index 00000000..016c483f --- /dev/null +++ b/community/weblogs.mdwn @@ -0,0 +1,17 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +Weblogs from Hurd programmers and enthusiasts. + +[[inline +pages="community/weblogs/*/* and !*/discussion" +show=0 +actions=no +rootpage="community/weblogs" postformtext="Add a new user named:"]] diff --git a/community/weblogs/ArneBab.mdwn b/community/weblogs/ArneBab.mdwn new file mode 100644 index 00000000..8c7b377a --- /dev/null +++ b/community/weblogs/ArneBab.mdwn @@ -0,0 +1,45 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +I'm just a Hurd dabbler who likes the ideas behind the Hurd: + +*"With the Hurd, users can change anything in their system which doesn't affect other +users."* + +And this is one definition of freedom in a community: *"Do what you want as long as +you don't restrict others from doing what they want."* + +In contrast, current systems (like Linux, MacOSX, Windows or others) require root/admin access to just install a new file system for reading out a nonstandard USB-stick (OK, who'd put reiserfs, zfs or similar on a USB stick? but still...). + +Why do I have to be root or even to recompile my kernel in Linux to get a new filesystem to run? Why can't I just start a program which takes care of the filesystem for me, and only for me? + +Well, with the Hurd I can do that, and it will be a transparent layer over my normal filesystem. + +And the same is true for networking stuff and anything else. Hacking on the deep internals of the system is possible with the Hurd without all the pain of having to compile the kernel to check it - and even without the need of superuser access for doing to. + +And sharing and exchanging programs deep inside the core is possible, too, since any Hurd user can just test them without fearing to compromise his/her machine. + + +Myself, I don't hack the kernel or anything (this shouldn't be a 'yet', I think, but I try not to be too sure about these kinds of things - life is weird :) ), but I'd sure like to be able to just get a new filesystem when I need it (and I don't dig rebooting my computer). + +And I like my freedom - in my life as well as in technology. + + +See you in the Hurd! + +- Arne Babenhauserheide ( http://draketo.de ) + +----- My Blog ----- + +[[inline +pages="community/weblogs/ArneBab/* and !*/discussion" +show=0 +actions=no +rootpage="community/weblogs/ArneBab" postformtext="Add a new entry named:"]] diff --git a/community/weblogs/ArneBab/2008-06-17-latest-changes-in-the-hurd.mdwn b/community/weblogs/ArneBab/2008-06-17-latest-changes-in-the-hurd.mdwn new file mode 100644 index 00000000..111bb640 --- /dev/null +++ b/community/weblogs/ArneBab/2008-06-17-latest-changes-in-the-hurd.mdwn @@ -0,0 +1,18 @@ +In the past few months the Hurd got quite many commits. + +I want to write a bit about the changes they brought, and what they mean to the Hurd. + +If some of my comments seem too 'simple' to you, just ignore them :) + +First we got many Bug fixes from Samuel Thibault, mainly in libpthread (multithreading), ext2fs and libdiskfs (both filesystem interaction). + +Then hurd-l4 (the port of the Hurd on the L4 kernel) seems to get quite much love by Neal H. Walfield (neal) at the moment. +Quite much is saying a bit to little: hurd-l4 looks steamingly active in the commits :) + +And there is the [PyHurd](http://pypi.python.org/pypi/PyHurd) project. It attempts to create a full binding to the GNU/Hurd API, so people should someday be able to, for example, create translators in Python. + +There's been more - a lot more in fact, but much of it is above my coding horizon, and this entry shall end someplace (it's late - too late :) ). + +Best wishes, +Arne + diff --git a/community/weblogs/ArneBab/2008-07-12-codeswarm-movies-for-the-hurd.mdwn b/community/weblogs/ArneBab/2008-07-12-codeswarm-movies-for-the-hurd.mdwn new file mode 100644 index 00000000..54bd0eff --- /dev/null +++ b/community/weblogs/ArneBab/2008-07-12-codeswarm-movies-for-the-hurd.mdwn @@ -0,0 +1,29 @@ +Today (OK, this night) I created some codeswarm movies to visualize the code history of the Hurd. + +What's particularly interesting to me in gnumach is the tschwinge - sthibaul effect in march 2008, where development suddenly seems to speed up enormeously. + +It clearly shows how much impact just two developers can have - you can have that kind of an impact, too! + +The code movies are created from the history of the cvs branches gnumach, hurd-l4 and +hurd. + +The movies: + + - [Gnumach](http://draketo.de/filme/codeswarm/gnumach_code_evolution.avi) + + - [Hurd](http://draketo.de/filme/codeswarm/gnu_hurd_code_evolution_1_min.avi) + + - [Hurd L4](http://draketo.de/filme/codeswarm/hurd-l4.avi) + + - [Hurd wiki](http://draketo.de/filme/codeswarm/hurd_wiki.avi) + +in gnumach, red is the "kern", while in "hurd" red is stuff in "release". + +.*doc.* is dark blue and any stuff named .*linux.* is shown in a blue-green in +both. In Hurd-L4 is annotated: It shows libc, gcc, Hurd and L4 kernel commits in +different colors. + +The hurd wiki movie shows all web commits as "web-hurd@gnu.org", and you can clearly see that most changes are being done via the version control system. There's a way to split the web-commits, but since there aren't many, I leave that for another day :) - [article on the ikiwiki page](http://ikiwiki.info/news/code_swarm/). + +Best wishes, +Arne diff --git a/community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn b/community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn new file mode 100644 index 00000000..d72f4cef --- /dev/null +++ b/community/weblogs/ArneBab/2008-08-02-gnu_hurd_and_x.mdwn @@ -0,0 +1,38 @@ +Getting X to work on the GNU/Hurd +================================= + +This is a try to get X to work in my qemu GNU/Hurd. + +*This is a first try, my next one will be with the [[guide_from_this_wiki|Hurd/DebianXorg]].* + +Firstoff: I used the following guides: + +* [X Under the Hurd from debian-hurd](http://www.kerneltraffic.org/debian-hurd/dh20000112_31.html#3) +* [GNU/Hurd FAQ](http://www.gnu.org/software/hurd/faq.en.html#q4-7) + + +What I did +---------- + +I worked as root. + +First I installed xorg, x-window-system-code, rxvt and twm: + + apt-get install xserver-xorg x-window-system-core rxvt twm + +Then I set the LD_LIBRARY_PATH and DISPLAY + + export LD_LIBRARY_PATH=/usr/X11R6/lib + export DISPLAY=localhost:0.0 + +After that I set the mouse and keyboard translator. + + settrans /dev/kbd /hurd/kbd /dev/kbd + settrans -c /dev/mouse /hurd/mouse --protocol=ps/2 + +Then I started x + + startx + +It didn't work yet - but watch the blog for updates - I'll post once I get it +working. diff --git a/community/weblogs/ArneBab/hurd-gsoc2008-code_swarm.mdwn b/community/weblogs/ArneBab/hurd-gsoc2008-code_swarm.mdwn new file mode 100644 index 00000000..01757867 --- /dev/null +++ b/community/weblogs/ArneBab/hurd-gsoc2008-code_swarm.mdwn @@ -0,0 +1,11 @@ +Hurd GSoC 2008 code_swarm +========================= + +I created a code_swarm of the work done in the Hurd project during this years Google +Summer of Code. + +* [Hurd GSoC 2008 code_swarm](http://draketo.de/filme/codeswarm/hurd-gsoc2008.ogv) + +I hope you enjoy it! + +PS: Now also available [on vimeo](http://www.vimeo.com/2097773) thanks to scolobb! diff --git a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn new file mode 100644 index 00000000..ecfcc4c8 --- /dev/null +++ b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn @@ -0,0 +1,310 @@ +Niches for the Hurd +=================== + +In the bug-hud mailinglist we did a search for niches where the Hurd is *the biggest +fish in the pond*. + +This search was segmented into four distinct phases, three of them major: + +- Brainstorm +- Reality check: can already do vs. could be used for +- Turn ideas into applications +- Find a compromise -> About which niches should we talk in the wiki? + + +Brainstorm +---------- + +"Which niches could there be for the Hurd?" + +### Basic Results + +The result is a mix of target groups, +nice features and options of the Hurd, reasons for running a Hurd and areas where +the Hurd offers advantages: + +#### Nice features and options the Hurd offers + +- Give back power to users: arbitrary mounts, subhurds +- Nice features: dpkg -iO ftp://foo/bar/*.deb +- Easier access to low-level functions +- Advanced lightweight virtualization +- operating system study purposes as its done with minix +- The possibility to create more efficient and powerful desktop environments +- Having a _complete_ GNU System +- All-in-one out-of-the-box distro running a webserver for crash-proof operation. + + +#### Target groups and strong environments + +- Tinkerers who like its design. +- multicore-systems + + +### The keyphrases in more detail or with additional ideas + +#### Give back power to users: arbitrary mounts, subhurds + +Simpler virtual computing environments - no need to setup XEN, everyone can +just open up his/her computer for someone else by creating a new user account, +and the other one can login and easily adapt the system for his/her own needs. +If most systems just differ by the translators setup on them, people could +even transfer their whole environment from one computer to another one without +needing root access or more root interaction than creating a new user account. +"I want my tools" -> "no problem, just setup your translators". + +Also it would be possible to just open an account for stuff like joining the +"World Community Grid" allowing for easier sharing of CPU time. + + +#### Easier access to low-level functions + +*"One important use is for very technical people, who don't always go with +standard solutions, but rather use new approaches to best solve their +problems, and will often find traditional kernels too limiting."* + +*"Another interesting aspect is application development: With the easily +customized/extended system functionality, and the ability to contain +such customizations in subenvironments, I believe that Hurd offers a +good platform for much more efficient development of complex +applications. Application developers can just introduce the desired +mechanisms on a very low level, instead of building around existing +abstractions. The extensible filesystem in particular seems extremely +helpful as a powerful, intuitive and transparent communication +mechanism, which allows creating truly modular applications."* + + +#### Advanced lightweight virtualization + +*"There is also the whole area I called "advanced lightweight +virtualization" (see +http://tri-ceps.blogspot.com/2007/10/advanced-lightweight-virtualization.html +), i.e. the ability to create various kinds of interesting +subenvironments. Many use cases are covered by much bigger fish; but the +flexibility we offer here could still be interesting: I think the middle +grounds we cover between directly running applications, and full +isolation through containers or VMs, are quite unique. This could +simplify management of demanding applications for example, by partially +isolating them from other applications and the main system, and thus +reducing incompatibilities. Creating lightweight software appliances +sounds like an interesting option.*" + +#### The possibility to create more efficient and powerful desktop environments + +*"While I believe this can be applied to any kind of applications, I'm +personally most interested in more efficient and powerful desktop +environments -- these considerations are in fact what got me seriously +interested in the Hurd. + +Even more specifically, I've done most considerations (though by far not +all) on modular web browsing environments. Those interested can read up +some of my thoughts on this: + + +http://sourceforge.net/mailarchive/message.php?msg_name=20080909073154.GB821%40alien.local + +(Just skip the text mode browsing stuff -- the relevant part is the long +monologue at the end... I really should put these ideas into my blog.)"* + + + +#### Nice features + +Another example of features which would be easily possible with the Hurd: + +* media-player translator: + - settrans play /hurd/mediaplayer_play + - cp song1.ogg song2.ogg play + - # -> files get buffered and played. + +or even: + +* cp ftp://foo/bar/ogg play + +that's KDEs fabled network transparency on the filesystem / shell level. + + +Reality check +------------- + +Check which of the ideas can already be done easily with the Hurd in its current +state, which ones are a bit more complex but already possible, which ones need a bit +of coding (could be accomplished in a few months judging from the current speed of +development), which ones need a lot of work (or fundamental changes) and which ones +aren't possible. + +### Already possible and easy + +- Sample translators: + * hello world. + * transparently bind FTP into the filesystem + * hostmux + ftpfs -> connect to FTP automatically via asking for a dir named after the hostname -> fully transparent FTP filesystem: "touch ftp: ; settrans ftp: /hurd/hostmux /hurd/ftpfs / " + * bind any filesystem at any place in the filesystem (you have access to) without needing to be root. + * 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' + +- Having a complete GNU System (but not yet on every hardware, and only about half the software Debian offers has been ported). + +### Already possible but complex or underdocumented + +- Easier access to low-level functions via translators. + +- Operating system study purposes as it's done with minix. + +- Tinkering for fun - need documentation about the fun things which can be done. + +### Need a few months of coding + +- A filesystem-based package manager. + +- A framework for confining individual applications is really just one +possible use case of the hurdish subenvironments. Writing the tools +necessary for that should be quite doable in a few months. It's probably +not really much coding -- most of the work would be figuring out how it +should be set up exactly. + +- 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 +you (translators written in scripting laguages can make this easier - they could +also for example be taken to each computer on USB stick). + +- A more powerful alternative to FUSE filesystems: While FUSE is limited to standard +filesystem semantics, while Hurd translators can implement whatever they +want. +It is possible to change the behaviour in any aspect, including the way +file name lookup works. Admittedly the only specific use case I know is +the possibility to implement namespace-based translator selection with a +set of normal translators, without any changes to the Hurd itself. +It is also possible to extend the filesystem interfaces, adding new RPCs +and options as needed. This allows using the filesystem for +communication, yet implementing domain-specific interfaces where +standard filesystems are too unefficient or cumbersome. A sound server +would be one possible use case. + +- Namespace based translator selection (if you for example want to quickly check the +contents of an iso image, just look at them via 'ls image.iso,,iso9660fs'). + +### Need a lot of coding or fundamental changes + +- Effective resource management (For example via Viengoos on which Neal Walfield is +working). The idea is that we could make a virtue out of necessity: Once we have a +proper resource management framework, we should be able not only to catch up with +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 +using the existing OS. +With the Hurd people could just create a user for them, give that user specific +permissions (like "you're always lowest priority"), add the public ssh keys of +the project they want to donate CPU cycles to, and the project could just turn +the computer into the environment it needs for the specific computation, +without compromising the main system in any way (needs better resource management). + +- A shared MMORPG game world consisting simply of files for levels and person +descriptions with access rights. All synchronizing is done on the translator +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. + + + +### Unfeasible ideas + + + +Applications +------------ + +A minor phase, which will surely be interleaved with the others: Making the ideas +tangible to turn them into ways how people can use the Hurd. + +"Hey, look, this is the Hurd. You can use it like this to do that which you can't do +as well/easily/elegantly in any other way." + + +### Applications for private use + +### Applications for companies + +### How an application should be presented so people can easily test and digest it + +We need stuff which gets people to say "hey that's cool!" + +And it must be readily available. +If I have to search for arcane command line parameters before I can use it, +it's too hard. + +From what I see, each direct cool application must be about as simple as + +$ qemu hurd-is-cool.img +$ login root +$ settrans cool /hurd/cool +$ ls cool + +One main focus in this example is: No command line parameters but the ones we +really need. No "-a", if the example is also cool without it. +No "--console" if it works otherwise. + +Especially no "qemu --cd livecd --hda hurd.img ..." - that one is great for +specialists, but the goal here isn't to teach people better usage of qemu, +but to show them that the Hurd is cool, and only that. + +All that interesting advanced stuff just gets newcomers confused. + +The translator concept in itself is enough news to faze a mind - anything else +can easily be too much. + +If the application isn't as simple as the example above, then the best step +would be to see if we can make it as simple - if that involves writing trivial +scripts than be it so. They are trivial only to those who already understand +the underlying concepts. + +And now enough with rambling :) + +The Hurd is cool, and the complex to use applications are cool, too. +But they are hard to present in a way newcomers easily understand. + + +Compromise +---------- + +For each niche: + +- What do we have to do to conquer the niche? +- How many additional programmers can the Hurd get in this niche? +- How does choosing this niche limit the flexibility of further development (for example due to the goals of the people who join up)? +- Can we easily move on to conquering the next niche once we got this one? +- What should the Hurd accomplish on the long term (long term goals)? Which possible niches help that? + +Each participant: + +- Give your personal priorities to the niches: + * Must -> all of these of all developers must be included; + remember that at most 3 to 4 ideas can be conveyed in any text. + * Should -> The number of shoulds can be used for ranking and similar. + +("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)) + + +Things to do +------------ + +todo-item -> niches for which it is useful. + +### Easy + +- Port debian packages to the Hurd -> mainly tinkerers, but also any other niche. + diff --git a/community/weblogs/ArneBab/xkb-woes-trying-to-get-a-german-keyboard-layout.mdwn b/community/weblogs/ArneBab/xkb-woes-trying-to-get-a-german-keyboard-layout.mdwn new file mode 100644 index 00000000..fef628bc --- /dev/null +++ b/community/weblogs/ArneBab/xkb-woes-trying-to-get-a-german-keyboard-layout.mdwn @@ -0,0 +1,47 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +Yesterday I spent a few hours trying to get my german keyboard to let me use my umlauts (and to let me type without having to hunt down the right keys), but without much luck. + +I got xkb installed after following this FaQ answer: + +- <http://www.gnu.org/s/hurd/faq.en.html#q4-4> + +and this info: + +- <http://people.debian.org/~mbanck/hurd-console.default> + +(you can find the second under /etc/default/hurd-console ). + +But I didn't get it to work. + +### What I did in short: + + +First I got the needed apt-sources: + +- <http://debian.duckcorp.org/> + +Then I installed the xkb console: + +- `apt-get install console-driver-xkb` + + +And set it in the file /etc/default/hurd-console + + +Sadly it didn't work, but maybe this posts will give You the needed headstart for success :) (I'd be glad to see a guide from you!). + + +Some additional info: + +- <http://kerneltrap.org/node/420> +- <http://www.bddebian.com/~wiki/hurd/console/> + |