bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC application deadline passed


From: Arne Babenhauserheide
Subject: Re: GSoC application deadline passed
Date: Fri, 14 Mar 2008 15:58:33 +0100
User-agent: KMail/1.9.7

El Friday, 14 de March de 2008 15:08:31 Carl Fredrik Hammar escribió:
> Indeed, under exposure is a problem.  Hopefully, GSoC will give us
> some.

I think exposure is also to a part a general structure problem, but one which 
shouldn't be that hard to solve. 

I see many posts on this list, but they aren't visible for someone visiting 
the website. 

And I can't even see a direct link from the main page to the wiki. 

To make the Hurd more visible, I see two simple first steps: 

* Put a *prominent* link to the wiki on the main Hurd page. 
* Put a *prominent* link to the bug-hurd archives on the main Hurd page. 

A third step would be: 
* Setup a blog and write your commit messages in there. If there is a git (or 
mercurial) repository, also add a link to its web frontend on the website. 
People must see, that the Hurd is active. 

This is for the easy steps. 

<snip>

> First a little nit-picking.  :-)
>
> The Hurd is capitalized ``Hurd'' and not ``HURD'', a common
> misconception given by the logo.

I wasn't sure which one is correct :) 
Thanks! 

> Lines should be manually wrapped when entered in the wiki, while it
> doesn't change the presentation it is visible when viewing changes of
> viewing it through a normal editor.

OK. 

> Also, please put a comment on every change, however small.

That's far easier when just committing via git/hg/... at least I'm more used 
to doing it there :) 

> I'll fix it this time, but please keep it in mind the next time you
> contribute (which I hope you keep doing :-).  I'll put these as a
> start of a new page with instructions on how the wiki should be
> formatted.

Thanks! 

