From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 From: Marshall Conover Date: Thu, 14 Sep 2017 14:58:02 +0000 Message-ID: To: "9fans@9fans.net" <9fans@9fans.net> Content-Type: multipart/alternative; boundary="001a114b12dc6bd52005592781fb" Subject: [9fans] The Case for Bind Topicbox-Message-UUID: c10e0076-ead9-11e9-9d60-3106f5b1d025 --001a114b12dc6bd52005592781fb Content-Type: text/plain; charset="UTF-8" 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 --001a114b12dc6bd52005592781fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All!

=C2=A0 =C2=A0I've been expl= oring the Fuchsia operating system, and while they have per-process namespa= ces, 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 prog= ress on adding it (https://imgur.com/= HELWbrQ), but enthusiasm for the concept seems lukewarm, and I'm co= ming to the point where I feel I'm going to need to make a strong argum= ent for why it should be a feature of their per-process namespace filesyste= m. 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 f= ruit of a feature.

I have two scenarios currently = I feel make a strong argument for the inclusion of bind: one is running tes= ts on an install of a product while still being able to do development on i= t, 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 b= ind would just be convenient, such as a certain process needing python2 ins= tead of python3 on a system which defaults to python 3, and have scripts th= at reference #/bin/python.

So, I'd like to hea= r 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 continui= ng implementation of the command. I also want to implement union mounting i= n the future (which I can get very-close-to-being-free with my changes for = umount), but right now bind is my focus.

Thanks fo= r your time.

Marshall
--001a114b12dc6bd52005592781fb-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 14 Sep 2017 08:11:55 -0700 From: Kurt H Maier To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20170914151155.GC25914@wopr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c1158530-ead9-11e9-9d60-3106f5b1d025 On Thu, Sep 14, 2017 at 02:58:02PM +0000, Marshall Conover wrote: > > 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 Suggest to them that the namespace status could be exposed to javascript and used to enhance the accuracy of browser fingerprinting. Alternately, if you could come up with a way to shove ads into the output of ns, they'd probably implement it for you. khm From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Marshall Conover Date: Thu, 14 Sep 2017 19:55:21 +0000 Message-ID: To: "9fans@9fans.net" <9fans@9fans.net> Content-Type: multipart/alternative; boundary="f403045f4c8eb064a005592ba87e" Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c1222b14-ead9-11e9-9d60-3106f5b1d025 --f403045f4c8eb064a005592ba87e Content-Type: text/plain; charset="UTF-8" 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 (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 > --f403045f4c8eb064a005592ba87e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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, forwa= rds to them, and opens up emacs.

Thanks!

<= /div>
Marshall

On Thu, Sep 14, 2017 at 10:58 AM Marshall Conover <marzhall.o@gmail.com> wrote:
Hi All!

=C2=A0 = =C2=A0I'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&= #39;m going to need to make a strong argument for why it should be a featur= e of their per-process namespace filesystem. As someone who's neither o= n their team nor an employee of google, I feel that I'm going to need t= o 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 whi= le still being able to do development on it, by using a bind to redirect th= e development dll to the install's dll in the process I'm developin= g in; and the other an example of when a bind would just be convenient, suc= h as a certain process needing python2 instead of python3 on a system which= defaults to python 3, and have scripts that reference #/bin/python.
<= div>
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 f= or 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 ver= y-close-to-being-free with my changes for umount), but right now bind is my= focus.

Thanks for your time.

Marshall
--f403045f4c8eb064a005592ba87e-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 14 Sep 2017 13:25:23 -0700 From: Kurt H Maier To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20170914202523.GA50485@wopr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c1281f2e-ead9-11e9-9d60-3106f5b1d025 On Thu, Sep 14, 2017 at 07:55:21PM +0000, 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. There's no reason you can't attach the fingerprint data as part of a MIME message part. You're basically taking money out of Googlers' pockets with this refusal to focus on the web. Are you sure you can live with yourself, this way? Anyway, the common problem with both of your use cases is that it focuses on making programmers' lives easier. If you want to be taken seriously by a Silicon Valley company, you should focus on making users' lives harder, instead. For instance, with bind, Google could install different versions of application packages in parallel on unsuspecting customers' devices, then do A/B testing to track ad engagement. Google employees LOVE A/B testing; this is a sure-fire pitch. khm From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Marshall Conover Date: Thu, 14 Sep 2017 21:40:16 +0000 Message-ID: To: "9fans@9fans.net" <9fans@9fans.net> Content-Type: multipart/alternative; boundary="001a1148fc74ec3f0305592d1f85" Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c12e3b8e-ead9-11e9-9d60-3106f5b1d025 --001a1148fc74ec3f0305592d1f85 Content-Type: text/plain; charset="UTF-8" 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 (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 >> > --001a1148fc74ec3f0305592d1f85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 instillatio= n and startup of applications - updates to app can be installed in the back= ground to a bound /tmp directory, with that directories' location journ= aled; meanwhile, the application continues running for the user. The update= d application then begins in the background - using the /tmp directory - an= d 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 - wit= h the benefit of being able to use CPU-intensive eye-tracking software to w= atch the user's interest in ads. The amount of time could also be A/B t= ested per application. At some point when the user is not using the applica= tion, 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 th= ey normally are with this method, however...

