Note that Fuschia is a microkernel. Does it provide a filesystem
interface? It's possible this wouldn't be adopted simply because it's
not in scope for the core system, and it's something that a system
module could implement without requiring maintenance.


2017-09-14 17:53 GMT-07:00 Marshall Conover <>:
> Aleksandar -
>> I have a honest feeling you will end up as roadkill with this sort of
>> approach.
> This is my concern as well. Combined with the fact the OS only has an IRC
> channel (which I'm constantly concerned I'm wearing out my welcome in) and
> the tepid response so far, part of the reason I came to 9fans was help
> refining my approach.
> Your paragraph is apt and inspiring to me, but I'm beginning to think they
> may just not be interested in outside code or approaches at this point in
> time - which is rough, because now seems like the time to make a decision
> like employing binds and union mounts. To put it simply, I'm not sure I have
> the leverage or opening to really put forth the idea - especially
> considering this is, y'know, their job, and they've got shit to do. But,
> I'll try and keep in mind that I should argue not just from "here's some
> places it would make things simple," but "this is how things should work. It
> is detrimental to not have this feature, and not having it, in sum, will
> waste millions of man-hours for the people who use this operating system,
> the same way it's wasted lifetimes not being in Mac or Windows."
> I don't want to give up on this, though. I honestly do believe it's the
> right thing to do - and I want them to see that as well. I'm just trying to
> figure out how to make the pitch that's needed, and I appreciate your help.
> Micah -
> thanks for your use cases. I'll keep these in mind. I had thought about
> bringing up getting rid of $PATH and the others, but I wasn't sure I could
> make a clean argument for why union mounting the directories was better than
> just having a path. This will be a big help in allowing me to argue that
> this is the 'correct' way to handle having to source information from
> multiple paths, when you may or may not want any individual folder in the
> current set.
> Thanks again, all. I'm going to keep working on getting together a bigger
> set of changes, and maybe staking my claim on a pull request. I'm not sure
> there's any other way to really get an 'audience.'
> Thanks!
> Marshall
> On Thu, Sep 14, 2017 at 5:40 PM Marshall Conover <>
> wrote:
>> Hmm... I had thought of parallel installs, but A/B testing in order to
>> maximize ad revenue is a brilliant application.
>> I have also been thinking about the potential for seamless instillation
>> and startup of applications - updates to app can be installed in the
>> background to a bound /tmp directory, with that directories' location
>> journaled; meanwhile, the application continues running for the user. The
>> updated application then begins in the background - using the /tmp directory
>> - and loads everything the user is currently doing in the old. Then, it
>> prompts the user to 'restart' the application, during which it plays an ad
>> for the amount of time a user would usually expect a restart to take - with
>> the benefit of being able to use CPU-intensive eye-tracking software to
>> watch the user's interest in ads. The amount of time could also be A/B
>> tested per application. At some point when the user is not using the
>> application, the journaled /tmp location can be copied over to the correct
>> install path. I'm not quite sure how to inconvenience the user further than
>> they normally are with this method, however...
>> Thanks for all the insightful advice!
>> Marshall
>> On Thu, Sep 14, 2017 at 3:55 PM Marshall Conover <>
>> wrote:
>>> 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 <>
>>> 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 (, 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