summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--faq/how_many_developers.mdwn61
-rw-r--r--faq/why_so_few_developers.mdwn27
-rw-r--r--public_hurd_boxen.mdwn8
-rw-r--r--user/jkoenig/gsoc2011_proposal.mdwn1
-rw-r--r--user/jkoenig/gsoc2011_proposal/discussion.mdwn180
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]]).