diff options
| -rw-r--r-- | faq/how_many_developers.mdwn | 61 | ||||
| -rw-r--r-- | faq/why_so_few_developers.mdwn | 27 | ||||
| -rw-r--r-- | public_hurd_boxen.mdwn | 8 | ||||
| -rw-r--r-- | user/jkoenig/gsoc2011_proposal.mdwn | 1 | ||||
| -rw-r--r-- | user/jkoenig/gsoc2011_proposal/discussion.mdwn | 180 |
5 files changed, 236 insertions, 41 deletions
diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn index 3c430ca4..ab8e8f28 100644 --- a/faq/how_many_developers.mdwn +++ b/faq/how_many_developers.mdwn @@ -8,18 +8,55 @@ 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="How many developers are working on the GNU Hurd?"]] +[[!meta title="How many developers are working on the GNU Hurd, and why so +few?"]] -Not many. One handful work on it in their free time, and another two -handful do help with [[Debian GNU/Hurd|hurd/running/debian]] and -[[hurd/running/Arch_Hurd]] packaging. Also, an additional handful of -former developers are still available for answering technical questions, -but are not really participating in the current development anymore. -For reaching out to new developers, we're participating in [[Google's -Summer of Code program|community/gsoc]]. Likewise, any interested party -(*you*!) are very welcome to start [[contributing]]. Mentoring is -possible, too, to help you get started. +# How Many Developers? -Continue reading some speculation about [[why so few developers]] are working -on the GNU Hurd. +One handful works on the core of the system in their free time, and another +handful helps with [[Debian GNU/Hurd|hurd/running/debian]] and +[[hurd/running/Arch_Hurd]] packaging. Also, an additional handful of former +developers are still available for answering technical questions, but are not +participating in the current development anymore. + +In the past (that is, a lot of years ago), the FSF did pay a few developers for +working full time on the GNU Hurd. But that was for a limited amount of time +only, and evidently, it was too little for getting the system into a +competitive state. Nowadays, it's only unpaid and free-time volunteers' work. + +In contrast to the Linux kernel, there is no industry involvement in +development. For one, this is a good thing: independency; no conflicts of +interests. For another, it is also a bad thing: no dedicated full-time +manpower -- which matters a lot. + + +# Why So Few? + +We can only speculate. One major problem might be that the [[architectural +benefits|advantages]] are generally perceived as very abstract, with little +practical benefit. We currently don't have many tools that are actually making +use of all the possibilities. + +Another reason is that it's been taking too long. Today, most people don't +believe it will ever be ready for production use, and thus would consider +involvement a waste of time. This latter point is invalid, of course, as +learning can never be a waste of time. The same holds for the [[challenges]] +raised by the GNU Hurd -- we can only learn and improve upon working on them. + +For likely the same reasons there is no industry interest in the GNU Hurd: its +advantages are too abstract and incomplete for being of interest there. + +As for the scientific sector, the GNU Hurd projects was rather about *using* a +[[microkernel]] intead of doing research on them, for example. But, there have +been some projects and theses done, and some scientific papers published on GNU +Hurd topics, and we're generally very interested in further such projects. + + +# Attracting New Faces + +We're an open project: any interested party (*you*!) are very welcome to start +[[contributing]]. Mentoring is possible, too, to help you get started. + +Likewise, for reaching out to new developers, we're participating in [[Google's +Summer of Code program|community/gsoc]]. diff --git a/faq/why_so_few_developers.mdwn b/faq/why_so_few_developers.mdwn deleted file mode 100644 index a2740abc..00000000 --- a/faq/why_so_few_developers.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!meta title="Why are there so few developers working on the GNU -Hurd?"]] - -[[There aren't working a lot of people on the GNU -Hurd|how_many_developers]]. Why is this? - -We can only speculate. One major problem might be that the -[[architectural benefits|advantages]] are generally perceived as very -abstract, with little practical benefits. We don't have many tools to -present actually making use of the possibilities. - -Another reason is that it's been taking too long. Most people don't -believe it will ever be ready for production use, and thus would consider -involvement a waste of time. This latter point is invalid, of course, as -learning can never be a waste of time. The same holds for the -[[challenges]] raised by the GNU Hurd -- we can only learn and improve -upon working on them. diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn index 33fe5cbc..5a281368 100644 --- a/public_hurd_boxen.mdwn +++ b/public_hurd_boxen.mdwn @@ -41,11 +41,15 @@ addresses for requesting support with respect to software installations, etc. For easy access, you should append your public SSH key(s) to `~/.ssh/authorized_keys` on the remote machine. -Also, add the [[!toggle id=bddebian_ssh_config text="following stanza"]] to -`~/.ssh/config` file of the machine you're connecting from. +Also, add the [[!toggle id=bddebian_ssh_config text="following stanza (click +here to toggle display)"]] to the `~/.ssh/config` file of the machine you're +connecting from. [[!toggleable id=bddebian_ssh_config text=""" + # Stanza from <http://www.gnu.org/software/hurd/public_hurd_boxen.html>, + # 2010-12-15. + Host blubber.bddebian.com blubber HostName blubber.bddebian.com diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn index eeaa5aaa..4052f455 100644 --- a/user/jkoenig/gsoc2011_proposal.mdwn +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -221,6 +221,7 @@ low-level systems programming. The principles I would use to guide the design of these Java bindings would be the following ones: + * The system should be hooked into at a low level, to ensure that Java is a "first class citizen" as far as the access to the Hurd's interfaces is concerned. diff --git a/user/jkoenig/gsoc2011_proposal/discussion.mdwn b/user/jkoenig/gsoc2011_proposal/discussion.mdwn new file mode 100644 index 00000000..0131d8d5 --- /dev/null +++ b/user/jkoenig/gsoc2011_proposal/discussion.mdwn @@ -0,0 +1,180 @@ +[[!meta copyright="Copyright © 2011 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 [[tschwinge]] comments regarding your proposal. Which is very good, if I +may say so again! :-) + +Of course, everyone is invited to contribute here! + +I want to give the following methodology a try, instead of only having +email/IRC discussions -- for the latter are again and again showing a tendency +to be dumped and deposited into their respective archives, and be forgotten +there. Of course, email/IRC discussions have their usefulness too, so we're +not going to replace them totally. For example, for conducting discussions +with a bunch of people (who may not even be following these pages here), email +(or, as applicable, the even more interactive IRC) will still be the medium of +choice. (And then, the executive summary should be posted here, or +incorporated into your proposal.) + +Also, if you disagree with this suggested procedure right away, or at some +later point begin to feel that this thing doesn't work out, or simply takes too +much time (I don't think so: writing emails takes time, too), just say so, and +we can reconsider. + +Of course, as this wiki is a passive medium rather than an active one as IRC +and email are, it is fine to send notices like: *I have updated the wiki page, +please have a look*. + +One idea is that your proposal evolves alongside with the ongoing work, and +represents (in more or less detail) what has been done and what will be done. +Also, we can hopefully use parts of it for documentation purposes, or as +recipes for similar work (enabling other programming languages on the Hurd, for +example). + +For this, I suggest the following procedure: as applicable, you can either +address any comments in here (for example, if they're wrong :-), or if they +require further discussion; think: *email discussion*), or you can address them +directly in your propoal and remove the comments from here at the same time +(think: *bug fix*). + +Generally, you can assume that for things I didn't comment on (within some +reasonable timeframe/upon asking me again) that I'm fine with them. Otherwise, +I might say: *I don't like this as is, but I'll need more time to think about +it.* + +There is also a possibility that parts of your proposal will be split off; in +cases where we think they're valuable to follow, but not at this time. (As you +know, your proposal is not really a trivial one, so it may just be too much for +one person's summer.) Such bits could be moved to [[open_issues]] pages, +either new ones or existing ones, as applicable. + + +# POSIX Threads Signal Semantics + + * Great! [[tschwinge]] had a brief look, and should have a deeper one. + + * If [[jkoenig]] thinks it's mature enough: should ask Samuel to test this + (that is, only the refactoring patches for starters?) on the buildds. + + * Then: should ask Roland to review. + + * Documentations bits should probably be moved to [[glibc/signal]]. + + +## libthreads (cthreads) Integration + + * [[tschwinge]] suggests to leave them as-is? + + +## [[libpthread]] integration + + * To be done. + + +# Java + + * [[tschwinge]] has to read about RMI and CORBA. + + +# Joe-E + + * For later. + + +# GCJ + + * [[tschwinge]] has the feeling that Java in GCC (that is, GCJ) is mostly + dead? (True?) + + * Thus perhaps not too much effort should be spent with it. + + If the POSIX threads signal semantics makes it going, then great, otherwise + we should get a feeling what else is missing. + + +# OpenJDK + + * All in all, [[tschwinge]] has the feeling that a working OpenJDK will be + more useful/powerful than GCJ. + + * We need to get a feeling how difficult such an OS port will be. + + * [[jkoenig]] suggests OpenJDK 6 -- should we directly go for version 7 + instead? + + * What are the differences (regarding the OS port) between the two + versions? Or this there something even more recent to be worked upon, + for new OS ports? + + * Perhaps the different versions' OS port specific stuff is not at + all very different, so that both v6 and v7 could be done? + + * They seem to have a rather heavy-weight process for such projects: confer + <http://mail.openjdk.java.net/pipermail/announce/2011-January/000092.html>, + for example. Do we need this, too? + + +# Eclipse + +OK for testing -- but I'd very much hope that it *just works* as soon as we +provide the required Java platform. + + +# Java Bindings + + +## Design Principles + + * Generally ack. + + +### MIG + + * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult. + + * (Unless you want to make MIG's own code (that is, not the generated + code, but MIG itself) look a bit more nice, too.) ;-) + + * There are also alternatives to MIG. If there is interest, the following + could be considered: + + * FLICK ([[!GNU_Savannah_task 5723]]). [[tschwinge]] has no idea yet if + there would be any benefits over MIG, like better modularity (for the + backends)? If we feel like it, we could spend a little bit of time on + this. + + * For [[microkernel/Viengoos]], Neal has written a RPC stub generator + entirely in C Preprocessor macros. While this is obviously not + directly applicable, perhaps we can get some ideas from it. + + * Anything else that would be worth having a look at? (What are other + microkernels using?) + + +### `mach_msg` + + * Seems like the right approach to [[tschwinge]], but hasn't digested all the + pecularities yet. Will definitely need more time. + + +# GSoC Site Discussion + + * Discussion items from + <http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/jkoenig/1> + should be copied here: + + * technical bits (obviously); + + * also the *why do we want Java bindings* reasoning; + + * CLISP findings should also be documented somewhere permanently. + + * We should probaby open up a *languages for Hurd* section on the web + pages ([[!taglink open_issue_documentation]]). |