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 >>> >>
