diff options
Diffstat (limited to 'faq')
| -rw-r--r-- | faq/ghamp.mdwn | 18 | ||||
| -rw-r--r-- | faq/how_many_developers.mdwn | 63 | ||||
| -rw-r--r-- | faq/how_many_developers/discussion.mdwn | 61 | ||||
| -rw-r--r-- | faq/posix_compatibility.mdwn | 32 | ||||
| -rw-r--r-- | faq/posix_compatibility/discussion.mdwn | 25 | ||||
| -rw-r--r-- | faq/sharing_the_user_space.mdwn | 23 | ||||
| -rw-r--r-- | faq/smp.mdwn | 28 | ||||
| -rw-r--r-- | faq/system_port.mdwn | 47 | ||||
| -rw-r--r-- | faq/which_microkernel.mdwn | 55 | ||||
| -rw-r--r-- | faq/which_microkernel/discussion.mdwn | 94 |
10 files changed, 446 insertions, 0 deletions
diff --git a/faq/ghamp.mdwn b/faq/ghamp.mdwn new file mode 100644 index 00000000..16849aff --- /dev/null +++ b/faq/ghamp.mdwn @@ -0,0 +1,18 @@ +[[!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="GHAMP"]] + +*GHAMP* is the GNU/Hurd-based Apache, MySQL, PHP solution stack -- analoguous +to GLAMP, which is based on GNU/Linux. + +Pronounce it like the *G* in +[GNU](http://www.gnu.org/pronunciation/pronunciation.html), followed by a +mostly silent *H*, and *AMP* as in amplifier. diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn new file mode 100644 index 00000000..a96e0576 --- /dev/null +++ b/faq/how_many_developers.mdwn @@ -0,0 +1,63 @@ +[[!meta copyright="Copyright © 2010, 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]]."]]"""]] + +[[!meta title="How many developers are working on the GNU Hurd, and why so +few?"]] + + +# How Many Developers? + +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 (apart from some +[[bounties|tag/bounty]]) 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/how_many_developers/discussion.mdwn b/faq/how_many_developers/discussion.mdwn new file mode 100644 index 00000000..6ca47c9a --- /dev/null +++ b/faq/how_many_developers/discussion.mdwn @@ -0,0 +1,61 @@ +[[!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]]."]]"""]] + +# IRC, freenode, #hurd, 2011-05-22 + + <silver_hook> Since apparently Hurd's aim is a very stable and transparent + system ...why aren't there any companies backing it up? + <antrik> silver_hook: it's not in a state yet where it would be + commercially interesting + <antrik> silver_hook: and after some epic failures in the 90s, few + companies dare to invest in microkernel development... + <silver_hook> Isn't MacOS X running on top of Mach? + <antrik> yes, but it's not a true microkernel system + <antrik> for one, it's single-server, which is boring + <antrik> also it uses co-location, i.e. runs all the system code in the + kernel address space -- they are separated only formally + <antrik> even NT is more of a microkernel system I think + <silver_hook> Oh, OK, I'm not that knowledgeable about kernels to know + that. + <antrik> well, now you know :-) + <silver_hook> Yup, thanks :) + <antrik> most people don't know this, so don't worry + <silver_hook> I was just wondering that it might be potentially an ideal + server system, right? + <antrik> well, *potentially* it might be an ideal general-purpose system, + which includes server use... though personally I think the advantages of + the architecture are more visible in desktop use, as servers tend to be + rather streamlined, with little need for individualisation :-) + <antrik> however, it still remains to be proven that true (multi-server) + microkernel operating systems actually work for general-purpose + applications... + <silver_hook> antrik: I mean regarding hosting or virtual servers. + <antrik> so far, they are only successful in the much simpler embedded + space + <antrik> well, yes, the Hurd architecture in theory allows very much + flexibility regarding virtual environments... I once blogged about + that. not sure whether server applications really require that + flexibility though. I think most people are pretty happy with the various + virtualisation/container solutions available in Linux. again, the + flexibility is more relevant in the desktop space IMHO + <antrik> dosn't mean it wouldn't be useful for servers too... just not as + much of a selling point I fear :-) + + +# IRC, freenode, #hurd, 2011-07-09 + + <antrik> gnu_srs1: regarding your question why people aren't interested in + workin on Hurd: Eric Raymond explains it pretty well in his famous + "Cathedral and Bazaar" paper + <antrik> people are more likely to work on something that *almost* works + for them, and where they only have to fill in a few missing bits + <antrik> the Hurd doesn't almost work for anyone + <antrik> actually, you should probably reread the whole paper. it's + essentially an analysis why the Hurd failed compared to Linux diff --git a/faq/posix_compatibility.mdwn b/faq/posix_compatibility.mdwn new file mode 100644 index 00000000..4490b7cb --- /dev/null +++ b/faq/posix_compatibility.mdwn @@ -0,0 +1,32 @@ +[[!meta copyright="Copyright © 2010, 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]]."]]"""]] + +[[!meta title="POSIX compatibility"]] + +Is it favorable of rather a hindrance to be compatible to POSIX and similar +standards? + +A lot of things in POSIX et al. are designed for [[UNIX]]-like systems with +traditional monolithic [[kernel]]s. + +Thus, a [[microkernel]]-based system, as ours is, has to employ a bunch of +detours, for example to implement the [[`fork` system call|glibc/fork]]. + +On the other hand, (mostly) complying to these standards, made a really big +body of software *just work* without any (or just trivial) [[hurd/porting]]. +Especially so for command-line programs, and libraries. + +But: a large part of today's user programs are not written according to POSIX +et al. low-level interfaces, but against GNOME, GTK+2, and other high-level +frameworks and libraries. It may be a valid option to enrich these instead of +striving for total POSIX compliance -- and the high-level programs (that is, +their users) may not even notice this, but we would avoid a lot of overhead +that comes with wrapping the [[Hurd interfaces|hurd/interface]] to be POSIX +compliant. diff --git a/faq/posix_compatibility/discussion.mdwn b/faq/posix_compatibility/discussion.mdwn new file mode 100644 index 00000000..0d722c9e --- /dev/null +++ b/faq/posix_compatibility/discussion.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010, 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]]."]]"""]] + +[[!tag open_issue_documentation]] + +\#hurd IRC channel on Freenode, 2010-12-21: + + <antrik> tschwinge: the writeup ignores the fact that POSIX compatibility + is not only for applications, but also for users familiar with the UNIX + environment + <antrik> also, I still don't buy the fact that most software is not written + for POSIX. even if assuming that GNOME programs don't use POSIX (which is + only half true), there is a lot of other software in a system that is + just as important, though less visible + <antrik> (server software, startup system, device management, automation, + ...) + <antrik> tschwinge: BTW, I meant to (and partially did) write a blog + article on this topic -- but I didn't get around to finish it... diff --git a/faq/sharing_the_user_space.mdwn b/faq/sharing_the_user_space.mdwn new file mode 100644 index 00000000..ec880827 --- /dev/null +++ b/faq/sharing_the_user_space.mdwn @@ -0,0 +1,23 @@ +[[!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]]."]]"""]] + +*Question:* Could it be possible to have a system installation where you can +dual-boot using either the [[Linux]] kernel, or the GNU Hurd, so that +everything but the kernel is shared? + +*Answer:* Given that both Linux and GNU Hurd are using the [[ELF]] binary +format, this could indeed be made possible, if all programs agreed to rely on +only one abstraction layer, for example the standard C library ([[glibc]]). +(Additionally, for example for [[system call]]s that are not covered by glibc +calls, you'd need to be able to reliably trap and emulate these.) However, +Linux' and the GNU Hurd's [[ABI]]'s have sufficiently diverged, so that this is +not easy to do. That's why you can't currently install a system in this way, +but you need a separate installation of the userspace suited for the Linux +kernel, or the GNU Hurd. diff --git a/faq/smp.mdwn b/faq/smp.mdwn new file mode 100644 index 00000000..e95edcd2 --- /dev/null +++ b/faq/smp.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2009, 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]]."]]"""]] + +[[!meta title="Does GNU/Hurd support SMP/Multicore?"]] + +The Hurd servers themselves are multithreaded, so they should be able to take benefit of the parallelism brought by SMP/Multicore boxes. This has however never been tested yet because of the following. + +[[microkernel/Mach]] used to be running on SMP boxes like the [[!wikipedia +Intel_iPSC/860]], so principally has the required infrastructure. It has +however not yet been enhanced to support nowadays' SMP standards like ACPI, +etc. Also, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue +code likely isn't SMP-safe. As this glue code layer is not used in the +[[microkernel/mach/gnumach/ports/Xen]] port of GNU Mach, the plan is to try it +in this enviroment first. + +[[!tag open_issue_gnumach open_issue_xen]] + +That is why for now GNU/Hurd will only use one logical processor (i.e. one core or one thread, depending on the socket type). + +Once this issue is solved, there are follow-up issues about +[[open_issues/multiprocessing]] and [[open_issues/multithreading]]. diff --git a/faq/system_port.mdwn b/faq/system_port.mdwn new file mode 100644 index 00000000..c831c36f --- /dev/null +++ b/faq/system_port.mdwn @@ -0,0 +1,47 @@ +[[!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]]."]]"""]] + +[[!meta title="Doing a GNU/Hurd System Port"]] + +How difficult is it to port the GNU/Hurd system to run on another architecture? + +The GNU/Hurd system consists of [[/Hurd]] servers running as user-space +processes on top of the [[GNU Mach|microkernel/mach/gnumach]] microkernel. The +system functionality is usually accessed through the +[[POSIX|posix_compatibility]] interface that is provided by [[/glibc]] and +[[/libpthread]]. + +A whole-system port involves touching all these components, with varying +degree, of course. + +For a CPU architecture port, the microkernel is the most involved part, +followed by glibc and the threading library. + +The original [[microkernel/Mach]] microkernel was portable to a number of +architectures which were a lot more popular at the beginning of the 1990s than +they are now. + +The GNU/Hurd system is currently available for the x86 architecture. This +includes emulators such as [[hurd/running/QEMU]] (or KVM), or +[[hurd/running/VirtualBox]]. Besides this, there is a port for the [[Xen +domU|microkernel/mach/gnumach/ports/xen]] *sub-architecture*. + +Further on, there are some [[unfinished porting +attempts|microkernel/mach/gnumach/ports]] for the Alpha, MIPS and PowerPC +architectures. These have not been completed due to little developer interest. + +Another option is to do the port at a different layer: port the Hurd servers to +not run on the GNU Mach microkernel, but instead on top of [[another +microkernel|which_microkernel]]. Or, even by providing a Mach emulation layer +on top of a monolithic kernel. For example, there could be a port for [[having +Mach run as a POSIX user-space process|open_issues/mach_on_top_of_posix]], or +by implementing the [[Mach IPC|microkernel/mach/ipc]] facility (as well as +several others) as Linux kernel modules. While there have been some +experiments, no such port has been completed yet. diff --git a/faq/which_microkernel.mdwn b/faq/which_microkernel.mdwn new file mode 100644 index 00000000..84b661e4 --- /dev/null +++ b/faq/which_microkernel.mdwn @@ -0,0 +1,55 @@ +[[!meta copyright="Copyright © 2009, 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]]."]]"""]] + +[[!meta title="What happened with the Hurd ports to the L4 / Coyotos / Viengoos +microkernels?"]] + +<!-- This page shares some text with history/port_to_another_microkernel. --> + +It is a frequently asked question, which microkernel the Hurd should be based +upon assuming that [[microkernel/Mach]] is no longer considered state of the +art, and it is well known that there has been a lot of discussion about this +topic, and also some code produced, but then, years later, the Hurd is still +based on [[GNU Mach|microkernel/mach/gnumach]]. + +Around the turn of the millenium, some of the Hurd developers began +experimenting with using other [[microkernel]]s for the Hurd, as they have been +encountering a number of fundamental design issues with the [[Mach +microkernel|microkernel/mach]], mostly with respect to +[[open_issues/resource_management_problems]]. + +At that time, L4 (Pistachio) was the prime candidate. A reimplementation of +the Hurd on this microkernel looked promising, and got pretty far (running some +simple POSIX programs, such as `banner`). However, over time some lingering +design issues turned out to be fundamental problems: the original L4 is not +suitable for building object-capability systems like the Hurd. Thus +development was aborted in 2005. + +During that process, Neal Walfield and Marcus Brinkmann started on a period of +research on other microkernels, getting in deeper contact with other +researchers. There was a lot of discussion, and a lot of good ideas produced, +but a straight-forward port of the Hurd to such a modern microkernel (Coyotos, +or the new L4 variants, for example) didn't seem feasible to them anymore: they +found microkernel design and system design to be interconnected in very +intricate ways, and this demanded design changes in the Hurd's core itself. + +Based on this experience, the next step was to write an own microkernel +instead, which Neal Walfield began doing with his experimental +[[microkernel/Viengoos]] project, for his research on resource management. +Currently he works in another research area though, and thus Viengoos is on +hold. + +Note that while none of the microkernel research work is active now, the +previous experiments already yielded a lot of experience, which will be very +useful in the further development / improvement of the mainline (Mach-based) +Hurd implementation. + +For more details about this topic, please see our history page about the +[[history/port_to_another_microkernel]]. diff --git a/faq/which_microkernel/discussion.mdwn b/faq/which_microkernel/discussion.mdwn new file mode 100644 index 00000000..7ea131e9 --- /dev/null +++ b/faq/which_microkernel/discussion.mdwn @@ -0,0 +1,94 @@ +[[!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]]."]]"""]] + +[[!tag open_issue_documentation]] + +[[!toc]] + + +# Olaf, 2011-04-10 + +This version mixes up three distinct phases: rewrite from scratch; redesign; +own microkernel. + +While Okuji initially might have intended a direct port of the existing Hurd +code, by the time I started following Hurd development (2004 IIRC), it has been +long clear that Hurd/L4 is a rewrite from scratch. + +The next phase was the desire of Neal and especially Macrus to completely +reinvent the design of the Hurd. This was mostly fueled by Shapiro's influence, +resulting in a security-above-everything rage. It was in this phase that not +only the original L4 has been abandonend, but also all thoughts about using +newer L4 variants (which might have been suitable) were forsaken in favor of +Shapiro's Coyotos. + +The whole idea of redesigning the Hurd -- especially for security concerns -- +is highly controversial: I always strongly objected to it; and Marcus later +admitted himself that he got carried away and lost sight of what really matters +for the Hurd. (But only after realising that Shapiro's notion of high security +is fundamentally incompatible with the GNU philosophy.) I opted for not +explicitely mentioning this aspect in the FAQ at all, as it's impossible to +explain properly in a compact form, and probably impossible at all to do it in +an objective fashion. + +The final phase -- following the realisation of incompatibility with +Shapiro/Coyotos -- was the attempt to create new microkernels specifically for +Hurd's needs. Marcus abandonned his pretty soon, and never made it public, so I +didn't mention it at all; but Viengoos is still relevant in certain ways. + +BTW, my original text also more explicitely answers the question what happened +to the Coyotos port -- which after all is what the title promises... + +All in all, I still think my text was better. If you have any conerns with it, +please discuss them... + + +# IRC, freenode, #hurd, 2011-09-27 + + <cjuner> Does anyone remember/know if/why not seL4 was considered for + hurd-l4? Is anyone aware of any differences between seL4 and coyotos? + + +## 2011-09-28 + + <antrik> cjuner: the seL4 project was only at the beginning when the + decision was made. so was Coyotos, but Shapiro promised back then that + building on EROS, it would be done very fast (a promise he couldn't keep + BTW); plus he convinced the people in question that it's safer to build + on his ideas... + <antrik> it doesn't really matter though, as by the time the ngHurd people + were through with Coyotos, they had already concluded that it doesn't + make sense to build upon *any* third-party microkernel + <cjuner> antrik, what was the problem with coyotos? what would be the + problem with sel4 today? + <cjuner> antrik, yes I did read the FAQ. It doesn't mention seL4 at all + (there isn't even much on the hurd-l4 mailing lists, I think that being + due to seL4 not having been released at that point?) and it does not + specify what problems they had with coyotos. + <antrik> cjuner: it doesn't? I thought it mentioned "newer L4 variants" or + something like that... but the text was rewritten a couple of times, so I + guess it got lost somewhere + <antrik> cjuner: unlike original L4, it's probably possible to implement a + system like the Hurd on top on seL4, just like on top of + Coyotos. however, foreign microkernels are always created with foreign + design ideas in mind; and building our own design around them is always + problematic. it's problematic with Mach, and it will be problematic with + any other third-party microkernel + <antrik> Coyotos specifically has different ideas about memory protection, + different ideas about task startup, different ideas about memory + handling, and different ideas about resource allocation + <cjuner> antrik, do any specific problems of the foreign designs, + specifically of seL4 or coyotos come to mind? + <antrik> cjuner: I mentioned several for Coyotos. I don't have enough + understanding of the matters to go into much more detail + <antrik> (and I suspect you don't have enough understanding of these + matters to take away anything useful from more detail ;-) ) + <antrik> I could try to explain the issues I mentioned for Coyotos (as far + as I understand them), but would that really help you? |