Lennart Poettering Announces New Project: casync

[Krejzi]

The thing is, the Unix philosophy isn't right for all problems. The idea of having lots of small modular programs used to compose a whole does result in clean implementations - but the limitation is that they sometimes lose on efficiency, because they can't take a high-level view of the problems. Monolithic solutions have their own downsides, but one of their strengths is the ability to perform optimisations that rely on having a more complete view of the problem.

Reading Lennart's post reminds me of another similar discussion a few months back, where someone had devised a replacement for the venerable "tar". The traditional UNIX approach is the one we're all familiar with - you pack your files into one with tar, then you compress the tar file with the compression tool of your choice, gzip / bzip2 / xzip, whatever. It's a clean design using interchangeable parts - but it's not necessarily optimal... you may be able to achieve better overall compression if the packing process is aware of the compression process; conversely, you might get better random-access into the compressed file if the compressor is aware of the packed data. The downside is that you lose the ability to mix-and-match modules.

It seems to be the same situation with this new project. The same thing *can* be done by taking a collection of existing tools and gluing them together - but if it can possibly be done *better* by designing a new tool that can incorporate knowledge of all steps of the process, it seems silly to reject it because it doesn't conform to the "Unix philosophy".

Ah, the irony of bsdtar. People claim BSD is true unix, yet bsdtar (ironically named part of libarchive) does something similar. It uses library functions, linked into single executable, no pipes.

[duby229]

nobody is going to trust arrogant idiot. you already stated that you don't know to this day

What I said was that I don't understand why people like you make that out to be somehow bad or wrong. You're the idiot that doesn't understand why it's not wrong or somehow bad. You can have your opinions of course. Haters gotta hate on something, and even when it is the most awesome capability.

[Krejzi]

May I ask where you're from? [country]

Not sure why this matters at all. I'm from SE Europe and I'll leave it at that.

[oleid]

Ah, the irony of bsdtar. People claim BSD is true unix, yet bsdtar (ironically named part of libarchive) does something similar. It uses library functions, linked into single executable, no pipes.

That's probably a little faster, but more inflexible. But bsdtar inherits all the disadvantages ment in the post you quoted due to the composite compressing a stream of information, not the single files being part of the archive.

[Delgarde]

That's probably a little faster, but more inflexible. But bsdtar inherits all the disadvantages ment in the post you quoted due to the composite compressing a stream of information, not the single files being part of the archive.

Yep - doing everything in one monolithic process doesn't mean that you *do* get improved efficiency... it merely makes it possible to make optimisations that could not be made with a more modular system.

[microcode]

Look, we all know full well that LP hates the Unix philosophy. But the real truth is that rsync, dd, truncate and a few others have been doing what LP needs for decades. And if he wasn't so scared of shell scripting he could already have been doing what he wanted.

rsync works great for syncing mutable filesystems, especially if you don't care if the update is atomic and you don't care what the final state is in terms of write timestamps and disk layout. In this case his tool is doing atomic patching of an unmounted filesystem image with deterministic output, something outside of rsync's capabilities. If you jerk your knee every time Lennart Poettering does something, you're going to have some sore joints.

[ElectricPrism]

So far I love the things LP has started that people seem to have hated on. systemd and other tools do their jobs adequately and simplify complex scenarios and standardize the foundation across distros making software work better IMO.

I recall BTRFS had several features or tools to sync over the network file-system changes which I think is cool.

https://btrfs.wiki.kernel.org/index.php/Incremental_Backup

https://github.com/digint/btrbk

https://github.com/stuartf/btrfs-remote

[ElectricPrism]

So far I love the things LP has started that people seem to have hated on. systemd and other tools do their jobs adequately and simplify complex scenarios and standardize the foundation across distros making software work better IMO.

I recall BTRFS had several features or tools to sync over the network file-system changes which I think is cool.

https://btrfs.wiki.kernel.org/index.php/Incremental_Backup

https://github.com/digint/btrbk

https://github.com/stuartf/btrfs-remote

[uid313]

Probably soon it will be baked into systemd so you can't run without it.

[Vistaus]

What I said was that I don't understand why people like you make that out to be somehow bad or wrong. You're the idiot that doesn't understand why it's not wrong or somehow bad. You can have your opinions of course. Haters gotta hate on something, and even when it is the most awesome capability.

Blablabla. What you said was also that you had been doing this for decades with other tools. Then people asked for examples but you never responded to that. So either you're lying about it or you're just trolling. If not, then I ask you one more time to gives us an example of how you've been doing this for all of those decades, 'cause me and quite a few others are interested.