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