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

[Frank Terbeck]

Csillag Tamas wrote:
> On Wed, Dec 28, 2011 at 02:28:13AM +0100, Ulrich Dangel wrote:
[...]
>> http://daily.grml.org:8080/job/grml64_Release/25/artifact/changelog.txt
>> which has a removed section 
>
> I am a bit sad glancing on that list.
> Some of the tools removed are big (ok, so one can accept that and it
> can be justified), but most of them are small so from the size point
> of view it does not help if you remove.

Here is my take on the subject: As other members of the team have
pointed out, these rather severe have been done because there we don't
have the manpower to keep the large set of packages rolling properly. We
do realise, that not everything may be perfect. But it is equally
important, that everyone understands, that the few people who do the
major work on rolling out releases (and I am not one of them by a long
shot) on a fairly regular schedule only have 24 hours in a day, just
like everyone else. The workload needed to be contained at a doable
level.

That aside, I don't see the changes as being damaging, but rather as a
chance. I agree that there are some packages that are missing. But it's
only *now* that we get to know what these packages were. It is a well
deserved cleanup of our list of packages, because we now get to see
which packages deserve attention and which do not.



> afio

Agreed. I used to have my backups handled with afio scripts. But there
seems to be issues with afio copyright (see
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509287> for details)
and there is no package in debian testing right now.

So that's kind of a little hairy. (But I'd like to see this packages
included again, too, if that's possible at all.)

> aircrack-ng

No official debian package. We can't maintain it.
<http://packages.qa.debian.org/a/aircrack-ng.html>

Otherwise it might well be in.

> awesome (i do not use this a friend does)

Yes. WindowManagers. Again. We won't be maintaining a proper
configuration for awesome and we'd also like this particular part of the
distribution to be more uniform than before. If you must have it,
grml-live is your friend.

> build-essential (so from now on building inside grml will be not that easy)
> gcc, g++ also gone...

I'm finding this a little sad too. But build-essential is probably not
enough to build most stuff anyway. So you'll need to install stuff
already and you can just install build-essential along the way with
that.

> comgt (180k)

Can probably included. Our very own jimmy is the maintainer of the
debian package, even. ;)

> dns2tcp (201k) (I am using this if I stay at a hotel with insane
> internet rates)

A bit specialised, but a debian package is available and it would be
reasonable added functionality at the cost of a pretty small package.
So, I'd be for including this.

> emacs23 (this is a beast I know, more than one friend use this)

Yeah. No. Don't get me wrong, I'm an emacs user *myself*. But if you
don't have your setup along, it's useless. Well, not useless, but way
less useful.

I'd include `mg' which is a tiny emacs-like editor.

If you want emacs23 (or even 24) - again - grml-live is your friend.

> fakeroot

What's the use-case here? I mean, including it would be possible, but I
don't see what for, off hand.

> firmware-qlogic (this means that it will not boot on server containing
> FC card?)

Hm. this one's non-free. I don't know what else is blocking that.
Someone else would have to comment.

> 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).

> ipmitool

Um, no idea... I guess this one wouldn't hurt.

> ldapvi

Again, no idea.

> libnet-*-perl

As a Perl hacker, I'd agree. But I don't know how much space this would
take. Maintaining such a proper list wouldn't be trivial either, I'd
imagine.

> mutt

I don't know. Without setup, you can't do much with mutt. I think this
is a clear case for a private package list and grml-live again.

> postfix (I was using this for educating mailing basics also good for
>          testing)

grml-live, I guess.

> pppoe (no one with adsl anymore?)

Hm. Yeah. Maybe someone can comment on that one.

> radvd

No opinion.

> runit (520k)

What for? We don't use it.

> rxvt-unicode (this was part or the release from the begining)

There's xterm. I wouldn't mind if this would be included. But I guess
this is yet another candidate for grml-live.

> tcptraceroute

I wouldn't mind

> virtualbox

grml-live. Really.

> tp_smapi

There were issues with dmks, IIRC.

> zsh-lovers is your package afaik

Well, I don't really see the use on a simple disk. Never looked at it
even once on there.

[...]
> What kind of testing is needed to get (most/some of) the tools back
> on the cd? I used to be around on IRC, but when some folk switched
> from english I was unable to follow the conversation so I dropped out.

Well, it would be useful to do some research before requesting packages:
Is there a debian package, is it free/non-free, are there any severe
problems with it? Etc. etc.


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.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925