Niches: Added useful: easily remount readonly as user.

1 files changed, 29 insertions, 45 deletions

diff --git a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
index e8dec5a2..2b3ecc32 100644
--- a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
+++ b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
@@ -33,7 +33,7 @@ the Hurd offers advantages:
 - 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. 
-- Debian: Allowing users to install stuff which affects only them. 
+
 
 #### Target groups and strong environments
 
@@ -107,19 +107,6 @@ http://sourceforge.net/mailarchive/message.php?msg_name=20080909073154.GB821%40a
 monologue at the end... I really should put these ideas into my blog.)"*
 
 
-#### Debian: Allowing users to install stuff which affects only them. 
-
-This can be done in two ways: 
-
-- changeroot + unionfs (which is also possible in Linux)
-- a translator on / or /bin set by root which selects a different filesystem view based on which user accesses it. 
-
-Both solutions might need a special translator on the package database which makes 
-sure that dpkg of each user is aware of the changes root does. 
-
-> [15:20] <antrik> as I said, I'm not sure what is the better solution. both have advantages
-> [15:22] <ArneBab> antrik: But regardless of what is teh better solution: This is a damn nice niche!
-
 
 #### Nice features
 
@@ -152,11 +139,12 @@ aren't possible.
 	* 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. 
+	* bind any filesystem at any place in the directory tree (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' (needs transparent ftp bound to 'ftp:'). 
+	* Install deb-packages from an ftp server via 'dpkg -iO ftp://foo/bar/*.deb'
+	* remount a filesystem readonly as regular user: fsysopts /foo -r
 
 - Having a complete GNU System (but not yet on every hardware, and only about half the software Debian offers has been ported). 
 
@@ -168,28 +156,22 @@ aren't possible.
 
 - Tinkering for fun - need documentation about the fun things which can be done. 
 
-- 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. 
-
 ### 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. 
+- subhurds for regular users
+	* 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. 
+	* subusers
+	* "subdo":  
+	  # Example: Let a virus run free, but any effect vanishes  
+	  # once the subhurd closes.  
+	  $ subdo --no-lasting-changes ./virus
 
 - 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 
@@ -201,20 +183,22 @@ between computers). Maybe this should be placed in "need a lot of coding".
 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'). 
 
-- Debian: Allowing users to install stuff which affects only them.
-
-- smbfs: we'd need a servermux and sharemux there as well, in order to be able to cd 
-/smb://host/share/dir
-
-- provide devices to userspace with some restrictions, i.e. provide a specialized 
-device so user translators can access it. The providing translator can set 
-restrictions on values which can be passed so safe but almost arbitrary device access 
-would be possible. 
-
-
 ### Need a lot of coding or fundamental changes
 
 - Effective resource management (For example via Viengoos on which Neal Walfield is