diff options
-rw-r--r-- | community/weblogs/ArneBab/niches_for_the_hurd.mdwn | 74 |
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 |