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

[Tom {Tomcat} Oehser]

Hi-

Up until this release, the 'buffer' command was included.

I use this all the time. Things like:

nc -l 12345 | buffer -z256k -p75 -m10m -o /dev/sda

Gone? :(

Is there an alternative?

-Tom
--
"Let us do our duty in our shop or our kitchen, the market, the street, the
office, the school, the home, just as faithfully as if we stood in the front
rank of some great battle, and we knew that victory for mankind depended upon
our bravery, strength, and skill. When we do that the humblest of us will be
serving in that great army which achieves the welfare of the world."
--Theodore Parker
The little girl expects no declaration of tenderness from her doll.
She loves it -- and that's all. It is thus that we should love.
-- DeGourmont

[Tom {Tomcat} Oehser]

Hmmm... 'atop' also? Not as bad as 'buffer', but, I'm having withdrawal.

Is there a list of what was removed?

I'm unconvinced that filling 50% of iso images with unused stuff
(64 unused on 32, 32 unused on 64...) is an ideal trade-off. I'm
just sayin...

For now I'm back on 11.5...

-Tom

Post by Tom {Tomcat} Oehser
Hi-
Up until this release, the 'buffer' command was included.
nc -l 12345 | buffer -z256k -p75 -m10m -o /dev/sda
Gone? :(
Is there an alternative?
-Tom
--
"Let us do our duty in our shop or our kitchen, the market, the street, the
office, the school, the home, just as faithfully as if we stood in the front
rank of some great battle, and we knew that victory for mankind depended upon
our bravery, strength, and skill. When we do that the humblest of us will be
serving in that great army which achieves the welfare of the world."
--Theodore Parker
The little girl expects no declaration of tenderness from her doll.
She loves it -- and that's all. It is thus that we should love.
-- DeGourmont
_______________________________________________
Grml mailing list - Grml at ml.grml.org
http://ml.grml.org/mailman/listinfo/grml
join #grml on irc.freenode.org
grml-devel-blog: http://blog.grml.org/

--
"Let us do our duty in our shop or our kitchen, the market, the street, the
office, the school, the home, just as faithfully as if we stood in the front
rank of some great battle, and we knew that victory for mankind depended upon
our bravery, strength, and skill. When we do that the humblest of us will be
serving in that great army which achieves the welfare of the world."
--Theodore Parker
The little girl expects no declaration of tenderness from her doll.
She loves it -- and that's all. It is thus that we should love.
-- DeGourmont

[Ulrich Dangel]

* Tom {Tomcat} Oehser wrote [28.12.11 00:45]:
Hi,

Post by Tom {Tomcat} Oehser
Hmmm... 'atop' also? Not as bad as 'buffer', but, I'm having withdrawal.

Yes, have a look at htop instead.

Post by Tom {Tomcat} Oehser
Is there a list of what was removed?

Yes, you can either create your own list by comapring the dpkg selection
files or use
http://daily.grml.org:8080/job/grml64_Release/25/artifact/changelog.txt
which has a removed section

Post by Tom {Tomcat} Oehser
I'm unconvinced that filling 50% of iso images with unused stuff
(64 unused on 32, 32 unused on 64...) is an ideal trade-off. I'm
just sayin...

Hm? The default images are 64bit or 32bit only.

Ulrich

[Tom {Tomcat} Oehser]

Post by Ulrich Dangel
Yes, have a look at htop instead.

atop/htop I don't care so much about, but, buffer is more of an issue.

Ouch! Even lzop is gone! This is 2/3 or a command I use very often!

buffer -i <device> -z256k -p75 -m10m | lzop | buffer | nc <hostname>

And while I can always fake buffer with 'dd' and bad performance, if
I have a backup in .lzop format, I'm just screwed now!

Post by Ulrich Dangel

Post by Tom {Tomcat} Oehser
I'm unconvinced that filling 50% of iso images with unused stuff
(64 unused on 32, 32 unused on 64...) is an ideal trade-off. I'm
just sayin...

Hm? The default images are 64bit or 32bit only.

I guess I was figuring that the cute point of going from 700mb to 350mb
was to fit both images on the 96.

Frankly, I boot GRML from 4GB USB sticks, which are costing $8, I don't even
put an optical drive in machines anymore. I do not see the point of reducing
functionality. For what? Bandwidth is going up, media sizes are going up,
prices are going down... I think it is a good idea to keep the media size at
CDROM size or less, but, 350? I do - not - see - the - point! I mean, what
media are smaller than 700 and larger than 300? How many people are going to
prefer the quicker download? First ubuntu, now grml? <rant='off'/>

When I read the description, I thought, this sounds fine, after all, I don't
need my sysadmin tool to have 50 zillion window managers... but I didn't
expect to find text-mode command-line tools I use like buffer and atop gone!
Now I'm afraid to look to see what else is missing that matters...

Now, I love smallifying more than _anyone_ - tomsrtbt was my doing, back in
the day - and I could certainly figure out how to customize and add stuff in.

But, the reality is that I switched from my own tomsrtbt to knoppix and then
to grml because they "just worked" - grml has the lvm2 and the swraid and the
command line tools I need - it had become the 'answer' to my bootable system
needs. For me, going from 700=>350 has no "upside", with a fast connection
and a 4GB USB stick.

Glancing through the "removed" list, I don't _know_ i'll need arj or bin86 or
cpuburn or dsniff or expect or fatattr or gdb or hexedit or info or etcetera
during a recovery situation - but I know I'd rather have them than not have
them!

Is the "full" version just *gone*? I really *liked* the mix of software there!

-ack! -Tom
--
"Let us do our duty in our shop or our kitchen, the market, the street, the
office, the school, the home, just as faithfully as if we stood in the front
rank of some great battle, and we knew that victory for mankind depended upon
our bravery, strength, and skill. When we do that the humblest of us will be
serving in that great army which achieves the welfare of the world."
--Theodore Parker
The little girl expects no declaration of tenderness from her doll.
She loves it -- and that's all. It is thus that we should love.
-- DeGourmont

[Ulrich Dangel]

Post by Tom {Tomcat} Oehser
Ouch! Even lzop is gone! This is 2/3 or a command I use very often!
buffer -i <device> -z256k -p75 -m10m | lzop | buffer | nc <hostname>
And while I can always fake buffer with 'dd' and bad performance, if
I have a backup in .lzop format, I'm just screwed now!

I added lzop to the package list. The next daily images will contain
lzop - http://git.io/H2XqNQ

Post by Tom {Tomcat} Oehser

Post by Ulrich Dangel
Hm? The default images are 64bit or 32bit only.

I guess I was figuring that the cute point of going from 700mb to 350mb
was to fit both images on the 96.

Coincidence. We didn't even plan to release grml96 but a user pointed it
out that it would be neat to have both of them on a ISO image with the
current size.

Post by Tom {Tomcat} Oehser
Frankly, I boot GRML from 4GB USB sticks, which are costing $8, I don't even
put an optical drive in machines anymore. I do not see the point of reducing
functionality. For what? Bandwidth is going up, media sizes are going up,
prices are going down... I think it is a good idea to keep the media size at
CDROM size or less, but, 350? I do - not - see - the - point! I mean, what
media are smaller than 700 and larger than 300? How many people are going to
prefer the quicker download? First ubuntu, now grml? <rant='off'/>

First of all it is about manpower. We do not have enough man power to
release all the flavours and test everything. And it is not only about
the size but download speed is also a big factor. And it also takes more
time to transfer an image into ram (grml2ram) with the bigger
version. And loading the old 700mb image into RAM is not possible on
systems with only 512MB ram.

OTOH it is also possible to place grml for example on /boot and use it
as a rescue medium directly from the boot partition. Most /boot
partitions are not bigger than 500MB.

Post by Tom {Tomcat} Oehser
But, the reality is that I switched from my own tomsrtbt to knoppix and then
to grml because they "just worked" - grml has the lvm2 and the swraid and the
command line tools I need - it had become the 'answer' to my bootable system
needs. For me, going from 700=>350 has no "upside", with a fast connection
and a 4GB USB stick.

JFTR lvm/swraid etc. are still available. We just removed software like

Post by Tom {Tomcat} Oehser
Glancing through the "removed" list, I don't _know_ i'll need arj or bin86 or
cpuburn or dsniff or expect or fatattr or gdb or hexedit or info or etcetera
during a recovery situation - but I know I'd rather have them than not have
them!

We readded hexedit. But tbh i don't think dsniff or expect are really
useful on a live cd.

Post by Tom {Tomcat} Oehser
Is the "full" version just *gone*? I really *liked* the mix of software there!

The package list is still in the git repository (grml-live) under the
name grml-full. We need volunteers doing the work. The current team
is not able to produce it. Brad Cable already offered his help re.
GRML_XL.

Btw. if you are interested in this topic we are already discussing it on
grml-devel, please have a look at the grml devel mailinglist
<http://ml.grml.org/mailman/listinfo/grml-devel> i already answered some
details in
<http://ml.grml.org/pipermail/grml-devel/2011-December/000215.html> and
the other messages. It would be great if we can discuss the issue on the
grml-devel mailingst.


cheers,
Ulrich

P.S: For a short introduction about remastering Grml have a look at
http://blog.grml.org/archives/364-Remastering-Grml-2011.12-will-be-as-easy-as-never-before.html

[Csillag Tamas]

Hi,

Post by Ulrich Dangel
Hi,

Post by Tom {Tomcat} Oehser
Hmmm... 'atop' also? Not as bad as 'buffer', but, I'm having withdrawal.

Yes, have a look at htop instead.

Post by Tom {Tomcat} Oehser
Is there a list of what was removed?

Yes, you can either create your own list by comapring the dpkg selection
files or use
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.

I name just a few:
afio
aircrack-ng
awesome (i do not use this a friend does)
build-essential (so from now on building inside grml will be not that easy)
gcc, g++ also gone...
comgt (180k)
dns2tcp (201k) (I am using this if I stay at a hotel with insane internet rates)
emacs23 (this is a beast I know, more than one friend use this)
fakeroot
firmware-qlogic (this means that it will not boot on server containing FC card?)
irssi
ipmitool
ldapvi
libnet-*-perl
mutt
postfix (I was using this for educating mailing basics also good for
testing)
pppoe (no one with adsl anymore?)
radvd
runit (520k)
rxvt-unicode (this was part or the release from the begining)
tcptraceroute
virtualbox
tp_smapi
zsh-lovers is your package afaik

If a tool is used when you are online it makes sense to remove it (nsd,
bind9) and one can reinstall easily.
If you remove pppoe how can one connect facing an adsl connection?
If an package mostly used offline is removed a functionality is lost.

I make my /boot 1Gb to be able to put a grml there for recovery
purposes.

I used to make my own (remaster) grml flavour and a bit of this or
that. But now that most of the tools gone maybe I will just stick to
the old one.

I used to recommend grml to friends who are not that experienced to
make their own grml (and to tell the truth most of us are just lazy or
lack the time).

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.

I want grml to be *the* rescue/sysadmin cd again not just one of the
bootable linux cds out there.
Thanks.

Regards,
cstamas

[Christian Hofstaedtler]

Post by Csillag Tamas
[..]
pppoe (no one with adsl anymore?)
[..]
If a tool is used when you are online it makes sense to remove it (nsd,
bind9) and one can reinstall easily.
If you remove pppoe how can one connect facing an adsl connection?
If an package mostly used offline is removed a functionality is lost.

pppoe is the old rp-pppoe code.

ppp (which is included) can do normal PPP and PPPoE.

Please check your facts before bringing up red herrings.

-ch

[Csillag Tamas]

Post by Christian Hofstaedtler

Post by Csillag Tamas
[..]
pppoe (no one with adsl anymore?)
[..]
If a tool is used when you are online it makes sense to remove it (nsd,
bind9) and one can reinstall easily.
If you remove pppoe how can one connect facing an adsl connection?
If an package mostly used offline is removed a functionality is lost.

pppoe is the old rp-pppoe code.
ppp (which is included) can do normal PPP and PPPoE.
Please check your facts before bringing up red herrings.

Sorry If I made mistakes. It was unintentional.

Regards,
cstamas

[Frank Terbeck]

[...]

Post by Csillag Tamas

Post by Ulrich Dangel
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.

Post by Csillag Tamas
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.)

Post by Csillag Tamas
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.

Post by Csillag Tamas
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.

Post by Csillag Tamas
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.

Post by Csillag Tamas
comgt (180k)

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

Post by Csillag Tamas
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.

Post by Csillag Tamas
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.

Post by Csillag Tamas
fakeroot

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

Post by Csillag Tamas
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.

Post by Csillag Tamas
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).

