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.
--dho 2017-09-14 17:53 GMT-07:00 Marshall Conover <marzhal...@gmail.com>: > 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 <marzhal...@gmail.com> > 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 <marzhal...@gmail.com> >> 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 <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
