Cog in the cloud

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Cog in the cloud

Ben Coman
 

Just some thoughts that arose as I skipped along the web...

With the idea of using Pharo in the cloud, I was thinking of how
PharoNOS[1] is basing off top of the Linux kernel, but the examples
indicate its operating in User Mode.  So I was wondering about
performance being greater[2] if the CogVM ran in Kernel Mode. However
maybe this could get tangled in the GPL license of the kernel.

Now I believe FreeBSD/NetBSD license is compatible with COG's MIT
license, so that seems a better option for eliminating layers of the
operating system.  They both[3][4] have pre-built Amazon Machine Images
to run on EC2, as well as instructions[5] to build your own AMI.  So
potentially we could build an AMI with the CogVM linked to the
FreeBSDKernel operating in Kernel Mode, with no User Mode. The lack of
direct access to memory from the Image, and probably single application
focus should be sufficient security to forgo User Mode, and run faster.

But we could go a step further.  Runing in the cloud relies heavily on
virtualisation, and for performance[6], most likely on the OS's
paravirtualisation interface - to Xen for example.  So from Cog, why not
interface direct to the Xen FrontEndDriver[7] and eliminate the DomU
operating system all together.  What I understand from [6] is that Xen's
paravirtualisation hooks makes it much easier to boot, than booting on
the bare metal of a fully-virtualised system. So the former seems more
achievable than the latter (which was the only option in years past),
and also be more portable as technology evolves, to any platform Xen
runs on.

Squeak/Pharo on Cog-Xen could be a good choice for a Cloud Operating
System[8]. Maybe a good student research project?

cheers -ben

[1] http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos
[2] http://blog.codinghorror.com/understanding-user-and-kernel-mode/
[3] http://www.daemonology.net/freebsd-on-ec2/
[4] http://wiki.netbsd.org/amazon_ec2/amis/
[5] http://wiki.netbsd.org/amazon_ec2/build_your_own_ami/
[6] http://wiki.xen.org/wiki/Virtualization_Spectrum
[7] http://wiki.xen.org/wiki/FrontendDriver
[8] http://wiki.xen.org/wiki/Cloud_Operating_Systems

Reply | Threaded
Open this post in threaded view
|

Re: Cog in the cloud

Edgar De Cleene
 
Thanks for share.
I away of Pharo world so don’t know about Pharo NOS.
This days i playing with a Cuis fork under 900 classes and under 4 Mb.
What you could do wit it?
See the system running in www.squeakros.org
user: visita
pass: (blank here)
It’s a combination of swiki/blog and exploration of how to build web 2.0 apps without Node, npm, Bower, Grunt ,nothing.
Only HTML5, CSS, JavaScript powered by my Cuis fork.
I want to have a NOS version of it, wish work together exchanging feedback ?

-- 
Edgar De Cleene
@morplenauta en twitter
Sent with Sparrow

On Saturday, December 20, 2014 at 1:08 AM, Ben Coman wrote:


Just some thoughts that arose as I skipped along the web...

With the idea of using Pharo in the cloud, I was thinking of how
PharoNOS[1] is basing off top of the Linux kernel, but the examples
indicate its operating in User Mode. So I was wondering about
performance being greater[2] if the CogVM ran in Kernel Mode. However
maybe this could get tangled in the GPL license of the kernel.

Now I believe FreeBSD/NetBSD license is compatible with COG's MIT
license, so that seems a better option for eliminating layers of the
operating system. They both[3][4] have pre-built Amazon Machine Images
to run on EC2, as well as instructions[5] to build your own AMI. So
potentially we could build an AMI with the CogVM linked to the
FreeBSDKernel operating in Kernel Mode, with no User Mode. The lack of
direct access to memory from the Image, and probably single application
focus should be sufficient security to forgo User Mode, and run faster.

But we could go a step further. Runing in the cloud relies heavily on
virtualisation, and for performance[6], most likely on the OS's
paravirtualisation interface - to Xen for example. So from Cog, why not
interface direct to the Xen FrontEndDriver[7] and eliminate the DomU
operating system all together. What I understand from [6] is that Xen's
paravirtualisation hooks makes it much easier to boot, than booting on
the bare metal of a fully-virtualised system. So the former seems more
achievable than the latter (which was the only option in years past),
and also be more portable as technology evolves, to any platform Xen
runs on.