Post by Csillag Tamas
ipmitool

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

Post by Csillag Tamas
ldapvi

Again, no idea.

Post by Csillag Tamas
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.

Post by Csillag Tamas
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.

Post by Csillag Tamas
postfix (I was using this for educating mailing basics also good for
testing)

grml-live, I guess.

Post by Csillag Tamas
pppoe (no one with adsl anymore?)

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

Post by Csillag Tamas
radvd

No opinion.

Post by Csillag Tamas
runit (520k)

What for? We don't use it.

Post by Csillag Tamas
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.

Post by Csillag Tamas
tcptraceroute

I wouldn't mind

Post by Csillag Tamas
virtualbox

grml-live. Really.

Post by Csillag Tamas
tp_smapi

There were issues with dmks, IIRC.

Post by Csillag Tamas
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.

[...]

Post by Csillag Tamas
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

[Michael Prokop]

Post by Frank Terbeck

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

Post by Frank Terbeck
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
neither.

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.

regards,
-mika-
-------------- 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>

[Frank Terbeck]

Post by Michael Prokop

Post by Frank Terbeck
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.)

True. But still. ;)

The client I'm installing on my machines (I'm connected 24/7 on one
machine that has `irssi') is usually `epic4', because it does *not*
require any configuration.

% irc nickname irc.freenode.net

