Sorted the ideas for niches according to the approximate amount of work necessary for them.

1 files changed, 117 insertions, 5 deletions

diff --git a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
index 9007f027..133b46a1 100644
--- a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
+++ b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
@@ -135,8 +135,26 @@ aren't possible.
 
 ### Already possible and easy
 
+- Sample translators: 
+	* hello world. 
+	* transparently bind FTP into the filesystem
+ 	* hostmux + ftpfs -> connect to FTP automatically via asking for a dir named after the hostname -> fully transparent FTP filesystem: "touch ftp: ; settrans ftp: /hurd/hostmux /hurd/ftpfs / "
+	* bind any filesystem at any place in the filesystem (you have access to) without needing to be root. 
+	* elegantly mount iso images and similar as unprivileged user. 
+
+- Other useful stuff: 
+	* Install deb-packages from an ftp server via 'dpkg -iO ftp://foo/bar/*.deb'
+
+- Having a complete GNU System (but not yet on every hardware, and only about half the software Debian offers has been ported). 
+
 ### Already possible but complex or underdocumented
 
+- Easier access to low-level functions via translators. 
+
+- Operating system study purposes as it's done with minix. 
+
+- Tinkering for fun - need documentation about the fun things which can be done. 
+
 ### Need a few months of coding
 
 - A filesystem-based package manager. 
@@ -145,15 +163,67 @@ aren't possible.
 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.
+should be set up exactly. 
+
+- Running parts of the Hurd on different computers, maybe even with shared servers on 
+dedicated hardware (Cloud Computing when the servers can be made to migrate from 
+between computers). Maybe this should be placed in "need a lot of coding". 
+
+- subhurds for quickly adapting the whole system without bothering others. 
+
+- Define your personal environment via translators, so you can easily take it with 
+you (translators written in scripting laguages can make this easier - they could 
+also for example be taken to each computer on USB stick). 
+
+- A more powerful alternative to FUSE filesystems: While FUSE is limited to standard
+filesystem semantics, while Hurd translators can implement whatever they
+want.
+It is possible to change the behaviour in any aspect, including the way
+file name lookup works. Admittedly the only specific use case I know is
+the possibility to implement namespace-based translator selection with a
+set of normal translators, without any changes to the Hurd itself.
+It is also possible to extend the filesystem interfaces, adding new RPCs
+and options as needed. This allows using the filesystem for
+communication, yet implementing domain-specific interfaces where
+standard filesystems are too unefficient or cumbersome. A sound server
+would be one possible use case. 
+
+- Namespace based translator selection (if you for example want to quickly check the 
+contents of an iso image, just look at them via 'ls image.iso,,iso9660fs'). 
 
 ### Need a lot of coding or fundamental changes
 
-- Effective resource management
+- Effective resource management (For example via Viengoos on which Neal Walfield is 
+working). The idea is that we could make a virtue out of necessity: Once we have a 
+proper resource management framework, we should be able not only to catch up with 
+traditional systems in this reagard, but in fact surpass them.
+
+- The possibility to create more efficient and powerful desktop environments. 
+
+- Multicore systems (need to fixup Mach for SMP)
+
+- Currently to offer CPU time to some project (like the World Community Grid), it is 
+necessary to install a program from them, and they can then do only what that proram 
+allows them to - which leads to reinventing a processing environment instead of just 
+using the existing OS. 
+With the Hurd people could just create a user for them, give that user specific 
+permissions (like "you're always lowest priority"), add the public ssh keys of 
+the project they want to donate CPU cycles to, and the project could just turn 
+the computer into the environment it needs for the specific computation, 
+without compromising the main system in any way.
+
+- A shared MMORPG game world consisting simply of files for levels and person 
+descriptions with access rights. All synchronizing is done on the translator 
+level. Programs only have to display the given files and quickly update the 
+state of their own files, so the programs stay very easy. The translator could 
+notify the program when something changes.
+
+
 
 ### Unfeasible ideas
 
 
+
 Applications
 ------------
 
@@ -163,20 +233,60 @@ 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
 
+### How an application should be presented so people can easily test and digest it
+
+We need stuff which gets people to say "hey that's cool!"
+
+And it must be readily available. 
+If I have to search for arcane command line parameters before I can use it, 
+it's too hard. 
+
+From what I see, each direct cool application must be about as simple as 
+
+$ qemu hurd-is-cool.img
+$ login root
+$ settrans cool /hurd/cool
+$ ls cool
+
+One main focus in this example is: No command line parameters but the ones we 
+really need. No "-a", if the example is also cool without it. 
+No "--console" if it works otherwise. 
+
+Especially no "qemu --cd livecd --hda hurd.img ..." - that one is great for 
+specialists, but the goal here isn't to teach people better usage of qemu, 
+but to show them that the Hurd is cool, and only that. 
+
+All that interesting advanced stuff just gets newcomers confused. 
+
+The translator concept in itself is enough news to faze a mind - anything else 
+can easily be too much. 
+
+If the application isn't as simple as the example above, then the best step 
+would be to see if we can make it as simple - if that involves writing trivial 
+scripts than be it so. They are trivial only to those who already understand 
+the underlying concepts. 
+
+And now enough with rambling :) 
+
+The Hurd is cool, and the complex to use applications are cool, too. 
+But they are hard to present in a way newcomers easily understand.
+
 
 Compromise
 ----------
 
 For each niche: 
 
+- What do we have to do to conquer the niche? 
 - How many additional programmers can the Hurd get in this niche? 
-- How does choosing this niche limit the flexibility of further development? 
+- How does choosing this niche limit the flexibility of further development (for example due to the goals of the people who join up)? 
 - 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? 
+- What should the Hurd accomplish on the long term (long term goals)? Which possible niches help that? 
 
 Each participant: 
 
@@ -192,7 +302,9 @@ telling someone to stop what he's doing is no option (in my opinion))
 Things to do
 ------------
 
+todo-item -> niches for which it is useful. 
+
 ### Easy
 
-- Port debian packages to the Hurd. 
+- Port debian packages to the Hurd -> mainly tinkerers, but also any other niche.