Thank= s for all the insightful advice!

Marshall

On Thu, Sep 14, 2017 at = 3:55 PM Marshall Conover <marzha= ll.o@gmail.com> wrote:
khm - Unfortunately, that would conflict with the browsing mode= l I want to propose once I've proven my worth - in which the user email= s a daemon with the site they want, which the daemon then wgets, forwards t= o 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!

=C2=A0 =C2=A0I've been exploring the Fuchs= ia operating system, and while they have per-process namespaces, they don&#= 39;t have a utility like plan 9's bind, nor a method of supporting it b= y default in their system libraries. I've made some progress on adding = it (https://imgur.c= om/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 ar= gument for why it should be a feature of their per-process namespace filesy= stem. 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 h= ave easily within reach in a modern OS, and it seems like such a low-hangin= g fruit of a feature.

I have two scenarios current= ly 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 o= n 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 conti= nuing implementation of the command. I also want to implement union mountin= g in the future (which I can get very-close-to-being-free with my changes f= or umount), but right now bind is my focus.

Thanks= for your time.

Marshall
--001a1148fc74ec3f0305592d1f85-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 15 Sep 2017 00:22:26 +0200 From: Aleksandar Kuktin To: 9fans@9fans.net Message-ID: <20170915002226.3ae46f72@ikilid> In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/25AF.CbXJ7O2dGPsCHJ8nTN"; protocol="application/pgp-signature" Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c138211c-ead9-11e9-9d60-3106f5b1d025 --Sig_/25AF.CbXJ7O2dGPsCHJ8nTN Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >On Thu, 14 Sep 2017 14:58:02 +0000 >Marshall Conover wrote: > 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. I have a honest feeling you will end up as roadkill with this sort of approach. You are discussing individual specific use cases; accepting your argument relies on the other party being imaginative enough to independently see the value of the proposal. Generally speaking, if the person has not already seen the value of an idea, they are probably not going to have an epiphany after you throw them some examples. Instead, try discussing the correctness of the premise, and how it is steeped in fundamental value. Try: "The ability to binding filesystem elements between different paths of a filesystem is of critical importance to the operating system flexibility and usability. While many current users, brought up on Windows, may lack the vision of the features usability, with the continued refinement of public expertise in all matters IT, there will mature the opinion that binding is a right-of-entry feature, with operating systems lacking it being summarily dismissed." There. If they don't buy that, then their vision is flawed, the project mistargeted and governance found lacking. And they will fail. You don't want to waste your time and energy on a doomed project. --=20 Svi moji e-mailovi su kriptografski potpisani. Proverite ih. All of my e-mails are cryptographically signed. Verify them. -- You don't need an AI for a robot uprising. Humans will do just fine. -- --Sig_/25AF.CbXJ7O2dGPsCHJ8nTN Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJZuwEiAAoJEKa4cgqNx31/Y2kP/iKCXLWjfvshJVq1c5RoiD6d CFjT9VDY6w8EYMCaOHaVm1LaRI+CTXOO2k1IAGiHK5U+JknhDtonB6g7hK0BSwhb wyFIDcbLOoNpaOh0sIfUD3g9zfBKfB9vzf980nRmlKnuOVnNtFM0YnwzGXdUxLoh mtwKeZRv5YzCQhedK4HvZXiQR1lkZztVMdc9QfnrARkvqOppEAp/oAts6yyIpkxK x40feXupEdmTrJWHxzI3Pu4bi+r8WJa6tomt1dUMivc8FWUv6etL9CoNLFGDXDEr v5KZzJMONVYmv4K1rS0g5DOKlVPJgtEr7179+w/n+Io5r3oUH7smIr5TVDA5ax2g BBM0dPyE1PcuKn0DfjFnin8oOok2kriBrZWdvqT7IKW8qll56rc4BIzO1y5osKiW mcDU2ztCX8e8OiC+LU83ashju8TspwUSKHxZ3kNI4WWxu+2X3JeON/uKdACg5/wo K2IzesnyOfoyYbItoOf+jcpKLIxhhS5FFXuFwWqMPkp2QN31vSHFY9YQAqDHwvo9 y33va0Jhlp1W1KBkk3ZgsvJoSPqrlwDA/KFFCey630QTVxMxi+0Y11vIM2xf6ECy Jhzz/CA8t+y7A2/EYJPY1pSWLT3V8Ustr8g4yBcf4cpwoRZzWnEoLbG9t7/gp8ZP leJEfB8FJ7mgfgS8k0IP =nNtC -----END PGP SIGNATURE----- --Sig_/25AF.CbXJ7O2dGPsCHJ8nTN-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: micah@classroomsystems.com (Micah Stetson) Date: Thu, 14 Sep 2017 16:46:07 -0700 Subject: [9fans] The Case for Bind In-Reply-To: References: Message-ID: Topicbox-Message-UUID: c165455c-ead9-11e9-9d60-3106f5b1d025 It's been years since I've used Plan 9, and I very-much miss bind and union mount. For me, the big benefit of them is that you can hard-code well-known names for certain files or directories, and yet you can override those paths as needed, without having to set a bunch of environment variables and worry about whether the program you're dealing with checks the environment variables. Real-world example: I maintain a commercial program that uses embedded Python and is run on customer servers over-which I have little or no control. I don't want my program to use the system Python libraries, if there are any. But in order to work in many different situations, including for testing while uninstalled, Python does a whole bunch of hunting around the system to find its libraries. This hunt is affected by the PYTHONHOME and PYTHONPATH environment variables, as well as code in site.py, and C initialization code with some hard-coded paths. To work around this, I set a flag that advises Python to ignore the environment, I overwrite the hard-coded paths (in spite of warnings in the Python docs) before initializing Python, and I supply my own replacement site.py. I think this isolates my program from the system Python, but it's complicated and there's probably some corner case I've missed. If the OS had bind and union mounts, then Python could always look for its libraries in /lib/python. Need a different library? bind ./lib /lib/python. There would be no need for PYTHONHOME or PYTHONPATH or sys.path or the searches in site.py and the C initialization code. I would simply bind my own library into the well-known location, and I would never have to worry about some bug in Python accidentally loading the system library. Off the top of my head, bind and union mount can eliminate the need for all of these common environment variables: PATH, MANPATH, LD_LIBRARY_PATH, PKGCONFIG, PYTHONPATH (as well as GOPATH, etc), TMPDIR, PAGER, EDITOR, and surely others. Namespace manipulation is not just an alternative to environment variables in cases like these; it's better because it eliminates code. Every program that wants to support one of these environment variables must contain code to do so. With namespace manipulation, they don't need any code, they just open() or exec() a well-known path. Namespace manipulation works to reconfigure any path name for any program, without the program's author having to provide a configuration hook of any kind. Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Marshall Conover Date: Fri, 15 Sep 2017 00:53:52 +0000 Message-ID: To: "9fans@9fans.net" <9fans@9fans.net> Content-Type: multipart/alternative; boundary="001a114923463f7d0d05592fd427" Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c14225e0-ead9-11e9-9d60-3106f5b1d025 --001a114923463f7d0d05592fd427 Content-Type: text/plain; charset="UTF-8" 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 (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 >>> >> --001a114923463f7d0d05592fd427 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Aleksandar -

