> On 15 Jan 2015, at 12:43, Joerg Beekmann, DeepCove Labs
> <[email protected]> wrote:
>
>
>
>> -----Original Message-----
>> From: Pharo-dev [mailto:[email protected]] On Behalf Of
>> Alain Rastoul
>> Sent: Wednesday, January 14, 2015 10:39 PM
>> To: [email protected]
>> Subject: Re: [Pharo-dev] Hosting the Pharo VM on MirageOS
>>
>> Le 15/01/2015 03:08, Joerg Beekmann, DeepCove Labs a écrit :
>>>
>>> I was not planning specializing the VM for the image. But rather link
>>> in a VM with everything needed to run a range of images. The
>>> dependencies are handled by creating an OCAML module that expresses
>> these and the VM code then lives in the module. The OCAML dependence
>> analyser (a sat solver) then ensures those are satisfied.
>>>
>> But if you don't have a specialized smalltalk vm and image, you will have to
>> embed full system dependencies, in order to build a full working smalltalk
>> system (having most part not working could be a very bad thing), and then you
>> loose the unikernel approach benefits (very lean dedicated system, small
>> attack surface etc.).
> My implicit assumption was that these VM would be designed for running
> headless web-services on smaller EC2 instances. And perhaps naively was
> thinking that the number of system dependencies would be quite low:
>
> - memory
> - CPU
> - networking stack
> - http/https
>
> - no file system but access to block storage (or perhaps even link image in
> so no storage at all)
> - mirage is single threaded with green threads so no multithreading/processing
Honestly, the VM is not that large. There are not many variation points on that
level.
Where you want specialisation is the *image*.
Marcus
