<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Igor Stasenko wrote:
<blockquote
cite="mid:CAEYrNzAtV9u=_X36BUnJx9o4gPJp9pKFAveO0vfY3TigFFfmhQ@mail.gmail.com"
type="cite">
<pre wrap="">
On 27 October 2012 02:40, <a class="moz-txt-link-rfc2396E" href="mailto:btc@openinworld.com"><btc@openinworld.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Igor Stasenko wrote:
On 26 October 2012 21:17, Stéphane Ducasse <a class="moz-txt-link-rfc2396E" href="mailto:stephane.ducasse@inria.fr"><stephane.ducasse@inria.fr></a> wrote:
Thanks a lot igor!
I love the noise of burning servers under the pressure of integration scripts.
At least we achieved that part :)
Well, to build VM and all 3-rd party libs from scratch it takes 1 hour
and 5 minutes on slave..
a bit too much to my taste.. perhaps we will need to rearrange jobs to
build thirdparty libs separately,
because they don't change that often.
Perhaps a bit fanciful and wishful thinking.... but what would be cool would be a preconfigured operating system "virtual appliance" that I could download and run in VMWare or VirtualBox, which would download and run build-jobs from a central server, and would push results back to the main server. I'd be happy to contribute cycles and bandwidth to such a task. Ideally this could be hands-off from my side once I booted the appliance. Also from a security perspective there should be some configuration outside the appliance at the VMWare level to restrict appliance network access to the central server only. This would scaling as the number of thirdparty libs grows. Developers should be able to configure their own lib to be run more often than others.
</pre>
</blockquote>
<pre wrap=""><!---->
Well, developers can always build these libs by themselves. But users can't :)
I don't think that the number of 3rd-party libs will explode that you
will need to focus on making things easy (as you proposed).
There are two reasons why someone would like to bundle thirdparty
library with VM:
- no 'official' binary available (like with cairo on windows) , or
you need to build it with custom settings.
</pre>
</blockquote>
<br>
Ahh... I mis-understood slightly. I was replying in pharo-project and
thinking about community contributions to the Configuration Browser.
I thought I had seen some talk of putting those through continuous
integration testing and was thinking in case that turned out to require
lots of cpu time, then farming it out to interested members of the
community might help. At the Smalltalk level it might work to
distribute only a Linux appliance doing a highly repetitive first pass,
from which successes proceed with other platform testing on the central
servers.<br>
<br>
<blockquote
cite="mid:CAEYrNzAtV9u=_X36BUnJx9o4gPJp9pKFAveO0vfY3TigFFfmhQ@mail.gmail.com"
type="cite">
<pre wrap="">
Aside of that, the idea about virtual appliance is cool by itself :)
There's one little problem, however: proprietary licenses..
Microsoft is not very happy running multiple copies of Windows
registered using same serial number.
So, this seems to be an issue.
That's not the case for Linux , of course.. but on linux you barely
need to build libs either:
they can be easily installed from distro(s), without much hassle.
For Mac OS, i'm not sure, but i assume the worst (like Microsoft).
Software companies stuck in 80's and keep exploiting a business model
where 'copying files' their main source of income.
Hoping that with emergence of cloud computing people will slowly
abandon that idea :)
</pre>
</blockquote>
agreed.<br>
<blockquote
cite="mid:CAEYrNzAtV9u=_X36BUnJx9o4gPJp9pKFAveO0vfY3TigFFfmhQ@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">just a passing thought... cheers -ben
Stef
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>