Re: [9fans] The Case for Bind

[Marshall Conover]

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

Re: [9fans] The Case for Bind

[Micah Stetson]

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

Re: [9fans] The Case for Bind

[Aleksandar Kuktin]

>On Thu, 14 Sep 2017 14:58:02 +
>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.

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


signature.asc
Description: PGP signature

Re: [9fans] The Case for Bind

[Marshall Conover]

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

Re: [9fans] The Case for Bind

[Kurt H Maier]

On Thu, Sep 14, 2017 at 07:55:21PM +, 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

Re: [9fans] The Case for Bind

[Marshall Conover]

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
>

Re: [9fans] The Case for Bind

[Kurt H Maier]

On Thu, Sep 14, 2017 at 02:58:02PM +, 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

[9fans] The Case for Bind

[Marshall Conover]

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