[Grml] grml-small - raise ISO-size?
Marc Haber
mh+grml at zugschlus.de
Wed Sep 19 13:14:41 CEST 2007
On Mon, Sep 17, 2007 at 11:25:50PM +0200, Michael Prokop wrote:
> grml-small 0.1 started with 49MB total ISO-size,
> grml-small 0.2 had 56MB,
> grml-small 0.3 had 58MB and
> grml-small 0.4 has 60MB now.
>
> So it's definitely growing (due to the new features of kernel and
> userland in every single release).
Yes, I see that with one crying and one smiling eye.
> The main problem for the grml team so far was, to keep the ISO size
> of grml-small as small as possible but nevertheless provide all the
> software people wanted to see included. Another important drawback
> is the separate kernel version, which had to be maintained
> *additionally* to the main (non-small) grml-kernel.
I understand that, but I could live with "not the latest" and greatesta
kernel in grml-small. Would the work load significantly decrease if
you would only build the -small kernel for every fifth image you
build? Or, can kernel maintenance maybe automated (for example by
obtaining the -small .config file by scripting on the normal .config
file)?
> Using grml-live we are able to build grml-small with one single
> command now. The resulting ISO for grml-small has a size of 133MB
> currently - though the ISO still provides some more software than
> grml-small 0.4 did (like python, aptitude,...) and even a full
> featured /usr/share/doc (24MB) plus the current grml-kernel
> (2.6.22-grml). So the 133MB ISO could be stripped down a little bit
> further (maybe to something like 125MB) without losing toooo much.
I do not care about python, and with most of /var stripped out,
aptitude is not useable anyway. I do not like the idea of having a
larger grml iso at all, mostly because I'll lose the business card CD
(although I have not used grml on a business card CD for at least two
years now), and grml toram takes even more longer now. Additionally,
low memory boxes lose the ability to use grml toram.
> My suggestion therefore is to raise the ISO-size of grml-small to
> something like <=128MB (so it still fits on 128MB USB pens).
Sigh. If you think this is best for the project, go ahead.
> Pros:
>
> * some more software could be included (and /usr/share/doc could be
> shipped as well maybe)
That's a non-pro, it's a con. Grml-small's advantage is that it does
not have ballast.
> * use of same kernel version as with full grml -> installing
> additional Debian kernel packages not being available on the ISO
> yet (due to lack of space) is no problem furthermore
The current -small kernel is just fine.
> As grml-live will be available to the public soon and everyone might
> build his own grml-version ;-), everyone could build his own
> grml-small version anyway.
I would probably do that, yes.
> So what's *your* opinion about "grml-small grows to ~125MB"?
I don't like the idea too much.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
More information about the Grml
mailing list