Squeak/Pharo on Cog-Xen could be a good choice for a Cloud Operating
System[8]. Maybe a good student research project?

cheers -ben


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Cog in the cloud

Eliot Miranda-2
In reply to this post by Ben Coman

Hi Ben,


On Dec 19, 2014, at 8:08 PM, Ben Coman <[hidden email]> wrote:

>
> Just some thoughts that arose as I skipped along the web...
>
> With the idea of using Pharo in the cloud, I was thinking of how PharoNOS[1] is basing off top of the Linux kernel, but the examples indicate its operating in User Mode.  So I was wondering about performance being greater[2] if the CogVM ran in Kernel Mode. However maybe this could get tangled in the GPL license of the kernel.
>
> Now I believe FreeBSD/NetBSD license is compatible with COG's MIT license, so that seems a better option for eliminating layers of the operating system.  They both[3][4] have pre-built Amazon Machine Images to run on EC2, as well as instructions[5] to build your own AMI.  So potentially we could build an AMI with the CogVM linked to the FreeBSDKernel operating in Kernel Mode, with no User Mode. The lack of direct access to memory from the Image, and probably single application focus should be sufficient security to forgo User Mode, and run faster.
>
> But we could go a step further.  Runing in the cloud relies heavily on virtualisation, and for performance[6], most likely on the OS's paravirtualisation interface - to Xen for example.  So from Cog, why not interface direct to the Xen FrontEndDriver[7] and eliminate the DomU operating system all together.  What I understand from [6] is that Xen's paravirtualisation hooks makes it much easier to boot, than booting on the bare metal of a fully-virtualised system. So the former seems more achievable than the latter (which was the only option in years past), and also be more portable as technology evolves, to any platform Xen runs on.
>
> Squeak/Pharo on Cog-Xen could be a good choice for a Cloud Operating System[8]. Maybe a good student research project?

This sounds really cool, but could you analyse a bit further?

- what key economic and managerial benefits accrue from this configuration?

- what infrastructure is missing?  (e.g. what key drivers need implementing?)


Eliot (phone)
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Cog in the cloud

Ben Coman
In reply to this post by Ben Coman
 
(whoops forgot to cross-post)

Eliot Miranda wrote:

> Hi Ben,
>
>
> On Dec 19, 2014, at 8:08 PM, Ben Coman <[hidden email]> wrote:
>
>> Just some thoughts that arose as I skipped along the web...
>>
>> With the idea of using Pharo in the cloud, I was thinking of how PharoNOS[1] is basing off top of the Linux kernel, but the examples indicate its operating in User Mode.  So I was wondering about performance being greater[2] if the CogVM ran in Kernel Mode. However maybe this could get tangled in the GPL license of the kernel.
>>
>> Now I believe FreeBSD/NetBSD license is compatible with COG's MIT license, so that seems a better option for eliminating layers of the operating system.  They both[3][4] have pre-built Amazon Machine Images to run on EC2, as well as instructions[5] to build your own AMI.  So potentially we could build an AMI with the CogVM linked to the FreeBSDKernel operating in Kernel Mode, with no User Mode. The lack of direct access to memory from the Image, and probably single application focus should be sufficient security to forgo User Mode, and run faster.
>>
>> But we could go a step further.  Runing in the cloud relies heavily on virtualisation, and for performance[6], most likely on the OS's paravirtualisation interface - to Xen for example.  So from Cog, why not interface direct to the Xen FrontEndDriver[7] and eliminate the DomU operating system all together.  What I understand from [6] is that Xen's paravirtualisation hooks makes it much easier to boot, than booting on the bare metal of a fully-virtualised system. So the former seems more achievable than the latter (which was the only option in years past), and also be more portable as technology evolves, to any platform Xen runs on.
>>
>> Squeak/Pharo on Cog-Xen could be a good choice for a Cloud Operating System[8]. Maybe a good student research project?
>
> This sounds really cool, but could you analyse a bit further?
>
> - what key economic and managerial benefits accrue from this configuration?