> Now to a real issue.  While there's nothing wrong with the project as
> such (in fact it's quite a good idea), I think most of the project is
> more in the domain of distributions, e.g. Debian, rather then the Hurd
> itself.
>
> The Hurd is only the kernel, and as such it is quite uninteresting to
> have a live cd containing only that, what you want is a complete
> distribution of packages.  While of course interesting in the context
> of the Hurd, it is not technically part of it so I don't think it's
> appropriate for GSoC.
>
> It should probably be moved to a different suggestion/task page.  But
> I'll let someone with more authority make the decision whether it
> stays or not.

That means, the Hurd would completely depend on the Debian people to make new 
releases. 

That dependency might not be bad (and might save time), but for things like 
updated qemu images and similar, it doesn't seem to work well enough. 

Maybe it would really be a project for Debian, to package new things with the 
Hurd. 

But packaging a new Hurd with an existing Debian image doesn't need to be done 
by the Debian people. 

The kernel itself might not be interesting, but testing teh changes in a new 
release of the kernel is - and that can be done without having to rebuild the 
whole installation. 

> > I like the ideas about the HURD, and I want to be able to switch to a
> > HURD system soon (at most a few years), so the progress and state of the
> > HURD must be visible.
> >
> > One example: I see many changes in the commit list.
> > Why don't I see livecds integrating the new changes appearing at once?
> > Why are there no automatically updated images, I can just testdrive?
>
> Most of the recent changes has been on the L4 branch, which was
> originally an attempt to port Hurd to the L4 micro kernel.  That
> didn't work out for various reasons, so currently they are
> experimenting with their own kernel until something better comes
> along.  (Disclaimer: I'm not a 100% sure on any of this.)

Does that already run? 
Would it be possible to turn it into a livecd or qemu image? 

> Development on the Hurd proper has been slower.  Most of the progress
> seems to be temporary fixes that is managed through patches and needs
> real solutions in-order to actually get into the Hurd.
>
> There are some important bugs that needs to be properly fixed before a
> new release can be made (although I can't seem to locate a list of
> them).

If you find a list, that list should go into the wiki, along with a roadmap on 
which things can be marked "done". 

That means, the Hurd needs something like the Shedules in KDE: 
-> http://techbase.kde.org/index.php?title=Schedules

Each new release just needs a todo list with bugs and features. 

And with these things (maybe 1 or 2 hours of work, plus coordination to find 
out where the Hurd should actually head right now) the Hurd will look far 
promising than any long text could make it. 


> > Besides: Is there some other way to update the wiki besides the
> > webinterface? That web interface is horribly slow for me.
>
> That's what happens when you host stuff on a Hurd machine.  ;-)
>
> You can access the git back-end directly.  Unfortunately there ae no
> instructions on how to access it on the wiki (or anywhere else it
> seems).  I'll try to fix it once I figure it out myself.  :-)

That would be great! 

> I'm not sure it's actually faster though, but at least you'd be able
> to update multiple changes in one batch (I think).

And I'd get better feedback :) 

Besides: I attached an update on the main website which includes a link to the 
wiki and a link to the Bug-Hurd archives. 
$ diff index.html index.html.1
34a35
> <a href="http://www.bddebian.com/~wiki/";>Information in the Wiki</a>
67a69,70
> <P>
> Current discussions about the Hurd can be found in the <a 
href="http://lists.gnu.org/archive/html/bug-hurd/";>Bug Hurd archives</a>.

-- 
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )
-- Weblog: http://blog.draketo.de

-- Mein öffentlicher Schlüssel (PGP/GnuPG): 
http://draketo.de/inhalt/ich/pubkey.txt
 [image of the Hurd logo] [ Dutch | English | Esperanto | German | Hebrew | Polish | Slovak | Spanish ]
What's New
 
ChangeLogs
 
Documentation
Information in the Wiki

GNU Hurd
 
Installation
Getting Help
Source Code
Development
History
 
GNU Mach
 
Installation
Source Code
 
GNU MIG
 
Source Code
 
Related Projects


What is the GNU Hurd?

The GNU Hurd is the GNU project's replacement for the Unix kernel. The Hurd is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux).

If you have any news related to the Hurd project, feel free to send a news entry to web-hurd@gnu.org so that it can be added here.

Current discussions about the Hurd can be found in the Bug Hurd archives.


What's new?

2008-02-11

A number of GNU Hurd developers will again (as already in the previous years) meet at the time of the FOSDEM 2008, which will take place from 2008-02-23 to 24 in Brussels, Belgium. This wiki page has some details. Contact us if you are interested in meeting with us.

2007-10-12

Stefan Siegl added support for IPv6 networking to the pfinet translator.

2007-10-01

This year the GNU Hurd had again been assigned one slot within the Google Summer of Code program, which was assigned to the task design and implement libchannel, a library for streams. Carl Fredrik Hammar has been working on this task and recently posted a summary about the successful work he had been doing, but also gave an outline about how he intends to continue improving and extending it.

2007-03-14

The GNU Hurd project will participate in this year's Google Summer of Code, under the aegis of the GNU project.

The following is a list of items you might want to work on. If you want to modify these task proposals or have your own ideas on what to work, then please don't hesitate to contact us on the bug-hurd mailing list or the #hurd IRC channel.

Please see the page GNU guidelines for Summer of Code projects about how to make an application and Summer of Code project ideas list for a list of tasks for various GNU projects and information about about how to submit your own ideas for tasks.

2007-01-14

Neal Walfield and Marcus Brinkmann have written and submitted for publication A Critique of the GNU Hurd Multi-server Operating System and a position paper Improving Usability via Access Decomposition and Policy Refinement. Please follow the two preceding links to see the complete announcements. The authors welcome comments and discussion which may be directed to the <bug-hurd@gnu.org> mailing list for the Critique and to the <l4-hurd@gnu.org> mailing list for the position paper.

The abstract of the Critique:

The GNU Hurd's design was motivated by a desire to rectify a number of observed shortcomings in Unix. Foremost among these is that many policies that limit users exist simply as remnants of the design of the system's mechanisms and their implementation. To increase extensibility and integration, the Hurd adopts an object-based architecture and defines interfaces, which, in particular those for the composition of and access to name spaces, are virtualizable.

This paper is first a presentation of the Hurd's design goals and a characterization of its architecture primarily as it represents a departure from Unix's. We then critique the architecture and assess it in terms of the user environment of today focusing on security. Then follows an evaluation of Mach, the microkernel on which the Hurd is built, emphasizing the design constraints which Mach imposes as well as a number of deficiencies its design presents for multi-server like systems. Finally, we reflect on the properties such a system appears to require.

The abstract of the position paper:

Commodity operating systems fail to meet the security, resource management and integration expectations of users. We propose a unified solution based on a capability framework as it supports fine grained objects, straightforward access propagation and virtualizable interfaces and explore how to improve resource use via access decomposition and policy refinement with minimum interposition. We argue that only a small static number of scheduling policies are needed in practice and advocate hierarchical policy specification and central realization.

Old news entries.

[ Dutch | English | Esperanto | German | Hebrew | Polish | Spanish ]

Return to GNU's home page.

Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

Please send comments on these web pages to web-hurd@gnu.org, send other questions to gnu@gnu.org.

Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Updated: $Date: 2008/02/11 13:55:02 $ $Author: tschwinge $


Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]