Daniel P. Berrange wrote:
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 mean no offense, but it seems like every time I say anything on this
list, people assume it means that I am advocating some change in the
core infrastructure that everybody should use. When in reality, I'm
merely trying to open the possibility to do something that just couldn't
be done before.
My livecd generation system is dog slow, but its something that joe-user
could download/install, and then use to create a custom livecd for
personal or very limited use, *WITHOUT* requiring them to su to root,
then have selinux disabled while livecd-creator runs.
Ok, so 99% of the people on this list can go ahead and think that that
new functionality serves no useful purpose. I admit, I don't have a lot
of users yet. But hey- I like it.
Getting back to your point- what I'm saying is that I'm not saying my
tool is the right tool for everyone's job. If you saw my anti-selinux
rant a while back, you may have noticed that I wasn't saying that
selinux shouldn't exist, just that maybe it isn't the right tool for
*every* job.
A while back on this list, I asked what parts of fedora required root
privileges to be rebuilt. I.e. why you couldn't just rpmbuild --rebuild
every last thing as a build user, never subjecting the build system to
the impact of building as root. The answer seemed to come back that the
only things that _really_ required root, were the creation of small
filesystem-disk images. My tool qfakeroot provides a solution for that,
and given the sizes of the images involved, will add but a few minutes
to the rpmbuild--rebuild time.
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.
No.
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.
Trust is not absolute. I may want to do all kinds of experimental
things with a LiveCD, that I wouldn't want to put on the particular
build system. And please, don't be obtuse like everyone seems to be on
this list and think that I just argued 180degrees against you. Your
point is fine, and one I agree with, and have considered before and
already take well into account. I'm _only_ suggesting that _maybe_
there are some people out there that can appreciate the functionality
I'm bringing to the table, even with it's relative costs.
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.
Yeah yeah, go ahead and be like the rest of the people here with that
attitude. Just focus on countering everything I say, instead of maybe,
just maybe admitting that the functionality I'm bringing to the table
might actually be useful for quite a few scenarios.
"Fallacy". I mean Puhlease... Would it cause the world to end if some
of the core fedora developers would try to actually be constructive?
Was your comment there _really_ necessary? Yeah!!! you showed me how
utterly wrong I was. What a 'fallacy' I uttered. Come on. Give me a
break.
-dmc
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
