The Interwebs are littered with this question - please use a web search engine of your choosing and let’s not delve into the matter deeper here.
Some people use OpenBSD, and not, i.e. macOS; mg(1) instead of Emacs; vi(1) instead of Vim… I guess the answer is usually the same - because it works for them.
I did search the web. The question is common, but the only answers given are pat replies such as yours which don’t actually answer anything.
“It works for me” is a cop-out, and makes no sense given that this person clearly is familiar with git yet still chooses to use CVS privately. So it can’t be a case of “it isn’t broken, don’t fix it”, which only makes sense in order to save yak-shaving effort. But yaks are being shaved here in order to use CVS as the source of truth. That’s surprising.
“vi vs emacs” is a case of equivalent tools. CVS vs git is not such a case.
I want to know why someone would actively avoid using git in favor of CVS for private use, when one is familiar with both. Even “personal fetish” is a more satisfying answer than the aw-shucks “to each his own” automated tripe.
Fetish is at least a conscious choice. Technical reasons would be more interesting. But I suspect the reason is actually license-based, and that’s what I would like to know.
Sounds like you already have an answer prepared for me, buddy! It’s just a tool that does what I need it to do. I don’t know what the fuss is about. (I can’t speak for OpenBSD—just me.)
I don’t know about that. Unit testing is definitely less common than in dynically typed languages, but sqlite, for example, is one of the most thouroughly tested pieces of software I know of.
It’s probably bad to use sqlite as an example of what (general class of people here) do in QA for C code given it’s pretty unique in its level of QA. If anything, it’s evidence of what QA its project leader and/or team are willing to do when writing C.
I didn’t say unit testing. I mean for rsync I would probably just have a script that can generate random directories and sync them while taking metrics.
No, you don’t get the benefit of those particular syscalls. Emacs on OpenBSD is pledged too, that doesn’t mean it can’t function just fine everywhere else without pledge.
Perhaps, tedu. However, rsync (and openrsync) specifically accommodate for running as root with full access to one’s file system, accepting ill-specified data coming down the wire. It’s chmoding and chowning and renaming. A lot of moving parts. And on stock rsync, without even chroot in there. (Except for, optionally, –daemon.) It’s bare-back. And especially when you’re talking to a public rsync:// daemon, you have no idea what’s running on the other end. Which is usually the case as root, I might add.
I know that @rain1 amongst others have done some analysis in how to effect pledge/unveil security measures on Linux, but folks like the child derail his efforts. This is 2019 and Linux folks are stuck with seccomp-bpf and… namespaces?… it’s a mess, I know. But this attitude of “strip away the security” is harmful and irresponsible and contributes to the CVE culture. Instead of nooping, consider working together with other folks to improve the status quo.
(This last bit isn’t to you, @tedu, but the nooper.)
No. I will welcome a non-noop implementation with joy when it works. For now to get better, saner and safer software (just by the team and policies that created it) I can handle two syscalls nooping.
The website is awfully empty but I heard about this a month ago, so this might be more useful:
http://www.undeadly.org/cgi?action=article;sid=20190211081518
https://github.com/kristapsdz/openrsync
Yes, different stages have been linked to previously:
Now, it looks like OpenRsync is on its way to becoming (announced as) an official OpenBSD-associated project, like all the other ones:
Not just a piece of software that has been imported into the tree.
They sure seem to love CVS in OpenBSD land. Why?
The Interwebs are littered with this question - please use a web search engine of your choosing and let’s not delve into the matter deeper here.
Some people use OpenBSD, and not, i.e. macOS; mg(1) instead of Emacs; vi(1) instead of Vim… I guess the answer is usually the same - because it works for them.
I did search the web. The question is common, but the only answers given are pat replies such as yours which don’t actually answer anything.
“It works for me” is a cop-out, and makes no sense given that this person clearly is familiar with git yet still chooses to use CVS privately. So it can’t be a case of “it isn’t broken, don’t fix it”, which only makes sense in order to save yak-shaving effort. But yaks are being shaved here in order to use CVS as the source of truth. That’s surprising.
“vi vs emacs” is a case of equivalent tools. CVS vs git is not such a case.
What is it you want to know?
I want to know why someone would actively avoid using git in favor of CVS for private use, when one is familiar with both. Even “personal fetish” is a more satisfying answer than the aw-shucks “to each his own” automated tripe.
Fetish is at least a conscious choice. Technical reasons would be more interesting. But I suspect the reason is actually license-based, and that’s what I would like to know.
Sounds like you already have an answer prepared for me, buddy! It’s just a tool that does what I need it to do. I don’t know what the fuss is about. (I can’t speak for OpenBSD—just me.)
expert C programmers don’t seem to like writing test cases, though the code seems to always work as advertised so I can’t complain too much.
I don’t know about that. Unit testing is definitely less common than in dynically typed languages, but sqlite, for example, is one of the most thouroughly tested pieces of software I know of.
It’s probably bad to use sqlite as an example of what (general class of people here) do in QA for C code given it’s pretty unique in its level of QA. If anything, it’s evidence of what QA its project leader and/or team are willing to do when writing C.
Also NetBSD has been working steadily on improving their test coverage with Kyua.
I didn’t say unit testing. I mean for rsync I would probably just have a script that can generate random directories and sync them while taking metrics.
There’s https://www.opencvs.org/ as well, but luckily rsync is a smaller (I think) project to replicate
Not to mention that Andrew Tridgell’s PhD thesis is a nice and short read.
‘Roughly 100 pages’ is short ?
:) Well, the core part of the algorithm is short - see page 49 onwards.
It would be wonderful to have a port of this on linux, but for that we really need a solid reimplementation of pledge and unveil.
At least those can be noops without compromising function.
No, they can’t. openrsync functions securely. Take away the security, you take away the functionality.
No, you don’t get the benefit of those particular syscalls. Emacs on OpenBSD is pledged too, that doesn’t mean it can’t function just fine everywhere else without pledge.
so rsync does not function?
That seems an unreasonably pedantic reading of “security is a feature”.
Perhaps, tedu. However, rsync (and openrsync) specifically accommodate for running as root with full access to one’s file system, accepting ill-specified data coming down the wire. It’s chmoding and chowning and renaming. A lot of moving parts. And on stock rsync, without even chroot in there. (Except for, optionally, –daemon.) It’s bare-back. And especially when you’re talking to a public rsync:// daemon, you have no idea what’s running on the other end. Which is usually the case as root, I might add.
I know that @rain1 amongst others have done some analysis in how to effect pledge/unveil security measures on Linux, but folks like the child derail his efforts. This is 2019 and Linux folks are stuck with seccomp-bpf and… namespaces?… it’s a mess, I know. But this attitude of “strip away the security” is harmful and irresponsible and contributes to the CVE culture. Instead of nooping, consider working together with other folks to improve the status quo.
(This last bit isn’t to you, @tedu, but the nooper.)
No. I will welcome a non-noop implementation with joy when it works. For now to get better, saner and safer software (just by the team and policies that created it) I can handle two syscalls nooping.
it certainly would be, if that’s what their post said
Out of curiosity, what is “easy to use” referring to? Other synchronising tools or the “regular” rsync?
Also, will this by available in base for the next OpenBSD release?
It’s part of -current at the moment, so unless there are reasons to pull it, it will most likely be part of base. It’s coming out if the RPKI validator initiative. https://undeadly.org/cgi?action=article;sid=20181130162059.