duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] On replacing tar, why not dar ?


From: Zach Adams
Subject: Re: [Duplicity-talk] On replacing tar, why not dar ?
Date: Wed, 9 Sep 2015 10:31:05 -0500

libdar has binary packages provided for Windows and Mac OS and it says
it has been tested on several other systems as well. I don't know what
platform dependencies duplicity has at the moment, but if duplicity
eventually becomes a wrapper around libdar then it seems reasonable
that it could become cross-platform.

Zach

On Wed, Sep 9, 2015 at 8:49 AM,  <address@hidden> wrote:
> i totally agree with every point you make Aaron. it should be an optional 
> component as long as it is unstable or developed within a completely new 
> forked differently named project, so users will be able to enjoy a working 
> duplicity.
>
> just a sidenote. someone mentioned that using libdar would make duplicity 
> more cross-platform. my experience is that each platform dependent library 
> makes it more difficult to maintain/distribute a software for different 
> platforms.
>
> ..ede/duply.net
>
> On 09.09.2015 15:38, Aaron Whitehouse wrote:
>> I haven't personally used dar. It looks as though it has some very
>> interesting features, but mainly only one (quite active) developer. I
>> see that public key encryption is only available in the pre-release version:
>> http://sourceforge.net/p/dar/feature-requests/67/
>>
>> I'm always nervous when people talk about a complete rewrite,
>> particularly in a small project and particularly where it is something
>> critical like backups (and you may not find issues until you come to
>> restore the backup many years later). It also reminds me of:
>> http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx
>> http://www.joelonsoftware.com/articles/fog0000000069.html
>> It tends to create a pretty bad user experience: all the developers want
>> to work on the new version; all the users are on the old version; and
>> you spend all your time telling users that their bug will be fixed in
>> the new version, but that they can't use that yet because it isn't finished.
>>
>> Is there any reason that we couldn't do things more incrementally? Say:
>> 1. add in dar to do exactly what we currently use tar for (and no more;
>> potentially activated by a commandline option?);
>> 2. switch the default to write dar files (but read either type);
>> 3. as developers have time, we could replace pieces of home-brew code to
>> use dar's features when duplicity is using dar files; and
>> 4. if maintenance of the tar-writing codepaths is considered too much of
>> a burden, turn off tar file output (though keep tar reading code).
>>
>> I would expect it would create a much better user experience, if nothing
>> else, and would mean that we could more gracefully deal with things like
>> the user having an old version of libdar that doesn't contain the
>> required feature (taking the above example, use our encryption code for
>> public key encryption until the user is both outputting to dar files
>> *and* has a version of libdar that supports public key encryption).
>>
>> Just my thoughts and happy to be proven wrong by somebody who knows more!
>>
>> Aaron
>>
>>
>> On 08/09/15 16:54, Kenneth Loafman wrote:
>>> Except for rsync processing, dar does a lot of what we need:
>>> compression, encryption, hard links, split files, etc., plus it's
>>> fast.  The backend processing could be done after the .dar file
>>> creation, so it looks like rsync processing is the only addition to be
>>> made.  Granted, handling the signature files would be a PITA, but that
>>> could be done by dar as well.  We would only need two file types, dar
>>> and sig.
>>>
>>> This would do away with most of duplicity's guts and make libdar the
>>> central player in duplicity.
>>>
>>> This does not sound like a bad idea to me.  Someone else weigh in please.
>>>
>>> ...Ken
>>>
>>>
>>> On Mon, Sep 7, 2015 at 10:00 AM, Kenneth Loafman <address@hidden
>>> <mailto:address@hidden>> wrote:
>>>
>>>     Don't really need to reimplement, just make sure that the python
>>>     bindings are sufficient to access libdar fully.  I think that
>>>     driving dar from duplicity would be nearly a rewrite since I see
>>>     so much that dar does would replace much of duplicity's
>>>     functionality.  It might even be easier to start with libdar and
>>>     add the librsync functionality to it, wrapping all that with
>>>     multiple backends.  Just a wild thought, but it would give us a
>>>     solid basis on which to add.
>>>
>>>     A new structure like dar would solve a lot of the problems we
>>>     currently have, including split signature files, better manifest
>>>     handling, etc.
>>>
>>>     Just a thought, but sometimes a complete rewrite solves a lot of
>>>     problems.
>>>
>>>
>>>     On Wed, Sep 2, 2015 at 9:30 PM, Meta Schima <address@hidden
>>>     <mailto:address@hidden>> wrote:
>>>
>>>         People have made some python bindings to dar, but
>>>         re-implementing dar in python is probably not feasible.
>>>
>>>         > -----Original Message-----
>>>         > From: address@hidden <mailto:address@hidden>
>>>         > Sent: Mon, 31 Aug 2015 11:35:12 +0200
>>>         > To: address@hidden <mailto:address@hidden>
>>>         > Subject: Re: [Duplicity-talk] On replacing tar, why not dar ?
>>>         >
>>>         > On 31.08.2015 02 <tel:31.08.2015%2002>:50, Meta Schima wrote:
>>>         >> Hello,
>>>         >>
>>>         >>     In regards to:
>>>         >>
>>>         >> http://duplicity.nongnu.org/new_format.html
>>>         >>
>>>         >>     Why not use the dar archive ? It was specifically
>>>         designed to
>>>         >> replace tar, and adds all the features that you want:
>>>         >>
>>>         >> https://en.wikipedia.org/wiki/Dar_%28disk_archiver%29
>>>         >> http://dar.linux.free.fr/
>>>         >>
>>>         >>     It has also been in development for 10 years so is mature.
>>>         >>
>>>         >>     Just a suggestion.
>>>         >>
>>>         >
>>>         > tar is available as plain python module. are you aware of a
>>>         python dar
>>>         > implementation?
>>>         >
>>>         > ..ede/duply.net <http://duply.net>
>>>         >
>>>         > _______________________________________________
>>>         > Duplicity-talk mailing list
>>>         > address@hidden <mailto:address@hidden>
>>>         > https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>
>>>         ____________________________________________________________
>>>         FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
>>>         Check it out at http://www.inbox.com/earth
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Duplicity-talk mailing list
>>>         address@hidden <mailto:address@hidden>
>>>         https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Duplicity-talk mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>>
>>
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk



reply via email to

[Prev in Thread] Current Thread [Next in Thread]