RED ALERT LENNART IS RELEASING A NEW PROJET

phoronix.com/scan.php?page=news_item&px=Lennart-casync
>Lennart has been working on casync the past number of months as a project inspired by rsync and Git while aiming to be a new tool for distributing file-system images.
>inb4 fedora, debian, ubuntu and arch adopt it
>inb4 muh lincucks veterans forking distros like there is no tomorrow

Other urls found in this thread:

0pointer.net/blog/casync-a-tool-for-distributing-file-system-images.html
github.com/systemd/casync/pull/23
en.wikipedia.org/wiki/Feature_creep
hub.docker.com/r/suckowbiz/gimp/
github.com/jamesnetherton/docker-atom-editor
github.com/mviereck/x11docker
twitter.com/AnonBabble

God damn it Lennart

Oh shit nigga. Someone ring the alarm!

How long until it has all the features of a filesystem itself?

Someone stop him
STOP HIM

the fuck is wrong with rsync

What the fuck is wrong with you guys? If you don't like his software - don't install it.

Pulseaudio and systemd are great, tho.
Thank you, based Len Artpottery.

shoo shoo lennart

...

We won't. The problem is what ever shit Lennart makes for some reason major linux distributions start using it. And they will suffer from it like with pulseaudio and systemd.
It just sucks that sometimes you have to deal with ubuntu / redhat / centos in working environment.

Wew lad. Will this be the official systemd/Linux package manager?

Sounds pretty nice desu

This. What's the fucking point?

Based Lennart.

It doesn't really meet the same requirements. Read his explanation 0pointer.net/blog/casync-a-tool-for-distributing-file-system-images.html

No, this isn't a "rsync replacement for everyone", but it could be a very nice backup tool. Many of the backup tools that wanted to perform better with deduplication or such have gone in this direction anyhow.

I don't get why he couldn't have just submitted a patch to do this in rsync. It sounds like a very narrow use case to me.

It is a more clever approach than rsync. Even having to walk and checksum the whole directory tree to be sure the destination node can replicate the source is unfriendly, but there is more.

This is completely not like rsync.

Maybe git, bup, borg, zbackup or something could have been somehow patched, but I don't think that would have been a good idea overall.

This sounds like something that needs to be done from scratch.

>to make this work we'd need a patch, as nobody of us tests this
-- Lennart

(cont'd)
Oh, actually they even wrote a git commit about borg:
github.com/systemd/casync/pull/23

Why not? Add an option in rsync that does his fancy variable block chunking shit.

>2 programs that do a job well
>wants to combine them to create a convoluted clusterfuck of fuck knows what which even he can't explain
>even the diagram is a mess

Fuck, you never write software, do you?

Might as well ask why git wasn't added to lftp.

en.wikipedia.org/wiki/Feature_creep

Google is releasing their backup sync tool on the 28th supposedly.

Inb4 lennarts only works with btrfs.

I've only looked at the diagram, but this sounds really similar to Jigdo.

>software can't call other software to perform functions

Never stopped him before.

>wants to combine them to create a convoluted clusterfuck of fuck knows what which even he can't explain
He explains it well enough and in some detail, what more do you want? A reduction to Apple marketing bullshit?

It's the best sync he has ever done. Lel.

Thank fuck i installed devuan already, dodged a bullet there.

Fuck poetterware. It's already a stretch I'm tolerating PA. But it's stable enough.

> software can't call other software to perform functions
No, rsync and git can't do this.

And he is using other software such as fuse, curl, lzma, libacl.

>Never stopped him before.
Yeah, so it's better to have him isolate that shit to his own project than spread the cancer to rsync like suggested.

>lennartware
>isolated
If only

He should try using rsync too.

Yeah...

> dodged a bullet there
You did not dodge shit.

> It's already a stretch I'm tolerating PA.
Feel free to use just plain ALSA. It's shittier though.

At what step specifically will you need rsync?
> Encoding: Let's take a large linear data stream, split it into variable-sized chunks (the size of each being a function of the chunk's contents), and store these chunks in individual, compressed files in some directory, each file named after a strong hash value of its contents, so that the hash value may be used to as key for retrieving the full chunk data. Let's call this directory a "chunk store". At the same time, generate a "chunk index" file that lists these chunk hash values plus their respective chunk sizes in a simple linear array. The chunking algorithm is supposed to create variable, but similarly sized chunks from the data stream, and do so in a way that the same data results in the same chunks even if placed at varying offsets. For more information see this blog story.

> Decoding: Let's take the chunk index file, and reassemble the large linear data stream by concatenating the uncompressed chunks retrieved from the chunk store, keyed by the listed chunk hash values.

> As an extra twist, we introduce a well-defined, reproducible, random-access serialization format for directory trees (think: a more modern tar), to permit efficient, stable storage of complete directory trees in the system, simply by serializing them and then passing them into the encoding step explained above.
Where does rsync fit in here? And why does it fit better than, say, ftp or scp?

Still no replacement for GRUB that can boot (preconfigured, e.g. when a device gets driver support from a community, outside of the OS ISO itself/integrated) images dynamically.
Booting Linux should ALWAYS look like on Android phones.

Scrap GRUB, replace it with something that can boot OS images by dynamically mounting them and get rid of the driver fuckery altogether.

Somebody has the same device as you and managed to configure everything so that it works?

Well, you have to copy his steps 1 by 1 to get it working.
With Android however, you install images with drivers fully configured and installed from the community, no need to repeat configuration personally, somebody did it already and shared it with you.

Linux on the desktop has NONE of this.
With obscure commands you can boot ISOs through GRUB, but it's not intended for making things easier, it's just in there to build shitty bridges for shitsupported hardware.
Configuring a Linux and making an ISO out of it ain't an easy job either. Big construction site, especially when you consider UEFI and secure boot rekting everything anyway. Could start over again and do it properly once and for all.

tl;dr Linux is still shit, wrong problem was solved.

> Booting Linux should ALWAYS look like on Android phones.
Fuck no. Android phones should have an interactive boot selection capable loader.

> Scrap GRUB, replace it with something that can boot OS images by dynamically mounting them
GRUB can do that, what are you even talking about?

Not that this is typically delegated to GRUB in reality, you usually do it with VMs or such.

There are many ways to do this with far more complex setups than Android permits.

> With Android however, you install images with drivers fully configured and installed from the community
Yea, use fucking virtualization or paravirtualization images. Or containerized distros.

> Linux on the desktop has NONE of this.
It has hundreds more options. You're just the kind of retard who should stick with Android. No options to do various setups - just a ROM specific to your device.

But you already have Android. We don't need Linux to be Android, too. Linux needs to cover more complex use-cases that Android can't.

>I don't need Linux to be Android

FTFY

I'm sure you hate snaps as well.

I'll assume you mean the idiotic 50th implementation of a Windows installer on Linux, not snapchat images or the other meanings of "snaps".

Yes, they're fucking stupid as compared to docker / rkt containers. [You know, the stuff companies and people ACTUALLY use.]

Alright, I see.

But what about stuff like e.g. Atom Text Editor or GIMP? Why is that only available as a snap and not a docker image? Sorry for going offtopic here, but now I would like to know.

> Why is that only available as a snap and not a docker image?
They are available as a docker image.
hub.docker.com/r/suckowbiz/gimp/
github.com/jamesnetherton/docker-atom-editor

PS: These are not the only images for these two applications. There are more, and I don't know how you missed them.

Wew lad
>I don't know how you missed them
Same, thanks, you teached me something useful. Much appreciated.

By the way, if you want a GUI thing to use this, consider:
github.com/mviereck/x11docker

Looks amazing, thanks.