[Grml] removal of "buffer" command? alternatives?

Michael Prokop mika at grml.org
Wed Dec 28 14:22:16 CET 2011

* Frank Terbeck [Wed Dec 28, 2011 at 01:43:22PM +0100]:
> Csillag Tamas wrote:

> > irssi

> I'd like at least one IRC client on the ISO, too. It's useful for crying
> for help when something goes haywire. Irssi or epic are reasonable
> suspects, I guess. Maybe even weechat (although I think the default
> behaviour is insane).

Hm, good point. But the ones needing help need network
access anyway, so they can just install their favourite IRC client
anyway, no? (I'm aware that we did provide out-of-the-box config for
irssi which just joined our channel, but I didn't see that many
people using that actually.)

> And finally: I am not a fan of the grml96 ISOs and I was only realising
> that they existed after the release. Here is why I don't like them: The
> cleaned up package list leaves us with huge amounts of free space on a
> standard blank CD. It would be trivial to say "What, you'd like afio
> back? Well. No problem. Readded it. Get tomorrows daily image."

> Now there is a new artificial limit: If we add a lot of new packages,
> then grml96 may overflow. And if that limits what we'd include in our
> images, that would be *quite* unfortunate to say the least.

> I realise, that grml96 may contain a completely different set of
> packages then the single-arch package. But I wouldn't want to diverge
> too much, because it would lead to confusion and pain. And it's trivial
> to create a bootable medium with both architectures using, say,
> grml2usb.

grml96 is the result of one single grml2iso command line, so it
won't receive a different package list than grml32 and grml64 but
instead will just continue being the result of the two ISOs getting
combined, from my POV.

And IIRC Christian already mentioned that he doesn't consider the
"artificial limit" an real issue for grml96, and I don't really

I don't consider CDs that relevant anymore nowadays. Either the
hardware can boot of USB/PXE or the hardware is that old that an old
version/release should work as well. So from my POV it's more
important to provide a decent grml32/grml64 version which has sane
size limits. grml96 could also increase to over 700MB in size, since
<=512MB won't be possible anyway and the next common USB pen size
limit is 1GB. If booting from CD is *that* important and relevant
you shouldn't care about the MBs that you're "losing" with burning
the ~350MB grml32/grml64 ISO to CD.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://ml.grml.org/pipermail/grml/attachments/20111228/b0515c68/attachment.pgp>

More information about the Grml mailing list