From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Marshall Conover Date: Sun, 17 Sep 2017 21:06:32 +0000 Message-ID: To: "9fans@9fans.net" <9fans@9fans.net> Content-Type: multipart/alternative; boundary="94eb2c0d2944c7cc02055969002b" Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c19cb26c-ead9-11e9-9d60-3106f5b1d025 --94eb2c0d2944c7cc02055969002b Content-Type: text/plain; charset="UTF-8" BLS - thanks for the wise words. What you've said has inspired me to consider moving my efforts into user-space, and trying to create the entire environment I want instead of just a piece of that environment, so that I can achieve the simplicity you describe - instead of mixing approaches with the environment the fuchsia developers currently plan. Giacomo - While thinking on your advice, I realized most of what I've done so far is just a fix for a bug in their current exposed version of the 'bind' command. If I submit that fix and some tests for it, I should be able to then create union mounts and full-featured binds myself, in user-space, by creating an additional fileserver that is able to return merged directory entries from multiple sources, creating an entry in that fileserver when the user asks to bind or union mount directories or files, and binding the paths in the fuchsia namespace to the entries in that fileserver. It'll still be a bit clunky due to their restriction of processes being unable to modify their own namespace - so, I'll have to start a new process for the desired bind/mount operations to apply - but in the mean time, it'll be better than nothing (and I may just keep a parallel branch with the four-line hack I fudged together that removes that restriction). And in the mean time, I'll be looking for things to contribute to fuchsia unrelated to that pursuit. Thanks again, all. I appreciate you all taking a moment to help straighten this dunce out. :) (even you, khm) Marshall On Fri, Sep 15, 2017 at 7:59 AM Marshall Conover wrote: > > But you are not your contributions, and since you freely agreed to > donate your time for free, they don't owe you anything. > > Yeah, I've gone into this fully knowing they have no obligation to respond > - and to be honest, even if I were a team member, they'd still have no > obligation; I'm not leadership. That's why I've been trying to figure out a > compelling reason, but I think you have it right with: > > > If you want to contribute to Fuchsia (or any similarly leaded project), > start by writing tests, reviewing code, fixing small bugs, implementing the > interfaces they designed and so on... they will thanks you a lot for your > free and (really) useful work. > > I'll start digging in to see what I can do. I think I jumped the gun by > trying to contribute a feature, and you're right that they're bound to > appreciate bug fixes, test implementations, etc. > > Thanks for the help. > > Marshall > > On Thu, Sep 14, 2017 at 10:01 PM Marshall Conover > wrote: > >> > Note that Fuschia is a microkernel. Does it provide a filesystem >> interface? >> >> Hi dho! Yes, it does, and the code I've modified to introduce the ability >> to perform bind is a modification of the rudimentary binding their >> interface already provided (top-level directory binds only, previously, >> with any bind attempting to go more than one directory deep breaking >> things), which they had implemented only as a method of testing a few >> namespace features. The code changes are pretty much entirely in the >> kernel, and are pretty small. >> >> That said, taking the long view, my current approach only extended their >> current method - I'm thinking I may have to instead change some more >> fundamental things in order to get union mounts working, such as creating a >> per-namespace unions directory that holds the file descriptors for >> namespace union filesystem nodes point to - which is what I'd like their >> input on. I have noticed, though, that in their github repo (previously I >> had been grabbing straight from the google repo), they have a README that >> says they're not currently accepting more than bug changes, which might >> partially explain the majority radio silence. While that decision hasn't >> been mentioned directly in response to me on IRC, I'm thinking I may just >> have to maintain a branch until it's exclusively opened up for more >> substantial user contributions, whenever that is. :/ >> >> Thanks! >> >> Marshall >> >> On Thu, Sep 14, 2017 at 8:53 PM Marshall Conover >> wrote: >> >>> 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 < >>>>> marzhall.o@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 >>>>>> >>>>> --94eb2c0d2944c7cc02055969002b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BLS - thanks for the wise words. What you've said has = inspired me to consider moving my efforts into user-space, and trying to cr= eate the entire environment I want instead of just a piece of that environm= ent, so that I can achieve the simplicity you describe - instead of mixing = approaches with the environment the fuchsia developers currently plan.=C2= =A0

Giacomo - While thinking on your advice, I realized = most of what I've done so far is just a fix for a bug in their current = exposed version of the 'bind' command. If I submit that fix and som= e tests for it, I should be able to then create union mounts and full-featu= red binds myself, in user-space, by creating an additional fileserver that = is able to return merged directory entries from multiple sources, creating = an entry in that fileserver when the user asks to bind or union mount direc= tories or files, and binding the paths in the fuchsia namespace to the entr= ies in that fileserver. It'll still be a bit clunky due to their restri= ction of processes being unable to modify their own namespace - so, I'l= l have to start a new process for the desired bind/mount operations to appl= y - but in the mean time, it'll be better than nothing (and I may just = keep a parallel branch with the four-line hack I fudged together that remov= es that restriction). And in the mean time, I'll be looking for things = to contribute to fuchsia unrelated to that pursuit.