I'll put some more thought into this, but just off the top of my head
(so it turned out more technical than economic/managerial):

* Eliminates performance overhead of system call context switching.
Although this is replaced by hypercalls, it removes one layer on
hypervisor systems, which plausibly is going to be EVERYTHING in the future.

* Eliminate performance overhead of OS networking stack
http://roscidus.com/blog/blog/2014/08/15/optimising-the-unikernel/

* Data from virtual devices is event driven.

* More easily portable to different ARM platforms.  Xen will present a
common interface to hide platform idiosyncrasies.
--> More widespread embedded use Cog.
http://www.slideshare.net/xen_com_mgr/free-rtos-xensummit

* Run databases in their own domain.

* Isolate plugin memory space. Rather than linking plugins into Cog,
potentially threatening its stability, run them in a separate domain and
use high-speed inter-domain shared memory.
http://www.cs.ucsb.edu/~nanli/projects/cs270.pdf

* Have a cloud community of thousands** of Images running each in their
own domain, communicating with high-speed inter-domain shared memory.
    ** presumptive figure - would need to check scaling ability

* Data sharing on high density hosting providers. Not sure if its there
yet, but may get Copy-On-Write
http://www-archive.xenproject.org/files/xensummit_fall07/18_GregorMilos.pdf

* In very large Images, which Spur will allow, perhaps a better way to
snapshot an Image is via virtual machine snapshotting using Copy-On.
http://www.cercs.gatech.edu/tech-reports/tr2010/git-cercs-10-05.pdf

* Rather than convert the Cog/Image to be multi-threaded, could have
many grid nodes running their own domain, communicating with high speed
shared memory.
http://www.cs.ucsb.edu/~nanli/projects/cs270.pdf
http://osnet.cs.binghamton.edu/publications/hines07memx.pdf

* AMD's hardware virtualisation eliminated a Ring and also segmented
memory protection used by virtualisation to separate address spaces, so
64-bit AMD can be slower.  Eliminating the OS kernel layer probably
bypasses this limitation since there would be only two levels -
Hypervisor & Cog.
https://lse.epita.fr/data/2011-lse-summer-week/xen.pdf

* Its where all the cool kids hang out --> marketing opportunity



>
> - what infrastructure is missing?  (e.g. what key drivers need implementing?)

I'll need to understand Cog more. As a start, here are some porting and
API docs...

http://events.linuxfoundation.org/sites/events/files/slides/Porting%20FreeBSD%20on%20Xen%20on%20ARM%20.pdf

http://oss.org.cn/ossdocs/server_storage/xen/interface/interface.html

http://www.informit.com/articles/article.aspx?p=1160234&seqNum=4

https://lse.epita.fr/data/2011-lse-summer-week/xen.pdf

https://github.com/cloudius-systems/osv/blob/master/drivers/xenfront-xenbus.cc

cheers -ben



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Cog in the cloud

Ben Coman
 
Ben Coman wrote:

>
> (whoops forgot to cross-post)
>
> Eliot Miranda wrote:
>> Hi Ben,
>>
>>
>> On Dec 19, 2014, at 8:08 PM, Ben Coman <[hidden email]> wrote:
>>
>>> Just some thoughts that arose as I skipped along the web...
>>>
>>> With the idea of using Pharo in the cloud, I was thinking of how
>>> PharoNOS[1] is basing off top of the Linux kernel, but the examples
>>> indicate its operating in User Mode.  So I was wondering about
>>> performance being greater[2] if the CogVM ran in Kernel Mode. However
>>> maybe this could get tangled in the GPL license of the kernel.
>>>
>>> Now I believe FreeBSD/NetBSD license is compatible with COG's MIT
>>> license, so that seems a better option for eliminating layers of the
>>> operating system.  They both[3][4] have pre-built Amazon Machine
>>> Images to run on EC2, as well as instructions[5] to build your own
>>> AMI.  So potentially we could build an AMI with the CogVM linked to
>>> the FreeBSDKernel operating in Kernel Mode, with no User Mode. The
>>> lack of direct access to memory from the Image, and probably single
>>> application focus should be sufficient security to forgo User Mode,
>>> and run faster.
>>>
>>> But we could go a step further.  Runing in the cloud relies heavily
>>> on virtualisation, and for performance[6], most likely on the OS's
>>> paravirtualisation interface - to Xen for example.  So from Cog, why
>>> not interface direct to the Xen FrontEndDriver[7] and eliminate the
>>> DomU operating system all together.  What I understand from [6] is
>>> that Xen's paravirtualisation hooks makes it much easier to boot,
>>> than booting on the bare metal of a fully-virtualised system. So the
>>> former seems more achievable than the latter (which was the only
>>> option in years past), and also be more portable as technology
>>> evolves, to any platform Xen runs on.
>>>
>>> Squeak/Pharo on Cog-Xen could be a good choice for a Cloud Operating
>>> System[8]. Maybe a good student research project?
>>
>> This sounds really cool, but could you analyse a bit further?
>>
>> - what key economic and managerial benefits accrue from this
>> configuration?
>
> I'll put some more thought into this, but just off the top of my head
> (so it turned out more technical than economic/managerial):
>
> * Eliminates performance overhead of system call context switching.
> Although this is replaced by hypercalls, it removes one layer on
> hypervisor systems, which plausibly is going to be EVERYTHING in the
> future.
>
> * Eliminate performance overhead of OS networking stack
> http://roscidus.com/blog/blog/2014/08/15/optimising-the-unikernel/
>
> * Data from virtual devices is event driven.
>
> * More easily portable to different ARM platforms.  Xen will present a
> common interface to hide platform idiosyncrasies.
> --> More widespread embedded use Cog.
> http://www.slideshare.net/xen_com_mgr/free-rtos-xensummit
>
> * Run databases in their own domain.
>
> * Isolate plugin memory space. Rather than linking plugins into Cog,
> potentially threatening its stability, run them in a separate domain and
> use high-speed inter-domain shared memory.
> http://www.cs.ucsb.edu/~nanli/projects/cs270.pdf
>
> * Have a cloud community of thousands** of Images running each in their
> own domain, communicating with high-speed inter-domain shared memory.
>    ** presumptive figure - would need to check scaling ability
>
> * Data sharing on high density hosting providers. Not sure if its there
> yet, but may get Copy-On-Write
> http://www-archive.xenproject.org/files/xensummit_fall07/18_GregorMilos.pdf
>
> * In very large Images, which Spur will allow, perhaps a better way to
> snapshot an Image is via virtual machine snapshotting using Copy-On.
> http://www.cercs.gatech.edu/tech-reports/tr2010/git-cercs-10-05.pdf
>
> * Rather than convert the Cog/Image to be multi-threaded, could have
> many grid nodes running their own domain, communicating with high speed
> shared memory.
> http://www.cs.ucsb.edu/~nanli/projects/cs270.pdf
> http://osnet.cs.binghamton.edu/publications/hines07memx.pdf
>
> * AMD's hardware virtualisation eliminated a Ring and also segmented
> memory protection used by virtualisation to separate address spaces, so
> 64-bit AMD can be slower.  Eliminating the OS kernel layer probably
> bypasses this limitation since there would be only two levels -
> Hypervisor & Cog.
> https://lse.epita.fr/data/2011-lse-summer-week/xen.pdf
>
> * Its where all the cool kids hang out --> marketing opportunity
>

* Security versus lines of code...

   Linux = 15.9 million (3.6 Kernel)
   OSX = 86 million
   FreeBSD = 6.25 million
   OpenSolaris = 10 million
   Windows = 64 million

   Xen-ARM = 90,000
   Xen-x86 = 140,000

https://www.google.com/fusiontables/DataSource?docid=12Eg7Ru1CH5MIjomcfjaGKe2qBd9ynmSQni5CAioK

http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper





Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Cog in the cloud

Alain Rastoul-2
 

Le 22/12/2014 13:14, Ben Coman a écrit :

