Niches for the Hurd =================== In the bug-hud mailinglist we did a search for niches where the Hurd is *the biggest fish in the pond*. This search was segmented into four distinct phases, three of them major: - Brainstorm - Reality check: can already do vs. could be used for - Turn ideas into applications - Find a compromise -> About which niches should we talk in the wiki? Brainstorm ---------- "Which niches could there be for the Hurd?" ### Basic Results The result is a mix of target groups, nice features and options of the Hurd, reasons for running a Hurd and areas where the Hurd offers advantages: #### Nice features and options the Hurd offers - Give back power to users: arbitrary mounts, subhurds - Nice features: dpkg -iO ftp://foo/bar/*.deb - Easier access to low-level functions - Advanced lightweight virtualization - operating system study purposes as its done with minix - The possibility to create more efficient and powerful desktop environments - Having a _complete_ GNU System - All-in-one out-of-the-box distro running a webserver for crash-proof operation. #### Target groups and strong environments - Tinkerers who like its design. - multicore-systems ### The keyphrases in more detail or with additional ideas #### Give back power to users: arbitrary mounts, subhurds Simpler virtual computing environments - no need to setup XEN, everyone can just open up his/her computer for someone else by creating a new user account, and the other one can login and easily adapt the system for his/her own needs. If most systems just differ by the translators setup on them, people could even transfer their whole environment from one computer to another one without needing root access or more root interaction than creating a new user account. "I want my tools" -> "no problem, just setup your translators". Also it would be possible to just open an account for stuff like joining the "World Community Grid" allowing for easier sharing of CPU time. #### Easier access to low-level functions One important use is for very technical people, who don't always go with standard solutions, but rather use new approaches to best solve their problems, and will often find traditional kernels too limiting. Another interesting aspect is application development: With the easily customized/extended system functionality, and the ability to contain such customizations in subenvironments, I believe that Hurd offers a good platform for much more efficient development of complex applications. Application developers can just introduce the desired mechanisms on a very low level, instead of building around existing abstractions. The extensible filesystem in particular seems extremely helpful as a powerful, intuitive and transparent communication mechanism, which allows creating truly modular applications. #### Advanced lightweight virtualization There is also the whole area I called "advanced lightweight virtualization" (see http://tri-ceps.blogspot.com/2007/10/advanced-lightweight-virtualization.html ), i.e. the ability to create various kinds of interesting subenvironments. Many use cases are covered by much bigger fish; but the flexibility we offer here could still be interesting: I think the middle grounds we cover between directly running applications, and full isolation through containers or VMs, are quite unique. This could simplify management of demanding applications for example, by partially isolating them from other applications and the main system, and thus reducing incompatibilities. Creating lightweight software appliances sounds like an interesting option. #### The possibility to create more efficient and powerful desktop environments While I believe this can be applied to any kind of applications, I'm personally most interested in more efficient and powerful desktop environments -- these considerations are in fact what got me seriously interested in the Hurd. Even more specifically, I've done most considerations (though by far not all) on modular web browsing environments. Those interested can read up some of my thoughts on this: http://sourceforge.net/mailarchive/message.php?msg_name=20080909073154.GB821%40alien.local (Just skip the text mode browsing stuff -- the relevant part is the long monologue at the end... I really should put these ideas into my blog.) #### Nice features Another example of features which would be easily possible with the Hurd: * media-player translator: - settrans play /hurd/mediaplayer_play - cp song1.ogg song2.ogg play - # -> files get buffered and played. or even: * cp ftp://foo/bar/ogg play that's KDEs fabled network transparency on the filesystem / shell level. Reality check ------------- Check which of the ideas can already be done easily with the Hurd in its current state, which ones are a bit more complex but already possible, which ones need a bit of coding (could be accomplished in a few months judging from the current speed of development), which ones need a lot of work (or fundamental changes) and which ones aren't possible. ### Already possible and easy ### Already possible but complex or underdocumented ### Need a few months of coding - A filesystem-based package manager. - A framework for confining individual applications is really just one possible use case of the hurdish subenvironments. Writing the tools necessary for that should be quite doable in a few months. It's probably not really much coding -- most of the work would be figuring out how it should be set up exactly. ### Need a lot of coding or fundamental changes - Effective resource management ### Unfeasible ideas Applications ------------ A minor phase, which will surely be interleaved with the others: Making the ideas tangible to turn them into ways how people can use the Hurd. "Hey, look, this is the Hurd. You can use it like this to do that which you can't do as well/easily/elegantly in any other way." ### Applications for private use ### Applications for companies Compromise ---------- For each niche: - How many additional programmers can the Hurd get in this niche? - How does choosing this niche limit the flexibility of further development? - Can we easily move on to conquering the next niche once we got this one? - What should the Hurd accomplish on the long term? Which possible niches help that? Each participant: - Give your personal priorities to the niches: * Must -> all of these of all developers must be included; remember that at most 3 to 4 ideas can be conveyed in any text. * Should -> The number of shoulds can be used for ranking and similar. ("must", because in a community people can do what they perceive as important, and telling someone to stop what he's doing is no option (in my opinion)) Things to do ------------ ### Easy - Port debian packages to the Hurd.