Hi Willy, On Sat, Apr 11, 2009 at 09:10:20PM +0200, Willy Tarreau wrote: > I'm simply sending you a big kudos again for your live CD. I was > looking for a way to do 64-bit builds once in a while. I've just > installed the recent VirtualBox 2.2.0 on my 32-bit slackware, and > with it I can run a 64-bit distro. Guess what I'm running in it ? Thank you for posting this. FWIW, I am using QEMU, which is smaller than VirtualBox. It runs x86-64 code (including Owl ISOs) on 32-bit x86 just fine as well - I happened to test this on some occasions. Indeed, this kind of emulation is slow, and x86-64 CPUs are cheap, so there's little reason for doing things in this way. > Your 64-bit live CD is just the *only* live distro around offering > a C compiler in a 64-bit environment. I'm now using it to ensure > that haproxy cleanly builds both in 32 and 64bit environments, and > this is by far the most convenient solution I have found. And as an > added bonus, it boots very quickly ;-) OK, that's yet another reason for us to make an official x86-64 ISO. As you know, those we have so far are unofficial, which is wrong. > I know that this usage is far from being the main target of Openwall > but since it's the only one offering such useful features and that > level of quality and user-friendliness, I wanted to send a big "thank > you guys" for the amazing work you have done there ! You're welcome. Owl is quite selective about who its friends are. ;-) > If I may add a very minor suggestion : if in future builds you could > create the /us/src/.rpm.d/* directories, it would be even easier to > use the live CD to build RPMs. Right now I managed to do that using > a few mount --bind tricks. But as you see, this is not a showstopper. I don't think merely pre-creating those directories on the CD would change a thing - they would be read-only. Indeed, we could point .rpm.d to under /ram with a symlink and run "rpminit" - is that what you want? (Please see the rpminit(1) man page on Owl.) /ram is a bit too small, though. When we use the live CD to build any software (usually kernel modules, the kernel, or low-level tools for the system being installed), we normally mount an instance of tmpfs for that. For example, you can use: useradd -m rpm mount -t tmpfs tmpfs ~rpm -osize=100M,mode=700,uid=rpm,gid=rpm su - rpm rpminit I've just tested this under QEMU. Mounting a tmpfs right on /usr/src wouldn't be great as it would hide the kernel headers, as well as Owl packages and sources. (It is somewhat wrong that we install the kernel headers under /usr/src rather than introduce a glibc-kernheaders package, though.) Perhaps we should switch to using tmpfs instead of a RAM disk for /ram. Then a /usr/src/rpm.d symlink to /ram would make more sense. Alexander -- To unsubscribe, e-mail owl-users-unsubscribe_at_private and reply to the automated confirmation request that will be sent to you.Received on Sun Apr 12 2009 - 18:35:45 PDT
This archive was generated by hypermail 2.2.0 : Sun Apr 12 2009 - 18:36:03 PDT