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 _______________________________________________ Grml mailing list - [email protected] http://lists.mur.at/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://grml.supersized.org/
