Le 16/01/2015 00:50, Ben Coman a écrit :
Actually, the requirements to modify/link the vm make it more a [vm-dev] topic, but still interesting for [pharo-dev]s.
that's how I understand it, but the distinction is not allways clear: standard frameworks devel (not use) who are part of the system should go here too IMHO, but that's an opinion.
May be a private list for the pharo-devs would be better for them not to be disturbed (that I can understand) , keeping the two lists open to everybody: users for general and use of the system and devel for vm or system related stuff. Or only one list open to every body and one private. For now, I don't want to ask myself if people will be diturbed or not or if they will answer or not, or to ask myself is it really pharodev or pharo use ? I think I will allways post questions on pharo-users, I will not disturb anybody, no problem :)
It wouldn't be [pharo-users] until there was something to "use" :) On Fri, Jan 16, 2015 at 5:18 AM, Alain Rastoul <[email protected] <mailto:[email protected]>> wrote: Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a écrit : -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@__lists.pharo.org <mailto:[email protected]>] On Behalf Of Alain Rastoul Sent: Wednesday, January 14, 2015 10:39 PM To: [email protected] <mailto:[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 <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
-- Regards, Alain
