Hurd-ng is an effort to build a new operating system that preserves the main design goals of the Hurd while fixing some of the Hurd's shortcomings. There is not yet an official roadmap or a concrete specification; indeed, much of the work is research oriented. These pages try to summarize the major discussions and ideas. * [[History]] # Why ngHurd This section explains the motivations behind the new design: * [[IssuesWithMach]] * [[IssuesWithL4Pistachio]] * [[LimitationsOfOriginalHurdDesign]] # Work already done A [position paper](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf) by Marcus Brinkmann and Neal H. Walfield can be found. A draft specification of the Hurd-NG interfaces has been, but is no longer, available. A [[critique]] of the original Hurd is available. # Subjects ## Design processus * [[DesignGoals]] * [[RequirementsForUser]] * [[DesignPrinciples]] * [[Philosophy]] ## Concepts * [[CapabilityBasedMicrokernel]] * [[FirstClassReceiveBuffer]] * [[PowerBox]] * [[WhatIsACapability]] * [[WhatIsAConstructor]] * [[WhatIsASpacebank]] * [[TrivialConfinementVsConstructorVsFork]] * [[CopyVsRevocableCopyVsMap]] * [[SetuidVsConstructor]] * [[HurdishApplicationsForPersistence]] * [[WhatsInAGroup]] * [[ThePolycastInterface]] * [[PermissionBits]] * [[CancellationForwarding]] ## Problems to solve * [[HowMuchConfinementDoWeWant]] * [[SharedLibraries]] * [[PathMax]] ## Implementation * [[ChoiceOfMicrokernel]] * [[HurdInterafaces]] * [[PosixLayer]] * [[SystemStructure]] ## Use Cases _please move me somewhere better! [[SamMason]]_ * [[UseCaseUserFileSystem]] * [[UseCasePrivateKeys]] ## Organization Summaries should obey the following structure: * if there is a consensus, it is clearly described * if controversial points remain, there are also described after the consenus * if no choice has been clearly made, all valid positions are descrbied * withdrawed and invalid positions (prooved wrong, unrealistic, contradictory to some design principle, etc.) should be described only very briefly, and developed in a separate article Each time a point seems to be overly long with respect to the rest of the article, it should be summarized in place and developed in a separate article.