Thank you for showing this. I'll echo what some others say: if you're claiming to be faster than rsync, you should demonstrate why front-and-center. There have been decades of documentation on how rsync optimizes transfers, so it's a lot to live up to.
As an aside, It's perhaps an indictment of our networking landscape that multiple parallel connections between 2 specific machines would accelerate a transfer. I would've expected a single TCP connection to be able to saturate a line. Or perhaps the parallel connections seeks to amortize the per-file setup overhead?
I entirely agree that multiple connections shouldn't actually be necessary for speed, but they help in multiple situations (long-distance transfers, same DC between servers, NFS), and it's not just about amortizing per-file setup overhead.
There is some info on the optimizations in the docs, but I agree that a more complete technical explanation of all the things syq does could be useful. I will work on one. On the other hand, I also tried hard to make it just go fast without needing the user to understand why it is fast or tune anything. For instance, the number of connections is auto-tuned by default.
> There is some info on the optimizations in the docs, but I agree that a more complete technical explanation of all the things syq does could be useful
First, thank you for taking the feedback :)
To be clear, I'm focusing on the first thing you should be telling users. It seems that, as a CLI program, the target audience of this tool is fairly technical users who are likely already familiar with SSH, rsync, and everything. As demonstrated in this thread, your first communication task is to convince them why it's worth their time to use your tool, considering they're probably satisfied with the pre-existing ones (or a replacement would already exist!).
My point is, explaining why it's better/faster than rsync shouldn't be buried in the docs. It should be a paragraph on the front page.
Hope this helps, and keep it up. HN is a rough audience to go public on ^^;
> I would've expected a single TCP connection to be able to saturate a line
There's several factors at play that make this (usually) not the case.
Besides physical latency (which includes those added by any VPNs/tunnels/etc., some of which may be internal to an ISP along the route and outside of your control), there's other things like the TCP window sizes / window scaling option[1] that can affect single stream performance, and those type of parameters can differ by OS/interface type on both ends.
Also for SSH specifically, it has its own fixed buffer size that also limits throughput unless you're using the HPN-SSH fork[2].
Also, in syq, a connection is the unit of independent transfer work. Probably it would be possible to get higher bandwidth per TCP connection by some kind of multiplexing, but that architecture would be more complex and probably not have many benefits.
There's also MPTCP (multipath TCP) which is even supported on mobile devices these days. So for example if your device has both a wifi and a cellular connection, and both ends of the stream support MPTCP, you can increase throughput/failover by combining multiple interfaces.
Princess Mononoke & Spirited Away (and also Kiki's Delivery Service because it was a package. Not that it's bad, but not as important to me as the other two)
Into the Spider-Verse, for breaking away from the 3D animation movie style
I'll have to rewatch Princess Mononoke; I haven't seen it since it was in the theater in the US. I remember not liking it as much as the other Miyazaki I've seen, but I'm a different person today.
I tried it a few years ago, following all the "It's actually good now!" stories.
But a few hours into the tutorial, at a point of yet another "go gather 20 wolf Pel^H^H Ores from that other planet and bring it back", and I lost interest.
The inner gameplay loop didn't work for me, and I need that hook.
Have there since been improvements to that inner loop?
In contrast, Destiny 2 keeps hooking me back in because its inner loop, the gunplay and abilities, and variety of builds, really works for me.
Yep. Last time they made a mini iPhone it didn’t sell as well as they expected. It seems the market loves big phones. I bet these folding iPhones will sell like hotcakes.
To reinforce your point, by default on macOS you can't use Tab to select different options in a dialog box. You have to enable that in System Settings -> Keyboard -> "Keyboard navigation" which is off by default.
See also when Microsoft introduced DocX, Apple products corrupted documents because Apple followed the standard that Microsoft had specified but turns out they didn't follow it themselves.
This is off-topic, but I am reminded of the sci-fi novel Eternity by Greg Bear, in which the protagonist Olmy downloads a copy of an alien Jart mind into his nanowear to study it. Turns out this was a trojan horse, and the Jart escapes the confines of the sandbox.
> Curry emphatically denied that interpretation. “I saw the Muppets as actors with distinct personalities,” he said. “It’s astonishing how quickly you see them as people.”
There's a video that expands on Tim Curry's time with the muppets: The Muppets Brought Out the Best in Tim Curry https://youtu.be/XzU8f4HaQw0
> In this video, we look at why Tim Curry’s Long John Silver works so well in Muppet Treasure Island, not just because he’s funny, theatrical, and completely larger than life, but because he understood the real magic of acting with the Muppets.
> There’s a popular idea that Michael Caine treated the Muppets like real actors, while Tim Curry treated himself like a fellow Muppet. But according to Curry himself, that isn’t quite right. He didn’t see Kermit, Miss Piggy, Gonzo, Rizzo, or the rest of the Muppet crew as props or puppets. He treated them as fully formed characters with their own personalities, timing, and emotional lives. That may be the key to why his performance feels so alive.
> This video essay explores Tim Curry’s casting as Long John Silver, his love for the Muppets, his larger-than-life theatrical style, and the behind-the-scenes energy of Muppet Treasure Island. We also look at how the Muppet performers stayed in character, how Curry approached the songs and comedy, why the “A Professional Pirate” number works so well, and how one surprisingly heartfelt scene with Jim Hawkins revealed a more vulnerable side of Curry’s acting.
Both Tim Curry and that video seem to misinterpret the "popular idea", at least as it is stated in this thread.
It doesn't say anything about how Tim Curry viewed the Muppets, but rather about how Tim Curry treated himself. It stands to reason that if he was, say, method acting as an actual Muppet, that he too would view the other Muppets as fellow actors with their own identities etc.
That was my reading of it too - Curry's response seems to seek to refute something that the original quote didn't actually say!
I can definitely see how someone could interpret it that way, assuming it's implying that he didn't see them as real, but I think that's an incorrect assumption and the quoted observation wasn't actually implying that at all.
As an aside, It's perhaps an indictment of our networking landscape that multiple parallel connections between 2 specific machines would accelerate a transfer. I would've expected a single TCP connection to be able to saturate a line. Or perhaps the parallel connections seeks to amortize the per-file setup overhead?
reply