On Wed, 30 Jan 2013 13:01:20 +0000 Tom Hacohen
<tom.haco...@samsung.com> wrote:

> On 30/01/13 11:32, Bertrand Jacquin wrote:
> > Hi,
> >
> > For e5 buildbot/whatever we will need different OS and architecture
> > to test. So if some volunteer are free to build some, we can gladly
> > host them.
> >
> > Needed OS :
> >
> >   - Windows XP x86
> >   - Windows XP x86_64
> >   - Windows Vista x86_64
> >   - Windows 7 x86_64
> >   - Windows 8 x86_64
> >
> >   (maybe more declination are needed ?)
> >
> >   - Mac OS X Snow Leopard
> >   - Mac OS X Lion
> >   - Mac OS X Mountain Lion
> >
> >   - FreeBSD 8
> >   - FreeBSD 9
> >
> >   - NetBSD 4.0 (still supported)
> >   - NetBSD 6.0 (still supported)
> >   - NetBSD 6.0
> >
> >   - OpenBSD 5.2
> >
> >   - ?? Other, and maybe more declination on previous list

Various versions of Linux as well, or did you leave them off coz you
don't need any help setting them up?

> > Here are characteristics :
> >
> >   - More the system is light, faster we can transfer it
> >   - dd if=/dev/zero of=/device at first
> >   - Make the image available as a disk gzip/xz format (as main
> > content will be unused space defined with zeros previously)
> >   - Use virtIO for network, disk and console
> >   - kernel parameters:
> >      panic=5 clocksource=kvm-clock console=tty0 console=ttyS0,115200
> >   - 1 network interface with DHCP
> >   - syslog everything to host: log.e5 (I can send you a syslog-ng
> > conf if necessery)
> >   - smtp relay: smtp.e5 (I can send you a exim config)
> >   - minimal install
> >   - watchdog (wdd prefered http://linux.exosec.net/watchdog/daemon/)
> >   - necessary packages
> >      - snmpd
> >      - acpid
> 
> Some comments:
> 
> You can't run Mac OS in a vm.

It's possible, and it used to be legal, but Apple changed their license
terms to make that illegal now.  Now it's only legal to run Mac OSX on
actual Apple branded hardware.  Even if you own the Apple hardware,
it's still illegal to run Mac OSX on a virtual machine on something
else.

I think that's a seriously silly mistake by Apple, as it prevents
exactly the sort of thing we are trying to do here.  Unfunded open
source project wanting to be portable to everything, including Mac OSX,
gets shot in the back by silly Apple policies so we can't afford to
support them.  Sooo, thanks to Apple, it's way too hard to support
them for portable open source projects.

I WANT to produce open source code that runs under Mac OSX as well as
Windows and Linux and ..., but I came to the conclusion that Mac OSX
users are just gonna have to wait until poor old me has a couple of
grand laying around doing nothing before I can afford to support them.
Not my fault, Apples fault, but the MAC OSX users scream blue bloody
murder that I don't want to support them.  It's really hard to justify
purchasing expensive hardware just for a few open source projects.  I
know there's Mac Mini's, but they still cost twice as much as the money
I spent on an equivalent development PC.  I WANT to support them, Apple
tied my hands and I can't.

Why do I get the feeling Samsung's not gonna donate Apple hardware to
open source EFL development any time soon?  No love lost there.  lol

While on the subject, we got suitable licenses for the Windows vms?

> I think it's too soon for this. We haven't really figured out our
> whole CI process. Lets have those VMs when all of that is sorted.

I agree here, especially with the talk of moving from buildbot to
jenkins.  Let that settle, as it might change the requirements.


A few words of my own from my experience doing similar stuff -

A very minimal default install of the OS, followed by a script that can
install the rest of the build tools and build dependencies needed, is
what I do.  That makes things easy to reconstruct each OS later.  It
should even help when building variants for any specific OS if the
script has a bit of flexibility.


A lot of people say "just use ssh" for connecting to the systems to
automate the builds.  Now I don't know what buildbot and jenkins use,
so this part might not be needed to say.  I think ssh is a mistake
under these sorts of circumstances, coz it's too heavy weight when you
are running lots of VMs to compile lots of source code, on local
virtual machines.  They are throw away VMs that can be recreated from
scratch, running a local network that is scripted from the local host.
They don't NEED end to end encryption and security to slow things down,
they NEED all the CPU cycles we can throw at them.  Serial terminals
are much better for this sort of thing, and even Windows can be
scripted via serial terminal.  Waaaay less overhead.

On the other hand, ssh for us developers to connect from the outside
world is still good there, that's the sort of thing ssh is for.  For
the internal build scripting though, it's just excess overhead that gets
in the way.  Ssh is just lazy, coz it's used for everything else,
better to use the right tool for the job.

Seriously, you might think ssh is not THAT much overhead, but when you
are looking at dozens of vms, all busy compiling source code as quick
as they can, and sending build logs back, then things start to
multiply.  You really don't want extra overhead then.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

Attachment: signature.asc
Description: PGP signature

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to