Re: Code Bounty
On Wed, Sep 10, 2008 at 08:10:56PM +1200, Gregory Plummer wrote: Hi all, I would like to offer a small cash incentive for tasks needing to be completed. It would be great if the Hurd could support file systems greater than 2 GB in size. How would I go about sponsoring this feature? Some input on the best way to do this would be appreciated. Working code is there (it's included in the Debian hurd package), somebody just needs to either (i) convince the Hurd maintainers that code is good enough to get in or (ii) rewrite it so that it can get in. Michael
Re: Code Bounty
Am Mittwoch 10 September 2008 15:20:07 schrieb Michael Banck: On Wed, Sep 10, 2008 at 08:10:56PM +1200, Gregory Plummer wrote: Hi all, I would like to offer a small cash incentive for tasks needing to be completed. It would be great if the Hurd could support file systems greater than 2 GB in size. How would I go about sponsoring this feature? Some input on the best way to do this would be appreciated. Working code is there (it's included in the Debian hurd package), somebody just needs to either (i) convince the Hurd maintainers that code is good enough to get in or (ii) rewrite it so that it can get in. Does the Hurd have a bounty-system? If not, would it be possible to add one? Can the GNU project accept and manage the legal part of the bounties for the Hurd, or does the Hurd need its own legal entity for that? Best wishes, Arne -- -- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :) -- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the history of free software. -- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln. -- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt signature.asc Description: This is a digitally signed message part.
Re: Code Bounty
Arne Babenhauserheide, le Wed 10 Sep 2008 15:36:54 +0200, a écrit : Can the GNU project accept and manage the legal part of the bounties for the Hurd, or does the Hurd need its own legal entity for that? I guess these are not specific to the Hurd, and could be discussed directly with GNU people. samuel
Re: Code Bounty
Am Mittwoch 10 September 2008 15:59:16 schrieb Samuel Thibault: Arne Babenhauserheide, le Wed 10 Sep 2008 15:36:54 +0200, a écrit : Can the GNU project accept and manage the legal part of the bounties for the Hurd, or does the Hurd need its own legal entity for that? I guess these are not specific to the Hurd, and could be discussed directly with GNU people. Does the GNU project have a way to accepts bounties bound to one specific purpose? Can someone specify: My '200$ bounty for making the improved ext2 code conform with Hurd requirements' must only be given to the one who implements it? That way, GNU would only manage the money for the Hurd, until it gets given out. Best wishes, Arne -- -- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :) -- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the history of free software. -- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln. -- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt signature.asc Description: This is a digitally signed message part.
[task #5487] cthreads - pthreads
Follow-up Comment #3, task #5487 (project hurd): OK I'm attaching my latest patch. I've taken zentons work and taken it all the way. Everything compiles but there are issues. Static linking has issues. If I let the build system do it's thing, ext2fs and ext2fs --help return values however its linked to the binary libpthread. If I link against the ascii pthread in hurd/libpthread it either gives some goofy errors or hangs. For some reason I cannot get gdb to give me debugging symbols or it hangs even inside of gdb and I can't attach to the pid because ps also hangs. I have added pt-cond-implies but it is not completed and neal thinks the code should be inlined anyway. Obviously it needs testing, testing, testing. ___ Reply to this item at: http://savannah.gnu.org/task/?5487 ___ Message sent via/by Savannah http://savannah.gnu.org/
[task #5487] cthreads - pthreads
Additional Item Attachment, task #5487 (project hurd): File name: hurd_pthread_09102008.diff.gz Size:131 KB ___ Reply to this item at: http://savannah.gnu.org/task/?5487 ___ Message sent via/by Savannah http://savannah.gnu.org/
GSoC results!
Hi, On Sun, Aug 31, 2008 at 06:54:15PM +0200, Arne Babenhauserheide wrote: Could you post an update with this years results to the GSoC project sites in the wiki? Well, I haven't touched the actual project pages (I guess the students should update them, just like they did during the official GSoC); but I now updated the main GSoC page ( http://www.bddebian.com/~wiki/community/gsoc/ ) and the project ideas page ( http://www.bddebian.com/~wiki/community/gsoc/project_ideas/ ). Would have done so before, but unfortunately I was quite swamped for the past 2 1/2 weeks... Here is the interesting part from the updated wiki page: All in all we had five students working on a diverse selection of five projects from our ideas list. All of the projects were more or less successful: - Sergiu Ivanov 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, he was able to complete nsmux (the main namespace proxy handling the magic filename lookups, running dynamic translators on demand); however, 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 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 accesing network devices through device files; support for settingthe 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 was working on Lisp bindings for the Hurd interfaces, and did a great job: Not only he implemented bindings for all low-level interfaces as well as higher-level libraries for easy creation of translators and other hurdish programs, but also implemented 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 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 was working on a new procfs implementation, to allow runnig 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 arestill 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. We decided to keep up the IRC 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 on this list and would like to contribute, but feel that you could do so better under formal mentoring: Please
Re: An idea for versiont racking using translators
Hi, On Sat, Aug 30, 2008 at 10:55:37PM +0200, Arne Babenhauserheide wrote: Am Samstag 30 August 2008 02:55:25 schrieb [EMAIL PROTECTED]: It would certainly be possible -- but what's the use? Version control is not interactive, nor does it pass around komplex structured data -- it's just the kind of use case for which the main UNIX communication mechanisms (command line arguments and pipes) were created, and consequently they work very nice here... And Git demonstrates how to make good use of that :-) A possible use is, that it could be done by any user tool, and it could use any version control system below that. It would provide a layer of abstraction for version tracking software. I could commit from any file system browser without having to change that browser. Imagine a multi-user system, where the administrator wants to provide a version tracked collaborative writing system, but all users can use exactly the system they want - they only have to have something which can operate on files, regardless if it's a GUI browser, a shell, or anything else. These are very good arguments -- and in fact the same ones that make me argue for extensive use of filesystem interfaces in many contexts! Yet I'm not convinced that version control really fits well into a filesystem interface. Again, I do think that it would be very useful for *browsing* the history; but I have very serious doubts about comitting... No, that's not possible. cp is really a rather dumb action: It reads the data from the source files, and writes it to the destination files. If the source files are managed by a translator, the translator will only see that the files are read, but not where they are written, or to what purpose... Damn, but that's how it is... So, the next step is a mechanism for overloading UNIX commands?... ;-) -antrik-