>
> Ben Coman wrote:
>>
>> (whoops forgot to cross-post)
>>
>> Eliot Miranda wrote:
>>> Hi Ben,
>>>
>>>
>>> On Dec 19, 2014, at 8:08 PM, Ben Coman <[hidden email]> wrote:
>>>
>>>> Just some thoughts that arose as I skipped along the web...
>>>>
>>>> With the idea of using Pharo in the cloud, I was thinking of how
>>>> PharoNOS[1] is basing off top of the Linux kernel, but the examples
>>>> indicate its operating in User Mode.  So I was wondering about
>>>> performance being greater[2] if the CogVM ran in Kernel Mode.
>>>> However maybe this could get tangled in the GPL license of the kernel.
>>>>
>>>> Now I believe FreeBSD/NetBSD license is compatible with COG's MIT
>>>> license, so that seems a better option for eliminating layers of the
>>>> operating system.  They both[3][4] have pre-built Amazon Machine
>>>> Images to run on EC2, as well as instructions[5] to build your own
>>>> AMI.  So potentially we could build an AMI with the CogVM linked to
>>>> the FreeBSDKernel operating in Kernel Mode, with no User Mode. The
>>>> lack of direct access to memory from the Image, and probably single
>>>> application focus should be sufficient security to forgo User Mode,
>>>> and run faster.
>>>>
>>>> But we could go a step further.  Runing in the cloud relies heavily
>>>> on virtualisation, and for performance[6], most likely on the OS's
>>>> paravirtualisation interface - to Xen for example.  So from Cog, why
>>>> not interface direct to the Xen FrontEndDriver[7] and eliminate the
>>>> DomU operating system all together.  What I understand from [6] is
>>>> that Xen's paravirtualisation hooks makes it much easier to boot,
>>>> than booting on the bare metal of a fully-virtualised system. So the
>>>> former seems more achievable than the latter (which was the only
>>>> option in years past), and also be more portable as technology
>>>> evolves, to any platform Xen runs on.
>>>>
>>>> Squeak/Pharo on Cog-Xen could be a good choice for a Cloud Operating
>>>> System[8]. Maybe a good student research project?
>>>
>>> This sounds really cool, but could you analyse a bit further?
>>>
>>> - what key economic and managerial benefits accrue from this
>>> configuration?
>>
>> I'll put some more thought into this, but just off the top of my head
>> (so it turned out more technical than economic/managerial):
>>
>> * Eliminates performance overhead of system call context switching.
>> Although this is replaced by hypercalls, it removes one layer on
>> hypervisor systems, which plausibly is going to be EVERYTHING in the
>> future.
>>
>> * Eliminate performance overhead of OS networking stack
>> http://roscidus.com/blog/blog/2014/08/15/optimising-the-unikernel/
>>
>> * Data from virtual devices is event driven.
>>
>> * More easily portable to different ARM platforms.  Xen will present a
>> common interface to hide platform idiosyncrasies.
>> --> More widespread embedded use Cog.
>> http://www.slideshare.net/xen_com_mgr/free-rtos-xensummit
>>
>> * Run databases in their own domain.
>>
>> * Isolate plugin memory space. Rather than linking plugins into Cog,
>> potentially threatening its stability, run them in a separate domain and
>> use high-speed inter-domain shared memory.
>> http://www.cs.ucsb.edu/~nanli/projects/cs270.pdf
>>
>> * Have a cloud community of thousands** of Images running each in their
>> own domain, communicating with high-speed inter-domain shared memory.
>>    ** presumptive figure - would need to check scaling ability
>>
>> * Data sharing on high density hosting providers. Not sure if its there
>> yet, but may get Copy-On-Write
>> http://www-archive.xenproject.org/files/xensummit_fall07/18_GregorMilos.pdf
>>
>>
>> * In very large Images, which Spur will allow, perhaps a better way to
>> snapshot an Image is via virtual machine snapshotting using Copy-On.
>> http://www.cercs.gatech.edu/tech-reports/tr2010/git-cercs-10-05.pdf
>>
>> * Rather than convert the Cog/Image to be multi-threaded, could have
>> many grid nodes running their own domain, communicating with high speed
>> shared memory.
>> http://www.cs.ucsb.edu/~nanli/projects/cs270.pdf
>> http://osnet.cs.binghamton.edu/publications/hines07memx.pdf
>>
>> * AMD's hardware virtualisation eliminated a Ring and also segmented
>> memory protection used by virtualisation to separate address spaces, so
>> 64-bit AMD can be slower.  Eliminating the OS kernel layer probably
>> bypasses this limitation since there would be only two levels -
>> Hypervisor & Cog.
>> https://lse.epita.fr/data/2011-lse-summer-week/xen.pdf
>>
>> * Its where all the cool kids hang out --> marketing opportunity
>>
>
> * Security versus lines of code...
>
>    Linux = 15.9 million (3.6 Kernel)
>    OSX = 86 million
>    FreeBSD = 6.25 million
>    OpenSolaris = 10 million
>    Windows = 64 million
>
>    Xen-ARM = 90,000
>    Xen-x86 = 140,000
>
> https://www.google.com/fusiontables/DataSource?docid=12Eg7Ru1CH5MIjomcfjaGKe2qBd9ynmSQni5CAioK
>
>
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper
>
>
>
>
>
>>
>>
>>>
>>> - what infrastructure is missing?  (e.g. what key drivers need
>>> implementing?)
>>
>> I'll need to understand Cog more. As a start, here are some porting and
>> API docs...
>>
>> http://events.linuxfoundation.org/sites/events/files/slides/Porting%20FreeBSD%20on%20Xen%20on%20ARM%20.pdf
>>
>>
>> http://oss.org.cn/ossdocs/server_storage/xen/interface/interface.html
>>
>> http://www.informit.com/articles/article.aspx?p=1160234&seqNum=4
>>
>> https://lse.epita.fr/data/2011-lse-summer-week/xen.pdf
>>
>> https://github.com/cloudius-systems/osv/blob/master/drivers/xenfront-xenbus.cc
>>
>>
>> cheers -ben
>>
>>>>
>>>> [1] http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos
>>>> [2] http://blog.codinghorror.com/understanding-user-and-kernel-mode/
>>>> [3] http://www.daemonology.net/freebsd-on-ec2/
>>>> [4] http://wiki.netbsd.org/amazon_ec2/amis/
>>>> [5] http://wiki.netbsd.org/amazon_ec2/build_your_own_ami/
>>>> [6] http://wiki.xen.org/wiki/Virtualization_Spectrum
>>>> [7] http://wiki.xen.org/wiki/FrontendDriver
>>>> [8] http://wiki.xen.org/wiki/Cloud_Operating_Systems
>>>
>>>
>>> Eliot (phone)
>>>
>>
>>
>>
>>
>
>
Very interesting thread.


