<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 November 2013 01:12, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Tue, Nov 19, 2013 at 12:00 PM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 19.11.2013, at 12:35, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
<br>
> Hi All,<br>
><br>
> this is an important discussion that is taking a religious tone that we should strive to avoid.<br>
<br>
Let's call it philosophical, "religious" is just flame bait.<br>
<br>
> There are good arguments for plugins, namely security and encapsulation. There are good arguments for an FFI, namely extensibility and platform compatibility.<br>
<br>
Agreed.<br>
<br>
> [... nice explanation snipped ...]<br>
<br>
> A number of straw men have been raised against the FFI in this discussion.<br>
<br>
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.<br>
<br>
> 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.<br>
<br>
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.<br>
</blockquote><div><br></div></div><div>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. </div>
<div><br></div><div>In these days of build and test slaves this kind of layering is straight-forward to manage.</div><div class="im"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
</blockquote><div><br></div></div><div>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.</div>
<div> </div></div></div></div></blockquote><div><br>Amen.<br><br></div><div>For application-level developer the main focus is how to get <br>missing functionality with minimum effort. The amount of effort increases (up to an<br>
infinity), once you start adding artificial walls and layers.<br></div><div>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,<br>
</div><div>packed with libraries A, B,C .. and they don't care if it won't run on system Y or Z,<br></div><div>since it is beyond their deployment target.<br></div><div><br></div><div>VM-level security is IMO wrong approach. VM runs on a system which provides<br>
</div><div>(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.<br></div><div>The level of security should be in hands of developers , users of VM, not in hands of VM.<br>
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.<br></div><br><div><br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
- Bert -<br>
<br>
<br><span class="HOEnZb"><font color="#888888">
</font></span></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</font></span></div></div>
<br><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Igor Stasenko.
</div></div>