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

[Ulrich Dangel]

* Tom {Tomcat} Oehser wrote [28.12.11 05:32]:
> 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

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

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


> 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 

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

> 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
-- 
twitter: @mr_ud  | identica: @mru
IRCNet:  mru     | freenode: mrud