...and I'm on freenode. That's enough for quick chats, IMHO. `ircii' is
even simpler and only requires minimal dependencies, but epic is a
little more convenient to use out-of-the-box, I think (and we probably
ship its dependencies already). Both are alternatives for the `irc'
command used above.

If you're firmly against it, I don't care too much.


[...]

Post by Michael Prokop
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.

That's good. Although, I'd probably burden people with calling grml2iso
themselves. But you guys are better people than me. ;-)

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

So the policy is rather: Here's an image with grml32+64 for your
convenience, but be advised that it may not fit on a blank CD, but
probably on your USB pen-drive.

[...]

Post by Michael Prokop
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.

I couldn't agree more. The quicker `toram' beats the living shit out of
a half-full CD.

Regards, Frank

[Michael Prokop]

[irc client]

Post by Frank Terbeck

Post by Michael Prokop
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.)

True. But still. ;)
The client I'm installing on my machines (I'm connected 24/7 on one
machine that has `irssi') is usually `epic4', because it does *not*
require any configuration.
% irc nickname irc.freenode.net
...and I'm on freenode. That's enough for quick chats, IMHO. `ircii' is
even simpler and only requires minimal dependencies, but epic is a
little more convenient to use out-of-the-box, I think (and we probably
ship its dependencies already). Both are alternatives for the `irc'
command used above.

