[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] On replacing tar, why not dar ?
From: |
edgar . soldin |
Subject: |
Re: [Duplicity-talk] On replacing tar, why not dar ? |
Date: |
Wed, 9 Sep 2015 15:49:42 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 |
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
>
- Re: [Duplicity-talk] On replacing tar, why not dar ?, Meta Schima, 2015/09/02
- Re: [Duplicity-talk] On replacing tar, why not dar ?, Kenneth Loafman, 2015/09/07
- Re: [Duplicity-talk] On replacing tar, why not dar ?, Kenneth Loafman, 2015/09/08
- Re: [Duplicity-talk] On replacing tar, why not dar ?, Zach Adams, 2015/09/08
- Re: [Duplicity-talk] On replacing tar, why not dar ?, Aaron Whitehouse, 2015/09/09
- Re: [Duplicity-talk] On replacing tar, why not dar ?,
edgar . soldin <=
- Re: [Duplicity-talk] On replacing tar, why not dar ?, Kenneth Loafman, 2015/09/09
- Re: [Duplicity-talk] On replacing tar, why not dar ?, Zach Adams, 2015/09/09
- Re: [Duplicity-talk] On replacing tar, why not dar ?, Scott Hannahs, 2015/09/09
- Re: [Duplicity-talk] On replacing tar, why not dar ?, Zach Adams, 2015/09/09
- Re: [Duplicity-talk] On replacing tar, why not dar ?, Kenneth Loafman, 2015/09/09