info'hiding vs blackbox binaries

5.10: addx/info'hiding vs blackbox binaries:
. info'hiding means being able to reuse a modules
without having access to the module`body;
by accessing only the module`header .
. only the linker needs the bodies of
a program and the modules it uses .
. the bodies are blackboxes:
usable but unviewable,
protecting both trade secrets
and unintended reuse or adaptation .
. addx's intent is simply to warn coders
that the implementation could change;
ie, if you rely on impl'details,
you can't expect easy updates;
instead,
you'd have to rewrite your code
in order for it to work with any new impl'details .

. addx does allow code obfuscation
since you can easily change names to nonsense;
on the other hand,
the user is a new co.maintainer of your code,
and can easily rename them again
to match ongoing understanding of their roles .

. as for binary black boxes,
adda compiles to c, and then to native binary,
but addx should't run a binary unless
either adda compiled it;
or, there's some other way to trust it .

. if there was some secure way to know
that the binary on my machine
was actually generated by
an untampered adda on your machine
then blackbox modules could be consistent with
the addx security model .

. another way to support blackbox binaries
is for addx to know of a secure website
where it could find such adda products .
. that could, however, bring
new complexity to the security problem:
each time you trust a website
that's another time you have to ask:
"(has that site been cracked recently?)
. by staying with the openware model,
you need be trusting only your platform
(the os, and other apps installed).

. some mutually-trusted 3rd party
could accept code and compile it to binaries;
then commercial interests would be assured privacy;
and trusting users would be assured
that this binary was generated by adda,
while non-trusting users
would be free to download pure openware .

5.10: todo.addx/making openware usable:

. an advantage of addx being openware
is that it minimizes trust requirements;
eg, if you're on Apple's mac,
the only thing you have to trust
is Apple's xcode compiler .

. if addx is built by mac's xcode
then xcode should be easy to get;
will it always ship with every new mac?
... in the qt crossplatform ide doc's
they assume xcode will always be
right at your finger tips .
yet, new versions require payment;
and the code base is getting huge;
so, if it's unused by most mac fans
why cut another entire dvd for every unit ?

addx should written in such a way that
the code can be compiled with
easy to get tools .
. for those who want a completely
native mac app,
some of addx will need to be
compiled with xcode .
. therefore,
they will need to download atleast a small binary
or get xcode .

. this small module should allow them
to build extensions;
so then most of their system
is still modifiable by them
yet is native code rather than addm .

xcode's lang is obj'c,
and that provides dynamic linking;
but does it bind gcc binaries ?
gcc itself has obj'c,
but xcode is no longer using gcc;
it uses clang . is clang free ? [..., yes .]
[5.30: anyway,
the plan for now is as was originally:
the source is meant to be compiled all at once,
and subsequent scripting is done with addm .]

5.10: pos.addx/qt on mac decreases security:
. I'm assuming that adda can protect my code
from abusing qt's large library;
and, qt itself reduces bugs by being easy to use .
. it's also a popular code base with a lot of eyes,
but one disadvantage with being popular on Windows
is that it will be worth more to malware writers .
. by requiring the qt codebase,
addx might be adding to a platform's vulnerability .
sharing a runtime:
. another possibility is that
if any other qt app's are run alongside addx,
they may be able to violate addx`privacy
so then addx can't make any privacy claims
to the user in this situation ?

5.20: addx/unix, KDE, and compon tech:
. I was recently baffled by this filename:
"( dims of addx (unix KDE compon tech) );
but, a review of the article put this together:
. when saying unix was a dimension of addx,
I was assuming linux was unix
and unix was the future platform .
. this article was pointing out that
linux domination plans needed dev tools;
and that, KDE was there for even beginners .
. linux's support for components
is a key to healthy competition and evolution .