Re: [9fans] The Case for Bind

2017-09-15 Thread Fran. J Ballesteros
I'm going to print your mail, and read it every night. 
thanks. 

> El 15 sept 2017, a las 20:07, Brian L. Stuart  
> escribió:
> 
>> 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
> 




Re: [9fans] The Case for Bind

2017-09-15 Thread Brian L. Stuart
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



Re: [9fans] The Case for Bind

2017-09-15 Thread Marshall Conover
> 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 

Re: [9fans] The Case for Bind

2017-09-15 Thread Giacomo Tesio
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