On 20 November 2013 01:12, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> On Tue, Nov 19, 2013 at 12:00 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:
>
>> On 19.11.2013, at 12:35, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> > Hi All,
>> >
>> >     this is an important discussion that is taking a religious tone
>> that we should strive to avoid.
>>
>> Let's call it philosophical, "religious" is just flame bait.
>>
>> >  There are good arguments for plugins, namely security and
>> encapsulation.  There are good arguments for an FFI, namely extensibility
>> and platform compatibility.
>>
>> Agreed.
>>
>> > [... nice explanation snipped ...]
>>
>> > A number of straw men have been raised against the FFI in this
>> discussion.
>>
>> No-one has been arguing against FFI in general. We agree an FFI is
>> useful, and a more powerful FFI is better. We just (appear to) disagree on
>> how widely it should be used.
>>
>> > Bert asks "Suppose we add a new VM platform, like a VM running on
>> JavaScript in the browser. Do you really want to re-implement all the C
>> libraries utilized via FFI? Or rather a handful of primitives in your
>> language of choice?".  First it is not clear that one *can* implement these
>> primitives taking either approach.  If the platform, e.g. JavaScript in a
>> browser, takes the Squeak plugin approach of preventing access to the
>> platform except through a restricted set of facilities, then certain
>> functionality will simply be off-limits, whether one has an FFI or not.
>>  Second, reimplementing all the C libraries isn't obligatory.  If the
>> platform provides an FFI one simply mates to its FFI and accesses the
>> underlying libraries.  If it doesn't then that functionality is off-limits,
>> but that doesn't mean the rest of the system doesn't work.
>>
>> That's where we disagree. If basic functions in the system depend on FFI,
>> and FFI is not available, then the system *does not work* at all. E.g.,
>> there are efforts in other Squeak forks to replace fundamental parts of the
>> system (which currently rely on VM primitives) with FFI calls. That's what
>> I am wary of.
>>
>
> I see your concern but it doesn't worry me.  I don't see why the system
> can't be constructed so that it discovers what services are available.  It
> already does that in a number of circumstances.  For example, the menu bar
> includes a system report if class SystemReporter is loaded.  So I can
> imagine that the socket layer would look for an FFI-based implementation
> and use it if available, falling back on the plugin interface if absent.
>
> In these days of build and test slaves this kind of layering is
> straight-forward to manage.
>
>
> One of the fundamental services of a virtual machine is providing a safe
>> and complete environment for the system to function in. Plugins enrich that
>> environment. But FFI pokes holes into that safe environment, reaching out
>> of the virtual world into the "real" world.
>
>
>> Indeed sometimes that is exactly what you need, namely to better interact
>> with the specific host system you are running on. I'm simply saying that we
>> need to clearly separate this from the base system, which should be as
>> independent of the actual host platform as possible.
>>
>
> Again I see this as a straw-man.  Yes, the system should be able to
> provide something portable and safe, and feature-rich.  But it should also
> be able to provide access to the broader environment if so desired.
>  Further, if a superior interface is available via FFI the system should
> use it over and above the plugin interface.  The JIT does this, but you'd
> never notice.  If sse instructions are available they get used, etc.  The
> system already adapts to the underlying host (file directory separators,
> etc).  Whether the system is independent of the host or heavily dependent
> on it is a matter of perspective.  One perspective is to say that it
> provides portable abstractions of host facilities.  Whether one goes
> through an FFI or a plugin to provide these abstractions makes little
> difference.  I would agree that we keep the FFI separate from /a/ base
> system, but not form /all/ base systems.  I want support for symbolic links
> and I don't want to depend on a plugin that can't, because the facilities
> are too different across platforms, provide a portable abstraction of
> symbolic links across unix, windows and mac.  I want to be able to launch
> an arbitrary external program and not be limited to a small set of
> supported programs known by a plugin, etc, etc.  These are all valid things
> to have in a base system, but not valid things to have in e.g. a web plugin.
>
>

Amen.

For application-level developer the main focus is how to get
missing functionality with minimum effort. The amount of effort increases
(up to an
infinity), once you start adding artificial walls and layers.
For system-level design, i agree, we should be accurate and keep things
separate (but this is just a modularity concern, not security!). But for
application-level, it is usually completely opposite: because people
develop and deploy their app on system X,
packed with libraries A, B,C .. and they don't care if it won't run on
system Y or Z,
since it is beyond their deployment target.

VM-level security is IMO wrong approach. VM runs on a system which provides
(or not) certain level of security. If you start artificially putting
barriers, you only making it harder for application-level developer to get
what he wants.
The level of security should be in hands of developers , users of VM, not
in hands of VM.
So, VM role is like a screwdriver - a tool you using to (screw ;) do
something, but not a police officer, which watches after your crimes.





>> - Bert -
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131120/2c158155/attachment.htm