> Am 16.01.2015 um 00:50 schrieb Ben Coman <[email protected]>:
>
> Actually, the requirements to modify/link the vm make it more a [vm-dev]
> topic, but still interesting for [pharo-dev]s.
> It wouldn't be [pharo-users] until there was something to "use" :)
>
But you could use it if it would be there. Having it on pharo-users could lead
to a lot of people showing their interest in using it. And it definetely is a
use case :)
Norbert
>> On Fri, Jan 16, 2015 at 5:18 AM, Alain Rastoul <[email protected]> wrote:
>> Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a écrit :
>>
>>>
>>>
>>>>>
>>>>>> -----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 specialization is the *image*.
>>>
>>> Thanks Marcus - good to know
>>>
>>>>
>>>> Marcus
>>>
>>>
>>>
>> Yes, the vm is not so big, and specialization has to be done in the image.
>> But there is a key point to mention about openmirage : if it started as unix
>> (or linux, don't know), it is not linux at all as I understand it See
>> chapter 3
>> http://queue.acm.org/detail.cfm?id=2566628
>> " ... The last compilation strategy drops the dependency on Unix entirely
>> and recompiles the MirNet module to link directly to a Xen network driver,
>> which in turn pulls in all the dependencies it needs to boot on Xen. This
>> progressive recompilation is key to the usability of MirageOS, ... etc"
>>
>> The compilation process produce a single compiled unit that includes your
>> application linked with the needed libraries, ie: the kernel+application,
>> there is no linux kernel and no processes at all.
>> Even driver's code is linked to you application.
>> It can be booted in a Xen guest vm like PharoNOS, Linux tiny core
>> or others linux but ...
>> I see a completely different animal is here :)
>> if I'm wrong, please correct me
>>
>> NB: Is this thread about pharo devel ?
>> or should it be moved to pharo-users ?
>>
>> --
>> Regards,
>>
>> Alain
>>
>>
>