> I have a honest feeling yo= u will end up as roadkill with this sort of approach.

Th= is is my concern as well. Combined with the fact the OS only has an IRC cha= nnel (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 i= nterested in outside code or approaches at this point in time - which is ro= ugh, because now seems like the time to make a decision like employing bind= s 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 place= s it would make things simple," but "this is how things should wo= rk. 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 syst= em, the same way it's wasted lifetimes not being in Mac or Windows.&quo= t;

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 -= =C2=A0

thanks for your use cases. I'll keep th= ese in mind. I had thought about bringing up getting rid of $PATH and the o= thers, but I wasn't sure I could make a clean argument for why union mo= unting the directories was better than just having a path. This will be a b= ig help in allowing me to argue that this is the 'correct' way to h= andle 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 bi= gger 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 <marzh= all.o@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 an= d startup of applications - updates to app can be installed in the backgrou= nd to a bound /tmp directory, with that directories' location journaled= ; meanwhile, the application continues running for the user. The updated ap= plication then begins in the background - using the /tmp directory - and lo= ads 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 th= e 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 teste= d 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 pat= h. I'm not quite sure how to inconvenience the user further than they n= ormally are with this method, however...

Thanks fo= r all the insightful advice!

Marshall

On Th= u, Sep 14, 2017 at 3:55 PM Marshall Conover <marzhall.o@gmail.com> wrote:
khm - Unfortunately, that = would conflict with the browsing model I want to propose once I've prov= en my worth - in which the user emails a daemon with the site they want, wh= ich the daemon then wgets, forwards to them, and opens up emacs.

Thanks!

Marshall

On Thu, Sep 14, 2= 017 at 10:58 AM Marshall Conover <marzhall.o@gmail.com> wrote:
Hi All!

=C2=A0 =C2= =A0I've been exploring the Fuchsia operating system, and while they hav= e per-process namespaces, they don't have a utility like plan 9's b= ind, nor a method of supporting it by default in their system libraries. I&= #39;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 o= f their per-process namespace filesystem. As someone who's neither on t= heir team nor an employee of google, I feel that I'm going to need to m= ake a damn good argument - and I'd very much like to, as it really, *re= ally* 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 th= e 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 d= evelopment dll to the install's dll in the process I'm developing i= n; and the other an example of when a bind would just be convenient, such a= s a certain process needing python2 instead of python3 on a system which de= faults to python 3, and have scripts that reference #/bin/python.

So, I'd like to hear the community's thoughts on ot= her 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-c= lose-to-being-free with my changes for umount), but right now bind is my fo= cus.

