Re: Google Summer of Code 2007
Hi, On Sun, Mar 11, 2007 at 08:44:00PM -0400, Barry deFreese wrote: > Are we talking Debian specific stuff or no? This is about the FSF's GSoC project, so I don't think Debian-specific stuff would be appropriate. > There still the Debian installer afair. Yes, but after last year's fiasco, I'm weary to waste another Debian GSoC slot on Debian GNU/Hurd again, the port has enough PR problems in Debian as is. > Also, how about implementing PPP? Some solution for DSL etc. wouldn't be bad, but today most people have Ethernet of a dedicated DSL router I guess, so it's less urgent than a couple of years ago I think. > I think there was something about being able to boot from a stow'd > filesystem? That might be an important task for the GNU system, but AFAIK it's only a matter of debugging/finding the culprit, not sure whether it merits a GSoC project really. Michael ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [task #6612] Overriding the system's default servers
Hi, <[EMAIL PROTECTED]> writes: > Plan9 has a rather simple solution for this: They have local namespaces > (i.e. each process can have a different view of the filesystem), which > allows easily installing alternative servers in place of the default > ones for individual programs/users/whatever. Likewise, Plash provides an API that eases the creation of a file system hierarchy that can then be served by a proxy server to the sandboxed process. A similar API would be nice to have on the Hurd and would elegantly address a number of issues, including that of replacing system servers. Thanks, Ludovic. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Google Summer of Code 2007
IMHO, o GSoC project should be something doable that can be completed within the given time. Too broad tasks should be avoided. Libchannel is a prerequisitive for many proposed projects. I think that any project that depends on it, should not be proposed. IMHO, each project should be independed of the others for maximum efficiency. AFS? Ext2fs is not working at 100%. Ext3fs support is virtually null. Ognyan Kulev worked on ext3fs, but all his work is documented in bulgarian :(. Why bother with AFS? cthreads-->pthreads: From time to time the same question arises. What is the status of pthread support? Does this task involve bug fixing or code writing? From my limited experience i tend to think it's more of the former, but then again i really don't know. Glue code update: Finally something i have personal experience of. I think it's too complex to be on GSoC. For more details, see one of my old posts here http://lists.gnu.org/archive/html/bug-hurd/2006-11/msg00076.html. Linux has all the documention we need to write new glue code. However, Mach has almost no documentation on how to write device driver code. I believe this is a long term project that can only be accomplished under the close guidance of an experienced mentor. For the rest of the tasks, i agree with Thomas' comments or have the same questions. Thanks, Constantine ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [task #1618] Allowing filesystems larger than ~2 GB
From the wiki: "Note that, while the official CVS sources still suffer of this problem, recent (as of 2007) Debian GNU Hurd distributions do not have this limit anymore. Be happy." I must be missing something serious here because the following question logicaly arises. How can this problem be solved on Debian GNU Hurd and still exist in the official CVS sources?? Thanks, Constantine ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [task #1618] Allowing filesystems larger than ~2 GB
Constantine Kousoulos, le Mon 12 Mar 2007 16:19:11 +0200, a écrit : > I must be missing something serious here because the following > question logicaly arises. How can this problem be solved on Debian > GNU Hurd and still exist in the official CVS sources?? Because Debian includes a lot of patches that didn't go into CVS yet. Samuel ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
