4 ms·
- No need to be snarky. It's a new project, while rsync is time tested, and that is certainly an advantage for rsync and all old software. - You can install by
by greaber 22d ago
- No need to be snarky. It's a new project, while rsync is time tested, and that is certainly an advantage for rsync and all old software.
- You can install by piping curl to bash, using brew, or by compiling yourself. One thing about distribution I would argue syq gets right is that you are never relying on whatever version of syq happens to be installed on a server. The client syq always talks to a server syq tagged with the exact same version, and when your local copy of syq installs a remote copy, it verifies that the remote binary is signed by me.
- I never said or implied that rsync has a byzantine interface or poor documentation. I think rsync is well documented and the interface is overall fine. Syq even has an rsync compatibility mode, so you don't have to learn any new syntax if you don't want. Still, I tried to provide good docs for syq too, and honestly even if there were a gap in the docs, all you have to do these days is ask AI to look at the source code and tell you what to do. I think this also mitigates the trust issue with a new project from a single contributor.
- ProphetOfParado 22d agoHow do you hope to convince sys-admins to install this? I work with clusters where I do not have superuser access, so this is a no go for me.
- greaber 22d agoIt just installs in $HOME/.local/bin by default (and some other parts go in other locations inside your home directory). You don't need superuser access for anything. The first time you connect to a server, it installs its matching counterpart in your home directory on the server.
- unsnap_biceps 22d agoHonestly, that's even scarier for an untrusted/low trusted tool...
- cstrahan 22d agoWhat is it about a tool, running as your own non-root user, installed in your home directory, that makes it scary?
- unsnap_biceps 21d agoLet's say this is widely used and let's presume that a specific version has a security issue. With everyone having their own copy of the binary on every host versioned at the time they first ran a command on that host, or any decently sized fleet, it'll take a big effort to track down and ensure all versions have been updated or removed (to be re-generated later). Frankly, we would re-kick our fleet ahead of schedule rather then try to remediate it more manually. But we re-kick our fleet on a rotating yearly schedule, so it's not too much an effort to re-kick it earlier. It's a completely automated system in place now.
- ProphetOfParado 22d agoAh, that's nice!
- nimih 22d agoFWIW, I'm only half-joking with my comment: dealing with software updates is an annoying part of life, and IMO rsync's UI is rather complicated (in that it's easy to use the wrong set of flags and do the wrong thing, sometimes in annoyingly subtle ways) and I basically always need to refer to the man pages (or, these days, an LLM, followed closely by the man pages to sanity-check what I'm doing) whenever I'm writing a new incantation of it rather than copying from an existing script or my shell history. I just chafe a little bit at declarations like "better than," since that's clearly not true (in the same way that rsync is not unequivocally "better than" syq), when more precise and less conceited descriptors like "faster than" are sitting right there on your benchmarks page.
- greaber 22d agoYeah, I get that. I really didn't mean to sound conceited, and I don't think that syq is better than rsync for every use case. I was just trying to convey in a very short space that it is something that rsync users might be interested in because it solves some frustrations with rsync.