You can also add Docker, an epitech guy's startup
https://xen-orchestra.com/blog/xen-and-docker-for-the-best/


And about the "key economic and managerial benefits" from this kind of
system : on-demand "elasticity" : to pay only for needed cpu, and to
avoid the slashsdot effect
link from Sven: http://zerg.erlangonxen.org/
100 ms to boot a VM gest to serve an http request and then exit ... very
elastic


The PharoNOS project looks great.

I just tried it on an ubuntu+xen and windosw8.1+hyperv dual boot
desktop, and it runs better on a guest VM with one core and 1GB RAM than
on the desktop host with 12 cores and 16 GB,  on both boot
configurations (almost every times not always)
funny

test is 0 tinyBenchmarks with a Pharo 3.0 VM:

config 1
Host = Ubuntu 14.04 + Xen 4.4.1, core i7  6 cores, 12 vcpu , 16 GB
Guest VM = PharoNOS (TinyCorelinux, 1 vcpu, 1GB)
(1) Ubuntu 14.04 on host : '1,523,809,523 bytecodes/sec; 219,893,944
sends/sec'
(2) PharoNOS Xen VM guest : 1,728,270,042 bytecodes/sec; 224,211,429
sends/sec

config 2: same hardware, booting on Windows8.1 pro with HyperV hypervisor:
Host = Windows 8.1 pro, 12 vcpu, 16 GB
Guest VM = PharoNOS , 1 vcpu, 1GB
(3) Host, Win 8.1 pro:   '1,595,015,576 bytecodes/sec; 206,330,393
sends/sec'
(4) PharoNOS Hyper-V VM guest :  1,651,612,903 bytecodes/sec;
201,435,694 sends/sec

Unfortunatly, I can't test it much, I have no network on my Xen vms for
now (it will come), I tested the available iso of the PharoNOS project



Regards,

Alain