WDef
Group: Members
Posts: 798
Joined: Sep. 2005 |
|
Posted: Sep. 22 2005,07:04 |
|
Again, I'm not necessarily proposing that lzop should be added to the base.
It would be very easy to change the hack to be able to use lzma, bzip2 or any other comp programs as well as lzop and gzip, depending on what compression extension was loaded. You could then take your pick of max speed or max compression, or a compromise. How's that for a big picture.
ie This does not have to be solely about lzop in the longer term, so could we please not get bogged down in a discussion about the merits of various programs.
What I am asking for now are testers for the present extensions.
So far nobody has said they've tried these yet. How about some feedback?
----------------------------------------- To respond to Friedgold's points:
Thanks for the figures. These will vary according to the mixture of data types of course.
Quote | ..making it hard to manipulate the files in the backup from outside DSL. |
If you've restored using lzop and decide to backup using gzip, just remove the lzop binary thus
Code Sample | sudo rm -f /bin/lzop |
and hit backup. You should get a gzipped tarball back. Then either don't load lzop.dsl at next boot, or you can delete /move the previous lzopped tarball from the backup device. The altered script should then restore much as the original did. Of course a change of comp prog could easily be automated from (eg) the backup/restore widget.
Similarly, if you've restored ordinarily with gzip, you can load the two extensions and hit backup to get an lzopped tarball.
Lzop is available for Windows, and various *nixes etc. There's a statically-linked i386 linux binary anyway.
Quote | ..l.ess useful when space is limited (e.g. on a pendrive). |
Pendrives are very slow to write to, and getting rapidly bigger, so some who back up on pendrives might be looking for whatever speed gains they can get.
|