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