I guess this rsync sloppery is going to make me write my own backup tool…
Timeline
Post
Remote status
Context
4
@lanodan wait rsync is slop now? 😭
@ska Yeah :( It's been since 3.4.2
@ska And thankfully I don't use rsync on my Alpine machines, only Gentoo where 3.4.1 is still available (and would probably be easy enough to keep for some time, although not forever).
Replies
8
@phnt @jn @ska Well… sure and it's what I do for my packages but then, how much time for reviewing the diffs between LLVM/Firefox/… versions?
It's the kind of stuff where if you'd apply it, it would be *smaller* than BSDs. (As proven by lack of code-review of OpenSSL during heartbleed era, xz-utils during Jia Tan, …)
Like probably would be 9Front-sized.
It's the kind of stuff where if you'd apply it, it would be *smaller* than BSDs. (As proven by lack of code-review of OpenSSL during heartbleed era, xz-utils during Jia Tan, …)
Like probably would be 9Front-sized.
@lanodan @jn @ska Reviewing every diff isn't doable I think, unless you actually bring llms into the equation which could go through those. But you also have to manage that as well, not including the various questions about llms which I won't go through. I mean it more in terms of automated testing and checking that upstream didn't do something completely stupid. Netdata suid binary path traversal comes to mind for example, which should have been caught by any distro trying to be serious and packaging it.
On the matter of size, software is getting larger and won't stop. IMO sizes like Linux, LLVM, Firefox, Chrome should be an exception and are a problem in an of itself. Those codebases are all unauditable.
Also on the topic of OP, borgbackup is nice although written in python/cython. Definitely don't use tar ;)
On the matter of size, software is getting larger and won't stop. IMO sizes like Linux, LLVM, Firefox, Chrome should be an exception and are a problem in an of itself. Those codebases are all unauditable.
Also on the topic of OP, borgbackup is nice although written in python/cython. Definitely don't use tar ;)
@phnt @jn @ska Well yeah we could have tools to help (say static analysis kind of thing, fuck LLMs at 100%) and to be clear it's not the kind of code review at the same level as the maintainer of the code, it's more skimming through it to see stuff like dependency and other packaging relevant changes and if there's something obviously bad in the code.
We've lost the plot in distros when it comes to doing that.
Also imagine effectively banning Rust/Go/npm/… stuff because there's just no way anyone would vet all the code involved for 99.999% of this stuff.
Plus of course also effectively banning OCaml, dotnet-sdk, Haskell, Swift, Pascal, … because you can't have those without binaries.
We've lost the plot in distros when it comes to doing that.
Also imagine effectively banning Rust/Go/npm/… stuff because there's just no way anyone would vet all the code involved for 99.999% of this stuff.
Plus of course also effectively banning OCaml, dotnet-sdk, Haskell, Swift, Pascal, … because you can't have those without binaries.
@lanodan @jn @phnt@fluffytail.org
Also imagine effectively banning Rust/Go/npm/… stuff because there's just no way anyone would vet all the code involved for 99.999% of this stuff.
Honestly? I wish this would happen.
The situation we're in is one some of us have been warning against for ages, and I've been saying that anything non auditable should be banned. Obviously, nobody listened to me, and would you look at that, shit hit the fan.
Unless and until we start, if not from scratch, at least from way back and slowly and with proper scientific approach this time, things will be unmanageable.
@lanodan @jn @ska I know, I've tried. Similarly I was really annoyed at gkh's decision to file CVEs for absolutely benign things in the kernel out of spite for the system. I know that the system sucks, but me going through 150 CVEs per-release to figure out if they actually matter isn't a good solution either.