<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 11, 2014 at 7:00 PM, Michael Thoreson <span dir="ltr"><<a href="mailto:m.thoreson@c4labs.ca" target="_blank">m.thoreson@c4labs.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As for making packages we just need to get the makefile(s) right and then I can use centos\fedora\debian\ubuntu vm's to make rpm's and debs. *BSD systems that use ports will take care of themselves once the project is included as the ports system builds ports periodically so them be added with pkg.<br>
</blockquote><div><br></div><div>We use devel/cook and devel/aegis (I will put a snapshot of our development instance up on <a href="http://down2earthcloud.com">down2earthcloud.com</a> [where we put all downloadable instances for now... the host <a href="http://petitecloud.org">petitecloud.org</a> only has 20GB of disk] in the next day or so).  Since cook uses a very different method of building then make you should study it but once learn it you will never go back to make.   See  <a href="http://miller.emu.id.au/pmiller/software/cook/cook-2.34.tut.pdf">http://miller.emu.id.au/pmiller/software/cook/cook-2.34.tut.pdf</a> and <a href="http://aegis.sourceforge.net/auug97.pdf">http://aegis.sourceforge.net/auug97.pdf</a> for a conceptual overview.    Linux is currently built in the cook-blank/scrap-linux and deployed in cook-blank/deploy-linux (both are optional recipes in src/build/cook/Howto.cook).   If you have any questions on how to use either ask.   As you get more comfortable with stuff we should like set up pa aget repo on the public internet.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I don't know enough about making linux binaries yet to write a how to but it is something I can work at.<br></blockquote><div><br></div><div>The Java is extremely portable and the C is very simple (for now we are planning to convert the core over to C sometime before 0.4 [basic clustering/security]) <br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I agree you can go too far with the lego method but the outcome can be very entertaining either "wow that is not practical at all" or "omg that failed spectacularly with fireworks and the like" especially on those nights were exhaustion has faded into a dim memory and some bizarre part of your mind believes it can work so you keep banging your head against the wall :)<br>
</blockquote><div><br></div><div>Or even worse some GSoC kid came up with this brilliant "security" model that allows wonderful things like having scripts that run as root being embedded as a part of the API call (the same script btw has the username/password in plain text in it)<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I might be able to take the "unstable" environment further than a living of an NYC apartment to extreme conditions. It would be a very small market but still one that could be an option. Remote sites or mobile sites that may have extreme temperature stress or need a small, light and low power solutions could benefit from some new pico and thin mini-itx platforms running a light weight hypervisor which could run any os\app combo that may be needed. Another future option is ARM platforms since there is current development for a FreeBSD arm port.<br>
</blockquote><div><br></div><div>We are thinking along very simelar lines (your examples are more extreme but not out of line with what we have in mind with things like "cloud on a stick" [bootable USB drive with a full mini-cloud on it] one of our use cases for this idea is ability to give finals in classes that require computers but to prevent cheating only very limited connections are allowed,.... right now I have 0.2.5 to get out (I have one last feature to add and then deal with any fall out a "brilliant idiot" test [i.e. I, as main developer, purposely try to <bleep> PetiteCloud up [note I am complete clutch with hardware so when we tell friends and family that our goal is that PetiteCloud be "Aryeh proof" they know that is being as mean as we can think of then then more])... that main feature being able to specific multiple "disks" for each instance.    As for the long term our main goal in pre-1.0 is to master the scaling problem (we can scale up to any size) and one of the goals of 2.0 is the shrinking problem (many of the apps we have in mind require both at the same time)<br>
</div><br></div>-- <br><div dir="ltr">Aryeh M. Friedman, Lead Developer, <a href="http://www.PetiteCloud.org" target="_blank">http://www.PetiteCloud.org</a><br></div>
</div></div>