Thanks for your time.

Marshall
--001a114923463f7d0d05592fd427-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: "Devon H. O'Dell" Date: Thu, 14 Sep 2017 18:14:06 -0700 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c149541e-ead9-11e9-9d60-3106f5b1d025 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 : > 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 (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 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Marshall Conover Date: Fri, 15 Sep 2017 02:01:51 +0000 Message-ID: To: "9fans@9fans.net" <9fans@9fans.net> Content-Type: multipart/alternative; boundary="001a1148fc746447fa055930c7dc" Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c15c5744-ead9-11e9-9d60-3106f5b1d025 --001a1148fc746447fa055930c7dc Content-Type: text/plain; charset="UTF-8" > 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 >>> 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 >>>> >>> --001a1148fc746447fa055930c7dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Note that Fuschia is a microkernel. Does it provide a= filesystem interface?

Hi dho! Yes, it does, and the code I've m= odified to introduce the ability to perform bind is a modification of the r= udimentary binding their interface already provided (top-level directory bi= nds only, previously, with any bind attempting to go more than one director= y deep breaking things), which they had implemented only as a method of tes= ting 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 ord= er to get union mounts working, such as creating a per-namespace unions dir= ectory that holds the file descriptors for namespace union filesystem nodes= point to - which is what I'd like their input on. I have noticed, thou= gh, 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 a= ccepting more than bug changes, which might partially explain the majority = radio silence. While that decision hasn't been mentioned directly in re= sponse 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 contribution= s, whenever that is. :/

Thanks!

Marshall

= On Thu, Sep 14, 2017 at 8:53 PM Marshall Conover <marzhall.o@gmail.com> 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 cam= e to 9fans was help refining my approach.=C2=A0

Yo= ur paragraph is apt and inspiring to me, but I'm beginning to think the= y 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 con= sidering this is, y'know, their job, and they've got shit to do. Bu= t, I'll try and keep in mind that I should argue not just from "he= re's some places it would make things simple," but "this is h= ow 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 -=C2=A0

thanks for your use case= s. 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 argume= nt for why union mounting the directories was better than just having a pat= h. This will be a big help in allowing me to argue that this is the 'co= rrect' 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 ge= tting together a bigger set of changes, and maybe staking my claim on a pul= l 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 <= marzhall.o@gmail.= com> wrote:
Hmm... I had thought of parallel installs, but A/B testing in order to max= imize 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 boun= d /tmp directory, with that directories' location journaled; meanwhile,= the application continues running for the user. The updated application th= en begins in the background - using the /tmp directory - and loads everythi= ng the user is currently doing in the old. Then, it prompts the user to = 9;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= 9;s interest in ads. The amount of time could also be A/B tested per applic= ation. At some point when the user is not using the application, the journa= led /tmp location can be copied over to the correct install path. I'm n= ot quite sure how to inconvenience the user further than they normally are = with this method, however...

Thanks for all the in= sightful advice!

Marshall

On Thu, Sep 14, 2= 017 at 3:55 PM Marshall Conover <marzhall.o@gmail.com> wrote:
khm - Unfortunately, that would confli= ct 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 daem= on then wgets, forwards to them, and opens up emacs.

Tha= nks!

Marshall
On Thu, Sep 14, 2017 at 10:58= AM Marshall Conover <marzhall.o@gmail.com> wrote:
Hi All!

=C2=A0 =C2=A0I've = been exploring the Fuchsia operating system, and while they have per-proces= s namespaces, they don't have a utility like plan 9's bind, nor a m= ethod 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 see= ms 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 no= r an employee of google, I feel that I'm going to need to make a damn g= ood argument - and I'd very much like to, as it really, *really* is som= ething I'd like to have easily within reach in a modern OS, and it seem= s like such a low-hanging fruit of a feature.

I ha= ve 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 d= ll to the install's dll in the process I'm developing in; and the o= ther 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 py= thon 3, and have scripts that reference #/bin/python.

<= div>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-bein= g-free with my changes for umount), but right now bind is my focus.