Thanks again, all. I appreciate you all taking a moment to help straighte= n this dunce out. :)

(even you, khm)
Marshall

On Fri, Sep 15, 2017 at 7:59 AM Marshall Conover <marzhall.o@gmail.com> wrote:
> But you are not your contribu= tions, and since you freely agreed to donate your time for free, they don&#= 39;t owe you anything.

Yeah, I've gone into this ful= ly knowing they have no obligation to respond - and to be honest, even if I= were a team member, they'd still have no obligation; I'm not leade= rship. That's why I've been trying to figure out a compelling reaso= n, but I think you have it right with:

> If you want to contrib= ute to Fuchsia (or any similarly leaded project), start by writing tests, r= eviewing code, fixing small bugs, implementing the interfaces they designed= and so on... they will thanks you a lot for your free and (really) useful = work.

I'll start digging in to see what I can do. = I think I jumped the gun by trying to contribute a feature, and you're = right that they're bound to appreciate bug fixes, test implementations,= etc.

Thanks for the help.
=

Marshall

On Thu, Sep 14, 201= 7 at 10:01 PM Marshall Conover <marzhall.o@gmail.com> wrote:
> Note that Fuschia is a microkernel= . Does it provide a filesystem interface?

Hi dho! Yes, it does, and = the code I've modified to introduce the ability to perform bind is a mo= dification of the rudimentary binding their interface already provided (top= -level directory binds only, previously, with any bind attempting to go mor= e than one directory deep breaking things), which they had implemented only= as a method of testing a few namespace features. The code changes are pret= ty much entirely in the kernel, and are pretty small.

Th= at said, taking the long view, my current approach only extended their curr= ent method - I'm thinking I may have to instead change some more fundam= ental things in order to get union mounts working, such as creating a per-n= amespace unions directory that holds the file descriptors for namespace uni= on filesystem nodes point to - which is what I'd like their input on. I= have noticed, though, that in their github repo (previously I had been gra= bbing straight from the google repo), they have a README that says they'= ;re not currently accepting more than bug changes, which might partially ex= plain the majority radio silence. While that decision hasn't been menti= oned directly in response to me on IRC, I'm thinking I may just have to= maintain a branch until it's exclusively opened up for more substantia= l user contributions, whenever that is. :/

Thanks!=

Marshall

On Thu, Sep 14, 2017 at 8:53 PM M= arshall Conover <marzhall.o@gmail.com> wrote:
Aleksandar -

> I have a honest feelin= g 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.=C2=A0

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 i= s 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 lever= age or opening to really put forth the idea - especially considering this i= s, 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 p= laces it would make things simple," but "this is how things shoul= d work. It is detrimental to not have this feature, and not having it, in s= um, 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.

Mic= ah -=C2=A0

thanks for your use cases. I'll kee= p these in mind. I had thought about bringing up getting rid of $PATH and t= he others, but I wasn't sure I could make a clean argument for why unio= n 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= 9;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 <marzhall.o@gmail.com> w= rote:
Hmm... I had= thought of parallel installs, but A/B testing in order to maximize ad reve= nue is a brilliant application.

I have also been thinkin= g about the potential for seamless instillation and startup of applications= - updates to app can be installed in the background to a bound /tmp direct= ory, with that directories' location journaled; meanwhile, the applicat= ion continues running for the user. The updated application then begins in = the background - using the /tmp directory - and loads everything the user i= s 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 use= r would usually expect a restart to take - with the benefit of being able t= o 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 som= e point when the user is not using the application, the journaled /tmp loca= tion 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 met= hod, however...

Thanks for all the insightful advi= ce!

Marshall
On Thu, Sep 14, 2017 at 3:55 P= M Marshall Conover <marzhall.o@gmail.com> wrote:
khm - Unfortunately, that would conflict with the b= rowsing model I want to propose once I've proven my worth - in which th= e 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 <marz= hall.o@gmail.com> wrote:
Hi All!

=C2=A0 =C2=A0I've been explori= ng 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 sup= porting it by default in their system libraries. I've made some progres= s on adding it (htt= ps://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 name= space filesystem. As someone who's neither on their team nor an employe= e 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 scena= rios 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 d= evelopment on it, by using a bind to redirect the development dll to the in= stall's dll in the process I'm developing in; and the other an exam= ple of when a bind would just be convenient, such as a certain process need= ing python2 instead of python3 on a system which defaults to python 3, and = have scripts that reference #/bin/python.

So, I= 9;d like to hear the community's thoughts on other uses of bind. I thin= k they'd be useful both for making my case for bind, and in thinking ab= out my continuing implementation of the command. I also want to implement u= nion 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
--94eb2c0d2944c7cc02055969002b--