Ok thanks! Added them to the list of software packages open for
discussion.

Post by Frank Terbeck
[...]

Post by Michael Prokop
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.

That's good. Although, I'd probably burden people with calling grml2iso
themselves. But you guys are better people than me. ;-)

Let's see what kind of feedback we get regarding grml96.

Post by Frank Terbeck

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

So the policy is rather: Here's an image with grml32+64 for your
convenience, but be advised that it may not fit on a blank CD, but
probably on your USB pen-drive.

Jepp :)

Post by Frank Terbeck

Post by Michael Prokop
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.

I couldn't agree more. The quicker `toram' beats the living shit out of
a half-full CD.

:))

regards,
-mika-
-------------- 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/0a149576/attachment.pgp>

[Christian Hofstaedtler]

Post by Frank Terbeck
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 can see us releasing a single ISO, with a 32bit userland and
kernels for 64bit and 32bit for maybe the next or next-next release.
Ulrich is pushing hard for this, and (while I don't necessarily like
it) I think that's the correct way forward for the time being
(read: as long as i386 still lives).

Post by Frank Terbeck
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.

(As others have pointed out, grml96 is basically the result of
a grml2usb/grml2iso call.)

-ch

[Michael Prokop]

Post by Csillag Tamas
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.
afio

Will be further discussed [1]

Post by Csillag Tamas
aircrack-ng

Not available from Debian anymore/yet

Post by Csillag Tamas
awesome (i do not use this a friend does)

Was discussed but wasn't considered to be essential enough to be
included.

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

It's not considered as part of our install & rescue" mission to
compile software on the live system. If you want/need a
full-featured development environment we recommend remastering and
ship everything *you* need.

Post by Csillag Tamas
comgt (180k)

Thanks, re-added already: http://git.io/rtTeQg

Post by Csillag Tamas
dns2tcp (201k) (I am using this if I stay at a hotel with insane internet rates)