Thanks for your time.
Marshall
--001a1148fc746447fa055930c7dc-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: giacomo@tesio.it (Giacomo Tesio) Date: Fri, 15 Sep 2017 11:45:31 +0200 Subject: [9fans] The Case for Bind In-Reply-To: References: Message-ID: Topicbox-Message-UUID: c1744db8-ead9-11e9-9d60-3106f5b1d025 2017-09-14 16:58 GMT+02:00 Marshall Conover : > ...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... > 2017-09-15 2:53 GMT+02:00 Marshall Conover : > 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. > IMHO, there is a wise suggestion hidden in khm jokes. It's pretty naive to think that contributing to open source projects leaded by a large company (even just informally, by its employees) you can pursue these kind of values. Your contributions might be welcomed for a while, if they align with their current objectives. But you are not your contributions, and since you freely agreed to donate your time for free, they don't owe you anything. As long as they lead the project, the choice of open source license is just marketing: there's neither openness nor freedom there. Think about this for a while: if Google (or Microsoft, or...) would care about wasted man-hours (or wasted gigawatts) do you think they would have turned HTML browsers to what they are now? 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. And as long as you align with their purposes they will threat you as a peer. It's not that those developers are evil but there's a large amount of politics inside these companies they have to cope with. And ultimately, the companies that pay them are not pursuing values, just long term profits. Giacomo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Marshall Conover Date: Fri, 15 Sep 2017 11:59:24 +0000 Message-ID: To: "9fans@9fans.net" <9fans@9fans.net> Content-Type: multipart/alternative; boundary="001a1148fc74645065055939208b" Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c16d62fa-ead9-11e9-9d60-3106f5b1d025 --001a1148fc74645065055939208b Content-Type: text/plain; charset="UTF-8" > 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 >>>> 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 >>>>> >>>> --001a1148fc74645065055939208b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> But you are not your contributions, and since you fre= ely 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, the= y'd still have no obligation; I'm not leadership. That's why I&= #39;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 s= imilarly leaded project), start by writing tests, reviewing code, fixing sm= all 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 b= ound to appreciate bug fixes, test implementations, etc.

Thanks for the help.

Marshall

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

Hi dho! Yes, it does, and the c= ode I've modified to introduce the ability to perform bind is a modific= ation of the rudimentary binding their interface already provided (top-leve= l directory binds only, previously, with any bind attempting to go more tha= n one directory deep breaking things), which they had implemented only as a= method of testing a few namespace features. The code changes are pretty mu= ch entirely in the kernel, and are pretty small.

That sa= id, taking the long view, my current approach only extended their current m= ethod - 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-namesp= ace unions directory that holds the file descriptors for namespace union fi= lesystem 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 n= ot 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 main= tain a branch until it's exclusively opened up for more substantial use= r contributions, whenever that is. :/

Thanks!

Marshall

On Thu, Sep 14, 2017 at 8:53 PM Marsha= ll Conover <ma= rzhall.o@gmail.com> wrote:
<= div dir=3D"ltr">Aleksandar -

> I have a honest feeling you= will end up as roadkill with this sort of approach.

