On Thu, Jan 24, 2008 at 06:59:47PM -0600, Douglas McClendon wrote: > Daniel P. Berrange wrote: > > > > >Plain QEMU is unusably slow for doing any real work - particularly compute > >and disk intensive stuff like builds / composes. > > Takes 12 hours to compose my 1G LiveDVD, involving a full anaconda http > install under qemu, followed by mksquashfs of the result. Honestly I do > a lot of data shuffling, and think that I could probably halve that time > if I wasn't more interested in further functionality at the moment than > I am in performance. A 12 hour compose time fundmanetally limits the quality / speedy delivery of LiveCDs because the turn around time between compose + QA cycles is being bottlenecked. You can only do one compose & QA cycle per day. If a chroot install takes < 1 hour you can get through 5 or more compose & QA cycles a day. > I'll take that 12 hours over the 1hr for livecd-creator any day of the > week, knowing that I'm not running about 1000 rpm post install scripts > under the limited protection of a chroot with selinux disabled. > Combined with the comfort of knowing that if I do a compose on a > different piece of hardware, that those 1000 scripts will have no chance > to sneakily incur any host build dependencies based on their access to a > random /proc (as opposed to the consistency of always identical qemu /proc). Do you inspect all these %post scripts ahead of time each time you do a 'yum update' for your host machine. Every time you yum update you're running the same scripts in your host without even the chroot protection. And if you don't trust the RPMs you're using to build the LiveCD images, why should any user trust the resulting LiveCD you're about to distribute. If you really don't trust the RPMs you're about to compose, then run the compose on a throw away host - just re-kickstart it after execution. > You may call 12 hours for a compose unusably slow. I don't. And > computers and software get improved all the time, so maybe in 3 years, > that 12 hours will just become "order a pizza and wait for the results". That's a fallacy. History shows that software increases its resource requirements to easily match increases in hardware speed. Compare total install time between RHL 5 and Fedora 8 - hardware has increased in performance dramatically, but install time is still effectivelly unchanged. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
