khm - Unfortunately, that would conflict with the browsing model I want to
propose once I've proven my worth - in which the user emails a daemon with
the site they want, which the daemon then wgets, forwards to them, and
opens up emacs.

Thanks!

Marshall

On Thu, Sep 14, 2017 at 10:58 AM Marshall Conover <marzhal...@gmail.com>
wrote:

> Hi All!
>
>    I've been exploring the Fuchsia operating system, and while they have
> per-process namespaces, they don't have a utility like plan 9's bind, nor a
> method of supporting it by default in their system libraries. I've made
> some progress on adding it (https://imgur.com/HELWbrQ), but enthusiasm
> for the concept seems lukewarm, and I'm coming to the point where I feel
> I'm going to need to make a strong argument for why it should be a feature
> of their per-process namespace filesystem. As someone who's neither on
> their team nor an employee of google, I feel that I'm going to need to make
> a damn good argument - and I'd very much like to, as it really, *really* is
> something I'd like to have easily within reach in a modern OS, and it seems
> like such a low-hanging fruit of a feature.
>
> I have two scenarios currently I feel make a strong argument for the
> inclusion of bind: one is running tests on an install of a product while
> still being able to do development on it, by using a bind to redirect the
> development dll to the install's dll in the process I'm developing in; and
> the other an example of when a bind would just be convenient, such as a
> certain process needing python2 instead of python3 on a system which
> defaults to python 3, and have scripts that reference #/bin/python.
>
> So, I'd like to hear the community's thoughts on other uses of bind. I
> think they'd be useful both for making my case for bind, and in thinking
> about my continuing implementation of the command. I also want to implement
> union mounting in the future (which I can get very-close-to-being-free with
> my changes for umount), but right now bind is my focus.
>
> Thanks for your time.
>
> Marshall
>

Reply via email to