Will be further discussed [1]

Post by Csillag Tamas
emacs23 (this is a beast I know, more than one friend use this)

Sorry, I like and use emacs on my own, but emacs23 is just too large
for inclusion and doesn't match our "install & rescue" mission
neither.

Post by Csillag Tamas
fakeroot

Will be further discussed [1]

Post by Csillag Tamas
firmware-qlogic (this means that it will not boot on server containing FC card?)

Will be further discussed [1]

Post by Csillag Tamas
irssi

If you've network access you can just install it :)

Post by Csillag Tamas
ipmitool

Will be further discussed [1]

Post by Csillag Tamas
ldapvi

Will be further discussed [1]

Post by Csillag Tamas
libnet-*-perl

They used to be dependencies of other packages that aren't available
any longer. Is there any specific package that's considered relevant
for install and rescue?

Post by Csillag Tamas
mutt
postfix (I was using this for educating mailing basics also good for
testing)

Both shouldn't be relevant for a live system (and both don't match
the install and rescue mission), and if you've network access you
can once again just install it :)

Post by Csillag Tamas
pppoe (no one with adsl anymore?)

See Christian's mail

Post by Csillag Tamas
radvd

Will be further discussed [1]

Post by Csillag Tamas
runit (520k)

What's the benefit for the live system?

Post by Csillag Tamas
rxvt-unicode (this was part or the release from the begining)

xterm is there and should be enough for install and rescue mission, IMO

Post by Csillag Tamas
tcptraceroute

Will be further discussed [1]

Post by Csillag Tamas
virtualbox
tp_smapi

External kernel modules available via DKMS can't be shipped as
standalone binary Debian packages yet (due to limitations in DKMS).
Evgeni Golov is working on something to resolve that, but until this
is ready-to-go I'm afraid we won't provide external kernel packages.

Post by Csillag Tamas
zsh-lovers is your package afaik

It wasn't considered relevant enough for the install and rescue mission.
Not sure what our people think about it?

Post by Csillag Tamas
If a tool is used when you are online it makes sense to remove it (nsd,
bind9) and one can reinstall easily.
If you remove pppoe how can one connect facing an adsl connection?
If an package mostly used offline is removed a functionality is lost.

See Christian's mail (short version: ppp still supported, pppoe is
old and deprecated).

Post by Csillag Tamas
I make my /boot 1Gb to be able to put a grml there for recovery
purposes.

Same for me :)

Post by Csillag Tamas
I used to make my own (remaster) grml flavour and a bit of this or
that. But now that most of the tools gone maybe I will just stick to
the old one.

Remastering became easier than ever with this release:

http://blog.grml.org/archives/364-Remastering-Grml-2011.12-will-be-as-easy-as-never-before.html

And there's no reason to not remaster it. We can't provide one Grml
version that makes everyone happy. (And the old model just doesn't
work for us any longer if the manpower stays the same, see below.)

Post by Csillag Tamas
I used to recommend grml to friends who are not that experienced to
make their own grml (and to tell the truth most of us are just lazy or
lack the time).

Well, that's exactly our problem: we also lack time and we couldn't
keep the project up and running any longer if we wouldn't have
chosen the "reset button" for this release. With 3 flavours for 2
architectures we had way too many ISOs to support with the available
manpower.

Post by Csillag Tamas
What kind of testing is needed to get (most/some of) the tools back
on the cd?

Testing is very important, yes. But it's not just testing but also:

* taking care of failing builds (we provide daily builds at
http://grml.org/daily/ and trigger ISO builds with each git
commit)

* integrating packages into Grml tools (grml-quickconfig,
grml-x,...), window manager, providing sane default configs,...