Thi= s is my concern as well. Combined with the fact the OS only has an IRC chan= nel (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 in= terested in outside code or approaches at this point in time - which is rou= gh, 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 o= r opening to really put forth the idea - especially considering this is, y&= #39;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 wor= k. It is detrimental to not have this feature, and not having it, in sum, w= ill waste millions of man-hours for the people who use this operating syste= m, the same way it's wasted lifetimes not being in Mac or Windows."= ;

I don't want to give up on this, though. I h= onestly 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&= #39;s needed, and I appreciate your help.

Micah -= =C2=A0

thanks for your use cases. I'll keep th= ese in mind. I had thought about bringing up getting rid of $PATH and the o= thers, but I wasn't sure I could make a clean argument for why union mo= unting the directories was better than just having a path. This will be a b= ig help in allowing me to argue that this is the 'correct' way to h= andle 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 bi= gger 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 <marzhall.o@gmail.com> wrote:<= br>
Hmm... I had thoug= ht of parallel installs, but A/B testing in order to maximize ad revenue is= a brilliant application.

I have also been thinking abou= t the potential for seamless instillation and startup of applications - upd= ates to app can be installed in the background to a bound /tmp directory, w= ith that directories' location journaled; meanwhile, the application co= ntinues running for the user. The updated application then begins in the ba= ckground - using the /tmp directory - and loads everything the user is curr= ently 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 woul= d 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 poin= t when the user is not using the application, the journaled /tmp location c= an be copied over to the correct install path. I'm not quite sure how t= o inconvenience the user further than they normally are with this method, h= owever...

Thanks for all the insightful advice!

Marshall

On Thu, Sep 14, 2017 at 3:55 PM Mars= hall Conover <= marzhall.o@gmail.com> wrote:
khm - Unfortunately, that would conflict with the browsin= g 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, forw= ards to them, and opens up emacs.

Thanks!

Marshall

On Thu, Sep 14, 2017 at 10:58 AM Marshall Conove= r <marzhall.o@= gmail.com> wrote:
Hi All!

=C2=A0 =C2=A0I've been exploring th= e Fuchsia operating system, and while they have per-process namespaces, the= y don't have a utility like plan 9's bind, nor a method of supporti= ng 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 st= rong 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 - an= d I'd very much like to, as it really, *really* is something I'd li= ke 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 r= unning tests on an install of a product while still being able to do develo= pment 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 o= f when a bind would just be convenient, such as a certain process needing p= ython2 instead of python3 on a system which defaults to python 3, and have = scripts that reference #/bin/python.

So, I'd l= ike to hear the community's thoughts on other uses of bind. I think the= y'd be useful both for making my case for bind, and in thinking about m= y 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 ch= anges for umount), but right now bind is my focus.

Thanks for your time.

Mars= hall
--001a1148fc74645065055939208b-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 15 Sep 2017 18:07:47 +0000 From: "Brian L. Stuart" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <1312270110.2858999.1505498867019@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <1312270110.2858999.1505498867019.ref@mail.yahoo.com> Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c17a1a4a-ead9-11e9-9d60-3106f5b1d025 On Fri, 9/15/17, Marshall Conover wrote: > I'll start digging in to see what I can do. I think I jumped the > gun by trying to contribute a feature, ... On this point, I'd suggest a slight shift of perspective. This is something that I've tried to convey both to collegues when in industry and to students when teaching. Don't think in terms of implementing features. Think instead of implementing mechanisms. The mindset where every feature is implemented with its own mechanisms is the reason so much software is so poorly engineered. Witness the browsers mentioned earlier. Good engineering involves designing and selecting a good set of simple mechanisms that when used in various combinations provide a rich set of features. If a mechanism doesn't fit, don't include it. Remember that perfection is achieved not when there's nothing left to add, but when there's nothing left to remove. Bringing this back to bind, I wouldn't think of bind itself as a feature. However, when the bind mechanism is used in conjunction with the union directory mechanism and the architecture environment variable, the feature of sane multi-architecture binary handling emerges. No where in the source of the shell or the kernel or anywhere else is there code specifically designated to make it possible to run the correct binary based on the architecture. Of course, there are other ways of accomplishing this feature, such as a path variable, but the beauty of this approach is that all of the mechanisms involved also find application in other features. For example, bind and per- process name spaces make possible the elegance of rio which in turn provides the feature of recursively running rio inside a rio window, something that takes a lot of special effort in X. Likewise, when bind is used with import, you can get a particularly elegant form of network gatewaying. So I suggest not thinking of bind as a feature, but as a very general tool for building features. One objective when implementing a mechanism is that is reduces the amount of code in other places by more lines than it takes to implement the mechanism. There are two major reasons why it's important to keep the number of lines of code down. First, every line is a potential bug. To a first approximation, the fewer lines of code the fewer places where you might have bugs. Second, every individual and organization has a maximum level of complexity that it can manage. Once that point is hit, all new releases merely rearrange the bugs. They don't really make the product any better. A well designed set of mechanisms is like a set of basis vectors and each point in the vector space is a potential feature. If your set of features isn't larger and richer than the set of mechanisms, then you should go back and rethink the set of mechanisms. So when adding a mechanism, you want to make sure you're adding a new dimension to your feature space. BLS From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Fran. J Ballesteros" In-Reply-To: <1312270110.2858999.1505498867019@mail.yahoo.com> Date: Fri, 15 Sep 2017 21:54:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1312270110.2858999.1505498867019.ref@mail.yahoo.com> <1312270110.2858999.1505498867019@mail.yahoo.com> To: "Brian L. Stuart" , Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c17f9ca4-ead9-11e9-9d60-3106f5b1d025 I'm going to print your mail, and read it every night.=20 thanks.=20 > El 15 sept 2017, a las 20:07, Brian L. Stuart esc= ribi=C3=B3: >=20 >> On Fri, 9/15/17, Marshall Conover wrote: >>=20 >> I'll start digging in to see what I can do. I think I jumped the >> gun by trying to contribute a feature, ... >=20 > On this point, I'd suggest a slight shift of perspective. This is somethi= ng > that I've tried to convey both to collegues when in industry and to > students when teaching. Don't think in terms of implementing features. > Think instead of implementing mechanisms. The mindset where every > feature is implemented with its own mechanisms is the reason so much > software is so poorly engineered. Witness the browsers mentioned > earlier. Good engineering involves designing and selecting a good > set of simple mechanisms that when used in various combinations > provide a rich set of features. If a mechanism doesn't fit, don't include= > it. Remember that perfection is achieved not when there's nothing > left to add, but when there's nothing left to remove. >=20 > Bringing this back to bind, I wouldn't think of bind itself as a feature. > However, when the bind mechanism is used in conjunction with the > union directory mechanism and the architecture environment variable, > the feature of sane multi-architecture binary handling emerges. No > where in the source of the shell or the kernel or anywhere else is > there code specifically designated to make it possible to run the > correct binary based on the architecture. Of course, there are > other ways of accomplishing this feature, such as a path variable, > but the beauty of this approach is that all of the mechanisms involved > also find application in other features. For example, bind and per- > process name spaces make possible the elegance of rio which > in turn provides the feature of recursively running rio inside a rio > window, something that takes a lot of special effort in X. Likewise, > when bind is used with import, you can get a particularly elegant > form of network gatewaying. So I suggest not thinking of bind as > a feature, but as a very general tool for building features. >=20 > One objective when implementing a mechanism is that is reduces > the amount of code in other places by more lines than it takes > to implement the mechanism. There are two major reasons why > it's important to keep the number of lines of code down. First, > every line is a potential bug. To a first approximation, the fewer > lines of code the fewer places where you might have bugs. Second, > every individual and organization has a maximum level of complexity > that it can manage. Once that point is hit, all new releases merely > rearrange the bugs. They don't really make the product any better. >=20 > A well designed set of mechanisms is like a set of basis vectors > and each point in the vector space is a potential feature. If your > set of features isn't larger and richer than the set of mechanisms, > then you should go back and rethink the set of mechanisms. So > when adding a mechanism, you want to make sure you're adding > a new dimension to your feature space. >=20 > BLS >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 From: newton688@gmail.com (Chris McGee) Date: Fri, 15 Sep 2017 20:02:49 -0400 Subject: [9fans] The Case for Bind In-Reply-To: <1312270110.2858999.1505498867019@mail.yahoo.com> References: <1312270110.2858999.1505498867019.ref@mail.yahoo.com> <1312270110.2858999.1505498867019@mail.yahoo.com> Message-ID: <8F9D9BB7-5189-4823-B3DC-D69C60503CDC@gmail.com> Topicbox-Message-UUID: c1882216-ead9-11e9-9d60-3106f5b1d025 I really like this description. Thank you > On Sep 15, 2017, at 2:07 PM, Brian L. Stuart wrote: > >> On Fri, 9/15/17, Marshall Conover wrote: >> >> I'll start digging in to see what I can do. I think I jumped the >> gun by trying to contribute a feature, ... > > On this point, I'd suggest a slight shift of perspective. This is something > that I've tried to convey both to collegues when in industry and to > students when teaching. Don't think in terms of implementing features. > Think instead of implementing mechanisms. The mindset where every > feature is implemented with its own mechanisms is the reason so much > software is so poorly engineered. Witness the browsers mentioned > earlier. Good engineering involves designing and selecting a good > set of simple mechanisms that when used in various combinations > provide a rich set of features. If a mechanism doesn't fit, don't include > it. Remember that perfection is achieved not when there's nothing > left to add, but when there's nothing left to remove. > > Bringing this back to bind, I wouldn't think of bind itself as a feature. > However, when the bind mechanism is used in conjunction with the > union directory mechanism and the architecture environment variable, > the feature of sane multi-architecture binary handling emerges. No > where in the source of the shell or the kernel or anywhere else is > there code specifically designated to make it possible to run the > correct binary based on the architecture. Of course, there are > other ways of accomplishing this feature, such as a path variable, > but the beauty of this approach is that all of the mechanisms involved > also find application in other features. For example, bind and per- > process name spaces make possible the elegance of rio which > in turn provides the feature of recursively running rio inside a rio > window, something that takes a lot of special effort in X. Likewise, > when bind is used with import, you can get a particularly elegant > form of network gatewaying. So I suggest not thinking of bind as > a feature, but as a very general tool for building features. > > One objective when implementing a mechanism is that is reduces > the amount of code in other places by more lines than it takes > to implement the mechanism. There are two major reasons why > it's important to keep the number of lines of code down. First, > every line is a potential bug. To a first approximation, the fewer > lines of code the fewer places where you might have bugs. Second, > every individual and organization has a maximum level of complexity > that it can manage. Once that point is hit, all new releases merely > rearrange the bugs. They don't really make the product any better. > > A well designed set of mechanisms is like a set of basis vectors > and each point in the vector space is a potential feature. If your > set of features isn't larger and richer than the set of mechanisms, > then you should go back and rethink the set of mechanisms. So > when adding a mechanism, you want to make sure you're adding > a new dimension to your feature space. > > BLS > 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-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: giacomo@tesio.it (Giacomo Tesio) Date: Mon, 18 Sep 2017 10:31:50 +0200 Subject: [9fans] The Case for Bind In-Reply-To: References: Message-ID: Topicbox-Message-UUID: c1aa4184-ead9-11e9-9d60-3106f5b1d025 2017-09-17 23:06 GMT+02:00 Marshall Conover : > 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. > Just read carefully https://fuchsia.googlesource.com/zircon/+/HEAD/docs/contributing.md As of today, it states clearly: we're *not* seeking major changes or new features from new contributors, > however, if you desire to contribute > , *small* > bugfixes are welcome. > NOT and SMALL are the key words here. In other words This project is not open, despite the pool of permissive licenses. > Oh... well yes, you can fork it if you want... feel free to do so! > We like competition! (should we remind you that we have the best engineers > on the market? Please compete with us!) > I don't want to put you down, but I've seen this happen several times at several open source projects leaded by large companies. Nevertheless, good luck! Giacomo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Marshall Conover Date: Mon, 18 Sep 2017 12:15:32 +0000 Message-ID: To: "9fans@9fans.net" <9fans@9fans.net> Content-Type: multipart/alternative; boundary="001a1149807c9eff68055975b3ff" Subject: Re: [9fans] The Case for Bind Topicbox-Message-UUID: c1a2c788-ead9-11e9-9d60-3106f5b1d025 --001a1149807c9eff68055975b3ff Content-Type: text/plain; charset="UTF-8" Thanks, Giacomo. I have no illusions of being the smartest person in the room or anything above mediocre, but I think there's a good chance the people at Bell Labs were in that category. Hopefully, if I try to follow their design ideas, I can at least play at being smart for a bit. And, if I do as much as possible in user-space, Google's lack of openness hopefully won't be too great an obstacle. This is the first thing I've been excited about in a long time, I'm going to at least take a shot, even if working hard at something doesn't necessarily mean it'll pan out. (Besides, I already have a name for the project in my head: "gihnurshk." It stands for "It's pronounced 'nurshk'.") Thanks! Marshall --001a1149807c9eff68055975b3ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Giacomo. I have no illusions of being the smartest= person in the room or anything above mediocre, but I think there's a g= ood chance the people at Bell Labs were in that category. Hopefully, if I t= ry to follow their design ideas, I can at least play at being smart for a b= it. And, if I do as much as possible in user-space, Google's lack of op= enness hopefully won't be too great an obstacle. This is the first thin= g I've been excited about in a long time, I'm going to at least tak= e a shot, even if working hard at something doesn't necessarily mean it= 'll pan out.

(Besides, I already have a name for the= project in my head: "gihnurshk." It stands for "It's pr= onounced 'nurshk'.")

Thanks!
= Marshall
--001a1149807c9eff68055975b3ff--