Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111026044552.GA2122@openwall.com>
Date: Wed, 26 Oct 2011 08:45:52 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: kernel size

On Tue, Oct 25, 2011 at 11:23:51AM +0400, gremlin@...mlin.ru wrote:
> On 24-Oct-2011 22:05:06 +0400, Solar Designer wrote:
> 
>  > > It looks like we waste too much time on these size issues.
>  > I think we don't, but you say so each time. ;-)
> 
> Yes, as it is visible only from outside :-b

You might be over-estimating the time spent on this.  While this topic
is brought up once in a while, it is not a primary time eater.

For example, I've just figured the kernel size growth out in under an
hour, and I have a one-liner patch for it (adding .eh_frame to discard
list in arch/i386/kernel/vmlinux.lds.S).  I think it's desirable to fix
this regardless of the 2.88 MB "floppy" size limit.  It's just gcc's
change of default, which our kernel tree was ready for on x86_64, but
not yet on i386.  The patch brings these in sync.

Of course, you can say (and you'll be right) that we wouldn't even face
this issue with a newer kernel (where the x86_64 and i386 trees have
been merged together).  So it's a matter of our approach to development -
update things one by one (gcc first, then others) or many at once (gcc,
glibc, kernel).  These have their pros and cons.

> It is reasonable to not bother about the kernel size at all -
> for now, the "server" kernel 2.6.32 (which I use on most of
> my servers, including DDoS filters) is 4765520 bytes, and it
> includes only network and mass storage device support (though
> including some exotic hardware like 10Gbps network adapters).

Yes, we'll have to move to ISOLINUX before moving to RHEL6'ish kernels.

> OMFG... Don't waste time on that - simply stop bothering about
> ISO image size.

I am not going to bother about it for now.  But I realize that for some
of our prospective users Owl's small size is an advantage and a reason
to choose Owl over something else.  In fact, some have complained about
Owl already being too large (they did not realize that our LiveCDs
essentially include three copies of the system - installed, RPMs, sources).

I am not sure what to do about this, if anything.  We could cut down our
live system and exclude sources to make some prospective users more
willing to try Owl out, but there are also good reasons for actually
including everything in the ISOs.  Start building two sets of ISOs per
version/arch?  But we're already building four ISOs: stable vs. current,
and i686 vs. x86_64.  Building eight instead doesn't feel nice.

Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.