* taking care of bugs (see http://bts.grml.org/grml/) and
user support ("why doesn't foo work?")

We highly appreciate and welcome any contributors helping us out.

Reminder: we're an open source project. Everyone can contribute and
improve areas where work needs to be done. But we just can't do all
the work for you if it's "just take but don't give back".

Post by Csillag Tamas
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.

Sorry for that. The channel language is english-only nowadays, so
please feel free to join the IRC channel again.

Post by Csillag Tamas
I want grml to be *the* rescue/sysadmin cd again not just one of the
bootable linux cds out there.
Thanks.

Thanks for your feedback, we highly appreciate that.

[1] Thanks for the list. We will review and discuss your software
selection in further detail, promised.

regards,
-mika-
-------------- 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/de1189f4/attachment.pgp>

[Csillag Tamas]

I also have a valid usecase.
(Maybe not one that grml targets.)

I used grml on my thinkpad x40 for a year when its expensive and
special HDD died. It served me quite well.
I also created a remastered version with the newest firefox and ubuntu
repo chromium on it.

What am I saying is that with these tools in question already
available it was (not perfect, but) quite usable.

When I left my pendrive in my friends car who gave me a lift to
debconf11 I tried grml-live to streamline the bootprocess for a brand
new grml and it also worked quite well.

So when I am talking about a tool I am also thinking about grml as an
educational tool, survive sysadmin minimal desktop and
learning/experimenting/development environment.
(Which all can be invalid from another point of view.)

Post by Michael Prokop

Post by Csillag Tamas
comgt (180k)

Thanks, re-added already: http://git.io/rtTeQg

Thanks.

Post by Michael Prokop

Post by Csillag Tamas
libnet-*-perl

They used to be dependencies of other packages that aren't available
any longer. Is there any specific package that's considered relevant
for install and rescue?

ok, I understand.
Maybe this is not that important. I agree.

Post by Michael Prokop

Post by Csillag Tamas
mutt
postfix (I was using this for educating mailing basics also good for
testing)

In an friendly evironment it is easy to mail with postfix and mutt.
replying to another mail in this thread:
If your mail is available on an imap server a stock mutt config is
enought for sending/receiving mails, a bit tweaking in postfix can be
necessary.

Post by Michael Prokop

Post by Csillag Tamas
runit (520k)

What's the benefit for the live system?

I find many of its tools valuable. Like setting up (mini) services for
replicating data to other machines on the network (along with ipsvd).

Post by Michael Prokop

Post by Csillag Tamas
rxvt-unicode (this was part or the release from the begining)

xterm is there and should be enough for install and rescue mission, IMO

rxvt-unicode is quite small, much more flexible and resource friendly
than xterm.

Post by Michael Prokop

Post by Csillag Tamas
What kind of testing is needed to get (most/some of) the tools back
on the cd?

* taking care of failing builds (we provide daily builds at
http://grml.org/daily/ and trigger ISO builds with each git
commit)
* integrating packages into Grml tools (grml-quickconfig,
grml-x,...), window manager, providing sane default configs,...

I think most of the tools we are talking about either do not need
configuration or the default is ok.
grml-* tools are ok. For tools already there in 2011.05 maybe not a
must-have.

Post by Michael Prokop
* taking care of bugs (see http://bts.grml.org/grml/) and
user support ("why doesn't foo work?")

I think most of the package related bugs is a valid debian bug also.
So it could make sense to forward to the debian bts.

Post by Michael Prokop
Thanks for your feedback, we highly appreciate that.

Thanks for your encouragement.

Post by Michael Prokop
[1] Thanks for the list. We will review and discuss your software
selection in further detail, promised.
regards,
-mika-

Regards,
cstamas

[Michael Prokop]

Post by Csillag Tamas
I also have a valid usecase.
(Maybe not one that grml targets.)
I used grml on my thinkpad x40 for a year when its expensive and
special HDD died. It served me quite well.
I also created a remastered version with the newest firefox and ubuntu
repo chromium on it.
What am I saying is that with these tools in question already
available it was (not perfect, but) quite usable.
When I left my pendrive in my friends car who gave me a lift to
debconf11 I tried grml-live to streamline the bootprocess for a brand
new grml and it also worked quite well.
So when I am talking about a tool I am also thinking about grml as an
educational tool, survive sysadmin minimal desktop and
learning/experimenting/development environment.
(Which all can be invalid from another point of view.)

:)

Post by Csillag Tamas

Post by Michael Prokop
* taking care of bugs (see http://bts.grml.org/grml/) and
user support ("why doesn't foo work?")

I think most of the package related bugs is a valid debian bug also.
So it could make sense to forward to the debian bts.

Absolutely, and we take care of that already. But it's work that
needs to be done, and the more packages we ship the more bugs we
might (and usually) run into. And there *are* bugs which prevent us
from building daily ISOs which then need special attention and
workarounds/patches/.... That's where we need help as well.

regards,
-mika-
-------------- 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/9fbf3a03/attachment.pgp>